tisdag 4 november 2014

React and the compiler

During the last month's, React.js has sailed up to the position of "the coolest thing ever" in the JavaScript world, effectively pushing Angular down a notch.
This week I started building a trading app for a client, with high performance demands with a lot of real time data being pushed from the server. I thought that react was a perfect match and starting building a proof of concept.
The praise I've heard about react promises great performance, and my first metrics shows that react seems to live up to it's hype.
I must say it's really cool! Plus the fact that I get to try out webpack, which seems just as cool, feels great!

But...
There's one thing that really bothers me. And that's the use of a compiler. I know, a lot of different frameworks use a compiler these days, so what's the big deal?
Well, let me explain.
I am using the webpack react-loader, which compiles the jsx files to regular JavaScript. That is cool, because you can mix HTML and JavaScript in the same files without having to quote strings. You can even add a "harmony" setting to the loader, which let's you use some, but not all,  parts of ES6. Like arrow functions, they just work, being compiled to ES5 functions. But try generators and you're out of luck, there's no support for them yet, try and use them and you'll get a compilation error.

Is that a problem? I believe it is.
Soon browsers will start to support different parts of ES6, like, for instance generators (which Firefox already does by the way).
So, there's stuff the browser supports, but the compiler doesn't, meaning you can't use them. I get flashbacks to my Java background, where you often couldn't use the latest version of the Java language because the app server doesn't support it...

But can't we use another compiler, to convert the generator to ES5 code? Like traceur for instance? No, you can't. Because jsx files contain HTML, the traceur compiler fails if you try that compiler first. And the jsx compiler fails if you try to compile jsx files containing generators first.

Were in the hands of the react developers to keep up with the ES6 spec if we want to use the latest features.
The JavaScript world is moving blazingly fast, and what's trendy today might be dead tomorrow. What if we build all those applications using react, only to find out that Facebook stops developing it? Then we'd probably never be able to use any never features of EcmaScript than those in the react compiler now, 2014.

A better way
I believe a better way would be to follow the sweet.js motto: "stop building compilers, build macros!"
There's not that big a difference, but a sweetjs macro only replaces syntax that it recognizes. It doesn't crash if it find something that it doesn't recognize.
Using macros instead of a compiler would allow us to use whatever syntax the target browser supports, and replace all those non supported stuff with ES5 code. And later on, when browser's starts to support those ES6 features, just remove the macro and let the code pass through.

Any framework I use should let me do as much or more as I could without it. If it robs me of some JavaScript goodies, I'm not that happy with it.