Google’s bid to fix Javascript, Dart, is ready for the real world

Dart SDK’s first developer-ready version is now available.

A year ago, Google unveiled a programming language called Dart in an attempt to fix what’s wrong with JavaScript. The hope was to eventually “replace JavaScript as the lingua franca of Web development."

At the time, it was just a technology preview, more useful for people interested in developing Dart itself than for those interested in developing applications with Dart. That’s not to say developers couldn’t build with Dart, but the language needed a complete set of development tools to get a sniff of the mainstream. And that’s exactly what Google delivered today, with what it calls the “first developer-oriented version of the Dart SDK.”

The key improvements and features, according to Google software engineer Lars Bak, are as follows:

• A faster Dart Virtual Machine that outperforms even V8 on some Octane tests

• A new Dart to JavaScript translator that generates fast and compact output

• An HTML library that works transparently on modern browsers

• A library to interoperate with JavaScript code

• An easy to use editor

• Pub, a new package manager

• Dartium, a Chromium build with native Dart support

• A server-side I/O library

• A language specification describing the Dart semantics, including new features

Although Google is seeking to build a language that is simpler and faster than JavaScript, it won't replace JavaScript at this early date. While developers could build applications in Dart alone, Google is providing tools to compile finished code to JavaScript, an essential step in making applications that can work in extant browsers.

The aforementioned Dart Virtual Machine will also let developers test applications in Web browsers without having to compile to JavaScript first. To that end, Google in February released a version of Chromium called "Dartium" that embeds the Dart Virtual Machine.

Downloading the Dart Editor will give developers a copy of both the open source Dart SDK and Dartium. More improvements are on the way.

"Over the following months," Bak wrote, "we will continue to work hard to evolve the SDK, improve Dart’s robustness and performance, and fine-tune the language while maintaining backwards compatibility."

Promoted Comments

Why are we bothering with developing new languages when what we should be doing is developing a web standard for a universal bytecode + VM? Hell, use the JVM or the CLR, just as long as it doesn't tie me to a specific language. Dart may be better than JavaScript (I would hope so) but that doesn't mean it's a silver bullet. If we create a standardized bytecode, it doesn't matter what language produced it.

That's what I want. I want to be able to choose between dynamic and static typing, between low level, high performance bit fiddling and very high level DSLs.

We're already sort of doing that with all the JavaScript transpilers (CoffeeScript, TypeScript, ScriptSharp, GWT, etc) but those basically use Javascript as the low level bytecode and JavaScript is unbelievably poorly equipped to act as bytecode (verbose and ambiguous).

The fact that DART was born with a "JavaScript translator" and "A library to interoperate with JavaScript code" tells us that Google knows full well what hurdles it faces, the issues most often cited for DART being unlikely to gain any real traction. And I would say that the day that they abandon those translators and compatibilities, is the day that DART dies. I just don't see other browser vendors implementing it without a huge amount of pressure being applied.

But I have to wonder if perhaps they really wanted it for some internal use, and are handling the development publicly to sort of test the waters, set the stage.

46 Reader Comments

Going to be hard for Dart to break through with all the fantastic javascript tools coming out every day. Interested to give it a try, though, and wish google the best in their effort to fix the awesome but admittedly a bit broken Javascript/ECMA Script.

That's a pretty poor use of a good XKCD. Languages are not standards. "We should all just code with assembly", etc.

Except now that Google wants browsers to support Dart?

I don't think that's "now" at all. At the very least, it's not going to happen. You can't use the Chomium build with built-in Dart VM for regular browsing, no other browser vendor is picking dart up, Google is still part of the Javascript standardization process, and they still employ prominent members of the Javascript community, who say Javascript is here to stay:

Near as I can tell, Lars Bak wanted to make Dart, so Google put resources behind that, just like Rob Pike and Ken Thompson wanted to make Go and so they put resources behind that. Some people at Google feel like JS is broken and needs to be thrown out completely, but clearly many don't (see Alex Russell's blog post above)...which is exactly like the larger web community. I'm an Alex Russell fanboy (from the dojo days), so I know which side of the divide I fall upon, but people freaking out about Dart is silly at this stage, especially considering the huge number of other languages that also compile to JS.

