Google Dart – Should JavaScript be Replaced?

September 27th, 2011 by Mike Wilcox

A memo from a Google employee was leaked earlier this month exposing the new plan for Dart, which they claim to be a new programming language for structured web programming. The memo goes into some detail on what Dart would be, but doesn’t go into much detail on why Dart should be. In other words, it doesn’t explicitly state the deficiencies in JavaScript. Do they have a point? Should JavaScript be replaced?

Dart to replace JavaScript?

Precedence

You already can run other languages in a browser. There is a TCL plugin; IE has VB Script; and there is also C# in the form of Silverlight. And who can forget the most popular plugin and language on the web today…. Java FX!?

Flash is the obvious precedent, since at one time in the early 2000′s it actually did replace JavaScript. However, since then we’ve had HTML5 with new language APIs, a new and improved browser war with faster engines, and Harmony with buy-in from all the browser vendors.

Flash is also a good example of how you can reach too far. Flash has and has had many impressive features, but a lot of these were later hindered by internet security issues. So we can, for example, wish for a browser language with access to the local file system, but that’s not going to happen. So what then can we wish for?

What is not the problem

One thing I don’t want to see is strict typing. Okay, maybe a little bit of optionally typed variables, preferably in vectors or typed arrays for speeding up Canvas and 3D. Otherwise, loose typing is what makes JavaScript so versatile. AS3 went to a rigid, Java-like syntax, and it’s not very fun to code.

As we all know, JavaScript is not the problem nor bottleneck in web page performance. It’s the DOM, browser compatibility, and server requests. This narrows down the situation to pure language features. HTML5 has added features that make JavaScript more robust than ever. Workers are a simple API (though more difficult in practice) that allow multiple threads for unprecedented scripting power. They also added Storage, so now we don’t have to suffer at the hands of a 4K cookie. Once Web Sockets security is figured out, giving us faster and more consistent server connections, what more do we need?

Structure

I love the lack of structure and wild west nature of developing in JavaScript. But realistically, it’s very difficult for devs to jump between different libraries like jQuery, MooTools or Dojo. This is a delicate balancing act however, because JavaScript is already a great language and the task is to make it better, not more restrictive. Any structural code changes need to be optional.

Modules

It’s flabbergasting to me that CSS has @import and JavaScript doesn’t. I think that can only be explain with “What the Hell?” Dojo’s bread and butter is its script loader — solving a problem that shouldn’t be there in the first place.

Packages

The unique thing about a Flash movie SWF is that it is a self contained file that can include all the necessary resources, minimizing or eliminating multiple server requests. JavaScript has no such ability, save some real kludgy experiments. Mozilla is addressing this issue with their Resource Packages Proposal.

Classes

Yes, JavaScript has prototypes and we have our syntactic sugar to give us inheritance, but again, it’s hard to write standardized code. jQuery, MooTools and Dojo all address this limitation is vastly different ways, fracturing web development.

Fix this!

It would be nice if ‘this’ were optional. Object oriented code is a bit discouraging in JavaScript because you are punished with tens of hundreds of ‘this’ keywords peppered throughout your code, which bloats it and doesn’t help readability. It also hampers newbie developers who have trouble grokking the concept of context invoked functions (like say, calling an object method from a setTimeout). Adobe claims to have fixed ‘this’ in ActionScript 3.0… but not really. ActionScript is essentially Java with JavaScript mashed on top of it. When you write actual ECMAScript in an ActionScript file, you need to use ‘this’ or the compiler gets confused.

What I’m suggesting would require the co-mingling of context and scope. The variable search would start with the initially scoped function, then the object and prototype chain, then the remainder of the scope chain. Would this implementation affect performance? When I write a JavaScript engine I’ll let you know! Until then, I’m punting to the browser vendors!

Protected Variables

Yes, everyone wants their precious private variables, but I’m on record for not being a fan, as I feel they are over used and abused. Protected variables on the other hand, give you the best of both worlds: the public API can be exposed as the clear intent, and the protected variables and methods can only be accessed or changed if the class is extended to explicitly override them. If you want to change my library code you need to work for it, yo!

Maff

