
Brendan Eich on Ecma TC39, JavaScript.next, and Google Dash - mbrubeck
http://brendaneich.com/2011/08/my-txjs-talk-twitter-remix/
======
georgemcbay
I feel for Brendan Eich, he is a bit of an unsung hero when you consider what
he enabled with JavaScript and it is always stressful to learn someone is
trying to kill your baby.

Having said that, I really do hope it is killed. Well, not _killed_ , but
demoted to "one supported language of many". And the sooner this is started,
the better, because it is a long, long process. I don't think JavaScript is
_bad_ , but I do strongly feel that the underlying engine for client side web
programming should be a full-blown VM that supports many possible source
languages (ala modern .net with the CLR, DLR and all), and I'll support that
model regardless of who pushes it, so long as they do a good job on the
technical side and don't try to use it as a lock-in mechanism. Google seems to
be the most posed to do this (I can't imagine Microsoft giving up that much
control of .net) and their idea to support JavaScript as an interim target is
the only practical way this will ever be solved, so I hope Dart is successful
-- assuming it is actually going for this and not just trying to switch one
core language out with another, which remains to be seen when they announce
more information.

BTW, yes, I know you can already compile many other languages to JavaScript
(as Dart itself will do in the first stage), but.. why? Why not just put a
proper VM down there that is truly designed to efficiently run byte-code from
many different source languages, and have JavaScript be one of those
languages?

~~~
thepumpkin1979
A standard VM/Runtime specification for all the browser would be awesome. We
got plenty of them; CLR, DLR, JVM, Parrot, etc. Can you imagine? I can see
those mime types already: application/csharp, application/perl,
application/ruby, application/IL.

~~~
StrawberryFrog
To be pedantic, it wouldn't be "application/csharp". By the time it's compiled
to MSIL bytecode it doesn't matter if it was C#, VB, F# or whatever.
"application/MSIL" is what I'd say.

I can imagine it, and I guess my browsers already have three VM/Runtimes in
them (JavaScript, Flash, Silverlight) but it feels so inelegantly top-heavy to
have lots more.

~~~
thepumpkin1979
Right, call me silly but I'm honoring the "Right-click->View Source" spirit
here, I don't know about you but I feel more confortable knowing that my
browser is downloading source code and compiling or interpreting than
downloading some kind of binary to execute, even if you call it "intermediate
code", "byte code" "almost-there-machine-code" or whatever, it's still binary
stuff. I get your point though.

~~~
StrawberryFrog
I agree, source is better.

But. Flash isn't served as source, is it? And JS is often minified/obfuscated.
Sure you can run that through a tool to get back the source (sans comments and
long variable names) but you can do just that with MSIL bytecode too.

~~~
thepumpkin1979
Yep, Agree. Then we will see how additional tabs emerge in Firebug and Chrome
Developer Tools, I can see them already: "IL View", ".NET Refactor", "JSIL
View" hehe.

------
equark
From what is known, it seems as if Google plans to move all their Javascript
app building efforts to Dart. Given that GWT/Closure are already pretty
successful in large organizations and internally, that seems like a big bet on
Dart's future.

Whether the Dart VM gets adopted by other browsers seems relatively
inconsequential provided they have a decent cross-compilation story.

Assume Dart is objectively better except for lacking browser support. Even
Brendan Eich seems to admit that Dart will be "better". Then developing using
Dart will give you an adult tooling story (through Chrome/Dash VM/Brightly), a
server-side front-end language (capable of Google-scale applications),
optimized compilation to Javascript (presumably better than GWT), and major
corporate backing (in contrast to coffeescript).

This seems to be like the makings for a major win provided that Google commits
to adopting it internally.

~~~
BrendanEich
"Even Brendan Eich admitted...". As if I would not expect, nay _demand_ , that
Gilad and Lars would do better -- much better -- than JS!

For the record, I'm not worried about JS being replaced by a better language.
I am working to do that within Ecma TC39, by evolving JS aggressively.

The leaked Google doc's assertion that this is impossible and that a "clean
break" is required to make significant improvements is nonsense, a thin
rationale for going it alone rather than cooperating fully.

