
We are Switching to Dart - MartinMond
http://www.ramen.io/post/46936028144/we-are-switching-to-dart-why
======
michaelwww
I think a few points are worth emphasizing. Dart produces JavaScript that is
closer to being correct <https://news.ycombinator.com/item?id=5424680>

Dart can produce JavaScript that is faster
[http://news.dartlang.org/2013/03/why-dart2js-produces-
faster...](http://news.dartlang.org/2013/03/why-dart2js-produces-faster-
javascript.html)

The JavaScript output of Dart2js works across all modern browsers (IE9 and
above, among others.) No browser hacks required.

Having said that, I wish they would stop working on advancing Dart and ship a
1.0 version. It's been 1.5 years since it was announced. Make the advancements
in the 1.1 or 2.0 and give the tool developers a solid target to optimize for
in 1.0. Let us not have to sell clients on a beta development system, even
though that's what I'm doing and it's working, despite some panic when Dart
developers break things with breaking changes (which is often.)

~~~
trungonnews
IE9+. I hope people don't miss this keyword.

~~~
michaelwww
That satisfies all mobile development as far as I know. The loss is on Windows
XP desktop for those stuck on IE8 and below. So far, I'm doing ok telling
people to run Chrome or FireFox on XP as most of them are anyway.

------
trimbo
Assuming this is not April 1 con'd.

Dart is really cool. Awesome, in fact. I want this project to do well.

But there's just no way I am going to base my business on it when not even
Google uses it for their own stuff. It's just way too early.

~~~
michaelwww
I don't know if Google does not use it for their own stuff and you don't
supply references. That's not the same as saying Google will not use it for
their own stuff. That would be quite surprising. In fact, I'm assuming they
are developing it primarily as an internal tool, hence the disregard for a
reasonable time line for shipment of 1.0

~~~
munificent
> I'm assuming they are developing it primarily as an internal tool

It's neither primarily internal nor external. My understanding is that the
higher-ups feel Dart must succeed both inside and outside of Google to be
successful. Which one must happen _first_ is an open question, but I think the
end goal is wide use both inside and outside the company.

~~~
michaelwww
> end goal is wide use both inside and outside the company I agree fully. I
> would just add that, just in terms of salaries they've paid to Google
> employees working on Dart, they've spent millions, which they won't get back
> from by selling Dart. They probably have a compelling internal reason for
> doing this. They win if external developers adopt it because useful
> libraries will be written.

~~~
munificent
> they've spent millions, which they won't get back from by selling Dart

Yes, I think everyone understands today that languages don't directly generate
revenue.

> They probably have a compelling internal reason for doing this.

Off the top of my head:

* If it makes Googlers more productive writing apps in Dart, that directly saves Google money. We, obviously have some _very_ large JavaScript applications (gmail, maps, docs...) and we spend a ton of engineering time on them. If we can make those engineers more productive, that's a huge savings.

* If Dart succeeds externally, that's more third-party code that Google can then use for its own projects, so that directly saves us money.

* If Dart makes other web developers more productive, that makes the web bigger. A bigger web means more people spending time on it and more people doing web searches, which ultimately goes right back to Google. Google is happy when the web gets bigger.

~~~
michaelwww
Your first reason is the most compelling and what JavaScript developers might
want to consider. My own experience is that I am much more productive writing
code in Dart and then converting it to JavaScript. Why?

* Autocompletion (intellisense)

* Refactoring

* Use types and catch errors before runtime. Types are optional, although I don't know why you wouldn't use them unless you are pasting in some JavaScript code and running it as Dart. Hand converting JavaScript to Dart is fairly easy because types are optional.

* Quick turn around time in the "change code, set breakpoint, run code, stop at break point" cycle.

* Calling native JS code is painless. Libraries that are currently not available as Dart, such as three.js can still be used.

* Project organization is fairly automatic.

* Code analyzer - this one is my favorite. The analyzer will tell me if my change causes a problem in another file. It runs in the background, like C# does.

