Comment on The future of back-end development
mark@programming.dev 10 months agoDefinitely can second this. JavaScript/TS doesn’t get a great rep being used on the backend. But I use it on quite a few of my projects, one of which gets thousands of requests per minute. I was skeptical of whether or not using Node on the backend would hold up, but the performance has been stellar.
It doesn’t get a great rep? Would love to hear from that perspective. I’m only seeing the opposite.
Many popular node libraries are/have converted to Typescript. I was on the fence last year but now I’m working towards converting my work into Typescript too.
I think they meant JavaScript/TypeScript don’t get a great rap in comparison to others like Java, Rust, C#, etc.
I think everyone who works with JavaScript/TypeScript professionally prefers TypeScript.
sine@programming.dev 10 months ago
Thousands of requests per minute can mean many things so maybe you’re referring to several hundred requests per minute. One of our services at work gets 300 requests/second which is ~18K requests per minute and it’s really not that much. We’re using pretty cheap cloud services. Even thrice the traffic is pretty much a slow walk for your average production-grade web framework.
Web frameworks are built to support an insane amount of incoming requests, including node. The issue with node is the single threading and having to scale with worker threads AFAIK.
mark@programming.dev 10 months ago
People always say this but its not technically correct and can be misleading.
Technically, JavaScript runs single threaded but not Node.js itself and certainly not when using it on the backend in something like Express. IO operations and other things that plugins can do run out of a thread pool. But Node.js gives you much of the benefit of multithreading without having to deal with multithreaded code.