Google has revealed they are working on a new programming language, Google Dart, which one can surmise will be targeted at web development, likely on both the back end and front end. The first indication was the release of the speaking schedule for the Goto Conference in October, where two speakers will be presenting the keynote concerning this new language. If it turns out that Dart is in fact targeted at replacing Javascript on the front end, regardless of any other platform targets it might have, it is not going to transform the client side development experience without more support than just Google’s Chrome.

What is Google Dart Targeting, Really?

Based on an alleged leaked memo discussing a project codenamed “Dash”, it seems that Google is trying to supplant Javascript in the browser in order to fight the “encroachment of other, less open platforms”. This appears to be referring to native apps and in the case of mobile, iOS apps in particular. According to the “Dash memo”, the plan will be to have Dash cross compile to Javascript in order to continue to support Javascript centric browsers until such clients are capable of natively running Dash. The intent, then, is to create a new environment, entice developers to jump in and use it, and use that momentum to move vendors like Apple, Microsoft, Mozilla and Opera to incorporate Dart VMs in their browsers. There are some problems with this approach though.

A Twenty Mule Team

Google is going to be pulling against several different, very powerful forces if they make an attempt such as they seem to be undergoing. To begin with one of the problems they cite as a reason to consider Dart, a multitude of frameworks and libraries to perform various functions, is also one of the reasons many developers will want to stick with the language as they have already invested time and effort in learning and deploying these frameworks. Moreover, Google points to the use of myriad incompatible design patterns. Based on this statement, it suggests they want to perform some sort of enforcement over which patterns might be used or perhaps create alternative frameworks which use a common pattern and provide them as a means to allow developers to use a consistent set of frameworks. This suggests Google is looking to create “the One True Way” for web development by fiat rather than by allowing for the development of a standard which other entities might have a say in. If they were truly concerned about asserting the homogeneity of the Javascript ecosystem they would proffer their own such frameworks using compatible design patterns.

Then there are the other browsers. If you take a look at the speakers list as well as the list of sponsors, you will notice some absences. Namely any other browser vendor. Barring a last minute surprise, it doesn’t seem as though Dart has the backing of anyone but Google which means that the best we could hope for would be for Chrome to have Google Dart support out of the gate. Chrome is doing well, but Chrome alone will not be sufficient to convince the majority of developers to switch to its environment. What about the other vendors?

Microsoft has continued to release additional details about development on their upcoming platforms and it seems that it is going to focus on .NET and WinRS on the backend and for native code and use of HTML5/CSS/JS for UI development. It seems unlikely that Microsoft would have a great deal of concern for moving toward adoption of yet another VM for their front end functionality. Not to mention Microsoft has their own development toolchain which they want to see in use as opposed to a Google Dart based toolchain which would allow for more cross platform oriented development.

Apple, too, is focusing on HTML5/CSS/JS for support in their browsers and given the competition between iOS and Android, I wouldn’t imagine they would want to provide a leg up for developers to create apps using Google Dart that would function equally well on either platform. On top of that, Apple has already dealt with another company who owned a toolchain which focused on cross platform development. Adobe still has yet to compel Apple to release a Flash compatible update on iOS and in fact has started making overtures to the HTML5/CS/JS crowd through their announcement of Edge as well as the recent changes to their Flash Media Server to deliver alternative content to iOS devices on the fly. Apple isn’t going to let their major mobile competitor install a competing VM platform on iOS devices when that means that competitor will have a distinct edge in keeping support for it more featureful and up to date on Android.

Mozilla could possibly accept Google Dart as a native VM in their browsers, simply because they have the least to lose in such an arrangement. Unlike Microsoft and Apple, Mozilla as an organization is not pushing a competing development environment or toolchain, isn’t competing in the mobile space and in fact is really only going head to head with Google with regard to browser market share. Still, that may yet be reason enough not to jump in bed with Google. Plus unless Google Dart is made part of a standard of some kind, it’s possible that there will be even less traction in this space.

The same argument goes for Opera, perhaps even more so. Opera has a reputation for being one of the most standards compliant browsers available and again, unless Google Dart is made a standard, Opera may not wish to incorporate this VM into their product.

What’s the End Game?

Google isn’t stupid, so if it seems so obvious that uptake of Google Dart is going to be difficult to achieve, why bother? As the “Dash memo” points out, this is a high risk/high reward option. Given how many different projects Google has going at one time, creating a new VM to include in their browser and to make available for back end development isn’t asking much in terms of time and money. The risk is in the reputation. Google is going to put their name behind this and try to get developer muscle to push it into other browsers. In essence it is going to test how much weight they actually have to throw around. If it succeeds, they will have grabbed a commanding position, providing a toolchain which can target apps on their platforms to their liking and which other vendors would need to tailor their systems around. If it fails, it will be a sign that while they are big, they can’t yet force the other big players to play their game. High risk, high reward. I don’t see a bullseye in the making.

Image by renjith krishnan