Change happens gradually. Google knew that back in 2010 when, frustrated with perceived fundamental flaws in JavaScript, it first decided to create Dart, a more structured yet flexible programming language.

JavaScript was and still is entrenched as a lingua franca of sorts in Web development, but after three years of buildup and open-source collaboration, Dart looks to redefine the programming landscape.

(Dart’s release: Google says Dart 1.0 is ready for wide Web use)

Dart 1.0 has been widely available since November, and its documentation and tools are completely open source. The question now is whether Dart is all it’s cracked up to be. Whether the language sees more widespread adoption or not depends on the effectiveness of its development tools and resources, and how Dart’s changes in structure, syntax and libraries stack up against JavaScript.

Going off-scriptWhy Google created Dart
Dart was designed to make it easy to write modern app-development tools capable of high-performance implementations. Formerly known as Dash, Dart is a class-based, object-oriented language with C-style syntax that also comes with a programming environment, a set of libraries and a virtual machine.

According to Google software engineer and Dart co-creator Lars Bak, the Dart project started two and a half years ago with two distinct goals: increased programmer productivity, and faster execution. And he believes Dart has achieved them.

“There’s a very fast turnaround cycle from when you change the source code until when you run the code,” Bak said. “In our case, if you use the VM, we changed the source code to program right away. If you’re used to Java or another programming language where you have to go through tools before you can run the program, in Dart you can run them right away.”

Lowering that source code runtime threshold leaves Dart free of what Bak called defensive programming. He explained that when dealing with a long tool chain, developers often fall into the habit of playing it safe. They spend an inordinate amount of time examining the code before compiling and running the program, instead of having the freedom to experiment with code.