Why or why not Dart?

Kind of weird that most of the problems identified that are being identified are actually language features that end up making code smaller and more concise, which are languages features that can be optionally used or not. I get the feeling that most of the disadvantages listed here are just things that are done differently and you are used to having to do in node.js because of limitations in the language, that you've later found and attached some benefits to, rather than ideal language features with merits that stand on their own.

Seems weird that a declarative module/import system can be viewed as a bad thing, node.js require is done the way it is because that's the most concise way it can be done in node.js without an in-built module system.

Creating more boilerplate by exposing a function is easier to read? I'm just not able to follow the logic here. You can easily identify what dependencies a package has and what it exposes by looking at the header of each library which maintains it in a concise, readable and declarative form - again another area where I can't see how having exports litered throughout the code-base which devs need to scan the whole code-base to find can be considered an advantage.

Being able to split out your source files by using library/part is a blessing, which is similar to using partials in C#. i.e. we're not artificially forced to create new classes and abstractions/delegations because the source code is getting too big, as we can group different parts of a library into cohesive and logical parts, that has no effect to the external surface area of the API.

I find Batteries included for core functionality is a great win, instead of using/finding adhoc libraries to do the same thing, you can instead use the built-in libraries that are always well thought out and written in idiomatic dart that provides a consistent development experience across the entire platform. The libraries also smoothes out browser quirks behind a consistent API. Not having built-in collections, or not having all async APIs return Futures makes composability harder since different libraries will import and implement their own, and using adhoc libraries that don't follow the same conventions, unnecessarily increases institutional knowledge that is a productivity drain and a source of bugs.

Tree-shaking encourages the developer to be lazy and is why it shouldn't be used?

This defies logic, wasting time and being forced to find and use minimal libraries not because of technical fit but because of how much your application uses and how much it adds to the overall download size - has only downsides. This developer time-sink exercise is just an artificial complexity that doesn't add any benefits to the end-user. Knowing that your production code will be tree-shaken and optimally packaged for deployment means you can maintain the most optimal development environment you wish as your code will be in its most optimal form when its deployed, so you're free to reference the most suitable library, use as much or as little of it as you need without concern about resulting code-size, which ends up having a smaller output than having hand-picked micro libraries since only the parts of the library that you end up using gets deployed and not the entire library.

One of the benefits I got when using the Closure Library (i.e. what Gmail, Google Maps were built-on) was the vast array of well-tested and robust libraries that I could use without any concern of its deployment footprint, being able to freely use any library you wish is what Tree-shaking allows.

In .NET world partial classes are often used in the generated code scenarios, when the tool might generate the partial class and later, another part of the class is being added manually to provide some customizations to the generated code.

- Browsers will support pluggable scripting languages so the developer will be able to choose Javascript, Dart (native), Ruby, Python or Go as the language they use to code in the browser. Why? Because it's the only way to break the innovation stasis in client-side web coding. As an aside, Microsoft got this right in very early versions of IE when you could script in JS or VBScript for example.

- A new Open Source IDE will become defacto. it will embed Chromium and Webkit and will feel more like a traditional IDE that a text editor with IDE features, or a browser with a console window. The Browser was never designed as an IDE, yet it is becoming one, organically, and accidentally. Ironic since there are very capable sophisticated IDEs out there that can accelerate web app coding. Dart gets this right. Coding in browser is not going to cut it. You need a sophisticated tool designed explicitly for this purpose to build bigger, more complex, performant applications.

I've prototyped some with Dart and my personal opinion is: - better than Javascript, but - it's evolved from JS which I feel is a critical flaw - native IDE is smart, requisite for future web development - core libraries and language are changing too rapidly to use in any 'conservative' production application

Let's skip the stopgap measures and get a browser that supports Ruby or Go natively, then revisit this whole question.

Also, a lot of the points you make on style are insane. If you think underscore is bloated then well what isn't bloated? It's one of the smallest libraries I've ever used.

http://www.youtube.com/watch?v=CKh7UOELpPo

I started laughing when reading that apparently having an IDE instead of using a Text Editor would alienate "a whole bunch of developers".