kriszyp at xucia.com
Tue Oct 30 15:25:22 PDT 2007
Thank you for the thorough and even somewhat inspiring response, that
certainly helps me (and hopefully others) to understand the situation
better. I may a have few other questions later, but for now, Thank you!
On 10/30/07, Brendan Eich <brendan at mozilla.org> wrote:
> [Kris asks legitimate questions, to be answered by more than a Microsoft
> spokesperson. I'm going to reply cc'ing the list, even though there are
> political points here along with technical content. The list is for
> discussion of ES4, and that category looks like it must include some
> political discussion.
> Also, this reply is LONG. Sorry, I've tried to compress without doing
> anyone an injustice.
> Skip if you want to avoid any political content. If you think I'm FUDding
> or attacking individuals unfairly, call me on it -- with specific quotations
> if possible. If I'm out of line, I'll apologize to the list and amend my
> words. If we simply disagree on the fundamental substance, that's good to
> know too.
> I'm trying to shed some light on what has clearly been too much of a
> dark-room standards process, excluding the materials we've exported at
> On Oct 30, 2007, at 9:17 AM, Kris Zyp wrote:
> From a pragmatic perspective, it seems to that the critical goal behind
> all of this, is what will bring a better development environment for the
> future of the web, and the key to this is what will be broadly implemented.
> The choice of the name is of course around this central issue since the ES
> title brings such a strong motivitation for implementation. However, if ~10
> Try two years -- ten is way, way too long for developers to wait, and
> anyway beyond any credible crystal ball's range. The proprietary stacks from
> Microsoft and Adobe won't wait that long for competition from browser-based
> web standards, as Doug Crockford and others warn; they'll propagate all over
> the web well before ten years.
> down the road, ES4 is not implemented broadly enough that web developers
> can code to it, than it is of signficantly less value. While unanimity is
> not needed for a standard to be passed, if the one of the key browser
> vendors will not implement it, than how valuable are our efforts?
> Let's find out, by having a standard that browsers and plugins can choose
> to implement for interoperability and shared developer knowledge. Enough
> companies want ES4 as a standard that (absent technical problems), it ought
> to become one, whether or not all browser vendors buy into it.
> If you give all the power over standardization to any one company, then
> you are that company's slave, and I predict you'll get treated accordingly.
> This happened once already, after IE achieved a virtual monopoly. Just
> consider all the unfixed JScript bugs, many dating to IE4, still in IE7.
> I know that there are, or will be efforts to provide a Tamarin plugin for
> other browsers, but is this really what we are pinning our hope on?
> Not necessarily, but (hey, I came up with it <http://weblogs.mozillazine.org/roadmap/archives/2007/07/new_projects.html>;-)
> it's not a bad plan absent competitive pressure on Microsoft to support ES4
> in IE.
> You may not know this, but minority-share browsers do not have as low
> market share as the Comscore and WebSideStory analytics firms' results show
> in aggregate for the U.S.. At high value sites, visited more frequently by
> "lead users" and otherwise influential (and better-monetized) visitors,
> Firefox, Safari, and Opera do better -- sometimes much better. If you look
> at Xiti's results<http://www.xitimonitor.com/en-us/browsers-barometer/firefox-july-2007/index-1-2-3-102.html>for Europe, Firefox is trending to cross the 50% market-share line in some
> Whatever you do, never give up your own sovereignty as a browser user or a
> web developer to a dominant player. You always have a choice.
> Plugins usually don't reach necessary distribution for developers to rely
> on them.
> Counterexample: the Flash Player.
> I have no idea whether Flash would ship ScreamingMonkey support. I
> certainly hope so, given Microsoft's rejection since early this year of ES4.
> Or are we hoping that the ES4 title will be sufficient to get an
> implementation from every vendor?
> Title, schmitle. :-) The "brand value" of ES4 may be an issue for browser
> vendors, but it is not the main issue for developers, and users don't know
> or care. What matters is whether web developers can effectively demand, and
> count, on near ubiquity and quality from ES4 implementations, soon (a year
> or two). That is an open question, as noted above -- and there are several
> reasons to have hope.
> I certainly acknowledge that it is insidious that there might a
> suggestion to design around one member, but I will still ask, is there any
> concessions that can be made to increase the probability that MS would
> implement ES4 in the future?
> No. Without speaking for anyone else, I am now going to give more
> information about what has already been said inside TG1, since the TG1
> dispute has already spilled out into the blogosphere since last week's Ajax
> Experience East, when as part of a panel discussion, Doug Crockford made
> some statements about TG1 members and motives. Others in TG1 can back this
> up, and anyone can check our meeting minutes, which are public at
> http://wiki.ecmascript.org/ with complete revision histories.
> While at certain times, as in late 2006 and before March 2007<http://wiki.ecmascript.org/doku.php?id=discussion:browser_profile>,
> Microsoft talked in TG1 (or possibly just to me) about perhaps
> of substantive changes from ES3 like those in Firefox: No JS1.7extensions, no change from ES3 apart from deprecations and maintenance.
> IIRC, you yourself heard a "No" in reply to your "JS1.7 features coming in
> IE?" face-to-face question posed to Chris Wilson at The Ajax Experience West
> this summer (I happened to be nearby at the time). I recall seeing some
> back-peddling to avoid committing either way in a comment from Chris at
> http://ajaxian.com after that, but you tell me: do you really expect
> anything more, given statements such as Allen Wirfs-Brock's comment at Ric
> Johnson's OpenAjax blog<http://openajax.com/blog/2007/10/29/god-bless-scoble/>,
> and the content available at the JScript blog<http://blogs.msdn.com/jscript/archive/2007/10/29/ecmascript-3-and-beyond.aspx>
> Sure, a Microsoft "vision" for JScript will be rolled out, real soon now.
> Based on everything we've heard in TG1, it is safe to say that the vision is
> either a fork of ES3 away from ES4, or a lot of do-nothing posturing about
> maintenance and safeguarding compatibility, to give Silverlight and WPF time
> to penetrate the Web. I would love to be proven wrong -- c'mon, Microsoft,
> make me eat my words (happily): embrace (and extend, for all I care) ES4.
> Just get the mandatory core language right, as in, far fewer overt bugs than
> JScript vs. ES3.
> Perhaps this has already been discussed, so I apologize if it has. Does
> MS have specific issues, or is their dissent simply for the purpose of
> avoiding committing to implementation (regardless of the content of ES4)? Is
> security one of the main issues? Is it the size and scope of the language?
> From what I understand, I think these are Crockford's concerns, although I
> don't know if that is true for MS.
> One at a time:
> * Not only the majority of TG1, but many on this list, have asked for
> specific technical objections, and received none in reply. Even a summary
> technical judgment against ES4 in full needs to be decomposable into smaller
> technical arguments. ES4 needs to be fully specified and implemented, for
> sure, so we're not claiming it is done or proven yet. But disproof that
> disqualifies it as a candidate successor edition needs to be demonstrated.
> On a positive note, I will say this: as a working group, when we have not
> been wearing political armor, we've had productive technical dialogs about
> proposed ES4 features and their progenitors in the literature, especially
> with Allen Wirfs-Brock. But the Microsoft position (so-called -- it's clear
> when Allen is speaking for Microsoft, which is a good thing!) has not
> consisted of detailed analysis and conclusions against specific technical
> features. It has simply been a summary judgment expressed as "Microsoft
> opposes ES4" and (memorably, from April) "the web doesn't need to change
> * The browser profile<http://wiki.ecmascript.org/doku.php?id=discussion:browser_profile> I
> cited above, started by Pratap Lakshman of Microsoft, was superseded by an
> ES3.1<http://wiki.ecmascript.org/doku.php?id=es3.1:es3.1_proposal_working_draft> proposal,
> which was made following an agreement at the March TG1 meeting. At that
> meeting, it was also agreed that any ES3.1 would be implemented as a
> subset of the ES4 reference implementation (for testability) This has not
> Everyone also agreed at the March meeting that ES3.1 would not be approved
> by TG1 until it could be evaluated for forward and backward compatibility.
> Finally, I recorded an agreement at least among the majority of TG1 that
> ES3.1 was not approved of as a standard-to-be, but was something the
> majority thought could be explored further by the minority group, under
> TG1's charter from TC39.
> Note that the "3.1" name does not work in Ecma terms. There is no minor
> edition process in Ecma (mozilla.org has hosted the only errata<http://www.mozilla.org/js/language/E262-3-errata.html>page), so if
> ES3.1 were standardized as a successor to ES3, it would be renamed the 4th
> Edition. This obviously would create conflict in TG1 and confusion in the
> * ES3.1 was superseded by no substantive work in the es3.1 section of the
> wiki since April<http://wiki.ecmascript.org/doku.php?do=recent&first=100&id=>.
> Instead, two documents describing JScript (one about the @if/@else/@endif
> the other about JScript deviations<http://wiki.ecmascript.org/lib/exe/fetch.php?id=resources%253Aresources&cache=cache&media=resources:jscriptdeviationsfromes3.pdf>from ES3), have been produced by Pratap. These are informative, but not even
> potentially normative as written, except where browser implementations have
> already matched JScript (in order to gain market share by interoperating) --
> and ES4 already contains such bug fixes to ES3.
> * Security is an "issue" (not in the Oprah sense), all right. A bit more
> precisely, it is a set of end-to-end properties that need solid enforcement
> mechanisms at many layers of abstraction. Security is however *not* a
> unitary good or "product". You sometimes hear demands for TG1, or all
> browser vendors, to stop the world and work on security. That is an
> unrealistic demand; the world doesn't work that way.
> We've talked a bit in TG1 about security properties, mainly Integrity and
> Confidentiality. Apart from making ES4 statically checkable and improving
> binding forms to reduce mutation hazards, we are not biting off riskier
> work. The academic research is not solid yet (unlike the research on
> multimethods, for example). There is no good way that anyone involved in TG1
> can see, in the core ECMAScript language only, to standardize a capability
> system for the web.
> It's clear from experience from Mozilla and many security researchers that
> even *a posteriori *mashups built on a capability system will leak
> information. So information flow type systems could be explored, but again
> the research on hybrid techniques that do not require *a priori*maximum-authority judgments, which do not work on the web (think mashups in
> the browser without the user having to click "OK" to get rid of a dialog),
> simply is not there yet. Mashups are unplanned, emergent. Users click "OK"
> when they shouldn't. These are hard, multi-disciplinary research problems.
> Experiments such as Google Caja<http://google-caja.googlecode.com/files/caja-spec-2007-10-11.pdf>are interesting (
> discussion<http://www.nabble.com/Initial-draft-Caja-design-docs---library-now-available-t4611010.html>here), and Mark Miller will (I hope) smite me mightily if I misspeak about
> it, but as far as I can tell, such systems create an incompatible subset of
> JS into which developers may "opt" -- not a successor standard for the
> ECMAScript language that is backward compatible. Such a subset could be a
> very good thing, don't get me wrong. But it does not fall neatly under TG1's
> charter, because it's not backward-compatible, and profiled standards are
> considered harmful.
> Anyway, it's early days for Caja and other such systems. If TG1 continues
> to function, it should definitely harvest good ideas from it, and stand on
> shoulders, not toes.
> We've pressed Doug Crockford on this point and heard nothing in the way of
> concrete proposals, save for a small one I championed at the last
> face-to-face meeting (a better-isolated String.prototype.evaluate() taking
> a scope object). But that went nowhere for lack of effort -- I half expect
> it to turn up in "Microsoft's vision for ECMAScript", which would make a
> fork in the standard. I'll still try to rescue it for ES4, but it's just a
> small isolation device, good to have, but not nearly enough for "Security"
> with a capital S.
> I hope to hear more from Doug and others as things evolve, but ideas like
> a capability-based message-passing architecture built on Google Gears, which
> Doug proposed at a talk<http://video.google.com/videoplay?docid=452089494323007214>given at Google recently, do not fit in ES4's schedule and mandate to avoid
> premature standardization. ES4 is not about to normatively specify Google
> Gears APIs, which only came out this past spring. Gears APIs for
> workerpools <http://code.google.com/apis/gears/api_workerpool.html> are a
> great idea, but they are out of scope for the core language, which has not
> only an apparently single-thread execution model, but one-thread-only and
> even zero-OS implementations.
> APIs such as those purveyed by Gears should be standardized in the WHAT-WG
> and/or the W3C (and I've seen some WHAT-WG standardization work on Gears
> I think that if even 25% subset of ES4 was uniformly implemented in all
> browsers in 10 years, web developers would be vastly further along than if
> the 100% of ES4 was implemented in half the browsers.
> You're kidding, right? Ten years is far too long, and there's no coherent
> 25% -- a lot of ES4 depends on the type system. Would you cut that and try
> to stitch the remaining pieces back together? King Solomon only offered to
> bisect a child to find the true mother. Quartering was not a good idea even
> for that purpose. Anyway, Microsoft is now the avowed anti-mother of ES4, so
> you are only going to help mutilate or kill ES4 with this kind of
> To switch metaphors to something less biblical, gory, and humorless: given
> the on-again/off-again flirtation with JS1.7 compatibility by Microsoft in
> TG1, I would not be surprised if you got a little foot-bumping under the
> table. But take it from me, they are teasing. ;-)
> While unfortunate that such orthogonal issues could affect language
> design, and perhaps stifle innovation, I would like to see what will be best
> for the future of the web.
> Does anybody know if there is anything that can be done to increase the
> likelood of full cross browser implementation of ES4? Does anyone know the
> issues or parts of ES4 that are causing dissent? Is it the impact of the
> size of the language (on security, implementability, etc)?
> Apologies for my excessive pragmatism,
> I don't think you are being pragmatic. I think you are making yourself too
> much of a victim :-], seemingly giving all power to the dominant player and
> hoping for some scraps from the table. Pragmatism means using the tools you
> have and looking out for your own interests, even if it is scary, or
> requires some risk in the short run.
> For me, pragmatism means ES4 as a standard that any browser can
> interoperably implement and deploy, with ScreamingMonkey for browsers that
> don't like ES4.
> The world can change. Before Firefox, there was no hope. Who knew in 2002
> or 2003 that we would be having an exchange like this one, within (my best
> prediction) a year or two of ES4 support rolling out, possibly to the
> majority of browsers? To quote from a great movie: Never give up, never
> surrender! ;-)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Es4-discuss