JSX - a faster, safer, easier alternative to JavaScript

http://jsx.github.com/

by frsyuki • 14 years ago

53 69 14 years ago

jsx.github.com

politician4• 14 years ago

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

ZenPsycho17• 14 years ago

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?

ams6110• 14 years ago

http://javascript.crockford.com/prototypal.html

fleitz2• 14 years ago

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_baker2• 14 years ago

It would seem as though prototypes are the more expressive option if you can use them to simulate classes. In fact, one could argue that this is essentially what Python does.

...but the OP seemed to indicate that prototypes were "primitive", and it sounds like you agree with him. Are you trying to say something that I'm missing?

ZenPsycho17• 14 years ago

@j_baker I do not agree that prototypes are primitive and I decided to express this in the form of socratic irony.

@fleitz Whether prototypes are overly complex is neither here nor there. the question is whether they are primitive. More primitive than classes- something which is historically and demonstrably untrue, in my opinion.

olalonde5• 14 years ago

When talking about programming languages, "primitive" usually means low level. For example, primitive data types (http://en.wikipedia.org/wiki/Primitive_data_type).

sophacles2• 14 years ago

Here is an example of doing prototypes with classes in python: http://kashif.razzaqui.com/30414548

I presume similar is available in just about any language with decent reflection and/or generics.

franze• 14 years ago

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.

drivebyacct2• 14 years ago

Those are pretty unimportant metrics. Especially given that Dart's eventual intended usage is not to be compiled to JS and the infamous example you cite is strikingly unfair . The real world is much, much, much, much less code.

Besides taking something like "5 lines vs 8 lines for a hello world" and acting as if ALL code bases are automatically that much more bloated via a percentage like that is silly at worst, disingenuous at best.

detst• 14 years ago

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.

phoboslab• 14 years ago

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

dinedal• 14 years ago

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?

reitzensteinm• 14 years ago

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.

berdon• 14 years ago

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

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

dsrguru• 14 years ago

They work for Scala...

pcwalton• 14 years ago

I think they make the types read better, personally, especially if you leave out the space to the left-hand side of the ':'. It clearly signifies to the reader where the code is entering the type grammar. And if you leave out both the spaces to the left and the right of the ':' (as OCaml code often does), it's exactly as many characters as the version with spaces.

B-Con• 14 years ago

I think that most new languages feel obliged to have some sort of fun syntax quirk, usually, it seems, in the form of odd token choices.

viraptor3• 14 years ago

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.

RandallBrown• 14 years ago

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• 14 years ago

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?

ZenPsycho17• 14 years ago

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

robert00700• 14 years ago

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

spyder• 14 years ago

Haxe does the same and more: http://haxe.org/

chii2• 14 years ago

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

HoLyVieR• 14 years ago

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

ZenPsycho17• 14 years ago

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.

tolmasky• 14 years ago

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.

zenocon• 14 years ago

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• 14 years ago

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.

ZenPsycho17• 14 years ago

That's what Ecmascript 4 was.

nickmain• 14 years ago

http://www.jangaroo.net/home/

btipling• 14 years ago

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.

netmau5• 14 years ago

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.

azinman2• 14 years ago

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.

JSX - a faster, safer, easier alternative to JavaScript

Related Stories