JavaScript has problems. Do we need Dart to solve them?

JavaScript, the linchpin of scripted websites, is not a perfect programming …

Google hopes to upset JavaScript's dominance by introducing a new language, Dart. Dart is designed to be simpler, more familiar, and faster than JavaScript, and Google one day wants to see it everywhere: in the browser, on the server, and maybe even on the smartphone. Those are big ambitions, but before we take a look at Dart and at Google's plans for it, it's worth taking a closer look at JavaScript itself. Why exactly doesn't Google like it?

The oddball

JavaScript is a funny little language. Languages which buck trends rarely flourish, and though JavaScript mostly has the syntax and structure of a conventional, C-family programming language, the way it actually works is quite unusual. It's an object-oriented language, but instead of using classes, it has only objects and prototypes. (Classes are cookie cutters that can be used to stamp out a whole set of objects that all have the same behavior. To create multiple objects with identical behavior in JavaScript and other prototype-based languages, you take an object with the behavior you want and clone it.)

Every other object-oriented language in widespread use sticks to classes. Widespread variations do exist—classes in, say, C++ or Java are static, defined at compilation time, and can never change during the execution of a program, whereas those in Python or Ruby can be modified by a running program—but the use of classes is a constant.

Still, JavaScript has been enormously successful. The ability to add dynamic scripting to webpages has proven useful, and because JavaScript was the first language to be used this way—it was invented in a hurry by Netscape for Navigator 2.0—it has become the dominant force for Web scripting. Microsoft does have a pluggable scripting system supporting JScript (Microsoft's JavaScript implementation) and VBScript, with Perl and Python (among others) available as downloadable options, but only JavaScript has had the cross-platform, cross-browser uptake that's necessary to flourish in the Web environment.

JavaScript's wide usage has produced great pressure to make the language faster. Google's Chrome was the first browser to really tout JavaScript performance as a feature, and its V8 engine was the first to use techniques such as just-in-time (JIT) compilation to make serious improvements in JavaScript execution. Microsoft (with its Chakra engine) and Apple (with its Nitro engine) and Mozilla (with its various Monkey engines), have all followed suit. The result is that modern JavaScript engines are an order of magnitude or more faster than engines of old.

Probably the biggest single advance is the use of JIT compilation instead of interpretation. JIT compilers generate small fragments of native code so that script programs are compiled in a piecemeal fashion. When it comes to performance, JavaScript engines are some of the most advanced scripting runtimes around—generally being much faster than perl, Python, or Ruby.

But there's a big difference between "the fastest scripting language" and just plain "fast." Compared to traditional compiled languages like C++ or Fortran, or even JIT-compiled safe languages like C# and Java, JavaScript's performance looks a lot less impressive. For all the time, money, and effort that has been poured into JavaScript engines, JavaScript programs still perform at a huge disadvantage relative to those built with typical desktop development tools.

Writing a high performance scripting engine is hard to do—and writing a high performance JavaScript engine is particularly challenging. One of the things that makes it difficult is the use of prototypes instead of classes. With a class-based language, every single instance of that class has the same behavior: the same set of fields to store data and the same set of methods to perform actions. The scripting engine need only generate optimized executable code for that class once and it can then be used for every single instance of that code. Even in languages like Python, where modifications to the class can be made at runtime, the amount of code generation is limited; a modification might force the engine to throw away all the executable code it has generated so far and create new code, but that code is still shared by every instance of the class.

This approach allows very fast code to be generated. As an example, consider the simple case of accessing a field in an object. With an old-fashioned interpreted scripting engine, this might be accomplished by looking inside a dictionary mapping from field names to field values—a slow, expensive operation. With a traditional compiled language, the compiler will lay out all the fields of a class in a particular order and it will know the exact position of each field; accessing the field then becomes as quick as reading a value from memory. The position of the field will be the same for every single instance of the class, so the native code can be very simple and very fast.

In JavaScript, that's much harder to do; there are no real classes, so there's much less scope for easily sharing generated code. The overhead of generating this code will often outweigh the performance improvement that code generation provides; if you can't share the native code between lots of objects, you're often better off using the slow dictionary lookup. V8 (and the Firefox engine and, I believe, other high-performance JavaScript engines) tries to remedy this problem by generating synthetic hidden classes, which can then be shared among multiple object instances.

This works well, to a point—the modern JavaScript engines are faster than their counterparts in other languages—but it's nonetheless complex. And it's a complexity that languages with explicitly defined classes don't have to handle.

Giving developers what they want

Prototypes have also proven to be a mixed blessing for developers. Prototype-based languages are academically interesting, but it's fair to say that they've lost the battle for mainstream acceptance (if they ever really fought it). Class-based languages are taught in schools and in universities now; they're what most of the object-oriented literature and research focuses on. They're the mainstream. Developers want to use their class-based knowledge and techniques, but JavaScript doesn't directly support that. In response, many of the widely used JavaScript libraries include their own emulation of class-based objects. With classes baked directly into the language, both JavaScript engines and libraries would be easier to develop, easier to use, and faster.

The use of prototypes isn't the only thing that makes JavaScript complex, but it's probably the biggest single issue. And significantly, it's arguably also the most discardable one. If neither users of the language nor developers of engines really want prototypes, perhaps the language shouldn't be built around them after all.

JavaScript also has features (or, more commonly, it lacks features) that make development of large applications somewhat more challenging than they might be in other languages. Some of these are minor grievances—the way variable scope works, for example. Others are a bit more significant; for example, JavaScript has no built-in module system. This is a particular annoyance for programs that depend on third-party libraries, since they have no good way of ensuring that library A won't conflict somehow with library B (for example, both libraries might try to create objects with the same name).

JavaScript also lacks any kind of static typing. This is not at all unusual; dynamic typing is a feature of most scripting languages, and in this sense JavaScript is thoroughly conventional. With static typing, every variable or field has a singular, well-defined type (say, "number" or "string" or "file"). It can only store objects of that type, and the compiler will complain before you even try to run the code if you try to do something that the type cannot do—for example, if you try to divide a string by a file, or add a network socket to an integer. With dynamic typing, that's no longer the case. Variables and fields can store values of any type, and the scripting engine will only complain if it simply can't figure out what to do at runtime.

Opinions vary wildly on which approach is better. Dynamic typing tends to be easier to use and less verbose, because programmers don't need to specify type information at all. Dynamically typed languages have much of the power of interfaces, templates, and generics without ever having to suffer the complexity of those mechanisms. But static typing has its advantages, too. Detecting errors at compile time, rather than having them blow up in the user's face at runtime, is greatly preferable. Fixed knowledge of the types used in a program makes it easier to generate fast code, too. Static typing also tends to make it easier to answer questions about the code, such as "show me every part of the program that uses this class." This can be a boon to maintenance; it makes refactoring much simpler and safer.

Not everyone will agree that every JavaScript issue is a real problem. The language has its fans, though it's certainly not the case that everyone who uses it actually likes it. But everyone who uses it must surely acknowledge that some of these things are problems, even if minor ones. Some problems, such as the small built-in library and the lack of module system, can be solved with a combination of policy and third-party code. People may prefer classes to prototypes, but prototypes can be used to implement class-like systems anyway. The dynamic typing versus static typing question will never be resolved, as there's no right answer, but there's a sizeable minority at least who would prefer some kind of static typing to be possible.

The importance of Web scripting is unlikely to diminish any time soon. Web programs are only going to grow in scope and complexity. The case in favor of making the Web's scripting language better—easier to run at high speed, easier to develop, easier to test—is therefore compelling.

197 Reader Comments

The focus on Javascript Runtime performance improvements that has come as a result of all these competing browsers and advancing online user experiences is precisely why we're attempting to move as much of our development toolchain to Javascript as possible. We're evaluating Node.js currently with a handful of client projects in place of our traditional Symfony (PHP) and Rails (Ruby) development, because the bet is that Google is going to keep hammering on V8 performance at a pace that vastly outstrips PHP and Ruby interpreter performance. There are just bigger gorillas in the Javascript ecosystem now compared to the competitors.

Not having classes makes programming really quick (for little programs that don't really matter), it also (or more specifically javascript) makes it really easy to make a total ..... mess of a program - it's probably fair to say that javascript is too flexible (even without thinking of "eval") in the number of ways you can use it..

But maybe it was javascripts flexibility that made it successful - .. probably the web is much more professional now and the low barrier to entry of unstructured js programs has become irrelevant

y first thoughts on looking at dart is "that looks suitably restrictive (ie organised) to be a faster ( and more ordered) language" - which is waht they want - I understand - the big question here is - if they just want a fast, well strcutured language that can be used ubiquitously on the web for their apps and so on - WHY DONT THEY USE JAVA ?

One point on generics, you note "support for something akin to Java-like generics (Java-like, in the sense that they're fake and are only used by the type checker, with no runtime representation)".

I think it's the opposite - if type-checking is enabled (non-"production mode") the Dart specification says generics are reified and not implemented through type erasure like Java. At least this is claimed at the top of page 7 in the lang spec: http://www.dartlang.org/docs/spec/dartLangSpec.pdf .

One point on generics, you note "support for something akin to Java-like generics (Java-like, in the sense that they're fake and are only used by the type checker, with no runtime representation)".

I think it's the opposite - if type-checking is enabled (non-"production mode") the Dart specification says generics are reified and not implemented through type erasure like Java. At least this is claimed at the top of page 7 in the lang spec: http://www.dartlang.org/docs/spec/dartLangSpec.pdf .

Hmm, well now I am a little confused.

I looked through the specification, but also read this page. That has the following identities:

Code:

new List() is List<Dynamic>new List<String> is List<Dynamic>new List<Dynamic> is List<String>

which led me to believe types were getting erased. However, you are right; the spec does say that type arguments to constructors are reified.

I wonder if maybe they are reified to the extent that you can query them (like C# generics, C++ templates, unlike Java generics), but not to the extent that the runtime stops using virtual dispatch to look up functions (like Java generics, unlike C++ templates).

But, but, Google is open, they say so! And open is best cause Google says so!

Except when they don't want to be.

Dart won't go anywhere unless its got cross platform, cross browser support and thats not likely to happen. Neither Apple nor Microsoft are going to embrace a proprietary system from one of their main competitors, especially a proprietary one. Plus Dart would have to be a substantial improvement over JavaScript to drive people to adopt a completely new format.

the big question here is - if they just want a fast, well strcutured language that can be used ubiquitously on the web for their apps and so on - WHY DONT THEY USE JAVA ?

Because Google doesn't own it. Or, more importantly, someone else (Oracle) does. And Google doesn't particularly like that someone.

That (not-invented-here) would make sense to me if it was being used for in-house stuff (eg like they did with Go language) - but they appear to expect everyone else to jump on board. Seems a little optimistic - maybe someone who does this for a living could say why this is a better choice than using something old that already exists.

When I read the abbreviation TC39 on the third page, I was a little confused at first as to when it was first mentioned. I realized that it was referring to the ECMA Technical Committee 39, but it wasn't explicitly stated. I'm not sure if there is a term for this, but on other articles I read the abbreviation of the term is written immediately after in parenthesis so there would be no confusion. So the correct sentence would read as "ECMA Technical Committee 39 (TC39), the open standard group..."

Likewise, the abbreviation NIH also tripped me. I get that it means Not Invented Here, but this is more confusing since the term is not mentioned in the article at all, just hyperlinked. At first I didn't bother clicking on it, but searching for what NIH means finally led me to it.

I realize that I look like I'm nitpicking, but it's these little things I think that make for a more professional article and a better website overall.

But, but, Google is open, they say so! And open is best cause Google says so!

Except when they don't want to be.

Dart won't go anywhere unless its got cross platform, cross browser support and thats not likely to happen. Neither Apple nor Microsoft are going to embrace a proprietary system from one of their main competitors, especially a proprietary one. Plus Dart would have to be a substantial improvement over JavaScript to drive people to adopt a completely new format.

Google has said that the language, it's compiler and VM are going to be Open Source.Google has also said they intend to send the specs to a standards body.Google does not want to be the sole owner of the language, they just want to get it done and then release it for everyone to contribute. And you know why they're doing it? Because that's the only fast way to do it. You will fail (timewise) if you try to design a new language through a community, just look at all the reactions people have had because it lacks a certain feature, or has a certain syntax.

Don't know why you don't get your fact straight and stop being so bitter about Google.

For a company that is so connected to web tech, it never ceases to amaze me how much Google seems to hate the fundamental web techs and want to remake them in its image. This isn't the first time they've written something to make JavaScript more Java-like, they did it once already with GWT. They don't like http/https either, so they created spdy rather than propose extensions or revisions to the http protocol itself. And now there's Dart. At this rate I expect them to rage against CSS and the Box model within a few years.

JS has its warts, sure, but none of them are really that bad. Aside from the DOM API that is, which is just terrible and would be even if you tried to deal with it in another language (for laughs look at the W3C DOM API in Java, if you think the JS version is verbose and stupid). JS scope resolution is hard? So are C++ templates, and that hasn't killed the language off. Both allow you to do some fantastic tricks when you've learned how they work completely, but it seems that only about 5% of the programmers out there are willing to learn how JS does things.

As far as classes v. prototypes, both mechanisms are expressive enough to implement each other easily in dynamic languages. I've seen perfectly workable implementations of prototype-based OO in Python before, and I've written at least a half dozen different class implementations in JS in my time. There's nothing inherently wrong with prototypes, they just require a different thought process when developing code in them much like one must use a different process when developing code in FP languages.

IMO, Brendan Eich and John Resig have it right on this one. Harmony should add more than enough to the JS language to make some of the stupider parts of it better (those that weren't already fixed with ECMAScript 5 strict mode that is). There's no need to replace JS, particularly with yet another scripting language developed only because of how much it works like Java. If they really want to replace JS, they should be considering either a standardized bytecode VM that the developer could target any language to, or they should consider reusing an existing scripting language like Peter suggested in this article.

Google has said that the language, it's compiler and VM are going to be Open Source.Google has also said they intend to send the specs to a standards body.

Microsoft has been criticized for dumping fully-formed, complete specifications on standards bodies for a rubber stamp; it's fair to criticize Google for the same.

Being submitted to a standards body is only half of the point. The other half is being developed by an open community. Dart can't be, because it runs counter to Google's frankly inexplicable demand to do everything as fast as possible.

Quote:

Google does not want to be the sole owner of the language, they just want to get it done and then release it for everyone to contribute.

Do you not see how contradictory that is? They want to get the language to a finished usable state, and only then--when it no longer matters--do they wish to invite the community to participate.

Quote:

And you know why they're doing it? Because that's the only fast way to do it. You will fail (timewise) if you try to design a new language through a community, just look at all the reactions people have had because it lacks a certain feature, or has a certain syntax.

Yes its isn't open of Google to develop Dart in house but at least if it isn't successful Google isn't going to delay its eventual death; (wave comes to mind). Google will continue to optimize Chrome for the web no matter what the primary platforms are.

I don't understand why everyone says that developing Dart behind closed doors is somehow un-web-like. You know, the _web_ was developed behind closed doors. So was Javascript. As long as it's made open afterwards what's the big deal?

It may be a question of Betamax vs VHS, where it is not a question of being the best solution out there, but the one with the lowest entry cost. Dart sounds interesting, but maybe it may have more use in influencing the future direction of Javascript, rather than being a complete replacement.

If Google wants to replace Javascript, then it is going to have to provide solutions for all the browsers, since that will help reduce some of the excuses for not picking it up.

Microsoft made VB available as one of the scripting languages in IE, but no one else ever picked it up and for a number of companies this has meant intranet applications that only work in IE.

Google may still get their wish, but it should be seen as an up hill battle until then.

I think Google has a goal -- a ubiquitous, general-purpose scripting language that is better than current Javascript -- and making this move with Dart will further that effort regardless of the success of Dart itself. Should Dart become widely accepted, then wonderful. Google gets a feather in its cap. But if not, it will likely have spurred along Harmony development faster than if Dart had never existed, and will at least have kept it from dying in committee, which remains a risk.

The focus on Javascript Runtime performance improvements that has come as a result of all these competing browsers and advancing online user experiences is precisely why we're attempting to move as much of our development toolchain to Javascript as possible. We're evaluating Node.js currently with a handful of client projects in place of our traditional Symfony (PHP) and Rails (Ruby) development, because the bet is that Google is going to keep hammering on V8 performance at a pace that vastly outstrips PHP and Ruby interpreter performance. There are just bigger gorillas in the Javascript ecosystem now compared to the competitors.

Rails and Node.js are two totally different beasts though, with different purposes. I'd think they can fill their own niches simultaneously

I don't understand why everyone says that developing Dart behind closed doors is somehow un-web-like. You know, the _web_ was developed behind closed doors. So was Javascript. As long as it's made open afterwards what's the big deal?

Because Javascript was created while HTML was in its infancy and half the modern world didn't use the web as a platform the way it does now. Also all the browsers at that point in time, every single one, was a closed system and had a ton of incompatibilities. JS was first introduced in Netscape Navigator 2.0 in 1995, and the web itself only beat it to the punch by a couple years. The web began its open standardization phase in like 1995-1996 when it was clear that IE and NN were splitting the market and developers needed some commonality between the two of them put in writing. Do you really want the equivalent of those Best in Netscape Navigator/IE badges that used to litter sites in the mid 90s to come back because main browser developers started doing things in secret again?

To suggest that Google developing Dart in private is no different than JS's initial implementation is not credible, not after nearly 15 years of web standards evolving out in the open by meritocracy (albeit one that has stumbled at time, necessitating groups like the WHATWG to come in and right the ship). Small things can come in through proprietary extension, including things like XHR, CSS3 animations, and the excellent work Adobe's been doing on CSS Pixel Shaders. But you can't simply shoehorn an entire new application language into the platform in the same manner, it's too big a piece of technology to not go through public comment.

I don't understand why everyone says that developing Dart behind closed doors is somehow un-web-like. You know, the _web_ was developed behind closed doors. So was Javascript. As long as it's made open afterwards what's the big deal?

It's not the 90s anymore.

Not to mention that Google's hypocrisy on openness is rubbing a lot of people the wrong way.

I'm a -1 on Dart as the language for the Web since I actually like JS but the Dart DOM API proposal is very much worth a look. Edit: I would, however, be fine with using Dart as Android's programming language.

Rails and Node.js are two totally different beasts though, with different purposes. I'd think they can fill their own niches simultaneously

We're using a set of community driven middlewares to add Rails-like functionality to Node.js. Right now we're just using it for building more flexible data-integration lines with MongoDB as the intermediate datastore. So far it's been quite an interesting toolset to work with.

These are relatively basic applications. They sit between two end-point systems and arbitrate data movement between them, performing manipulations on the data sets as they move back and forth. The reason we use tools like Rails (or now ExpressJS) is to provide some monitoring and reporting visibility into the system.

If our experience with Node.js (and associated middleware) is a good one, then we'll start to push the toolset into larger problem spaces.

I think prototyping has also made it so adaptable too. It's made it easy to extend the core language in order to overcome poor implementations between browsers. So the strangeness of JS has also been one of it's greatest strengths.

Microsoft has been criticized for dumping fully-formed, complete specifications on standards bodies for a rubber stamp; it's fair to criticize Google for the same.

Being submitted to a standards body is only half of the point. The other half is being developed by an open community. Dart can't be, because it runs counter to Google's frankly inexplicable demand to do everything as fast as possible.

While i agree it's fair to criticize, he should do it with facts. Google don't want to shove a proprietary standard on the web, they want to develop and open it (like they did with Chrome, WebP, SPDY, GWT, Wave and so on). This is not a "Google doesn't want to be open", this is just a Google want to get things done.

As far is a know, Microsoft is one of the main reasons standards have failed over the years. And they aren't too keen on open sourcing their stuff.

DrPizza wrote:

Do you not see how contradictory that is? They want to get the language to a finished usable state, and only then--when it no longer matters--do they wish to invite the community to participate.

There are a lot of open source projects like this. Actually, most of open source start with one entity developing it closed, then opening it, then asking for improvements. I'm pretty sure Dart will get improved if the community wishes to do so.

DrPizza wrote:

And? What's the hurry?

I cannot answer that for Google, but i would say that they've waited long enough already, any new "web" language will take years to be viable, so the longer you wait, the longer you will suffer from the non-improved/fixed Javascript.

If you were asking my real opinion, i for one welcome more languages to the web, as long as i can get one bug free with cross browser support, i will be happy. And after the reveal (which didn't really impress anyone as it looks like a child of Java+Javascript) i'm more curious for the "IDE" support Dart will have, as it is one of its main goal (which Javascript severely lacks).

All these attempts to create a Java-esque language to natively run in browsers. Just make Java run natively in browsers. It's so simple it hurts.

K.I.S.S.

Or stop making browsers into something they weren't meant to be.

This may not be what browsers are meant to be, but the demand is making browsers what they are. So we should go about it in a more intelligent way.

It's the natural progression to make something more capable to keep up with demands. Java is more capable, Dart is borrowing heavily from the strucure of Java. It doesn't really take a Degree is C.S. to see what makes the most sense here. I may be slightly biased, but it doesn't really take away from my point.

This reminds me of an xkcd comic (many real-world issues do):There are currently 18 standards in X.Let's make 1 standard to unify all 18.There are now 19 standards.(sorry didn't feel like finding the image out of 9XX comics.)

Like the article points out briefly, using a JavaScript framework, like YUI 3, easily hides all these issues from the developer and makes the JavaScript code examples look a bit ridiculous. Accessing the prototype directly, dealing with browser implementation differences, or worrying about name collissions is a clear sign that a framework is in order. It really makes a world of difference.

Whenever I've seen the code of somebody who complained about JS, I felt the exact same way, because their approach made it that way. That seems to be a curse of scripting languages in general.

I think it's a bit like Ruby in that it took a strict and fairly complete framework to make it really click for mast people.

As far as classes v. prototypes, both mechanisms are expressive enough to implement each other easily in dynamic languages. I've seen perfectly workable implementations of prototype-based OO in Python before, and I've written at least a half dozen different class implementations in JS in my time.

And right there is another example of why Javascript is a bad language. Having so many different ways of doing the same thing is just begging for ugly code. Yes, with proper coding standards your application will just pick one and use it but I would love to be able to create web apps with a language that has this built in... like all my other favourite languages.

I do wish that Dart was being developed in more openly. However, just looking at how long it is taking to get the next version of ECMAScript to come out makes me very skeptical that it is even a realistic possibility. Someone above asked what the rush is, well I for one want to move away from Javascript as soon as I can.

It's amazing to me JavaScript has not yet been replaced. On other platforms, like Web servers, you'd think everyone wants to keep replacing old languages with newer, better one, such is recent advances of Ruby over PHP for example, committee design or not.

But Web browsers have up until now been designed by slow proprietary companies; Microsoft and Netscape, or by even slower and more reluctant to change communities from Mozilla & co. much akin to how Linux Desktop is so slow to evolve. Have you ever seen a language that takes as much time as HTML for a new version to be designed?

The answer is simple, really. There's no infusion of capitalism in the world of Web languages. It's like a big fat communist machine where changes are not necessary to survive. Sure, evolution is wanted, but everyone has to agree first. If there was at least some competition with financial push, major improvements would be made right away.

So my take is precisely the opposite of the Web community in general: There absolutely needs to be a proprietary no questions asked development of a new language for the Web, and Google is doing just that.

The only danger is that Google becomes dominant and starts "sleeping" on its language, thereby stopping innovation. The argument that the community in general won't have any choices is bogus; Microsoft has always been adapting C# with feedback from its developers. That's the way to go with any successful language, and I think Google is well aware it needs to have feedback and build on it.

However, it's also essential that competition remains possible. For this, code for Dart VMs from Google should remain open source, and I believe it already is (Chromium?), so there's nothing to worry on that. Mozilla can always make its own competing changes.