------
eliben
This makes sense. Every time I side-peek at JS, I get terrified by the huge
amount of libraries that one is supposed to be used to just get it running. It
must be a liberating feeling to be able to just use one language with one
standard library, for all your stuff. The "batteries included" philosophy
worked well for Python.

~~~
michaelwww
I wonder if we could go so far as to say Dart is to JavaScript what Python is
to PHP? My whole reason for using Dart on a project was out of desperation
because I was handed a JavaScript/PHP mess and I didn't want the nightmares to
start again. I've been sleeping really well lately. Since Guido von Rossum did
a stint at Google, all they need him to do is ask him to bless Dart and we're
good, or find a suitable rock star replacement to promote "The Dart Way" ;-)

------
MatthewPhillips
The title is inaccurate, they weren't using JavaScript before, they were using
CoffeeScript.

Seems that the story is they are moving towards a more opinionated
language/framework. That it is Dart isn't the story here; they don't even
mention the Dart VM as a benefit for the switch. It just as easily could be
ClojureScript, which provides all of the same benefits.

~~~
mraleph
[disclaimer: I work on Dart VM]

Even though Dart VM is not a deployment target for the client side code right
now it is still an integral part of the development experience. It runs all
your code while you develop (no need to compile to JavaScript just
edit&refresh) and backs things like dart2js, dwc, pub which are all written in
Dart itself.

~~~
MatthewPhillips
Right, but the author here doesn't mention the Dart VM as a reason for the
switch; they are not switching to get better performance in Chrome. They are
switching because they like the language/ecosystem better.

Also, IANAL but I'm pretty sure you don't have to include a disclaimer to post
on the internet. No one is going to rush out and buy Google stock based on
your comments so there is no conflict of interest to what you wrote.

~~~
mraleph
Yes, I agree with your point. Yet, I see quick edit&refresh as the part of the
ecosystem. Hard to enable that without VM.

[regarding the disclaimer: I add it for two reasons. First, I have seen people
accusing others of hiding their bias, so I prefer to state my affiliation
explicitly. Second, if anybody wants to ask any Dart VM related questions and
get response they know where to ask :-)]

~~~
_jmar777
Sweet... so how does Dart compare with asms.js?

/me _ducks_

:)

~~~
kyrra
Serious answer:

The Dart2js compiler could easily take advantage of asm.js additions, and
generate javascript code that uses asm.js. If asm.js does take off, all it can
do is help Dart generate faster running code.

Now, if we are talking about the DartVM, asm.js could be used as an argument
not to include the DartVM in other browsers. But asm.js is still very much in
it's infancy, so we really need to wait and see how it's adopted and how it
progresses.

~~~
ryeguy
No it couldn't. asm.js has no garbage collector. The only way to get dart
running on asm.js would be to port the entire VM to asm.js, which afiak won't
work since the dart JIT emits machine code at runtime.

~~~
_jmar777
I don't think @kyrra was suggesting that Dart would compile _completely_ to
asm.js code, just parts where it makes sense (just like normal JavaScript uses
asm.js only where it makes sense).

------
peroo
Why does so many startups feel the need to brag about the fact that they're
switching to <hot new technology>? To me it just comes off as an attempt to
convince themselves it's a great idea.

How about coming back in a year and telling us how it turned out instead?
Actual case-studies and analysis are interesting, fashion statements are not.

~~~
dantheman
I think it does at least 3 things well:

1\. It lets developers familiar/interested in the tech to know that you use it
and that they should apply there.

2\. You've done the work to research it and make the decision to switch - it
doesn't hurt share that. Who knows someone may point out some flaws you didn't
expect.

3\. It increases the inertia of the technology. There are strong network
effects in technology and if everyone sees that something is growing they'll
make the jump too. One new library created per X developers is a big win and
makes it better.

------
arkitaip
It seems very risky to base your core business on a language that's only been
around for two years. Sometimes web development seems to be more volatile than
the fashion industry.

~~~
lmm
With the state of javascript at the moment you would certainly be using
library code that's less than two years old to build core parts of your app.
The line between language and library can get pretty blurry, particularly when
we're talking about a language that compiles to JS.

