Home Dart is to JavaScript as C# is to C++

Dart is to JavaScript as C# is to C++

Given the background of Lars Bak, the Google engineer whose V8 JavaScript interpreter upended Firefox’s claim on speed, it was reasonable to suspect Google’s new Web development language might look a lot like Smalltalk. But that might have taken the Web in a strange and different direction. Today, on the day of a Web developers’ conference in Denmark, Google and members of the Chromium open source development team raised the curtain on Dart, the company’s bid for a new and somewhat more structured approach to Web programming.

Making Dart work will require a new virtual machine, which puts it on a competitive plane with Java, Adobe Flash, and Microsoft Silverlight. But architecturally speaking, Dart will be more dependent on the browser, at least for now.

Google’s plan is to implement the Dart virtual machine as a kind of supplement to the browser’s existing JavaScript engine. In other words, it will digest Dart code and produce JavaScript. Google is being careful not to mention an eventuality where Dart is embedded in all browsers, though in a blog post this morning, Bak did mention that with respect to integrating the Dart VM in Google Chrome, “we plan to explore this option.”

At last, class

The reason for Dart’s existence appears to be to improve upon JavaScript, whose viability as the functional backbone for distributed applications in the “open Web” seems shakier as time goes on. Compared to more structured, object-oriented languages like C# and Java, JavaScript often carries with it a lot of duct tape and baling wire. And compared to more clever dynamic languages like Python, Ruby, and D, JavaScript is more verbose, and doesn’t get to the point quickly enough.

As the first round of Dart tutorials reveals, Bak and his team of architects started from a JavaScript base and worked from there, adding some critical Java elements and improving the underlying assumptions of the interpreter to enable brevity. True class structures, using the class keyword familiar to Java developers, is the key addition.

With JavaScript, there are a handful of ways to get something object-ish, all of which use the keyword function. You can declare a function which happens to have properties, and whose function is embedded therein as a kind of method. The problem with that is that the method itself doesn’t get re-used but rather recreated each time, so the alternative is to add the method back to the function’s prototype as a kind of bolt-on. Alternately, you can declare a kind of object using the all-purpose instantiator var, which may use literals to define internal structures. You then assign a function as a method for one of those literals as though it were a variable value. Or, you could declare a var and assign the whole thing the result of a function, assuming that function were to be the only component of the object.

None of these methods is particularly elegant. A great deal of the work performed by the latest generation of JavaScript engines such as V8 and Mozilla’s TraceMonkey is actually made up of condensing the “crap code” that inelegant instructions produce, into something less entangled and more precise.

So theoretically, the performance hit incurred by a browser running the Dart VM may be compensated for, by way of code that’s easier for the JS interpreter to parse. Theoretically.

Dart reintroduces class in a way that will be familiar to most Java programmers. A few tweaks make the definitions more concise; for example, the reflexive pointer this may be used inside the declarative for a member method (as in Ball.throw (this.distance); instead of Ball.throw (distance); this.distance = distance;). And interface is also supported for creating member properties and methods that may be common to more than one class; a class implements an interface just as you’d expect.

Still unknown: event triggers

One dramatic structural change to which some JS developers might object concerns context. JavaScript functions are often pasted throughout the page, and although somewhere within it is supposed to be a main() function, most functions are triggered by browser events, including window.onload. With Dart, every <script> element is a self-contained context. Class members and variables are considered public by default (there’s no “public” keyword in Dart), although “public” for Dart is not a scope that encompasses the entire page – just the script.

“In JavaScript, declarations across multiple script tags are combined together in the same namespace,” write Sigmund Cherem and Vijay Menon this morning. “In Dart, code in one script tag cannot directly access code defined in another. If a script wishes to load code from a different URL, it must do so via #import. Each script tag must define its own main() entry point in order to run.”

The main() function is the event handler for the DOMContentLoaded event. Otherwise, we’re not seeing from the early documentation any indication of how Dart code responds to browser events the way JavaScript code does. If Dart makes no changes at all, then it’s foreseeable that, while nothing runs until the DOM is loaded, the main() function could be written as empty while the other functions respond to events – which is about as inelegant as most everything else in JavaScript.

But conceivably, this scheme could facilitate a fairly simple and straightforward approach to multithreading: A page could have multiple scripts, and the VM could run them in parallel… again, theoretically, according to the early documentation. Browsers don’t have multithreading interpreters yet, and Dart is not described thus far as something that will include a JS interpreter, so it’s difficult to see how Dart would invoke a feature that doesn’t actually exist.

Nevertheless, from an architectural standpoint, there’s a lot to like about Dart, and there’s reason to believe its wealth of opportunity will be spread among multiple browsers, including even Internet Explorer. What remains to be seen is how Dart will impact browser-free HTML5 apps, or “native apps,” if at all. We’ll be monitoring the news from the developers’ conferences as well as from Google itself this week.

About ReadWrite’s Editorial Process

The ReadWrite Editorial policy involves closely monitoring the tech industry for major developments, new product launches, AI breakthroughs, video game releases and other newsworthy events. Editors assign relevant stories to staff writers or freelance contributors with expertise in each particular topic area. Before publication, articles go through a rigorous round of editing for accuracy, clarity, and to ensure adherence to ReadWrite's style guidelines.

Get the biggest tech headlines of the day delivered to your inbox

    By signing up, you agree to our Terms and Privacy Policy. Unsubscribe anytime.

    Tech News

    Explore the latest in tech with our Tech News. We cut through the noise for concise, relevant updates, keeping you informed about the rapidly evolving tech landscape with curated content that separates signal from noise.

    In-Depth Tech Stories

    Explore tech impact in In-Depth Stories. Narrative data journalism offers comprehensive analyses, revealing stories behind data. Understand industry trends for a deeper perspective on tech's intricate relationships with society.

    Expert Reviews

    Empower decisions with Expert Reviews, merging industry expertise and insightful analysis. Delve into tech intricacies, get the best deals, and stay ahead with our trustworthy guide to navigating the ever-changing tech market.