launchpad-dev team mailing list archive

[John Meinel <john@xxxxxxxxxxxxxxxxx>]

I think removing duplication is good, and being searchable from Google
is.still important. I worry a little bit for the Martin Gzs of the world,
that really prefer to run without javascript[1], but still are valuable to
have around.

John
=:->

[1] I'm not sure of all the reasons, but memory pressure and privacy come
to mind.
On Feb 21, 2012 6:01 AM, "Robert Collins" <robertc@xxxxxxxxxxxxxxxxx> wrote:

> 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
>
> _______________________________________________
> Mailing list: https://launchpad.net/~launchpad-dev
> Post to     : launchpad-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~launchpad-dev
> More help   : https://help.launchpad.net/ListHelp
>