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

Reply via email to