JSX - a faster, safer, easier alternative to JavaScript

&#62; (...) even the optimized JavaScript libraries like Box2D becomes faster when ported to JSX.<p>Box2D is a C++ library that has been ported to ActionScript and then, from ActionScript, converted to JavaScript - not by hand, but by a bunch of scripts[1]. The JS version of Box2D still carries around a lot of unnecessary weight from the original C++ and ActionScript versions and has much room for improvement.<p>A rewrite or "smart" conversion from C++ to JS, that endorses JS instead of trying to emulate C++ or ActionScript, should be able to improve performance a lot.<p>I don't know how Box2D was ported to JSX. Maybe it was a rewrite by a human? In any case, I'm not saying what they do isn't impressive, but calling Box2D an "optimized JavaScript library" is just plain wrong.<p>[1] There are several different JS ports of Box2D available, but, to my knowledge, none of which is a sensible rewrite by a human.

"JSX offers a solid class system much like the Java programming language, freeing the developers from working with the too-primitive prototype-based inheritance system provided by JavaScript."<p>Pass.

&#62; JSX performs optimization while compiling the source code to JavaScript. The generated code runs faster than an equivalent code written directly in JavaScript.<p>This is just absurd. It is claiming it will run faster than JavaScript ... by compiling to JavaScript. If generated JavaScript code would run faster, it just mean the JavaScript code could have been written better in the first place. They probably have logic optimization behind the scene, but clamming it will run faster that JavaScript is just ridiculous.

Haxe does the same and more: <a href="http://haxe.org/" rel="nofollow">http://haxe.org/</a>

the jsx source code of the "hello world" example is only 62.5% of the code needed by dart for the same example. 5 lines vs 8 lines of code.<p>the compiled JS source of the "hello world" example is only 0.5% of the code needed for the same task by dart. 91 lines vs 17259 lines code.

Static typing is nice, but does this support type inference?

Is it weird that I'm happy this site doesn't have a lot of pretty gradients and fancy art? For whatever reason I'm a little tired of too pretty sites related to JavaScript or other client side development. I think the reason for this is because I get the impression that the contributors emphasize trivial features and care more about artificial things, like a really opinionated interface but not a lot of innovation in performance.<p>It's like the bike shed concept. Anyone can paint a bike shed, but it takes real skill and hard work to build a decent one. It's great to have a nice coat of paint, but the accomplishment wasn't picking the color. That's how I feel about ember.js's website, and the website for all these other client side things with fancy buttons, large web fonts and gratuitous use of space. It's probably a pretty coat of paint, but I doubt I can get efficiently achieve 200,000 datastore operations with speed.

Looks quite good. Very similar to AS3, although it has the type inference of Scala. Nice. Either way something like this needs to exist to produce more robust code when creating large projects in Javascript. Google did this in using Java, but Java is overly restrictive. Being able to mix static (to a compilers checks + self-documentation) &#38; dynamic (e.g. write parsing code more easily) typing is the future. This either/or approach is antithesis of what's good in CS.

here is a recent hacker news thread about a very similar (and in my opinion much more interesting and useful) project called LLJS <a href="http://news.ycombinator.com/item?id=3965713" rel="nofollow">http://news.ycombinator.com/item?id=3965713</a>

Looks like ActionScript, which is already based off ECMAScript...why not just use that, or extend what's already there? Getting adoption for a brand new language is tough, plus there's already a ton of software/libraries/tools written in As3

function foo(bar : string) : string...<p>Why, why do we need unnecessary tokens?! Get rid of the stupid :'s.

Faster: a language change is not worth performance &#60; an order of magnitude. Safer: unit tests; user input is only one type. Easier: prototypal inheritance is not a bug.<p>Next language please.