Live data from Hacker News

JSX - a faster, safer, easier alternative to JavaScript

jsx.github.com

31–40 of 73 posts

Re: JSX - a faster, safer, easier alternative to JavaScript

#31
> 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.

Re: JSX - a faster, safer, easier alternative to JavaScript

#32
post #6

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

I was hoping it was because they allowed `(x, y, z: int)` as syntax sugar (like OOC does)... but no, they don't. In that case the : is a bit pointless.

Re: JSX - a faster, safer, easier alternative to JavaScript

#33

Earlier quoted context omitted.

Just as you said yourself: classes can be simulated with prototypes and are therefore higher level than prototypes. In other words, prototypes are lower level (more primitive) than classes.

The Gameboy color hardware can be simulated on a desktop computer in a browser, in javascript. Does that make desktop computers more primitive than Gameboys?

@viraptor and so we can see that we must take into account more than just whether one can be simulated on another, we must take into account /expressiveness/, or level of complexity as well! In theory, you could simulate prototypes with classes too. You have to be able to, or else it wouldn't be possible to write an interpreter for a language which supports prototypes. The question of "can" and "can't" then, in the context of my original question has to do with the level of difficulty in doing one or the other. Now that we've got this far, what is more difficult- simulating classes with prototypes, or simulating prototypes with classes? Which requires more code, and more complexity? And from that, what do we conclude about primitiveness?

Re: JSX - a faster, safer, easier alternative to JavaScript

#34
post #6

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

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

Re: JSX - a faster, safer, easier alternative to JavaScript

#36

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

There are certain javascript constructs and memory usage strategies which are known to harm performance- and a compiler can ensure that your code does not use any of these constructs. While you can't make this claim for any arbitrary code, it's not completely absurd.

Re: JSX - a faster, safer, easier alternative to JavaScript

#37

> (...) 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…

As a former contributor to Box2DX, I'm impressed with your knowledge of the state of Box2D ports, did you contribute to one of them?

Re: JSX - a faster, safer, easier alternative to JavaScript

#38
post #35

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

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.

Re: JSX - a faster, safer, easier alternative to JavaScript

#39

Earlier quoted context omitted.

The Gameboy color hardware can be simulated on a desktop computer in a browser, in javascript. Does that make desktop computers more primitive than Gameboys?

@viraptor and so we can see that we must take into account more than just whether one can be simulated on another, we must take into account /expressiveness/, or level of complexity as well! In theory, you could simulate prototypes with classes too. You have to be able to, or else it wouldn't be possible to write an interpreter for a language which supports prototypes. The question of "can" and "can't" then, in the c…

I'd still stand by the opinion that the browser in GBA is the same level of complexity as GBA in browser. They're interpreters of some code essentially (one of GBA roms, the other of html/js). There is of course a different human complexity of "how hard would it be to implement"... but if we're adding JS engine to the mix, the browser may be actually harder.

With classes / prototypes (sorry for wibbly wobbly explanation, my CS is not good enough to use the proper terms, which probably exist out there), you can pretend there's a "behaves like" relationship. To simulate a prototype using a class you have to build the freely accessible dictionary and initialisation/cloning semantics level inside of the class.

To simulate classes using a prototype... that depends on your definition of a class. Dynamic dispatch is already there, encapsulation too, subtypes just need a field specifying the name and cloning the right prototype, inheritance is on by default. Self-referencing is usually in there too.

So in my opinion classes can be substituted by prototypes in a large number of cases. Classes however need another layer on top to act like prototypes. So prototypes look like more primitive than classes and classes look like a special-cased version of prototypes. Then again, it's late here, so maybe I missed something obvious...

Re: JSX - a faster, safer, easier alternative to JavaScript

#40

> (...) 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…

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.

Post reply on HN