
Why Google thinks you should drop everything you do and pick up Dart - WoodenChair
http://video.coldfrontconf.com/video/10277729?source=share
======
voidr
This to me feels a lot like GWT: making it easier for Java developers to write
client side code.

It was marketed as faster, however in reality it's slower on everything except
a special build of Chrome.

It supposed to make us more productive, however all it does is that it makes
churning out code easier at the expense of debugging. Sourcemaps are here to
solve these issues, however since Dart is not a purely transpiled language, I
don't really see that working out.

In my opinion Dart is an excellent research project, but it ultimately fails
at fixing anything that makes client side web development hard.

------
shurcooL
I wish they'd invest in Go for the frontend. If a project like GopherJS can
get as far [1] as it is now with just 1 person working on it for a few months,
imagine if it had more support. And then you could use a language as nice as
Go for both frontend and backend.

[1] [https://github.com/gopherjs/gopherjs#what-is-
supported](https://github.com/gopherjs/gopherjs#what-is-supported)

~~~
dingdingdang
Yes, I totally echo this sentiment - Javascript has the traction and the
stability to be a good transpiler target. That Google is actively trying to
push both Dart and Go simply makes no sense for me, especially since Dart is
supposedly (as far as I can tell with half a degree in googling) aimed at
frontend work more-so than Go but at the same time seems to come with even
more complex language structure than Go..

------
scotty79
What's the killer feature of dart? I went through some docs and couldn't see
anything JavaScript doesn't already have or is soon to have.

~~~
WoodenChair
There's not just one killer feature. Here's a few _strong_ features that add
up:

\- optional static type annotations

\- advanced object-oriented features (mixins, advanced constructors, etc)

\- rich built-in libraries

\- pub package manager

\- 2X V8 performance w/ the Dart VM

\- integrated tooling

\- exceptions

\- generics

\- operator overloading...

I could go on, but basically I'm not sure what language you were looking at
because Dart has a lot that plain vanilla JavaScript does not (although can
have with extensions). It also doesn't inherit all of those flaws JavaScript
got from being designed in a time crunch (10 days is really not enough time to
design a language).

If I had to pick one though, it would probably be the fact that _Dart is a
platform_ (rich language, libraries, tools, and package manager) rather than
hodge podge of frameworks on top of a lightweight language.

~~~
ajizzle
If it compiles down to javascript then it does have the same flaws as
javascript. 2x performance of v8 is bullshit, and "rich built-in libraries"
and "integrated tooling" are just marketing drabble. If you understand what
they actually mean please explain or gtfo.

~~~
WoodenChair
Sure, I'll explain each one.

Performance - Dart has its own VM which runs independently (on the server, or
in special builds of Chrome, but soon to be mainline Chrome). So it's not just
a language that trans-compiles to JavaScript, it's also a language with its
own independent high performance VM that you can use on the server today and
the browser tomorrow (hopefully). By the way the Dart VM was written by the
same guys that created V8 - generally considered to be one of the highest
performance JavaScript VMs - so I think we can believe them when they say it's
higher performing.

Rich Built-in Libraries - Just take a look here:
[https://api.dartlang.org/](https://api.dartlang.org/) There's everything from
a reflections API to a WebGL library. There's JavaScript interop libraries,
concurrency libraries, and the equivalent of jQuery built-in. That's just
scratching the surface.

Integrated Tooling - Dart has its own package manager (pub) which is quite
nice as well as its own IDE (Dart Editor) which comes with a debugger,
profiler, and all the niceties you'd expect (code completion, deployment help,
etc).

It's also a new language (less than a year since 1.0) backed by a big company
so these things are only going to continue to improve.

~~~
jeswin
The wider adoption of Dart is a pipe dream, and the fact that it will remain
confined to Chrome is _a very good thing_. The web community should reject
this, or we'll soon have only one browser and one true master of the internet.

\- No other browser can practically implement or support Dart. If they do
their implementation will be slower than Google's, and will get classified as
inferior. Google has in abundance the time and money to build and fix bugs,
which Mozilla and Opera may not have in the near future.

\- Google's engineering could have gotten JS much farther along, but from what
I have read on Twitter the V8 team has been shuffled around and the focus of
innovation on Chrome is Dart.

\- See how Chrome trails Firefox in ES6 here: [http://kangax.github.io/compat-
table/es6/](http://kangax.github.io/compat-table/es6/) (Thankfully, arrow
functions are landing soon).

There is no other way this would be played out, and the plan from the outset
must have been to push Dart forcefully using Google's distribution capability
on the web and on devices. I am waiting for Servo to launch to become a full-
time Mozilla cheerleader again, once again after Internet Explorer's heydays.

~~~
mythz
> No other browser can practically implement or support Dart.

They don't have to, they can use the Open Source DartVM as-is, in-fact this is
what Google encourages, just like how node was able to use V8 JavaScript
engine - which they've said is an example of new use cases that's possible
when you create a high-performance VM.

> Google's engineering could have gotten JS much farther along

Lars Bak and Kasper Lund on the Dart VM are the same guys on the V8 team, who
were also on the world-leading JVM Hotspot compiler that was derived from the
Strongtalk VM (the fastest implementation of Smalltalk) that they created.
They believe performance of JavaScript is reaching its peak and is unlikely to
see another 2x improvement, JS VM's are also extremely complex as JavaScript
is extremely hard to optimize.

By contrast Dart is a much simpler and predictable language designed for both
productivity and performance and because it was designed in-hand with the VM
engineers, language features are designed in a way that performs well.

~~~
shadowmint
Which means exactly nothing if youre compiling dart to a javascript runtime,
which is currently its only viable deployment target.

------
tomjen3
Anybody have a link to the slides? I don't really want to waste time watching
a video to see what they are up to.

~~~
WoodenChair
[https://docs.google.com/presentation/d/1EWLLgsl-m4OCRcvgf2Bi...](https://docs.google.com/presentation/d/1EWLLgsl-m4OCRcvgf2BixnLCLNTAGLfxWhYI0M5j19c/edit#slide=id.g177d510c8_0342)

------
ntoshev
"Google" does not think that, a cofounder of the Dart project does.

~~~
WoodenChair
It's the official name of the talk.

~~~
thomasahle
He seems to be from Mozilla..

~~~
kevingadd
Literally his first slide says that he works for Google on Dart. What is this
nonsense?

------
lars_francke
I am mostly a Java developer. I guess I could write syntactically correct
JavaScript but it's a bit alien to me. As is the whole tooling landscape of
JavaScript (Grunt, Node, Angular, Backbone, etc.).

I'd like to do a few personal projects with server-side scripting and I need
to learn a new language and ecosystem for it. From what I've seen I'd rather
learn Dart because it is more familiar to me. What's been stopping me from
doing that is missing integration and/or documentation in asset compilation
toolchains for example in Play (i.e. no sbt-web plugin).

~~~
javajosh
You might try Adobe's editor, Brackets. It does a very good job at psudeo-
intellisense, can even infer argument types, and has lots of nice plugins for
working with JavaScript - including features that let you see the body of a
function under the cursor, or the JSDoc (the equiv of JavaDoc). There is a
JSHint plugin (linting is the closest JS gets to compilation). And of course
the Theseus debugger, which is quite good. I think its neat that the editor is
built on browser tech (Github's Atom is built like that, too).

Client side development is, ironically, somewhat _more_ complex because of the
lack of module standard. You'll almost certainly want to use require() in the
browser, but that won't work without taking extra, confusing steps.
'Browserify' pre-processes your JavaScript, generating a single large bundle,
but that introduces complexity both at build- and run-time. And that doesn't
even address the ongoing saga of the lack of a module standard for the
browser.

By contrast, writing simple programs or servers in Node is vastly more
enjoyable than in Java.

------
Soyuz
Anybody used Dart for serious web development?

~~~
woven
Way before 1.0 existed (and using an early version of Polymer called WebUI) we
built a first version of our app, e.g.
[http://woven.co/miamitech](http://woven.co/miamitech), which is a fairly
complex client and server side application. (The slowness is due to our poor
pgsql data design.) I'm now building a more focused version with the latest
SDK and Polymer, the beginnings of which are at
[http://mycommunity.org](http://mycommunity.org). For me it's simple: Google
is arguably the greatest champion of the open web and probably does more to
advance modern web development than most anyone else. V8 was a game changer,
and enabled Node. The same folks behind V8 are building, in essence, a better
Node. Modern web development with JavaScript is exciting, and there are so
many great libraries and resources out there, but there is also much to be
desired such as more structure, a saner language and a strong suite of core
libraries that play well together. In my experience, Dart is what they say it
is: a more structured approach to modern web app development.

------
A1kmm
I actually see the Google-backed web technologies as a net negative. The
general pattern is that 1) the community starts to develop good tools that
work well in all browsers 2) Google comes along with a technologically
inferior solution that they developed in-house. They present it as being
ostensibly completely free and open source, but it is designed in a way that
means it will be faster in Chrome and hard for other browsers to support as
well due to different architectural decisions. 3) Google markets the solution
well through its large and well connected employee and fan base, and so the
Google technology gets much more adoption than the earlier and technically
better alternative. Presumably they do all this in an attempt to make the web
unusable through any browser except Chrome, so they can over the long term
replace the open web with the 'Google web' that they control.

For example, compare Ember and Angular; Ember's architecture records the
dependencies between values, and only updates what needs to be updated when an
upstream dependency changes, while Angular has to recompute everything on
every 'digest' cycle. When it comes to writing directives in a complex Angular
application, you often to set a numerical priority field to the just the right
number to get things to happen in proper order - leading to spaghetti code
that is hard to reason about and fragile to extend.

I think Dart is even worse when compared to better emerging options like ghcjs
(which compiles Haskell to JavaScript) and Elm; these alternatives have more
powerful type systems that make common patterns like reactive programming and
generic programming much easier and safer. Control structures that are built
into Dart (e.g. the 'async' feature) can be treated as just one instance of a
general type class (e.g. Monad) with ghcjs.

I think everything considered, these highly promoted and usually highly
adopted but technically inferior Google front-end technologies are actually a
net negative for the web.

~~~
abritishguy
I agree that ember is better than angular but there is no reason why angular
should run faster in chrome so it is not really relevant to your first point.
In fact apart from Dart I can't think of any web technology that Google is
promoting to developers that will be faster in chrome.

------
bsaul
this talk didn't talk about server-side dart. does this mean the project is
refocusing on client code ?

also another question : does anyone here using angulardart can talk about how
much static type anotation helps ? i'm thinking of future<t> instead of $q and
directive writing ( which i always found a bit confusing, so maybe types
help).

~~~
WoodenChair
In regards to your question about server-side Dart, it seems that the space is
just beginning to mature. A couple frameworks have solidified a fan base such
as:

[http://redstonedart.org](http://redstonedart.org)

[https://github.com/lvivski/start](https://github.com/lvivski/start)

There's also a Dart specific hosting service that's in beta:
[http://www.dartvoid.com](http://www.dartvoid.com)

And there's been some success running Dart on Google Compute Engine through
App Engine Managed VM (not sure if this is out of beta).

------
dingdingdang
"Why Google thinks you should drop everything you do and pick up Go" .. no
wait.. compute error.

------
ajizzle
Another self-righteous blue haired web developer complaining that he doesn't
get enough geek respect in the current state of the web.