~~~
rictic
To be fair, there's a difference between a library and a language here.
Replacing or taking on the maintenance for a library is a much more feasible
option for many than jumping to a new language or taking on the maintenance
for an entire language (as it's not just the compiler, it's also custom
tooling, debugging, plus Dart really needs its own libraries, etc.)

------
tjholowaychuk
Why go through so much pain to avoid JavaScript, coffeescript now Dart?
JavaScript is not the problem, it's how terrible our community is at
sharing/creating modular things. Classes and shitty syntax wont help you there

~~~
oinksoft
You touch on a good point, but I'm not sure it has to do with this particular
piece. Rather, the author seems really confused:

    
    
      There are great projects like Underscore, Sugar,
      Prototype, jQuery, CoffeeScript and many many more that
      help to work around JavaScript’s language quirks.
      Unfortunately they don’t mix and match very well. Also,
      which map() or forEach() implementation should I use if I
      have multiple available?
    

That's like comparing barricuda, rubberbands, and bolts. Only one of the
projects he mentions has anything to do with "JavaScript’s language quirks,"
and that's CoffeeScript. Just another person who did not know
JavaScript/frontend development, expected it to be like any other programming
environment, and bailed rather than stepping back and reconsidering his
original assumptions.

~~~
tosh
I understand what you're saying but I'm humbly disagreeing.

I do believe that all the mentioned frameworks (while positioned differently)
do offer solutions to work with/around JavaScript language quirks. e.g. simple
things like

    
    
        * working with collections
        * working with objects
        * extending 'things'
        * iterating over 'things'
        * working with async
    

That's one of the main things that I (and probably more) people find confusing
about the JavaScript ecosystem even while I'm not new to it.

~~~
oinksoft
JavaScript provides arrays and objects, and also functions for grouping data
(via closures). What else would you expect it to come with? The quality
`goog.structs` package speaks to how easy it is to create very high-level data
structures.

Are you perhaps thinking of the baroque and once-very-inconsistently-
implemented DOM API?

Regarding your other points, JS is an extremely object-oriented language. I
really don't think you need more "working with obejcts" things out-of-the-box.
Iteration is very straightforward in all cases, unless you find hasOwnProperty
confusing. The Node.js project has demonstrated well how easily Async maps to
JS outside of the browser model (where Async has always reigned).

JS is a strange beast in certain ways, but it is a featureful language.

~~~
mythz
JavaScript is extremely poor at expressing OOP, it requires so much un-
intuitive boilerplate to express your intent that many don't bother and will
just hack together the simplest thing that works. Which causes the current
situation of having so many different libraries to declare classes and they
all do it their own unique way which are not compatible with each other.

It's the same for iteration, the hasOwnProperty is mostly omitted because it
works most of the time without it and specifying it adds un-necessary boiler
plate.

Same with async, there's a zillion async libraries that try to manage async in
different ways and they aren't interchangable either. By standardizing on
Futures/Streams it means all libraries can build on consistent and composable
foundations and build higher-level functionality.

~~~
tjholowaychuk
If you avoid inheritance js is just fine, inheritance is a pretty terrible
concept to begin with IMO.

------
desireco42
This sure sounds like April 1 joke, but, I get that developer(s) wanted
something even more innovative then brunch and coffeescript. Like arkitaip
said, it is a very risky move.

~~~
michaelwww
Riskier than using the latest perpetual beta JavaScript library? I don't think
so.

~~~
desireco42
Which one ?! JQuery? What are you angry about?

~~~
michaelwww
I'm not angry, I just want something better. As Anders Hejlsberg said "you can
write large programs in JavaScript. You just can't maintain them."

[http://lostechies.com/derickbailey/2012/06/04/anders-
hejlsbe...](http://lostechies.com/derickbailey/2012/06/04/anders-hejlsberg-is-
right-you-cannot-maintain-large-programs-in-javascript/)

------
tosh
BTW this is _not_ an April fools joke :)

