On 2/9/11 10:37 AM, Kyle Simpson wrote:
I think you're assuming a uniformity to browser implementations that's
simply not there.
No, I'm relying on the growing trend of more and more web authors being:
1) aware of performance issues, especially initial page-load performance
2) able to use more tools to measure these issues, and test them across
a broader range of user-agents
3) able to leverage more functionality that the spec and browsers give
to them, to have better optimization of their pages
Again, you're assuming that the "optimization" that needs to happen is
that same for all browsers....
Assuming the browser does the parsing on the main thread, yes? What if
it doesn't?
Regardless of what thread the processing is on, if the parsing happens
during the critical few moments of page-load, and the device's
CPU/hardware is overwhelmed, it's going to be obvious that there's a
slowdown or freeze.
If the hardware is overwhelmed. On the other hand, if it's a multicore
chip (which is what mobile hardware is shipping with nowadays) and the
page-load is gated on one core, there's no reason to not be parsing on
another core...
The major problem in the mobile-performance part of the use-case is
around parsing. Noone is suggesting here that the web author should have
a .parse() function where they deterministically control it and handcuff
the browser.
OK, good.
What we're suggesting is that we be able to directly
control execution, and in so doing, make an indirect hint to the browser
that it should also strongly consider deferring the parsing.
That sounds fine to me.
-Boris
