Mozilla's Brendan Eich, inventor of JavaScript, on the Dart memo leaked a few weeks ago:
A Dart to JS compiler will never be "decent" compared to having the Dart VM in the browser. Yet I guarantee you that Apple and Microsoft (and Opera and Mozilla, but the first two are enough) will never embed the Dart VM. So "Works best in Chrome" and even "Works only in Chrome" are new norms promulgated intentionally by Google. We see more of this fragmentation every day. As a user of Chrome and Firefox (and Safari), I find it painful to experience, never mind the political bad taste
The Dart to JS compiler doesn't have to be "decent" compared to having the Dart VM in the browser to be useful in a world where other browsers don't use the Dart VM, it merely has to be "decent" compared to handcrafted JavaScript performing the same task in another browser.
If direct Dart code runs faster than JavaScript on Chrome, that's a nice bonus, but if it runs as well as similar code that was originally written in JavaScript on the other browsers (when the Dart code is compiled to JS) that's good enough. Dart on the other browsers isn't competing with Dart on Chrome, it is competing with JavaScript on the other browsers and that's how it should be measured.
And if it turns out apps in Dart on Chrome really blow away apps in JavaScript on other browsers to the point where both devs and users start embracing Chrome even more for these gains then hopefully that will light a fire under everyone else to either adopt Dart or do something to fix what would then be an undeniable problem of JavaScript.
That statement came with no benchmarks or numbers, no knowledge of the Dart VM and it's relative performance to V8, and no knowledge of the Dart to JS compiler and what kinds of optimizations it does.
If you run Google's closure compiler on JS, for example, in some cases, it produces a very significant speedup than hand-tuned hand-written JS, so saying "never be decent" is a pretty strong claim to make.
What Brendan is missing is that the contest is not closed between JavaScript and Dart. The elephant in the room is the huge and growing mobile space where ObjectiveC and Java rule. It's not about "Works only in Chrome", it's about "Works only on iOS/Android".
I don't speak for the team but I believe I can add some perspective.
Think of it this way: what is GWT? GWT os compiling Java, a statically typed language, into Javascript. If you've used GWT you'll know that particularly early on there was a lot of friction. What's simple in Javascript with anonymous objects and duck typing doesn't quite gel with Java so you've had to do things like use JSNI for edge cases.
Google has some incredibly large and ocmplex JS apps (eg GMail). While GMail isn't written in GWT, GWT is aimed at that kind of application with deferred binding and the benefits of static type analysis.
What if you took that expertise (of GWT and static type analysis in producing Javascript) to produce a language that could run on the server, run in the browser (for browsers that support that) and compile to Javascript (for browsers that don't)?
The last point is particular is key to driving adoption as no one is going to develop only for Chrome.
I see it as no surprise the syntax is Java-like. I fully expect sometime soon to see a JVM implementation that will then leverage all the existing Java libraries.
In that context (IMHO) it makes a lot more sense. It might not be solving the problems you're interested in but it is definitely solving a particular set of problems.
If Google produced an innovative replacement for JavaScript, the world would listen. Instead, based on what they have released so far and your comments, they have released a language that is primarily designed to enhance their own tool-chain, which the rest of the world doesn't use and isn't interested in. We don't use GWT. Apparently, we won't use Dart either.
IMHO, this is not a "break away" approach as originally indicated in the leaked memo.
One of the biggest pain point in web dev is the inconsistent DOM implementations. I was imagining some sort of DOM-less, HTML5 Canvas-based UI controls. And something about the "Web", Semantic Web/URIs or a new approach to programming on Web. This is NOT a break away language in any sense - its more re-packaging.
Google should be proposing a standard, open, byte-code compatible, Intermediate Language standard that can run Javascript and in the interim run on Javascript.
That is something I could see Mozilla and Apple getting behind.
Only once they have actively campaigned for this should they be adding new languages to the browser which fracture the web.
I had hoped that Dart would surprise us and turn out to be a 'machine-code for the web' implementation. This would have been a much smarter move, I believe.
+1000. Give us a platform that people can grow languages on! Maybe the DartVM could become something like what you describe in the same sense as the JVM/CLR is a platform for many languages now? But since their pushing the language it doesn't seem to be the stated goal... sad ;(
> Google should be proposing a standard, open, byte-code compatible, Intermediate Language standard that can run Javascript and in the interim run on Javascript.
> That is something I could see Mozilla and Apple getting behind.
Why would you expect either Mozilla or Apple to get behind such a proposal? Apple has a powerful self-interest in making sure the Web remains a second-best app platform behind iOS and desktop OS X. Mozilla wants the Web to be the premier app platform - but it's no bloody good to Mozilla if the web is the world's #1 web platform but Mozilla has no control over it anymore. The last thing Mozilla wants to see is the Web browser become some fairly-easily-implemented, highly-interchangeable runtime platform adhering to a stable, open spec somewhere. This would, I think, be very good for the world at large, but it would undoubtedly be very bad for Mozilla - it's what is known as the commoditization of the platform. Mozilla's self-interest is served by keeping as much of the Web as possible controlled, in the minutest detail possible, by the hard-to-join club of major browser vendors. Right down to things like the lexical syntax of JavaScript. So in reality, as soon as Google proposed such an IL, Mozilla's advocates would start blowing smoke about "oh no, another Java".
My hopes were high, but the more read about it, the more it started to look like Java:
class Foo implements Comparable Observable Deniable ...
Why not have interfaces like in Go, where you just define a set of methods and all classes having the methods will automatically implement the interface.
Is it really necessary in the 21st century to create a language that terminates lines with semicolons? I am sure I have seen some other languages in the past that get by just fine without them.
The language isn't done yet. Now is the time to let us know if you want semicolons to go away. I know some of us on the team do too, but public interest will help a lot.
To be honest though, small syntactical differences like that are something that is meaningful only for novice-to-intermediate level programmers. Semicolons, braces, tabs-vs-spaces - classical examples of bikeshed bickering.
This was my first thought, as well. Looks like I will still go with another layer on top like CoffeeScript to actually write my scripts. Curly braces for blocks are something I don't see the need for anymore, either.
Does having semicolons help with minification (which is common practice for sending JavaScript over the web)? Although, thinking about it, replacing ";" with "\n" would be the same number of bytes.
The only (contrived) advantage of using semicolons that I can think of is to avoid potential problems with line wrapping. For example, some mail clients add new lines after 80 characters, which would be more likely to break Dart code than JavaScript.
"Concurrency is supported via actor-like entities called isolates. An isolate is a unit of concurrency. It has its own memory and its own thread of control. Isolates communicate by message passing (10.14.4). No state is ever shared between isolates. Isolates are created by spawning (10.11)"
Well, you can implement pretty much everything you just described as a library. The only thing missing is preventing memory sharing, but that you can sort out at compile time.
An interesting question is if this means V8 is gaining threads.
If you're going to go to the trouble of creating a JavaScript replacement, making something more like Java is the wrong way to go IMO. CoffeeScript is a lot more palatable.
CoffeeScript basically simplifies (and does a pretty good job, imo) existing JavaScript language features. Whereas, Dart adds classes and interfaces and a few other neat things.
Admittedly, however, I do cringe whenever I see things like x.compareTo(y) or X x = new X();
The one thing I don't understand is why people work on new languages for the browser instead of giving us a platform (virtual machine / intermediate representation, whatever) to implement languages against.
I mean here in this thread we are already seeing it. Some people like semicolons, some people don't. Some people like a prototype based object system, some people like a class based system. And on and on.
I think what would really benefit us is a platform (like a JVM for the browser with a great API replacing the dom) where people could implement languages against. we would get
1) A lot of competition of languages (see what is happening on the JVM right now... Clojure, Scala, Groovy ... you name it), hopefully giving us better languages. Javascript has its strenghts but could you imagine that in such an environment a language that doesn't allow you to test whether or not something is a string would make it very long?
2) People could make their choice and be happy. Then you can program the server and the client in the same language, which is pretty much the main argument for server-side javascript.
Let the languages compete instead of giving us one and now another language for the platform!
I think the Dart VM will be a nice target for compilation from other languages. In general it's easier to put a typed language on an untyped runtime than it is to put an untyped language on a typed runtime.
Before Google I worked on an academic project that built a small Smalltalk-like VM that was also a compilation target for something that was very close to unthreaded Java. Worked pretty well.
This is what JavaScript is trying to be, with the latest revision. They're explicitly trying to make it a better target language for things like ClojureScript and CoffeeScript.
A question to ask yourself: If this had been Microsoft creating an IE10-only language to replace JavaScript, instead of Google, would you feel any differently about Dart?
But if they released an open-source version of IE, started shipping IE frequently for Windows, Macintosh and Linux and released the Dart language spec and implementation under an open-source license... well, then I'd like it a lot better.
Probably the biggest difference between JS and whatever revision to it you like, and Dart, is that dart is early-bound. That means, you can't change the list of methods or fields present on an object at runtime.
It doesn't really make sense to ask "Why should I switch from a language I already love?" If you're already productive and love what you're using, then you should probably keep using it.
There are people who want a language that is more modular, scales better than JS for programming in the large, for IDE tooling, or ahead of time compilation, etc. Take a look at the Dart spreadsheet Total for example (https://code.google.com/p/dart/source/browse/branches/bleedi...) I find this code a lot cleaner than JS versions I've seen.
The project page is very unclear, so I ended up on Wikipedia instead. Wikipedia actually has a leaked memo that seems to do a really good job describing the purpose of the language.
Specifically, the language is meant for three environments: server-side, compiled to JavaScript client-side, and fast native client-side once there is browser support. (The main goal is better performance on the client-side, which is deemed to be very difficult with JavaScript.)
However, the language looks so Java-like, one wonders why they didn't just use Java and extend GWT with a native Java client in Chrome. Did it just not make sense to bet the farm on Java when Oracle controls it?
Also, what does the "structured" in "structured web programming" mean?
The "hello world" example is incredibly uninformative. What does that have to do with "structured web programming"? Where is this printed out on a web page? Does the console output there correspond to the html output? Or some other console?
It was created in the 1990s and it still looks innovative, even compared to a lot of the new 'hot commodity' languages like python and ruby. I knew it wouldn't happen.
If a big corporation like Google put money into something like that, I think it would dominate the market.
But what they have delivered here isn't even interesting.
(The other option for something I would want would be standardized 'web byte-code', so that you just re-target a compiler back-end to emit it, and your language can be used as if it were javascript.
This is neither of those thing and I am sorely disappointed.
The thing I was really hoping for from the dart site was an "about" section, or a "why" section, explaining about the language and their goals, instead of just jumping to code examples...
Wow guys. Google is not aiming at a next gen Haskell or ML. They are trying to create a less cluttered Java and a stricter, more performant Javascript. Judge a solution in context of the problem it is trying to solve. If they got Simon Peyton Jones to design this it would be somewhat intimidating for your average webdev[no disrespect].
I'm somewhat disappointed that they insist on a 90's C syntax. It's like Python/Ruby/Coffeescript never existed.
Pretty disappointed with the lack of risk with this. Conceptually seemed like something with a ton of potential, but the minute I saw the tutorial shoehorning the worst of Java and JavaScript into something new, it was a non starter for me...better being insulated writing CoffeeScript a layer up and waiting for a compiler.
Things I've noticed so far that I don't like: get/set proliferation, semicolons, braces, positional args, var for instance vars, int/num dinostyle pseudo-primitives.
It seems like they tried to do some cool things, but failed in execution. Like "Greeter.withPrefix(this.prefix);" one-line constructor definition .. where this.prefix is a "shortcut that assigns the parameter's value to the instance variable prefix". Eliminate needless code.. but instead of using a dedicated symbol to call attention to the sugar, they used "this." WTF.. did they specifically want to kill scanability.
Things I've noticed so far that I like: using "_" as a prefix to enforce encapsulation.
Enforcing naming conventions as syntax seems at least somewhat python inspired in the sense of bringing the whitespace is significant design to naming is significant.. wish there had been more of that.
If someone other than Google were doing this it would be dead in the water already.
Funny to read all these comments just a few minutes after the announcement. I bet nobody had enough time to explore the language in any significant way. Yet very strong opinions already.
Two things I don't like about Dart, just from reading the tutorial:
1. Consuctor syntax requires repeating the name of the class when yor define the constructor. So if you change a class name, you have to carefully find all your constructors and rename them.
2. Instance variables in classes seem to be defined at the same level as class methods. Yet one is an instance attribute, and the other a class attribute. So you have irregular scoping rules based on type (data vs. function). This scares me as it indicates functions are "special" and not first-class types in the language.
[+] [-] thristian|14 years ago|reply
A Dart to JS compiler will never be "decent" compared to having the Dart VM in the browser. Yet I guarantee you that Apple and Microsoft (and Opera and Mozilla, but the first two are enough) will never embed the Dart VM. So "Works best in Chrome" and even "Works only in Chrome" are new norms promulgated intentionally by Google. We see more of this fragmentation every day. As a user of Chrome and Firefox (and Safari), I find it painful to experience, never mind the political bad taste
From here: https://news.ycombinator.com/item?id=2982949
[+] [-] georgemcbay|14 years ago|reply
The Dart to JS compiler doesn't have to be "decent" compared to having the Dart VM in the browser to be useful in a world where other browsers don't use the Dart VM, it merely has to be "decent" compared to handcrafted JavaScript performing the same task in another browser.
If direct Dart code runs faster than JavaScript on Chrome, that's a nice bonus, but if it runs as well as similar code that was originally written in JavaScript on the other browsers (when the Dart code is compiled to JS) that's good enough. Dart on the other browsers isn't competing with Dart on Chrome, it is competing with JavaScript on the other browsers and that's how it should be measured.
And if it turns out apps in Dart on Chrome really blow away apps in JavaScript on other browsers to the point where both devs and users start embracing Chrome even more for these gains then hopefully that will light a fire under everyone else to either adopt Dart or do something to fix what would then be an undeniable problem of JavaScript.
[+] [-] cromwellian|14 years ago|reply
If you run Google's closure compiler on JS, for example, in some cases, it produces a very significant speedup than hand-tuned hand-written JS, so saying "never be decent" is a pretty strong claim to make.
[+] [-] pacala|14 years ago|reply
[+] [-] cletus|14 years ago|reply
Think of it this way: what is GWT? GWT os compiling Java, a statically typed language, into Javascript. If you've used GWT you'll know that particularly early on there was a lot of friction. What's simple in Javascript with anonymous objects and duck typing doesn't quite gel with Java so you've had to do things like use JSNI for edge cases.
Google has some incredibly large and ocmplex JS apps (eg GMail). While GMail isn't written in GWT, GWT is aimed at that kind of application with deferred binding and the benefits of static type analysis.
What if you took that expertise (of GWT and static type analysis in producing Javascript) to produce a language that could run on the server, run in the browser (for browsers that support that) and compile to Javascript (for browsers that don't)?
The last point is particular is key to driving adoption as no one is going to develop only for Chrome.
I see it as no surprise the syntax is Java-like. I fully expect sometime soon to see a JVM implementation that will then leverage all the existing Java libraries.
In that context (IMHO) it makes a lot more sense. It might not be solving the problems you're interested in but it is definitely solving a particular set of problems.
[+] [-] maratd|14 years ago|reply
[+] [-] seasoup|14 years ago|reply
[+] [-] chintan|14 years ago|reply
One of the biggest pain point in web dev is the inconsistent DOM implementations. I was imagining some sort of DOM-less, HTML5 Canvas-based UI controls. And something about the "Web", Semantic Web/URIs or a new approach to programming on Web. This is NOT a break away language in any sense - its more re-packaging.
[+] [-] sambeau|14 years ago|reply
Google should be proposing a standard, open, byte-code compatible, Intermediate Language standard that can run Javascript and in the interim run on Javascript.
That is something I could see Mozilla and Apple getting behind.
Only once they have actively campaigned for this should they be adding new languages to the browser which fracture the web.
I had hoped that Dart would surprise us and turn out to be a 'machine-code for the web' implementation. This would have been a much smarter move, I believe.
[+] [-] paulkoer|14 years ago|reply
[+] [-] ConstantineXVI|14 years ago|reply
[+] [-] leoc|14 years ago|reply
> That is something I could see Mozilla and Apple getting behind.
Why would you expect either Mozilla or Apple to get behind such a proposal? Apple has a powerful self-interest in making sure the Web remains a second-best app platform behind iOS and desktop OS X. Mozilla wants the Web to be the premier app platform - but it's no bloody good to Mozilla if the web is the world's #1 web platform but Mozilla has no control over it anymore. The last thing Mozilla wants to see is the Web browser become some fairly-easily-implemented, highly-interchangeable runtime platform adhering to a stable, open spec somewhere. This would, I think, be very good for the world at large, but it would undoubtedly be very bad for Mozilla - it's what is known as the commoditization of the platform. Mozilla's self-interest is served by keeping as much of the Web as possible controlled, in the minutest detail possible, by the hard-to-join club of major browser vendors. Right down to things like the lexical syntax of JavaScript. So in reality, as soon as Google proposed such an IL, Mozilla's advocates would start blowing smoke about "oh no, another Java".
[+] [-] nene|14 years ago|reply
I could go just on and on...
[+] [-] jurre|14 years ago|reply
Primitives and objects, it kind of makes sense but I do see your point.
[+] [-] vegai|14 years ago|reply
[+] [-] timclark|14 years ago|reply
Is it really necessary in the 21st century to create a language that terminates lines with semicolons? I am sure I have seen some other languages in the past that get by just fine without them.
[+] [-] munificent|14 years ago|reply
[+] [-] roel_v|14 years ago|reply
[+] [-] perlgeek|14 years ago|reply
Python is a totally different beast, and I wouldn't include it in the discussion, because it also uses whitespace for block grouping.
[+] [-] ch0wn|14 years ago|reply
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] dave1010uk|14 years ago|reply
The only (contrived) advantage of using semicolons that I can think of is to avoid potential problems with line wrapping. For example, some mail clients add new lines after 80 characters, which would be more likely to break Dart code than JavaScript.
[+] [-] shykes|14 years ago|reply
"Concurrency is supported via actor-like entities called isolates. An isolate is a unit of concurrency. It has its own memory and its own thread of control. Isolates communicate by message passing (10.14.4). No state is ever shared between isolates. Isolates are created by spawning (10.11)"
http://www.dartlang.org/docs/spec/dartLangSpec.pdf
I wonder how they compile this down to Javascript?
[+] [-] psawaya|14 years ago|reply
[+] [-] moomin|14 years ago|reply
An interesting question is if this means V8 is gaining threads.
[+] [-] akavlie|14 years ago|reply
[+] [-] jamesrom|14 years ago|reply
Admittedly, however, I do cringe whenever I see things like x.compareTo(y) or X x = new X();
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] paulkoer|14 years ago|reply
I mean here in this thread we are already seeing it. Some people like semicolons, some people don't. Some people like a prototype based object system, some people like a class based system. And on and on.
I think what would really benefit us is a platform (like a JVM for the browser with a great API replacing the dom) where people could implement languages against. we would get
1) A lot of competition of languages (see what is happening on the JVM right now... Clojure, Scala, Groovy ... you name it), hopefully giving us better languages. Javascript has its strenghts but could you imagine that in such an environment a language that doesn't allow you to test whether or not something is a string would make it very long?
2) People could make their choice and be happy. Then you can program the server and the client in the same language, which is pretty much the main argument for server-side javascript.
Let the languages compete instead of giving us one and now another language for the platform!
[+] [-] ErikCorry|14 years ago|reply
Before Google I worked on an academic project that built a small Smalltalk-like VM that was also a compilation target for something that was very close to unthreaded Java. Worked pretty well.
[+] [-] tree_of_item|14 years ago|reply
[+] [-] jashkenas|14 years ago|reply
[+] [-] cwp|14 years ago|reply
But if they released an open-source version of IE, started shipping IE frequently for Windows, Macintosh and Linux and released the Dart language spec and implementation under an open-source license... well, then I'd like it a lot better.
[+] [-] snorkel|14 years ago|reply
[+] [-] cromwellian|14 years ago|reply
It doesn't really make sense to ask "Why should I switch from a language I already love?" If you're already productive and love what you're using, then you should probably keep using it.
There are people who want a language that is more modular, scales better than JS for programming in the large, for IDE tooling, or ahead of time compilation, etc. Take a look at the Dart spreadsheet Total for example (https://code.google.com/p/dart/source/browse/branches/bleedi...) I find this code a lot cleaner than JS versions I've seen.
[+] [-] socratic|14 years ago|reply
The project page is very unclear, so I ended up on Wikipedia instead. Wikipedia actually has a leaked memo that seems to do a really good job describing the purpose of the language.
Specifically, the language is meant for three environments: server-side, compiled to JavaScript client-side, and fast native client-side once there is browser support. (The main goal is better performance on the client-side, which is deemed to be very difficult with JavaScript.)
However, the language looks so Java-like, one wonders why they didn't just use Java and extend GWT with a native Java client in Chrome. Did it just not make sense to bet the farm on Java when Oracle controls it?
Also, what does the "structured" in "structured web programming" mean?
[+] [-] frisco|14 years ago|reply
[+] [-] ohyes|14 years ago|reply
http://en.wikipedia.org/wiki/Dylan_programming_language
It was created in the 1990s and it still looks innovative, even compared to a lot of the new 'hot commodity' languages like python and ruby. I knew it wouldn't happen.
If a big corporation like Google put money into something like that, I think it would dominate the market.
But what they have delivered here isn't even interesting.
(The other option for something I would want would be standardized 'web byte-code', so that you just re-target a compiler back-end to emit it, and your language can be used as if it were javascript.
This is neither of those thing and I am sorely disappointed.
[+] [-] vegai|14 years ago|reply
[+] [-] pyrhho|14 years ago|reply
[+] [-] wulfric|14 years ago|reply
I'm somewhat disappointed that they insist on a 90's C syntax. It's like Python/Ruby/Coffeescript never existed.
C'mon Google, you can do way better...
[+] [-] stephenhandley|14 years ago|reply
Things I've noticed so far that I don't like: get/set proliferation, semicolons, braces, positional args, var for instance vars, int/num dinostyle pseudo-primitives.
It seems like they tried to do some cool things, but failed in execution. Like "Greeter.withPrefix(this.prefix);" one-line constructor definition .. where this.prefix is a "shortcut that assigns the parameter's value to the instance variable prefix". Eliminate needless code.. but instead of using a dedicated symbol to call attention to the sugar, they used "this." WTF.. did they specifically want to kill scanability.
Things I've noticed so far that I like: using "_" as a prefix to enforce encapsulation.
Enforcing naming conventions as syntax seems at least somewhat python inspired in the sense of bringing the whitespace is significant design to naming is significant.. wish there had been more of that.
If someone other than Google were doing this it would be dead in the water already.
[+] [-] perfunctory|14 years ago|reply
[+] [-] mckoss|14 years ago|reply
1. Consuctor syntax requires repeating the name of the class when yor define the constructor. So if you change a class name, you have to carefully find all your constructors and rename them.
2. Instance variables in classes seem to be defined at the same level as class methods. Yet one is an instance attribute, and the other a class attribute. So you have irregular scoping rules based on type (data vs. function). This scares me as it indicates functions are "special" and not first-class types in the language.
[+] [-] tcard|14 years ago|reply