Brendan Eich on Ecma TC39, JavaScript.next, and Google Dash

http://brendaneich.com/2011/08/my-txjs-talk-twitter-remix/

by mbrubeck • 15 years ago

138 121 15 years ago

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?

thepumpkin19793• 15 years ago

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.

StrawberryFrog2• 15 years ago

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.

SwellJoe3• 15 years ago

This was the original intent (to have many languages supported by browsers; not necessarily a single VM with many languages). It just never really materialized. By the time the web was ready for bigger apps that needed more software, Javascript was Good Enough for the purpose, and munging other languages into the browser was too much effort. JavaScript grew up alongside HTML and the DOM, making it uniquely qualified for building applications around HTML and the DOM. I think it's telling that Google is building a new language rather than modifying an existing one (though it does appear to be inspired by other languages).

DanielRibeiro• 15 years ago

Google's PNaCl is trying to promote this. I've talked about this a few weeks ago[1]. But until it gets widely deployed and accepted, it is just yet another standard[2] that will unify everything.

[1] http://bit.ly/phxe16

[2] http://xkcd.com/927/

azakai• 15 years ago

It's not even another standard - it's an experimental implementation.

LeafStorm• 15 years ago

The main problem with common VMs for multiple existing languages is that often the semantics of the language are heavily coded into the VM. For example, Parrot's core opcodes mimic Perl's behavior of "Type coercion for everyone, the string "0" is false!" There are a lot of other issues as well, and while they are certainly solvable, the resulting VM would be very heavyweight. If you want to design a VM that runs multiple languages, often you have to design the languages around the VM.

chromatic2• 15 years ago

Parrot's core opcodes mimic Perl's behavior of "Type coercion for everyone, the string "0" is false!"

That's true only for the intrinsic STRING type. Language-specific strings supply their own boolean semantics.

mbrubeck• 15 years ago

Brendan has previously talked about some obstacles to a bytecode/VM-level specification, and some advantages of specifying the browser language at the source level rather than at the bytecode level:

http://news.ycombinator.com/item?id=1893686 (see comments by BrendanEich and others)

http://www.aminutewithbrendan.com/pages/20101122

http://www.hanselman.com/blog/JavaScriptIsAssemblyLanguageFo...

_sh• 15 years ago

The reason you won't see a bytecode VM replace Javascript is because bytecode is either interpreted (slow) or JIT-compiled (complicated but faster). If you go for speed and JIT-compile bytecode, why not just compile your source and dispense with bytecodes altogether (as V8 has done)? This gives other runtime implementers the freedom to choose whether to create an interpreter, compiler, or some other execution mechanism, and the programmers the freedom to code at a high-level.

Bytecode, as distinct from object code, is on the way out. Consider Javascript a portable high-level object code and move on. If you want other languages, compile them to Javascript. Semantic affinity between source language and execution environment (e.g. is "0" false, as mentioned elsewhere) is an issue you'll need to address regardless of whether you're using bytecode.

Also, don't underestimate the power 'view source' had in making Javascript perhaps one of the most widely-adopted programming languages in the world.

jeske• 15 years ago

The trouble with this approach is that the Javascript prototype-based object model is somewhat incompatibile with precompiled-library loading. Loading Javascript (Even in bytecode form) requires running the code. Modern desktop/server software leverages tons of code via shared-libraries with fast startup times, but Javascript webpages have horrible startup times with only tiny amounts of library code. This problem is important to fix or the javascript ecosystem will be prevented from effectively building higher and higher leverage software layers.

In addition, Javascript's abstractions are based on relatively slow mechanisms such as dynamic-hashes. This make it difficult if not impossible to get C/Java/C# like performance out of it even with a JIT. You can build fast dynamic hashes out of structs, but you can't really build fast structs out of dynamic hashes.

equark6• 15 years ago

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.

wavephorm2• 15 years ago

Google is clearly priming to do a Microsoft-style embrace-and-extend in a big way. Between Chrome, V8, NaCL, WebGL, Android, they have a wide range of technologies that they could begin steering away from standards.

ender7• 15 years ago

But...why? Google makes money selling ads. It doesn't make money selling you support contracts for software that you've been locked into.

