
Dart is ready for the real world - leephillips
http://arstechnica.com/information-technology/2012/10/googles-bid-to-fix-javascript-dart-is-ready-for-the-real-world/
======
cletus
Honestly I still don't see the point of Dart. It's made some strange choices
(IMHO) like optional typing.

The idea that code can be shared between client and server is the panacea
touted by GWT, which (IMHO) failed to eventuate (eg some classes weren't "GWT
compatible" and this included protocol buffers generated classes). Dart seems
like the next throw of the dice. I am not optimistic about its successes.

Go on the other hand, seems to have an incredibly bright future (IMHO) and it
has lots of things in it that I like.

The only issue with Go, as a low-level (C++ replacement) language at least, is
that it is a GC language. I used to think that you could implement some kind
of ARC (automatic reference counting) system a la Obj-C/iOS 5+ as a middle
ground between manual memory management and GC but I now have doubts about
this, largely due to reference counting being an issue with locking on highly
concurrent systems (something not an issue on phones with Obj-C/iOS).

More to the point, I think Javascript is like the email of programming
languages: its ubiquitous and a whole bunch of people are convinced it needs
fixing but I'm not exactly sure why. More to the point, those fixes seem to be
incredibly complicated to the point of being a questionable value proposition.

I've been using AngularJS of late and to me it's a bit like the Lisp of
Javascript frameworks in the sense that it is actually incredibly expressive
but can have a steep learning curve. There is a lot that's simple about
Angular but once you start delving into custom directives that support ngModel
and the like you start requiring a deeper understanding of what's actually
happening.

Anyway, back to Dart: I wish them the best but the complexity of language
cross-compilation I think diminishes most if not all of the benefits of client
and server language-sharing.

~~~
ahoge
>It's made some strange choices (IMHO) like optional typing.

Yes, this may look a bit weird, but it actually makes perfect sense. Those
types are annotations. If you use them at the "API boundaries" (parameters and
return values), you already get most of the benefits you may know from Java or
C#.

Compare the doc comments you usually have to write with those baked-in type
annotations:

    
    
        /**
         * Foos the bar.
         * @param {int} x
         * @param {int} y
         * @returns {String}
         */
        function foo (x, y) {
            ...
        }
    

vs

    
    
        /// Foos the bar.
        String foo (int x, int y) {
            ...
        }
    

Much better, isn't it?

Additionally, adding those type annotations is useful right off the bat. The
IDE will make use of them right away.

>Go on the other hand [...]

Well, Go is very different. It has a completely different focus. It's more
like Rust, for example.

~~~
riquito
You made an example of how not to write documentation and then you shown that
the code was better without. That is not the point.

Try to add content to the documentation, as "what is expected to be x?", then
you can't remove it so easily anymore

~~~
TazeTSchnitzel
Um, I think that's a type annotation for closure compiler, not a documentation
comment.

~~~
ahoge
The closure compiler uses doc comments.

YUIDoc or JSDoc comments look pretty similar, for example. However, since this
stuff isn't standardized, there are some differences between different
flavors.

------
agentultra
From the editor-promoted comment:

 _Why are we bothering with developing new languages when what we should be
doing is developing a web standard for a universal bytecode + VM? Hell, use
the JVM or the CLR, just as long as it doesn't tie me to a specific language.
Dart may be better than JavaScript (I would hope so) but that doesn't mean
it's a silver bullet. If we create a standardized bytecode, it doesn't matter
what language produced it._

I've been thinking about something like this for a long time. However, the
question came up in an interview or presentation with either Brendan Eich or
Douglas Crockford (I can't remember exactly where I read this) about why
Javascript won out over a VM solution (supposedly this is what the JVM was
made for). The most salient argument against a universal VM was that
maintaining backwards compatibility between byte-code versions and the
competing eco-system of languages would have been a nightmare. Instead the web
targeted a single language (and all the trouble that has been along with it).
I would rather like to see other languages on the web but I don't think a
browser is good place to do it.

Instead what I'd rather see is
<http://www.cs.cornell.edu/home/ulfar/cuba/paper/> \-- work could be done to
improve that initial design, but the idea IMO is that the OS already handles
processes and allocating memory well and the browser vendors are terrible at
this task by comparison.

Either way, Dart is an interesting experiment and I'd give it a shot on some
prototyping projects.

~~~
billwashere
Brendan Eich talks about the VM solution
(<http://www.youtube.com/watch?v=Rj49rmc01Hs> Slides:
<http://brendaneich.github.com/Strange-Loop-2012/#/>).

I personally believe that HTML is fantastic for what it was designed for:
Structured Documents. But the world has gone more interactive and I believe
the ad-hoc solution of Javascript, HTML and CSS is not "rich" enough to
provide for the users demand.

I like the language independent VM idea as long as it doesn't turn out like
bloated Java bytecode.

~~~
ralph
#golang had Limbo in its ancestry, another CSP language, this time for the
Inferno register-based VM from Bell Labs. Target Go at a browser VM?

------
bengillies
From what I've seen of both, TypeScript seems like the language that Google
should have created in the first place. It has similar goals, but without the
"let's create a whole new VM and replace the entire JacaScript runtime in all
browsers" ambition (which is ridiculous).

~~~
polux
(Disclaimer: I'm partly working on Dart)

\- Every Javascript program is a valid typescript program so typescript
doesn't fix JS semantics (like variable hoisting and the only numeric type
being floats). I think typescript is a good fit when you already have some big
JS project and you want to get some type errors by loading a predefined
signature for jquery or whatever library you're using. You basically get a
linter + code completion for free on a pre-existing project. But if I have the
choice between Javascript and any other language with saner semantics to start
a new project, then I will for sure not chose Javascript.

\- I don't think that Dart aims to "replace the entire JacaScript runtime in
all browsers", even though the Ars Technica article says so. It's an
alternative to Javascript, exactly like Ruby is an alternative to Python. Of
course there's a difference between Js vs Dart and Python vs Ruby: every
browser runs Js and only Js. That's why the story with Dart is: develop with
the VM and Dartium, so that you can reload you application with F5, use the
debugger, etc. and then deploy by compiling to Javascript.

~~~
MatthewPhillips
Function hoisting is a good thing.

~~~
polux
Sorry, what do you mean by function hoisting? The fact that you can write
mutually recursive functions at toplevel? Anyway, I was referring to variable
hoisting.

------
TazeTSchnitzel
I was excited about Dart, until I saw how many lines of code the JavaScript
output was for one of its simple examples.

And then I completely lost interest when I started structuring my code well,
and realised that I didn't need it as much as I thought.

~~~
ahoge
The output is more optimized now. However, there is a one-time cost for some
of the language features. So, it grows kinda quickly initially. There is some
sort of bump, basically.

Thanks to "tree shaking" (=dead code removal), you'll reach the break-even
point fairly quickly though. You can use massive libraries, buy only those
pieces you actually use get included in the final output.

For example, the last JS app I wrote is about 80kB (minified and compressed).
jQuery alone took about 33kB of that. How much of jQuery do I actually use?
I'd guess it's less than 20%.

So, even with that initial overhead, a Dart version would be probably a bit
smaller.

------
saltonc
I'm not convinced. After Google killed numerous projects this year, I'm a
little skittish about jumping into Dart. When it has the traction of Go, I'll
be more willing.

~~~
justinschuh
Second time I've seen this today. An account created minutes after the
submission apparently just for the purpose of spreading FUD.

~~~
ternaryoperator
I disagree that it's FUD. Not every concern expressed about a new technology
is FUD. And it seems to me that Google's history of canceling projects that
get only limited traction does provide a legitimate concern.

------
jabr
There are some things in Dart that would be nice to have in Javascript, but I
don't see why Google wouldn't just try to work them into future ECMAScript
revisions. With the exception of banning eval and run-time modification of
prototypes, I don't see anything that's completely incompatible with a future
revision of Javascript.

I'd even bet that the ES standards committee will eventually give in on the
"arrow" lambda style. ES5 has the "function(x) x * x" shorthand, but with C#
and Java both settling on "(x) => x * x", I can see it happening in time.

~~~
kevingadd
They did a while ago:
[http://wiki.ecmascript.org/doku.php?id=harmony:arrow_functio...](http://wiki.ecmascript.org/doku.php?id=harmony:arrow_function_syntax)

------
Kilimanjaro
You know what, bringing Dart to android development may be a good idea. Web
hobbyists hate java with a passion but may embrace Dart for its resemblance
with javascript.

~~~
georgemcbay
Bringing Go development to Android would be even better, but I doubt either
will ever happen, at least not as an officially sanctioned way to create
native apps.

~~~
sigzero
Oh I would love for Google to do that!

------
discreteevent
I like it. Here's what it has got for me:

Isolates: Message passing concurrency which takes away 80% of the problems
with threads and locking. I find it intuitive in the way that Unix pipes are
intuitive. A few other languages have this also but Dart is one of them and
its a plus.

Optional Typing: Its a dynamic language so its very flexible. Some statically
typed languages are also flexible but you can still run into some very complex
cases with the type system. I want to focus on my application. By having
optional types though I can get 80% of what static, strong typing gives me,
namely documentation, the ability to quickly reverse engineer someone else's
code and runtime type checks. You know all those unit tests that you write in
a dynamically typed language just to check the type of some parameter? With
Dart you just turn on a switch and those unit tests are built in (I don't
think typescript gives you this as the type information is erased at runtime)

Native debugger: I want my apps to run everywhere which means generating
javascript. I see the Dart VM as a native debugging environment. Google have
built a special VM so that I can debug Dart natively. I don't think source
maps will be able to give as rich a debugging experience.

Tree shaking: The size of javascript libraries is a big issue. Have you tried
looking at some sites over a slow mobile connection? Tree shaking looks like
it will make it possible to only pay for what you use. This is a major plus

A consistent core: How many javascript libraries are there? Which should I
pick? I don't even want to pick anymore I just want to get on with the job.

A pretty good experience: Rob Pike had an article a while ago about people
complaining about a language without using it. I tried Go and that's why I
like it. I also tried Dart with the Dart editor. Its nice, the libraries are
good, the language is fluent and concise enough. Everything seems to be in the
right place.

------
smegel
Dart + Native Client Modules almost makes me excited about web programming
again. Obviously not for general websites, but for specific applications it
would not be unreasonable to require Chrome to be installed as the alternative
would be installing a native app anyway.

~~~
iSnow
Not again. We have been through this with ActiveX and it was no fun. Similarly
we have been through "works on every OS (if it is Windows)".

Web development today with JS/CoffeeScript + jQuery + Underscore and other
libs is not hard. Just accept that different users will use different
browsers.

~~~
smegel
I am more thinking of Dart+Native Client as a nice alternative to native
application development rather than an alternative to general web development.

If you wanted to write an application that performed with native speed would
you rather write it multiple times for Windows, Linux and OSX, iOS* and
Android (and make sure it compiles on multiple architectures) AND force your
users to install and update the application on their computer...

OR

Write it once as a mixed Dart/Native Client app targeting the LLVM bytecode
and run it securely in the Chrome browser on multiple platforms? All the user
needs to do is install Chrome and visit a URL. Updating the app becomes
trivial.

I am not saying it is the clear winner, but to me it sounds like a damn
interesting alternative with a lot of promise.

It is also _possible_ that Chrome will "win" - either by gaining such majority
user-base that targeting specific features of Chrome becomes worth while, or
because Dart+Native Client becomes a de facto standard the other browsers
adopt.

Also, if you are writing a "web app" to target a niche market that really want
to use the application (hard-core gamers?), requiring Chrome really may not be
a big deal for the user-base. After all, if people are willing to install
native applications on their local system, why would they be unwilling to
install Chrome and visit a URL?

* It is unclear if the Chrome browser on iOS will ever be able to download and run native code for both technical and policy reasons.

------
OrdojanAndrius
I haven't read all the comments sorry if this has been posted already. I think
you guys would enjoy listing to this discussion about TypeScript, Dart and
JavaScript between Anders Hejlsberg and Lars Bak the guy behind V8 and co-
creator of Dart.

Link: [http://channel9.msdn.com/Shows/Going+Deep/Anders-
Hejlsberg-a...](http://channel9.msdn.com/Shows/Going+Deep/Anders-Hejlsberg-
and-Lars-Bak-TypeScript-JavaScript-and-Dart)

------
MatthewPhillips
My problem with Dart is that it's just not that interesting from a language
perspective. TypeScript is somewhat interesting in that it has a very low
learning curve for JS devs, so that you can go straight to using ES6 maximally
minimal classes and type annotations. The ability to jump straight in makes it
worth a look. But Dart... Dart is a different (by similar) language that,
therefore, has to be learned like any other language. And I simply have no
desire to learn another traditional object oriented language that has all of
the same features as other object oriented languages but with a "we do this
one small thing better" proposition.

You might say that this is the point, but I have to ask why they didn't just
fully commit to GWT instead. If the point is to attract Java developers, that
seems like the more logical way to go.

------
fourstar
I was at this. I was really looking forward since listening to the Javascript
Jabber podcast ([http://javascriptjabber.com/008-1-v8-and-v8-and-dart-with-
la...](http://javascriptjabber.com/008-1-v8-and-v8-and-dart-with-lars-bak-and-
kasper-lund-bonus-content/)) about it.

Less than 1/3 through I decided to started to zone out. I don't understand why
you need a VM to compile something into Javascript. Also the optional typed
language feature is just odd (okay I can see working in groups and wanting to
empirically let other developers what type a variable is), but it's just not
something I see myself wanting to learn to do what I already know.

I was also interested in the Angular talk, which was good, but it left me
thinking Angular is to CakePHP in the MV* javascript world with all the built-
in automagic.

Overall some pretty good talks at this.

~~~
polux
You don't need a VM to compile something into Javascript but the VM buys you a
fast edit/reload cycle and some tooling like a debugger. Also Dart can be used
as server-side language and there the VM makes sense. It can also be used as
an interpreted language just like Python and here it doesn't hurt if it's
fast.

Even if _you_ don't put type annotations in your code, the IDE infers types
(locally) and gives you useful warnings and code completion.

------
islon
Is google really betting dart will take off? Because I don't see
microsoft/apple/mozilla supporting it in the future. But of course dart can
still be a cofeescript competitor.

~~~
kevingadd
They don't need anyone else to support it. Compiling to JS means Dart apps
will work in other browsers, and in a Chrome-only world (the world Google
wants to exist), everyone will benefit from the native Dart VM.

------
loftsy
I have been using dart for a couple of months now and am extremely happy with
it. Code completion on the DOM API is a different world to the classic
javascript edit-test-fix syntax error cycle.

The language and the vm are a distraction. The huge win with dart is what the
IDE will do for your productivity.

------
zobzu
Dart, attempt 35.

------
ekm2
Could someone throw a good "Beginning Dart" Tutorial here please.Just want
play with it.

------
perfunctory
Why does this video sound like a tv shop program selling body hair removal
solutions.

