Hacker News new | ask | show | jobs
by jpgvm 1860 days ago
The tooling and ecosystem are the main problems from my perspective. If you set yourself up with Kotlin + Gradle + IntelliJ you now already have all the tools you need.

Want to create/maintain a modern JS/TS stack? Well, you are going to need npm, webpack, probably babel, linters, need to understand how to setup source maps and get those working for debugging server side. etc.

It's a nightmare and it's all very fragile and that isn't even touching on the poor quality of the libraries outside of React/big ones.

1 comments

Deno is definitely trying to fix that. Single executable, no node_modules, no package.json no Webpack no Babel, built in linter, formatter, bundler, Typescript compiler...

It's definitely not there yet but they have the right idea.

Yeah but I still don't see what I get from it for server side development that isn't better on the JVM...

Better JIT, real threads (also Loom coming which is better than async/await or Promises), better standard library, better library ecosystem, better profilers, better debuggers, better metrics/monitoring for the VM, better portability.

It seems to me that the core server-side JS benefit is isomorphic code on browser and server which is probably useful if your team is small enough to have the same people working on both but for companies of the size I generally work for this is rarely the case beyond maybe small fixes I might do in JS/TS.

For me personally this can't offset the absolutely gigantic difference in quality between say JS/TS and Kotlin/Java.

I agree, I definitely wouldn't use JavaScript on the server side, unless you really want server-side rendering of React or something.