On Saturday, October 10, 2015 at 4:28:30 AM UTC-7, Mounir Lamouri wrote: > On Sat, 10 Oct 2015, at 02:02, zbranie...@mozilla.com wrote: > > On Friday, October 9, 2015 at 10:51:54 AM UTC-7, Mounir Lamouri wrote: > > > As far as speed feeling goes, they would win to show something as soon > > > as possible and handle any post-first paint loading themselves. > > > > That is unfortunately not consistent with my experience. People tend to > > perceive visible progressive as much slower than delayed first-paint in > > most scenarios. > > > > On top of that, it is perceived as a really_bad_ux. > > I don't think I agree but I don't mean to discuss Firefox OS product > decisions.
I don't think it's specific to Firefox OS. FOUC is a pretty well researched problem and we have spent a lot of time designing standards to limit the risk of them happening. The problem is that all we take into account when building anti-FOUC heuristics is HTML+CSS, while in the modern Web Apps, JS is part of the bootstrap process. Of course a lot of things still apply, and we still aim at minimizing the amount of JS necessary during bootstrap but the state of art is that we do need and we will need some minimal JS executed before firstPaint. One other reason it is necessary is that compared to web pages, there is no static content in HTML. Hell, there is no content at all. What is the value for the user to see Music index.html file [0] before JS kicks in? Literally zero. And if JS breaks? The app will not work. At all. While with web pages you can salvage and aim at displaying the content, even without JS, without CSS, because the goal is an article, with Web App, the goal is the "Play" button, the "New SMS" button etc. and those will not work without JS. So the first valuable thing to see is after HTML+JS provides chrome of the app and CSS provides styling. And it does not work well if this chrome flashes as it relayouts while JS finalizes it after firstPaint. As Vivien said, yeah, of course we want to show something as soon as possible, minimal useful Chrome and let above-the-fold content load later - that's precisely how we designed our responsive guidelines [1], and we're incentivizing developers to make bring minimal UI early. But that still requires JS. And currently we don't take it into account when discussing FOUCs, so platform races to paint while JS races to finish preparing chrome. The result is two fold - one are FOUCs if we are unsuccessful. The other, if we are successful, is bad code. That's where we get synchronous <script/> tag injected at the end of <body/> to prevent FOUCs. That's where we get "document.write", and synchronous XHRs. All there to win the race with Gecko. I see a huge value for the quality of the Web App Stack in removing the whole notion of this race. And Vivien's proposal seems to do just that with minimal invasion. zb. [0] https://github.com/mozilla-b2g/gaia/blob/master/apps/music/index.html [1]https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
