ES4 implementation process, teams, and meetings

Geoffrey Garen ggaren at
Thu Feb 21 08:14:15 PST 2008

Is there a published specification that all these implementors will be  


On Feb 20, 2008, at 3:38 PM, Brendan Eich wrote:

> 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
> finalized.
> Any questions? Feel free to reply-all.
> /be
> _______________________________________________
> Es4-discuss mailing list
> Es4-discuss at

More information about the Es4-discuss mailing list