

I ported a JavaScript app to Dart - zetalabs
http://blog.sethladd.com/2014/05/i-ported-javascript-app-to-dart-heres.html

======
supporting
It's a little bit sad that Google pays people to have their entire job be to
astroturf for Dart with blog posts like this one.

Being a "developer advocate" is one thing, writing official documentation,
answering questions on forums, whatever — but "I ported a JavaScript app to
Dart. Here's what I learned." Seriously? More like "I'm on the Dart Team. I
ported a JavaScript app to Dart because it's my job."

Open source shouldn't need to be juiced with paid posts. If you scroll down to
the "Lessons learned" section at the end, it really strikes to the core of
what being disingenuous is all about.

~~~
spankalee
Your definition of astroturfing doesn't seem to match mine. Seth states
several times on his blog that he works on Dart developer relations at Google.
Blogging about Dart is part of his job, and in no way is he being deceiving
about that fact.

 __I on the other hand am simply an engineer on the Dart team, as I must
disclaim in this context.

~~~
plorkyeran
Where does he mention that other than the sidebar? I completely missed the
fact that he works for Google while reading the article since it's never
mentioned in the body of the article itself, and the article is written as if
he's completely new to Dart and trying it out for fun. If he's not trying to
present that image, then it's a really awful writing style.

~~~
vdaniuk
Do you imply a conflict of interest? If you do, please state it explicitly.
Your criticism as it stands doesn't add to the discussion and one could say
that your writing style is really awful, too.

Sidebar is not an unusual place to place author bio and it is definitely
enough for me.

~~~
plorkyeran
Okay, I'll state it explicitly: I feel that the article is actively deceptive
about the background of the author, which makes me distrust the content of the
article as well. The sidebar with his background is not visible on the first
page of the content, so I would have had to interrupt reading the article to
read it.

I say that it is a bad writing style because I am assuming good faith. I
assume that the positioning of his bio is merely unfortunate and not
specifically chosen to reduce the number of people who read it, and that the
article is not actually trying to deceive me about the author. I think it is
obvious that coming across as astroturfing to some subset of your readers when
that isn't what you're trying to do is a bad thing.

~~~
magicalist
> _I assume that the positioning of his bio is merely unfortunate and not
> specifically chosen to reduce the number of people who read it, and that the
> article is not actually trying to deceive me about the author_

Oh please. Most blog authors barely manage to fill out an About page, let
alone a sidebar and a big subheading at the top of the page that says who
their employer is. If you're going to claim to be "assuming good faith", how
about actually doing so?

------
tyleregeto
I've been porting a larger application from JS to Dart, and I can repeat a lot
of what Seth says in this article. The experience has been generally very
good. While porting I also discovered a couple bugs that existed in the
original code base for a very long time.

I do keep flip-flopping on whether I'm going to seriously commit to it though.
I really like Dart, my code is safer, cleaner, and more maintainable. But it
just doesn't _feel_ like it has much momentum yet.

~~~
spankalee
I'm not sure what I can say about Dart adoption internal to Google, so I'll be
conservative and say that it's going well in my opinion. I hope we can speak
more about it at some point. Language adoption is a very gradual thing at
first, so I'm not at all surprised that momentum isn't that apparent yet. The
community is very active though (join the email lists or G+ if you're not
already).

Rest assured, we're very committed to Dart.

