On 2/9/11 12:27 AM, Kyle Simpson wrote:
I can't speak definitively as to how the JavaScript engine is
implemented (and if the code is significantly different between mobile
and desktop).
In Gecko's case, it's identical (modulo the different JIT backends for
ARM and x86 and x86-64, of course).
But I can say that even if their code is substantially the
same, I could still see it quite plausible that the device itself locks
up (not the browser) if there's just simply too much going, taxing its
limited CPU power.
Yes, but that could just happen due to background tabs, workers, etc.
That's not something a page author can sanely control....
I can also see it quite plausible that mobile OS's are not as capable of
taking advantage of multi-threading
That's not the case for the OSes Gecko is targeting on mobile, at least.
It's not the case on iOS, last I checked. I can't speak to WP7 or
Symbian; I don't have any experience with them.
Regardless, considering such things is way outside the scope of anything
that's going to be useful for web developers in the near-term dealing
with these use-cases.
Yes, but so is the proposal here, no?
Even if you're right and the fault really lies with the implementor of
the JavaScript engine (or the OS), that's still a fruitless path for
this discussion to go down. No matter how good the mobile JavaScript
engine gets, I promise you sites will find a way to stuff too much
JavaScript down the pipe at the beginning of page-load in such a way as
to overload the device. That is a virtual certainty.
Yes, but what makes you think that those very same sites will make good
use of the functionality we're proposing here?
Now you may be right that authors who really want to screw up like
that will just do browser-sniffing hacks of various sorts and still
screw up. But it's not clear to me that we need to make the barrier to
shooting yourself in the foot lower as a result....
That sounds more like a question of degree (how much we should expose to
the developer, and how) than the principle (should we expose it).
Yes, of course. Degree is my only concern here.
In any case, I don't see much evidence that suggests that allowing an author to
opt-in to pausing the script processing between load and execute is
going to lead to authors killing their page's performance. At worst, if
the browser did defer parsing all the way until instructed to execute,
the browser simply would have missed out on a potential opportunity to
use some idle background time, yes, and the user will have to suffer a
little bit. That's not going to cause the world to come crashing down,
though.
Neither will the browser eagerly parsing. ;)
What's VERY important to note: (perhaps) the most critical part of
user-experience satisfaction in web page interaction is the *initial*
page-load experience.
Really? The pages I hate the most are the ones that make every single
damn action slow. I have had no real pageload issues (admittedly, on
"desktop") in a good long while, but pages that freeze up for a while
doing sync XHR or computing digits of pi or whatever when you just try
to use their menus are all over the place....
So if it's a tradeoff where I can get my page-load
to go much quicker on a mobile device (and get some useful content in
front of them quickly) in exchange for some lag later in the lifetime of
the page, that's a choice I (and many other devs) are likely to want to
make.
See, as a user that seems like the wrong tradeoff to me if done to the
degree I see people doing it.
Regardless of wanting freedom of implementation, no browser/engine
implementation should fight against/resist the efforts of a web author
to streamline initial page-load performance.
Perhaps they just have different goals? For example, completely
hypothetically, the browser may have a goal of never taking more than
50ms to respond to a user action. This is clearly a non-goal for web
authors, right? Should a browser be prohibited from pursuing that goal
even if it makes some particular sites somewhat slower to load initially
(which is a big "if", btw).
Presumably, if an author is taking the extraordinary steps to wire up
advanced functionality like deferred execution (especially negotiating
that with several scripts), they are doing so intentionally to improve
performance
My point is that they may or may not be improving performance in the
process, depending on implementation details. Unless they tested in the
exact browser that's running right now, it's hard to tell.
I see this all the time in JS: people time some script in one browser,
tweak it to be faster, and in the process often make it slower in other
browsers that have different JIT heuristics or different bottlenecks.
I think you're assuming a uniformity to browser implementations that's
simply not there.
and so if they ended up actually doing the reverse, and
killing their performance to an unacceptable level, they'd see that
quickly, and back-track.
You're assuming authors will test in multiple browsers. In my
experience, bad assumption...
It'd be silly and unlikely to think they'd go
to the extra trouble to actually worsen their performance compared to
before.
You're assuming malice; I'm just assuming insufficient testing (which is
pretty understandable, by the way; I wouldn't want to invest a few
thousand dollars in all the various mobile devices needed to run all the
different mobile browsers to test on my site) and overtuning for the
things you test. The latter is pretty likely.
Really, let's not always assume the worst about web authors.
I'm not. Really, I'm not. Above I'm even assuming way better than is
warranted based on my experience actually interacting with websites and
attempts by site authors to fix issues. I'm still led to the conclusion
that if we let authors overconstrain the UA here that's a bad idea.
If they do it wrongly and their users suffer, bad on them, not on the rest of
us.
If they do it wrongly _my_ users suffer. I'm in the business of
creating a user-agent here. Something that represents the user and is
supposed to provide the user with the best experience I can manage.
While I agree that authors who really want to screw up can always do it,
I think we should be careful to make screwing up _hard_, all else being
equal. Of course sometimes not all else is equal.
In other words, forbid the browser to start parsing the script, right?
How would you tell whether a browser implemented this as specified?
I could tell if the browser let me control execution pretty easily.
I'm talking about parsing here, not execution.
As for telling if the browser were deferring parsing to a useful degree,
I'm sure that the only way to actually determine that would be test a
site with a particularly long script file (length being a rough
approximation for parsing time), and see just when (between load and
execution) the big parsing delay (as observed previously) was happening.
Assuming the browser does the parsing on the main thread, yes? What if
it doesn't?
OK. I definitely agree that better user control over when script
_executes_ is a good idea. Sounds like we're on the same page there.
I think that what should happen is, if a web author chooses to defer the
execution of a script (easily detectable if it's not ready for execution
when loading finishes), the browser should get the strong HINT that
maybe the parsing should be put off until later (and perhaps until
execution time).
I can live with that.
Do you see how what I'm asking for is not direct forcible control over
parsing but some way to strongly encourage the browser to defer both
parsing and execution until later, when *I* say I want it to?
That wasn't what the initial proposal sounded like, but ok. If that's
what you're looking for, that sounds fine.
-Boris