The big issue I have with Dart, which you seem to consider inconsequential, is
whether Google forks the web developer community, not just its own paid
developers, with Dart, and thereby fragments web content.

A Dart to JS compiler will never be "decent" compared to having the Dart VM in
the browser. Yet I guarantee you that Apple and Microsoft (and Opera and
Mozilla, but the first two are enough) will _never_ embed the Dart VM.

So "Works best in Chrome" and even "Works only in Chrome" are new norms
promulgated intentionally by Google. We see more of this fragmentation every
day. As a user of Chrome and Firefox (and Safari), I find it painful to
experience, never mind the political bad taste.

Ok, counter-arguments. What's wrong with playing hardball to advance the web,
you say? As my blog tries to explain, the standards process requires good
social relations and philosophical balance among the participating
competitors.

Google's approach with Dart is thus pretty much all wrong and doomed to leave
Dart in excellent yet non-standardized and non-interoperable implementation
status. Dart is GBScript to NaCl/Pepper's ActiveG.

Could Google, unlike Microsoft ten or so years ago, prevail? Only by becoming
the new monopoly power on the web. We know how that story ends.

~~~
magicalist
> We see more of this fragmentation every day

I'd be curious to see this backed up. Certainly with a long enough timeline we
are not at a maximum of "works only in x", and -- ignoring those beleaguered
Opera users still subjected to crappy UA sniffing -- I can't think of the last
time I came across a site that blocked me for whatever my choice of browser
(I'm a Chrome and Firefox user as well).

If, on the other hand, you're talking about fancy new CSS3 or WebGL (or
whatever) demos leaving out some browser due to neglecting to add a particular
prefixed property (or whatever), I don't really see that as a problem.
Prototype then standardize, right? Yes, not feature detecting and prefixing
properly is poor web development practice and yes, they are cutting out part
of their audience, but using an experimental feature inherently means that it
may break at some point, and almost certainly isn't supported in all browsers.

When 3d CSS transforms land in Firefox soon, there are going to be a whole lot
of demos out there that won't work. I would say that's an education and
library problem, not a fragmentation one.

~~~
BrendanEich
I was explicit about the problem, which is _not_ new features that come to
some browsers first, advertised in a browser-agnostic way. That is ok,
provided the features are on a standards track. What I cited is fragmentation
due to capital-C Chrome as a requirement.

Google is doing deals and marketing web apps and add-ons as "Chrome". This is
showing up all over the place, most recently in my experience on the Starbucks
free wireless service agreement page.

Major content publishers Mozilla has talked to are surprised that we can host
their Chrome-targeted web apps and HTML5-based extensions. They think such
things are exclusive to Chrome. If they use Dart and need native performance,
then that'll be true. There is a slippery slope, especially when more and more
of the differentiation is not on a standards track (Dart, NaCl, WebSQL).

Nevertheless most of the current differentiation is bogus and any modern
browser will do. There's certainly some "WebKit required" fragmentation. We
saw this with Amazon's kindle web app, which is specifically built to WebSQL
and not IndexedDB. But I do not believe any big player is pushing "WebKit
required" as an agenda or marketing program. In contrast, Google is clearly
pushing "Chrome" as a requirement or works-best-in brand.

The Chrome experiments, most recently

<http://www.allisnotlo.st/index_en.html>

are obvious, maybe too obvious. Defenders can always play up the "experiment"
hedge. That helps but only so much, especially when many of these experiments
could work in other browsers with trivial changes.

I'm told that people have run chrome.angrybirds.com in Firefox. So it should
be html5.angrybirds.com but -- no surprise from a marketing angle -- the
domain name starts with C not H.

~~~
foobarbazetc
Brendan,

First, I'm a huge fan. :)

... and I was with you until the WebSQL vs IndexedDB thing.

IndexedDB is a horrible, horrible thing. It should be put out of its misery
and replaced with WebSQL in Firefox.

Mozilla is singlehandedly holding back offline web apps with the insistance on
a slow and hard to program -- yet buzzword friendly -- technology that no one
actually wants to use. There's no reason what so ever to stick with a dumbed
down K/V store when you're not trying to replicate data across data centers.

