Critics call foul as Google takes aim at JavaScript with Dart

Google is preparing to unveil a new client-side programming language for the …

Google is developing a new scripting language for the Web that the company hopes will eventually supplant JavaScript. The language, which is called Dart, will be presented next month during an opening keynote at the GOTO conference.

Few technical details about the programming language are available at this time, but an internal Google memo that was authored last year and subsequently leaked offers some insight into the company's strategic goals for the project.

Dart has recently drawn heavy criticism from some prominent figures in the Web standards community, including JavaScript architect Brendan Eich. Eich originally created JavaScript in 1995 while at Netscape. The language was submitted to ECMA for standardization the following year. It provided early Web developers with the ability to perform useful tasks—such as programmatic form validation—on the client side. Despite its extreme simplicity and multitude of idiosyncrasies, JavaScript has weathered the explosive growth of the Web and has kept up with the increasingly complex workload imposed on it by modern Web applications.

Efforts to improve JavaScript at the specification level are ongoing, but have been slow due to a number of technical and political reasons. The ECMAScript 4th Edition (ES4) proposal, which was published in 2007, laid out a plan to radically overhaul JavaScript. The proposal was largely authored by Mozilla, Adobe, and Opera but faced strong resistance from other major stakeholders, including Microsoft and Yahoo. The split led to a public dispute in 2007 over the future of the programming language and its role in Web development.

A 2008 compromise ended the stalemate and laid out a new roadmap. An incremental update to the standard was issued in 2009, but a more ambitious update called Harmony was planned for the future. Harmony is currently under active development within the JavaScript standards committee and is on a positive trajectory for eventual adoption. Harmony, as the name suggests, represents a more consensus-driven vision than the contentious ES4 proposal.

Alongside this productive effort to deliver an acceptable update to the language standard, JavaScript has benefited over the past few years from other changes in the browser technology space. Browser vendors have implemented radically more efficient JavaScript runtimes and hope to eventually deliver performance that rivals native code. Consistency between JavaScript implementations has also greatly improved. Browser vendors have embraced shorter development cycles, ensuring that performance improvements and emerging standards reach end users faster than ever before.

This confluence of positive factors has made JavaScript a healthier part of the Web technology stack. The programming language is in a better position than before to keep up with the demanding requirements of next-generation Web applications.

Despite all of the progress that has been made over the past few years, Google takes the view that JavaScript's limitations are too fundamental to be overcome through revisions. The search giant wants a clean break and a new language, designed from the ground up for Web development.

Google is creating the new Dart programming language to "leapfrog" JavaScript and deliver a better-designed alternative that the company wants to eventually see integrated into Web browsers. An internal Google memo authored by Google's Mark Miller describes the rationale behind Dart, stressing the technical weaknesses of the Web as a platform and the need for a more competitive development stack.

"Complex web apps—the kind that Google specializes in—are struggling against the platform and working with a language that cannot be tooled and has inherent performance problems. Even smaller-scale apps written by hobbyist developers have to navigate a confusing labyrinth of frameworks and incompatible design patterns," the memo said. "The emergence of compelling alternative platforms like iOS has meant that the web platform must compete on its merits, not just its reach. Javascript as it exists today will likely not be a viable solution long-term."

To address this challenge, Google imagines a two-pronged approach: improving the existing JavaScript language through the standards process and simultaneously developing an eventual replacement. Miller's memo strongly emphasizes the importance of both approaches—which he views as complementary and interdependent, contending that each one in isolation would likely fail.

Google recognizes that developing a new language, moving it through the standards process, and winning the support of other browser vendors is going to take an extremely long time. Even with an optimistic timeline, a new scripting language for the Web that is introduced today could easily take six or seven years to see widespread adoption.

As Google sees it, working with other browser vendors to continue improving the JavaScript standard is necessary so that Web programming won't stagnate while Dart is maturing. Miller also points out that a strengthened JavaScript will be the only fallback position if Dart fails.

Google's technical plan is to start by implementing a compiler that translates Dart code into JavaScript. This is similar to how CoffeeScript and other existing third-party Web languages are already used. As Dart matures, Google plans to natively support the programming language in Chrome and persuade other browser vendors to support it, too. The memo says that third-party developers who start using the language will be able to continue relying on the compiler in the event that other browser vendors decide not to bake in support for the language.

