Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

First look: Google Dart vs. JavaScript

Dart nails some of Web programming's worst pet peeves, but is it good enough to beat JavaScript?

By Peter Wayner, InfoWorld, 11/23/11

Let's begin with the good news. Google's Dart is a modern, full-featured tool designed by grabbing the best features of Java, JavaScript, and C. The development team is obviously large, and the samples show they have the ambition and talent to create a system that will power desktop, mobile, and browser applications in the future. The tools are real, and the path to gaining widespread acceptance is one that Google can travel. The platform works.

There really isn't any obvious bad news, but there is plenty of cold, hard reality that appears after one plays with the code for a bit. The documentation is upbeat and highlights how Dart is fixing the pet peeves of the Dart creators -- peeves that many of us probably share. But the Dart developers are not superhumans, and they did not find new breakthroughs to taming the way that software turns into a jungle of vines. At best, it's not even clear that they did more than remove some hard corners and smooth over some rough edges. Their fixes work for them, but like all fixes in laws and software, they're bound to create new problems down the road.

[ Also on InfoWorld: Google Dart hits a bull's-eye for Web developers | Beyond jQuery: JavaScript tools for the HTML5 generation | See if you can pass InfoWorld's programming IQ test, round 1 and programming IQ test, round 2. | Get software development news and insights from InfoWorld's Developer World newsletter. ]

How will you feel about this? Programming languages are great topics for debate, and your opinion of Dart will depend heavily on your tastes. It is largely a mixture of JavaScript and Java, so anyone who feels comfortable with those languages will feel at home with Dart. There are moments when you feel like you're coding in JavaScript, and there are moments when you are living with constructs from the Java API. The team clearly went out of its way to stick with familar structures to make it simple for programmers to adopt Dart.

Many of the decisions the Dart developers made are likely to be cheered by most JavaScript and Java programmers. Other changes will be seen as great victories by some and grave mistakes by others. Still others look like advances, but I think they create even more problems than they solve. Naturally, you might feel differently.

Any differences of opinion about Dart, though, aren't likely to be crippling. Switching to Dart from JavaScript or Java isn't much of a leap. There are no radical decisions or dogmatic structural impositions -- indeed, you can pretty much ignore the features you don't like because the developers aren't on a quest to convert you. While each of us will be able to find fault with something, no one should find anything noxious enough to be a deal breaker.

Google Dart: Art of the familiar
Before I give my opinion about the type system in Dart, I want to explain that I began this project after spending two solid days trying to chase down a crashing bug in an Objective-C program that appeared after I upgraded a library. My code didn't change, but it started crashing in one small, yet crucial corner. The new version of the library renamed one of the objects that my code used as a base class, but I never noticed. The Objective-C compiler probably noticed, but it didn't bother to tell me it couldn't find that base class anymore. Nope -- it built my code and gave me a high five, perhaps because someone thought that the word "objective" means not sticking your nose into others' conflicts or taking sides of any kind. After a few days of fiddling, I found the conflict and the code stopped crashing.

For more enterprise computing news, visit InfoWorld. Story copyright InfoWorld Media Group, Inc.