Implementor Question

[Brendan Eich]

On Oct 29, 2007, at 10:56 AM, Yehuda Katz wrote:

> Is there any reason browser vendors couldn't continue to ship the  
> old ES3 interpreter, and make it available for <script type="text/ 
> javascript"> and make ES4 available for <script type="application/ 
> javascript"> or <script type="application/es4">.

Browsers not bundled with operating systems, therefore downloaded  
voluntarily by users, cannot afford two engines. Even more to the  
point: browsers targeting phones and other small devices cannot  
afford two engines. And there is no need for two engines, since ES4  
is a superset of ES3.

The overview discusses this a bit; so do my posts at the LtU thread.  
See in particular:

http://lambda-the-ultimate.org/node/2504#comment-37607

Note the cyclic leak problem, a subset of the distributed GC problem.

> That way, ES4 would not be capable of breaking anything, because  
> the same old ES3 interpreter would be running old code.

ES4 as implemented won't break any ES3 code, if we do our jobs -- and  
we are, in full view of everyone here (see http://bugs.ecmascript.org/).

The nice thing about the assertion that ES4 will break the web is  
that it is falsifiable within the next year. But it's also nonsense  
based on recent history, and on first principles.

The general "break the web" argument against JS evolution is old as  
the hills. We've been evolving the language in Mozilla for years,  
feeding results into Editions 2-4, while also engineering more IE  
compatibility in order to help Firefox gain market share. Obviously  
something is working.

The "break the web" sky did not fall, and it won't fall on account of  
ES4. The best thing Microsoft could hope for would be other browsers  
committing suicide by breaking the web. We at Mozilla are anything  
but suicidal.

But again, two engines don't cut it, for footprint and memory  
reasons. And two engines are intentionally unnecessary by the design  
of ES4.

/be