As the language stabilizes, Google intends to work with standards bodies to open the language and formalize the specification. The search giant also intends to eventually expand it to other problem domains, including server-side development and mobile programming. Miller even hints that it could eventually be used on the Android mobile platform.

Governance

Although the notion of pursuing a clean break and introducing a new client-side programming language for the Web is intriguing, it's also highly problematic. A new language to supplant JavaScript would have extraordinarily far-reaching implications for the Web. As such, it would need to be created in a manner that reflects that gravity: complete transparency and broad collaboration with other stakeholders.

Google has already hit a foul ball on that front, because the Dart language and baseline requirements were drafted entirely behind closed doors. The fact that the Web development community and other browser vendors had to find out about this plan through a leak is deeply troubling. It is simply not reasonable for one team to unilaterally redefine the rules of the game halfway through the season and expect all of the other teams to play along.

The open governance model of the Web has been vital to its survival and is equally essential to its future sustainability. A programming language that is defined and controlled by one vendor is neither desirable nor appropriate for the Web at this stage in its evolution. Google's poor track record on open governance makes it difficult to place faith in the company's motives and trust it to be a responsible steward of a critically important Web technology.

282 Reader Comments

Funny how Google known for or believed to be most closely aligned with open software is now behaving like a vendor of proprietary software while the reverse is true of Microsoft. This thread should be an interesting battle where Microsoft supporters are on the open standards side and Google supporters are playing the role that Microsoft used to fill in a previous decade.

Funny how Google known for or believed to be most closely aligned with open software is now behaving like a vendor of proprietary software while the reverse is true of Microsoft. This thread should be an interesting battle where Microsoft supporters are on the open standards side and Google supporters are playing the role that Microsoft used to fill in a previous decade.

I doubt Microsoft loves Javascript either, but for any new technology to recieve widespread adoption, it has to have widespread web adoption. That means Google will have to fight the battle or win over the other vendors to their cause.

Bravo, Google. Javascript has had its time, and it's a cute little language, but it should no longer be the only language available to web developers, considering that:

1. browser-based apps are getting more and more complex.2. Javascript lacks critical features to ensure safe and correct code in large apps.3. Javascript is not adapting to these needs because of the glacial pace of design-by-committee. (RIP ECMAscript 4.0)

I think Google did the best thing by not involving large "open" committees in these decisions. Sometimes you just have to make the first move and let people catch on to good ideas. As long as they open the spec and don't try to charge royalties or such bullshit, then I don't care about the origination of the design.

Just last year I was talking with a work friend and wishing there was a modular plug-in system for alternate browser languages. Sounds like Google is doing its best to make that a reality. (eventually) The intermediate step of transcoding everything into Javascript will help ease the transition until other browsers figure out that one web language is no longer sufficient for today's needs.

PS Google.. don't just throw this at the wall and then abandon it. You need to stand behind your initiatives!

ANYTHING is better than javascript. Glad to see somebody with clout on the web try this. I am so disappointed with "standards body". Often, I really think they exist for themselves.

I disagree wholeheartedly.

A fragmented web is not better than javascript.

The problem with the standards process for the web, regardless of forum, appears to be simple: everything seems to require 100% consensus to move forward. Whether its Google, MS, Apple, Mozilla, or Opera, all of the players seem to have veto power over anything in the standards bodies. The result is far too much compromise instead of progress.

Heres hoping that Google can nail it. And after we've gotten rid of the abomination known as JavaScript lets move on the some of those 200 meg install files just to read a damn PDF file. And then Quicktime, and after that......

Anyways, its nice to see someone working to shake up the established offerings.

Every project I've worked on in my career has had at least some components of Javascript.. but I definitely think there is a lot wrong with it.

Ignoring the open/closed issues and whether Google is trying to hijack the web we could do a lot better then javascript IMO.