Languages that compile to JavaScript, and experiments with the syntax (whether it's EcmaScript 6 stuff or the new sweet.js macros) have been blossoming all over the place recently, and the extreme diversity of approaches is a strength, not a weakness. Maybe someday "fragmentation" or something will be a hindrance, but for now we can explore many many paths for progress in parallel.

Why are we bothering with developing new languages when what we should be doing is developing a web standard for a universal bytecode + VM? Hell, use the JVM or the CLR, just as long as it doesn't tie me to a specific language. Dart may be better than JavaScript (I would hope so) but that doesn't mean it's a silver bullet. If we create a standardized bytecode, it doesn't matter what language produced it.

That's what I want. I want to be able to choose between dynamic and static typing, between low level, high performance bit fiddling and very high level DSLs.

We're already sort of doing that with all the JavaScript transpilers (CoffeeScript, TypeScript, ScriptSharp, GWT, etc) but those basically use Javascript as the low level bytecode and JavaScript is unbelievably poorly equipped to act as bytecode (verbose and ambiguous).

I'd currently be more interested in learning Dart than JavaScript. It sounds like Dart is the superior of those two languages; and since Dart can be automatically converted into JavaScript, the lack of browser support isn't particularly important.

I'd currently be more interested in learning Dart than JavaScript. It sounds like Dart is the superior of those two languages; and since Dart can be automatically converted into JavaScript, the lack of browser support isn't particularly important.

(But I know next to nothing about web development.)

Dart can be compiled into JavaScript, but so can many other languages like C++, C#, Java, etc.

The real question is what performance you get when you compile into JS. I haven't seen benchmarks, but I suspect Dart will see some slowdowns when compiled to JS (for example, Dart numbers are all bignums, so you need checks on every math operation it would seem).

The fact that DART was born with a "JavaScript translator" and "A library to interoperate with JavaScript code" tells us that Google knows full well what hurdles it faces, the issues most often cited for DART being unlikely to gain any real traction. And I would say that the day that they abandon those translators and compatibilities, is the day that DART dies. I just don't see other browser vendors implementing it without a huge amount of pressure being applied.

But I have to wonder if perhaps they really wanted it for some internal use, and are handling the development publicly to sort of test the waters, set the stage.

Why are we bothering with developing new languages when what we should be doing is developing a web standard for a universal bytecode + VM? Hell, use the JVM or the CLR, just as long as it doesn't tie me to a specific language.

PervertRyan, by my official decree, you are in charge now. Make it so. I'd love to write my client-side code in, say, python, or C#, or *whatever*. When I write a server-side or desktop app, I have almost limitless language options. I would love the same in the browser.

I'm really excited about new technologies like this but quite honestly the thing needs to be fixed is old browsers.

We need an elite set of hackers to find ever user who uses IE 8 or less (I'm being generous here) and FORCE them to upgrade to IE 9, Chrome, Firefox, etc. As a web developer who has to design for IE 7-9, Firefox, & Chrome I have to design for the lowest common denominator and it severely cripples what features I can create before things get slow.

I'm really excited about new technologies like this but quite honestly the thing needs to be fixed is old browsers.

We need an elite set of hackers to find ever user who uses IE 8 or less (I'm being generous here) and FORCE them to upgrade to IE 9, Chrome, Firefox, etc. As a web developer who has to design for IE 7-9, Firefox, & Chrome I have to design for the lowest common denominator and it severely cripples what features I can create before things get slow.

And then we need Microsoft to stop dropping support in the new browsers for OS more than 2 generations old. If every one of their competition can create a modern browser for Windows XP, then MS should be able to do the same with IE 9 and 10.

Personally I think JavaScript is a horrible language and for many reasons. Because of that I've done all I can to avoid web development. Those who do web development are probably people who actually like JavaScript. I don't know much about Dart, but what I do know makes me think I'd probably enjoy it a lot more than JS. As a developer, I'd be a lot more keen on developing a website with something like Dart and it might be enough to draw me to the field. Perhaps Dart will draw people to web development that otherwise would have avoided it completely. Sorta like how if the only application development language today was assembler, most people who are programmers now would instead be bus drivers or photo-journalists or something else completely different.

what we should be doing is developing a web standard for a universal bytecode

A couple of problems with bytecode:

Verification - you need to verify that the bytecode is safe. This can be just as slow as parsing source code. Worse it can be much harder to make secure, as your VM must be secure against malicious hand-crafted bytecode, that isn't even the output of a compiler.

Loss of AST - often the VM has to do extra work to infer the original AST of your source code, so that it can perform runtime optimisations. Bytecode often causes useful information in your source code to be thrown away, which means the VM must do more inference.

Size - Often bytecode is not smaller than source code. It is also possible to create a compact binary AST representation of your source. I doubt that bytecode would beat the wire size of a minified binary AST format.

A bytecode and VM must always make optimisation decisions. It is hard to make one bytecode and one VM work equally well for all languages which target it. Compromises must be made. It's hard to make the VM fast for all languages, it will likely also lead to a complicated code base which has security implications.

There are lot's of examples of good transpilers these days. Sourcemaps allows you to debug transpiled languages as if they were native. So a sourcecode VM can support multiple languages.

So what advantages does a bytecode VM actually provide over a sourcecode VM?

Also, It will be interesting to see what happens as Dart matures. We will see if they can live up to their prediction of a 10x start up speed over Javascript. We will also see how well the VM performs against the JVM, and CLR (Does MS still prohibit publishing of CLR benchmarks?).

Why are we bothering with developing new languages when what we should be doing is developing a web standard for a universal bytecode + VM? Hell, use the JVM or the CLR, just as long as it doesn't tie me to a specific language. Dart may be better than JavaScript (I would hope so) but that doesn't mean it's a silver bullet. If we create a standardized bytecode, it doesn't matter what language produced it.

That's what I want. I want to be able to choose between dynamic and static typing, between low level, high performance bit fiddling and very high level DSLs.

We're already sort of doing that with all the JavaScript transpilers (CoffeeScript, TypeScript, ScriptSharp, GWT, etc) but those basically use Javascript as the low level bytecode and JavaScript is unbelievably poorly equipped to act as bytecode (verbose and ambiguous).

I think part of the problem is that a lot of javascript is so inherently tied to the DOM.

The fact that DART was born with a "JavaScript translator" and "A library to interoperate with JavaScript code" tells us that Google knows full well what hurdles it faces, the issues most often cited for DART being unlikely to gain any real traction. And I would say that the day that they abandon those translators and compatibilities, is the day that DART dies. I just don't see other browser vendors implementing it without a huge amount of pressure being applied.

But I have to wonder if perhaps they really wanted it for some internal use, and are handling the development publicly to sort of test the waters, set the stage.

Javascript is a terrible language for large scale apps - but only because of a small number of mistakes in the language (scoping issues, number issues, NAMESPACES, etc).

Hide those mistakes behind a good compiler, and who cares? Devs writing large apps would otherwise have to choose from $flavorOfTheDay for namespacing (AMD? Could you create a less readable syntax?) , and also pick a nice OO library/framework/toolkit, oh, and does it build with NodeJS? Or is it dynamically assembled? Or both, like Enyo? What about the MV[C | VM | WTF] framework?

Developers like myself will pick up something like Dart simply FOR the incredible compilation that anything Google offers is sure to provide. The fact that one browser will consume Dart natively and will just fly is pure frosting.

Why did Google start their own browser? And now a programming language that only runs in that browser? How long before certain Google apps will only be developed in Dart "because that allows the company to better focus on reliably providing end user needs" or some similar weasel statement? If there is a strategy behind it, it's called domination.

It's not a bad moment right now to push a compile-to-javascript language as everyone and his little sister use some kind of minifier/optimizer for Javascript right now.

YUI compiler, Google Closure, JSmin, PrettyDiff change any of those for Dart compiler and your work flow won't change.

The same is going on with CSS, Closure Tools, less compiler, SASS ... but those have to beat CSS3 as most of the problems that those tools fix - variables and that kind of things - are solved in the standard itself.

A "bytecode" VM is the exact same thing as a "sourcecode" VM. They are both "language" VMs just with different languages.

As your link puts it, there are many arguments why a "bytecode" may not necessarily be better, but there is only one that makes it strictly worse: it adds an extra compilation step. Now, obviously, if you're transpiling, and/or minifying and compacting for deployment, you already do have a "compilation" step, so that argument is instantly bust.

In fact, there are no reasons for "bytecode" to be strictly worse than "sourcecode" for distribution, and probably not many reasons for it to be strictly better either. Ergo, they're pretty much the same.

Javascript is a perfectly good bytecode for Javascript semantics, just as JVM/Dalvik are perfectly good bytecodes for Java/Scala semantics, and .NET a perfectly good bytecode for C#/F#/VB.NET semantics. Neither are good bytecodes for the others, and though cludges exist, neither are good bytecodes for Python/PHP/Perl. And much more problematic than "bytecodes" for interoperability are the huge, disparate, standard libraries these languages need to be themselves.

So anyone claiming to want to replace Javascript with a "bytecode" VM just doesn't like the rather exotic Javascript semantics, the lack of a decently rich standard library, the weird DOM, or all of the above. But that's replacing one's preference with another's. There is simply no way to make performant versions of Javascript/C#/Java/Python and their standard libraries available portably to any and all browsers.

Personally I think JavaScript is a horrible language and for many reasons. Because of that I've done all I can to avoid web development. Those who do web development are probably people who actually like JavaScript.

Not really, no. Unless your job is "create JavaScript tools for other devs," you're probably not working in straight JS. You're using node.js, or Jquery, or one of the other dozens of platforms that have been created to work on top of JS.

Avoiding web development because you don't like Javascript is like avoiding app development because you don't like Assembler.

The fact that DART was born with a "JavaScript translator" and "A library to interoperate with JavaScript code" tells us that Google knows full well what hurdles it faces, the issues most often cited for DART being unlikely to gain any real traction. And I would say that the day that they abandon those translators and compatibilities, is the day that DART dies. I just don't see other browser vendors implementing it without a huge amount of pressure being applied.

But I have to wonder if perhaps they really wanted it for some internal use, and are handling the development publicly to sort of test the waters, set the stage.

IMHO a better approach would be Google to release a Chrome version with Dart support and an on-the-fly Javascript-to-Dart translator instead. This way all legacy JS would work on top of the new language, and when people realizes that Dart is better (if it is actually that better in the day by day usage - I really don't know) they would eventually migrate.

The fact that DART was born with a "JavaScript translator" and "A library to interoperate with JavaScript code" tells us that Google knows full well what hurdles it faces, the issues most often cited for DART being unlikely to gain any real traction. And I would say that the day that they abandon those translators and compatibilities, is the day that DART dies. I just don't see other browser vendors implementing it without a huge amount of pressure being applied.

But I have to wonder if perhaps they really wanted it for some internal use, and are handling the development publicly to sort of test the waters, set the stage.

Javascript is a terrible language for large scale apps - but only because of a small number of mistakes in the language (scoping issues, number issues, NAMESPACES, etc).

Hide those mistakes behind a good compiler, and who cares? Devs writing large apps would otherwise have to choose from $flavorOfTheDay for namespacing (AMD? Could you create a less readable syntax?) , and also pick a nice OO library/framework/toolkit, oh, and does it build with NodeJS? Or is it dynamically assembled? Or both, like Enyo? What about the MV[C | VM | WTF] framework?

Developers like myself will pick up something like Dart simply FOR the incredible compilation that anything Google offers is sure to provide. The fact that one browser will consume Dart natively and will just fly is pure frosting.

Good points, particularly the one about the tools that Google will provide - that's very tempting. But I perceive risk there: if Google can't get * ALL * major browser vendors to implement native support for DART, and therefore fails to achieve nearly ubiquitous support for DART, then how likely are they to continue development, maintenance, and support of their DART dev tools? I think that the tools then become yet another laboratory curiosity, much like all the great stuff that came out of Google Labs but never flew, and has since vanished, along with support and upkeep.

Personally, I'd really like to see it work, but I think that Google has overestimated their clout here. It's simply all going to come down to native support and adoption, and that will kill it unless they're willing to offer a tool suite as a stand-alone package - forever.

The fact that DART was born with a "JavaScript translator" and "A library to interoperate with JavaScript code" tells us that Google knows full well what hurdles it faces, the issues most often cited for DART being unlikely to gain any real traction. And I would say that the day that they abandon those translators and compatibilities, is the day that DART dies. I just don't see other browser vendors implementing it without a huge amount of pressure being applied.

But I have to wonder if perhaps they really wanted it for some internal use, and are handling the development publicly to sort of test the waters, set the stage.

Well, Google does have a penchant for throwing lots of things against the wall in the hope that some things stick.

Regardless of the outcome, they deserve credit for moving to advance Web functionality.

The real question is what performance you get when you compile into JS. I haven't seen benchmarks, but I suspect Dart will see some slowdowns when compiled to JS (for example, Dart numbers are all bignums, so you need checks on every math operation it would seem).

dart2js generates quite fast js code apparently: they're able to make direct use of js numbers when they can guarantee some assumptions, and on 5 benchmarks, their compiled js code is actually faster than the js original O_o (otoh, on one benchmark, it's 3 times as slow)

(ok, lies, damned lies and benchmarks... I'd like to see the js code for those, but still: it isn't as bad as I might have thought )

JavaScript isn't a bad "bytecode". One could argue that Lua has a simpler type system which is more consistent and flexible and that it has an actual binary representation. But second to Lua, JavaScript is pretty close to the lowest common denominator of all managed languages.

Consider Joose as an example of the range of higher-level object models that can be implemented in JavaScript without even involving a precompiler. You can have classes with single inheritance and runtime reflection (like Java). You can compose classes from reusable "roles" (like Common Lisp). You can have meta-classes and meta-roles ("traits") that control how classes are composed. You can compose inherited methods (like decorators in Python). You can even have immutable objects (like Clojure).

Obviously, adding a precompiler greatly extends the range of expressible language semantics, allowing for more powerful syntactic elements and compile-time logic such as type-checking and string-interning.

The longevity of C is easy to explain: it's a simple, consistent, and flexible representation of the Von Neumann architecture, which is been the basis for just about every CPU instruction set architecture since the beginning of time. Memory is a flat linear array.

But consider this line of reasoning from the opposite direction. Instead of abstracting the CPU's view of the world, let's abstract the programmer's view of the world. What is the most simple, consistent, and flexible representation of a namespace? A namespace is a nested associative array.

So, yeah, Lua is to associative machines as C is to linear machines. And the LuaJIT is crazy fast without the vast development resources that have been expended on the JS engines. Maybe JavaScript should be cast aside as the Fortran of its generation: on the right track, but not without its flaws.

But at the end of the day, C superseded Fortran because K&R couldn't write UNIX in Fortran. That situation doesn't exist with JavaScript. In fact, there are significant barriers to writing a web application in anything other than JavaScript. So we may be stuck with Fortran this time around.

maybe i'm not using JS to it's full capabilities... but I haven't encountered issues with JS effectiveness.

++

Agreed. I've had a few modest hits in the web app world, and they've all started out as vanilla js. Don't get me wrong -- I rely on the occasional 3rd party library to get me through the day myself (date.js especially), and there have been times when I thought to myself, "Man...that sure seems broken"...but its never been anything that I couldn't work around, and its certainly never been so big that I thought someone needs to reboot the entire experience.

I think a lot of the ire stems from javascript's prototypical nature...its really tough to wrap your head around at first, especially if you come from a classic oop background.

JavaScript isn't a bad "bytecode". One could argue that Lua has a simpler type system which is more consistent and flexible and that it has an actual binary representation. But second to Lua, JavaScript is pretty close to the lowest common denominator of all managed languages.

Consider Joose as an example of the range of higher-level object models that can be implemented in JavaScript without even involving a precompiler. You can have classes with single inheritance and runtime reflection (like Java). You can compose classes from reusable "roles" (like Common Lisp). You can have meta-classes and meta-roles ("traits") that control how classes are composed. You can compose inherited methods (like decorators in Python). You can even have immutable objects (like Clojure).

Obviously, adding a precompiler greatly extends the range of expressible language semantics, allowing for more powerful syntactic elements and compile-type logic such as type-checking and string-interning.

The longevity of C is easy to explain: it's a simple, consistent, and flexible representation of the Von Neumann architecture, which is been the basis for just about every CPU instruction set architecture since the beginning of time. Memory is a flat linear array.

But consider this line of reasoning from the opposite direction. Instead of abstracting the CPU's view of the world, let's abstract the programmer's view of the world. What is the most simple, consistent, and flexible representation of a namespace? A namespace is a nested associative array.

So, yeah, Lua is to associative machines as C is to linear machines. And the LuaJIT is crazy fast without the vast development resources that have been expended on the JS engines. Maybe JavaScript should be cast aside as the Fortran of its generation: on the right track, but not without its flaws.

But at the end of the day, C superseded Fortran because K&R couldn't write UNIX in Fortran. That situation doesn't exist with JavaScript. In fact, there are significant barriers to writing a web application in anything other than JavaScript. So we may be stuck with Fortran this time around.

Those who think web standards are a solution for everything should do a real assessment of the quality of the standards that exist. Those who think Javascript is an adequale language just demonstrate that they do not know much about programming technology. The truth about the state of HTML 5 and Javascript is tha they are still low function technologies that are far behind a variety of other proprietary and open source efforts. The quality of most of the sofware that appears on the web is also pretty low grade in comparison, for example, with what it took to get to the moon or what it takes to run the Internet. You can't just throw that kind of technology at users and worry about all of the mistakes later. Then, of course, there is the reality that a large part of the web head community has rejected one of the most central standards to emerge from the w3c, XML.

Cross compilation (interpretation??) to JavaScript is the flaw IMHO. As long as these new languages, supposedly to replace JavaScript, continue to be backwards / across compatible with JavaScript, there will be no incentive for developers to take the pains to learn something new and at the same time alienate themselves from the rest of the crowd. Also, in an effort to provide (seamless) translation to JavaScript, the language will probably remain hampered in some fundamental ways. Sometimes it is important to realize when to let go of something and start afresh. Apple's remarkable success with its archaic (as in the first-impressions-of, at least) language Objective-C is a living proof of this approach.