So, IMHO, you've bought this bit of "WebKit required" onto yourselves. WebSQL
is the only production ready offline web app technology available today.

Take it from someone who offline enabled one of the biggest web apps on the
web: I'd rather leave out offline entirely than code IndexedDB.

Considering that Apple will never support it, it's pretty much dead. And I
feel that Mozilla is really on the losing end of this particular battle.

TL:DR; Please support WebSQL in Firefox. :)

~~~
ootachi
How should we deal with the mandatory dependency on a particular
major/minor/patchlevel version of SQLite? That seems bad to standardize on.

I personally think there's definitely room for a SQL database API built into
the browser, but Mozilla did have a point. It should be something a little bit
better specified than that.

Also, it's not singlehanded -- IE refused to support Web SQL as well IIRC, and
they aren't going away anytime soon.

~~~
BrendanEich
Thanks, that's worth reiterating: IE wasn't buying. Alas they didn't get
IndexedDB done for IE9. And, just because WebSQL wouldn't fly does not make
IndexedDB the one and only winner. We need to revisit this whole messy area.

~~~
tomica
did anyone on the standard bodies (from MSFT?) suggest LINQ framework as a
WebSQL "replacement" ?

it makes a lot of sense IMHO. it abstracts away dependency on exact SQLite
version, but preserves a familiar _SQL-like_ mental model. it is stable,
mature, well understood and widely deployed/used (god i sound like a shill..
;)

and has the added benefit that it can be implemented in two different
_flavours_ : as a standard JavaScript (ES3) library on top of WebSQL (or
SQLite in Gecko), or as a first-class language extension with syntax sugar
similar/related to array comprehensions (from JS1.7/Harmony/ES6)..

check out the two code samples, and a list of language extension (all feeling
right at home in JS):
[http://en.wikipedia.org/wiki/Language_Integrated_Query#Langu...](http://en.wikipedia.org/wiki/Language_Integrated_Query#Language_extensions)

if it wasn't proposed, can someone from WHATWG (like you Brendan ;) politely
ask Microsoft to "contribute" any related intellectual property to W3C? how
likely do you think would it be for AAPL/GOOG to accept it? (and if not, it
could simply be implemented as a thin layer above WebSQL ;)

------
gruseom
I'll pipe up with one thing nobody seems to be emphasizing. A lot depends on
_how good_ Dart turns out to be. Suppose it turns out so good that we get all
four of the following:

    
    
      1. No worse a user experience in any browser;
      2. A much better user experience in Chrome;
      3. A much better developer experience;
      4. A much better server-side platform than V8.
    

If we get all that, standards or not, I will be jumping for joy. If Dart is
that good, it will become standard, either de jure or de facto as alternatives
fall by the wayside.

Of the four, #1 (a good enough Dart->JS) seems problematic. #2 may be bad for
other browser vendors, but if it's good for users and programmers, why should
I care? I see no virtue in a lowest common denominator. #3 and #4 are hardly
objectionable. Only those who like them need bother.

I don't know how likely this win-win-win-win is, but here's why I'm indulging
in the hope. These guys have been gods of fast dynamic VMs since Strongtalk.
If Dart is their chance to build what they always wanted, but this time with
20 years of experience to draw on and the institutional support of a Google
behind them... well, we have the chance of something insanely great. Greatness
sets its own standard.

Comparisons to VBScript and Flash only kick in if what they come out with is
lacklustre.

~~~
bzbarsky
#2 is bad for users unless Chrome is shipping on all hardware and operating
systems users use. In fact, that's the same reason any sort of web-related
monopoly is bad.

Where's Chrome for PPC processors? Chrome for ARM (being worked on, but no
there yet)? Chrome for whatever architecture or OS users might want tomorrow?

The right comparison here in your success scenario may not be VBScript but
ActiveX, except without the security issues ActiveX had. If ActiveX were
required for use of gmail today, how would you feel about it? How would you
have felt about it in 2002?

~~~
gruseom
If ActiveX had been insanely great, not only would I feel fine about it, it
would be ubiquitous by now.

~~~
BrendanEich
Isn't "insanely great" a Steve Jobs phrase?

I like Apple's hardware (modulo the fans running all the time on my latest
dual-core i7 MBP), and some of its software (but WTF happened to Mail.app on
Lion?).

