
JSX - a faster, safer, easier alternative to JavaScript - frsyuki
http://jsx.github.com/
======
phoboslab
> (...) even the optimized JavaScript libraries like Box2D becomes faster when
> ported to JSX.

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.

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.

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.

[1] There are several different JS ports of Box2D available, but, to my
knowledge, none of which is a sensible rewrite by a human.

~~~
reitzensteinm
You're definitely right about that.

Probably the biggest inefficiency with all the ports is that they don't pool
vectors. In the C++ version, vectors are often on the stack, which is way more
efficient. In JS, it creates large numbers of temporary vectors that must be
garbage collected.

For my iPad port of one of my Flash games (written in Haxe, so it was actually
being translated back into C++), I spent quite a few days profiling the places
that were vectors were being created the most, and modifying them to use a
pool.

Then some verification code in debug mode checked that there was never a dead
vector being written to or read from.

In pathological places with tons of collisions, that got the speed from 2 fps
to 30.

------
politician
"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."

Pass.

~~~
ZenPsycho
That's a weird thing to think. If you can simulate classes with prototypes,
but you can't simulate prototypes with classes, what is the natural conclusion
you can come to about which is more expressive or primitive?

~~~
fleitz
That prototypes are overly complex.

You can't simulate most imperative programs with functional ones because
writing in a functional language eliminates a vast majority of bugs due to
incomplete reasoning about memory barriers and other really hard to duplicate
issues like race conditions.

CHESS is an amazing piece of software precisely because it CAN simulate race
conditions and reproduce them, however, if these things didn't exist no one
would ever bother trying to reproduce them.

I'm quite fine not being able simulate these issues.

~~~
j_baker
I'm not saying you're wrong, but isn't this a bit like saying that files are
overly complex because they can be used to simulate sockets?

~~~
fleitz
It is, but on the other hand if you write code to work with sockets then you
get a performance boost on spinning disks because your IO is sequential. And
many other benefits like trivial cache prediction, buffering, etc.

I do think that prototypes have useful properties, but I'm not sure that a
prototype isn't a form of an open class. I tend to think that the biggest
problem with prototypes in js is the interface.

~~~
ZenPsycho
Prototypes in JS are problematic due to false cognates- it tried to look like
Java (due to marketing department fuckery), and use the same keywords as java,
but it doesn't act at all like Java which leads to some nasty surprises. This
has been fixed in ES5- the correct way to inherit from a prototype is no
longer via constructor functions and their prototype property, but via
Object.create()

------
HoLyVieR
> JSX performs optimization while compiling the source code to JavaScript. The
> generated code runs faster than an equivalent code written directly in
> JavaScript.

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.

~~~
tolmasky
CoffeeScript makes the exact same claim, right on their front page (emphasis
mine):

"The compiled output is readable and pretty-printed, passes through JavaScript
Lint without warnings, will work in every JavaScript runtime, _and tends to
run as fast or faster than the equivalent handwritten JavaScript._ "

This is not absurd at all, it has been a proposition made by many languages in
the past regarding their target. In fact it's kind of the whole point of an
_optimizing_ compiler. Whether its C being turned into better ASM than you'd
write by hand, or CoffeeScript being turned into better JavaScript than you'd
write by hand, the basic idea is the same. Of course you could theoretically
just write the better ASM/JavaScript/whatever yourself, but the point is that
usually how to do so is not obvious or not worth your time. If the average
programmer's output ends up more performant with your compiler, then the claim
is fair.

------
spyder
Haxe does the same and more: <http://haxe.org/>

~~~
chii
I can't believe no one has mentioned GWT in this whole thread.

------
franze
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.

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.

~~~
detst
The equivalent in Dart is:

    
    
      main() {
        print("hello world!");
      }
    

and you know the "17259 lines" thing is FUD.

EDIT: The above Dart code currently generates 445 lines of JS with comments
and readable formatting. Obviously it's not quite where it needs to be but
it's coming along quite well.

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

------
btipling
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.

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.

------
azinman2
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) & dynamic (e.g. write parsing code more
easily) typing is the future. This either/or approach is antithesis of what's
good in CS.

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

------
zenocon
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

~~~
deafbybeheading
ActionScript running directly in the browser could be interesting. It has some
cruft (much of it shared with JS due to the ECMAScript heritage), and the
ECMAScript lineage leads to some weird features (e.g., typically its class-
based inheritance is used, but it does include prototype inheritance), but
it's not a bad language.

~~~
nickmain
<http://www.jangaroo.net/home/>

------
berdon
function foo(bar : string) : string...

Why, why do we need unnecessary tokens?! Get rid of the stupid :'s.

~~~
RandallBrown
I agree We should also take periods out of sentences They aren't needed as
long as you capitalize the first letter of every sentence This makes things
much cleaner

~~~
Danieru
Odd, I had no problem reading your comment. It also has an unusual clean-ness.

Maybe period-less sentences are the future Throughout history english has
already had many typological changes From a DRY stand-point capitalization and
periods contain the same information payload Eliminating one of them would
thus be good software engineering Right?

~~~
ehsanu1
I didn't notice there were no periods till I finished reading and then had a
"hey, wait a second" glance back This is an experiment worth trying out: just
write everything in this style for a while

The main problem I see here is figuring out whether a new sentence has been
started when a Proper Noun or capitalized pronoun like "I" has been introduced
I provide the current sentence as an example of that It's not so hard to
figure out from context usually, but I'm sure there are easily constructed
cases where the meaning changes based on the period Then again, much of the
English language is like that

~~~
politician
"... been introduced I provide the ..."

I'll admit that I did a triple-take when reading through your example. Let's
keep periods. :)

~~~
ehsanu1
This is a cognitive problem. I also read you as doing a "double-take", even
though you clearly wrote "triple-take". Another cognition issue. The
unthinking mind reacting automatically without consulting our conscious. The
solution is obviously to augment our brains with computers. :)

------
netmau5
Faster: a language change is not worth performance < an order of magnitude.
Safer: unit tests; user input is only one type. Easier: prototypal inheritance
is not a bug.

Next language please.

