[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
_______________________________________________
Es4-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es4-discuss