Still, "insanely great" didn't make Apple-only web tech ubiquitous. That took
hard, open-standards spec-work in the CSS WG. And that, to the extent it
happened with help from Apple, is the _opposite_ of the Dart plan in the
leaked memo.

Stop worshipping i.g. It's never that great. Native apps on iOS use
Objective-C, for crying out loud. Everyone's sh*t stinks.

I.g. is no excuse for monopoly behavior. The greatness goes away, leaving only
insanity.

~~~
m-k-s
Well said Brendan!

Like I said in a tweet this morning, I know those Googlers know way more about
JS than I do, but if they think as per the leaked mail) that devs are choosing
iOS over browsers because of JS, they have their heads in the sand.

Those choices are happening due to iOS as a _platform_ not because devs are
somehow so much more happier learning/using objective-C! The best thing that
Google could do is to KEEP working hard on improving the browser _platform_
like you guys are doing with B2G and they started to do with ChromeOS.

For example, I'd love to hear from the ChromeOS team exactly what in JS is
blocking them delivering all the kinds of APIs that B2G is promising to
deliver.

And on the server-side, some one should tell the hordes flocking to Nodejs
that they are all wrong! As you pointed out, serverside everyone can choose to
use whatever they want and given that choice, just look at everyone jumping on
the Nodejs bandwagon. I'd love to see all those thousands of module that dev
around the world have written in Go recently! (npmjs.org)

maks.

------
rafaelferreira
It is probably true that, even with a cross-compilation strategy, if Dart
doesn't get adopted by competing browser vendors it will be a force towards
fragmentation, which tends to be bad for the web.

An interesting question to consider, IMO, is whether a "clean break" for
client programming languages is a bad idea outright, irrespective of context
and motivation. If it is, it follows that the principal means for information
dissemination and collaboration our species has devised will forever be
programmed in the same language. It is a bleak thought, because, even if the
language was faultless at its time, progress happens and the web needs to
improve.

Of course Javascript can evolve (I personally very much like the proposals,
and look forward to working with ES.next), but any language designer knows
once some decisions are made there is no way to go back and revisit them.

If we allow for the possibility of a "clean break", then we can ask ourselves
how could it be done. IMHO, committees don't fare all that well in language
design. I think it would have to come from a single knowledgeable designer or
a group of closely aligned knowledgeable designers. I also think it would be
impossible to evaluate such a language without a real implementation. A real
implementation would have to be in a real browser. So, a Browser vendor that
employs experienced language designers seems like a good candidate to try a
clean break, and I'd be glad if it succeeds.

~~~
BrendanEich
Thumbnail of possible future (first is happening): ES6: modules and shallow
continuations; ES7: guards, contracts, event loop concurrency; ES8: macros,
parallel arrays (SIMD).

JS evolution disrupts the clean-break rationale.

Languages can change both surface and semantics. The open question I see is:
can JS become the VM (its source the "bytecode") to host many languages and
several approaches (none memory unsafe; no shared-memory threads).

We have lots of evidence for JS becoming the VM already, along with nay-sayers
who want a clean break.

I'm going with evidence over clean-break assertions until we hit a wall that
is either inherent in the language or emergent in the standards body and the
market. Again, this is why I am concerned about Google playing fair.

------
KamilTrebunia
Dart will not be 2x (or more) faster than JS. Dart will not be so much more
expressive and elegant than JS is.

Google would have to replace the whole stack (from HTTP to DOM to Dart to
IDEs) to make it really compelling, but I'm pretty sure they will give it a
shot.

Fortunately there is a competition:

Nobody will dedicate himself to Chrome Web Store and Google Web technologies
and miss out on future Facebook WebApp Store (or whatever Project Spartan
turns out to be) or future Apple AppStore (I believe in Apple's intelligence
and visionary and that they will realize potential of Open Web and Clouds in
time).

Android also is in trouble so unless Google will win the mobile market big
time it will get more fragmented and thus forcing _everybody_ to jump into
Open Web and not Google Web.

And then there's Mozilla - let's hope they can pull off some good piece
technology with their B2G and Firefox Mobile!

