Hacker News Reader

Comment by drderidder | Hacker News Reader

Compile-to-JavaScript technologies have come a long way and seem well-suited to porting certain legacy applications to the web as proof-of-concept projects, but I think an API-first approach supporting a lightweight, HTML/JavaScript web framework would have required a justifiable, moderate additional effort, and would not only run faster, look and feel more contemporary, and be easier to maintain, test and deploy, but would put you in a better position to add new functionality going forward.

View on HN

I would agree if the goal is just to build a web app, however, if you want to run natively on multiple platforms, Java still has its good points. If you really run a particular app on a daily basis, it can be nice to have an option for a dedicated desktop app.

We may see more of this with WASM. And JavaScript can get a little unwieldy beyond 100k lines of code.

I don't know if such a thing exists yet, but how would Java compare to a shared Electron?

[ Found the issue. https://github.com/electron/electron/issues/673 ]

It's those multi-client scenarios for which the API-first approach is a perfect fit, actually. Once the API is hammered out, it forms the common foundation for building gui's, cli's and even machine-to-machine interfaces. As a stepping stone, web applications can be deployed as hybrid mobile apps using something like Apache Cordova, even as fully native apps for Android and iOS are under development. Once you've implemented something like this, it's hard to go back to monolithic codebases. Caveat: this is predicated on having an API server and requiring an Internet connection. Writing a connectionless app this way would require some additional effort, though still quite do-able.

Everyone is using compile-to-JS technologies now, even JS programmers are doing it because they want to target legacy JS runtimes without new language features. And the minimization etc side benefits have becoim so relied on, that this toolchain is here to stay. It's a good thing because then a level playing field is enjoyed by a broad range of languages, like Elm, TypeScript and ClojureScript.

TeaVM also outputs WebAssembly, which can be faster than vanilla JS. I strongly disagree with you about that part. The HTML vs WebGL(/canvas) bit is more tricky. I do think there are valid uses of WebGL, but this project takes it too far. Their UI elements don't work great everywhere.

Amen to that

Reply on news.ycombinator.com