That said.. Google could be going in the complete opposite direction of what I think would be needed. My problem with javascript is it is often handed over to novice or complete "non-developers", and the language doesn't force them into any sort of proper coding practices, so they end up creating horrorshows of poorly documented and implemented components. Sometimes a bit more restriction in a language is a good thing. But Google could be going down the path of a language that is even more tolerant of hacks & poor practices so it is too early to know if what they're doing is a good thing.

I like some of these projects but a lot of the things they are trying to improve on are open and they can push the changes through a standards body.

That takes forever. It is more fun to see them spend some of their clout implementing improvements the "community" have been screaming for years. If it fails, it goes straight to the memory hole and the community does not have to care. If a standards body fail, though, that is pretty much end of it.

Bravo, Google. Javascript has had its time, and it's a cute little language, but it should no longer be the only language available to web developers, considering that:

1. browser-based apps are getting more and more complex.2. Javascript lacks critical features to ensure safe and correct code in large apps.3. Javascript is not adapting to these needs because of the glacial pace of design-by-committee. (RIP ECMAscript 4.0)

I think Google did the best thing by not involving large "open" committees in these decisions. Sometimes you just have to make the first move and let people catch on to good ideas. As long as they open the spec and don't try to charge royalties or such bullshit, then I don't care about the origination of the design.

Just last year I was talking with a work friend and wishing there was a modular plug-in system for alternate browser languages. Sounds like Google is doing its best to make that a reality. (eventually) The intermediate step of transcoding everything into Javascript will help ease the transition until other browsers figure out that one web language is no longer sufficient for today's needs.

PS Google.. don't just throw this at the wall and then abandon it. You need to stand behind your initiatives!

That is why I like the NaCl initiative, it provides a proper compilation target for languages, unlike JavaScript, so nearly any language can be used effectively.

ANYTHING is better than javascript. Glad to see somebody with clout on the web try this. I am so disappointed with "standards body". Often, I really think they exist for themselves.

I disagree wholeheartedly.

A fragmented web is not better than javascript.

The problem with the standards process for the web, regardless of forum, appears to be simple: everything seems to require 100% consensus to move forward. Whether its Google, MS, Apple, Mozilla, or Opera, all of the players seem to have veto power over anything in the standards bodies. The result is far too much compromise instead of progress.

I dunno know. The downsides of fragmentation may not be as bad when just about all browsers have plug-in architectures and getting a plug-in is really just as easy as getting a phone "app".

And, if nothing else, a viable alternative could serve a strong prod for standard bodies to come on already or risk irrelevance.

"A new language to supplant JavaScript would have extraordinarily far-reaching implications for the Web. As such, it would need to be created in a manner that reflects that gravity: complete transparency and broad collaboration with other stakeholders."

I don't know if I agree with this statement. I'm not sure if 'designed by committee' is the best way to design a language Ada comes to mind, and, come to think of it, Javascript enhancements--isn't that how we got into this mess in the first place?

It is probably best if it is designed by a small core of dedicated developers, but otherwise kept from prying and kibitzing eyes. When it looks like they have something useful, then show it to the world. If it is good, it will be adopted. Otherwise it will die on its own despite Google's best efforts.

Eich originally created JavaScript in 1995 while at Netscape. The language was submitted to ECMA for standardization the following year.

...

"That a 'clean break' is required to make significant improvements is nonsense, a thin rationale for going it alone rather than cooperating fully. The big issue I have with Dart... is whether Google forks the web developer community, not just its own paid developers, with Dart, and thereby fragments web content," he [Eich] wrote in reply to a Hackers News reader comment. "The standards process requires good social relations and philosophical balance among the participating competitors. Google's approach with Dart is thus pretty much all wrong and doomed to leave Dart in excellent yet non-standardized and non-interoperable implementation status."

So Eich wrote javascript in-house at Netscape without consulting Microsoft or Spyglass then presented the results as a fait accompli to the standards body. Now all of a sudden he is crying foul when someone else wants to do the same thing?

Harmony just isn't going to cut it. There is no hint of language support for multithreaded apps. Single thread performance is hitting a wall.

Sounds like people are making a mountain out of a molehill. If the timeline for Dart is really in the 6+ year range, it's likely that it will be in the public's hands for a good chunk of that, not just developed behind Google's closed doors. OK, so Google's putting the basic stuff together before releasing it, but everyone should have plenty of time to tinker with it and make sure the final standard meets their needs.

