[bp74]

Well, you should see it from another point of view. You write and debug(!) your application in Dart, later you compile it to JavaScript. The dart2js team tries very hard to generate code that runs just like the Dart code does in the VM. Look at the JS-code like the binary code you get from a c++ compiler. There are hardly any people debuging the generated machine code in c++ right?

I have allready written tons of Dart code, and i have to admit there were a few issues with the JS-code regarding cross browser compatibilty (btw. it is easy to read the generated js-code). Those issues were problems in the dart2js compiler because it's a alpha-version right now. The dart2js team fixed all those bugs. As soon as the compiler will finally ship we will rely on the generated output - no need to debug "assembly language".

[TazeTSchnitzel]

That's not my gripe with Dart's JS output. It's just that Dart is so different from JavaScript and has so many thick layers of abstraction that tiny programs can have thousands of lines of JS outputted, a lot coming from having to include Dart's own standard libraries.

[bp74]

You are right that small programs compile to pretty big JS-files, but noone should really care. I can do my "hello world" apps in javascript without a problem, the point of Dart is to write big apps! For those apps the footprint of the compiled JS-code doesn't matter at all. And you can work with nice structured source code.

[TazeTSchnitzel]

Well, personally I don't want to use a language that compiles to a representation around 50 times larger than the source code.

[munificent]

The JS output that gets generated from a Dart program isn't just "dart_size * multiplier", it's "dart_size * multiplier + constant". So, when you see a tiny Dart program being compiled to a large amount of JS, that doesn't mean a large Dart program will compile to a huge amount of JS, it just means that the constant is dwarfing the multiplier.

The constant is coming from the runtime library (or, more accurately, the portions of the runtime library that your program uses). That's relatively fixed so as your Dart program gets larger, the overhead of that becomes relatively smaller. The actual code-size multiplier when going from Dart -> JavaScript is actually fairly small and getting smaller over time.

In some cases, we may actually compile Dart code to less JavaScript code because of things like dead code elimination and constant folding.

JavaScript code size is something that we consider a core metric for dart2js and we're constantly working to reduce it.

[TazeTSchnitzel]

Of course. I'm just a little concerned about how easy it is to inflate a program's size in Dart by including another core library.

[munificent]

That's true of every language, though, isn't it? If you use libraries, your app gets bigger.

[bp74]

hahaha, i totally agree - if it is 50x larger i would use a different tool too :) But as i said, if your source is 100KB it's not 50x larger, maybe it's 20% larger than hand written JS. Currently the footprint of the js-code is around 150KB. While dart2js is evolving this number is declining constantly. In the end when you add js-minification you will have a footprint of maybe 20-30KB i guess.