Seth Ladd

Reading your quote from the ECMA standard, "no implicit conversions are supported" may be wrong but at the same time not generally misleading. That is, that function errors on null values and returns false for anything that isn't identical to true, so while it does provide a conversion to boolean from any non-null value, anything that isn't exactly a boolean "true" (unless I misunderstand what "identical" does) is going to return false on conversion. This is consistent with other writings on booleans in Dart [1]. So it appears that Dart has implicit boolean conversions, but it converts everything that is not the single "true" value to false, so using an expression that never can evaluate exactly to boolean true in a conditional (unless you mean it to be a wordy way to create unreachable code) is never something you want to do.

[1] http://blog.sethladd.com/2012/02/booleans-in-dart.html "The only value that is true is the boolean value true. [...] In a boolean context, everything that is not true is converted to false."

Dart is already very useful, so I disagree with that assertion. It's the Dart compiler that handles type-checking, not the runtime. If you write "String foo = 42; return foo + 8;" and compile without type checking, you generate code that will work fine. But if you turn on type-checking, you get the type error at compile-time.

Furthermore, the compiler is responsible for resolving the dependencies your main program uses ("tree shaking" to remove stuff you don't actually use [1]), so there has to be a compiler even if your browser had a Dart VM built in.

[1] http://blog.sethladd.com/2013/01/minification-is-not-enough-you-need.html

I use Dart because it allows me to organize and test my code in a way that is very inconvenient with Javascript. Any speed improvements or IDE support is incidental, I have not yet had any speed problems in Javascript and I don't use their IDE :) The type-checking, library system, and the language itself is wonderful, though.

You don't say if you used the 'dart2js --minify' setting, but Closure Compiler should do well. The --minify flag leaves alot more room for additional minification. You say you used two modules. The result really depends on the modules. For example, the Dart/JS interop module adds about 140K un-minified. Tree shaking is always on, so the 140K is after stripping unused code. I initially jumped into Dart because I was interested in doing packaged apps that run locally, so the size over the wire didn't concern me as much. I recently converted an ActionScript app to Dart and the post-minify Dart was around the same size as the compiled .swf file (for comparison, same functionality)

Seth Ladd has a couple of posts about Tree Shaking and Minification if you're interested
http://blog.sethladd.com/2013/01/minification-is-not-enough-you-need.html
http://blog.sethladd.com/2013/03/i-shrunk-my-dart-to-js-code-by-11x-and.html

A large number of dependencies is only a problem in environments that aren't amenable to per-function static linking or tree-shaking. These include dynamically typed languages like Python, Ruby, and JavaScript (except when using the Google Closure Compiler in advanced mode), but also platforms like the JVM and .NET when reflection is allowed. Where static linking or tree-shaking is feasible, the run-time impact of bringing in a large library but only using a small part of it is no more than the impact of rewriting the small part you actually use.

Edit: Dart is an interesting case. It has dynamic typing, but it's static enough that tree-shaking is feasible. Seth Ladd's blog post about why tree-shaking is necessary [1] makes the same point that I'm making here.

[1]: http://blog.sethladd.com/2013/01/minification-is-not-enough-you-need.html