
Google Dart target: Chrome soon, other browsers someday - daw___
http://news.cnet.com/8301-1023_3-57615837-93/google-dart-target-chrome-soon-other-browsers...someday/
======
_greim_
I'm sad that it's a Google-only thing and that all the other browser makers
are balking. Purely in terms of the merits of the language, it strikes me as
leaps and bounds better than JS.

I'm also a fan of Mozilla's asm.js. It seems to have so much potential. As a
full-time JS dev, I guess I'm easily impressed. I just wish the browser makers
could get their heads together and agree on some way forward, instead of
incrementally polishing the JS "turd."

~~~
sethladd
Dart compiles to JavaScript, is open source, and is now in ECMA. The project
has mostly Google engineers committing, but we also have plenty of open-source
contributions.

asm.js is a compile target that takes C/C++ code and outputs lots of typed
arrays, and a custom engine to interpret the asm.js "hints". It's an
interesting way to get C code onto the web, but developers don't write asm.js
code by hand. In contrast, Dart is designed to be written by developers. The
similarity is that both asm.js and Dart want to enable faster experiences for
users, but they take very different approaches.

~~~
_greim_
I thought that asm.js would be a compile target for _any_ language, not just
C/C++. E.g. you could have dart2asm instead of dart2js.

~~~
mraleph
Unfortunately right now asm.js is an unsuitable target for any dynamically
typed language with garbage collection, because you have to run your whole
runtime system and a garbage collector as asm.js'ied code, which is not
exactly what you want in terms of overhead. Asm.js is a target for anything
that is statically typed and low-level (e.g. C).

~~~
_greim_
Ah. Thanks for the info.

------
ChuckMcM
Wow.

"We have a language that works only/best in our browser, features that work
only/best in our browser, a dominant OS which requires automatically
includes/installs our browser."

I guess it was a good strategy for Microsoft while it lasted (and still pays
benefits) so they might as well copy it. It will be funny if the EU requires
Android phones / tablets to give you a 'browser choice' when you first turn
them on / install them.

