launchpad-dev team mailing list archive

[Robert Collins <robertc@xxxxxxxxxxxxxxxxx>]

So, going back at least 18 months, maybe more, there has been a long
slow-running conversation amongst us about what we render were, with
different projects choosing different answers.

I think we have enough data now, that we can consolidate on a good
default answer and ask that everyone pick that answers *by default*
with variation needing to be experiments - explicit decisions to learn
something new.

tl;dr: lets:
 * render searchable content on server side and client side using a
common template language
 * render the forms needed to file a bug server side and optionally client side
 * render all other forms exclusively client side and have them
communicate exclusively via the API

Currently we render most content server side (even things returned via
the API are often rendered server side to HTML: aieeeeee); this often
has performance issues (and see the separate discussion about
templating engines for other considerations). But, nearly all our
users have solid javascript browsers - browsers that can easily
support tools like handlebars.

In our efforts to provide a smooth experience for users via client
side logic, we're ending up reimplementing many things two or three
times (client side, API, python views). This is a lot of overhead and
not intrinsically beneficial.

We have an existing constraint from Ubuntu that headless Ubuntu server
installs be able to report defects; beyond that we have no need to
support anything other than users regular desktop browsers (in all
their varied glory). We do need to support a11y, but client side
rendering that adds stuff to the DOM usually handles that no worse
than what we do today.

Client side rendering helps ensure that our API meets all the needs of
our webapp, rather than being a second cousin which we update
sometimes. Making client side rendering an easier project choice (by
removing the duplicate work of doing client side rendering and server
side rendering) should then also benefit our launchpadlib users.

Google won't index javascript-rendered content (at least, that is
their official position) - they recommend folk have a server side
rendered version of anything they need indexed. So we'd want to render
anything that should get indexed (e.g. /~flacoste, or
/ubuntu/+source/gcc etc) on the server still, but we can use a common
template, and a common initial-data-assembly routine (the lp cache in
the view) to only write that once. (Yes, this assumes being indexed by
big search engines matters... a separate and interesting debate, but
currently we assume it does, and though I may be prejudging such a
discussion, I think it still matters).

Whatdoyouallthink?

-Rob