Google has released Dartium, a Chromium build with a Dart VM

Google has announced the availability of Dartium, a new Chromium build that …

Google has announced the release of an experimental Chromium build that includes an integrated Dart language runtime. The browser, which Google calls Dartium, is being made available as a technical preview for the benefit of developers who want to see how the Dart virtual machine works in a browser.

Dart is a new programming language that Google is developing for client-side Web scripting. The language has a more conventional object model than JavaScript and optional support for static typing, features that Google claims will allow it to be faster, safer, and more conducive to tooling than JavaScript. Much like Microsoft's VBScript, Dart is a nonstandard client language that is developed and supported by a single vendor outside of the Web standards process.

Google intends to include a Dart virtual machine in Chrome, but the language seems unlikely to attract the support of other browser vendors. Google is developing a compiler that will allow Dart code to be converted into JavaScript so that it can run in browsers where Dart is not supported. This "transpiler" approach is similar to how the CoffeeScript convenience language is used today.

Dartium, which includes an integrated Dart virtual machine, is the first browser that can run Dart code that hasn't first been converted to JavaScript. It can load raw Dart code from a conventional script tag. Dartium, which can be downloaded from the Dart language website, is currently available for Mac OS X and Linux. Google says that a Windows build is coming soon. For more details, you can refer to the official Google Code blog.

It seems to me that Google might heartily suggest adoption of Dart in Firefox.

Ugh, why do people keep coming up with this? That was not a donation, it was a business transaction, and Mozilla would never respond to that kind of maneuvering anyways. Mozilla employees have in fact been the *most* vocal in stating that they won't include a dart vm any time soon.

> Much like Microsoft's VBScript, Dart is a nonstandard client language that is developed and supported by a > single vendor outside of the Web standards process.

Kind of like Javascript too?

Dart has an open spec, two open source Dart-> compilers, an open source VM, and Google has said they intend to bring Dart to a standards body. Most important is the fact Dart runs on all modern browsers via the compiler.

It's not at all like VBScript, which had no open spec, no open implementation, and couldn't compile to Javascript.

It seems to me that Google might heartily suggest adoption of Dart in Firefox.

What I was specifically referring to was the discussion about Dart in the upstream WebKit project: https://lists.webkit.org/pipermail/webk ... html#18775 The WebKit community rejected a proposal to create a Dart integration branch on the basis that it conflicts with WebKit's mission of being a standards-focused rendering engine.

Mozilla, which is completely committed to the open web, is even less likely than upstream WebKit to endorse Dart. Google's financial relationship with Mozilla really doesn't give them any leverage over what functionality is supported in Firefox. If Google threatened to withhold funding unless Mozilla supported it (and I truly doubt Google would ever do something like that) Mozilla would find new partners.

Mozilla employees have in fact been the *most* vocal in stating that they won't include a dart vm any time soon.

The WebKit maintainers already refused adding Dart support on grounds of not being a web standard, not wanting to fragment the web any further and not wanting the extra maintenance burden for the changes required to WebKit in order to support multiple scripting languages. Same reasoning goes for Mozilla, especially because they don't see Dart solving any problems that either couldn't be solved in a future version of JavaScript or that warrant the pains of having to maintain two different scripting engines. AFAIK Opera also didn't show any interest in it.

So Google's only hope left is for Chrome to gain monopoly-level market share to simply force the remaining browsers into compliance.

That was not the proposal. The proposal was for a change in the DOM bindings so that a browsers could have multiple active VMs. Webkit already allows alternative VMs to be integrated, just one at a time. There was not initially a proposal for a Dart branch.

Quote:

Quote:

Quote:

on the basis that it conflicts with WebKit's mission of being a standards-focused rendering engine.

Which is pretty hypocritical considering that Apple has a history of adding non-standard elements to CSS and HTML. See Canvas.

So Google's only hope left is for Chrome to gain monopoly-level market share to simply force the remaining browsers into compliance.

