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