Developing a React+JSX Java app backend without node, webpack, and babel
you can't have a java article without picturing a cup of coffee ..
As "nashorn" is simply too slow in practice (>15 seconds to run browserify+babel on the example app below), currently the only option is to run and install a full node stack at least in development.
Modern browsers support ES6 out of the box
Arrow functions, classes, Proxies .. today's browsers support the most important features of the ECMAScript 6 specification .. there is no need to transpile your app down to ES5 anymore.
Long story short ..
As setting up node, webpack, bower and gulp just to get a react front end up and running felt kind of annoying, I implemented a JSX transpiler for kontraktor in order to have a simple and clean setup again.
Kontraktor is an asynchronous distributed Actor framework which can be used as a foundation for micro service architectures, distributed big data analytics as well as plain web app serving. Actually, everybody should use it nowadays, but mkay.
How does it compare to Browserify/Babel ?
Using a smallish react test app (fundamentals: login, register, handle opt-in-link, list tabular data). The following result could be observed:
Babel/Browserify in Production Mode. The bundled react-app is 204kb
Production Mode, intrinsic React (with kontraktor, java transpiler + bundler)
I would not have posted this if kontraktor created larger files ofc ;) .. but it seems like babel and browserify create some significant overhead (though transpilation level was set to es6, so it should not be caused by downtranspiling to es5).
Actually kontraktor's intrinsic JSX transpilation, bundling and minification created a file of only 132 kb (zipped) vs 204 kb created by the babel/browserify combo.
Maybe I missed something, so if someone want's to check the results with webpack, the source is here.
What about development mode ?
Strongly transpiled and bundled code is hard to debug, therefore "source maps" have been invented. A source map basically maps any part of the transpiled and bundled output back to the original file).
The downside of source maps is: they are pretty big and it takes some time to generate them. So it somewhat slows down your development turnaround cycle.
Babel/Browserify in Development Mode (SourceMaps are big ! 2,2MB index.jsx)
Konstraktor's intrinsic transpiled React/JSX does omit the bundling step in development mode, so the original source files are still present for debugging. This works pretty well in practice, so, for now, no source maps are provided.
Development mode, intrinsic React (with kontraktor, java transpiler)
kontraktor instrinsic react does not require sourcemaps as it does not bundle files when in development mode
Test also have shown, that server side pre-rendering rarely adds a significant load time advantage (i assume most articles talking of "isomorphic" web apps have been created because "isomorphic" adds this wonderful touch of academia ..).