The other option is to build something excellent and to maintain compatibility with modern browsers through the Dart-JS compiler.

Remember, Google already heavily uses GWT, which runs Java through a cross compiler and has very good browser support. Dart is a much better option than GWT, so even if it just supersedes GWT eventually it will have served it's purpose of making it easier to build fast, complex web apps with large teams. Google needs that, even if everyone else doesn't, and the Dart compiler ensures that Dart can be a great tool without help from other vendors.

It seems to me that Google might heartily suggest adoption of Dart in Firefox.

What I was specifically referring to was the discussion about Dart in the upstream WebKit project: https://lists.webkit.org/pipermail/webk ... html#18775 The WebKit community rejected a proposal to create a Dart integration branch on the basis that it conflicts with WebKit's mission of being a standards-focused rendering engine.

Oliver Hunt did give an impassioned message about this (which I have to point out is somewhat ironic considering the recent webkit prefix hubub is *about* webkit including non-standard prefixed features, and Apple especially being uninterested in getting some mobile safari features even on the standards track).

Private branch of webkit, then report back with results and hard data. This is what *almost* everyone does for major changes, including possible standards-track features like CSS shaders, css3 regions, WebCL, etc etc. Web doom aside, this was the correct move for Webkit as an open source project.

With all the scepticism, Dart is going to need to prove itself to be hugely faster than Javascript in all situations in order to gain any traction. Twice as fast won't do it. If it's ten times as fast, people might have a bit more trouble saying no.

The issue I have with the controversy over this is that the web has changed since the days Javascript was first standardised. When JS came about it was 1) a vendor-implemented extension first and 2) browser technology and client computers weren't powerful enough to do the thing we do today.

My issue is that as a developer I use a wide variety of tools to do my job, I use shell-script for automating common tasks, PHP for web development, C/C++ (or now D) for performance things, perl/python/ruby for more complex tasks that shell-script can't handle. When we get to the browser however, I use Javascript. Thats it, it doesn't matter whether I want to write a complex single-page web app that is driven by Ajax or want to auto-refresh my stats counter, both javascript. Need fast code for calculations on the browser, Javascript, want to animate something, javascript, javascript, javascript, f***ing javascript. On no other platform am I this limited! Its like demanding everybody to use C for everything, for all time. Sure its possible, but its damn hard in a lot of cases, and you're going to write some pretty shocking code to get around some of the limitations.

Maybe Dart isn't the answer, but how about an open-standard intermediate language for browsers that any language can target, something that reduces operations down to their most basic. We need a machine code for the browser, or at least an assembly for the browser. Jeff Atwood suggests that Javascript is the assembly of the web, but it isn't designed for it, we need something that allows people to make a better choice of language, something standardised, low-level, and extensible. Something that optimizers can, well, optimize, without breaking things. Once you have something like that in place, all you need is an open spec, minor modifications to the way browser interfaces are defined and each language (existing or new) can just have a compiler and standard library that targets that interface.

Sure, it would mean work for the browser devs initially, but if the spec was stable, once in place it wouldn't need changing much, so the maintenance cost is minimal.

There are some downsides and limitations, but if we can work around it, at the lower level, it will open up a massive amount of freedom for developers. Which means that we can write much better apps.

Mozilla employees have in fact been the *most* vocal in stating that they won't include a dart vm any time soon.

The WebKit maintainers already refused adding Dart support on grounds of not being a web standard, not wanting to fragment the web any further and not wanting the extra maintenance burden for the changes required to WebKit in order to support multiple scripting languages. Same reasoning goes for Mozilla, especially because they don't see Dart solving any problems that either couldn't be solved in a future version of JavaScript or that warrant the pains of having to maintain two different scripting engines. AFAIK Opera also didn't show any interest in it.

So Google's only hope left is for Chrome to gain monopoly-level market share to simply force the remaining browsers into compliance.

