Reposting my comment here so it can serve as a discussion point if wanted...
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.
He lost me when he said you have to use the Dart editor to find references. First of all, the whole idea was to bring JavaScript as Dart into an IDE with similar functionality of a C# or Java IDE, such as refactoring, which works like a charm. Second of all, there is a plugin for Sublime 2 http://news.dartlang.org/2013/02/using-dart-with-sublime-tex... and I'm sure there will be more for other editors. But I kept reading and it became clear he hasn't tested tree-shaking or doesn't understand it. Then he says tree shaking is slow, probably not realizing that converting to JavaScript is not a regular build step, and it's not slow. For development, I code and debug on the Dart VM, which has almost no build time.
I've only written a small amount of dart so far, but speaking as as a cranky C++ developer with not much recent experience with web development, having a thicker standard library is very useful. Specifically the platform has grown so much over the years it's hard as a newcomer to discover the well lit path. With dart:html for example, it's much more straightforward - they have done a lot of work simplifying the very broad set of DOM APIs. I understand there are various JS libraries that provide this, but as a newbie which one do I pick?
jQuery if you'd like to support older browsers, Zepto if not and you are targeting mobile.
By the way, dartlang.org includes this tongue-in-cheek statement: One area where the DOM has a bunch of baggage is finding elements. Today’s DOM has a pile of methods for finding stuff. All of this piled up before jQuery appeared on a mountaintop to give us the revelation that Thou Shalt Find Nodes By Using CSS Selectors. With the One True Way in hand, we’ve stripped it down to just two (!) methods: query() and queryAll().
I find it amusing that Dart is apparently bad because it has batteries included, and that the third party ecosystem should be relied on more, yet the author has no trust in third party 'future' libraries and likes that Dart has core support for it.
Criticism of partial libraries is a bit off, as it is a very powerful tool, if used properly.
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.
Dart is better than Javascript, but primarily because any real language is better than Javascript. However let's jump ahead 2 years:
- 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.
I like the idea of having language options on the browser. But realistically I don't think we'll get that across the board soon. If we do it will be fractured. IE will support TypeScript. Chrome will have Dart.
Maybe we'll have universal alternatives eventually. But I think 2 years is a very optimistic time line.
The problem with many of these languages is that they don't have an official spec, just a reference implementation. They aren't standardized in the same way javascript is. That makes it difficult to integrate them. There's no way multiple languages will be cross-browser in 2 years.
First time I've seen someone actually try and defend Javascript's non-existent roll-your-own module system against languages which actually have proper built-in module systems as first class.
What a load of bullcrap. Batteries included is bad because having fifty competing libs for i18n or unit tests is good. Optimizations like tree shaking are bad because lazy devs can abuse.
Wow, thus may be the worst language comparison I've ever read. It spends half the time covering the module import system, then blasts through the rest of the language features so fast it seems that no real thought is given.
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.
Why Dart? SIMD - Single Instruction Multiple Data - Speeds up things like WebGL, added to Dart VM, not available in JavaScript except through an experimental technique in FireFox
I was hoping for a well-reasoned and insightful post, but unfortunately this is not. The author appears to not quite understand how Dart works, with its optional static type system, and how Dart's imports work.
I started laughing when reading that apparently having an IDE instead of using a Text Editor would alienate "a whole bunch of developers".
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.