At least that's what I want to believe...

~~~
equark
> Dart will not be 2x (or more) faster than JS.

Why are you so sure of this? The people involved appear to be big believers
that dynamic languages can be extremely performant provided they are designed
with the VM in mind. LuaJit proves this out. A simple 1000x1000 matrix
multiply in LuaJit is already 20x (not 2x!) faster than V8 and on par with C.

[http://attractivechaos.wordpress.com/2011/01/23/amazed-by-
lu...](http://attractivechaos.wordpress.com/2011/01/23/amazed-by-luajit/)

<http://lua-users.org/lists/lua-l/2009-06/msg00071.html>

I think far too much emphasis is being placed on whether Dart replaces JS in
the browser. Google would gain a huge amount by having a performant server-
side language that can be tooled and compiled to JS for the client.

~~~
mraleph
> A simple 1000x1000 matrix multiply in LuaJit is already 20x (not 2x!) faster
> than V8 and on par with C.

You are using outdated measurements. Up to date results:

<http://attractivechaos.github.com/plb/plb-lang.png>

<http://attractivechaos.github.com/plb/>

The difference between V8 and LuaJIT is nowhere near 2x on matmul and comes
from differences in language features (no debugger interruption support for
generated code in LuaJIT2) and lack of certain optimizations (e.g. array
bounds check elimination) in V8 [matmul_v2.lua used for measurements relies on
ffi arrays which do not include bounds checks at all]. Code generated by both
compilers is roughly equivalent (invariants hosted out of the loop, temporary
double values are on xmm registers, etc). A bit more details:
[http://blog.mrale.ph/post/5436474765/dangers-of-cross-
langua...](http://blog.mrale.ph/post/5436474765/dangers-of-cross-language-
benchmark-games)

~~~
equark
Interesting, thanks. Do you have a guess on what the Dart means by "Dash is
designed with performance characteristics in mind, so that it is possible to
create VMs that do not have the performance problems that all EcmaScript VMs
must have." Where will a redesign likely see gains?

~~~
BrendanEich
JS has notorious optimization hazards such as holes in arrays
(Array.prototype[1] = "ha ha"; a = [0,,2]; ... a[i] for i=1 must find the
prototype element), prototype delegation in general, delete and default-
mutability, plus the eval of old and 'with' (respectively reformed in modern
impls and specs, and banned in strict mode).

These all add some cost in either runtime guards, static analysis burdens, or
a mix.

A new language could leave out most of these, but it would still want
inheritance. Then the question would be: how useful is mutability along the
inheritance chain, i.e. shadowing -- even if you remove 'delete'.

Beyond this, a new language _or_ a JS extension (this is what the Dash memo
rules out as un-possible, without evidence) could allow pinning down the shape
of objects, even to include machine types such as int32, etc. That would allow
for big speedups on certain benchmarks.

------
ryanisinallofus
"his is why I think cooperating in standards bodies is critical for web
interop and non-fragmentation. It necessarily implies less competitive content
languages at any given instant, but with consequent widest reach."

I think it's interesting he's admitting to standards bodies leading to
inferior languages but that the benefits include wide reach. I disagree. See
HttpRequest. I say let the browsers innovate at will and let the standards
bodies come in and standardize what people are actually using after the fact.

Shoot first, ask standards bodies later.

~~~
BrendanEich
"... he's admitting ..."? Hello, I'm here, and you're not deposing me, so drop
the lawyer talk.

Also, try to pay attention to the historical correlation of market forces: XHR
came in when Microsoft was a monopoly:

[http://en.wikipedia.org/wiki/XMLHttpRequest#History_and_supp...](http://en.wikipedia.org/wiki/XMLHttpRequest#History_and_support)

Even then, it was new and optional, and we cloned it into Mozilla (Opera
cloned it too). It was pretty simple compared to anything like Dart or NaCl's
Pepper APIs.

Ok, look where we are today: no monopoly power, but Google arguably acting
like one. That won't lead to reverse-engineering without a much less balanced
market.

First, the reverse-engineering costs of Dart are much higher than of XHR.

Second, the more balanced competition won't make any browser follow instead of
lead. We could indeed end up with two problems (three, counting JS), as just
happened with WebSQL and IndexedDB. Dart, and Microsoft's new language Phart,
say. :-P

Glib "shoot first, ask standards bodies later" is a recipe for fragmentation
and non-interoperation. Even if standards are written (years later, for XHR;
never for VBScript and ActiveX and a great many examples you conveniently
ignore), they don't offset the up front costs.

And here's the kicker: if you get your wish, there won't be one interoperable
superior language ruling the roost until that later standardization step, if
it even happens. If there's no monopoly or duopoly power structure, you'll
just have the "inferior" language (JS) and spotty support for the "superior"
one.

It seems to me that a lot of you "bring on our new overlords" boosters are
unaware of how HTML5 came about. It was not through one vendor shipping
proprietary code and standards bodies mopping up later. Study some recent
history.

~~~
ryanisinallofus
"First, the reverse-engineering costs of Dart are much higher than of XHR."

Does this matter if it's open source? Not being combative, I'm actually
asking.

"It seems to me that a lot of you 'bring on our new overlords' boosters"

Well shit. I definitely don't want to be one of those!

~~~
BrendanEich
Open source is usable only by some vendors. My Opera pals say they can use it
(I'd heard differently from others at Opera in the past). Microsoft, I'm told,
cannot -- they cannot even read open source. This is public knowledge, it came
out, e.g., as part of the IronPython project.

So Microsoft objected to WebSQL, since it depended on SQLite as source-code-
is-specification. Writing a spec for SQLite or Dart is very hard. SQLite is
>100KLOC in one .c file! Dart is at a guess bigger. Hence, reverse-engineering
is required.

Reading code at this scale doesn't tell you enough. Testing, with good
coverage, is required. Then you have to separate the over-specification due to
abstraction leaks and bugs, from the intentional specification. That's hard
work too, and while source code comments may provide clues, the source itself
does not say what's what.

"Well shit. I definitely don't want to be one of those!"

Sorry, I was not addressing you specifically, rather the (many, more than I
expected) people here and elsewhere who are asking for the new and good
monopoly to rewrite the web by itself with more awesome languages.

The IE monopoly with ActiveX and all that was so long ago, the new generation
did not live through it.

~~~
ryanisinallofus
"The IE monopoly with ActiveX"

I certainly remember and that's what your comment made me think of. It's not
QUITE the same thing as it is supposed to compile to js but yeah, I get the
comparison and would prefer to have no single-corporation overlords.

------
danmaz74
I'm afraid it's already too late to make suggestions, but I would be really
excited if Dart supported facilities to make unit testing an integral part of
the language, taking into consideration the interaction with the DOM. This is
something that would really help IMHO.

~~~
bzbarsky
> I'm afraid it's already too late to make suggestions,

Which was precisely the point of developing things this way. They don't want
anyone's suggestions; they want to force the thing that benefits _them_ the
most on everyone else.

------
ricardobeat
Classes :(

------
adgar
I hate to say it, because Brendan Eich is no blogspammer, but I feel like he
name-dropped Google Dart (Dash) as well-intentioned linkbait. It's mentioned
in one sentence and offers no new details or interesting discussion.

I agree with georgemcbay that he has reason to be disturbed by Dart's
appearance and the backing of Google/Chrome, but with no actual details, he's
just taking a quick shot at it while he can here.

~~~
BrendanEich
I took no shot at Dart because we all know nearly nothing about it.

My whole talk was about how competing browser vendors work together to
standardize and evolve JS. In that light, bailing to a proprietary move like
Dart is entirely relevant and not linkbait.

This is a non-technical, or really meta-technical point. Lots of JS and web
standards work is about techniques for solving technical problems, hence meta.

Any well-funded company with smart people on staff can "do better" for a given
point-function or language in the set of languages. On the web, such better-
is-better approaches won't get traction without being adopted by multiple
competing browsers.

The best way to get adoption is standardization. Forcing reverse-engineering,
open-washing as if that helps competing vendors more than a little (assuming
their hackers can even read the delayed-open source as a reference),
fragmenting web content are all "less good" in my view.

A browser with market power can try these tactics. They may backfire, or make
a messy "now you have two problems" world.

