ES4 implementation process, teams, and meetings

Brendan Eich brendan at
Wed Feb 20 15:38:44 PST 2008

As Jeff has laid out, with helpful comments from Michael O'Brien,  
Lars, and Graydon, we are entering a phase of ES4 work where  
practical implementations will adopt and implement proposed parts of  
the new language. We need to do this to shake out proposals and gain  
critical feedback from implementors. We hope to get usability results  
from programmers too.

I agree with Michael's point about the RI being both alpha and omega  
among implementations, so RI work will continue. But practical  
implementations, besides enabling usability testing with real  
programmers, will help weed out potential problems to do with  
performance and security that the RI blissfully ignores.

As Graydon and Michael point out, the waterfall diagram (even if you  
put the RI earlier in the waterfall) does not reflect the wheels  
within wheels (waterwheels?) that must cycle at several levels of  
design, implementation, and even usability testing, in order to reach  
the ES4 spec we aspire to write. So take that waterfall diagram more  
as a management crutch ;-).

Finally, we absolutely aspire to build our existing testsuites up to  
cover as much of the new language as we can. Test-driven development  
is the only way to go (I speak from painful experience back in the  
Netscape days :-/).

The good news is that I believe we will have many ES4 implementations  
coming up in the next few months, working in parallel to improve the  
spec and RI. I know of at least these already under way:

* ES4 RI (SML + ES4 self-hosted)
* MbedThis (C + Java)
* Rhino (Java)
* SpiderMonkey (C)
* Tamarin+ESC (C++ + ES4 self-hosted)

If you are implementing any part of ES4 and want to join forces,  
please reply.

We aim to track progress using the infrastructure created by John Resig:

I believe that the shared spreadsheet URL given above is correct, but  
John can provide the latest information as well as grant write  
access. My hope is that implementors can edit the spreadsheet to  
record progress, providing verifiable builds and even open source for  
their implementations, as they go. Again I'll defer to John on this.

We propose to communicate among implementation teams using es4- 
discuss at, since (a) the list is not terribly high-traffic,  
(b) we aim to operate transparently, and (c) we believe most of you  
are interested at least as onlookers, if not as implementors. We can  
split lists if we run into a problem, but I don't foresee one.

To provide focused face-to-face time working together and building  
rapport among the principals, we are thinking of meeting roughly  
every month, with this strawman schedule:

March 17-21 - Mountain View, CA
April 14-18 - Newton, MA
May 12-16   - Vancouver, BC

This is very straw, so please don't flame it or it will ignite! But  
please do feel free to suggest alternative dates and locations. We  
hope to host anyone who has known reputation on this list and who  
wants to help, or who is already implementing. Jon Zeppieri has  
already helped with the RI, for example, and he's welcome to attend.

More details on the meetings as we firm things up.

Anxiety about commercial pre-release implementations gaining undue  
influence over the proposed standard naturally arises, and I wanted  
to address this briefly:

Speaking for Mozilla, we do not intend to throw trump cards during  
this new phase of proposed-ES4 development based on implementations.  
We've implemented extensions in the past, some of which are popular,  
others not so popular. We carry what we create until we can drop it,  
ideally in favor of a standardized form that's an actual improvement.  
This has gone on since Netscape days.

We try not to mess around with marginal extensions, so the few  
mistakes we're still carrying, e.g. the magic __proto__  
Object.prototype property, in both its read and write modes, reflect  
usability gaps in the language. For example, __proto__ is useful in  
the absence of ES4's Map to make an object be a "hash":

var obj = {__proto__:null, "key1":val1, ... "keyN":valN};

and that use-case should be better served by something like ES4's Map  
proposal. But as noted in the thread that started here, __proto__ is  
not proposed in any way for inclusion in ES4.

I bet the other implementators cited above would make a similar "no  
trump cards" pledge. The point of this proposed-ES4 implementation  
exercise is not to develop and deploy production code to the Web,  
rather to gain crucial feedback from implementors and programmers --  
a kind of "open source" or "permanent beta" approach to  
standardization, where interoperation among ES4 implementations can  
be demonstrated with tests and real code before the standard is  

Any questions? Feel free to reply-all.


More information about the Es4-discuss mailing list