And in the meanwhile, Google has stated its support for improving Javascript, so it's not like Google is trying to overtake it with Dart. I really don't see the problem here.

This article is a rant. I can't see how you can get from 'Google wants to support BOTH javascript AND develop a new language' to raking them over the coals for everything under the sun. To date, they have been THE company to push javascript. The whole javascript speed race was started by them with v8, Chrome and their html5 experiments. node.js runs on Google technology (somehow Paul still uses it to attack them), i.e. the v8 javascript engine.

If Google, having been the absolute leader in javascript technology with every incentive to push it thinks it needs serious overhauling for technical reasons, maybe they're right. Comparing them to MS 'lock-in' is nonsense - MS wanted everyone to use their Operating System - Google's wants people to use the internet for rich apps (oh noooooo!) I kind of don't see the downside. The comparison is ludicrous and doesn't make any sense if you think about it for more than 10 seconds.

Ars is quickly becoming a meme-bulletin board. I guarantee if this was Javascript vs. C++, the comments would be full of people claiming how crap Javascript is for technical reasons. It's happened before. But because its Google v. Javascript, we get intelligent rants of 'google sux' by bandwagon jumpers and people piling on who wouldn't know the DOM if it hit em in the ass.

Basically, Ryan Paul has an ideological chip on his shoulder about Google because they don't use the open development model, but merely release the source after developing things behind doors. Because of that, you'll get these frothy rants every time his editor asks him to write about Google, even if its Google giving puppies to babies. Consider the source.

Ha ha, and this will be incorporated in Internet Explorer verson...? No, didn't think so.

Also for those who think Javascript has to go, you should probably watch the "Crockford on Javascript" series of videos available here: http://yuiblog.com/crockford/

They are by Douglas Crockford, author of jsLint and in general one of the biggest authorities on JS today and may open your eyes a bit more regarding what Javascript is and isn't. The problems that you perceive are more related to the mess in browser DOM implementaton than in the JS language itself. But anyway, have a look at the videos (first video is just the history of programming languages and doesn't have much to do with JS, so feel free to skip it if doesn't interest you; videos are about 90 minutes each).

"A new language to supplant JavaScript would have extraordinarily far-reaching implications for the Web. As such, it would need to be created in a manner that reflects that gravity: complete transparency and broad collaboration with other stakeholders."

I don't know if I agree with this statement. I'm not sure if 'designed by committee' is the best way to design a language Ada comes to mind, and, come to think of it, Javascript enhancements--isn't that how we got into this mess in the first place?

It is probably best if it is designed by a small core of dedicated developers, but otherwise kept from prying and kibitzing eyes. When it looks like they have something useful, then show it to the world. If it is good, it will be adopted. Otherwise it will die on its own despite Google's best efforts.

My thoughts exactly. I think we have seen the limits of openness and community processes. As long as it is free (in every sense), then that what does it matter that it was developed by evil geniuses in their mothers basement. Let the community at large judge the merits instead of waiting on a standards body.

I despise Javascript and don't believe it is well suited to the kinds of large projects people are starting to use it for, especially compared to things like C#, Python, and Ruby. While at this point it's obviously impossible to say whether Dart will be better, I think it stands a very good chance of it. While Javascript is not intrinsically a terrible scripting language (although it doesn't hold a candle to Ruby or Python), it's flexibility and oddness compared to everything else makes it hard to learn, and even harder to debug. While all languages allow programmers to write bad code, Javascript makes bad code the default.

As to the bitching about Google pushing it and not playing nice with the committees, it's a necessary evil. Someone has to really put their weight behind a new tech to get it supported on the web these days, and given Microsoft's still tattered web reputation, Google is likely the only company who even stands a chance of pulling it off. Design by committee is a terrible thing for a language, and I can say with confidence that I don't think any of the current standards committees could create a new language from scratch that can compete. They (kind of) work for maintenance, but there has to be a strong vision and steady hand to get things off the ground. Someone has to be able to say "No." and end discussion, that never happens on committees.