------
jlongster
I somewhat skimmed the article, but it doesn't mention the fact the JavaScript
is on the verge of getting modules. Unless you really love Dart, you can fix
most of these problems by using something like the ES6 module transpiler:
[https://github.com/square/es6-module-
transpiler](https://github.com/square/es6-module-transpiler). Even better, in
then next few years JavaScript will start adapting these natively, solving
many of the organizational issues laid out in this post.

~~~
sethladd
Thanks for the feedback. I did point out, in the end of the article, that some
of the techniques (e.g. libraries, futures) aren't impossible in JavaScript.
And I'm really happy to hear they might be coming to a future version of
JavaScript (everyone should have modules and promises!). Part of the point of
the article is that Dart has these features now.

~~~
Excavator
Thought you'd might want to know that Promise¹ is available in Firefox &
Chrome since quite a while back and the spec for Modules can be found here:

Spec:
[http://wiki.ecmascript.org/doku.php?id=harmony:modules](http://wiki.ecmascript.org/doku.php?id=harmony:modules)

1: [https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Reference/Global_Objects/Promise)

~~~
sethladd
Yup, thanks! What's the story for modern browsers that don't yet support those
features? Do they both have polyfills?

As I mentioned in the article, libraries and futures aren't exclusive to Dart.
It's just that they are here _now_ for Dart and are compiled to JavaScript for
all modern browsers.

I think it's telling that the original author didn't use Promises or Modules.
Of course he could have, but we should ask, why didn't he?

~~~
jamesknelson
While a lot of browsers are still lacking pretty much any ES6 support, you can
get around this by using Traceur [1] to compile your ES6 javascript down to
ES5, and then using the es6-shim [2] for new ES6 libraries (Promise, etc.)

Given that you'll need to compile dart down to JS for it to run on _any_
browser (including chrome), and given that it seems unlikely Mozilla will ever
include a dart VM, I'd say that starting to learn ES6 now is probably a better
long-term bet than learning dart. Which isn't to say Dart isn't a nice
language...

[1] [https://github.com/google/traceur-
compiler](https://github.com/google/traceur-compiler)

[2]
[https://github.com/paulmillr/es6-shim](https://github.com/paulmillr/es6-shim)

------
todd8
I really like Dart. I'm surprised its not getting traction faster. Its a
language with few surprises, everything looks familiar and works as you'd
expect without gotcha's. While it doesn't feel cutting edge like Haskell or
retro on steroids like Clojure, it seems just right as a replacement for
Javascript.

~~~
k__
It just doesn't play well with JS, because it was designed as a JS
replacement, with an own Runtime, which kinda sucks...

~~~
spankalee
Care to be more specific? You can use JavaScript from Dart now, and we're
working on improving interop support. Feedback is welcome.

~~~
k__
Really?

When I last looked into it, there had to be some strange stuff to be done, to
call JS from Dart and Dart from JS.

It just didn't felt as naturally as in TypeScript or LiveScript.

------
robmcm
One of the early issues raised about Dart was that it's compiled nature would
make it hard to debug and was against the open source (easy to hack) nature of
JS on the web.

These days JS is more or less compiled, at least the file you get in your
browser is very different that what the developer saw.

This seems to improve the case of Dart and I wouldn't be surprised if we saw
more languages that compile down to JS in the near future.

We already have ES6 down to ES5 [http://addyosmani.com/blog/author-in-
es6-transpile-to-es5-as...](http://addyosmani.com/blog/author-in-
es6-transpile-to-es5-as-a-build-step-a-workflow-for-grunt/)

~~~
grifpete
Why would the compiled nature of Dart make it hard to debug? Presumably you
mean debug by someone other than the original developer?

~~~
robmcm
That and debugging the compiled JS assuming there was a bug in the compiler or
a browser quirk the compiler hadn't worked around.

This is me remembering the arguments not making it ;)

------
adamkochanowicz
I'm concerned that, however good Dart may be, the fact that zero browsers
intend on supporting it natively (and I understand they non-natively support
it via js compilation), the popularity is likely to escalate.

Wasn't the idea of Dart to replace JavaScript as the "lingua franca"? And we
still have to run Chromium to support it natively?

~~~
rdtsc
There is nothing preventing Google from release Dartium (Chrome with DartVM).
In the meantime it compiles to js and is not the first thing to do so.

In fact I think Google should release Google Chrome with Dart VM and then
accelerate a few of their apps (oh look much better Google maps!), before you
know it, Opera will get it as well.

~~~
pjmlp
It is marked as "in development" on the Chrome dashboard.

[http://www.chromestatus.com/features](http://www.chromestatus.com/features)

------
ryanolsonx
I really liked the direct comparisons in this article between the original
javascript and the dart code. It makes me want to learn more about dart and
about how I can use it in my personal (or work) projects.

It's doubtful that JavaScript will be widely replaced as the language of the
web. I can see a day where most web developers don't write JavaScript anymore
and languages that compile to JavaScript (like dart) will be widely adopted.

It's almost like the evolution of programming languages. If you take, for
example, the C programming language, people could write a lot of modern
applications using it but C++ and .NET has made things easier and more
maintainable. I think a similar thing could be said in the future about dart
(representing C++ or .NET) and JavaScript (representing C).

------
Nilzor
Tl;dr News flash: static typing is a good thing!

------
Nekorosu
The article clearly shows that Dart doesn't stand too far from vanilla JS.
Conceptually it's on the same level. Futures? Really? Functional reactive
programming or communicating sequential processes solve the async problem a
lot better than futures. FRP is available in vanilla JS (take a look at
bacon.js) and CSP are part of ClojureScript which by the way exists because
it's a good tool not because some megacorp throws it's money to push it to the
masses.

------
Nemcue
Sure — I guess it's nice that Dart comes with a lot of useful things built in.

Outside of Dart we already have pretty good solutions for Promises (with
Promise A+ compatible libs; Q, RSVP etc) and modules (ES6 modules, Require
etc), which /kind of/ makes those points moot.

Which leaves type checking and autocompletion as the big benefit. Which are
nice, I guess.

~~~
sethladd
I've clarified at the bottom of the post that JavaScript is probably going to
get some of these features in the future. One of the points I was trying to
make was Dart has these features _now_ (and because Dart compiles to JS, it
means I can deploy these features now).

The other question we should ask is, why didn't the original author use those
new shiny JS features in his app? He's a crazy smart developer. My hypothesis:
because the out-of-the-box dev experience doesn't include modules, promises,
etc, there's a higher barrier to using the new shiny JS features because the
developer needs to first A) know about them B) find the right polyfill.

Thoughts?

~~~
Nemcue
As a counterweight: I'm not a crazy smart developer, and I use those features.
In production. Now.

I'm not going to argue against your point though, because I think you are
right. One needs to have some grasp of the JS ecosystem to know what libraries
to use. And as I said, it's nice that Dart has made that choice for you.

But that said, poking around a bit in the Dart documentation I think it's
interesting that "Futures" are seemingly /not/ entirely interoperable with the
de facto standard of Promises (A+) in JS.

~~~
sethladd
I don't know enough of the intimate details of Promises to know if Future ==
Promise. I hope I didn't make it sound like Future == Promise, but I do think
they are quite similar in intention.

Can you expand on why you think Futures aren't entirely interoperable with
Promises? Also, which specific implementation of promises? (what's the link to
the promises that you're talking about?)

------
bla2
I wonder how the size of the dart-generated js compares to the size of the
original js.

~~~
sethladd
Good question, I'll try to add that. Maybe more importantly, what is the
startup time for the two versions?

~~~
Nemcue
Would also be interesting: Perform some operations, compare flame charts from
Chrome developer tools.

~~~
sethladd
Also a good idea! Gah, I need more time.

------
x86_64Ubuntu
Why can't I comment on the blog? Anyway, I was going to say.

>Slowly but surely the JS worlds moves toward looking like the Flex/AS3 of
years before.

~~~
sethladd
Hm, the blog has G+ comments on it. Apologies if that's not working. You can
leave comments here, too :)

------
dkarapetyan
All that code and one bug? Either the original programmer is a genius or Dart
isn't as great as it seems.

~~~
sethladd
The original developer is really good. Also, the original app is small-ish, so
I really wouldn't expect too many (or any) bugs in the original app.