Yes, I’m referring to the fact that .1 + .2 = 0.30000000000000004. I understand that it’s common problem in floating point numbers using binary digits. I also concede that this situation rarely is an issue for me, because I do largely graphical work, not work that requires extreme numerical accuracy like accounting. Regardless, a new Math namespace would be a welcome addition, and even better, it could be a strictly typed namespace that allows only floating point numbers.

Tooling

The Google memo says that one major problem with JavaScript is the lack of ability to “tool it”. Not being a server side programmer (and when I play one on TV, I use PHP), I’m not familiar with these tools, or lack thereof. But I’m guessing they are referring to the loose and dynamic nature of JavaScript not allowing an IDE like Eclipse to track objects and report broken code. I’m going to punt a little bit here, and claim: the lack of tools forces you to write better, loosely coupled, encapsulated code. Tools make you lazy! I can hammer in nails with my forehead and drive screws with my teeth! Raaawarr!

Standards Politics

At first glance it may seem to be a great benefit to develop a language outside of the W3C and their sometimes draconian politics, their self centered policies, and their ability to take a great idea and turn it into a shitty one. Lots of languages are written, but only a few catch on. For every great language like Python, you get several like DOS, LotusScript, Authorware, Lingo, or Cold Fusion — or any other Macromedia derived language. Speaking of Macromedia, the early Flash scripting language was proprietary, cumbersome, and unusable. They switched to an ECMAScript-based syntax, and ActionScript exploded with success.

Believe me, I’m not championing the standards body that almost killed off HTML. Nor am I saying that designing a language by committee is a good idea. It’s just that you are fighting an uphill battle if you throw out the standards and start from scratch, even if it’s a better idea. The US System of Measurements is an example of design by a committee of retarded orangutangs flinging their feces at finger paintings to make their discussions — yet the Metric System was not widely adopted. Yet while Python was invented by one guy, it evolved in an open source community.

Conclusion

Can JavaScript be replaced? My guess is at worst never, and at best ten plus years. JavaScript developers are very protective of their domain, sometimes to a fault, and they don’t appear to be very welcoming of changes; they often are even averse to Harmony proposals. New technologies require a killer app in order to catch on. Flash had YouTube, Silverlight had NetFlix, and Java FX had… well, I rest my case. Since Dart has corporate giant Google behind it, a killer app is definitely not out of the question. And if so, the big brains at Google could make this happen.

8 Responses to “Google Dart – Should JavaScript be Replaced?”

  1. [...] Google Dart – Should JavaScript be Replaced? [...]

  2. [...] A Disaster http://www.businessinsider.com/google-motorola-deal-2011-8        There is a flurry of news in the media about Google's acquisition of Motorola Mobility. According to…sition, Google enters the mobile hardware space competing directly with its own Nexus brand (that is [...]

  3. Syntactic sugar for classes? Did you mean “new” or the next, maybe in your lifetime, JavaScript? “new” is not sugar. It’s the only way we have of assigning to [[prototype]]. (Why [[prototype]] isn’t an explicit property I can’t figure out.)

    Maff – In a previous incarnation, I ran the quant group at an American investment bank. (Screwed up my karma and came back as a human. Oh well.) Money works well in integers, not floating point. In the US that meant doing all our work in pennies and then sneaking a “.” into the final output. In dollars you can’t have three equal payments totaling $1, or $1 billion. Integers rule. You want 64-bit integer arithmetic.

  4. Mike Wilcox says:

    Sugar…
    JS has inheritance, but it’s awkward and singular:

    var Foo = function(){}
    var Bar = function(){}
    var Extension = {};
    Foo.prototype = Extension;
    Bar.prototype = Extension;

    So we got that much, but what if I want to use ExtensionTwo? Or what if I want Foo to extend Bar – and both constructors to fire? That’s the stuff that needs sugar and is inconsistent.

    All integers? Great tip! You gave me a different way to approach those kind of problems.

  5. Did I mention that it was a really good article?

    Martin

  6. You can understand why JavaScript developers are so protective of their domain – it took about a decade to learn about all it’s idiosyncrasies (and those associated with DOM scripting). Will the language that replaces it be much better, or will we have another decade of learning about it’s problems?

  7. The metric system, not widely used? Uhm. What planet are you from? It’s the standard system in all countries in the world, except for three.

    But it does show that bad habits are hard to change ;-)

    The rest was a truly good read :-)