ES4 implementation process, teams, and meetings

Maciej Stachowiak mjs at
Thu Feb 21 08:30:10 PST 2008

On Feb 21, 2008, at 8:14 AM, Geoffrey Garen wrote:

> Is there a published specification that all these implementors will be
> using?

To expand a bit on Geoff's comment:

I'd like Apple and the WebKit project to get involved with ES4  
implementation. But right now, as far as I can tell, there isn't a  
written record for any of ES4's features that I could point an  
engineer to and say "implement this". The proposals on the wiki are  
way out of date, it's not easy to find what trac tickets modified  
them, and there seem to be commonly understood planned changes that  
aren't even reflected in trac.

Before attempting interoperable implementations of particular  
features, I think we need at minimum a form of the proposal for that  
feature that is complete and up to date. It doesn't have to be formal  
specification quality, but there has to be something accurate.

Now, it may be that by telling someone to reverse engineer another  
implementation, or ask the ES4 crowd about every detail of how a  
feature should be implemented, someone could succeed in implementing.  
But it seems to me that this undermines the unstated assumption of  
interoperable *independent* implementations.

In contrast, with CSS, Web API or HTML WG specifications, I can point  
engineers to a spec that is more or less accurate for a given feature  
and they only have to ask questions about the few missing details. I  
would raise HTML5 as a particularly laudable example because it  
achieves this even though much implementation work is happening in  
parallel with writing the spec.

I think we should strive to achieve the same standard for ES4. At  
feature granularity, someone should first write an up to date accurate  
document and implementations should be done against that, not against  
some separate shared understanding of the feature.


> Thanks,
> Geoff
> 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
> _______________________________________________
> Es4-discuss mailing list
> Es4-discuss at

More information about the Es4-discuss mailing list