Microsoft shoots down Google's Dart(news.cnet.com)
news.cnet.com
Microsoft shoots down Google's Dart
http://news.cnet.com/8301-30685_3-57330431-264/microsoft-shoots-down-googles-dart-language/
15 comments
Not an endorsement of Dart at all, considering people who haven't really learned javascript by now are going to be the same people who won't really learn Dart in the future.
Guilty. Any recommendations for learning?
edit: I have the rhino book. I meant, learning alternatives to organizing my code as a series of jQuery event bindings.
edit: I have the rhino book. I meant, learning alternatives to organizing my code as a series of jQuery event bindings.
Yehuda Katz has a nice article on the prototype system that I generally point people to.
http://yehudakatz.com/2011/08/12/understanding-prototypes-in...
And the JavaScript Patterns book is a good read to get an overview of what can be done with just JavaScript. If your application is even remotely complex you'll probably end up using something like backbone or sproutcore which provide constructs for organizing your code anyway.
http://yehudakatz.com/2011/08/12/understanding-prototypes-in...
And the JavaScript Patterns book is a good read to get an overview of what can be done with just JavaScript. If your application is even remotely complex you'll probably end up using something like backbone or sproutcore which provide constructs for organizing your code anyway.
Douglas Crockford is the best JS teacher I've come across.
This video series is excellent (and provides a bit of CS history) http://yuiblog.com/crockford/
Also his book, Javascript: The Good Parts
This video series is excellent (and provides a bit of CS history) http://yuiblog.com/crockford/
Also his book, Javascript: The Good Parts
My favorite is 'JavaScript Patterns' (http://www.amazon.com/JavaScript-Patterns-Stoyan-Stefanov/dp...).
The most interesting part of the Microsoft blogpost that is the basis for this story, IMO, is that
> The Office Web Applications, which consist of hundreds of thousands of lines of JavaScript, are written primarily in a variant of Script# that is then compiled into JavaScript that can be executed on today’s browsers. http://blogs.msdn.com/b/ie/archive/2011/11/22/evolving-ecmas...
Apparently Script# is quite mature now, and is being used to compile very large apps to JavaScript. This is a big vote of confidence from Microsoft regarding JavaScript as a compilation target.
> The Office Web Applications, which consist of hundreds of thousands of lines of JavaScript, are written primarily in a variant of Script# that is then compiled into JavaScript that can be executed on today’s browsers. http://blogs.msdn.com/b/ie/archive/2011/11/22/evolving-ecmas...
Apparently Script# is quite mature now, and is being used to compile very large apps to JavaScript. This is a big vote of confidence from Microsoft regarding JavaScript as a compilation target.
> Apparently Script# is quite mature now, and is being used to compile very large apps to JavaScript. This is a big vote of confidence from Microsoft regarding JavaScript as a compilation target.
I'd say the same thing about Google's own Closure, which they oddly enough don't mention alongside CoffeeScript et al.
I see Dart as a rethinking of much of Closure so I don't quite get what Microsoft thinks the difference between their Script# and Dart/Closure is.
I'd say the same thing about Google's own Closure, which they oddly enough don't mention alongside CoffeeScript et al.
I see Dart as a rethinking of much of Closure so I don't quite get what Microsoft thinks the difference between their Script# and Dart/Closure is.
Did you mean Google Web Toolkit? That compiles Java to JS, and is similar to Script# (which compiles C# to JS). Whereas Closure Compiler is an optimizing compiler for JS, it compiles JS to (better) JS. (The Microsoft article did mention Google Web Toolkit, which was nice of them.)
GWT and Script# are both quite mature at this point, it looks like. Very interesting stuff. (However, GWT is probably losing focus inside Google to Dart, so I am not sure of its long-term prospects. It's open source though so anyone can continue it if they want.)
GWT and Script# are both quite mature at this point, it looks like. Very interesting stuff. (However, GWT is probably losing focus inside Google to Dart, so I am not sure of its long-term prospects. It's open source though so anyone can continue it if they want.)
Closure compiler doesn't just compile vanilla JS. It supports type annotations in comments and will use those to generate code. It's type system supports classes and interfaces. The Closure library has support for class-style inheritance.
Programming in Closure-style JS feels like you're using an optionally-typed class-based language, just one with really terrible syntax.
Programming in Closure-style JS feels like you're using an optionally-typed class-based language, just one with really terrible syntax.
Thanks, I didn't know that. Perhaps those type annotations could help optimize compiled code (like from Emscripten).
Google's stated they'd like to have native Dart in the browser eventually; that's likely their gripe.
I've never understood the point of special browser only languages.
Why don't browsers support a sand-boxed python (or insert favorite language x) with some sort of standard dependency management? It already has JIT compilation, is cross-platform, bytecode, a wealth of libraries, etc. Why are we reinventing this wheel?
Why don't browsers support a sand-boxed python (or insert favorite language x) with some sort of standard dependency management? It already has JIT compilation, is cross-platform, bytecode, a wealth of libraries, etc. Why are we reinventing this wheel?
JavaScript isn't a special "browser-only" language. It's just a normal interpreted, dynamically typed language (much like Python or Ruby) that just happens to run in all browsers. Right now it also happens to be quite a bit faster than Python or Ruby (as far as I know) and is also extremely expressive and flexible.
The fact that Python has "a wealth of libraries" isn't particularly pertinent--web apps mostly need web-specific libraries, which Python doesn't have (because it isn't in the browser). Most people using JavaScript get by with jQuery, maybe some web ui framework and perhaps something like Raphael. And, with the advent of node and server-side JavaScript, JavaScript is getting more and more libraries outside of the browser as well.
Of course, the browsers could support a bunch of different languages, but I think the complexity outweighs the (limited) benefits. Google, obviously, disagrees and thinks that Dart should also be an option, but I really think it isn't worth the effort.
Ultimately, JavaScript is more than good enough as a browser language; while it does have some annoying quirks, upcoming versions (and things like "use strict") are getting rid of most of them. There really is no overwhelming reason to switch away from JavaScript, and even just adding another language is probably not worth it.
The fact that Python has "a wealth of libraries" isn't particularly pertinent--web apps mostly need web-specific libraries, which Python doesn't have (because it isn't in the browser). Most people using JavaScript get by with jQuery, maybe some web ui framework and perhaps something like Raphael. And, with the advent of node and server-side JavaScript, JavaScript is getting more and more libraries outside of the browser as well.
Of course, the browsers could support a bunch of different languages, but I think the complexity outweighs the (limited) benefits. Google, obviously, disagrees and thinks that Dart should also be an option, but I really think it isn't worth the effort.
Ultimately, JavaScript is more than good enough as a browser language; while it does have some annoying quirks, upcoming versions (and things like "use strict") are getting rid of most of them. There really is no overwhelming reason to switch away from JavaScript, and even just adding another language is probably not worth it.
Javascript was originally built for the browser and later expanded to other areas.
I'm not claiming that python wouldn't need a new standard library to manipulate a browser's dom tree or whatever. That's about all it would need though, so it seems like it would have been far less work to embrace and extend than to completely start over.
You seem to be arguing from the perspective (and please correct me if I'm wrong) that javascript is a good solution and a fine programming language, and I am not claiming otherwise. I just don't understand why so much effort has been spent creating and polishing Javascript instead of making slight improvements to a previously established quality language.
I suspect the answer is that your browser has an advantage if your javascript engine is faster, but there can be no advantage if everyone uses the standard python interpreter.
I'm not claiming that python wouldn't need a new standard library to manipulate a browser's dom tree or whatever. That's about all it would need though, so it seems like it would have been far less work to embrace and extend than to completely start over.
You seem to be arguing from the perspective (and please correct me if I'm wrong) that javascript is a good solution and a fine programming language, and I am not claiming otherwise. I just don't understand why so much effort has been spent creating and polishing Javascript instead of making slight improvements to a previously established quality language.
I suspect the answer is that your browser has an advantage if your javascript engine is faster, but there can be no advantage if everyone uses the standard python interpreter.
I'm not sure why Netscape decided to write their own language for the job. Perhaps integrating a different language into their browser would have been difficult back then. Now, however, JavaScript is a well-established language so there is no need to replace it with anything else.
Also, unless I'm unaware of something, wasn't Perl the most popular scripting language back then? So if they had included an already existing language, Perl would probably have been the best bet.
Also, unless I'm unaware of something, wasn't Perl the most popular scripting language back then? So if they had included an already existing language, Perl would probably have been the best bet.
So if they had included an already existing language, Perl would probably have been the best bet.
Embedding Perl was (and is) painful. Tcl would have been easier.
Sandboxing would have been more difficult. Auditing all of Perl 5's operations for the possibility of escaping that sandbox is a huge task.
Embedding Perl was (and is) painful. Tcl would have been easier.
Sandboxing would have been more difficult. Auditing all of Perl 5's operations for the possibility of escaping that sandbox is a huge task.
The web browser is being sold to developers as a "general applications platform" to compete with native applications.
Since native environments often give the developer a greater degree of language-choice freedom as well as greater degree of access to complex APIs, I fail to see how offering the same freedoms in the comparatively miniscule browser API would cause the complexity to outweigh the benefits.
If browser makers just standardized on a language-neutral runtime like the JVM or the CLR then no central committee would have to be responsible for maintaining support for specific languages.
Since native environments often give the developer a greater degree of language-choice freedom as well as greater degree of access to complex APIs, I fail to see how offering the same freedoms in the comparatively miniscule browser API would cause the complexity to outweigh the benefits.
If browser makers just standardized on a language-neutral runtime like the JVM or the CLR then no central committee would have to be responsible for maintaining support for specific languages.
Exactly, it's time for us to transition to a CLR for web browsers and allow people to continue deploying plain-text javascript which the browser can compile, or let them deploy precompiled byte code written in their favorite language.
> Why don't browsers support a sand-boxed python (or insert favorite language x) with some sort of standard dependency management? It already has JIT compilation, is cross-platform, bytecode, a wealth of libraries, etc. Why are we reinventing this wheel?
1. Python is not sandboxed. Security is necessary in a web browser. 2. Python has some JIT work, mainly PyPy, but even so is much slower than JavaScript. 3. You can compile Python into JavaScript (see demo at repl.it), where it will be sandboxed.
Similar reasons apply to other proposed languages, for a web language we need security, speed, standardization, and portability (and often we can already compile them into JS, so the motivation is lessened anyhow). I am unaware of any option that has all of those to the extent that JavaScript does.
1. Python is not sandboxed. Security is necessary in a web browser. 2. Python has some JIT work, mainly PyPy, but even so is much slower than JavaScript. 3. You can compile Python into JavaScript (see demo at repl.it), where it will be sandboxed.
Similar reasons apply to other proposed languages, for a web language we need security, speed, standardization, and portability (and often we can already compile them into JS, so the motivation is lessened anyhow). I am unaware of any option that has all of those to the extent that JavaScript does.
Firefox nightlies do support Python. It's unfortunate that nobody wants to migrate away from JS though.
Why is it unfortunate? Once you learn it properly, JavaScript is a very pleasant language to work in and, I find, quite a bit more expressive than Python. It also doesn't make using a functional programming style painful the way Python does.
Are you implying that anyone who doesn't consider JavaScript a "very pleasant language" must simply not know it "properly"? Are you implying that there are no other possible reasons?
The lack of tail call optimization, persistent data structures, pattern matching and the cumbersome lambda syntax makes functional programming style very painful in Javascript.
What does "functional programming style" mean?
Does it mean lambdas or other anonymous functions? Python lets you close over names at any scope and define functions anywhere; you don't need the "lambda" keyword. Even if you want to only use lambdas, it's been shown that Python does not need statements, only expressions, to express everything, although you quickly turn your code into Scheme-soup. JS doesn't somehow improve on this.
Is it first-class functions? Python has those, just like JavaScript, although Python goes further, enabling you to have real bound methods, descriptors, properties, class methods, and all other kinds of fun.
Is it map, filter, and fold? Python's still got map, filter, and fold (foldl, called "reduce" in Python.) Python also has list comprehensions, borrowed from Haskell, as well as generator expressions, providing that valuable laziness that some functional languages value so much. And, in Python 3, there are set and dictionary comprehensions as well. JavaScript doesn't have comprehensions at all.
Is it referential transparency or immutability? Unlike JavaScript, Python refuses to allow you to edit the values of certain builtin types, like str and unicode.
So, uh, what did you mean, exactly?
Does it mean lambdas or other anonymous functions? Python lets you close over names at any scope and define functions anywhere; you don't need the "lambda" keyword. Even if you want to only use lambdas, it's been shown that Python does not need statements, only expressions, to express everything, although you quickly turn your code into Scheme-soup. JS doesn't somehow improve on this.
Is it first-class functions? Python has those, just like JavaScript, although Python goes further, enabling you to have real bound methods, descriptors, properties, class methods, and all other kinds of fun.
Is it map, filter, and fold? Python's still got map, filter, and fold (foldl, called "reduce" in Python.) Python also has list comprehensions, borrowed from Haskell, as well as generator expressions, providing that valuable laziness that some functional languages value so much. And, in Python 3, there are set and dictionary comprehensions as well. JavaScript doesn't have comprehensions at all.
Is it referential transparency or immutability? Unlike JavaScript, Python refuses to allow you to edit the values of certain builtin types, like str and unicode.
So, uh, what did you mean, exactly?
Python is much harder to make fast due to its highly dynamic nature. (Yes, Python is a much more dynamic language than JS -- see del(), locals(), code objects, etc.)
I'm not sure how locals() or code objects makes Python much more dynamic than JS -- even on it's own, but especially since it very rarely appears in idiomatic python code. Nothing in Python comes close to the dynamic mess that is JavaScript's "with" (bindings in Python are lexical; "with" makes bindings in JavaScript dynamic!)
Even if you were right, you could still make code that doesn't use these features fast, and slow back to interpreted if any of these features is used -- that's what JS JITs do when they see "with".
And finally, Lua is as dynamic as Python (both of which are, in my opinion, less dynamic than JS thanks to lexical binding). And Lua has been made significantly faster than any Python or JS implementation (Mike Pall's LuaJIT2)
Even if you were right, you could still make code that doesn't use these features fast, and slow back to interpreted if any of these features is used -- that's what JS JITs do when they see "with".
And finally, Lua is as dynamic as Python (both of which are, in my opinion, less dynamic than JS thanks to lexical binding). And Lua has been made significantly faster than any Python or JS implementation (Mike Pall's LuaJIT2)
The work has already been done; see PyPy (http://pypy.org/).
It looks like it's really the alternate VM that's being "shot down". After all, the piece goes to the trouble of pointing out that "...transforming compiler libraries like Traceur and CoffeeScript show how syntax additions to JavaScript and even completely alternative syntaxes can be supported in today’s browsers, without changes to the runtime."
Disclaimer: I work at Microsoft.
Disclaimer: I work at Microsoft.
But those languages aren't a significant deviation and still require pre-compilation as opposed to runtime cross-compilation to be useful. Dart is a significant deviation and expected to support debugging directly in the language. Similar to developing in GWT, I doubt the JS will really be looked by the developers at once Dart's compiler is optimized more.
Also, the VM wouldn't be required, it would just provide performance improvements.
Also, the VM wouldn't be required, it would just provide performance improvements.
Dart is a significant deviation and expected to support debugging directly in the language.
This can be done for CoffeeScript et al too - efforts are already underway.
Also, the VM wouldn't be required, it would just provide performance improvements.
There's just too much embrace-extend-extinguish risk for anyone but Google in that. That's why Mozilla and Microsoft are burning it at the stake.
This can be done for CoffeeScript et al too - efforts are already underway.
Also, the VM wouldn't be required, it would just provide performance improvements.
There's just too much embrace-extend-extinguish risk for anyone but Google in that. That's why Mozilla and Microsoft are burning it at the stake.
> Also, the VM wouldn't be required, it would just provide performance improvements.
I'm curious, is this true? Last I heard, Dart-in-JS didn't enforce types, so integer math could overflow into doubles for example, but the Dart VM did use native types (so ints would not overflow). So the semantics of the language differ in JS and in the native VM, which means the VM doesn't just provide speed, it provides different behavior.
Is this no longer the case - are the semantics of Dart-in-JS and in the VM exactly the same?
I'm curious, is this true? Last I heard, Dart-in-JS didn't enforce types, so integer math could overflow into doubles for example, but the Dart VM did use native types (so ints would not overflow). So the semantics of the language differ in JS and in the native VM, which means the VM doesn't just provide speed, it provides different behavior.
Is this no longer the case - are the semantics of Dart-in-JS and in the VM exactly the same?
Disclaimer: I work for Google.
JavaScript doesn't have integers. I suspect that the Dart VM will support integers with overflow. So yes, I suspect in that case they are different.
I also strongly suspect this will not be a significant edge case in practice: if you use integer types in your dart code, then you clearly don't want doubles to result from a calculation. So the only unexpected "surprise" you would encounter there is if you expect integer overflow but get doubles. If you are writing code that expects integer overflow to happen a certain way, you're doing it wrong. If you're writing code that doesn't expect integer overflow, and you want integers, then you're going to be fucked either way. Either you end up with doubles and type errors or an overflow and your result is wrong.
Changing things as entrenched as JavaScript while maintaining backwards compatibility is messy and hard. Especially given some of the horrible characteristics of the language. I'm glad someone's at least trying.
JavaScript doesn't have integers. I suspect that the Dart VM will support integers with overflow. So yes, I suspect in that case they are different.
I also strongly suspect this will not be a significant edge case in practice: if you use integer types in your dart code, then you clearly don't want doubles to result from a calculation. So the only unexpected "surprise" you would encounter there is if you expect integer overflow but get doubles. If you are writing code that expects integer overflow to happen a certain way, you're doing it wrong. If you're writing code that doesn't expect integer overflow, and you want integers, then you're going to be fucked either way. Either you end up with doubles and type errors or an overflow and your result is wrong.
Changing things as entrenched as JavaScript while maintaining backwards compatibility is messy and hard. Especially given some of the horrible characteristics of the language. I'm glad someone's at least trying.
> JavaScript doesn't have integers. I suspect that the Dart VM will support integers with overflow. So yes, I suspect in that case they are different. [..] I also strongly suspect this will not be a significant edge case in practice [..] If you are writing code that expects integer overflow to happen a certain way, you're doing it wrong.
It's a valid position to say that relying on integer overflow in one's Dart code is "wrong". But you will need to carefully educate coders about that, since relying on overflow is common in popular languages like C and C++. This won't be easy.
Another big worry is that this could lead to very hard to diagnose bugs. Having the native VM and the compiled code have different semantics in subtle ways is risky - unintended overflows will lead to different bugs in different cases.
Also, integer overflow is not the only case where this problem arises. It also happens with say division of an integer. Will Dart compiled code in JS add proper rounding correction to all divisions of integers? Or will this be another case where the VM differs from compiled code?
Overall, it seems much simpler and safer to just correct overflows in the compiled code.
> Especially given some of the horrible characteristics of the language [JavaScript]
It's fine if you don't like something of course, but I don't think calling languages "horrible" is going to lead to a productive discussion.
It's a valid position to say that relying on integer overflow in one's Dart code is "wrong". But you will need to carefully educate coders about that, since relying on overflow is common in popular languages like C and C++. This won't be easy.
Another big worry is that this could lead to very hard to diagnose bugs. Having the native VM and the compiled code have different semantics in subtle ways is risky - unintended overflows will lead to different bugs in different cases.
Also, integer overflow is not the only case where this problem arises. It also happens with say division of an integer. Will Dart compiled code in JS add proper rounding correction to all divisions of integers? Or will this be another case where the VM differs from compiled code?
Overall, it seems much simpler and safer to just correct overflows in the compiled code.
> Especially given some of the horrible characteristics of the language [JavaScript]
It's fine if you don't like something of course, but I don't think calling languages "horrible" is going to lead to a productive discussion.
> But you will need to carefully educate coders about that, since relying on overflow is common in popular languages like C and C++.
This is something we're aware of and we know we need to be extra clear and loud about it.
> Also, integer overflow is not the only case where this problem arises.
As far as I know, bigints are the only place where the VM and the generated JS intentionally differ in behavior. We are trying very hard to keep the two in sync.
> It also happens with say division of an integer. Will Dart compiled code in JS add proper rounding correction to all divisions of integers?
Dart has two division operators (~/ and /) to handle this. The former rounds (truncates? I'm not sure) and the latter does floating point division. So it's always the operation that determines the type of the result, and not the type of the operands.
> Overall, it seems much simpler and safer to just correct overflows in the compiled code.
Simpler: yes. Safer: yes. Unfortunately, it's also much slower.
Rolling your own numeric type in JS means slower behavior when you have overflowed and slow behavior even when you haven't. If you're generating code for "a + b", you can't compile that to "a + b" in JS because you need to check for overflow and handle the fact that a or b could be bignums.
We really want the compiled JS to behave the same as native code, but if it's significantly slower, people just won't use it at all. It's an unfortunate trade-off.
This is something we're aware of and we know we need to be extra clear and loud about it.
> Also, integer overflow is not the only case where this problem arises.
As far as I know, bigints are the only place where the VM and the generated JS intentionally differ in behavior. We are trying very hard to keep the two in sync.
> It also happens with say division of an integer. Will Dart compiled code in JS add proper rounding correction to all divisions of integers?
Dart has two division operators (~/ and /) to handle this. The former rounds (truncates? I'm not sure) and the latter does floating point division. So it's always the operation that determines the type of the result, and not the type of the operands.
> Overall, it seems much simpler and safer to just correct overflows in the compiled code.
Simpler: yes. Safer: yes. Unfortunately, it's also much slower.
Rolling your own numeric type in JS means slower behavior when you have overflowed and slow behavior even when you haven't. If you're generating code for "a + b", you can't compile that to "a + b" in JS because you need to check for overflow and handle the fact that a or b could be bignums.
We really want the compiled JS to behave the same as native code, but if it's significantly slower, people just won't use it at all. It's an unfortunate trade-off.
> > Overall, it seems much simpler and safer to just correct overflows in the compiled code.
> Simpler: yes. Safer: yes. Unfortunately, it's also much slower.
In my experience with something similar - compiling LLVM to JavaScript in Emscripten, which also needs to properly implement integer math in JavaScript - it actually isn't a lot slower. On the Emscripten benchmark suite enabling overflow correction everywhere makes it only 5% slower. We might be running very different benchmarks I guess.
(However, overflow correction does increase code size a lot, which is why we have tools that let you get rid of it where it isn't needed.)
> Simpler: yes. Safer: yes. Unfortunately, it's also much slower.
In my experience with something similar - compiling LLVM to JavaScript in Emscripten, which also needs to properly implement integer math in JavaScript - it actually isn't a lot slower. On the Emscripten benchmark suite enabling overflow correction everywhere makes it only 5% slower. We might be running very different benchmarks I guess.
(However, overflow correction does increase code size a lot, which is why we have tools that let you get rid of it where it isn't needed.)
> Similar to developing in GWT, I doubt the JS will really be looked by the developers at once Dart's compiler is optimized more.
Readable, debuggable JS is a high priority for Dart's Dart->JS compiler.
Readable, debuggable JS is a high priority for Dart's Dart->JS compiler.
Microsoft has long since lost the ability to shape the face of the web. While they do contribute to w3c here and there, at the end of the day the webkit and firefox teams are going to control where it goes. The question isn't whether or not it has Microsoft's support, the question is whether or not javascript is flawed enough to put the effort needed into releasing a new scripting language engine with browsers.
Disclaimer: I work for Microsoft.
Disclaimer: I work for Microsoft.
at the end of the day the webkit and firefox teams are going to control where it goes.
I don't think this is entirely true. IE still has more than enough marketshare to matter. Microsoft embracing some approach, be it a new language, or be it evolving JavaScript, has influences in how likely the efforts of the other teams are to succeed in the marketplace.
I don't think this is entirely true. IE still has more than enough marketshare to matter. Microsoft embracing some approach, be it a new language, or be it evolving JavaScript, has influences in how likely the efforts of the other teams are to succeed in the marketplace.
> Microsoft has long since lost the ability to shape the face of the web.
In a sense, it did. There are tons of IE6 installations in companies that built "web-based" applications that run only on IE6 and they won't upgrade to newer Microsoft browsers soon. OTOH, IE6+7+8+9 still has a huge percentage of the market and some flavor of IE comes pre-installed on about every desktop computer sold and web developers still have to cope with partial or incorrect support for many newer standards.
In a sense, it did. There are tons of IE6 installations in companies that built "web-based" applications that run only on IE6 and they won't upgrade to newer Microsoft browsers soon. OTOH, IE6+7+8+9 still has a huge percentage of the market and some flavor of IE comes pre-installed on about every desktop computer sold and web developers still have to cope with partial or incorrect support for many newer standards.
Ahh ... so the Evil Empire's new tactic for Total World Domination is to deny they have Total World Domination.
;-)
;-)
Saying Dart needs Microsoft adoption is like saying CoffeeScript or GWT needs Microsoft adoption. They all allow JS compilation and the ability to use JS and be called from JS. Google will likely make an IE extension to run Dart natively anyways.
> Saying Dart needs Microsoft adoption is like saying CoffeeScript or GWT needs Microsoft adoption. They all allow JS compilation and the ability to use JS and be called from JS.
I'm not sure that is the case, because of the native Dart VM.
CoffeeScript compiles very straightforwardly into JS, with similar performance to normal JS. But Dart is significantly different, and the Dart VM could be faster than Dart-compiled-to-JS, both because (1) The Dart VM will be optimized for Dart in new ways, and (2) It isn't clear that Dart code will be extremely efficient when compiled to JS.
So CoffeeScript adoption needs no support from browser vendors, but Dart, if it is to fulfill its goal of being fast, might need the Dart VM. And that does need browser vendor support.
I'm not sure that is the case, because of the native Dart VM.
CoffeeScript compiles very straightforwardly into JS, with similar performance to normal JS. But Dart is significantly different, and the Dart VM could be faster than Dart-compiled-to-JS, both because (1) The Dart VM will be optimized for Dart in new ways, and (2) It isn't clear that Dart code will be extremely efficient when compiled to JS.
So CoffeeScript adoption needs no support from browser vendors, but Dart, if it is to fulfill its goal of being fast, might need the Dart VM. And that does need browser vendor support.
If it requires my users on a public site to install an extension, I'm not going to use it. case. closed.
What he said was that Dart will compile into JS.
Natively run Dart will (otherwise, what's the point) than the JS it can be compiled into. What I forsee is some kind of conditional that will allow Chrome to run the Dart code, and other browser get served the compiled-into-JS.
Demanding an extension installation is a no-go.
Natively run Dart will (otherwise, what's the point) than the JS it can be compiled into. What I forsee is some kind of conditional that will allow Chrome to run the Dart code, and other browser get served the compiled-into-JS.
Demanding an extension installation is a no-go.
It wont. No legitimate developer would replace JS with it if that requirement existed.
I was surprised to hear about Dart. A closer look at Google's other new language (Go), shows a statically typed, compiled language that can be safely sand-boxed. For example, look at how Google has included Go in AppEngine. Additionally, there has been work at compiling Go to another project of theirs, Native Client (NaCl). It still seems like this might be a good match.
It took long enough for people to agree on Javascript and and HTML standard. It works well for most people, most of the time. Dart smells to me of another .NET for web...a framework that works ok, but not spectacularly enough for me to care.
Also, it seems there are a lot of people who don't like Javascript and try to either replace it or compile down to it. I don't understand why. I love Javascript. I think it's terse and powerful. It's a perfect fit for web applications. Sure, there may be a few annoying flaws, but it works well for its intended purposes. Also, add a few libraries, or a real framework like Mootools, and most of the flaws vanish.
Also, if we're going to go around creating systems for creating web apps that compile to javascript, can we PLEASE use languages that allow macros (ie a lisp variant)? Does another C-like language really add anything? (I'm actually asking, not judging)
Also, it seems there are a lot of people who don't like Javascript and try to either replace it or compile down to it. I don't understand why. I love Javascript. I think it's terse and powerful. It's a perfect fit for web applications. Sure, there may be a few annoying flaws, but it works well for its intended purposes. Also, add a few libraries, or a real framework like Mootools, and most of the flaws vanish.
Also, if we're going to go around creating systems for creating web apps that compile to javascript, can we PLEASE use languages that allow macros (ie a lisp variant)? Does another C-like language really add anything? (I'm actually asking, not judging)
It's been a looong time since i fooled around with it, but isn't IE the only browser that lets you specify the scripting language in page? I vaguely recall using perl and Windows Scripting Host to do perl in a web page... Perhaps my memory is as fossilized as that tech though.
I think their goal was to support any language. Do they still even support VBScript now?
I believe Dart may have lot of uses beyond scripting HTML pages, and does not need for IE compatibility.
And I have not found a single word about Dart in the article. Just some small changes in JavaScript, very minor compared to what is planed to JavaScript 5.
Interesting. This must be a new position within Microsoft - it deviated significantly from the previous Silverlight idea of using C# within an environment provided by a browser plug-in.
Now that they discontinued the plugin (was it a month ago?), they feel it's OK to criticize Google's approach.
Now that they discontinued the plugin (was it a month ago?), they feel it's OK to criticize Google's approach.
If they've decided to abandon plugins and proprietary languages in favor of javascript, why shouldn't they feel that it is ok to criticize Google's approach?
Usually, when you defend a flawed approach for years and spend millions of dollars on it, it's surprising to see you attack a competitor for following a very similar but slightly less flawed approach, weeks after you partially and not very publicly acknowledge your mistake.
They haven't officially discontinued anything.
I think they announced the EOL'ing of the browser plugin.
Strictly, not yet. They /did/ announce that IE in Win8 (in Metro mode) won't support plugins of any kind, Silverlight included.
So, they are criticizing the approach they still endorse?
Well, duh. They also seem to indicate (in the linked blog post) that they have no interest in the language's syntax evolving (including destructuring assignment or `let` block-scoped bindings)
As much as I like google I really don't want to go to yet another language. I rather focus on building content rather than have to maintain my page in dart and in JavaScript because of fragmentation issues.
Dart compiles to JavaScript, and the language is pretty standard stuff, if you know any C style language you can pick it up quickly.
The compiled Javascript is an abomination.
That initial 17 KLOC Hello World was an abomination, but it isn't looking anywhere near as bad these days.
https://gist.github.com/1385015
https://gist.github.com/1385015
The article is laughable. Microsoft itself is an important reason to develop Dart to begin with. MS has EEE'd html/js/css with IE 5.5 and up, and developed .NET to offer a competitive (proprietary) platform. We can't use C# although it's open, because MS is acting as a patent troll.
Do you live in the 90s? If Microsoft attempted to EEE HTML, Javascript, and CSS with IE5+, it's failed miserably, since the usage of both Chrome and Firefox continues to rise while IE stagnates or declines. You only have to follow the development of IE10 to realize the company knows it needs to play nicely with these technologies, whether it wants to or not.
Also, .NET was a response to Java, and while Silverlight and WPF were attempts to develop competing technologies to Flash and HTML/Javascript/CSS that also seems to have failed, since HTML and JS are key elements of the Metro UI for Windows 8.
In addition, Microsoft's actions against Android, while despicable, are hardly different than what most other tech companies are doing, so it's best to focus on the broken patent system. Finally, C# (and CLI) is a standard owned by the ECMA, so Microsoft can't sue you if you write a compiler and library from scratch.
That previous attempts failed does not mean they quit trying. IE9/10 does show some goodwill, but also shows the are still in the EEE game. Take for example the hardware accelerated canvas: Several (non-MS) websites had "optimized for IE" marketing campaigns. Such optimization is nonsense when using standards. Also, MS publicly stated WebGL has security problems because of direct access to the shaders. However, they forget to mention Silverlight has the exact same problem.
> In addition, Microsoft's actions against Android, while despicable, are hardly different than what most other tech companies are doing,
Eh, no. It's true more patent trolls exist, but not many companies in the industry try to enforce software patents.
About C#: Microsoft has stated several times that open is not the same as patent-free. They did so in context of Linux/Android, but also in the context of .net. Also, anaylis exist where C# tech is tied to patents.
> In addition, Microsoft's actions against Android, while despicable, are hardly different than what most other tech companies are doing,
Eh, no. It's true more patent trolls exist, but not many companies in the industry try to enforce software patents.
About C#: Microsoft has stated several times that open is not the same as patent-free. They did so in context of Linux/Android, but also in the context of .net. Also, anaylis exist where C# tech is tied to patents.
> That previous attempts failed does not mean they quit trying. IE9/10 does show some goodwill, but also shows the are still in the EEE game. Take for example the hardware accelerated canvas: Several (non-MS) websites had "optimized for IE" marketing campaigns. Such optimization is nonsense when using standards. Also, MS publicly stated WebGL has security problems because of direct access to the shaders. However, they forget to mention Silverlight has the exact same problem.
Cool story, bro. Most people these days either use the browser that comes with the OS, or install the one they want.
> Eh, no. It's true more patent trolls exist, but not many companies in the industry try to enforce software patents.
Really? Did you forget that Oracle started a lawsuit against Google for the usage of Java within Android? Or how about Apple's lawsuit against Samsung for the look and feel of the Galaxy Tablet? How about i4i's lawsuit against Microsoft?
> Eh, no. It's true more patent trolls exist, but not many companies in the industry try to enforce software patents.
[Citation needed]
From Wikipedia: The C# language definition and the CLI are standardized under ISO and Ecma standards that provide reasonable and non-discriminatory licensing protection from patent claims.
You seem to have a hard time differentiating the language, C# from the library, .NET. It's similar to C++ and the STL.
Cool story, bro. Most people these days either use the browser that comes with the OS, or install the one they want.
> Eh, no. It's true more patent trolls exist, but not many companies in the industry try to enforce software patents.
Really? Did you forget that Oracle started a lawsuit against Google for the usage of Java within Android? Or how about Apple's lawsuit against Samsung for the look and feel of the Galaxy Tablet? How about i4i's lawsuit against Microsoft?
> Eh, no. It's true more patent trolls exist, but not many companies in the industry try to enforce software patents.
[Citation needed]
From Wikipedia: The C# language definition and the CLI are standardized under ISO and Ecma standards that provide reasonable and non-discriminatory licensing protection from patent claims.
You seem to have a hard time differentiating the language, C# from the library, .NET. It's similar to C++ and the STL.
> Cool story, bro. Most people these days either use the browser that comes with the OS, or install the one they want.
This does not refute in an way that MS quit the EEE game. Merely, you seem to troll me ("Cool story, bro.").
> Really? Did you forget that Oracle started a lawsuit against Google for the usage of Java within Android? Or how about Apple's lawsuit against Samsung for the look and feel of the Galaxy Tablet? How about i4i's lawsuit against Microsoft?
Exactly, a few big fish and some smaller pure trolls. I am not aware of industrywide patent enforcement. There are thousands, if not tens of thousands of IT companies, who don't pursue software patents let alone enforce if they have.
> [Citation needed]
I am not aware of industrywide patentfights regarding software patents. Telecom companies do battle each other ferociously over patents, which are not necessarily for software (from what I read, not relatively many software patents are involved).
> From Wikipedia: The C# language definition and the CLI are standardized under ISO and Ecma standards that provide reasonable and non-discriminatory licensing protection from patent claims.
If MS decides to sue they decide to sue.
This does not refute in an way that MS quit the EEE game. Merely, you seem to troll me ("Cool story, bro.").
> Really? Did you forget that Oracle started a lawsuit against Google for the usage of Java within Android? Or how about Apple's lawsuit against Samsung for the look and feel of the Galaxy Tablet? How about i4i's lawsuit against Microsoft?
Exactly, a few big fish and some smaller pure trolls. I am not aware of industrywide patent enforcement. There are thousands, if not tens of thousands of IT companies, who don't pursue software patents let alone enforce if they have.
> [Citation needed]
I am not aware of industrywide patentfights regarding software patents. Telecom companies do battle each other ferociously over patents, which are not necessarily for software (from what I read, not relatively many software patents are involved).
> From Wikipedia: The C# language definition and the CLI are standardized under ISO and Ecma standards that provide reasonable and non-discriminatory licensing protection from patent claims.
If MS decides to sue they decide to sue.
> This does not refute in an way that MS quit the EEE game. Merely, you seem to troll me ("Cool story, bro.").
I'm trolling you because the claim that MS is trying to EEE HTML/JS/CSS by implementing hardware support for rendnering in IE is inane. Both Chrome and Firefox have the same capabilities, and I've seen more that one site (I actually use IE9 for specific reasons) that usually point me towards the usual bunch.
>Exactly, a few big fish and some smaller pure trolls. I am not aware of industrywide patent enforcement. There are thousands, if not tens of thousands of IT companies, who don't pursue software patents let alone enforce if they have.
So what in your mind makes Apple and Oracle different from Microsoft? If not, just concede the point: hating the players is pointless, the game is broken.
> If MS decides to sue they decide to sue. Your point here is? Sure, if I implemented C# according to the standard and my own set of libraries, the company could try to sue me. I am positive they wouldn't get very far. But continue on with your Stallman like conspiracy theories.
I'm trolling you because the claim that MS is trying to EEE HTML/JS/CSS by implementing hardware support for rendnering in IE is inane. Both Chrome and Firefox have the same capabilities, and I've seen more that one site (I actually use IE9 for specific reasons) that usually point me towards the usual bunch.
>Exactly, a few big fish and some smaller pure trolls. I am not aware of industrywide patent enforcement. There are thousands, if not tens of thousands of IT companies, who don't pursue software patents let alone enforce if they have.
So what in your mind makes Apple and Oracle different from Microsoft? If not, just concede the point: hating the players is pointless, the game is broken.
> If MS decides to sue they decide to sue. Your point here is? Sure, if I implemented C# according to the standard and my own set of libraries, the company could try to sue me. I am positive they wouldn't get very far. But continue on with your Stallman like conspiracy theories.
Some people working for Google pointed similar thoughts even before the launch of Dart, too.
This is only from my own experience but I'm consistently blown away by how little people actually know of JavaScript. Between interviews and looking at samples attached to jQuery Mobile issues all day I get the impression that most people don't know how to use the prototype system at all and generally organize their code as a series of jQuery event bindings.
While this isn't necessarily and endorsement of Dart, I welcome anything that can provide/encourage well-known and sane code reuse patterns.