On Tuesday, August 12, 2014 8:39:11 AM UTC-7, Jesper Kristensen wrote: > This templated prerendereing sounds like a complicated API. Is there any > advantage of this over what is possible today with a single page > application using history.pushState?
I'm still trying to wrap my head around the use case, but I'm with you on this so far... In order to support the proposed behavior, you would need to: (1) implement an endpoint that returns a base template page (2) implement page logic to receive the message, fetch right data, and render it If you have (1) and (2) implemented, you've effectively implemented the single-page app model. It seems like there are two cases to consider here: (a) You're on a page with the same base template as destination (b) You're navigating to a page with a different base template For (a), you're best off reusing the current context (it's already rendered, after all), and issuing a fetch for updated content and rendering it in place - with pushState, etc. Whereas for (b) you can also do it in place by prefetching the template and then issuing a data request for relevant data once you know the exact URL... Which, of course, is exactly how single-page apps work today. In short, seems like this is inventing a derivative single-page app model for building pages/apps, and that makes me wonder because it doesn't seem to make it any easier. Everything described here can be achieved with current tools, but perhaps could be made better with some smart(er) prefetch/prerender strategies? For example, prerender should not be limited to HTML: https://igrigorik.github.io/resource-hints/#prerender In your single-page app, you should be able to inject multiple prerender hints for images, CSS, JS, and let the UA fetch and process those ahead of time. Then, when the user triggers the action, just inject them into the doc and update the UI as necessary. ig _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform