On Wed, Aug 13, 2014 at 12:24 PM, Ilya Grigorik <igrigo...@gmail.com> wrote: > On Tue, Aug 12, 2014 at 3:17 PM, Jonas Sicking <jo...@sicking.cc> wrote: >> >> On Tue, Aug 12, 2014 at 1:04 PM, Ilya Grigorik <igrigo...@gmail.com> >> wrote: >> > 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. >> >> I don't understand what you are saying here. >> >> The point of (b) is that the different base templates. So it'd be very >> hard to use pushState and DOM mutations to morph the current page into >> the destination page. The fact that the destination page is template >> based doesn't make it any easier. > > > It's been done before, and with pretty good success: > - http://pjax.heroku.com/ > - https://github.com/rails/turbolinks - derivative of pjax and in fairly > wide use, since its core to Rails. > > As turbolinks repo notes, you get the most benefit from this technique when > you preserve the same CSS/JS... but the point is, full replace is not out of > scope either.
I don't understand why it makes a difference that the destination page is "template based". If the current page and the destination page use different CSS, JS and images, you are essentially morphing between two entirely different pages. If we think that's doable, then it sounds like we are arguing that prerender is not useful for same-origin navigation? Or am I missing something? Do you really think that Google would be able to morph a google calendar page into the google search result page? > On Tue, Aug 12, 2014 at 7:19 PM, Jonas Sicking <jo...@sicking.cc> wrote: >> >> On Tue, Aug 12, 2014 at 6:53 PM, Karl Dubost <kdub...@mozilla.com> wrote: >> > Le 13 août 2014 à 10:09, Jonas Sicking <jo...@sicking.cc> a écrit : >> But yes, this depends on scripting. It sounds like between the two of >> us we have three goals >> >> * Enable fast navigation between webpages in websites like bugzilla. >> * When a search result page is loaded, avoid loading and prerendering >> a separate DOM for each bug. >> * Avoid relying on JS. > > > So, same origin; substantially different page template; single-page app. I'm not sure why you say "single-page app"? The bugzilla search result page and the page rendering individual bugs are decidedly different pages right now. I.e. the DOM looks very different, they run different scripts, they are generated from different server-side scripts and they use different URLs, including the parts before the #. Maybe I don't understand what your definition of "single-page app" is. > It seems like the workflow you're after is something like: > <link rel="prerender" href="/some/other/template.html" > route="/other-thing/*" id="ABC"> > > When a navigation is initiated to "/other-thing/random", the above prerender > context is used: > - prerender context gets a notification that its visible (i.e. Page > Visibility API) > - prerender context inspects the actual target URL, extract right tokens > from it, does its thing... > > Is there even a need for postMessage, etc? Seems like the necessary pieces > are already there - i.e. the URL. The point of the postMessage was mainly to expose the actual target URL. I.e. by enabling a message channel between the initiating page and the prerendered page we wouldn't need to invent an API for exposing the target URL. Nor would we need to add a route attribute or define a URL pattern matching syntax. A message channel mainly uses components that already exist in the web platform. And it enables other features which would enable the prerendered page to be even more up-to-date by the time it gets rendered. > (Note: I'm still a bit skeptical of the use case, but... curious :)) The use case here is any search interface, as well as any page that contains links to database generated content. Both are incredibly common on the web. And, like Eshan points out, it works even when those navigate across origins. So for example: * Amazon's product search UI * Amazon's search result UI * Wikipedia's search UI * Wikipedia's search result UI * The search UI on NY Times * The search results UI on NY Times * Almost any product listing page * A contacts manager which uses "real" URLs rather than fragment-based URLs. I'm not sure why you are skeptical about that use case? So it would dramatically improve the situations when you could use prerendering. As it stands right now, you can't use prerendering at all for search UI. And you can only use it for search result UIs And to be clear, I'm not proposing making major changes or additions to the current spec. The only suggested changes is to add support for having a message channel, and that if the prerendered page calls replaceState that we match against the new URL rather than the URL that was originally loaded. And technically we could probably get away without the message channel since you can fake it using BroadcastChannel. But that's a bit error prone. / Jonas _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
