What I think about ES4.


Dean Edwards asked me
in a comment on the IEBlog what I personally thought of the ES4 proposal. (‘You say
that “Microsoft” think that the web is best served by the creation of
a new language. Your name is at the bottom of this article. What do *you*
think?’
– I’ll let the FUD comment bounce off.  Damned if we do, damned if
we don’t say anything.)  Consider the rest of this post to be only my
opinion, because I haven’t even run it by the other people on the team.

In a way, I’d say it’s somewhat immaterial
what I personally think, because I am not and have never claimed to be a
programming languages expert. Yes, I used to be a developer; but just because I
know how to drive a car doesn’t qualify me to design one.

On the other hand, I DO know what
principles I would place on a new car, and how I would prioritize them (off the
top of my head for my primary car: safety, emissions, fuel economy, handling, passenger comfort,
cargo space, acceleration) to a qualified car designer.  I’ve spent a lot of time
over the past year with a few people at Microsoft who DO know a thing or two
about language design, including those who participate on the ECMA TG-1
committee.

*I* think there are two approachs to take to moving
the state of “programming language for the web” forward.  One of
them is to evolve Javascript in place (pardon me for collapsing ECMAScript,
JavaScript, JScript et al together; it’s just easier, and one cup of coffee is
not enough for me to be prepared to play semantic games).  That requires
one set of principles – ensuring stability of the ecosystem as it is today
should take priority, furthering the interoperability of implementations (which
is a problem today), enhancing performance and security, and then cool new
language functionality.  Those are the priorities I think should be placed
on evolving Javascript.

As I understand it, on the other hand, the ES4
proposal introduces a lot of new language functionality that essentially
changes the character of the language.  I don’t personally have a problem
with that language as a language – but I think grafting that
different-in-character-language together with a compatible-and-performant
implementation of the Javascript of today is both super-hard (if even possible)
to get right, and is ignoring the bigger problems of language-for-web, namely
interoperating with all the script that is out there.  (I’d also take on
other challenges first if I were redesigning Javascript – e.g. domain-aware
security as a language tenet.  That’s Monday-morning quarterbacking the
ES4 design as a new language proposal though.)

My point is that it’s a fallacy to think that you’re evolving
Javascript if your expectation is that the scripts will have a different type
param, and be handled by a separate runtime (i.e. the ScreamingMonkey approach).  That doesn’t
seem like it will have good interop to me, at least not in a world where
mashups and separate code components from disparate places (all of which are
some variant of ES3 today) are the norm. 

Sadly, this seems to be turning into an
“ES4: yes or no” battle.  That’s unfortunate, because I don’t
think anyone should settle into the trenches, and I don’t think the other Microsoft guys ever intended to say “everything about ES4 is bad”.  It’s been pointed out that we haven’t made an alternate proposal – well, I’d kinda hoped we could work it out together.  “Open to input”
should be the way of the web, should it not?  I think it’s a shame that
dissenting opinion has been hidden from view, and not publicized; certainly, I
think the Microsoft response hasn’t been very audible, but that’s partly
because we’ve been trying to figure out if it’s just us – but of course, us
trying to understand what other people think of the proposal in detail has also
generated some apparent conspiracy-theorism.  I also think it’s a shame
that the response to any dissent has equated to shouting the dissenters
down.  The string of blog posts over the last week, and the immediate and
somewhat incendiary comments from ES4 proponents, has been a good
example of that.

Hey, everyone can have an opinion.

