Dart is part of Google's strategy to replace open-standards with its own proprietary walled-garden. Let's hope it doesn't work. Stay away from Dart.
Yes, you have the source code, so you can fork Dart if you want, I guess. How are you going to get your Dart fork into a browser?
Sounds like any other language or any other piece of technology. No one starts with standards. This always happens some time after 1.0.
http://en.wikipedia.org/wiki/JavaScript#History
first shipped in beta releases of Netscape Navigator 2.0 in September 1995
In June 1997, Ecma International published the first edition of the ECMA-262 specification.
> you can fork Dart if you want
You don't have to. The tools and the VM will continue to work. In the late 90s, I used a compiler from 1989. It still worked fine and it still works fine today (e.g. via DOSBox).
I really don't know why everyone here seems to think that these kind of tools will self-destruct if left alone. They really don't do that.
> How are you going to get your Dart fork into a browser?
You don't have to. You can still compile to JavaScript. You can still use the VM on the server, for command line stuff, or on Android devices (there will be an ARM VM soon).
It would be only a problem if you wouldn't be able to use browser with native Dart support for client-side web development, because compilation takes a few seconds and because you wouldn't be able to debug from within the IDE.
Is your concern that Google's name behind it will give it more popularity than its design/implementation merit, and you'll have to use it instead of Javascript because employers/clients will demand it? The job market is much bigger than you are imagining: I'm sure someone out there will still pay you to write COBOL. So I wouldn't worry too much about this yet.
The current community seems pretty active, and Dart isn't even at 1.0 yet: https://groups.google.com/a/dartlang.org/forum/?fromgroups#!...
Google commands tremendous marketshare with Chrome now, and so people are going to be hyper-sensitive about anything it does. But I would read PPK on Blink for example (http://www.quirksmode.org/blog/archives/2013/04/blink.html) to see how Google is treating the Web.
Honestly, the Web has been driven forward tremendously in the last few years with HTML5, CSS3, WebRTC, etc but Javascript hasn't budged much, although performance has increased, the warts of the language have not been fixed, and TC39 is taking too long. That's why you're seeing everyone create languages that compile down to JS.
My biggest concerns are that if the problems of the Web platform aren't fixed, especially for mobile, a whole generation of people will be raised on native apps, and the most amazing platform for distribution of federated, transparent information in human history will lose.
Simply put, the Web is more important than Javascript.
I respect your work a lot, but are you sure your view is not biased a bit by working for Google? It's sometimes hard to disconnect from that kind of working environment to see the kind of issues into the future certain practices can have.
Dart turning into something bad for the web is really not all that unfounded or unjustified. You don't have to agree, but you shouldn't dismiss that argument so quickly.
Dismissing this kind of thing is what leads to 'impossible' scenarios happening. The point needs to be raised, repeatedly, and hopefully within Google as well. As long as a possibility exists for Google to misuse Dart, there needs to be voices speaking out against that possible misuses before it occurs, not after.
Google is interested in making the experience of developing web apps better, and making web apps more performant. They have many different strategies for this: Chrome DevTools, AngularJs, Web Components and other spec improvements, Dart, Closure Compiler, GWT, etc. The company does not make money from selling the Chrome browser, and unlike Microsoft, it doesn't make money from selling an OS. The incentives are not aligned like the way they were with IE and Windows. At the end of the day, Google makes money from people using the web. The real threat is from the Web falling too far behind Native.
Also, the Web is far far bigger than the programming language Javascript. For the first 10+ years of the Web, people hardly even used JS except for form validation, and in general, on mobile, excessive amounts of JS lead to poor performance.
There's still a ways to go on just HTML and CSS, and I'd frankly be more concerned about fragmentation in that area rather than fixation on Javascript.
The way I see the potential of a DartVM is the same as OdinMonkey+asm.js. Dart compiles to JS, but DartVM will run it slightly faster, but it will always work on all browsers. Likewise, asm.js will work on all browsers, but will always run faster on OdinMonkey. Both Mozilla and Google have VMs that potentially bifurcate performance across browsers, but still produce outputs that can run (albeit slower)
The concerns you should have about Google misusing Dart I think should really be about Google misusing market share. It's not really Dart per se that's the issue, it's the fact that if Chrome is the dominant browser, Google can drop anything they want into it, not just Dart, but any APIs they want.
It's much harder to write cross-browser CSS, with full GPU compositing, and responsive layout than it is to compile Dart to JS. What is the incentive for the developer not to do is and leave a huge chunk of marketshare on the table with little effort?
Stuff like prefixed-CSS is a far far worse threat to the Web than a DartVM.
History tells us what will happen.
Again, I'm not disagreeing that there is a danger of fragmentation, but this won't happen because of Dart, but because of other forces. The criticism over the DartVM is being blown way out of proportion.
The best defense against any of this happening is not to protest Dart, but to make sure the browser market is competitive.
Why wouldn't you? Minifying Dart or compiling Dart to JavaScript is basically the same. You invoke the very same command line tool just with different switches.
Why would you do one thing in your build/deploy script but not the other? Especially if doing so makes it incompatible for a significant chunk of your users. Most people won't even drop a 5% chunk (e.g. something like IE8).
>or not testing it [in other browsers]
I don't see how that's specific to Dart.
Regarding the Dart language, I agree fully. It's another option like the ones you mentioned. They all generate JS, and since we have pretty good guarantees of JS running the same on different browsers, everything is interoperable.
But regarding the Dart VM, there is a concern. Of course the Dart VM on the server etc. is fine, but there is an issue in the browser: If Google ships the Dart VM in Chrome, and the Dart dev tools generate a 'fat build' containing both Dart and JS, and Chrome runs one while the rest of the world runs the other, we are at risk of fragmenting the web.
As Chrome's market share rises, many people are testing first and foremost in Chrome. It is possible that they will not include the JS part and ship only the Dart part, or that they will do far less testing of the JS part, leaving it suffering from bugs and performance faults.
Even if the Dart VM is open source, that is a bad situation that could break the web as we know it.
> The way I see the potential of a DartVM is the same as OdinMonkey+asm.js
The crucial differences is that asm.js is a strict subset of JS. There is 0 risk of someone shipping something that only runs in one browser - it is literally JS, and will run fine everywhere.
(And not just will it run, but it also runs quickly everywhere, because asm.js is not a random new subset but the result of a long-running industry trend, for example in this link asm.js code was fast on 3 different browsers http://j15r.com/blog/2013/07/05/Box2d_Addendum )
prefixed CSS and APIs are far more of a fragmentation threat. WebKit on mobile, for example.
But I disagree it is 1% for the risks mentioned before regarding the Dart VM in Chrome. It's hard to estimate that. If Chrome continues to increase in market share, it will no longer be a "huge chunk" of the market that they lose if they do not support dart2js, and furthermore, it isn't just a matter of working or not, but also how much focus on bugfixing and performance work they put on the JS fallback. It's easy to imagine many developers (especially smaller ones) developing in chrome and testing in chrome, and just verifying basic stuff works in other browsers.
We are not far from that risk today in other areas, for example important sites like Google Docs already say "For an enhanced and optimized experience, use Chrome". The risk gets that much worse when Chrome is actually running completely separate content in the Dart VM from everyone else.
The only defense against this is to preserve competition. My continual criticism in these HN threads is that people's vision is too narrow, too focused on irrelevant battles, focusing energies in the wrong place.
These are two battles going on right now. WebKit derived vs Mozilla, and Web vs native Mobile. The latter is a serious threat and no one is really offering anything to attack the problem. And no, FirefoxOS and asm.js doesn't.
Simply put, consumers find it easier to find and buy content on native platforms, and developers find it easier to use tools on native platforms. The Web has a huge looming consumer and developer problem. A lot of people who sit around in VIM/Sublime all day hacking MVC or jQuery websites don't seem to realize the looming problems.
Web Development needs to be made radically more productive. Web Performance needs to be radically upped. The current tap dancing around ES6 improvements or ION/ODINEngine are nice, but simply too underwhelming.
Web Components are a step in the right direction. But honestly, if I wasn't working for Google right now, I wouldn't be writing a web app these days, I've be writing an iOS or Android app.
Both Google and Mozilla have huge problems to solve IMHO, and this bickering over Dart, NaCL, Asm.js, et al is a big distraction. These organizations need to work together to make the web delightful on mobile and for developers as the whole industry transitions.
People make iOS apps and not web apps because iOS apps perform better on iOS than web apps on iOS. And iOS is where most app money is made. Making the web a better platform in general won't directly help with that, important as a goal it is.
I don't agree there is "bickering" over Dart, NaCl/PNaCl, asm.js. There are issues of principle there. For example, if we make the platform stronger but it loses some of its core attributes (like portability were NaCl to be adopted) then the whole thing is at risk of becoming pointless. At the same time, we do need to make the platform stronger and competitive in terms of speed with native as much as possible, which is a fine line.
There's plenty of examples that show Google has a pattern of abandoning open-standards in favor of proprietary solutions. XMPP, WebKit, RSS: embrace, extend, kill. Now JavaScript is in the gunsights.
Stay away from Dart.
RSS, by kill I assume you are hinting at how all the feeds were available through Google Takeout and Google Reader APIs that other SaaS applications used to very quickly get up to speed. And how it was recently reported (on Verge?) that these providers are doing great. Heck, I remember reading a Google blog post that even listed these alternatives. So as it was said elsewhere in this thread, stop spreading false information.
Are you talking about JavaScript? ;)
It's true that Dart and JS are the same in this regard, but it's not 1995. If Dart was introduced in 1995, it'd certainly deserve to beat LiveScript and we'd probably be using it now.
Furthermore, this person didn't care about tooling and he also didn't have any clue about optimizing virtual machines.
Anyhow, any language or piece of technology needs to reach a certain state of maturity before it can be standardized. Once you standardized something, things are pretty much set in stone.
when a project is open source with a permissive license as dart is, how can it become a walled garden?
walled garden to me is a closed platform, where nobody can change or see whats happening inside.. how that reality maps to dart?
and people believe things like javascript are open standard, just because it have a commite? isnt that why javascript is stuck in the nineties and cant move forward?!
Dart is a cool, modern and fast language designed from the ground up to give us a choice against the ugly javascript..
nobody really likes javascript, people just have to deal with it, because is there no option (until coffescript, dart, typescript and others came by)
why is so bad to have options? and what could be the evil plan of google behind the creation of dart?
there a lot of things i disagree the way google has being doing things.. but this technological fanatism will hurt us all..
Personally i dont care it came from google, or any other company.. actually from what i understand from the hystory of dart, it came from a V8 developer and its passion to make a better language that could be better for bigger projects and compile faster.. isnt cool that google believe in this project and put so many badass vm people behind it to make it work?!
i just dont understand what could be bad in this sort of move.. its innovation, and its open.. its miles away from a walled garden.. and any browser or any application can adopt it and make it even more open and widespread adopted