------
apunic
I like your post since it's a refreshing take on today's language and
framework decisions. Usually people go for Coffee, Node, Go, Clojure or
ClojureScript nowadays (I mixed FE and BE tech deliberately).

What I am interested in: Why did you go for Dart? What was the trigger? When I
look at Google Trends Dart seems to have a very hard time compared to other
current technologies regarding search popularity.

And what's your backend based on? Could I go for Dart with Node?

~~~
ahoge
You could write the back-end in Dart, too. The Dart VM can do IO out-of-the-
box. Just like the Node executable, it can be used to run command line
scripts, web servers, or anything else you can think of.

Anyhow, since the front-end only communicates with the back-end via
standardized protocols (say, HTTP or WebSockets), it doesn't matter what's
used on the server-side. These two parts are completely decoupled.

------
TeeWEE
While I think dart is a nice language, I do not think JavaScript is bad enough
to justify switching to a completely different language.

I worked on some big js projects, and together with a good module-system and
jslint with strictmode on it works out all quite well.

I think OOP is nice but you can do without much of it by focussing on
composition instead of inheritance.
<http://en.wikipedia.org/wiki/Composition_over_inheritance>

Dart has a big focus on OOS and looks a lot like "JavaScript for Java
Programmers". Which is not a bad thing.

~~~
smrtinsert
5k large? 10k large? 500k large?

the real test of a language is when it has all the millions of bug fixes built
in over the years. At that point, do you feel comfortable
refactoring/rearchitecting it to remove development inefficiencies? I argue
that with Javascript there is no way you do once it grows beyond a small team
size.

------
stephanos2k
Interesting post! I'm wondering:

1\. How do you test your Dart code?

2\. How do you integrate Dart with your existing Javascript?

3\. Do you use Dart Web UI?

~~~
sethladd
[disclaimer: I work on the Dart team]

1) We have unit tests and mocks built-in. Check out
<https://www.dartlang.org/articles/dart-unit-tests/>

2) We have JS-interop. Check out <http://www.dartlang.org/articles/js-dart-
interop/>

3) We have tutorials for Web UI. Check out
<http://www.dartlang.org/docs/tutorials/>

Hope that helps!

------
SeanDav
How well does Dart work with node.js? Should I even consider Dart if using
node.js?

~~~
michaelwww
It works transparently on the client to a node server of course. I haven't
seen a lot of examples Dart interop with Node on the server. There are two
choices, Use the Dart VM on the server and interop with Node through the js-
interop lib, or use Dart2Js to convert Dart to JavaScript and operate with the
node packages that way. There's still a lot of uncharted territory with Dart,
which I think provides me with a lot of interest and opportunity.

------
vor_
I would be too afraid to base a business on a language that's only two years
old. It's not even a guarantee that the language will remain supported by
Google in the long term, given their periodic house-cleaning.

------
MartinMond
I hope Google gets (even more) serious with Dart. Web App Development with
JavaScript is a joke. Just remember the recent callbacks vs promise debate.
It's like JS devs know nothing about software engineering.

~~~
leeoniya
debate?

~~~
MartinMond
I'm talking about <https://news.ycombinator.com/item?id=5466872>

------
xiaoma
Many libraries, including Underscore, default to the native browser methods
when they're available. It's not really much of an issue deciding which map()
to use.

------
33a
April fools?

~~~
tosh
It's not, we're serious about Dart :)

~~~
basch
Why Dart over <http://meteor.com/> <https://github.com/yahoo/mojito> or
<http://derbyjs.com/> ?

~~~
eliben
The answer is contained in your question, I think.

~~~
mythz
Exactly :) even more-so given the list is incomplete.

~~~
basch
there are others? what other frameworks render the page server and client
side?

<http://derbyjs.com/#why_not_use_rails_and_backbone>

edit: ok I forgot <http://www.socketstream.org/> but regardless, the realtime
single page app sector really is dominated by those four products. everything
else is already obsolete.

<http://derbyjs.com/#introduction_to_racer>