Comments (101)

  1. Hi Chris,

    I’ve merely lurked on the ES4-discuss list for a year or so, and to be honest a lot of the technical debate is beyond my comprehension. I’ll comment anyway..

    Nice list of priorities!

    * ensuring stability of the ecosystem as it is today

    Check – ES4 script engines should be nearly 100% backwards compatible with the ES3 spec, and some of the deviations are due to compatibility fixes that un-breaks the web 🙂

    * furthering the interoperability of implementations

    Check. The ES4-people have done their best with the mentioned compat fixes in the spec, and a reference implementation. I expect there will be some turbulence ahead while browsers get the new bits in place, and I hope the working group will also create a test suite for their spec. That said, implementing the spec should many many browsers MORE compliant with existing content, and if early adopters of ES4 find that the *new* functionality isn’t cross-browser compatible yet then, tough, but many UA vendors release upgrades quite frequently these days.. 😉

    * enhancing performance and security

    See Brendan Eich discuss how certain ES4 features help security-wise:

    https://mail.mozilla.org/pipermail/es4-discuss/2007-October/001415.html (please excuse him for any anti-“anit-ES4-people” comments that might occur..)

    On performance we’ll have to wait and see but when you consider how some people in the working group have *written* ES3 engines for embedded systems I think performance will be taken care of.

    * and then cool new language functionality

    Cool is subjective. I don’t really know yet how it will feel to write ES4 code, I didn’t try so far – but I look forward to it.

  2. Rick says:

    Glad to see you posting again!

    I agree that there is much to discuss for ES4, and whether it is the right thing to do, and to what extent.

    I think what causes such a ruckus, was that it was posted to the IE Blog.  Which historically (at least for the last 12 months), has not addressed any of the concerns of the readers of the blog.

    As mentioned in many of the comments, the lack of discussion as to what is, or isn’t going on with IE development these days *scares* the living daylights out of us, when a post like this is made.

    It gets read as: "We’ve been really quiet, because we’re actually planning to go in a different direction than the standards approach that you’re all hoping we will"

    I think (as does everyone else I’ve read or talked to) that the IE Blog is in desperate need of a "Where are we" post.

    The silence does a huge disservice to everyone reading it.  We are all working towards a common goal, building great software… but when the "core" platform that we are building our software on top of, goes into "Silent Running", it is EXTREMELY concerting.

    Please tell whomever on the team is doing the next post, to state where things are at in terms of development.

  3. Jon Breen says:

    Shouldn’t your points be proved before preparing a new language? Have you not got the resources at MS to hook up the ES4 refererence implementation and prove these points? Or have you and you’re not sharing. Would Microsoft be kind enough to share their findings if they have? There has been no mention of this in either of your posts; would it be prudent to say you are basing this on ‘feeling’ rather than ‘fact’?

  4. Garry Trinder says:

    @Rick  thanks, that’s a good point.

    @JonBreen how would you suggest "hook[ing] up the ES4 reference implementation and prov[ing] these points?"  The ES4 reference implementation is very slow and incomplete.  This is a principles and ecosystem issue; as in, "we believe different principles should drive the language design" and "we believe this will not evolve well in the ecosystem, and will be divisive."

    This is not a "feeling" – if you like, consider it an "opinion", of merit in principle on par with the other "opinions" of principles that designed the current ES4 proposal.

  5. thacker says:

    Wilson–

    I back your go slow approach on ES4.  The geek technology tail spends too much time trying to wag the Internet communication dog. [The preceding statement is overly simplified but will leave it at that.]

  6. Chris Double says:

    "It’s been pointed out that we haven’t made an alternate proposal – well, I’d kinda hoped we could work it out together.  "Open to input" should be the way of the web, should it not?"

    My understanding is that the proponents of the es4 draft are more than happy to work things out in the open. Looking through the es4 discussion and the blogs it seems that you’re not being ‘shouted down’. Rather those not happy about es4 have been quiet about the technical reasons and haven’t started a discussion on things to change, etc. Instead they’ve raised vague comments in open forums about not liking the new proposal.

    Please get your people involved in the es4 discussion list and help resolve what they see as issues in the proposal. In the open. Like you suggest.

  7. Alex Russell says:

    Hey Chris,

    I’m, again, not going to weigh in pro/con on ES4 (it’s not productive and far too charged right now), but I do want to take up where you’re leaving off.

    You mention that "ensuring stability of the ecosystem as it is today should take priority". I assume that means that Microsoft’s "ES 3.1" proposal is the preferred path forward for IE, which arguing from your point of view seems all well and good. What’s not well or good is that fundamental concerns about the capability and future JScript remain wholly unanswered. No matter what you think about ES4, the lack of communication and, quite frankly, effort on the JScript 5.x front leave a sour taste in the mouth of web developers and framework authors.

    Instead of fixing JScript 5.x, the JScript team (or their doppelgängers in other teams) have produced new fewer than two from-scratch, backwards compatible re-implementations of ES3. JScript.NET (a hacky, one-off language that never the less supports many critical, missing features from JScript 5.x) and JScript for the DLR simply cannot share DNA with the WSH version of JScript. Given the obvious effort being poured into this language by Microsoft, why won’t the JScript team *publicly and openly* declare their plans WRT the WSH JScript interpreter?

    Any improvements need to include Mozilla’s "JavaScript 1.6" and "JavaScript 1.7" extensions as well as performance and critical bug fixes. That’s not a lot to ask. Particularly when compared with writing an entirely new engine (or two).

    As the monopoly incumbent Microsoft owes it to the community which is wholly under its thumb to provide clear, timely, and accurate guidance with regards to its intentions or a full explanation of why it will not commit to addressing these show-stopping issues on any version of JScript for WSH.

    Regards

  8. Garry Trinder says:

    @Alex Russell – our JScript team works on JScript.dll, not JScript.NET or the JScript for the DLR.  You should expect their major body of work will appear in the next version of Internet Explorer.

  9. Lionel says:

    Chris,

    First, thanks for posting again on your blog and the IE blog!  This is always welcome.

    Would it not be possible to handle ES4 as a completely new language?  Maybe the implementation would have a different performance signature than old JScript, but it could be usable and match closely enough what is implemented by other browsers to get good interoperability (even if it is not backward compatible enough)?  In this case, what about switching the javascript engine depending on the same opt-in you plan to use for the layout engine?

    Would this be workable, or am I missing part of the difficulties you see?

  10. Thanks for this interesting post.  Disclaimer: I work for Mozilla.

    >>>"*I* think there are two approachs to take to moving the state of "programming language for the web" forward.  One of them is to evolve Javascript in place[…].  That requires one set of principles – ensuring stability of the ecosystem as it is today should take priority, furthering the interoperability of implementations (which is a problem today), enhancing performance and security, and then cool new language functionality.  Those are the priorities I think should be placed on evolving Javascript."

    This describes exactly what the ES4 committee has actually done.

    Stability:  Full backward-compatibility was the one overriding goal all along.  It would have been self-destructive for Mozilla and Opera to develop an ES4 standard that would break existing Web pages or disrupt the ecosystem.  Web compatibility is our bread and butter.

    Maybe you meant something a little different by "stability", though.  Please feel free to elaborate.

    Improving interoperability:  Not to put too fine a point on it, but the major obstacle to interoperability at the language level is IE’s poor conformance to the existing ES3 spec, which was ratified 7 years ago.  There’s only so much ES4 can do in this department. Still, it tries.  The committee proposes several clarifications to obscure details on which ES3 is silent or vague.  (This is extremely minor stuff though.  From what I hear, the changes are mainly to clarify what the standard means, and standardize the browsers’ existing practice, including IE behavior where appropriate.)

    Performance and security:  ES4’s optional static typing is a major performance feature.  I also think static-typed code has fewer bugs and is harder to abuse–so it’s a security feature, too.  The same goes for ES4 fixtures.

    Cool new features:  I don’t know about "cool", or even "new", but ES4 certainly has *useful* features, *important* features if you want to write real applications for the Web.  Making the language better for "programming in the large" was a design goal.  So ES4 has classes, interfaces, packages, iterators, generics, and (at last) real data structures.  (All optional, available if you want to use them–existing ES3 code will continue to work.)

    >>> "My point is that it’s a fallacy to think that you’re evolving Javascript if your expectation is that the scripts will have a different type param, and be handled by a separate runtime (i.e. the ScreamingMonkey approach).  That doesn’t seem like it will have good interop to me[…]"

    Come on, man, this is bogus–none of that is required, unless Microsoft refuses to implement ES4.

  11. Jonathan Watt says:

    There seem to be two parts to compatibility. First there’s the compatibility of ES4 with ES3. Second, there’s the compatibility of the ES4 _additions_ in various ECMAScript engines. The former type of compatibility is vital, as I think everyone has agreed. This should not be confused with the latter type of compatibility though. It is expected, and for a limited period of time, acceptable, that the ES4 _additions_ to ECMAScript engines would have some incompatibilities while things stabalize. You would expect implementations to be more compatible than incompatible though, so don’t throw the baby out with the bath water. To argue against ES4 with "the new additions could have incompatibilities between different implementations" would be to argue against producing standards and independant implementations, period, so I assume you’re worried about the former type.

    I’m glad to hear you feel ensuring stability and backwards compatibility should be a priority. I’m not so clear why you think the path being taken by the TG-1 committee isn’t that path though. Everyone on the es4-discuss mailing list seems to have agreed backwards compatibility is vital. Having minority browser share, the other TG-1 participants also have a much better track record of striving for compatibility and standards compliance than Internet Explorer.

    Furthermore, the reference implementation that’s taking shape, while imature, and thus, yes, currently buggy, is a great idea. It will give scripters the chance to throw their existing scripts at it as well as test out the new ES4 features. Success here is, as I understand it, mandatory to proceeding to standardization. I also know for a fact that Mozilla has JavaScript testsuites that have been building up for years (almost a decade I’d think) that they can be throw at it – I’m sure other implementators have the same.

    I’m not worried that the reference implementation might be slow. For it, correctness is what matters. I’m content that _real_ implementations can stay at least as fast as they currently are given the fact that other TG-1 members couldn’t possibly consider releasing slower, ES4 supporting engines, since Web developers/customers wouldn’t tolerate slowdown in minority browsers, and members like Mozilla (who are increasingly driving for better browser performance, with a new mobile effort) use ECMAScript to build their user interface. The language experts there have up to 12 years experience of implementing ECMAScript, and they can’t affort to screw that aspect up.

    Regarding "the ScreamingMonkey approach", it’s a last resort proposal to provide plugin ES4 support in IE if you guys decide not to implement it, right? Not sure how that can be an argument against you implementing it. 🙁

    Finally, I haven’t seen a "yes or no" battle or anyone "shouting dissenters down". I have seen people shouting at detractors for repeatedly making vague statements instead of providing technical arguments. That’s a different thing though, and to be honest I’ve had a certain amount of sympathy with the "shouters". It’s vital that any real problems with the proposal be ousted – anyone finding genuine problems needs to provide detail rather than appearing to spread FUD. Expressing worries is fine up to a point, but ultimately it has to be backed up or things could move forward with issues unresolved.

    Thanks for your post. It’s helpful in that it lays out your current thoughts and feelings on ES4, still, feelings and fears are not reasoned point by point analysis. I haven’t formed strong opinions on the ES4 proposal yet. I too certainly hope that everyone will keep an open mind, examine the proposal in detail, come to their own conclusions on each of the new features, and let es4-discuss know. That’s vital. Let’s out the issues! To that end I’d love to hear from those on your team who you do consider to be the language experts. I’ll form my own independant opinions, but I’d love to hear your guys’. It’s more important to collect first hand detail from the detractors that the proponents I think. Let’s hear the details please! 🙂

  12. Allen Wirfs-Brock says:

    @Alex Russell and Chris,

    I’m jumping in here because you mentioned “3.1” and Chris doesn’t have the same level ECMA TC39-TG1 involvement that I do so perhaps I can better clarify some things.

    At the beginning of this year I was asked to essentially audit Microsoft’s positioning and level of participation in the ongoing ECMAScript standardization processes.  Out of this emerged a set of concerns about the ES4 effort’s potential for negative impacts upon the entire web ecosystem.  Chris in his original post here essentially summarized those concerns.  At the March TC39-TG1 meeting we floated a proposal to split TG1 into two distinct efforts, one to incrementally evolve ES3 while maintaining strict backwards compatibility and one to work on a substantially new language (essentially the current ES4 with relaxed backwards compatibility constraints).  I believe  that in this proposal we suggested that JS 1.7 functionality would be a reasonable starting point for the first effort.   This overall proposal was not particularly well received  by the TG1 participants who were already committed to the current ES4 direction.  However, there was agreement that interested participants (mostly Microsoft and Yahoo!) could work on a maintenance proposal for ES3.  At the meeting this effort was given the informal “ES3.1” designation. The so called “ES3.1 proposal” was a first draft that emerged over the next couple months.  It was intended to simply be a starting point for discussions.

    Since then, we have continued to work in this direction.  The “JScript Deviations” document that started this discussion was created as an input into the process.  We think that a detailed understanding of the current level of conformance by various implementation is a necessary precursor to any major standards revision.   Our overall progress has been slower than I might have hoped for.  There are not a lot of organizations that actually participate in TC39-TG1, I believe that up to this month of this year there have been only 5 organizations that have been consistently attending meetings. Other than Microsoft and Yahoo! the other all seem firmly committed to the development of ES4 and have shown little interest in actively participating in “ES3.1” or any effort not directly related to the development of “ES4”. (some may argue with that last statement, but it’s my real perception)

    This is just to provide a little background and to make it clear that Microsoft is and has been open to consider standardization of ES3 extensions comparable in scope to JS 1.7

    Allen Wirfs-Brock

    Microsoft

  13. Alex Russell says:

    @Jason:

    You suggest that static typing is a "performance feature". It’s not. If you ask Brendan he’ll be the first to tell you that typing in ES4 is about safety and structure and not speed. Major speed gains are possible w/ ES3, but they require a different approach WRT interpreters.

    As for the proposed ES3 back-compat changes in ES4, some are trivial, some aren’t as trivial, but all are useful.

    As for ES4’s useful features, I’m afraid it’s not "done" yet. Interfaces (as written) aren’t useful for Open Web code, and keywords like "final" are probably a mistake.

    Regards

  14. JonBreen says:

    🙂 Someone @ MS asking me how to do something technical 🙂

  15. @Alex:

    Static typing will also allow compiler based unboxing, will it not? That would lead to increased performance along with safety.

  16. Justin Meyer says:

    Can someone give me one ‘thing’ that can’t be done in ES3 that can in ES4?  I’m not talking about making things easier.  I’m talking about actually producing something different, like XMLHTTP gave us (of course, this could be done with IFrames).

    Until then, I think the millions of ‘average’ programmers would rather just have the bugs worked out.

  17. Luke Gedeon says:

    Chris,

    I feel for you man! Joining a conversation late is painful. I have done the same thing – walking into a meeting an hour late. I would ask a question and they would say, "we just talked about that." If I had anything to add it was too late. If you ask 2 or 3 questions like that they tell you to shut-up and read the minutes later.

    You do have one advantage though, you can read through most of the conversation so far and catch up. It is just going to take a serious commitment of time.

    Once you are current you still have time to make specific recommendations, but it is, unfortunately, too late to change the process. Sometimes you have to play the cards you are dealt or change games. As some one that is stuck in the middle (developing for multiple browsers on multiple platforms) I really hope that you will take the time to work with this rather difficult process and even more difficult people.

    I realize this is not going to be pleasant but please, for the sake of web developers for years to come, please work with-in the existing structure trying to make it better when possible and honoring the decisions made.

  18. "As I understand it, on the other hand, the ES4 proposal introduces a lot of new language functionality that essentially changes the character of the language.  I don’t personally have a problem with that language as a language – but I think grafting that different-in-character-language together with a compatible-and-performant implementation of the Javascript of today is both super-hard (if even possible) to get right, and is ignoring the bigger problems of language-for-web, namely interoperating with all the script that is out there."

    Though I disagree with your opinion, I take no offense here. I must admit it’s frustrating, however, to hear things like this now that the ES4 spec is close to final. These are the sorts of things that needed to be said publicly *eighteen months ago*.

    The tone, latency, and substance of communicating with Microsoft seem to be markedly different compared to communicating with Mozilla, Apple, or Opera. You’re the most visible member of the IE team, so you’re treated as the point person, but most of the work in this area falls on the JScript team. Yet Aaron Gustafson met with the IE team to deliver the wish list for IE.next.

    It feels like the subtext of these discussions is wholly subjective — such that both parties walk away from the table largely satisfied, but with very different perceptions of what they’ve just agreed to. I’d give up half the stuff on my wish list if only we could get all the major players in the browser industry on the same damned page.

  19. @Alex:

    It’s a relief to talk about actual technical issues in the spec.  These are good comments.  Bring them over to the es4-discuss mailing list, *please*.

    You’re totally right about how Brendan Eich sees static typing, of course–untyped code could and should run just as fast.  Myself… well, let’s just say I have a lot to learn in this area.

    I think I see where you’re coming from on "final".  But what’s wrong with "interface"?

  20. Neil Mix says:

    Chris,

    According to TG1 meeting notes from June/July 2006, Microsoft was planning on implementing ES4 post IE7.  From there until March of 2007, it looks to me like Microsoft was fully complicit with the ongoing design.

    see:

    http://wiki.ecmascript.org/doku.php?id=meetings:minutes_jun_28_2006

    http://wiki.ecmascript.org/doku.php?id=meetings:minutes_jul_27_2006

    Perhaps you could address why Microsoft’s stance has changed in specific, technical details?  Clearly ES4 was acceptable and appealing at one point.  Why the change of heart?  And why weren’t reservations about ES4 brough to TG1 sooner?

    With regard to your "open to input" comment (grrr…that’s what TG1 and the ES4 mailing list are for, my friend), here’s some specific, narrowly defined input for you:  Stick to your original plan!  Accept ES4 and implement it!  It’s a well-engineered proposal.  Its adoption would further each of the goals you mention (stability, interoperability, security, features). You’ll be doing yourself and your customers a big disservice by not adopting it.  That’s my opinion.

  21. Hi Chris.

    > Sadly, this seems to be turning into an "ES4: yes or no" battle.  

    Lets look at use cases:

    I want to define extendable classes in clear, concise form, without having to sacrifice readability and performance by using tricks.

    I want to load external files without having to resort to hackery.

    I want static typed variable.

    I want modifiers, such as private and final, so that I can hide internal properties and declare things to be immutable. immutability is powerful.

    I want to be able to typecheck. typeof doesn’t do this. instanceof doesn’t work across frames.

    I want data structures like SortedSet and Map<T,T>. for-in is broken in ie and even if it weren’t, enumerability adds extra responsibility to Object that is not needed in most cases.

    I want type annotations like Map<T,T>.

    Look at how libraries attempt to deal with these issues with the current language features, look how these problems are addressed in other languages, then look at what ES could be doing and how ES4 addresses these issues.

    "[ES4 is] ignoring the bigger problems of language-for-web, namely interoperating with all the script that is out there"

    Are you saying the ES4 causes interoperability issues? What specifically is the problem? If this is a real issue, then please provide a scenario and post this on the ES4 discuss list.

    If you’re specific, I’m sure you’ll get an intelligent response.

    If Microsoft wants to release a patch of the JScript bugs in IE 7.1, and support Array Extras and other newer features, I would not have a problem with that.

    I do have a problem with Microsoft haltipg progress. I don’t want to wait for another long IE release cycle to complete. Lets say IE8 comes out and does not support ES4 and fixes JScript engine instead. Then we get IE9 around 2011. By 2014 there will be enough IE9 users to safely write ES4 code.

    Web devs still can’t use position: fixed and expect it to work consistently because the number of IE6 users is still high.

    Fulfilling use cases is important.

  22. Garry Trinder says:

    @Garrett Smith: I’m not sure what to make of your use cases, as they seem to be feature requests rather than principles for scoping a new language, and as I already said, I’m not a language designer.

    Yes, in my opinion the current ES4 proposal (and plan for deployment) causes interoperability issues on the web, as the mashup development pattern would require interoperation of current ES3 scripts as well as supposed new ES4 scripts.  With the ScreamingMonkey plan, this clearly won’t work well – as they’ll be run in different runtimes – but even without it I expressed my skepticism that ES3 scripts won’t suffer if run through an ES4 engine.

    If you wish to discuss that on the ES4 list, be my guest.  I never suggested halting progress; I did suggest some caution to make sure the end result, as it would actually be deployed, is actually progress for the web at large.

    I’m not sure what you would have us do differently WRT deployment; I’m certainly interested in moving users from IE6 to IE7 (and future versions) as quickly as possible.  What exactly have you heard from other vendors (other than the Mozilla/Adobe agreement) about their support for ES4?

  23. Rowan says:

    Crap! IE6 market share increased during October, with IE7 market share dropping by a similar amount. That’s the first time IE6 usage has increased since last year.

    http://marketshare.hitslink.com/report.aspx?qprid=7

  24. Mike Shaver says:

    _What_ interoperability issues will it cause on the web, specifically? That interoperation of ES3 and ES4 script has been the exact motivation for a huge part of the ES4 design work; if you see bugs in the design that will lead to interop or compatibility pain, please PLEASE elaborate on them on the es4-discuss list, where people are standing by to work through and resolve them.  (Or raise them in detail in the TG1 calls or meetings, if you’d prefer, though I think you’ll find that the es4-discuss crowd will give you quite a satisfactory response, and likely much faster.)

    Thanks,

    Mike

  25. Garry Trinder says:

    @Mike Shaver, see above.

  26. Ric Johnson says:

    Chris,

    As a .Net developer, I was excited to learn that Microsoft was joining the <a href="http://OpenAjax .Com">Alliance</a>, but now it seems that your message is taking a step back from that.  Is that a separate department? Or did Microsoft just join in order to try to control it?

  27. Ric Johnson says:

    Chris,

    As a .Net developer, I was excited to learn that Microsoft was joining the

    <a href="http://OpenAjax.Com">Alliance</a&gt;, but now it seems that your message is taking a step back from that.  Is that a separate department? Or did Microsoft just join in order to try to control it?

  28. Mike Shaver says:

    Chris: I’m not sure what you meant by "see above"; it was in response to your preceding comment about incompatibilities that I wrote my comment, as I very much want to understand what specific incompatibilities you’re concerned about, such that the design can be improved as needed to repair them.

  29. Backup Brain says:

    There’s been some rumblings lately in the usual quarters about the current proposal for ECMAScript 4th Edition, aka "ES4." For what it’s worth, here’s my two cents. When I first heard about what Mozilla calls JavaScript 2.0, it was in…

  30. Garry Trinder says:

    @Mike Shaver – "as the mashup development pattern would require interoperation of current ES3 scripts as well as supposed new ES4 scripts.  With the ScreamingMonkey plan, this clearly won’t work well – as they’ll be run in different runtimes – but even without it I expressed my skepticism that ES3 scripts won’t suffer if run through an ES4 engine."

  31. Dean says:

    Brendan Eich is correct here.  He is dedicated to an open, standards based web experience… an ideology well served.  You Mr. Wilson, have to balance serving Microsoft’s best interests with the interests of an open, standards based web.  As a result, you’re decisions and opinions generally skew towards the proprietary… something that is not compatible with the philosophies and practices on which the web was built.

  32. Robert Sayre says:

    Jason already pointed out that the "mashup development pattern" problem is an artifact of Microsoft’s refusal to implement ES4. But there probably won’t be a problem anyway, since the cornerstone of such a design (which is insecure in all ES3 implementations, including IE7) is isolated channels a la Google Gears. Since the messages should be self-describing and resemble JSON for security reasons, passing them among different script runtimes is not a dealbreaker. On this point, Doug Crockford is completely right.

    "I expressed my skepticism that ES3 scripts won’t suffer if run through an ES4 engine."

    So unsubstantiated FUD, basically? I’ll take this opportunity to point out that ES3 scripts do suffer when run through Microsoft’s badly buggy ES3 engine. For example, see the GMail team’s experience with the incompetent JScript garbage collector.

    http://blog.youngpup.net/2007/10/new-gmail-infrastructure-launches.html

  33. Garry Trinder says:

    @Dean: I, too, though you obviously don’t realize it, am dedicated to an open, standards based web experience.  I am not dedicated to any particular ideology, mind you; I just think they make good economic sense.

    Stating that my personal decisions and opinions skew toward the proprietary is so laughable that I needed to put down my coffee.  You clearly don’t know me, and are painting me personally with a stereotypic Microsoft brush.  I’m not upset, you understand; more amused.  Perhaps you’d like to talk to any of my current or past coworkers or managers, and ask them if they think I skew toward the proprietary.

    @Robert Sayre – I failed to see where Jason pointed out ANY such thing – can you point me to this?  The mashup development pattern problem is not an artifact of Microsoft’s supposed "refusal to implement ES4" – it is an artifact of using a different MIME type and the approach that says plugging in a different runtime engine will be workable.  We didn’t raise that solution.

    Please don’t refer to my personal opinions as unsubstantiated FUD.  I was asked for my personal opinion; I gave it.  I am open to both new input and being proved wrong; the same does not apparently go for everyone participating in this "discussion".

  34. Robert Sayre says:

    Oh, you’re entitled to your opinion. My opinion is that your opinion sounds like FUD. 🙂

    Jason wrote "Come on, man, this is bogus–none of that is required, unless Microsoft refuses to implement ES4."

    But like I said, I don’t see this as a barrier to secure mashups anyway. Douglas Crockford’s CSP ideas are right on the money, I think. If you want to collaborate on *those ideas*, I think that would be great, just totally orthogonal to the ES4 effort.

    You know, that would be in everyone’s interest too. Secure message passing could take place between JS from different hosts, between JS and Flash, JS and Silverlight, and Flash and Silverlight… you get the idea. But this is an addition to the standard library, and basically unrelated to other ES4 matters.

  35. Michael says:

    To Chris’s defense, I don’t think he stated anywhere that Microsoft wasn’t going to implement ES4.  Am I wrong on this?

  36. Anonymous says:

    Shouldn’t MS be more worried about supporting the current ES standard?

  37. Chris says:

    What’s FUD?

  38. Phillip says:

    JavaScript is OLD and we are starting to use it in ways that were unanticipated. I have written a LOT of JavaScript code but I am not afraid of dumping it for something better.

    Some people need to give Microsoft more credit for wanting to innovate. I think "upgrading" JavaScript is a wasted effort. The industry’s effort would be better spent designing a language to make web programming easier and more maintainable. We need to let go of all those design flaws that are crippling it now (no type-safety, inheritance, etc.). Getting browsers to comply with ES4 or a new language will take about the same amount of time.

    I say we leave JavaScript as it is and provide a path to providing a new industry/standard-supported language that better meets the needs of tomorrow’s web application.

  39. Chris Hallman says:

    Coming from the company that epitomizes "Embrace, extend, extinguish", it’s amazing you have the nerve to claim you’re "Open to input".

  40. William says:

    As I’ve been reading on this topic, and I am by no means a writer of languages, I can’t help but recall the frustrations I had with web site development during the Netscape Communicator 4.X era, when every slightly new version of the browser contained a new (and often different) implementation of JavaScript. There were endless hours of frustration and time wasted with version-specific scripts and browser detection. It’s been a joy to have a (reasonably) stable scripting platform for a few years now, despite subtle differences in the DOM implementations in IE and FF. I think that any move that leads back to those days is just that, a step backwards.

  41. Al Billings says:

    Philip,

    I look forward to Microsoft’s open and non-proprietary creation of something newer and better than ES3 that is open to all. Until then, unfortunately, the rest of the industry has to move on and do something. ES4 seems to be one of the things that is being done. Personally, I don’t want to wait another two or three years to see what Microsoft proposed alternative is and then hope it fills the needs of, among other things, its competitors.

    Chris,

    The "Open to Input" didn’t come from a company. I don’t see a "Mr. Microsoft" here. It came from Chris Wilson. Hyperbole won’t really serve well here. Having been told to shut up, alongside Chris, during IE5 days when we both were publicly speaking about better standards support, I can attest that Chris isn’t overly inclined to see a non-standards solution to things. That doesn’t mean his boss, his boss’ boss, or his company isn’t though, given a choice.

  42. John says:

    Opera has a good and fast JS engine, Mozilla will get one with Tamarin. Instead of coming up with an alternative, bugfree implementation you seem to continue playing nasty games. Again.

    Come on guys, we all know that IE is behind it’s competitors. Let’s close that gap first, then it’s time to come up with something better.

  43. thacker says:

    I would truly love to read an analysis of what changes within EC4 will bring to the end-user, from the ‘eyes’ of the millions of people who launch a browser every day.

  44. @Phillip: Why does a web developer need to learn a new language just because MS having issue to incorporate changes in their JS interpreter?  we already have so many frameworks around, we can’t afford another language in our pocket.

  45. Segedunum says:

    <i>I, too, though you obviously don’t realize it, am dedicated to an open, standards based web experience.  I am not dedicated to any particular ideology, mind you; I just think they make good economic sense.</i>

    Microsoft doesn’t make money from open standards. That’s the bottom line. You belong to a company that, quite frankly, has never worked with any.

    <i>Stating that my personal decisions and opinions skew toward the proprietary is so laughable that I needed to put down my coffee.  You clearly don’t know me, and are painting me personally with a stereotypic Microsoft brush.</i>

    You work for Microsoft, and Microsoft makes it’s money purely from proprietary software and the lock-in that brings.

    What do you want people to explain, exactly?

  46. Segedunum says:

    <i>@Robert Sayre – I failed to see where Jason pointed out ANY such thing – can you point me to this?</i>

    Did Microsoft know that you were incapable of communicating and reading at your interview?

    <i>it is an artifact of using a different MIME type and the approach that says plugging in a different runtime engine will be workable.  We didn’t raise that solution.</i>

    Would it be possible to phrase this in English, because it doesn’t actually mean anything?

    <i>Please don’t refer to my personal opinions as unsubstantiated FUD.  I was asked for my personal opinion; I gave it.  I am open to both new input and being proved wrong; the same does not apparently go for everyone participating in this "discussion".</i>

    Ahhhhhh. I believe that you were talking about shouting people down and dissenters above?

    Without specific examples and engaging in a manner where these specific problems can be identified, by you, what you’ve written is utterly meaningless. I think I read that in a manual somewhere.

    Sadly, this well worked approach in accusing the very people you’re having a go at of the same behaviour you’re exhibiting, whilst saying nothing at all, is a very familiar concept to a lot of people now ;-).

  47. SpankD says:

    I think before MS spends 1 minute on another standards committee they should spend the time on making their current browsers, through updates or rebuilds, Actually adhere to standards. We have issues with compliance with CSS, XHTML, HTML and Javascript. Simple hello world applications display exactly the same on most of the browsers out there with the exception of the MS line of browsers. There trash and the only reason they have ANY market share is the fact that its preinstalled on PC’s. Very few go to MS looking for a newer better browser.

    In fact maybe this is the time for MS to ditch the browser itself. Your not very good at it. Just include Firefox on all your PC’s from now on and save yourself the wasted money.

  48. dIE says:

    @above…bingo.

  49. President Leechman says:

    I agree with Microsoft: ES4 isn’t a new version of Javascript, it’s a completely different language… it’s damn near like calling C++ a new version of C.

    On the other hand, Microsoft does need to get its act together. Get your bloody browser in line with the rest of the world. Bring the HTML and JS and CSS up to spec, and quit pushing dangerous junk like ActiveX while you’re at it.

    You’re right here, but you’ve been a wolf in shepherd’s clothing too many times for people to see what you’re getting at without those "it’s only Microsoft" filters getting in the way.

  50. Brianary says:

    Seriously?

    You guys worked so hard to convince us that THIS time, you were really pro-standards, only to burn us AGAIN?

    What if every browser decided to go off on their own and decide not to implement a standard because the project lead decided that an update "changes the character of the language"? I’m sure that the specs aren’t perfect, but the web is agreement, not a cathedral.

    Expect some questions at MIX08.

  51. @Chris

    "I never suggested halting progress;"

    I never said you did. You did suggest that there were interoperability issues, though. You voiced an opinion based on a vauge factual statement that is yet unproven.

    Until you do provide proof, your opinion is baseless.

    I’m not sure if I confused you by my use of the word "use-case" or what you’re really confused about. It seems that out of all that I wrote, you picked out the word "use cases" and missed my point entirely.

    I am not an ES4 representative, I’m just a programmer. The things I listed are things that are either not practical or not possible in JS. These aren’t "user stories," so hope that clarifies.

    @Chris:

    "It’s my opinion the current ES4 proposal (and plan for deployment) causes interoperability issues on the web, as the mashup development pattern would require interoperation of current ES3 scripts as well as supposed new ES4 scripts"

    Opinion, and inductive logic in general, is formed on the basis of observation and insight.

    Your statment that the proposal and plan itself cause interoperability issues cannot possibly be true. How can a plan cause interoperability issues? If you meant to say that "if ES4 is implemented with/without feature XXX, it will cause interoperability issues," then well, that statement would merit further discussion, but you didn’t actually say that and you’re shying away from such discussion altogether by being vague. What you actually said is proposterous.

    If you want to be productive, communicate your observations on The ES4 discuss list. Provide a detailed scenario and a specific example. Brendan is super smart and very patient; there is a lot of intelligent discussion on the list; Don’t worry about FUD — what does that mean? I don’t even know. LOL

    Here’s an example of an opinion, backed by reasoning.

    ———————————————————-

    In ES4, RegExp will be callable (fact). Example:

    /hey/("hey")

    Here’s my opinion:

    This is just a shortcut to .exec().

    This complicates the object’s interface with behavior that it does not need.

    This feature makes it easier to write confusing code, but does not make it easier to do anything else. Example of confusing code:

    function doIt() {

     if( r("hey") ) return;

    }

    r looks like a function.

    The alternative:

    .exec().

    .exec() does the same thing.

    exec has widespread support and works.

    It’s more explicit, it doesn’t complicate the object and make it callable.

    ———————————————————-

    That’s my criticism for a real ES4 feature, backed by reason, which I posted this on the ES4 discuss list. AFAIK, nobody agrees or cares, but that’s not my point.

    Posting vague claims on your blog, e.g. "That doesn’t seem like it will have good interop to me," or "ensuring stability of the ecosystem as it is today should take priority," and providing absolutely no basis or validation for your claims is not unproductive, it’s counterproductive. It’s clearly getting you a pretty strong negative personal response.

    It is a misfortunate coincidene for you that your opinion seems to be the along the same lines as your company’s. Being vague and refusing to enter into intelligent debate on the list is not making you look any more sincere.

    I am a programmer who is doing this in my own time; I’m not going to try to post your opinion on the ES4 list, as you suggest. You go there.

    @Chris:

    "What exactly have you heard from other vendors?"

    Other than MS and Mozilla, I haven’t. I have not seen 1 post on the list from a MS emploee there. Instead, it’s Employees have posted on blogs, safely avoiding well-reasoned, intelligent debate.  

    I have read individuals’ posts. For example: Peter Michaux posted reasoned opinion for adding Funciton.prototype.bind, Robert Sayre had useful insight about JSON proposals/alternatives, David Anderson has posted insight regarding RegExp lookaheads. I’ve posted my own comments: |this| in a static method should point to the class, SortedSet<T>, Enum would be useful for a set of objects, a DateFormatter could fulfill the need for formatting/Parsing localized Dates, Object.prototype.toJSONString adds to much responsibility to Objects, String.prototype.parseJSON makes no sense.

    Posting on the list might seem scary. Don’t be afraid. Present your ideas on the ES4 list objectively, with examples.

    Best Regards,

    Garrett

  52. Swaroop says:

    Hello Chris,

    > "as the mashup development pattern would require interoperation of

    > current ES3 scripts as well as supposed new ES4 scripts.  With the

    > ScreamingMonkey plan, this clearly won’t work well – as they’ll be

    > run in different runtimes – but even without it I expressed my

    > skepticism that ES3 scripts won’t suffer if run through an ES4

    > engine.""

    Since ES4 is backwards-compatible with ES3, wouldn’t ScreamingMonkey

    be handling *all* scripting in the browser?

    I don’t understand why ES4 would run inside ScreamingMonkey and ES3

    would need to run inside IE. ES3 can also run inside ScreamingMonkey.

    Can you please explain "but even without it I expressed my skepticism

    that ES3 scripts won’t suffer if run through an ES4 engine."?

    What do you mean by "suffer"?

    Thanks!

    Swaroop

  53. me says:

    we should ignore IE and help people to use better browsers. MS will never understand.

  54. ES5 says:

    Make JavaScript more powerful won’t be compatible with long term Microsoft strategy. Personally I believe that’s one of the major concerns from MS.

    As to what I heard, _old_ style javascript should still run without any modification.

    And there is a ML implementation available now… I don’t know if it is possible to borrow some code there and merge with JScript code base?

  55. ChocoLim says:

    I hope that someday we can have just one javascript, i hate the "diferent" jscript and  very buggy.

    I think if it is a new languaje you is better for ms because ms never was capable to solve all the memory leaks of the old one

  56. Perl Junkie says:

    I jumped here (very QUICKLY) after skimming a news article about the new ECMA proposal in an InfoWorld article.  I don’t have the time right now to read neither that article nor your blog in it’s entirety, BUT…

    The InfoWorld article supposedly quotes Wilson of Microsoft from this very blog as stating:

    "As I’ve frequently spoken about publicly, compatibility with the current web ecosystem — not ‘breaking the Web’ — is something we take very seriously…"

    I just have to say that it’s literally laughable to hear you speak out of the corner of your mouth that your company "cares" about so-called "breaking the web" when no company in the history of software development is more guilty of breaking de facto standards than Microsoft.

    Current browser incompatibilities are practically entirely dominated by incompatibilities that your company has created in a so-called effort to "improve" things, when instead, you guys just have your own way of doing things and you drive those so-called "improvements" by sheer weight of market share and market penetration and not by actual technological innovation and improvement.

    No one is more guilty of "web pollution" than your company.  And the ECMA standard (both existing and proposed), is only ONE of those arenas in which your company as introduced massive incompatibilities and pollution of de facto standards that the rest of the development world not only honors but sees as better technology that what you guys generally postulate and then ram down everyone’s collective throats again by sheer force of market penetration (eg. people HAVE to pay attention to you, but not on the basis of superior technology — frankly your "standard" today of ECMA implementation STINKS, albeit that Mozilla’s isn’t always 100% compliant either.)

    So it’s laughable to hear that you "care" when it’s been clear for a very, very long time, esp. to people who aren’t taken in by your Borg  marketing machine, that Microsoft is the biggest culprit in the game of development standards technology pollution and "breaking the web."

    -pj

  57. Garry Trinder says:

    @Perl Junkie,

     You clearly have not been listened to what I’m saying.  "Breaking de facto standards"?  That is not, actually, something I would list on my conscience.  Improperly implementing de jure standards and causing de facto problems is probably more apt.

  58. afcnn says:

    99% of the JScript is identical to the ES3 spec, and ES4 spec is fully compatible with es3. Maybe microsoft does not want to see the JS to invole so quickly, because they have WPF and the SilverLight, if JS involves so quickly, no one will use SliverLight (futher will based on c# and other .net language) anymore, maybe that is the their concerns.

  59. Sean Green says:

    I think the same game is going to be played as with ODF -> That is The need for plug-ins.

    That is why Adobe Virtual Machine 2 ActiveScript3.0 Technology wise is light-years ahead then Javascript. As both are open source donations by now – their adoption by Ebay – in Ebay Desktop in Adobe (AIR) is by plugin. who can surf the web and watch a video on YouTube, without Flash. It will be Microsoft’s failure to aggravate both the consumer and developer – by making things hard and requiring plugin’s for IE7 and funny in Office for ODF support!  It will only hurt IE7 users and Office users left out of technical advancement. By doing so it  try’s to halt technological advancement by holding to the past. It never works, science and technology has way of advancing while others are fooling around. In this case, look at adobe, with Flash, Air, and Buzzword!

    Good luck  

  60. Why don’t you guys implement the EC4 proposal?

    There are people who bitch and moan and there are people that get things done.  Which one are you?

  61. bilgi yarışması says:

    we should ignore IE and help people to use better browsers. MS will never understand.

  62. My understanding is that the proponents of the es4 draft are more than happy to work things out in the open. Looking through the es4 discussion and the blogs it seems that you’re not being ‘shouted down’. Rather those not happy about es4 have been quiet about the technical reasons and haven’t started a discussion on things to change, etc. Instead they’ve raised vague comments in open forums about not liking the new proposal.

  63. Webdesign says:

    No one is more guilty of "web pollution" than your company.  And the ECMA standard (both existing and proposed), is only ONE of those arenas in which your company as introduced massive incompatibilities and pollution of de facto standards that the rest of the development world not only honors but sees as better technology that what you guys generally postulate and then ram down everyone’s collective throats again by sheer force of market penetration (eg. people HAVE to pay attention to you, but not on the basis of superior technology — frankly your "standard" today of ECMA implementation STINKS, albeit that Mozilla’s isn’t always 100% compliant either.)

  64. Webhosting says:

    Posting vague claims on your blog, e.g. "That doesn’t seem like it will have good interop to me," or "ensuring stability of the ecosystem as it is today should take priority," and providing absolutely no basis or validation for your claims is not unproductive, it’s counterproductive. It’s clearly getting you a pretty strong negative personal response.

  65. seo says:

    I hope that someday we can have just one javascript, i hate the "diferent" jscript and  very buggy.

  66. I want to chime in with support for Chris Wilson – not MS, just Chris, and his reaction to ES4. I’ve designed languages, and written compilers and interpreters, and ES4 fills me with repugnance.

    The implied claim of many posters here that programming language design can be made rational and systematic is itself illogical and contra-factual. It’s a bolshevik fallacy: Get a group of smart domain experts together and they can solve any problem, including leading the masses into a glorious future.  Since every programmer feels like a smart expert in some domain, this idea has seductive appeal. "Oooh, if I was on the committee, I know what I’d add!"

    But when a committee undertakes leadership, you get the Committte for Public Safety. You get language design with the intellectual integrity of legislation because it’s produced by the same process: Pork, horse trading, opaque bits contributed by lobbyists – A chimera, a Frankenstein’s monster of stolen parts with a disturbing smell clinging to them.  ES4 is as much a new language as C++ was, and language design is a fundamentally creative – forgive me, an *artistic* endeavor. Discard intuition and judgment, wisdom and restraint, and you discard the vital core of the process. When committees try it, they give birth to monsters.  ES4 is our decade’s PL/I. Or Algol 68. Or Ada. Or Common Lisp.

  67. TNO says:

    ES4 is our more like our decade’s Scheme.

    Since you have experience in language design, why not take a few minutes and post on the ES4 mailing list reasons why the language is repugnant?

    Just simply stating that:

    1. Committees are bad,

    2. ES4 has a committee,

    3. Therefore ES4 is bad.

    This is the same logical fallacy as stating:

    1. God is Love

    2. Love is blind

    3. Ray Charles is blind

    4. Therefore Ray Charles is God

  68. ES4 is our more like our decade’s Scheme.

    Since you have experience in language design, why not take a few minutes and post on the ES4 mailing list reasons why the language is repugnant?

    Just simply stating that:

    1. Committees are bad,

    2. ES4 has a committee,

    3. Therefore ES4 is bad.

    This is the same logical fallacy as stating:

    1. God is Love

    2. Love is blind

    3. Ray Charles is blind

    4. Therefore Ray Charles is God

    good.

  69. hello, thanks you for this articles

    i read all article to your web site

    i like your site, thank you friend

  70. hello, thanks you for this articles

    i read all article to your web site

    i like your site, thank you friend

  71. Ricardo Tomasi says:

    Almost one year passed and we’re still waiting for a sensible response to Garret Smith’s comment. Oh well…

  72. No one is more guilty of "web pollution" than your company.  And the ECMA standard (both existing and proposed), is only ONE of those arenas in which your company as introduced massive incompatibilities and pollution of de facto standards that the rest of the development world not only honors but sees as better technology that what you guys generally postulate and then ram down everyone’s collective throats again by sheer force of market penetration (eg. people HAVE to pay attention to you, but not on the basis of superior technology — frankly your "standard" today of ECMA implementation STINKS, albeit that Mozilla’s isn’t always 100% compliant either.)

  73. Posting vague claims on your blog, e.g. "That doesn’t seem like it will have good interop to me," or "ensuring stability of the ecosystem as it is today should take priority," and providing absolutely no basis or validation for your claims is not unproductive, it’s counterproductive. It’s clearly getting you a pretty strong negative personal response.

  74. FREE TEXTS says:

    I don’t understand why ES4 would run inside ScreamingMonkey and ES3

  75. Medyum says:

    My understanding is that the proponents of the es4 draft are more than happy to work things out in the open. Looking through the es4 discussion and the blogs it seems that you’re not being ‘shouted down’. Rather those not happy about es4 have been quiet about the technical reasons and haven’t started a discussion on things to change, etc. Instead they’ve raised vague comments in open forums about not liking the new proposal.

  76. Medyum says:

    I hope that someday we can have just one javascript, i hate the "diferent" jscript and  very buggy.

    I think if it is a new languaje you is better for ms because ms never was capable to solve all the memory leaks of the old one..

    Thank This Post.

  77. medyum says:

    It’s been pointed out that we haven’t made an alternate proposal – well, I’d kinda hoped we could work it out together.  "Open to input" should be the way of the web, should it not?"

    My understanding is that the proponents of the es4 draft are more than happy to work things out in the open. Looking through the es4 discussion and the blogs it seems that you’re not being ‘shouted down’. Rather those not happy about es4 have been quiet about the technical reasons and haven’t started a discussion on things to change, etc. Instead they’ve raised vague comments in open forums about not liking the new proposal.

    Please get your people involved in the es4 discussion list and help resolve what they see as issues in the proposal. In the open. Like you suggest.

  78. I don’t understand why ES4 would run inside ScreamingMonkey and ES3

  79. çilek oyun says:

    I don’t understand why ES4 would run inside ScreamingMonkey and ES3

  80. hikaye says:

    I want to chime in with support for Chris Wilson – not MS, just Chris, and his reaction to ES4. I’ve designed languages, and written compilers and interpreters, and ES4 fills me with repugnance.

    The implied claim of many posters here that programming language design can be made rational and systematic is itself illogical and contra-factual. It’s a bolshevik fallacy: Get a group of smart domain experts together and they can solve any problem, including leading the masses into a glorious future.  Since every programmer feels like a smart expert in some domain, this idea has seductive appeal. "Oooh, if I was on the committee, I know what I’d add!"

    But when a committee undertakes leadership, you get the Committte for Public Safety. You get language design with the intellectual integrity of legislation because it’s produced by the same process: Pork, horse trading, opaque bits contributed by lobbyists – A chimera, a Frankenstein’s monster of stolen parts with a disturbing smell clinging to them.  ES4 is as much a new language as C++ was, and language design is a fundamentally creative – forgive me, an *artistic* endeavor. Discard intuition and judgment, wisdom and restraint, and you discard the vital core of the process. When committees try it, they give birth to monsters.  ES4 is our decade’s PL/I. Or Algol 68. Or Ada. Or Common Lisp.

  81. aöf says:

    Very good, congratulations article

  82. cinsellik says:

    I am grateful to you for this great content.

  83. radyo dinle says:

    been pointed out that we haven’t made an alternate proposal – well, I’d kinda hoped we could work it out together.  "Open to input" should be the way of the web, should it not?"

    My understanding is that the proponents of the es4 draft are more than happy to work things out in the open. Looking through the es4 discussion and the blogs it seems that you’re not being ‘shouted down’. Rather those not happy about es4 have been quiet about the technical reasons and haven’t started a discussion on things to change, etc. Instead they’ve raised vague comments in open forums about not liking the new proposal.

    Please get your people involved in the es4 discussion list and help resolve what they see as issues in the proposal. In the open. Like you suggest.

  84. sikiş says:

    I am grateful to you for this great content.

  85. I want to chime in with support for Chris Wilson – not MS, just Chris, and his reaction to ES4. I’ve designed languages, and written compilers and interpreters, and ES4 fills me with repugnance.

  86. I don’t understand why ES4 would run inside ScreamingMonkey and ES3

  87. I don’t understand why ES4 would run inside ScreamingMonkey and ES3

  88. hakan bey says:

    medium ve medyumluk astroloji hakkında bilgi veren güvenilir bir site

  89. buraya birseyler karaliyorum sen bunlari gorme.

  90. medyum says:

    Bende senin yaptıgını yapıyorum nedesem yalan olur

  91. zayıflama says:

    guzel bir site imis bu site amina koyyum

  92. medyum memis cenap hoca buyu bozma yontemleri

  93. onliner says:

    Your article is still topical,

    thanks a lot

  94. yenimoda says:

    According to TG1 meeting notes from June/July 2006, Microsoft was planning on implementing ES4 post IE7.  From there until March of 2007, it looks to me like Microsoft was fully complicit with the ongoing design.

    see:

    http://wiki.ecmascript.org/doku.php?id=meetings:minutes_jun_28_2006

    http://yenimoda.blogspot.com/

    Perhaps you could address why Microsoft’s stance has changed in specific, technical details?  Clearly ES4 was acceptable and appealing at one point.  Why the change of heart?  And why weren’t reservations about ES4 brough to TG1 sooner?

  95. bmw gt1 says:

    I tested this on my 3.20 GHz Pentium http://www.nantonin.com  HT PC with 2GB RAM and a surprise on the old – 8-year-old woman – 20GB Seagate hard drive that works at http://www.chinese–furniture.com

  96. Since then, we have continued to work in this direction.  The “JScript Deviations” document that started this discussion was created as an input into the process.  We think that a detailed understanding of the current level of conformance by various implementation is a necessary precursor to any major standards revision.   Our overall progress has been slower than I might have hoped for.  There are not a lot of organizations that actually participate in TC39-TG1, I believe that up to this month of this year there have been only 5 organizations that have been consistently attending meetings. Other than Microsoft and Yahoo! the other all seem firmly committed to the development of ES4 and have shown little interest in actively participating in “ES3.1” or any effort not directly related to the development of “ES4”. (some may argue with that last statement, but it’s my real perception)

  97. y postulate and then ram down everyone's collective throats again by sheer force of market penetration (eg. people HAVE to pay attention to you, but not on the basis of superior technology — frankly your "standard" today of ECMA implementation STINKS, albeit that Mozilla's isn't always 100% compliant either.)

  98. medyum says:

    My understanding is that the proponents of the es4 draft are more than happy to work things out in the open. Looking through the es4 discussion and the blogs it seems that you're not being 'shouted down'. Rather those not happy about es4 have been quiet about the technical reasons and haven't started a discussion on things to change, etc. Instead they've raised vague comments in open forums about not liking the new proposal. http://www.medyumoguz.net

  99. werkbladen says:

    Wonderful post. I appreciate your attention to this subject and I learned a good deal.

    <a href="http://kopen-werkbladen.nl">werkbladen</a&gt;