Anders Hejlsberg and Lars Bak: TypeScript, JavaScript, and Dart(channel9.msdn.com)
channel9.msdn.com
Anders Hejlsberg and Lars Bak: TypeScript, JavaScript, and Dart
http://channel9.msdn.com/Shows/Going+Deep/Anders-Hejlsberg-and-Lars-Bak-TypeScript-JavaScript-and-Dart
10 comments
Lars Bak: To contrast these two languages, TypeScript is a safe bet... where Dart is trying to change some of the fundamental issues with JavaScript. I feel, from a computer science background, I still have problems that you can design applications with libraries where you can monkey patch the libraries when you get up running. I find that very, very disturbing when you are trying to write big applications. [with TypeScript] you end up in the same mess.
Anders Hejlsberg: Everything you say and more I will agree with. The question is not whether JavaScript is broken. The question is whether it is broken enough to merit being replaced by something else.
Anders Hejlsberg: Everything you say and more I will agree with. The question is not whether JavaScript is broken. The question is whether it is broken enough to merit being replaced by something else.
TypeScript is what Google Closure Compiler should have been; Closure’s static typing is similar but is much more tedious (you need to type 16 characters just to declare an int! https://developers.google.com/closure/compiler/docs/js-for-c...). I’m disappointed that nobody from Google Closure has stepped up to unify TypeScript and Closure’s syntax and to provide better tooling.
Can anyone explain what the difference between TypeScript and ECMAScript 4 are? I know ECMAScript 4 was abandoned for some reason, but from the few examples I've seen of Typescript it looks very similar. Did the js community just need a few more years to come around to the ideas?
ECMAScript 4 was implemented in ActionScript 3[1]; a very nice language to work with IMHO. The members of the ECMAScript steering group launched into a public fracas on their respective blogs[2] which eventually ended in the draft being canned, despite the fact both ActionScript and Silverlight were already based on the standard... shame.
[1] http://en.wikipedia.org/wiki/ActionScript#ActionScript_3.0
[2] http://blogs.msdn.com/b/ie/archive/2007/10/30/ecmascript-3-a...
[1] http://en.wikipedia.org/wiki/ActionScript#ActionScript_3.0
[2] http://blogs.msdn.com/b/ie/archive/2007/10/30/ecmascript-3-a...
> The second system syndrome is that evil effect that often happens when redesign a small, working system so that it becomes a huge leviathan built by piling new features over new features.
> Today I was reading the overview of ECMASCript 4 from ecmascript.org, and I got this very bad feeling that maybe the fourth version of ES, is suffering of an extremely strong case of this problem.
Imagine we had ES4 and HTML5 today. Nobody would be complaining about how much javascript sucks , and there would be no need for typescript, coffeescript ,etc ...
actually, it's my words[0] :)
I wrote it many years ago, but if you think it's wrong I'd be happy to understand why.
I have never been against Flash nor ActionScript(which I don't know enough to criticize) but my understanding was that ES4 was vastly more complex than even AS ever was, rather than being an incremental change as ES6 is.
And please note I wrote
""" ECMAScript 4 seems cool, I want to use a lot of those things (yay for multi method dispatch!), but maybe it is changing the language a little bit too much . """
And I wish I could influence what the dev world does, but I believe it is unlikely.
[0] http://www.riffraff.info/2007/10/25/ecmascript-4-the-fourth-...
I wrote it many years ago, but if you think it's wrong I'd be happy to understand why.
I have never been against Flash nor ActionScript(which I don't know enough to criticize) but my understanding was that ES4 was vastly more complex than even AS ever was, rather than being an incremental change as ES6 is.
And please note I wrote
""" ECMAScript 4 seems cool, I want to use a lot of those things (yay for multi method dispatch!), but maybe it is changing the language a little bit too much . """
And I wish I could influence what the dev world does, but I believe it is unlikely.
[0] http://www.riffraff.info/2007/10/25/ecmascript-4-the-fourth-...
Probably you've seen examples of ES6 which is actively developed now, and many features from it are already available in firefox nightlies. ES4 was abandoned 3-4 years ago. It was partially implemented in firefox, and ff addons used it. One of it's features that didn't made into ES6 was inline xml inside javascript. It was recently removed from firefox.
It looks very much like ECMAScript 4. I've done a lot (too much) Flex/AS3 coding and I plan on using TypeScript for my next big Javascript project. Static type checking makes a whole class of problems on large applications just go away.
ES4 ~= Action Script (with packages , classes , interfaces ,etc...)
The problem with typescript is that there is no real built-in module support you either need AMD or CommonJS that's why i wont use it.
The language is great but i dont want to have to use requireJS to create reusable components.
Funny how Microsoft rejected ES4 and now is "praising" and "advocating" for better web scripting language. That's hypocrisy.
The problem with typescript is that there is no real built-in module support you either need AMD or CommonJS that's why i wont use it.
The language is great but i dont want to have to use requireJS to create reusable components.
Funny how Microsoft rejected ES4 and now is "praising" and "advocating" for better web scripting language. That's hypocrisy.
Afaik tsc can also compile to CoffeeScript-style modules if asked.
I feel like Dart's emphasis on a fast but chrome-only vm has hindered it's adoption. I understand their goal, unlike most compile-to-js languages, was a language more amenable to fast implementation. However, I think the initial community reaction would have been more positive if Dart was positioned first as a language that compiled to js, with the added benefit that it runs significantly faster on Chrome.
> I feel like Dart's emphasis on a fast but chrome-only vm has hindered it's adoption.
Dart's VM isn't Chrome-only, its open source, and available both standalone and bundled into Chromium.
> However, I think the initial community reaction would have been more positive if Dart was positioned first as a language that compiled to js, with the added benefit that it runs significantly faster on Chrome.
Reaction might have been more positive in the short run if it was sold as a on-top-of-JS language rather than part of a long-term plan to build something to replace (or complement) JS as a language for which browsers would have a a built-in, language-specific VM. However, I think that even if initial reaction might have been better with such a response, Google clearly did the right thing by being up front about their vision.
Dart's VM isn't Chrome-only, its open source, and available both standalone and bundled into Chromium.
> However, I think the initial community reaction would have been more positive if Dart was positioned first as a language that compiled to js, with the added benefit that it runs significantly faster on Chrome.
Reaction might have been more positive in the short run if it was sold as a on-top-of-JS language rather than part of a long-term plan to build something to replace (or complement) JS as a language for which browsers would have a a built-in, language-specific VM. However, I think that even if initial reaction might have been better with such a response, Google clearly did the right thing by being up front about their vision.
> Dart's VM isn't Chrome-only
I meant that dart is chrome-only in practice. I don't know of any other browser vendor that bundles the dart vm, including the few browsers based on chromium like rockmelt or 360.
> However, I think that even if initial reaction might have been better with such a response, Google clearly did the right thing by being up front about their vision.
I can appreciate Google's directness regarding Dart's intention. However, from a web developer's perspective, Dart's multiple backends is very unappealing. I hesitate to adopt even a language like clojurescript or coffeescript because of debugging barriers and potential bugs in the language's crevices (though these problems are diminishing with things like source map support).
I meant that dart is chrome-only in practice. I don't know of any other browser vendor that bundles the dart vm, including the few browsers based on chromium like rockmelt or 360.
> However, I think that even if initial reaction might have been better with such a response, Google clearly did the right thing by being up front about their vision.
I can appreciate Google's directness regarding Dart's intention. However, from a web developer's perspective, Dart's multiple backends is very unappealing. I hesitate to adopt even a language like clojurescript or coffeescript because of debugging barriers and potential bugs in the language's crevices (though these problems are diminishing with things like source map support).
> I meant that dart is chrome-only in practice. I don't know of any other browser vendor that bundles the dart vm, including the few browsers based on chromium like rockmelt or 360.
I didn't think even Chrome bundles Dart, yet, either; for native Dart (as opposed to compiled-to-JS Dart), Google distributes (both separately and with the Dart SDK) a special Chromium-based browser with the Dart VM integrated called "Dartium".
For all practical short-term purposes, Dart is another compiled-to-JavaScript language, and is no more plagued by multiple backends than JavaScript (which, after all, runs on multiple different engines from different vendors) is.
And I don't see how having an optimized VM in development makes it less attractive than compiled-to-JS languages that don't have that.
> However, from a web developer's perspective, Dart's multiple backends is very unappealing. I hesitate to adopt even a language like clojurescript or coffeescript because of debugging barriers and potential bugs in the language's crevices (though these problems are diminishing with things like source map support).
I would think the fact that Dart is -- rather overtly -- immature and rapidly changing would be a much bigger barrier to adoption by relatively conservative, need-something-that-works-now, web developers. I don't see how having an experimental optimized VM available-but-not-widely-available-to-end-users factors in to making it less attractive to web developers.
I didn't think even Chrome bundles Dart, yet, either; for native Dart (as opposed to compiled-to-JS Dart), Google distributes (both separately and with the Dart SDK) a special Chromium-based browser with the Dart VM integrated called "Dartium".
For all practical short-term purposes, Dart is another compiled-to-JavaScript language, and is no more plagued by multiple backends than JavaScript (which, after all, runs on multiple different engines from different vendors) is.
And I don't see how having an optimized VM in development makes it less attractive than compiled-to-JS languages that don't have that.
> However, from a web developer's perspective, Dart's multiple backends is very unappealing. I hesitate to adopt even a language like clojurescript or coffeescript because of debugging barriers and potential bugs in the language's crevices (though these problems are diminishing with things like source map support).
I would think the fact that Dart is -- rather overtly -- immature and rapidly changing would be a much bigger barrier to adoption by relatively conservative, need-something-that-works-now, web developers. I don't see how having an experimental optimized VM available-but-not-widely-available-to-end-users factors in to making it less attractive to web developers.
Dart has special data types for the VM. They clearly want to target the VM for fast applications that aren't very usable compiled to JavaScript.
> Dart has special data types for the VM.
It has optional types, like many compiled-to-JS languages (as lack of declared types is one of the motivations for such languages.) I don't know what you mean by "special data types for the VM". Can you provide some examples?
> They clearly want to target the VM for fast applications that aren't very usable compiled to JavaScript.
Obviously, they think that the VM will provide some benefit over compiling to JS or they wouldn't make the effort of building the VM. But, unless you can give a reason to believe that they are crippling the performance of Dart-to-JS code to push the VM, I can't see why that would be a problem.
It has optional types, like many compiled-to-JS languages (as lack of declared types is one of the motivations for such languages.) I don't know what you mean by "special data types for the VM". Can you provide some examples?
> They clearly want to target the VM for fast applications that aren't very usable compiled to JavaScript.
Obviously, they think that the VM will provide some benefit over compiling to JS or they wouldn't make the effort of building the VM. But, unless you can give a reason to believe that they are crippling the performance of Dart-to-JS code to push the VM, I can't see why that would be a problem.
Okay, so you are talking about exposing integer vs. double distinction (because CPUs are better at int math) and the SIMD support in the Dart VM.
All of those are using explicit typing to do better at mapping from what the developer does to what the native hardware supports than is possible without explicit types in JS, sure. I don't see why this is a bad thing -- its not sacrificing performance in Dart-to-JS implementations that would be attainable, its just taking advantage of not being stuck with JavaScript's lack of types to further optimize the performance of Dart-on-its-own-VM.
All of those are using explicit typing to do better at mapping from what the developer does to what the native hardware supports than is possible without explicit types in JS, sure. I don't see why this is a bad thing -- its not sacrificing performance in Dart-to-JS implementations that would be attainable, its just taking advantage of not being stuck with JavaScript's lack of types to further optimize the performance of Dart-on-its-own-VM.
The Dart VM being faster than JavaScript can be a problem in itself. But with SIMD you'll get a lot of "Only usable in Dart VM" for a lot of apps (mainly games) written in Dart, because then the necessary speed for many game operations gets possible.
I don't want back to the "Best viewed in IE 5.5 and 1024x768 Pixels" times.
I don't want back to the "Best viewed in IE 5.5 and 1024x768 Pixels" times.
> The Dart VM being faster than JavaScript can be a problem in itself. But with SIMD you'll get a lot of "Only usable in Dart VM" for a lot of apps (mainly games) written in Dart, because then the necessary speed for many game operations gets possible.
Yes, building performance improvements into the Dart VM that go beyond something that is found in most JS engines means that there is the possibility that (given equivalent hardware) some things that peform acceptably on the Dart VM won't perform acceptably when relying on Dart-2-JS.
Which would be a problem if there was a barrier to other browser vendors incorporating the Dart VM, or adapting it to platforms that Google doesn't support. But there's not, and the whole point of Dart -- and why there is a Dart VM -- is because Dart is an effort to provide an alternative to JavaScript, with dart2js as a mechanism to make development in Dart useful even before Dart VM adoption takes off.
But dart2js isn't the long-term goal, its a tool to get passed the problem that without runtime deployment, no one will develop, and without development, no one will deploy the runtime.
> I don't want back to the "Best viewed in IE 5.5 and 1024x768 Pixels" times.
And I don't want the web to stagnate because we can't do anything that might work better than what exist now.
Good thing about new efforts being open is that they avoid both problems.
Yes, building performance improvements into the Dart VM that go beyond something that is found in most JS engines means that there is the possibility that (given equivalent hardware) some things that peform acceptably on the Dart VM won't perform acceptably when relying on Dart-2-JS.
Which would be a problem if there was a barrier to other browser vendors incorporating the Dart VM, or adapting it to platforms that Google doesn't support. But there's not, and the whole point of Dart -- and why there is a Dart VM -- is because Dart is an effort to provide an alternative to JavaScript, with dart2js as a mechanism to make development in Dart useful even before Dart VM adoption takes off.
But dart2js isn't the long-term goal, its a tool to get passed the problem that without runtime deployment, no one will develop, and without development, no one will deploy the runtime.
> I don't want back to the "Best viewed in IE 5.5 and 1024x768 Pixels" times.
And I don't want the web to stagnate because we can't do anything that might work better than what exist now.
Good thing about new efforts being open is that they avoid both problems.
You're complaining about more speed? Why don't we see the same complaints with asm.js?
If SIMD on Dart works out well, you can bet JS will get SIMD support too, and then dart2js will use that. It's this type of competition that pushes things forward.
If SIMD on Dart works out well, you can bet JS will get SIMD support too, and then dart2js will use that. It's this type of competition that pushes things forward.
Games often require special platforms. They're not web pages in the strict sense.
Interesting. I need Google Chrome to view these slides. (Doesn't work in Firefox 20 Beta.)
I doubt they are expecting Apple and Microsoft to incorporate the Dart VM, so they are putting a lot of effort into the JavaScript output. The Dart VM really comes into play in the near future for Chrome Packaged Apps. They interesting thing is loading snap shots of the virtual machine state quickly.
http://www.infoq.com/articles/google-dart
Date of the article: Oct 24, 2011
Thanks for catching that. Snapshots are still being worked on. Here's Feb 2013 info. http://www.dartlang.org/articles/snapshots/
Dart is Google's Silverlight.
A couple of clarifications:
* Dart compiles to JavaScript, Silverlight did not. * Dart is actively being developed, Silverlight is not. * Dart does not require any plugins, Silverlight did. * Dart natively supports the DOM, Silverlight did not.
[disclaimer: I work on the Dart team]
* Dart compiles to JavaScript, Silverlight did not. * Dart is actively being developed, Silverlight is not. * Dart does not require any plugins, Silverlight did. * Dart natively supports the DOM, Silverlight did not.
[disclaimer: I work on the Dart team]
ActionScript/Flash and .NET/SilverLight require a plugin, with Dart the "plugin" is optional.
It's called the Dart Runtime which is not included in non Google browsers.
Except:
1. The Dart VM isn't included in Google's generally-released browsers, either (it's included in Dartium, the special version of Chromium bundled with the Dart SDK).
2. The Dart VM isn't a plug-in.
3. As Dart compiles to JS, you don't need the Dart VM to run code developed with Dart, you just need a browser that supports JS.
Anything really new would be like that. WebGL was also Firefox-only for a while, until Chrome decided to adopt it. To make them a standard across browsers you either need to make them very popular, and make the others have no choice but adopting it, or collaborating. But the last one seems to happen less and less lately, with all companies.
I disagree. There's more cooperation because things are getting more complicated and it's necessary.
http://www.webplatform.org/stewards/
http://www.webplatform.org/stewards/
I agree. They stumbled initially because the "hello world" JavaScript output was something huge (17,000 LOC if I remember correctly.) But I think they are recovering nicely and people will notice.
That was unfortunate, mostly because a single compiler flag brought the code base way down, smaller the JQuery. If I recall correctly, that mistake was from a blogger, not Google, but it caught the bad publicity winds. Somebody was more eager to tear it apart than learn the tools.
Dart is great and I like how they are focusing on making it fast and creating a special VM for it (dartium, although it compiles to javascript, too). It's tempting to target a compiler to generate dart code, too, instead of javascript. But there is one deal breaker for me - dart can't compile locally in the browser (even a dartium one). It requires a server or else compiling off-line (same issue with Closure Compiler, too). You can't code a dart app on a chromebook, for example (unless you use remote desktop or install ubuntu on it). The future to me is doing all development work in the browser, and only connecting to the server for the server components or version control, like with c9.io and other browser-based IDEs. Even Eclipse has a browser-based version now - Orion.
It's not a huge deal - there are over a hundred alternative languages that compile to javascript out there now, many of which do support compiling in the browser: https://github.com/jashkenas/coffee-script/wiki/List-of-lang...
It's not a huge deal - there are over a hundred alternative languages that compile to javascript out there now, many of which do support compiling in the browser: https://github.com/jashkenas/coffee-script/wiki/List-of-lang...
> dart can't compile locally in the browser
dart2js is written in Dart. There's some small amount of work needed to self-host it and run the result in a browser, mainly swapping out the file IO API with something that works on the web. I think multiple people on the team have slapped together working examples of this, so it's not a lot of work.
It isn't a high priority for the dart2js team right now, though, and they are very careful to avoid taking on responsibility for features or use cases that don't have solid tests. I think before too long, we will have a reliably self-hosted Dart->JS compiler that runs in a browser, we're just focused on other stuff for the moment.
dart2js is written in Dart. There's some small amount of work needed to self-host it and run the result in a browser, mainly swapping out the file IO API with something that works on the web. I think multiple people on the team have slapped together working examples of this, so it's not a lot of work.
It isn't a high priority for the dart2js team right now, though, and they are very careful to avoid taking on responsibility for features or use cases that don't have solid tests. I think before too long, we will have a reliably self-hosted Dart->JS compiler that runs in a browser, we're just focused on other stuff for the moment.
Dart source is run by the Dart engine similarly to how JavaScript is run by the JavaScript engine, so you should be able to edit Dart source in a browser and run it if that browser includes the Dart VM (Dartium).
[deleted]
It's a pretty smart move that Microsoft did with TypeScript, making it a proper superset of JavaScript. Google seems to be stuck in the past, bringing out its own VM that is a complete non-starter, and making another class-based, Java-like language. I guess Google is going down the road that Microsoft did years ago with flinging feces on the wall and see what sticks.
I have nothing against Dart. I played with it a year and a half ago when the Eclipse beta came out. It's nice tooling, but brings absolutely nothing interesting to the table.
I have nothing against Dart. I played with it a year and a half ago when the Eclipse beta came out. It's nice tooling, but brings absolutely nothing interesting to the table.
Yesterday, I rewrote one of my JS modules into Dart, and it ended up being about 10 lines of code with only two modules imported. Then I compiled it to JS, and it was over 120k. I tried for about an hour to get that down to a reasonable size with Closure Compiler/Uglify, but the names were too wonky.
I'm sure that, given enough time, they'll solve these problems, but as for right now... it isn't ready for primetime. Not by a longshot.
I'm sure that, given enough time, they'll solve these problems, but as for right now... it isn't ready for primetime. Not by a longshot.
You don't say if you used the 'dart2js --minify' setting, but Closure Compiler should do well. The --minify flag leaves alot more room for additional minification. You say you used two modules. The result really depends on the modules. For example, the Dart/JS interop module adds about 140K un-minified. Tree shaking is always on, so the 140K is after stripping unused code. I initially jumped into Dart because I was interested in doing packaged apps that run locally, so the size over the wire didn't concern me as much. I recently converted an ActionScript app to Dart and the post-minify Dart was around the same size as the compiled .swf file (for comparison, same functionality)
Seth Ladd has a couple of posts about Tree Shaking and Minification if you're interested http://blog.sethladd.com/2013/01/minification-is-not-enough-... http://blog.sethladd.com/2013/03/i-shrunk-my-dart-to-js-code...
Seth Ladd has a couple of posts about Tree Shaking and Minification if you're interested http://blog.sethladd.com/2013/01/minification-is-not-enough-... http://blog.sethladd.com/2013/03/i-shrunk-my-dart-to-js-code...
> You don't say if you used the 'dart2js --minify' setting
I did. I'm no stranger to Closure Compiler, and even after fiddling around with ADVANCED_OPTIMIZATIONS for an hour, those ridiculous $variables persisted. What was even weirder was, just as a test, I imported a module I wasn't even using at all, and for some reason, Closure Compiler still refused to remove its code...
I did. I'm no stranger to Closure Compiler, and even after fiddling around with ADVANCED_OPTIMIZATIONS for an hour, those ridiculous $variables persisted. What was even weirder was, just as a test, I imported a module I wasn't even using at all, and for some reason, Closure Compiler still refused to remove its code...
Just for grins, I compiled the Dart app I'm working on now with --minify. It went from 530K to 240K. Then I cleared the --minify flag and used the Closure Compiler but it failed with errors. Not sure what is going on yet, but I don't think this is necessary or advisable -- I've never read of anyone using the Closure Compiler with Dart. Here is a sample few lines from --minify. It's fairly minimal.
function I(){} init() var $=I.p var $$={}
function I(){} init() var $=I.p var $$={}
Okay, but um, why did minify not get rid of the module i wasn't even using?
Just to be clear, here is what I did.
Dart source -> dart2js -> JavaScript (530K)
Dart source -> dart2js -> JavaScript (530K) -> Closure Compiler -> *error*
Dart source -> dart2js --minify -> JavaScript (240K)
--minify is still being improved and is not complete yet. As well, you need to say what libs you included. If you import "HTML" it is basically like including jquery.
Right, but the great thing about a compiled language like Dart is that it can detect at compile-time which modules aren't being used and then exclude those from the js output. Except, it doesn't seem to ever do that.
EDIT: Well, technically, Dart is actually designed to be interpreted (or JIT compiled, or what have you) by the Dart VM, so calling it a "compiled language" was incorrect on my part. However, dart2js is a compiler, so, it should be doing compiler-y shit.
EDIT: Well, technically, Dart is actually designed to be interpreted (or JIT compiled, or what have you) by the Dart VM, so calling it a "compiled language" was incorrect on my part. However, dart2js is a compiler, so, it should be doing compiler-y shit.
Tree-shaking is the term for removal of uncalled functions. The minifier is still early on so expect it to get better with time.
I think of the Dart VM as a dev tool. The goal is to use dart2js for production output. The Dart VM will eventually be very useful in Chrome Packaged Apps once Chrome has it built in. Google has a ton of experience with Google Web Toolkit to write JavaScript apps such as Gmail in Java. Dart is branch of that evolution. I am not even sure if they care all that much if the rest of use it. It seems to me an internal tool that they've open sourced. I see no plans to force it on the market.
Haxe anyone ? full HTML5 api support , dead-code elimination, loads of libraries and frameworks , easy integration with third party libraries ,multi-target (C++,Flash,JS,...) and open source...
Well, Haxe seems squarely aimed at the game sector, first with Flash, now with HTML5. There are quite a few possibilities, but I don't really see a big movement towards the "normal" web application area, even the nodejs/C++/Neko web wrappers seem a bit oriented towards providing backends for games. I'm not asking for Haxe's equivalent to Rails, but something like flask, sinatra, express or compojure would be nice. (Supported, with some mindshare behind it -- I'm aware that there are a few fledgling webapp frameworks on github)
Not that the game has been called, Typescript and Dart themselves have been out for a while and don't really took large slices of the pie. The biggest "transpiled" Javascript language is still Coffeescript, and that's basically Ratfor for the web.
There's also Opa and Fantom, if we're going even more esoteric...
( http://fantom.org/ and http://opalang.org/ )
Not that the game has been called, Typescript and Dart themselves have been out for a while and don't really took large slices of the pie. The biggest "transpiled" Javascript language is still Coffeescript, and that's basically Ratfor for the web.
There's also Opa and Fantom, if we're going even more esoteric...
( http://fantom.org/ and http://opalang.org/ )
Haxe 3 is just around the corner, the RC is out right now.
http://haxe.org/manual/haxe3/features
Not sure why it doesn't get more love here, it's awesome for developing complex js libraries, in addition to what you can do server side, and/or on a mobile platform.
Not sure why it doesn't get more love here, it's awesome for developing complex js libraries, in addition to what you can do server side, and/or on a mobile platform.
It's unfortunate that Haxe doesn't get the recognition it deserves. The type system and other features blow anything comparable out of the water.
The language and compiler are solid, what it needs is better documentation, getting started guides, and tooling for things other than games with NME.
The language and compiler are solid, what it needs is better documentation, getting started guides, and tooling for things other than games with NME.
Stop trying to make Haxe happen, it's not going to happen.
I've been wondering whether I should start using this language for a project, and almost every time there's a good reason not too, but I'm still thinking one day there won't and i will.
I'm curious to know what makes you think it will never happen, though.
It tries to be too many things to too many people, can't do a good enough job on any of it. Not really worth the investment.
haxe has flaws , but haxe is not backed by windows nor google. The team is 3/4 developers and they did a great work. Haxe will grow in the future. All it needs is a better "PR" and a bit of hype. A lot of successfull projects have been made with haxe.
To me this interview underlines the accomplishment of CoffeeScript.
No committees. No marketing team. No developer evangelists. No PR team. No corporate interests. No budget.
Just code.
No committees. No marketing team. No developer evangelists. No PR team. No corporate interests. No budget.
Just code.
Also nobody with the sense of history to design proper lexical scoping of variables.
This has been covered over, and over, and over again. CoffeeScript has some explicit goals with respect to the generated JavaScript output, and that includes not mucking with your identifiers. In order to implement correct lexical scoping, you'd need to rewrite identifiers to avoid shadowing and collision. CoffeeScript's design is a very reasonable trade off given the inadequacies of JavaScript.
To achieve that CS would have had to put everything with a new variable inside a new function scope, having a major impact on performance and readability of the generated code.
...No formal semantic or syntactic specification...
Anders Hejlsberg: Everything you say and more I will agree with. The question is not whether JavaScript is broken. The question is whether it is broken enough to merit being replaced by something else.