Dart 1.0 Is Out
news.dartlang.org
news.dartlang.org
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.
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 actually has horrible semantics in places. Only if x === true will if(x) run.
The type-checker will give a very clear warning if it catches you putting a non-bool in a conditional context. And make no mistake: the type checker is an important part of the Dart development process.
(One downside of this is that it does push you to working in the -- Eclipse-derived -- DartEditor, which isn't always a wonderful experience. However, the type checker is exposed and available, and there's nothing to prevent it being tightly integrated into other editors or IDEs.)
[1] And as a practical matter generates faster code, because it can be implemented with a comparison against a single constant.
If you'd like the same language for client and server side, try Kotlin or HaXe.
For now, Dart doesn't have a crossbrowser VM yet (except for Dartium), so it doesn't give you any performance boost over JavaScript. Maybe one day there will be a cross-browser Dart VM as a PNaCl or asm.js module?
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.
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.
I see it a bit like when Dijkstra wrote "Go To Statement Considered Harmful". I have no doubt a lot of developers at the time objected to it and said "that is wrong, it is possible to write good code using GOTO". Because they probably wrote code using GOTOs and some of that code was probably decent quality.
The problem is that `goto` is easy to abuse, and, worse, easy to abuse inadvertently, e.g. you might produce a `goto` into a loop or something like that during refactoring.
JavaScript is like one big `goto` in this regard.
"Goto" as another local flow control construct is relatively innocuous.
10 PRINT "hello, world"
20 GOTO 10Here is what Dijkstra said:
> "The go to statement as it stands is just too primitive; it is too much an invitation to make a mess of one's program. "
How does Knuth win that?
In any case, I think there is a popular understanding of that phrase. It entered folklore to mean something else and regardless if that something else is different, it does make sense.
Excessive GOTOs complicate code and create a spaghetti mess. Today we don't need scientific papers on it. That is how I understand it.
The general idea is that there are better construct and better paradigms out there. Not all programming construct are strictly equal in practice. Yes all languages that are Turing complete can do the same kind of things. We know the theory. But it turns out some paradigms are better than others. OO programming, despite it being hated and derided today, was a better idea that writing lots of GOTOs. Functional programming with immutable data-structures does make sense in a distributed and concurrent environment. STMs compose better than locks and mutexes and so on.
So if Javascript is "GOTO" then dart is: "function NotGoTo() { GOTO; }"
It does but I think Go might be more fitting for that purpose.
[1] http://www.techempower.com/benchmarks/#section=data-r7&hw=i7...
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...
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.
ES4 failed mainly because some people thought ES3 was good enough.
Adobe,harshly critized for Flash was the one pushing for a better javascript.
I will never understand why Microsoft basically killed ES4. They had their own implementation on .net ( JScript.net ) so it's not like it was going to be a huge effort. The only reason would be Microsoft pushing Silverlight at that time which was a huge flop. We basically lost a decade because of it, as i predict javascript will eventually look like ES4,that's inevitable.
People without an investment in Javascript have lost over a decade because of Javascript's monopoly on clients being maintained. If we had not been forcibly locked into Javascript all this time, then competition would have produced a better alternative or whipped the process designing Javascript into shape. Now we are stuck with this ridiculously tall, messy stack which uses an application scripting language as a compile target, still lacks basic features like a standard package system, and pushes trivial language features like iteration into third-party libraries like jQuery. So now we are constantly pushing megs of JS, using insanely complicated build systems to get anything done, and for all this trouble our code runs at a speed roughly equivalent to C in 1998.
(Now that Flash and Silverlight are dead I think it is safe for me to complain about Javascript without being an enemy of the open internet or whatever.)
I don't really care about Dart, but it's way past due that there was something serious to challenge Javascript. All the triumphalism about how Javascript is already a perfect language to use for eternity is explicitly counterproductive. Making the whole internet depend on the fortunes of one language just sucks.
Those who care, just keep happily using plain native applications.
Simplicity of the language.
I'll easily agree that ES4 would have been very interesting, but ES5 (and its spiritual successor features in ES6) gave us subtle low-level power that would have lacked otherwise.
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).
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.
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.
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.)
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.
Go is a better C++.
Rust is a better C++. Go is.. weird. I would even say it is a better Java.
Only when it gets generics, real enumerations, dynamic loading support, proper dependency management for large scale projects.
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.
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.
It is probably best to start writing web apps, and not on learning many tools.
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.
It will get standardized in the not too distant future. [1]
> Apple dominating the mobile web
Huh? Android's market share is over 80%. iOS got about 13%. [2]
[1] http://www.ecma-international.org/news/Dart%20workshop.htm
[2] http://thenextweb.com/insider/2013/11/12/idc-android-hit-81-...
Standardized by Google, perhaps, but by nobody else. It will not be a multi-vendor standard.
Let's see... Netscape Navigator 2.0 was shipped with it in September 1995 and ECMA-262 1st Edition was written in June 1997 and finally approved in April 1998.
However, the 1st edition was done entirely by Netscape (by the looks of it). So, this doesn't count as a multi-vendor standard since there wasn't any involvement by any other vendor.
Looks like you're being a bit unreasonable. Dart isn't even shipped yet in one browser and you're already complaining that it isn't a multi-vendor standard yet. Going by JavaScript's timeline, it still has more than 3 years for getting to that point.
And don't forget that Apple customers are acknowledged as the more valuable (higher net worth, disposable income, tastemakers etc)
Furthermore Dart supports mixins, so it's not exactly single inheritance classes.
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.
It really compiles, so you don't have to worry about it. The languages are so similar that stuff that is fast in Dartium will work pretty fine in JS.
Sure for special cases knowing those things can help get the very best out of your code, but for the other 99% of the time, it is not necessary.
(Edit: Not that I recommend Dart over JS necessarily, but I don't agree with your argument.)
But you DO need to learn Javascript to use Dart on web apps, so the comparison is irrelevant.
For things like CoffeeScript, which are fairly thin layers over another language, I'd always advise to just learn JS first. Dart and Clojurescript though are so far removed from their compilation target that you don't really need to know the JS, as long as there's good library support for what you want to do. In the case of clojurescript the interop is so seamless that it puts the focus on learning the APIs, which is where the true complexity lies. Of course, and even more so with typing, you also have the compiler to back you up.
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.
* Blossom
* Montage
* Soundtrap
* Mandrill
* Google's internal CRM app
* Google Elections
Companies that started to add support for it: Adobe, drone.io, and JetBrains
No, that's not the case. You need to understand the browser DOM, and the various APIs available to you, but these are presented by Dart libraries. If you have knowledge of Java or C#, then that knowledge will be useful, and if you have knowledge of JavaScript's functional elements, then that is also useful, but none of that is mandatory to be effective with Dart.
Their JS engines are woeful. Even if you can get something app-like (the kind of thing you would use dart for) to work, your app won't scale w.r.t. perf so you're painting yourself into a corner.
If you'd like the future to be as good as possible, you might want to build new tools without the same old constraints.
The fact is that MANY people need to support IE6-8.
I personally built a single page application about 2 years ago that worked in IE8, thanks to jQuery and the ecosystem of the time. jQuery, jQuery UI, various plugins incl. jsTree & DataTables.
It flew in Chrome, Firefox and Opera, even then. In IE8 it was slow as hell. Event listeners were slow, ajax and parsing JSON was slow. Everything was crazy slow. The app felt lumpy and awful. And when I hit bugs, the developer tools just were not there.
I would never do this again.
I'd wager that for IE < 8, for any non-trivial app, round-tripping to the server will give you a better UX than using JavaScript.
Deliver something usable for oldIE. There are many people that share this view. I suggest watching this talk on how the BBC deals with legacy browsers (9m 20s): http://www.youtube.com/watch?v=YfvMQ316hMU&t=00h09m20s
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.
[1] https://groups.google.com/a/chromium.org/forum/#!topic/blink...
They are working on an experimental solution to let garbage collection happen for DOM nodes that are created from Dart or V8. This basically requires a rewrite of the memory management of DOM nodes. This is still very much a work in progress and not ready for prime time.
The solution the team uses for Dartium is not the same as what they want to do for the shipping version of Chrome, so it'll be a bit before that's ready.
Silverlight and ActiveX have already shown the usefulness of proprietary enhancements.
No thanks.
Google being the ONLY committers don't exactly have a motivation to.
So, yeah, Google has a motivation to keep it up to date.
We've seen that game before, played by microsoft.
Other browser vendors know this: Dart is never gonna fly outside of Google's walled garden.
And, then, sure, Dart2JS stops being important to Google because its unimportant to how Dart code performs on the web. But its unimportant to Google because its unimportant to anyone, since it won't matter to users, either.
Dartium and dart2js already aren't quite in sync; numeric types work differently for example. But they're close enough that for most apps, you can develop in Dartium and deploy on dart2js and the language differences don't really bother you. The language differences between Dart-in-JavaScript and Dart-in-Dartium are a lot less than the differences between browsers that web developers deal with all the time.
Can't wait. I am already using Chrome, if it works best I'll like it even more.
> Silverlight and ActiveX have already shown the usefulness of proprietary enhancements.
So how do I compile Silverlight to .js again?
> No thanks.
Yes please!
Oh, and by the way, ActiveX would be awesome if it didn't have all the security flaws and was more portable. Too bad it didn't work.
1. Standards. The Dart VM is not part of any web standard, nor part of a spec that has interest from multiple vendors, so it should not be shipped in a standards-compliant browser. This is a matter of principle that most browsers agree on these days, see for example Google's Blink guidelines: http://www.chromium.org/blink#new-features
2. Effort. Adding a new VM into a browser is a huge amount of effort. The VM can't just be added even if it is open source (which it is) - it's very hard to integrate such a thing properly into a browser, technically speaking. Also aside from technical effort, there is also effort to start a new standards process for a new language.
However, I think it would be fun to explore that direction! I'd be happy to collaborate with Dart VM people on that.
My concerns are about things like PICs, but code generation is possible, so replacing functions to change PICs is one way to implement them. This is, I think, how the Graal project does JavaScript and Ruby, and they get very good performance.
But it is an incorrect point in that the field has changed a lot, for the better - most or all browser vendors want to play nicely these days. Even Microsoft is supporting the standards process and implementing WebGL, for example. The principles guiding browser vendors are more like these which Google wrote for Blink:
http://www.chromium.org/blink#new-features
> In practice, we strive to ensure that the features we ship by default have open standards.
That was not the case 18 years ago, but thankfully it is today. 18 years ago it might have been common practice to just ship a new VM in a browser, but to do so today with no regards for the standards process would be unexpected and improper.
Which is... exactly the same situation JavaScript was in when Netscape introduced it.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_...
Firefox 3.0+ added support for expression closures and generator expressions:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/New_...
Firefox 22+ supports fat arrow functions. Just open the console and try it yourself:
>>> let z = x => x * x;
undefined
>>> z(5);
25
>>> let y = (a, b) => a * b;
undefined
>>> y(2, 3)
6
http://wiki.ecmascript.org/doku.php?id=harmony:let
Arrow functions are being standardized as well,
http://wiki.ecmascript.org/doku.php?id=harmony:arrow_functio...
and for generators, the standards discussion led to a change in the spec, with the new version replacing the old implementation in SpiderMonkey (v8 recently implemented the new one as well).
In general see
http://kangax.github.io/es5-compat-table/es6/
where it lists compatibility for various new JS features. As it says there, let is supported not just in Firefox but also IE11 and Chrome 30.
It is true that Firefox shipped some of these several years back. I am not sure of the best way to find out exactly what the standards-track status was at those times.
But in general: Talking about the far past is counterproductive. We can probably find stuff that wasn't done properly by any browser if we look back far enough. But in recent years, there is growing consensus on the importance of not shipping non-standard things. That is the important thing I think.
> But in recent years, there is growing consensus on the importance of not shipping non-standard things.
Others might read that as no new and meaningful technologies will be seen implemented in the browsers soon. I can't think of too many thing designed and build by an intercompany commetee.
(And as mentioned above, I'm not sure about those examples - while it's very possible some were released before being standardized, I didn't see a link showing that, and they are all being standardized now. Need more info.)
Fair point about the limits of things designed by committees. But it isn't always true, just mostly true ;) For example, WebGL was designed through a standards process, and it is great.
Earlier you mentioned "far past", but this stuff is fairly recent:
Firefox 2 - October 24, 2006
Firefox 3 - June 17, 2008
Firefox 22 - June 25, 2013
> while it's very possible some were released before being standardized
Nothing of this is in ES5.1.
> they are all being standardized now
Yes, just like Dart.
> For example, WebGL was designed through a standards process, and it is great.
No, that's not how it happened. [1]
Experiment by Mozilla - 2006
Implementations by Mozilla and Opera - 2007
WebGL Working Group - 2009
1.0 spec - 2011
And all of this is based on Canvas which is something Apple made up.
Anyhow, you seem to think that this kind of thing is a problem. It's not. This is how the web works. This is how progress is made.
Regarding Firefox 22, that is recent, but I don't see a link showing it shipped something nonstandard and that was not being standardized? In fact I showed a link for the standardization process for arrows? Revision history for that page seems to show that it predates Firefox 22.
> Nothing of this is in ES5.1.
They are in ES6, which is being standardized, has interest from multiple vendors, is heavily discussed by multiple vendors, and has implementations by multiple vendors.
I never said everyone should wait until a standard is 100% final. Just like the Blink principles say, it can be perfectly valid to ship something that is being standardized, so long as there is interest from multiple vendors and work on standardization.
The risk is of one vendor shipping something entirely unilaterally, with no respect for any standards process. That's not what happened with arrows.
> > they are all being standardized now
> Yes, just like Dart.
AFAIK no other vendor has expressed any interest in Dart. The opposite in fact, Apple opposed including bindings to WebKit that would allow additional languages to JS. Please correct me if I am wrong?
> Anyhow, you seem to think that this kind of thing is a problem. It's not. This is how the web works. This is how progress is made.
I disagree. Why then do you think Google wrote the Blink principles about avoiding shipping something before it is standardized or has multiple vendor interest? Why did Google stop shipping vendor-specific WebGL extensions? In both cases Google is showing what most vendors consider proper behavior today, and I think Google is doing the right thing. Do you think Google is wrong in both cases?
I can see how many would see that as tail wagging the dog. But I see your point. And I agree it should be part of a standard. However I would imagine (and correct me if I am wrong) it is a lot easier to approve and go through the standard approval if there is already an implementation out there to look at. Standardizing on a hypothetical future feature via a large committee, doesn't work too well.
> 2. Effort.
Here, again, this is not a hypothetical, we haven't proven if it is possible we are just dreaming about adding a VM. Dartium works today. Presumably other would have a bit less work to do but it depends on how DOM interaction differs between them.
EDIT: 2nd part initially completely didn't make sense
I think you are correct. But that implementation does not need to be shipping on by default in a major browser like Chrome.
If Google would promote Dart mainly through dart2js, but not ship the Dart VM in Chrome, then I have no problem with that, and even the opposite - that would be quite cool, new languages are always nice to have. Then, if Dart catches on with developers in the industry, I think it would be very appropriate to discuss standardizing it. The momentum among developers, plus an existing VM that runs it even better, could be a compelling combination, and browser vendors could discuss that in a fair and open way.
But to ship the VM in Chrome far before any of that is a violation of the basic principles of the standards process. It sends the message that Google intends to use Chrome's huge and growing market share to force the market to do what it wants, instead of following the standards process. Perhaps that is not what Google intends, but that is how it can appear.
For that reason, I think that shipping the VM in Chrome is counterproductive if Google wants to standardize it, since it antagonizes all the rest of the industry.
> But it is also not vaporware.
Sorry if I wasn't clear, I never said anything to the contrary? Not sure what you are responding to here - the quote you refer to is about "Effort", where I talked about the effort for other browser vendors to adopt the Dart VM, not for Google. Clearly Google has a working VM today.
Sorry for the confusion, I read that somehow as effect on Google's part to integrate the browser in Chrome in order to have an example of it running to speed up the approval process. I see how it was a total brain fart on my part. Disregard that one. I updated it with actually what I think I was saying.
Browser vendors are free to integrate the VM into their products, and if they don't want to there is dart2js which is acceptable.
This isn't even close to the situation presented by Silverlight, ActiveX and I feel like you're being duplicitous by comparing them.
That's a tremendous amount of effort and it is likely to reduce the performance of JavaScript. Cross-language GC, in particular, is really hard. See Filip Pizlo's message to webkit-dev on this subject (citing two recent papers), which is part of the reason that Dart support was shot down when Google proposed adding it to WebKit: https://lists.webkit.org/pipermail/webkit-dev/2011-December/...
The Dart VM is nice but its primary purpose right now is running the Dart compiler and in Dartium which is only used by developers. (You can use it for other things but the ecosystem isn't there yet.)
This is a really good reason why dart2js exists and why so much effort has been expended in making it good.
However, I think that if Dart proves to be a compelling platform for developers I don't think it's out of the question for browser vendors to put some serious thought into integrating the Dart VM natively alongside JS.
After all, Google is going to be doing exactly that with Chrome/Chromium...
No they aren't. Integrating a Google-controlled VM into any software project (for example, Firefox) isn't trivial (you need lots of resources for it) nor is desirable (the technology is driven and controlled by Google).