I don't think this will do it, actually.

IE had monopoly-level marketshare, and VBScript never got implemented outside of IE. (ActiveX support never made it to a third-party browser either, AFAIK.) Web designers never saw a compelling use case for an alternative, platform-locked scripting language--of course, why would they?

Google's only hope would be for Chrome to gain monopoly-level market share, and after that is done, convince a sizable percentage of websites to switch to Dart without enabling cross-compilation into Javascript (but again, why would they?). Or abandon the Javascript cross-compilation feature and let it fall into disrepair after a sufficient percentage of websites moved to Dart...?

Jeff Atwood suggests that Javascript is the assembly of the web, but it isn't designed for it, we need something that allows people to make a better choice of language, something standardised, low-level, and extensible. Something that optimizers can, well, optimize, without breaking things. Once you have something like that in place, all you need is an open spec, minor modifications to the way browser interfaces are defined and each language (existing or new) can just have a compiler and standard library that targets that interface.

You can get great speed improvements when you focus on a limited subset of Javascript. Every modern browser now includes features that let Javascript run much, much faster when your code limits the feature sets it uses. For instance, they all notice when you have a bunch of objects with an identical structure, and optimize it. Or when you use the new packed array types.

Mozilla employees have in fact been the *most* vocal in stating that they won't include a dart vm any time soon.

The WebKit maintainers already refused adding Dart support on grounds of not being a web standard, not wanting to fragment the web any further and not wanting the extra maintenance burden for the changes required to WebKit in order to support multiple scripting languages. Same reasoning goes for Mozilla, especially because they don't see Dart solving any problems that either couldn't be solved in a future version of JavaScript or that warrant the pains of having to maintain two different scripting engines. AFAIK Opera also didn't show any interest in it.

So Google's only hope left is for Chrome to gain monopoly-level market share to simply force the remaining browsers into compliance.

Exactly. And I wish I could say that wasn't likely, but it just might happen: Chrome is rising fast on desktop and is now on Android too, where it will become the default browser.

#1 mobile OS browser + #1 desktop OS browser (soon, at current rates) will get Google close to monopoly power. Then it won't matter if WebKit and Mozilla (and Microsoft and Opera) oppose Dart, Google will forcefully make it a defacto standard.

Mozilla employees have in fact been the *most* vocal in stating that they won't include a dart vm any time soon.

The WebKit maintainers already refused adding Dart support on grounds of not being a web standard, not wanting to fragment the web any further and not wanting the extra maintenance burden for the changes required to WebKit in order to support multiple scripting languages. Same reasoning goes for Mozilla, especially because they don't see Dart solving any problems that either couldn't be solved in a future version of JavaScript or that warrant the pains of having to maintain two different scripting engines. AFAIK Opera also didn't show any interest in it.

So Google's only hope left is for Chrome to gain monopoly-level market share to simply force the remaining browsers into compliance.

Exactly. And I wish I could say that wasn't likely, but it just might happen: Chrome is rising fast on desktop and is now on Android too, where it will become the default browser.

#1 mobile OS browser + #1 desktop OS browser (soon, at current rates) will get Google close to monopoly power. Then it won't matter if WebKit and Mozilla (and Microsoft and Opera) oppose Dart, Google will forcefully make it a defacto standard.

Imagine just a few months after that when they have 200% of the browser market! What are you guys, industry analysts?

Even if Firefox dropped off the planet, you would still have essentially unkillable marketshare from Mobile Safari and whatever portion of Windows users don't switch or don't want to switch from IE. I think current trends actually suggest (barring a browser vendor ceasing operations or some other major, currently unforeseeable event) it's not possible for Chrome to even take a majority, let alone enough of the market to call it a monopoly.

More importantly, how well will the Dart-to-JavaScript tools work, and how well will the resulting code run? That's their only path to widespread adoption, even early adoption, in my opinion, so that final JS code needs to be tight.

