3 ms·

You don't run JavaScript in the backend and even if you do, it's not a problem for a lot of common use cases. JavaScript is also not the language people write

You don't run JavaScript in the backend and even if you do, it's not a problem for a lot of common use cases. JavaScript is also not the language people write in, it's the target. People compile there code into JavaScript more so that writing it. The reason you have JavaScript on the server side of things is that it bridges the browser gap. You get to share some bits between your client and server code. Also, if you have hybrid rendering solutions it's really convenient. You don't exclusively run Node everywhere just because you have Node. It's a tool that can do some things really well. That's it.

lovingCranberry 4y ago
Really? Personally, I've always enjoyed writing services with high I/O and low computation in Node.js. I usually consider Node.js first when having to create a new REST API (which usually just gaps between http and the database) or websocket server.
- john567 4y ago
  Depends on your use case but unless you really need JavaScript interop I think there are better alternatives. You are of course free to do whatever but neither JavaScript or Node is the answer to everything. I think the Go concurrency model is a lot nicer, and it's considerably better throughput wise. As much as I enjoy writing JavaScript is riddled with stupid stuff and lack sensible primitives but I do care about computational performance because I have a lot of code that I want to optimize and towards that goal JavaScript and V8 gets in the way. Even if it's a good VM it can get really ridiculous from a performance point of view.
ttymck 4y ago
Thanks, it sounds like we are in agreement. The "share some bits between client and server code" screams unnecessary coupling and failure to separate concerns between backend and frontend. That's what I've seen in practice anyway.
- john567 4y ago
  Not at all. Rather you might want a tight coupling because it will allow you to integrate deeper. Having the same code running on client and server when your application is split between running both on client and server is very convenient. As an example, a React application with server rendering and then progressive enhancements on the client. Very common pattern.

lovingCranberry 4y ago

Really? Personally, I've always enjoyed writing services with high I/O and low computation in Node.js. I usually consider Node.js first when having to create a new REST API (which usually just gaps between http and the database) or websocket server.

john567 4y ago
Depends on your use case but unless you really need JavaScript interop I think there are better alternatives. You are of course free to do whatever but neither JavaScript or Node is the answer to everything. I think the Go concurrency model is a lot nicer, and it's considerably better throughput wise. As much as I enjoy writing JavaScript is riddled with stupid stuff and lack sensible primitives but I do care about computational performance because I have a lot of code that I want to optimize and towards that goal JavaScript and V8 gets in the way. Even if it's a good VM it can get really ridiculous from a performance point of view.

ttymck 4y ago

Thanks, it sounds like we are in agreement. The "share some bits between client and server code" screams unnecessary coupling and failure to separate concerns between backend and frontend. That's what I've seen in practice anyway.

john567 4y ago
Not at all. Rather you might want a tight coupling because it will allow you to integrate deeper. Having the same code running on client and server when your application is split between running both on client and server is very convenient. As an example, a React application with server rendering and then progressive enhancements on the client. Very common pattern.