71
The future of back-end development
(lemm.ee)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 25 Aug 2023
71 points (94.9% liked)
Programming
17314 readers
291 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
I give typescript running a decent shot of being a major force in backend APIs. There’s a draw to being able to code the same language on front and backend. It’s got a stronger type system than Java in strict mode as well.
It also has quick boot time which can help in cloud functions that may eventually become the preferred method of APIs. No server or os to maintain and they are close to the customers location
Yeah, 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.. pretty surprising, actually.
I really like TS and Python as a backend language but only for projects that are under 5k lines. As soon as it gets above that refactoring, reference counting and type safety falls off for TS imo.
I'm still a TS fanboy. You can do some crazy type acrobatics in it.
Thousands of requests per minute can mean many things so maybe you're referring to several hundred requests per minute, but 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.
edit: our runtime is C#
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 tooling libraries do can cause you to run out of a thread pool. But Node.js, when handling requests, gives you much of the benefit of multithreading without having to deal with multithreaded code.
Aaaahh so libuv actually runs a thread pool, TIL. I'm another victim of internet propaganda I guess 😅 . You know, I never actually checked libuv docs until now and they seem quite welt built.
The silliest thing I've just realized is that I knew that the first implementation of a web server in dotnet core was using libuv, and I still didn't think twice about the single threaded meme.
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 will come to prefer TypeScript given a bit of time.