published in 'Kontraktor' on Juptr.io

0
0

Code is the only source of truth


R.Möller

Developing a React+JSX Java app backend without node, webpack, and babel 

Implementing a web app server side using Java has been getting ugly recently as its required to run a a full nodejs stack including a load of npm packages and javascript related stuff. By implementing bundling and JSX transpilation in native Java, kontraktor can help out and make things simple again.

 

you can't have a java article without picturing a cup of coffee ..

Modern JavaScript frameworks increasingly rely on extensive transpilation and bundling, which is available via Node / Babel / Webpack only.
 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.

3

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

Conclusion

As browsers catched up, it's not necessary to run a huge transpilation stack in order to get a modern web front end up and running. It's also not too hard to come up with a competitive alternative (like kontraktor does).
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 ..).



Published in: