[TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM

[Brendan Eich]

[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 http://ecmascript.org/.

/be]

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 years

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 ;-) 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 for Europe,  
Firefox is trending to cross the 50% market-share line in some  
countries.

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,  
Microsoft talked in TG1 (or possibly just to me) about perhaps  
standardizing JS1.7 in Firefox 2, at other times we have heard a very  
clear "No" to the question of substantive changes from ES3 like those  
in Firefox: No JS1.7 extensions, 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, and the  
content available at the JScript blog?

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 much".

* The browser profile I cited above, started by Pratap Lakshman of  
Microsoft, was superseded by an ES3.1 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  
happened.

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  
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 market.

* ES3.1 was superseded by no substantive work  in the es3.1 section  
of the wiki since April. Instead, two documents describing JScript  
(one about the @if/@else/@endif preprocessor (PDF), the other about  
JScript deviations 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 are interesting (discussion 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 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 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 already).

> 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 bargaining.

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! ;-)

/be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20071030/a2d744d9/attachment-0002.html