On 08/14/2014 12:50 PM, Jonas Sicking wrote:
On Thu, Aug 14, 2014 at 12:37 PM, John Schoenick <jschoen...@mozilla.com> wrote:
On 08/14/2014 11:48 AM, Jonas Sicking wrote:
On Thu, Aug 14, 2014 at 10:28 AM, Gavin Sharp <ga...@gavinsharp.com>
wrote:
On Thu, Aug 14, 2014 at 8:32 AM, Ehsan Akhgari <ehsan.akhg...@gmail.com>
wrote:
In this context, an app that performs in-place updates, as opposed to
full
page reloads, when transitioning between different views. The views can
use
different JS, CSS, and so on. To achieve this, you have to build your
app
in a very particular way. In the case of bugzilla, that would involve a
substantial rewrite of the app... you can't just drop in a few
prerender
tags on the page and defer the rest to the browser.
The point of what Jonas and I are talking about is to avoid having to
rewrite the app.
[snip]
the app would need to implement a separate template page which knows
how to load the barebone CSS/JS/images and then fill in the rest based
on the information received from the controlling document.
The argument being made is that what you describe here would be a
similar amount of work as "rewriting the app" (to be a single-page
app), at least for the specific page involved.
The last part is key. It's dramatically easier to rewrite just the
bug-page to enable transitioning between individual bug pages. Rather
than to rewrite all of bugzilla to enable transitioning between
arbitrary pages in bugzilla.
It's easier yet to write a bug-template-page that can transition
itself to be an arbitrary bugpage than to enable transitioning between
bug pages.
Another point here is that with ServiceWorkers developers can get
significant speedups prerendering aside if they create such a template
page that can transition itself to be a bugpage.
Finally, my argument is that with a relatively small addition to the
platform we enable web developers to do this work if they want to. If
they don't then it's no extra work for them. If we *don't* make this
small addition to the platform then developers simply can't get any of
the speedups that prerendering offers in these cases.
I don't understand how a new API is required to do this. Why couldn't the
bugzilla search results page create a hidden document that has a
search-result template, and then handle the navigation to any of the result
links by filling it in and switching to it?
That is exactly the goal yes. The only thing we need to ensure is that
the prerendered template page is used. Currently the prerendered page
is only used if the URL in the <link rel=prerender href=x> matches the
URL that the user navigates to.
Yes, but, without any prerendering API at all bugzilla could do this
today, couldn't it? Create a template iframe, and then switch to it when
a user clicks a link it can handle, rather than letting the navigation
proceed. Why is an entire pre-rendering API with <link> tags and defined
events needed?
The only thing that is missing in that scenario is the ability to do
e.g. |window.navigateTo(existingiframe)| to save boilerplate around
swapping contents with your iframe, and handling pushState() yourself.
/ Jonas
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