~~~
sethladd
Browsers should compete on performance. As long as dart2js outputs efficient
JavaScript (current benchmarks:
[https://www.dartlang.org/performance](https://www.dartlang.org/performance))
so that Dart code runs well on browsers without the VM, I think it's fine if
some browsers run Dart more efficiently than others. Consider Dart VM as an
accelerated way to run Dart code _which otherwise runs fine in other
browsers_.

To be very clear, Dart runs across the modern web when you compile it to
JavaScript, so it's not a language that works only in one browser.

~~~
pcwalton
> To be very clear, Dart runs across the modern web when you compile it to
> JavaScript, so it's not a language that works only in one browser.

What stops sites from shipping Dart only and not shipping the JavaScript?

~~~
lukesandberg
The same thing that prevents sites from shipping sites that only support
particular browsers today.

~~~
pcwalton
> The same thing that prevents sites from shipping sites that only support
> particular browsers today.

That's right, and historically encouraging authors to use vendor-specific
stuff by making that the easiest thing to do, whether it be
filter:progid:DXImageTransform, WebKit prefixes, ActiveX banking plugins, or
what have you, has been bad for user choice.

To give just one example, WebKit asked authors not to rely on WebKit prefixes,
but they did and now we're in the situation where just yesterday I wasn't able
to use clippercard.com on Firefox for Android because the design was so broken
as to be unusable. :(

------
BrandonSmith
Dart could be the glue between Chrome and Android.

* Sundar Pichai (Google VP) oversees both Chrome and Android.

* Google is experimenting with ART (LLVM-backed AOT runtime) for Android. This could be modified to run Dart directly.

* Angular was recently ported to Dart.

* Polymer is Google's Web Component polyfill until browsers catch up.

* Android layouts and views are essentially a form of components. (Possibly mapped to Web Components???)

I could see a singular development vision of Angular + Dart + Web Components
where Chrome apps are Android apps and vice versa.

------
salient
Do we really need another Java-like language? I would think since web
development is often an "entry level" for many beginning programmers, we need
languages with prettier syntax and easier to grasp, something like Python.

~~~
jiggy2011
Dart has optional typing so it should feel familiar to you whether you have a
background in Python or Java. IIRC being easy to learn is one of the explicit
goals of dart.

------
fidotron
Mozilla's take on Dart really strikes me as an emotional and not technical
reaction. They may have a valid point about PNaCl, but Dart presents the
opportunity to do a managed transition from JavaScript to something better.
Having someone for whom JS is their baby as your CTO is going to make letting
go very difficult.

~~~
vor_
Well, until recently, the proposed transition was to a non-standard language
controlled by one company. We'll see if the attempt to standardize Dart has a
positive effect.

~~~
kibwen
"Control" of any language is held by those with commit access to the dominant
implementation of that language, regardless of the existence of any formal
specification. In the absence of at least two healthy and competing
implementations, an ECMA standard will do nothing to alleviate the concerns
that people have voiced regarding Dart.

~~~
spankalee
Well, there are two implementations already: dart2js and the Dart vm, but this
is why TC52's work item #3 is so important:

"To develop test suites that may be used to verify the correct implementation
of these standards."

This way other implementations have an accessible way of testing compliance.
I'm not sure if we'll see another JIT'ing VM soon, but I personally hope
there's a JVM implementation one day.

------
JonSkeptic
It probably won't be successful, but I'm excited. I can't stop dreaming of a
future devoid of javascript.

------
kyrra
Google is a large company that is pushing various tech from a lot of different
angles. You have the V8 team that has done a lot of great work for Javascript
speeds. Members of V8 also were part of the EMCAScript committee to help move
the language forward. With Google's focus on Dart, some of those V8 members
have moved on to Dart.

Google has also been doing a lot of work with the Shadow DOM, Polymer, and
lots of other fun tech.

Dart is an experiment to see if they can create a better scripting language
for the web. Who knows if it'll work out, but it's nice to see a company
trying something a little out there.

I'm sure creating large web apps like GMail or Docs in Dart would be much more
pleasurable than doing it in Javascript. For smaller scripts just to do simple
form stuff, it probably won't be any better (but hopefully not worse than
Javascript today).

------
CmonDev
I can only hope that one day the tyranny of JS and HTML will be broken.

~~~
sethladd
If the web community doesn't continue to work on innovative new platform
features, and deliver fantastic experiences for mobile users, then native
mobile (ios, android) will become the de facto way to deliver apps to users.
That day is more likely and closer than some may want to believe. So double
check before you say something like your comment. :)

~~~
masklinn
> then native mobile (ios, android) will become the de facto way to deliver
> apps to users

I don't know which planet you're living on, but native _is_ the de-factor way
to deliver apps to users. Apple tried the other one during the first year of
iphone, developers mostly sat on their hand and waited for a native SDK.

> That day is more likely and closer than some may want to believe.

That day is 10 years ago, give or take some. The web has yet to _ever_ become
the de-facto way of delivering application on mobile, it's barely getting
there on desktop.

~~~
sethladd
I think the web was a big success on desktop (modulo some pretty big apps like
Photoshop, and we should ask ourselves why apps like Photoshop never landed in
the browser, and then fix those issues).

As for mobile, it's clear a lot of companies have no problem building their
app twice (for both iOS and Android).

~~~
masklinn
> I think the web was a big success on desktop

Hear that sound? That's your goalposts scraping the tarmac as you move them
around.

> As for mobile, it's clear a lot of companies have no problem building their
> app twice (for both iOS and Android).

Which is relevant to the conversation... how?

------
stcredzero
_Specifically, he pointed to problems with having two separate virtual
machines, both trying to clean up computer memory through a process called
garbage collection and both trying to control Web page elements through the
browser 's Document Object Model (DOM) interface. "Two runtimes sharing the
DOM adds both bug habitat and a performance tax," Eich said. That's an
objection Apple has raised, too._

Why have two garbage collectors sharing the DOM? Couldn't one construct a
bridge that synthesizes Javascript under the covers to access the DOM and also
maintains a reference for the separate Dart GC for the Dart object trying to
access the DOM? This would mean that the native Javascript GC wouldn't have to
be aware of Dart at all, apart from the presence of some special Javascript
objects that don't get collected by it. Then, when the Dart side is done, and
the Dart objects go away, remove the "special" flag from the JS bridge objects
and let them be collected normally. (There are a few more wrinkles than that,
of course.) Performance would be slower for non-native Dart VMs, but it should
be possible to leave Javascript GC mostly untouched.

------
voidr
As a web developer I have to say: a 2x increase in JS performance is
insignificant.

If I would profile most web apps, JS execution wouldn't account for much of
the processing time, the DOM interactions are order of magnitude slower.

Users would barely notice a 2x increase in JS speed.

Also the snapshotting could be done with JS too if Google would be really
concerned about startup time.

I would say that at this given moment in time the performance argument is BS,
the real reason is that most of Google are Java developers that probably don't
like JavaScript and they want something that looks more like Java, because
that's what they are used to.

JavaScript has it's issues, however I think that TypeScript the superior
approach towards these kinds of problems.

------
liviu
We wait first for Google to put Dart into Android development... then we'll
take a look at him.

------
manishsharan
I have always wondered whether an average Javascript programmer could generate
ninja like javascript code using Dart ? If so, I would gladly invest the time
to learn Dart.

------
TheAceOfHearts
I saw some benchmarks showing that Dart was slower than JavaScript... Is there
truth to this?

~~~
indy
Here are the latest benchmarks:

[https://www.dartlang.org/performance/](https://www.dartlang.org/performance/)

------
andyl
"Works best in Chrome"

Microsoft tried this with ActiveX. Deja-vu, all over again.
[http://technologizer.com/2010/09/16/the-unwelcome-return-
of-...](http://technologizer.com/2010/09/16/the-unwelcome-return-of-best-
viewed-with-internet-explorer/)

In Google's words: "The goal of the Dash (Dart) effort is ultimately to
replace JavaScript as the lingua franca of Web development on the open Web
platform"

I will never support Google's walled garden. Dart is a pathogen.

~~~
snird
walled garden? ActiveX? your comment is pure FUD. dart is as open as possible
- open source, open standard etc' etc'.

This is a genuine attempt to make the web better - I'm definitely supporting
it.

~~~
pjmlp
> This is a genuine attempt to make the web better

Better for Google that is.

~~~
sethladd
Better for users also (and yes, better for Google because Google makes money
when people see and click ads on the web).

When the web has more interesting content being produced by more motivated
developers, users win. When the web starts up faster, users and vendors win.
When pages and apps run much quickly on the web, users and vendors win.

