

Why or why not Dart? - khoomeister
https://gist.github.com/khoomeister/4976475

======
mythz
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.

~~~
michaelwww
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...](http://news.dartlang.org/2013/02/using-dart-with-sublime-text.html)
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.

------
bengoodger
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?

~~~
michaelwww
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()._

------
FuzzyDunlop
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.

------
jimbobimbo
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.

------
dlrush
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.

~~~
rexbarbaris
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.

------
cromwellian
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.

~~~
moneypenny
And after using a John Carmack quote to back that up. ROFL.

------
opinali
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.

------
andrewvc
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.

------
michaelwww
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

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

------
moneypenny
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".

~~~
michaelwww
He concludes by saying he is sticking to JavaScript because modularity is
important to him...

