Google Dart target: Chrome soon, other browsers someday
news.cnet.com
news.cnet.com
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."
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.
How many within the first year of it's development?
asm.js does not have Pepper, so I think it actually has fewer layers.
"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.
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?
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. :(
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.
* 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.
"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.
There are no attempts to standardise Dart, it's just the rubber-stamping of Dart by ECMA. Think C#.
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.
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#.
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).
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.
As for mobile, it's clear a lot of companies have no problem building their app twice (for both iOS and Android).
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?
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.
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.
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...
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.
This is a genuine attempt to make the web better - I'm definitely supporting it.
Better for Google that is.
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.
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.
> 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.
NaCl is the second coming of ActiveX.
I will only touch Dart when it is natively supported in major browsers or required by our customers.
- 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