We have a ton of JavaScript/CoffeeScript code and I really wish we could use something like Dart. JavaScript is great for smaller projects, but once you get a ton of code it really becomes a unmanageable mess.
I think tho' it would be amazing if Dart could run on the server side as well. This way you could just have one language on both the client and the server.
If you are looking for a structured language (for front end dev), Typescript is a better alternative imho. Javascript devs can still read it and it's compatible with any JS library out there.
Dart not so much since the semantics are different.You can still interact with JS libs but it's not as straight foward as TS.
I tested a number of options (GWT,Haxe,CS,Dart,Opal,Jsx,...),while i'm not a Microsoft fan(by a long shot),Typescript is the solution that allows the best integration with legacy code and pure JS libraries,while making easy to port old java/C#/as3 code to JS.
Dart does run on the server. The VM runs standalone for scripts and long-running apps, and the dart:io library provides very node.js like file, network and HTTP APIs, with the addition of Isolates for actor-like concurrency.
In fairness to JavaScript, it is absolutely possible to write very large apps and keep them organized and maintainable.
I think the issue is that JS doesn't have strong conventions for how to do that, so you actually need to make good choices that work well with your app.
I have no doubt that Dart makes that stuff easier, but there's nothing inherent to JavaScript that makes it unsuitable for larger applications. It just forces you to make decisions.
People have found success in managing large Javascript codebases through good design choices like module systems (AMD/CommonJS), using the SRP to keep modules tight, and testing. It's tough (nigh impossible?) to retrofit those design choices onto an existing codebase.
Dart and TypeScript seem to offer a more familiar path to people who are used to Java/.NET/etc and who have been burned by messy JS codebases.
Going forward, the Dart team will focus on improving Dartium, increasing Dart performance, and ensuring the platform remains rock solid. In particular, changes to core technologies will be backward-compatible for the foreseeable future.
Today’s release marks the first time Dart is officially production-ready, and we’re seeing teams like Blossom, Montage, Soundtrap, Mandrill, Google's internal CRM app and Google Elections, already successfully using Dart in production. In addition, companies like Adobe, drone.io, and JetBrains have started to add Dart support to their products.
Congrats to the team on releasing 1. Now to find a project to try it out in...
This is speculation: but JetBrains work on dart IDE, android releasing ART, I'm tempted to say we're 2 years out from seeing DART running on android. It makes sense from a business sense, have the option of running dart apps on android would free the platform from its java dependance.
I hope that you are correct! That would be great. I have experimented with Dart on both client and server and it is a nice language. Fun to develop with.
I think Dart has the potential to become a target for other languages [1]. The already-high-level code has a performant VM and it takes advantage of optional typing (unlike any other VMs I am aware of). In order to do so though, they should at least make a spawnString (like isolate's spawnUri) or even better, have the ability to JIT dart code by string but not execute it right away.
> In order to do so though, they should at least make a spawnString (like isolate's spawnUri) or even better, have the ability to JIT dart code by string but not execute it right away.
Of all of the core libraries in Dart (core, html, io, async, etc.) the isolate library has had the least attention so far. Now that those other libraries are stable, I'm hoping the corelib folks will have the time to give isolates some much needed love.
I definitely want spawnString() too and we've had to do some gross workarounds in pub to deal with its absence (dumping stuff to temp files).
So if i get it right, the way "Google" sees the future, there is Go at the server side and Dart at client side (which is in fact JS). Am I wrong?
I would expect Google, or at least, a team at Google, to take over NodeJS which is based on their V8 and expand it to universal server client language and libs. JS can be complied into go binaries after all, so why not letting people write apps using the same language.
Let alone I see no effort on their side bringing any of those language into the native world of Android, instead we got this cluttering Java thing as almost the only options for most projects.
> So if i get it right, the way "Google" sees the future, there is Go at the server side and Dart at client side (which is in fact JS). Am I wrong?
Yes, you are, in fact, wrong. Google doesn't have so narrow a vision. Dart is server and client side (the native VM is, aside from a for-testing-only build, server-side only now.) But the client side isn't just Dart (or JS, in which Google has also invested heavily), its also C/C++, and other languages, hence PNaCl, which also just went into general release.
And, sure, Go is a server-side language that Google is putting energy into, but so is Dart. And I doubt their vision ends there, those are just a couple of the more visible active fronts.
> I would expect Google, or at least, a team at Google, to take over NodeJS which is based on their V8 and expand it to universal server client language and libs.
The existing NodeJS team is doing enough for server-side JS-on-V8, and its open source -- Google could throw more resources, but its probably not the best bang-for-their buck in terms of developing new technologies that might improve the options for the things Google is concerned about. Doing what other people aren't doing is a bigger win.
> Let alone I see no effort on their side bringing any of those language into the native world of Android
I've seen quite a bit about Dart on Android (though I think there are issues with building the current distribution.) Less on Go.
The point of view within Google that spawned Dart is that JavaScript as a language has major and unfixable flaws that severely raise the cost of developing large apps. It's nice that node.js uses V8, but being based on a Google project does nothing to address the language issues.
Note that that point of view is not universally shared at Google, and many people are fine with JavaScript, and probably would use node.js.
> I see no effort on their side bringing any of those language into the native world of Android
The Dart VM supports ARM, and I've seen prototypes that get it running on Android. The team hasn't had much time to put into it yet, but I wouldn't infer that that says much about what we'll do in the future. (Not that I'm making any promises, either.)
And don't forget AngularDart or whatever for the front-end framework. I wish the name "Google" wasn't attached to any of these projects as I'm a huge fan of them but not the company they're born out of.
I am a newbie in field of Web Development, and recently I felt in love with JavaScript, especially because of the sheer capability to write Client side and Server side code in same language. Thanks to Meteor.js, it made my bond with JavaScript even more stronger.
But now with the buzz of Google Dart going around, I am afraid that, am I betting on the wrong horse? Is it the right to jump on Google Dart bandwagon? To be honest, it do looks promising.
Please guide me, what should I do, since I am a newbie, I want to take advantage of the fact that, since I don't know anything, I better learn something that have much promising future, and have an edge over technology.
Honestly, JavaScript has orders of magnitude more usage and a lot more momentum than Dart does. I don't think you'll be harming your career prospects in becoming proficient in JS.
I also think there are better choices than Dart if you want to learn something that will expand your mind. Dart strikes me as a very practical language.
ALL the committers are from Google and it is not an open standard which basically eliminates any chance that Mozilla/Apple will ever consider adopting it. And frankly with Apple dominating the mobile web without them any solution will never eventuate to anything.
I have spent time with both Dart and with JavaScript + Meteor. Both are good stacks. If you are already up to speed on Meteor, why not just use that for a year, build applications, and maybe look at alternatives later.
It is probably best to start writing web apps, and not on learning many tools.
JS prototypes provide a single parent lookup delegation, which is not that different from single inheritance and is mostly used to emulate single inheritance class systems in the wild.
Furthermore Dart supports mixins, so it's not exactly single inheritance classes.
My thoughts exactly. Dart is representative of 90's language design and as such is a step backward. That's not to say JS doesn't have its issues, but Dart isn't the solution.
Could you explain the brilliance of prototypes? Prototypes in JavaScript are pretty awful, but I've never been sure if that's just the JavaScript implementation (for instance, the lack of a good way to clone an object makes using prototypes in JS more painful than it needs to be), or the concept of prototypes more generally.
Psyched! See our HN post about our Dart app (Dart rocks) and our team's disappointment with not being included in the 1.0 announcement. https://news.ycombinator.com/item?id=6735044
Some people wanted to build optional-typing language for real world for decades, and finally made it. That is a great achievement.
From product point of view, Google would be much better to port Android Dalvik to Chrome. You can run GWT Java code in browser years ago. Running the same code using JVM would be much faster with much less code change. 5-10 man-year would be enough to do the porting, and it will share work between Android and Chrome for years to come. Of course, it would be much boring research work though.
From performance point of view, asm.js gets much better performance with way less work. No matter how good Dart performs, it would never make sense to port high performance C/C++ game code to Dart, so you end up having to use both Dart + pNaCl, which is an awful solution. Technically, TypeScript is more interesting if Microsoft can keep it simple and fast, but I doubt Microsoft would make anything simple.
Without any additional special assumptions about the someone and their particular circumstances, learning JS is probably a lower risk investment, learning Dart is probably higher risk and higher potential payoff; thinking only in terms of future income potential.
I really like Dart and hope it - or something like it - replaces javascript soon, but I'd heavily recommend learning javascript instead. I'll be quite some time, if ever till Dart is even 1/4 of the client side market.
Even if you did learn Dart, you'd inevitably have to include external javascript libraries, so you'll have to know javascript anyway.
And Google is still actively promoting javascript in things like AppScript and Angular js.
Even if you use language X that compiles to javascript ,you still need to learn javascript, Or it's a bit like learning rails without understanding ruby.
Dart seems interesting, but its sponsorship by Google creates a major problem - what incentive does Microsoft, Mozilla, or Apple have to implement Dart support in their browsers? What about JavaScript devs who choose not to support Dart (especially since many still have to support even as far back as IE8 due to enterprise/companies/organizations/schools that opt for long-term support solutions for software)? I don't think good answers are available to these questions, which makes me hesitant to jump in as quickly.
They need make some changes in Chrome for doing this right. They aim to make DOM nodes garbage collectible with project oilpan [1] AFAIK. Both Dart and V8 VM will benefit from this. So this will take some time. But Dart is already very useful with Dartium for development and Dart2Js for deployment.
> Why doesn't Google include the native Dart VM in Chrome?
Probably because Dartium (Chome w/Dart) doesn't yet have the kind of performance advantage that makes it compelling enough to split the web that way -- making developers use dart2js for client code means that you don't need separate client code for Chrome (Dart) and everyone else (JS) -- and needing to commit to extended support of two different scripting runtimes in Chrome for the future.
[+] [-] amix|12 years ago|reply
We have a ton of JavaScript/CoffeeScript code and I really wish we could use something like Dart. JavaScript is great for smaller projects, but once you get a ton of code it really becomes a unmanageable mess.
I think tho' it would be amazing if Dart could run on the server side as well. This way you could just have one language on both the client and the server.
[+] [-] camus2|12 years ago|reply
Dart not so much since the semantics are different.You can still interact with JS libs but it's not as straight foward as TS.
I tested a number of options (GWT,Haxe,CS,Dart,Opal,Jsx,...),while i'm not a Microsoft fan(by a long shot),Typescript is the solution that allows the best integration with legacy code and pure JS libraries,while making easy to port old java/C#/as3 code to JS.
[+] [-] spankalee|12 years ago|reply
[+] [-] kevincennis|12 years ago|reply
I think the issue is that JS doesn't have strong conventions for how to do that, so you actually need to make good choices that work well with your app.
I have no doubt that Dart makes that stuff easier, but there's nothing inherent to JavaScript that makes it unsuitable for larger applications. It just forces you to make decisions.
[+] [-] lowboy|12 years ago|reply
Dart and TypeScript seem to offer a more familiar path to people who are used to Java/.NET/etc and who have been burned by messy JS codebases.
[+] [-] mikehotel|12 years ago|reply
Today’s release marks the first time Dart is officially production-ready, and we’re seeing teams like Blossom, Montage, Soundtrap, Mandrill, Google's internal CRM app and Google Elections, already successfully using Dart in production. In addition, companies like Adobe, drone.io, and JetBrains have started to add Dart support to their products.
Congrats to the team on releasing 1. Now to find a project to try it out in...
[+] [-] ntkachov|12 years ago|reply
[+] [-] ahoge|12 years ago|reply
[+] [-] mark_l_watson|12 years ago|reply
[+] [-] clhodapp|12 years ago|reply
[+] [-] kodablah|12 years ago|reply
1 - https://www.dartlang.org/articles/why-not-bytecode/
[+] [-] georgemcbay|12 years ago|reply
Once upon a time this was going to be the basis of ECMAScript4 via tamarin, but that never panned out for lots of reasons, most of them political.
[+] [-] munificent|12 years ago|reply
Of all of the core libraries in Dart (core, html, io, async, etc.) the isolate library has had the least attention so far. Now that those other libraries are stable, I'm hoping the corelib folks will have the time to give isolates some much needed love.
I definitely want spawnString() too and we've had to do some gross workarounds in pub to deal with its absence (dumping stuff to temp files).
[+] [-] pacala|12 years ago|reply
[+] [-] tzury|12 years ago|reply
I would expect Google, or at least, a team at Google, to take over NodeJS which is based on their V8 and expand it to universal server client language and libs. JS can be complied into go binaries after all, so why not letting people write apps using the same language.
Let alone I see no effort on their side bringing any of those language into the native world of Android, instead we got this cluttering Java thing as almost the only options for most projects.
[+] [-] dragonwriter|12 years ago|reply
Yes, you are, in fact, wrong. Google doesn't have so narrow a vision. Dart is server and client side (the native VM is, aside from a for-testing-only build, server-side only now.) But the client side isn't just Dart (or JS, in which Google has also invested heavily), its also C/C++, and other languages, hence PNaCl, which also just went into general release.
And, sure, Go is a server-side language that Google is putting energy into, but so is Dart. And I doubt their vision ends there, those are just a couple of the more visible active fronts.
> I would expect Google, or at least, a team at Google, to take over NodeJS which is based on their V8 and expand it to universal server client language and libs.
The existing NodeJS team is doing enough for server-side JS-on-V8, and its open source -- Google could throw more resources, but its probably not the best bang-for-their buck in terms of developing new technologies that might improve the options for the things Google is concerned about. Doing what other people aren't doing is a bigger win.
> Let alone I see no effort on their side bringing any of those language into the native world of Android
I've seen quite a bit about Dart on Android (though I think there are issues with building the current distribution.) Less on Go.
[+] [-] spankalee|12 years ago|reply
Note that that point of view is not universally shared at Google, and many people are fine with JavaScript, and probably would use node.js.
[+] [-] staunch|12 years ago|reply
[+] [-] munificent|12 years ago|reply
The Dart VM supports ARM, and I've seen prototypes that get it running on Android. The team hasn't had much time to put into it yet, but I wouldn't infer that that says much about what we'll do in the future. (Not that I'm making any promises, either.)
[+] [-] tomp|12 years ago|reply
[+] [-] turbo_pax|12 years ago|reply
[+] [-] RivieraKid|12 years ago|reply
Go is a better C++.
[+] [-] jalan|12 years ago|reply
But now with the buzz of Google Dart going around, I am afraid that, am I betting on the wrong horse? Is it the right to jump on Google Dart bandwagon? To be honest, it do looks promising.
Please guide me, what should I do, since I am a newbie, I want to take advantage of the fact that, since I don't know anything, I better learn something that have much promising future, and have an edge over technology.
[+] [-] dangoor|12 years ago|reply
I also think there are better choices than Dart if you want to learn something that will expand your mind. Dart strikes me as a very practical language.
[+] [-] threeseed|12 years ago|reply
ALL the committers are from Google and it is not an open standard which basically eliminates any chance that Mozilla/Apple will ever consider adopting it. And frankly with Apple dominating the mobile web without them any solution will never eventuate to anything.
[+] [-] mark_l_watson|12 years ago|reply
It is probably best to start writing web apps, and not on learning many tools.
[+] [-] nfoz|12 years ago|reply
[+] [-] mraleph|12 years ago|reply
Furthermore Dart supports mixins, so it's not exactly single inheritance classes.
[+] [-] taylodl|12 years ago|reply
[+] [-] voyou|12 years ago|reply
[+] [-] ionforce|12 years ago|reply
[+] [-] woven|12 years ago|reply
[+] [-] moca|12 years ago|reply
From product point of view, Google would be much better to port Android Dalvik to Chrome. You can run GWT Java code in browser years ago. Running the same code using JVM would be much faster with much less code change. 5-10 man-year would be enough to do the porting, and it will share work between Android and Chrome for years to come. Of course, it would be much boring research work though.
From performance point of view, asm.js gets much better performance with way less work. No matter how good Dart performs, it would never make sense to port high performance C/C++ game code to Dart, so you end up having to use both Dart + pNaCl, which is an awful solution. Technically, TypeScript is more interesting if Microsoft can keep it simple and fast, but I doubt Microsoft would make anything simple.
[+] [-] davidedicillo|12 years ago|reply
[+] [-] dragonwriter|12 years ago|reply
[+] [-] libria|12 years ago|reply
Even if you did learn Dart, you'd inevitably have to include external javascript libraries, so you'll have to know javascript anyway.
And Google is still actively promoting javascript in things like AppScript and Angular js.
[+] [-] camus2|12 years ago|reply
[+] [-] rdtsc|12 years ago|reply
* Blossom
* Montage
* Soundtrap
* Mandrill
* Google's internal CRM app
* Google Elections
Companies that started to add support for it: Adobe, drone.io, and JetBrains
[+] [-] Bahamut|12 years ago|reply
[+] [-] sigzero|12 years ago|reply
[+] [-] klodolph|12 years ago|reply
[+] [-] notok22|12 years ago|reply
[+] [-] rayiner|12 years ago|reply
[+] [-] tzaman|12 years ago|reply
[+] [-] afsina|12 years ago|reply
[1] https://groups.google.com/a/chromium.org/forum/#!topic/blink...
[+] [-] dragonwriter|12 years ago|reply
Probably because Dartium (Chome w/Dart) doesn't yet have the kind of performance advantage that makes it compelling enough to split the web that way -- making developers use dart2js for client code means that you don't need separate client code for Chrome (Dart) and everyone else (JS) -- and needing to commit to extended support of two different scripting runtimes in Chrome for the future.
[+] [-] protomyth|12 years ago|reply
[+] [-] floitsch|12 years ago|reply
[+] [-] andyl|12 years ago|reply
Silverlight and ActiveX have already shown the usefulness of proprietary enhancements.
No thanks.
[+] [-] AstralRabbit|12 years ago|reply
[deleted]