Google Dart target: Chrome soon, other browsers someday(news.cnet.com)
news.cnet.com
Google Dart target: Chrome soon, other browsers someday
http://news.cnet.com/8301-1023_3-57615837-93/google-dart-target-chrome-soon-other-browsers...someday/
14 comments
Browsers should compete on performance. As long as dart2js outputs efficient JavaScript (current benchmarks: 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.
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.
> 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?
What stops sites from shipping Dart only and not shipping the JavaScript?
Nothing. Expect some sneaky deals on special Chrome apps in the future that will convince popular apps (with a nice sum of money) to have their hot new app being 'dart exclusive'. It's the obvious end game that sounds cynical if not for the fact that every single company in that position has historically abused that position.
They'd lose a huge chunk of traffic, but otherwise nothing would stop them and someone is eventually bound to try it.
The same thing that prevents sites from shipping sites that only support particular browsers today.
> 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. :(
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. :(
Why would a site want to target only Chrome? If your site has a URL, I think it's of the site's best interest to target many modern browsers and provide a graceful upgrade/download experience.
> Why would a site want to target only Chrome? If your site has a URL, I think it's of the site's best interest to target many modern browsers and provide a graceful upgrade/download experience.
I agree that sites should do it, but developers have not done this in the past. If Chrome has a commanding market share, history says that developers will not bother to target other browsers.
I agree that sites should do it, but developers have not done this in the past. If Chrome has a commanding market share, history says that developers will not bother to target other browsers.
nothing, it's their loss. But seeing how you can get JS support "for free", then there's no reason not to have both available.
It's also possible to add other vendor prefixes "for free", but that didn't stop WebKit-only prefixes from appearing all over the mobile Web. Developers do what is easiest.
[deleted]
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.
You incorrectly presume that Brendan Eich has such great affection for Javascript. To paraphrase comments that Eich himself has made here on HN, he'd be the first to celebrate should JS be relegated to the dustbin of history.
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.
"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.
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.
"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.
> We'll see if the attempt to standardize Dart
There are no attempts to standardise Dart, it's just the rubber-stamping of Dart by ECMA. Think C#.
There are no attempts to standardise Dart, it's just the rubber-stamping of Dart by ECMA. Think C#.
Maybe so, but there's still great value in a normative, comprehensive, practically implementable written specification, whether you choose to call it a "standard" or not. Taking your example, imagine how painful it'd be to write a C# compiler from scratch with the language defined by one of the existing implementations. As just one example of the madness this would entail, see Eric Lippert's "magic zero" "definition" from one version of Microsoft's C# compiler in
http://blogs.msdn.com/b/ericlippert/archive/2006/03/29/the-r...
where the compile-time literal (8 * (0+(7-7))) implicitly converts to an enumeration type, but (8 * ((7-7)+0)) does not.
http://blogs.msdn.com/b/ericlippert/archive/2006/03/29/the-r...
where the compile-time literal (8 * (0+(7-7))) implicitly converts to an enumeration type, but (8 * ((7-7)+0)) does not.
> there's still great value in a normative, comprehensive, practically implementable written specification
True but completely irrelevant to vor_'s comment. For all intents and purposes, Dart is still a non-standard language controlled by one company, exactly as C#.
True but completely irrelevant to vor_'s comment. For all intents and purposes, Dart is still a non-standard language controlled by one company, exactly as C#.
Like asm.js?
asm.js is standardized, in that its semantics are fully defined by ECMA-262, which is a multi-vendor, widely implemented standard.
I may be wrong, but I see Math.imul as part of the asm.js spec and I believe it's an extension on ECMA-252.5 (and related libraries, IIRC typed arrays are part of the webgl stuff, not ECMA-262)
Yeah, you're right. Both are part of the ES6 draft though:
https://people.mozilla.org/~jorendorff/es6-draft.html
https://people.mozilla.org/~jorendorff/es6-draft.html
Neat, I had no idea typed arrays were being moved into ES6.
If we're going to choose a transition language, maybe we should think about it a bit more ? Considering how different paradigms are entering mainstream, why jump for a class-based statically typed OOP-heavy language? Dart might be better than JS, but is it better than most other candidate languages?
It probably won't be successful, but I'm excited. I can't stop dreaming of a future devoid of javascript.
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).
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).
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.
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.
We wait first for Google to put Dart into Android development... then we'll take a look at him.
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.
[deleted]
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.
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.
"Works best in Chrome"
Microsoft tried this with ActiveX. Deja-vu, all over again. http://technologizer.com/2010/09/16/the-unwelcome-return-of-...
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.
Microsoft tried this with ActiveX. Deja-vu, all over again. http://technologizer.com/2010/09/16/the-unwelcome-return-of-...
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.
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.
This is a genuine attempt to make the web better - I'm definitely supporting it.
> This is a genuine attempt to make the web better
Better for Google that is.
Better for Google that is.
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.
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.
>Microsoft tried this with ActiveX. Deja-vu, all over again.
And Netscape (Mozilla's grandaddy) tried it with Javascript.
You know, the then proprietary to their browser technology that we now use as a standard. What "works best in X" can eventually be an adopted standard given time.
That said, your analogy is also flawed in another way. Active X was faulty technologically (insecure), proprietary and closed source.
Dart is better than JS architecturally, is open source, AND is passing through a standards body for standardization.
So no relation to Active X at all.
And Netscape (Mozilla's grandaddy) tried it with Javascript.
You know, the then proprietary to their browser technology that we now use as a standard. What "works best in X" can eventually be an adopted standard given time.
That said, your analogy is also flawed in another way. Active X was faulty technologically (insecure), proprietary and closed source.
Dart is better than JS architecturally, is open source, AND is passing through a standards body for standardization.
So no relation to Active X at all.
> And Netscape (Mozilla's grandaddy) tried it with Javascript.
> You know, the then proprietary to their browser technology that we now use as a standard. What "works best in X" can eventually be an adopted standard given time.
While true, everyone agrees that was the wrong way to go and suggesting that we repeat that mistake is... a mistake.
> You know, the then proprietary to their browser technology that we now use as a standard. What "works best in X" can eventually be an adopted standard given time.
While true, everyone agrees that was the wrong way to go and suggesting that we repeat that mistake is... a mistake.
Except that ActiveX works only in Windows. The finance dept where I work all need Windows VMs to access this one website that won't work on OS X.
Dart is more Visual Basic than ActiveX.
NaCl is the second coming of ActiveX.
NaCl is the second coming of ActiveX.
I fully agree with you.
I will only touch Dart when it is natively supported in major browsers or required by our customers.
I will only touch Dart when it is natively supported in major browsers or required by our customers.
Why wait for the VM when you can compile to JavaScript today?
Because customers only request JavaScript and I don't want to debug code generated from tools.
Have you tried to use source maps to help debugging? Plenty of compile-to-JavaScript languages support source maps, and even some CSS frameworks. Building complex/large apps without a compiler and tools is really difficult. GWT, Closure, TypeScript, Dart are all efforts to help developers build more interesting apps that scale. Building/compiling is just a natural step in the process, and source maps are a natural output of that process.
As I repeated here multiple times:
- customers request JavaScript written by humans, not tools. As it makes them easier to get "resources"
- source maps are only an option on a few desktop browsers, no fun testing generated JavaScript on specific browser issues
- customers request JavaScript written by humans, not tools. As it makes them easier to get "resources"
- source maps are only an option on a few desktop browsers, no fun testing generated JavaScript on specific browser issues
I can only hope that one day the tyranny of JS and HTML will be broken.
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. :)
> 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.
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.
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).
As for mobile, it's clear a lot of companies have no problem building their app twice (for both iOS and Android).
> 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?
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?
I stand for the victory of the native mobile.
I have no problem with that kind of future! Mono rules.
And that democracy of desktop becomes the new trend.
Even if it is replaced with something worse?
Hard to imagine frankly speaking, but any sort of "monopoly" is bad.
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.
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.
Whats the obsession with beginner friendly languages as of late? I can understand it to some extent, but at the end of the day, as long as its size doesn't cause problems does size really cause long term issues? After all you are going to be using (and learning) the language far longer than you're going to be a beginner.
I find Dart much easier to learn than Java. Check out http://programming.oreilly.com/2013/05/dart-is-not-the-langu... for many differences between Java and Dart.
I would love to see CoffeeScript with optional typing. Easy syntax, typing support for larger projects and compilation to JavaScript. The new compiler seems like it may actually be possible to support it too.
I have high hopes for Ruby in the browser. https://github.com/opal/opal-browser
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."
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."
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.
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.
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.
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).
Ah. Thanks for the info.
As far as I understand, the semantics of asm.js make that not very interesting.
> The project has mostly Google engineers committing, but we also have plenty of open-source contributions.
How many within the first year of it's development?
How many within the first year of it's development?
According to the history of the AUTHORS file (commits are not properly attributed in the repository, as far as I can see) there were 12 "external contributors" in the first year of dart (as a public project anyway): https://code.google.com/p/dart/source/browse/branches/bleedi...
Good question, I'd have to run some queries. dart.googlecode.com and github.com/dart-lang are the two main locations. We receive more patches for the libraries and docs than we do for the VM. But we have received patches for dart2js (a fairly complicated bit of code).
asm.js amuses me.. so many useless layers, NACL is much more sensible. But oh well Brendan Eich wants to keep his bragging rights.
> asm.js amuses me.. so many useless layers, NACL is much more sensible. But oh well Brendan Eich wants to keep his bragging rights.
asm.js does not have Pepper, so I think it actually has fewer layers.
asm.js does not have Pepper, so I think it actually has fewer layers.
I saw some benchmarks showing that Dart was slower than JavaScript... Is there truth to this?
Here are the latest benchmarks:
https://www.dartlang.org/performance/
https://www.dartlang.org/performance/
Really depends on what you're doing. The performance benchmark on Dart's site shows some of the strengths of Dart. There are other areas that are weak. See the Computer Language Benchmark Game[0].
A lot of those tests rely on fast i/o handling (be it a file or stdin/stdout). Also being able to work with large data structures and manipulate them in various ways. Dart does decent on some tests but fails on others. Also, all of the implementations are submitted by users, so there may be faster ways to do things, but it at least gives you an idea.
[0] http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te...
A lot of those tests rely on fast i/o handling (be it a file or stdin/stdout). Also being able to work with large data structures and manipulate them in various ways. Dart does decent on some tests but fails on others. Also, all of the implementations are submitted by users, so there may be faster ways to do things, but it at least gives you an idea.
[0] http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te...
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.
* 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.
"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.