Can Google's Dart successfully replace JavaScript?

Google is developing a programming language called Dart that is ultimately intended to replace JavaScript that has fundamental problems which cannot be fixed. Also, Dart is designed to make a clean break away from JavaScript, so it is not backwards compatible with JavaScript. Can such a radical technology shift succeed on the Web?

Will Dart's radical shift break the Web?

For years, browser vendors have told us that Web technology must evolve smoothly. If not the Web could break. This was the argument that killed development of XHTML2, a markup language meant to replace HTML that has fundamental problems that cannot be fixed. Dart will be the same type of radical departure from JavaScript that XHTML2 was from HTML. So will Dart break the Web in the same way that XHTML2 was predicted to do? Or have we accepted that backwards compatibility must be built into browsers, not into programming/markup languages?

Does JavaScript have problems?

In the last few years, JavaScript has received a lot of praise for its massive performance improvements, new libraries and new APIs. So if JavaScript is so wonderful, why do we need to replace it?

The most serious problem is that JavaScript applications are inherently insecure and are vulnerable to mischief, attacks and data theft. JavaScript lacks the rich class libraries for features such as advanced drawing, encoding, encryption, network communication, etc. found in Java and .NET.

JavaScript applications are built from loosely coupled technologies, often by non-traditional programmers. The inevitable result is spaghetti code - code is complex, tangled, and full of workarounds for browser versions/bugs or shortcomings in the technology.

Most of the time (and so most of the money) spent developing applications is consumed by debugging. It is not possible to create an Integrated Development Environment (IDE) on par with Visual Studio or Xcode for JavaScript apps. This makes debugging such JavaScript applications far more difficult than comparable desktop applications. Also, JavaScript is an interpreted and loosely-typed language, which also increases the complexity of debugging. This means that the development of sophisticated JavaScript applications requires larger development teams, more time, and more money.

Is Dart's future shaped by technology or politics?

Assuming that Google Dart is technologically superior to JavaScript, can this fact alone make it successful, or will Google's hopes for this technology be dashed? Will Google Dart suffer the same fate as W3C's XHTML2?

Google Dart is off to a really bad start. The main problem is that Dart is being developed by a single vendor. Google's intentions would not have been put into question had they partnered with other vendors to develop this technology. Granted, Google does recognize that support from other browser vendors is important, since it plans to "sweet talk" them into supporting the new programming language. But do they have any plans to sweet talk us, the application developers, who are after all the ones that will have to learn a new language and new associated tools?

Conclusion

Google Dart aims to replace JavaScript in the same way that XHTML2 was designed to replace HTML. JavaScript does have technology problems that cannot be fixed, so there is a genuine need to replace it. But Google's unilateral, non-consultative approach presents it with some real challenges when it comes to convincing application developers to embrace Dart.

Public comments

1. Posted by Ege Özcan
on Wednesday 2011-09-14 at 06:22:01 PST

"JavaScript lacks the rich class libraries for features such as advanced drawing, encoding, encryption, network communication, etc. found in Java and .NET."

There are definitely not problems of the language but the platform it is running on. Drawing? Canvas element came and that problem is fixed. Encryption? Encryption of data should not be done on the client side in the first place. If server side, there are various libraries that do that. Network communication? See: AJAX. Anything you lack is about platforms (being browsers, for the web) supporting that functionality. Language is just a small convention between.

2. Posted by Mohammed Arif
on Wednesday 2011-09-14 at 09:54:51 PST

Google is following Microsoft way's now but anyway this new 'tool' so called Dart or Dash can't really replace JavaScript at all.

At the same time Google Devs working upon ECMA TC39 (the part of Ecma that works on ECMAScript.next) which is implementing prototype implementation and would be available soon and see JavaScript has been making tremendous progress and there are new things coming up soon.

One more point to make, even today's world we struggling for JS standards to make it compatible cross browsers for many years then how Google would really push the UA’s to adopt a new 'Tool' in their engine.