From what I can tell, Android exists so that Google isn't at the whim of Apple. The big G's greatest fear is that iPhones become the defacto smartphone, and Apple has the power to cut them out of their platform (by banning Google's ad networks and by setting the default search engine to Bing). I doubt the Android platform will ever really make money for Google.

equark6• 15 years ago

Except that they have a monopoly position in none of those domains. Microsoft used their power to protect their monopoly. The Dart document itself says the number one reason for Dart is to protect Google's massive bet on the web platform. It's easy to see how Microsoft or Apple could seriously undermine Google by keeping the web platform second rate, which is certainly within their power given current browser marketshares.

MatthewPhillips• 15 years ago

Not all of Dart/Dash can compile to JS.

equark6• 15 years ago

Given that it is also a server side language this is not surprising or worrying. It's no different than node.js specific code that doesn't work in the client. I think it's just inherent to heterogenous environments. If they can do better than gwt I think they'll be fine.

BrendanEich36• 15 years ago

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

magicalist2• 15 years ago

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

equark6• 15 years ago

Thanks for the expanded comment on Dart.

I don't fear forking the developer community in terms coffeescript vs. GWT vs. Javascript vs. Dart-to-JS. The web development experience, from front-end to back-end and at the language and framework level, is already incredibly fragmented. More higher level options that unify the front-end and back-end seem like a win for the web stack.

I agree that there is virtually no chance that Microsoft or Apple will adopt the Dart VM. So the real question is whether the Dart-to-JS compiler combined with the Dart VM on the server side is compelling. This sounds to me like an improved GWT with server-side built in.

The controversial difference is the Dart VM will be in Chrome, enabling Chrome to deliver experiences that other browsers presumably cannot. I see your worry about "works only in Chrome". But this will only come true if Dart-to-Javascript delivers a much, much worse experience. If that's true, there is a problem that other browsers need to confront not avoid. Until they do the Dart VM will presumably be like Flash -- a necessary evil that makes clear the limitations of current standards. Presumably Dart will always compile to whatever the best target is, including whatever comes out of TC39.

haberman• 15 years ago

So somehow Google is going to become a monopoly because Apple and Microsoft will voluntarily decline to support a new technology that Google will presumably license freely (as with NaCl)?

I don't even know if I like Dash or not, but how is this move predatory? Did you approach a standards committee or consider the philosophical balance of your competitors before creating JavaScript and shipping it in Netscape? You don't get new good ideas from committees -- just look at the disaster of the last 10 years of the W3C.

espadrine• 15 years ago

I don't think Dart will beg other browsers to comply to their will of adding a VM. On the other hand, I find it more likely that, in a whole year's time, the people behind Dart thought about NPAPI. They may very well produce a plugin that everyone will download.

That would make Dart the new Flash, but that's the price to pay for a serious cross-browser Dart.

Of course, that would also make Dart second-class citizen in the web platform, and I guess Dart people don't want that. However, I find it hard to believe that they hoped all browser vendors would bow before the new programming language overlord.

Now, making browsers speak Dart will be the easy part, I think. The Enterprise will have a hard time accepting a brand-new language blindly when they have just learned that C# is slowly losing Microsoft backing.

Programming languages all make mistakes, and Dart will be no exception; they had a full year and bright engineers, but that rule is sacred. No matter how hard they advocate the niceties of the language (which I assume will be closures (again!), the full funarg, yet another garbage collector, optional typing, type inference, bignums, modules, event-oriented programming, maybe lazy evaluation) but I know many programmers that won't bother learning any programming language that falls too far from the C-like tree, especially if it has odd features, especially if there are mistakes in the way those features work together.

I have seen many bright programming languages that never found any serious adoption. Scheme would have been very interesting in real work environments; Perl6 has many interesting features, but is too late and slow; Haskell still has potential, but I don't see it suddenly go past Objective-C, C# or Java in popularity.

I would love Dart to find success. But this is not a dream world. The platform it seeks to conquer, the competition it must overcome, the tender age it has: Dart is so very late for such a challenge.

bobbydriscol• 15 years ago

Now that Apple has successfully marginalized Flash as a cross platform development environment the browser fragmentation will ramp up and we'll see more of this type of behaviour rather than less. Apple didn't start this fragmentation but they are committed to ensuring that the web is not a level playing field with technology segmentation like canvas and css ES. Microsoft has always tried to fragment the market with IE. Take for example the current version of web based Outlook which only functions at full power in the IE browser, otherwise you get the 'lite' incarnation.

And now that Google is joining the fray we're concerned? Not at all. There will always be applications that only run on one browser (or operating system like Android). This same methodology will be incorporated by Google for gmail or any of their other services which will allow them to control which environment gets the best features and allow them to leverage their technologies effectively when their competitors are already doing the same thing.

karussell• 15 years ago

Just one image for reference :) http://3.bp.blogspot.com/-GBSGBbc9UtA/TmexwLaJN9I/AAAAAAAAAK...

chintan• 15 years ago

Wow. Just wow!

Goes to show how "Open" the corporations are. Don't blame them, but just wow!

danmaz74• 15 years ago

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.

kmmbvnr• 15 years ago

Google's Go have unit testing in build-in libraries. Hope Dart developers will not forget about testing also.

bzbarsky5• 15 years ago

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

rafaelferreira• 15 years ago

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.

BrendanEich36• 15 years ago

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.

ricardobeat• 15 years ago

Classes :(

adgar2• 15 years ago

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.

BrendanEich36• 15 years ago

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.

gruseom5• 15 years ago

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.

BrendanEich36• 15 years ago

The comparison to VBScript is not technical at all. It is about single-vendor control.

Your item 1 is obviously problematic. If Dart and JS have close semantics, it's just a transpiler like CoffeeScript, which intentionally sugars JS semantics with leaner syntax.

But this does not match the leaked info and hype about Dart, and even then, such warm beer still requires you to run a tool over your primary source, which costs adoption. Lots of languages already contending in this transpiling space.

More likely, a Dart-to-JS compiler (making non-local transformations) and a JS-implemented Dart runtime (to support the novel runtime semantics, e.g. new numeric types) will be required.

This means a worse user experience in browsers that don't have the native Dart VM, because performance will lag (especially depending on the new numeric type details) and bug-for-bug compatibility will be lost.

The native VM will be the super-fast source of truth. The compiler/runtime will be a stop-gap. This brings us back to the standards table, unless the idea is to corner the browser market. See

https://news.ycombinator.com/item?id=2983157

under "On Dart: ..." about what the standards table would look like if it is anywhere near today's mix of browser vendors and other interested parties.

bzbarsky5• 15 years ago

#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?

gruseom5• 15 years ago

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

nxn2• 15 years ago

The ironic thing about this scenario of ActiveX being required by Gmail is that XHR sort of has its roots in ActiveX -- that is, before Mozilla and others had to replicate it to remain competitive.

ryanisinallofus3• 15 years ago

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

BrendanEich36• 15 years ago

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

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.

ryanisinallofus3• 15 years ago

"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!

KamilTrebunia• 15 years ago

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

equark6• 15 years ago

> 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://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• 15 years ago

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

Brendan Eich on Ecma TC39, JavaScript.next, and Google Dash

Related Stories