First look: Google Dart vs. JavaScript

Dart fixes a number of problems with Web programming, but introduces new problems of its own

By Peter Wayner, InfoWorld |  Development

Dart's simplicity is not always an advantage either. The Dart team tossed away the word "function" from the declaration of a function; now all you need to do is list the parameters between parentheses. As I read the Dart code, I found myself thinking like a parser to determine whether the parentheses were declaring a function or acting algebraically. The word "function" may be a pain to type repeatedly, but it's a helpful marker when you're reading the code. What speed we gain when writing the code, we lose when reading it. (Of course if you're really going to ignore the type system, you can just create a new class called "function" and have every method return it.)

It may be my inexperience with Dart, but at times I felt like I was dealing with the same kind of mad geniuses that invented Lisp or APL. They too worshipped the beauty of some minimal collection of keystrokes that were actually intricate mechanisms delivering the answer with deft precision. Yet those languages have been disasters in corporate environments. The fun that lone programmers can have with clever code tropes can't make up for the confusion that everyone else in the team feels until they figure out the inside move.

Google Dart: A cleaner Web Not all of the moves will have this effect. Almost everyone I know who writes JavaScript for the Web also uses a library like jQuery to smooth out the differences among browsers. I'm sure every one of them also wonders why someone hasn't made jQuery part of the official JavaScript spec or permanently baked it into the browser.

The developers of Dart heard these cries and added most of the goodness from these libraries to Dart. They've gotten rid of the lengthy names like getElementsByTagName and replaced them with a catch-all function called query that takes jQuery-like parameters to find what you want.

They've also smoothed out the internal data structures describing the DOM. The fields of each DOM element now use standard data structures. That means you don't need to remember method calls like hasChildNodes and firstChild. You just need to know that there's a field "node" that responds to the standard collection methods. These seem like perfectly obvious solutions and I'm thrilled with them.

But I'm not as thrilled as some Dart developers are about the way the team cleaned up the event connection code. The old way of simply putting an extra attribute like onclick into the HTML tag is gone. Now you have to add event listeners to the DOM element in the Dart code. The Dart team argues that this is cleaner because you might want to have several functions receiving the events.


Originally published on InfoWorld |  Click here to read the original story.
Join us:
Facebook

Twitter

Pinterest

Tumblr

LinkedIn

Google+

Answers - Powered by ITworld

ITworld Answers helps you solve problems and share expertise. Ask a question or take a crack at answering the new questions below.

Join us:
Facebook

Twitter

Pinterest

Tumblr

LinkedIn

Google+

Ask a Question
randomness