3. Posted by Robert
on Wednesday 2011-09-14 at 11:57:33 PST

JavaScript has some real limitations. Performance is a bit problem. The reason you will continue to see plug-ins like Flash or stuff to do 3D graphics or for playing games is because JavaScript and <canvas> cannot handle them.

It would be great to do encryption on the client. AJAX is limited to HTTP which is a stateless protocol. It would be nice to have a permanent connection between a client and server. Right now everything is a hack because of hidden AJAX calls to the server. I want to see a language (platform) that can compete with desktop apps. If Dart can deliver this, then it has a chance, otherwise it is dead of arrival.

4. Posted by Luis Gonzalez
on Wednesday 2011-09-14 at 14:43:50 PST

There interesting technical detail in all this story is the emergence and growing importance of transpilers (or trans-compilers).
Whatever Google or other companies try to impose as the future language for the web, developers (whether they like or not the new language, or the evolution of the existing javascript) will rely in their transpilers to make coding more amenable to their skills and preferences.

Google itself plans to take a double strategy: creating Dart, the new technology aimed to replace javascript, while improving javascript "harmony" and creating a transpiler (Dart -> Harmony) for those developers who want cross-browser compatibility.

A successful transpiler already exists, it fixes all the javascript annoyances and inconsistencies (it compiles down to fully compliant jslint code) and is gathering a loyal following amongst developers and hobbyists: Coffeescript.
This is not the only one. For example, the capuccino frameworks works on a superset of javascript, very similar to Objective-c (Objective-js).

Whatever happens with Dart, the future looks bright for developers for the first time since the web was created.

5. Posted by Paul Massey
on Wednesday 2011-09-14 at 14:51:14 PST

I really hope Google will be more successful with Dart than W3C was with XHTML2. Although I find it hypocrytical that Google helped kill XHTML2 on the same basis that it is trying to promote Dart.

6. Posted by Leif Halvard Silli
on Thursday 2011-09-15 at 07:10:12 PST

It is not always bad that a project starts out as a 'cabal'. Often it is good that agreing minds cooperate, in peace, before it becomes public. At least, it is often good for the projects themselves. I personally have bad experience from once inviting people to a project that wasn't ready to receive attention from disagreeing souls. And who hasn't? It is simply unrealistic to assume «full openness» always. Also, a thought that isn't thought through before it is presented, could risk fall dead to the ground.

And given the opposition Dart has met, it could sound as if it was neccessary - for the Dart project - to be worked out in peace ...

That said, I do of course understand the concerns about Google motifs and Google dominance and Google commitment to open standards, that many have raised. Also, the very idea, to repalce JavaScript, is something that very many will have opinons on, if one first is to replace JavaScript. — That said: this project, btw, increases the chances for a more serious discussion of that option.

Of course, Google's approach kind of demonstrates that a clean break with old technology, could be possible. And in that regard: Vlad, as for XHTML2, what did XHTML2 have to offer compared to what HTML5 served as XML can offer?

7. Posted by Vlad Alexander
on Thursday 2011-09-15 at 08:23:27 PST

Leif Halvard Silli wrote "Vlad, as for XHTML2, what did XHTML2 have to offer compared to what HTML5 served as XML can offer?"

To answer this question, first please see my interview with Steven Pemberton on XHTML2.

In addition, if everyone wrote HTML5 in the most accessible and semantically meaningful way, following best practices, then we would not need XHTML2. If everyone wrote JavaScript in the most efficient and secure way, then we would not need Dart. But people don't do that. What XHTML2 tried to do and what I believe Dart will do as well is to impose a new set of rules that everyone must follow in order to use the technology. The benefit of course is that computers will be able to process the technology more efficiently and it will become financially and technologically feasible for tool vendors to build cool tools that leverage the stable rules and predicable outcome imposed by the technology.

Comments are closed for this article.

Rebuilding The Web