* Error on first call to a function, where the function contains what
would be an early error but for the supposed cost of early error analysis.
As I understand it, this goes back to "lazy parsing"
http://ariya.ofilabs.com/2012/07/lazy-parsing-in-javascript-engines.html
which, in turn, seems to want to support the found-in-practice
pattern of pre-loading not-yet-parsed code (eg, Google's code
in comments trick).
https://developers.google.com/speed/docs/best-practices/mobile
http://googlecode.blogspot.de/2009/09/gmail-for-mobile-html5-series-reducing.html
The reason why that pays off is that sites tend to include
lots of code that they usually do not use, or for which they
don't know beforehand whether it will be used. In some cases,
the balance seems to be between utilization of HTTP requests
versus parsing of JS code.
So there are use cases (though some of them are addressed by
newer element attributes), but there should be other, more direct,
ways to achieve the goal:
- coders don't include code that isn't used (doesn't seem to
work, but is still worth mentioning)
- the language or its environment include explicit means
for including code for possible (but not certain) use (similar
to <script defer>, one might consider a <script provide>
with parse-on-use semantics?)
In particular, I would like to know whether the bandwidth vs
parsing balance is the only motivation for lazy parsing. If yes,
then it is a web-specific issue, and the solution should not
affect server-side JS.
Because there is a hidden assumption behind the lazy parsing
idea, namely: the parsing -when it is triggered- *will not fail*.
If the parse correctness wasn't tested before serving the code,
there is no easy way of catching parse failure later. So there
would need to be a development mode and a serve mode?
If you give me a switch/pragma to force early parsing/checking,
then I will use it in my code (another job for "use strict"?). And
if you give us a way to provide code for parse-on-use, someone
on the web will find that useful. But without such switch, I don't
want my JS engine to do its few "early" checks later, perhaps, just
to address real use cases badly and implicitly.
Claus
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
