Hi, Good questions.
1. What problems does Dart solve, what gap does it fill...?
Today you can do things in the browser that people wouldn't have thought possible 10, or perhaps even 5 years ago. JavaScript was able to provide interactivity to web pages, but coding web applications is complex. Not necessarily more complex than server-side applications, but on the server side you have the help of tools that we all take for granted - tools such as static analysis, break and continue debugging, refactoring - these were non-existent for building browser apps.
If you write your JavaScript in a particular style, then you can take advantage of modern JavaScript IDEs and other tools, but they can only go so far - because the language was never designed for collaborative, large-scale team development projects. Here's an example of some javascript
I come along and change function foo by removing parameter b:
But my call foo(1,2,3) is still a valid function call, even with the altered function signature foo(a,c). The application doesn't break, but something is wrong. Poor programmer Bob comes along in 6 months time, and who's to say which is correct - the function or the call?
Building server-side applications, we're spoiled by the wealth of tools to detect these errors at the
time the code changes. Sure, in an ideal world, you would have 100%
unit test coverage of your client-side JavaScript. Sure, in an ideal world, we'd all be uber-experts in every JavaScript API we came across,
and keep track of the breaking changes between versions. Sure, in an ideal world, we'd always be able to hire other uber-experts to work on our projects.
This is just one example that developers face every day with JavaScript. You can fix parts of it with commenting, code-reviews, unit-testing and more, but why not let the tools do some of this work (Answer, because JavaScript is
so dynamic, and the running code can even be changed at runtime, you can't create tools to perform 100% static analysis without actually running the code.
JavaScript is still a great language, given all these problems, but in the same way as C is a great language. Higher levels of abstraction have been built on it, such as
Java or C#, which help to ease some of the pain points. And so with JavaScript. Today, there are many languages that let you write in a higher level of abstraction: CoffeeScript, Dart, TypeScript to name a few recent ones.
GWT was created to solve the problem of client-side team-development, and getting Java developers proficient in building large-scale client-side apps without needing to worry about JavaScript. Another team created Closure Compiler, which also addressed the team-development aspect, buy using code comments to enforce structure.
It turns out, though, that JavaScript, because of it's dynamic nature, means that optimizing a browser virtual machine for super-fast JavaScript is challenging to say the least - partly because you can't make assumptions about the code from its structure - for example, the following valid JavaScript represents 1+1
(ref:
http://patriciopalladino.com/blog/2012/08/09/non-alphanumeric-javascript.html )
Enter Dart
In this section, I'll address Dart as a problem solver to the issues declared above, and also address the second question:
2. this site optimized for Dart... fragmentation...?
By designing a language with large-scale web development in mind, it is possible to address both parts of the story - developers can get a language that is designed for tooling, and VM builders can get a language that makes it easier to write optimizations for. Another design constraint is that Dart must always be able to compile to JavaScript.
The Dart VM is a browser virtual machine, rather than a rendering engine, and as the language is designed to compile to JavaScript, there should be no difference how the program runs (apart, perhaps, from speed). This means that you won't find websites that say "optimized for browser X" because the user experience will be the same (although the Dart apps will likely execute faster).
For Developers like you and I, we get to code in a language that is similar to Java or C#, and has the structure and tooling that we associate with server-side languages, but also has some of the dynamic nature of JavaScript, Ruby and Python. Using Dart's optional typing, you can throw together a quick prototype, using just as much type information as you would in JavaScript (ie, none), and later, add type annotations to improve the story for fellow developers and tools. When a third-party API changes, the tools will tell you that your code is broken. Autocomplete, sometimes called a "crutch", helps greatly when learning new or changed third party library APIs.
For customers and users of our apps, the quality, speed of development, and speed of execution will improve. Quality and speed of development, because we no-longer need to battle against the language, and speed of execution because of the faster virtual machine built into users browsers.
Finally, to see a 10 second clip of Dart running in Firefox and IE, take a
look here (G+)
Does the book address these questions - yes, and no. These questions (and answers) are outlined in the introduction and early chapters, but then you crack on with learning some Dart - open forums such as these are much better places for that kind of 2-way discussion
Thanks!