To my knowledge CoffeeScript never had the ambitions to replace JavaScript as the client-side scripting language of the web. It just offers a different (arguably nicer) syntax but has the same semantics as JavaScript. For Google the JS->Dart compiler is clearly only stop-gap solution until Dart is supported by the other vendors as well otherwise they wouldn't put all the resources into developing a new VM.

Apple will never adopt dart...and if you saw how apple killed flash by not supporting it anymore then its easy to see how big that one fact is.

Personally i like what google is doing (even if it seems very 90's microsoftian)...i just hope that some of dart gets wrapped into some js technology.

Its already supporter on Apple with Mac Chrome, but with Flash you either had it or didn't. Here developers can develop everything i Dart, and browser that doesn't support it will get JavaScript and the site will work fine. So in time Chrome would either gain traction being a lot faster or competition will pick up Dart to play on the same field.

"The disadvantages of bytecode", "There is no single bytecode to rule all languages". Guess what, there isn't a single programming language to rule all others either. What we do have today, however, is a much larger diversity of languages running on the CLR, the CLI or LLVM that there ever were languages running on top of Javascript.

"There is no common ground between browsers". So what? Why should we look at how browsers do Javascript today to decide on a bytecode? A good bytecode designed to bring diversity to the web defines an abstract computer that can efficiently implemented on top of real computers, it isn't molded around how Javascript is done today.

"Bytecode is inflexible". And Javascript isn't? Give me a break. "It ties you to the current version of the language and to implementation details such as how data is encoded". You just have to be kidding me. We can't funking fix Javascript, thanks to the recent goal of total backwards compatibility (old Javascript must forever remain valid). We can't change var and must add let instead and live with both, because of such compatibility, and you're telling be bytecode is the problem? We can't have integers and floats because to Javascript it's all doubles, but we're not tied today? Byte code is the problem here!?

"Source code is not that bad – it’s meta-bytecode". So basically, Javascript is not so bad as a bytecode. This is something I can relate to. But the if Javascript is a bytecode (and if you look at Gmail's source that's certainly it), why add some lame syntactic sugar such as comprehensions and classes, and force one object model on everyone? Why don't we add the stuff that really matters, like integers?

The conclusion is all wrong. Javascript as a bytecode is at best a mediocre inflexible bytecode. But I guess it's telling that the best way to defend a programming language supposedly designed to be used by humans, is to show us the gzipped, minified, ofbuscated source code of Gmail as an example of why we don't need any freaking bytecode.

I think that Dart might also be the attempt of Google to create a platfomr for they enterprise software, namely Google Apps. In this way they would be offering, practically, a preferred VM on which to run their apps.The approach is quite smart too if you compare to MS Silverlight:MS created SL as a VM that can run in our browser. They created a new Markup Language for UI (XAML) and they integrated with the tools they were selling (Visual Studio for developing, Expression for UI design). Google does not sell tools and with HTML 5 they can do (mostly) all the UI they can, therefore they build a platform that uses an advanced scripting language (Dart) plus an HTML rendering engine.I do not think that it will change the web (at least not in the short term), but it might be a quite nice platform to develop cloud applications on (Chrome Store anybody?).

Chrome also concurred to push the web forward: before Chrome the development of new web technologies was slower and the browser was seen as any other piece of software that you installed and you could completely manage by yourself. After Chrome, the browser (Firefox too) became more as a "fluid" platform that the browser provider can update whenever he wants/needs.

So at the end I think that Dartium could be an interesting niche product that will make people experiment new things for the web in an easier way than NaCl (that is native C code, after all).

Guess what, there isn't a single programming language to rule all others either.

The blog post does not argue that JavaScript is perfect. The section you quote merely argues that there is no such thing as perfect bytecode. Which has to be said, because people tend to not be aware of it. It’s not a very strong anti-bytecode argument, just one that lessens a pro-bytecode argument. It’s the general tone of the article: Bytecode is not as perfect as people think, source code is not as bad. JavaScript follows the school of “worse is better” – what we have now works quite well and it would take a very long time to duplicate it, especially given all the security work that has gone into JavaScript engines and all the JavaScript source code that has already been written.

kruzes wrote:

What we do have today, however, is a much larger diversity of languages running on the CLR, the CLI or LLVM that there ever were languages running on top of Javascript.

I’m curious: Are you really sure that’s true? There is an awful lot of languages compiled to JavaScript these days, including LLVM bytecode (crazy, but seems to work).

In the remainder of your entry, you argue the school of “better is better” (which has many valid arguments!). There is no doubt that Dart fixes many JavaScript quirks. The story of evolving JavaScript is probably not as bad as you think: For "var versus let", there will probably be warnings or errors if one mixes both, so one can just forget about var. For "integers and floats", there are plans for fixing that, V8 et al. already do a very good job of optimizing under the hood. JavaScript is not a big language, so it is remarkably fixable. I doubt that JavaScript proponents and Dart proponents will ever come to an agreement, because the languages are fundamentally different in style. JavaScripters love JavaScript’s dynamism, including the ability to directly create objects, Darters like how clean everything is and how statically predictable (again, for good reasons). Dart is not a cleaned up version of JavaScript, it is a cleaned up version of Java. While Dart approaches its version 1.0, JavaScript is also being improved. Following the progress of ECMAScript 6, my guess is that you will hate it much less than you think.

Actually, Dan Gohman argues in [1] that LLVM IR is not very well suited for building a platform because LLVM is not a virtual machine (the name stuck due to historic reasons) and therefore LLVM's intermediate language is closer to being a compiler IR than platform neutral bytecode.

I've read convincing arguments to the contrary if only because of the issue with covariant arrays which apparently even the Java developers regarded as a mistake in hindsight and there are trivial examples which illustrate the problem (cf. [2]).

JavaScript is not a big language, so it is remarkably fixable. (...) Following the progress of ECMAScript 6, my guess is that you will hate it much less than you think.

No, it's not. Scheme is (was) a small language. Forth is small. Javascript is not. It's a huge inconsistent kludge that's well beyond fixing. It has kludges on every level, and were only piling a metric tone more.

It has optional semicolons. It has null and undefined. It has an inexplicable concept of truth. It already has two equality operators, and will add a third one (maps and sets will use it, arrays will not). It has var and let (with const behaving like let, not var). It has __proto__ on track to being accepted, whereas with is on the way out. It changes syntax and run-time semantics based on a string literal. Etc.

Javascript is not a small language. It's a huge language, full of useful stuff everyone derides because someone said so, and of new and inconsistent ways of doing things that never quite replace the old ways of doing things. And growing it through new kludges (and string literals) is an explicit goal, and seen as the best way to ensure forward compatibility.

Javascript needs to decide what it is and is not, and what it intends to be. If its intent is to become the "assembly" of the web, the wrong things are being added to it right now. Destructuring, iterators, generators and comprehensions simply don't help. If it intends to become a language for humans to use, constantly adding new inconsistent ways of doing things doesn't help at all. PEP 20 comes to mind

"The disadvantages of bytecode", "There is no single bytecode to rule all languages". Guess what, there isn't a single programming language to rule all others either. What we do have today, however, is a much larger diversity of languages running on the CLR, the CLI or LLVM that there ever were languages running on top of Javascript.

Do we? We can run C, C++, Objective C, Java, C# in JavaScript - these are used in large real-world projects on the web today. We can also run Python, Ruby and Lua in JavaScript with some limitations (no one has focused on optimizing them, just getting them to run).

That's as good as the CLR or JVM I believe. (Can either of those run regular C++?)

As a Linux user I am unaccustomed to reading things such as this: "currently available for Mac OS X and Linux. Google says that a Windows build is coming soon". My world feels a little off kilter at the moment....

That's as good as the CLR or JVM I believe. (Can either of those run regular C++?)

Of course they can. The same ass-backwards way Javascript can.

But what is your point then if JavaScript has already been proven to be workable compilation target? And unlike your hypothetical byte code for the web, JavaScript already exists and is the most widely deployed language on the planet.

But what is your point then if JavaScript has already been proven to be workable compilation target? And unlike your hypothetical byte code for the web, JavaScript already exists and is the most widely deployed language on the planet.

My point is very simple, and has been stated repeatedly.

If being the "assembly" of the web is the designated future for Javascript, don't complicate it unnecessarily with stuff that it doesn't need to accomplish that goal. Focus on adding stuff that helps this specific use case. Mostly, a module system that allows for separate compilation and dynamic linking of libraries, and better ways to work with static or inferred primitive types. Bonus points if you standardize stuff similar to #line, and ways to debug transpiled languages. Javascript is not optimal for this, but it works and it's already here. Obviously, if you go down this road, your Javascript will no longer be human readable.

If being a good programming language for us humans to use is the goal, stop adding inconsistent stuff to the language. Do a module system as well. Then come up with a way to version the language everyone can agree to (no "use strict" string literals, please). Then, keeping the object model the same (so that modules written in different versions of the language can interoperate), evolve the language fixing what's broken instead of constantly adding different inconsistent ways of doing things.

Unfortunately, the priority is not the module system. If you look at Javascript since 1.6, the priority has always been syntactic sugar. But creating incompatible versions of Javascript while criticizing proposed replacements is Eich's thing.

Java has NestedVM and Cibyl (both use MIPS instead of LLVM as a target). NestedVM was used to produce the "pure Java" SqliteJDBC driver.

AS3 for instance has Alchemy (this one uses LLVM).

The CLR can me made to run subsets of unmanaged C/C++. It also makes it easy to interface with native code. And with mixed-mode assemblies you can freely mix managed and unmanaged C++ pretty liberally on Windows. Given all the above, the incentive to build a similarly "safe" way of running C/C++ code on the CLR has been pretty low. You can always combine NestedVM+IKVM with good results, tough.

Javascript definitely has an identity crisis. It's not a semantically rich language without frameworks or compilers on top of it, but it also has shortcomings and inconsistencies as a runtime target language.

I wish that Javascript were more along the lines of Lua: a lightweight dynamic namespace abstraction based on hash tables with a standard bytecode and text syntax, flexible enough to express arbitrary high-level language semantics, simple enough to implement very efficient runtime engines.

If being the "assembly" of the web is the designated future for Javascript, don't complicate it unnecessarily with stuff that it doesn't need to accomplish that goal.[...]

If being a good programming language for us humans to use is the goal, stop adding inconsistent stuff to the language.

The problem I have with this reasoning is that JavaScript does not exist in a vacuum, far from it. JavaScript is actively used for development by probably millions of developers today and cutting them off of any improvements to the language and telling them to use something else (which compiles to JS) is very unrealistic in my opinion. On the other hand JS is good enough as a compilation target for those who want to use an alternative and there are plenty already (though some better supported than others as kripkenstein noted). What you propose is actively alienating either group and I don't regard academic indignation a good enough reason for that given that the system works despite some of its warts.

But what is your point then if JavaScript has already been proven to be workable compilation target? And unlike your hypothetical byte code for the web, JavaScript already exists and is the most widely deployed language on the planet.

My point is very simple, and has been stated repeatedly.

If being the "assembly" of the web is the designated future for Javascript, don't complicate it unnecessarily with stuff that it doesn't need to accomplish that goal. Focus on adding stuff that helps this specific use case. Mostly, a module system that allows for separate compilation and dynamic linking of libraries, and better ways to work with static or inferred primitive types. Bonus points if you standardize stuff similar to #line, and ways to debug transpiled languages. Javascript is not optimal for this, but it works and it's already here. Obviously, if you go down this road, your Javascript will no longer be human readable.

If being a good programming language for us humans to use is the goal, stop adding inconsistent stuff to the language. Do a module system as well. Then come up with a way to version the language everyone can agree to (no "use strict" string literals, please). Then, keeping the object model the same (so that modules written in different versions of the language can interoperate), evolve the language fixing what's broken instead of constantly adding different inconsistent ways of doing things.

Unfortunately, the priority is not the module system. If you look at Javascript since 1.6, the priority has always been syntactic sugar.

The next version of JavaScript will include Harmony Modules. The main reason this didn't happen before is that it is a big change, and only recently did the standards process really pick up with support from all major browsers (even Microsoft). But it is happening now, expect support in Firefox and Chrome around this summer and other browsers hopefully not long after. The module system allows for separate compilation modules which will allow both optimizations and further language improvements in a much better way than now.

JavaScript is being developed with both of the goals you mentioned, both a good language for human-written code and as a target for compilation. Some JavaScript will be readable, some will not. It's harder to support both, but it isn't impossible and both use cases are crucial for the web.

kruzes wrote:

kripkenstein wrote:

I am honestly curious, can you point me to those projects?

Java has NestedVM and Cibyl (both use MIPS instead of LLVM as a target). NestedVM was used to produce the "pure Java" SqliteJDBC driver.

AS3 for instance has Alchemy (this one uses LLVM).

The CLR can me made to run subsets of unmanaged C/C++. It also makes it easy to interface with native code. And with mixed-mode assemblies you can freely mix managed and unmanaged C++ pretty liberally on Windows. Given all the above, the incentive to build a similarly "safe" way of running C/C++ code on the CLR has been pretty low. You can always combine NestedVM+IKVM with good results, tough.

I wish that Javascript were more along the lines of Lua: a lightweight dynamic namespace abstraction based on hash tables with a standard bytecode and text syntax, flexible enough to express arbitrary high-level language semantics, simple enough to implement very efficient runtime engines.

Precisely. Lua does one thing very well: tables. Namespaces, objects, classes, collections are all just tables. It's a small, but powerful, language.

Another interesting example is Python. Python is nice, but a much bigger language, and was collapsing under its own weight. This was recognized by its creators, so they decided to fix what was broken. It will probably take a decade to get Python 3.x to replace 2.x. There had to be parallel releases to ease the transition. But it was entirely worth it.

No one intends to do the same with Javascript. Versioning the language is perceived as being almost as bad as allowing alternative languages (Dart). So, since Javascript already isn't very consistent and we can't fix it, we simply keep pilling on the inconsistencies.

What sense does it make to have Set and Map in Javascript be based on egal (is and isnt), while Array keeps using ===? Does it even make sense to add a third equality operator? Will it make life easier for compilers? Will it make life easier for those learning the language? Will it make life significantly easier for advanced users? And why three when we could have four? Can't anyone think of a forth way of doing equality? Maybe an equals method, and some other collections that will use that one?

kripkenstein wrote:

The next version of JavaScript will include Harmony Modules. The main reason this didn't happen before is that it is a big change, and only recently did the standards process really pick up with support from all major browsers (even Microsoft). But it is happening now, expect support in Firefox and Chrome around this summer and other browsers hopefully not long after. The module system allows for separate compilation modules which will allow both optimizations and further language improvements in a much better way than now.

Will it really? Let's hope so. Firefox as done three Javascript revisions since ES3 and started by adding the cruft. And Chrome has now started doing the same on the path to ES6. ES5 really helped fix some of the inconsistencies in ES3, but now that that's done were introducing more of those for ES6. And everyone's implementations are focusing on the syntactic sugar, the operators, the libraries, etc. Because it's easier? Well, it's been at least seven years since we've started doing large-scale client-side web-applications, and it's hard not to loose hope.