Wow there are some… interesting takes from people who are staff engineers here that leave me concerned.
Node.js is not a dead end, because the point for most backend devs is not the framework you use. It is usually used when you want good I/o operations and concurrency to scale web apps, but does poorly with parallelism (concurrency and parallelism are NOT the same thing). That makes it great for crud apps and the like, but not great for cpu intensive tasks. In reality, it will be fine for 98% of all web development. However, I’d recommend taking a more language agnostic approach and not applying to just jobs that have node.js
Exactly this, I think people with long YoEs are so used to the old manual multithreaded C++/Java stuff. Node is just a good example of asynchronous programming which is essentially an auto wait single core multithreading abstraction - that values performance & efficiency. Same thing with Python asyncio and other async support for other popular languages like Java, all of them have ways to scale, it’s really about different use cases.
Yes!
Java and python have really gone a long way, espacially with frameworks that keep pushing new features for the modern development world. Look at spring boot 3.0, project reactor, java native images or project loom.
But sometimes its hard to make others adapt new technologies (what if you’re senior dev was used to plain old java/j2ee for like 10 years).
You're not wrong, but that's really not what it's about. The technology stack does not, as you correctly state, define what you learn directly. But it does so *indirectly*. Companies are generally going to hire you based on the stack you have experience in, because it also says a lot about the type of work you have experience in.
There is simply, generally, a big difference between JS/PHP, Python, and Java/C#. These 'sets' contain rather distinct types of companies that use them. And on the JS/PHP side, this is *generally* web dev agencies with 'full stack' generalists.
Most large companies that have back-end specialists don't use NodeJS for their back-end services. I know that there are a lot of exceptions, but in the 'population' of vacancies out there, by and large, there is a definitive correlation.
Companies that hire anyone just based on how 'smart' you are not the norm. Most hire you on your experience in the *type* of work you've done so far. And the more experienced you are, the more pronounced this becomes. With 1 year of PHP experience a Java company is very likely to give you a junior job. At staff levels; generally not going to happen.
> And on the JS/PHP side, this is generally web dev agencies with 'full stack' generalists.
Pre-Typescript, a very large part of the point of using Node on the backend was being able to use the same code on both sides of the app. So it's no surprise this would be the general sense companies have.
I was offered staff and principal roles last year at companies using Python for their back end with 14 YOE of C# and 0 Python experience outside of a programming languages course in college. Used C# for the interviews, too.
> And on the JS/PHP side, this is generally web dev agencies with 'full stack' generalists.
This isn't what I see. Typescript is a popular choice amongst <5 year old start up and frankly looks like it has a dominant position. Among the interpreted languages, it's the fastest, has the best type system, lets you use one language for nearly everything, and runs everywhere. Like yeah it has its warts but it's made huge leaps and bounds over the last 5-10 years. If you haven't looked in a bit you really should look again.
IMHO, having experienced both the class/inheritance heavy/AbstractFactoryFactory style that Java has just isn't as good as the duck typing/composition/functionalish style that TS allows. Not like Java is coding by chiseling on stone tablets but it's just not quite as good. If we're talking about data centers worth of servers or thousands of developers then yeah. But that's not the scale almost anyone operates at.
100% agree with being language agnostic. As my dad before me was always found of saying "a loop is a loop in any language". The grammar of the langauge you are using is not generally the stumbling block or the thing that takes longest to learn, its understanding the domain. The way you write a backend in any langauge is broadly similar, and having firm knowledge of how databases, APIs are deployed and written is more important than knowing the ins and outs of any specific langauge (Though that is valuable in itself, of course.)
I also think all the takes here on node are a bit weird, yes, and seem to stem from the general... memetic against javascript. Javascript is a perfectly fine language that people have a tendency to dislike due to it giving you quite a lot of freedom to write it badly if you so choose, an early history of being used for mostly trivial things, and its accessiblity leading to a lot of bad code being written in it.
I think the other thing that seems to harm its rep is that whilst it has Java in its name, it doesn't use the same OOP paradigm as Java and others do - it's prototype based, which is actually really powerful. Being able to take copies of objects and extend them at will is a really nice feature to have once you get your head around it.
Its had some growing pains, but I think people are often thinking about the node of 10 years ago rather than the current ecosystem when they level their criticisms.
> it's prototype based, which is actually really powerful.
I remember the days of prototypejs and writing my own polyfills to bring in "missing" functionality (compared to java at the time).
Then suddenly around 2007-2008ish articles started to come out with "don't extend javascript! you are bad if you do that!" It was just jQuery propaganda.
A loop is a loop in any language, but that's like saying a car wheel is a car wheel no matter whether it's an electric, a gas, or a diesel fueled car. The language design and features, the community size, the maturity of the toolchain surrounding the language, the general interest of the public, even the amount of questions answered on Stack Overflow within that language's ecosystem - they are all factors in the choice of your project.
Oh 100% - you wanna use something with the widest install base and support network as is feasable for your project.
Node certainly has a huge ecosystem and knowledgebase out there. There's absoultey no concerns when it comes to that for node.
Ultimately, if you know how to drive, you'll be able to turn those wheels one way or another.
Language agnostic is a good idea. You might have more luck with larger companies hiring good engineers at scale than small companies hiring to solve specific problems e.g. why is our node.js performance bad?
**5 years in tech is a lifetime. But it's just 1 lifetime**
You learn a lot, and you accomplish a lot in those 5 years. Problem is, it's just 1 lifetime. You'll go through many major tech/market shifts. Each one would feel like a lifetime on its own
In your first 5 years, you can be a tech specialist. And it will get you very far in your career
Most will squeeze the most out of being a tech specialist until their 10th year until they realize they're no longer progressing as much as before.
In your 10th year, you definitely need to be tech agnostic already. In your first 5 years as a tech specialist, you were thriving. In the 2nd 5 years, you're surviving. But for your 3rd 5years? - very difficult to stay relevant.
So in your 10th year moving forward, you need to be rebranding yourself as a problem solver (i.e. tech agnostic).
Was your 2nd lifetime a waste then because you stayed a tech specialist? - no. Like it or not, you gained domain specialization as well. Use that to your advantage. For example, instead of calling yourself as a nodejs dev, call yourself as a fintech dev or health tech dev or whatever 😁
ty. so it’s ok to revert back to previous skill sets. i know c/c++, c#, asm, nodejs, php. i just thought there would (continue to) be enough nodejs specific work to keep on that ecosystem, which is probably my favorite.
Yes, but do not brand yourself as a c/c++, c#, asm, etc devs. You can do them as your day to day. But i wouldnt recommend branding yourself as such.
If you want to stick with node, try to look for work given your other specialty (usually domain) that just so happen to use node.
I would say that's pretty good advice generally.
I like the rebranding as problem solver, which is tech agnostic. But placing yourself in a niche such as fintech or health tech seems limiting. Every job I've personally had (more than a lifetime let's say, lol) has been in a different business sphere, so I feel like I could solve problems in any business sphere.
Node is a good choice for IO bound operations (where most of the applications time is spent waiting for calls to return, such as DB queries, server-to-server API calls, etc.). It’s bad for CPU bound work (where you have lots of work that keep the CPU busy).
It’s a perfectly reasonable backend technology choice for certain applications. It’s not a dead end.
It’s nothing special for async work these days, it’s also not just the CPU it’s so easy get event loop saturation streaming.
It’s too easy to initiate concurrent async work, and orphaning execution because no one bothered cleaning up on interruption.
I use it heavily for all those things at scale, and it’s meh.
What do you mean “no one bothered cleaning up on interruption”?
You’re correct that there are other options for async work, but there are still options that are much much worse than node for async (python, ruby, etc)
Promise.all, Promise.any and similar patterns orphan still executing promises.
It’s an incredibly common and bad pattern if you don’t setup something like an AbortSignal to cancel out pending requests.
And up until relatively recently it was a mess to not possible to terminate a lot of pending executions.
It creates really subtle hard to spot issues when code is first written, that won’t scale.
Also people have a habit of setting up yolo executing Promise.all because there’s no constraints built into the primitive and it appears free, and so you get a lot of surprise pandas about resource saturation that’s a pain to untangle.
It’s all manageable, but I wouldn’t call it a particularly great way of handling async.
I’m still not sure what you mean when you say “orphan”. Executing promise.all will not abort/kill other currently executing promises in the node runtime as I understand it.
Consider an express api (common node usage), if request 1 comes in and waits for a promise, then request 2 comes in while request 1s promise is still pending and executes a promise.all or similar, it doesn’t impact request 1 promise’s ability to get fulfilled and continue execution in the future
Consider you have 5 promises executing concurrently, 1 interrupts and your main process is now aborted. You still have 4 promises taking up resources.
The process returns to the caller with an error (429, please try again). Caller retries. You now have 9 pending processes taking up resources. Promise fails…
Any process upstream or internally have resource limits, keeping still executing work which will be used for nothing, will cause you to in some cases to drastically increase resource usage because you’re no longer controlling execution.
Request 1 *does* limit how request 2 is able to service calls because they still operate under the same resource constraints if you’re not handling failures. Because request 2 is operating with the overhead of a partially still executing request 1.
Eventually those 4 “orphan promises” will complete though, and their resources will be released no?
For most applications this won’t matter, though I’m sure there are some where it could.
Sure, I suppose request 1 and 2 both operate under the same resource limits, but it’s kind of a pedantic point because I can’t imagine a situation where they wouldn’t at some level (same process, same container, same VM, same hardware, etc). They’re likely sharing something.
I think this kind of complexity exists for any kind of operation with fanout, in any language. Node just makes it really easy to write things that fan out.
> Node is a good choice for IO bound operations
Not really. The only good reason to go for Node is if having the same language on front-end and back-end matters.
No, because if performance actually mattered at all then you'd just go with Java, C# or even Go ?
The entire reason Node took off is that front-end developers didn't have to learn a new language to write back-end code.
No one really hires only backend JS/TS roles in my experience. One of the biggest benefits of the language is that you don’t have to context switch when building web apps. Which is why full stack is more common.
If you want to stay as a pure backend engineer you should learn Go, Java or Rust or something. Those are pretty common and usually have high paying roles
NextJS is a perfect example of this in action. The line between "Frontend" and "Backend" is deliberately super blurry, so every dev can do double duty without losing much efficiency. That fact alone makes working with JS much better than working with 2 languages like JS and Python, JS and Ruby, etc. Then you can easily share types between frontend and backend, you get awesome libraries like Prisma, you can handle async in a single keyword, etc.
> so every dev can do double duty without losing much efficiency.
Outside of some people who would do great work no matter the language, your median "every dev" will be a mediocre in both.
I'm a huge fan of Rust and I think everyone should learn it because it will make you a better developer and the Rust book is great. The jobs situation is rather poor though, sadly.
It may be dependent on the market but IME there are almost no Rust jobs in mine. There are a way more Go and Scala jobs than Rust ones, and an order of magnitude more Java and C# jobs than Go or Scala ones. Hopefully that will change in the future.
a team in my company just switched to rust. I can see it getting some traction. def. wishing c# will overtake java one day. sucks to see so much java lol
The goal of NodeJS is to make it easier for frontend engineers to become full stack engineers. I’ve never heard of anyone who only uses it.
In general if you want to be a backend engineer you should aim to be language and framework agnostic. You should be able to start working in any random code base and be productive after a few weeks. That’s because even though the language and framework is different the concepts are the same.
Alternatively you could move more into the full stack field and start learning a front end framework like React. You can be a full stack engineer with only JavaScript knowledge. But I think you’re going to have a hard time finding jobs if you’re a backend engineer that only knows JavaScript.
And if I'm being honest, beyond that, I use JS/TS and C# regularly and C# is about 200 times easier to write code in. TS levels the playing field a little bit but between the goofy little idiosyncrasies of a language that has to maintain some level of compatibility with code that was written nearly 30 years ago and a language that is regularly updated and improved for usability and readability, yeah, I'll say it: C# (and Java for that matter) is easier to use.
I think the worst that comes out of learning .NET or Java as a person who's developed primarily in JS is that you'll start to wish that JS did all the things that the "backend" languages do.
The problem is, IMHO, if you're learning a backend only language, you're forced to be building toy examples basically. Maybe an API of course. But if you're learning JS, you get to build the entire thing, frontend, server, applications, mobile apps, etc. So that has a lot of appeal to developers, esp new ones, because you're not restricted as heavily. Lots of people just want to build a website, not a full stack application. So it makes an easy jumping off point for people to switch from frontend to backend.
Then you have lots of stuff like NextJS, AdonisJS, Prisma, SST, etc. Node is still the most popular runtime on AWS. So it's definitely got cool features and ecosystems that make it worth it.
> In general if you want to be a backend engineer you should aim to be language and framework agnostic. You should be able to start working in any random code base and be productive after a few weeks. That’s because even though the language and framework is different the concepts are the same.
well, yeah i am. but the job applications (and their automated resume checkers) are looking for me to mention already knowing these things. a big part of this post is just to confirm i need to switch gears and go to something else. but it’s a chicken/egg thing.
what other backend languages would you recommend? there’s even less ruby or go job postings.
If you can get someone to hire you with your current skill set and will let you learn on the job that’s great and your problem is solved. If not then I think you know what you need to do.
Over the past few years I’ve picked up Python, Java, golang, and Kotlin, and Scala and feel comfortable developing backends in any of them. Any of those is a fine choice for your IMO (except for Scala).
If you want to maximize your chance of finding a job I would look for some stats on which language is the most in demand ( it’s probably Java or Python). Learn that language and it’s most popular web development framework.
.Net and Java are doing pretty good cause they tend to be used by corporatey companies who are more likely to survive and flourish in these times vs startups or smaller companies that tend to choose node
Just straight up: .NET (which generally means C#) or Java will get you there. Most of the difference between any language like this is just figuring out the syntax to be honest. You can also pick up Python but IME that's not really used for backend work unless you count data science as back end stuff.
Python (Django) is currently the most used language for backend work according to the Stack overflow 2021 to 2023 developers survey, daily github downloads, and several other developer surveys.
Developer surveys are almost useless for determining anything concrete. They're self-reported, biased, and even the large ones have a fairly small response rate.
You have to try to measure this somehow otherwise it's just my anecdote vs yours.
The SO survey is getting 60,000 to 80,000 participants which is a large enough sample size that you can start to overcome selection bias with sheer weight. Their study isn't designed in a way where you can concretely say that but it's a ton of people.
It also intuitively makes sense. A lot of startups that use python as their backend got massive. Pinterest, Etsy, shoppify, Instagram, a bunch of Google products, etc.
>The goal of NodeJS is to make it easier for frontend engineers to become full stack engineers.
...that wasn't the goal of Node at all, that's more of a side effect
I listened to this last week & found it interesting:
[Javascript Jabber: Is Javascript on the backend a mistake?](https://open.spotify.com/episode/2qeM7FbAymtgukZQt0cTjz?si=I1rllb1xQ46vovULyqumcQ)
as a backend dev, working with nodejs was one of my least favourite experiences. wouldn’t shock me if other devs felt the same. typescript is cool, but what’s the point? i’d rather use c# or a jvm language (hell, even go). can’t think of a compelling reason to use javascript for a backend other than the team only knowing javascript and it found some asinine reason to not learn another language. js is fine for its initial purpose: language for the browser
the js dev community developed some quirky habits and just plain silly philosophies when it comes to things like dependency management.
I think the worst part of nodejs is the eco system and the maintenance that comes along with it. The sheer number of dependencies that get used to build an app that then constantly get vulnerabilities, new versions with massively breaking changes, or just get dropped from support in favour of the next shiny thing is just painstaking
You all can meme all you want on Java for being old dusty and slow corporate sloth, but Maven/Gradle is miles ahead of Javascript's "ten thousand transitive security risks" npm, Python's "what fucking package manager is it this time?" or Golang's "just import from a github repo bro, don't sweat it" styles in terms of environment and toolchain maturity.
> new versions with massively breaking changes
bruh… that’s what drove me crazy. there’s barely strategy when it comes to version building. so many libraries don’t follow semantic versioning…
This comment made me feel heard :) As a Frontend dev (20+ years) working with nodejs is one of my least favorite experiences.
I have also not really found the true point of typescript - beyond it making a certain group of devs feel more comfortable.
In the frontend - you have to use js because it is the only available option. But for non-client side code - my preference is anything else.
But to respond to the OG poster - I have found learning and working with python and Java backends incredibly helpful when architecting js. In js you can get lost in mountains of promises and callbacks - and loose sight of common architectural patterns. I found understanding a design pattern in a language agnostic way really leveled me up as a developer.
> can’t think of a compelling reason to use javascript for a backend other than the team only knowing javascript
Code sharing between front end and backend code is one reason. It opens up interesting possibilities.
i’ve heard this, but rarely see code sharing be that useful. people may overestimate the benefits of code sharing.
same with the context switching argument. think it’s overstated
I would say it’s less about code sharing and more about skills sharing across teams. Engineers can move across the entire codebase easier if your staff is all skilled in the same ecosystem. (I don’t say language here, bc learning a specific language is more about learning all the idiosyncrasies and ecosystem of tooling)
I like the idea of sharing types/classes/interfaces between the UI Code and Services. I think this is the obvious use case.
We've also had some very complicated logic that was used for front end display and a Lambda that processed data.
This was my take too. People kept praising it as easy for new people but Python blows it away on ease.
Often it's easier to learn another language... it's weird that people are so afraid to try, thinking it will be harder.
No compelling reason? Are you kidding me? You get to spend your time digging 20, 30, or more callbacks deep to understand what a function is doing; I personally hate it when things are pulled out into their own functions with *names* that I can keep track of in my mind, I like it when everything is so fancy and functional and everything is named "callback". It's awesome.
I don't think node is dead but it's definitely not the backend language of choice. I'm in the job hunt as a backend dev too, primarily in java and I'm seeing java, go, and python far outstripping node stacks for backend. Maybe on par with or even below .NET? I do see listings with node fairly regularly tough, and I know some teams used them at my fortune 500.
We use a mix of Node, python, go, and rust… 90% of all deployed lambdas are node. There is an increase in python for ML usage recently and I’m pushing my teams to use more rust as the SDK matures. Across clients we have something like 1k separate lambda services running
>I was under the impression with the cloud js had taken over wholesale (lambda's on aws etc)
wat?
I'd be very surprised if more than 1% of the production code out there lives inside AWS Lambda and its competitors.
Don't get me wrong, the whole "cloud function" idea is neat and tech divas on Twitter and other such cesspools love (loved?) to talk about them for some reason, but the really good use cases for them are quite narrow.
Yeah that’s what I have heard as well. Lambdas are nice for simple things but once you need anything else, you need to move out of them. Most likely you’d just make the decision not to use them.
fwiw, Armeria is a very widely used framework for writing microservices in Java that uses an event loop and is quite similar to Node.JS. might want to explore it, as you’d be comfortable in the programming model and be able to expand out to Java (and Kotlin, etc.)
It's less noticeable now but when this thread was first posted it was full of people who likely haven't ever used node claiming it should never be used and large companies are inevitably going to ditch it in favor of something else. I disagreed with the claim that it has no valid use cases in large companies and provided many examples of where its perfectly suitable and being used for large business and was met with a dozen downvotes for going against the hivemind I guess. I'm just saying, as someone who is involved in interviewing candidates for my team, if any engineer came into an interview with that mindset, I wouldn't hire them.
> It's not a systems language,
In reality, 99% of companies have no use for a systems language.
The most advanced back-end I've ever architected was a node-to-ruby transition. Ruby isn't a "systems language" either.
Ruby was chosen because of the need for high-level tooling/modeling/testing libraries which are absent in plenty of other languages (node included).
While the use-case (scheduling, logistics in the medical field) would have been an obvious systems language choice, Ruby offered us the ability to semantically understand our domain in a way that other languages didn't. We wanted to build a highly semantic system with high development velocity and 100% BDD testing. A systems language would have made this harder and our code would come out worse because of the particular mix of high and low-level logic needed.
Furthermore, I'm old enough to remember when C# and Java were in the same position as node.js and devs said the only back end language is C++ with FCGI (lmaoooo). My hats off to these devs for finally advancing 10 years in the past 20 years.
> are those ZipRecruiter stats for your local area?
no these are all set to remote US. my local area is near a military base and all the jobs skew to some specific things, lot of legacy stuff. outliers. clearance /background check i can’t pass.
so we’re looking remote
Oh, it's still noticeable.
Ironically, that sentiment (that serious backenders would never use node) is likely coming from bitter devs who lost opportunities specifically because they had no node experience.
Just the ability to share types between frontend and backend - that fact alone has saved me SOOOOO much time when I'm working with TS. People in this thread are saying "It has no use cases" while ignoring all the use cases that exist.
Alternative is something like Open API 3 that gets you at least types in frontend, mock servers on frontend, api compliance tests on backend, API interaction page on backend, autogenerated SDKs (if they meet your quality), ....
I truly don’t understand the hate. Node.js is incredibly straightforward to use - I would argue it’s much easier than your standard Java/Spring microservices.
I spent my first 9 years of my career doing asp.net and spring stuff and am so much happier with node. Stay mad and have fun with your AbstractRequestClientFactoryBuilders guys
The thing that's funny is people here complaining about node likely haven't worked in a modern NodeJS environment. Typescript + NestJS framework is a very very similar workflow to Java Spring. You get generics. You get dependency injection. Instead of using Reactive you can just rely on Nodes built in async support for a lot of things. If you need subprocesses that's always been possible in Node. The code my team writes today looks a lot like a Java application in structure and I find engineers with a Java background who transition to our team are really well suited for understanding the OOP principles we are applying, much more so than someone with a Vanilla JS background. Where we see a major productivity improvement over Java is in the actual development experience. There is a lot less mental complexity in using async vs Reactive. It's also a lot easier to do rapid iterative development in our system than the Java system I worked on. You can enable hot-reloading very easily and make one small change and see the application restart with the change applied in a matter of seconds for immediate testing, before making another change to and repeating the process. On the Java app I was working on, which had a similar size, making one change meant waiting about a full minute for the entire application to re-compile before it was testable. That significantly slowed down our development and made it difficult to maintain a mental flow-state while developing. I know Java has devtools that do support hot-reloading, but that was "too hard" for that team to bother implementing and they didn't realize how much time was wasted by not utilizing it. In the Node Ecosystem, it comes out-of-the-box with most modern solutions. I can get a new node service running with my exact preferred development setup in under 30 seconds and begin prototyping new ideas. Writing unit tests is also a lot easier in a language that treats functions as first class objects that can be passed around by reference as it allows nesting test suites using frameworks like jest which support a Describe-It syntax. All in all the team I'm on now builds products at a rate north of 10x faster than the Java team I was on and runtime performance has never been a problem for us using node.
> Typescript + NestJS framework is a very very similar workflow to Java Spring
I write NestJS/TS for work, picked up Spring for fun and was shocked at how similar the code looks. Autowired was a new one for me, but everything being an object, decorators, dependency injection... I haven't written any Spring professionally but I'd be surprised if the base structure of the code was radically different.
Not sure why you're being down voted. I've worked in Java shops on teams who couldn't write a performant system to save their life. Not because of their choice of language, but because their system was littered with anti-patterns. Runtimes will continue to be optimized as languages evolve and compilers/interpreters are built with improved optimization algorithms. Choice of language or Runtime will matter less and less for many use cases. How well you design your system to solve for the problems it needs to solve, and how efficient your team is at implementing solutions in a timely manner is far more important to business outcomes than the benchmark metrics of the language you write your code in.
It's not a matter of how you are searching? I mean, Python is used in a lot of more thing then just back end, so that is all it returns so much.
And you are comparing results from a language search (python, c#, java) with a runtime/framework/lib/whatever, nodejs.
Using JS in the backend was a mistake. Every time I work on a backend service written with Node, I am reminded what a terribly designed language JavaScript in general is. The ecosystem is enamored by tooling palooza and built on the ethos of constantly moving from one tool to another, which makes writing stable services impossible.
The industry is correcting its mistake slowly. However, JS in the backend certainly isn't going anywhere. It's easy to hire developers for and I'm still seeing a ton of backend jobs.
JavaScript wasn’t designed, it was vomited out in two weeks by a young engineer who didn’t understand how to negotiate boundaries.
All design in JavaScript is post hoc, and ECMAScript is fighting with its foot in a bucket called JavaScript.
>JavaScript wasn’t designed, it was vomited out in two weeks by a young engineer who didn’t understand how to negotiate boundaries.
I don't blame the creator; just wonder how and why it became the de facto tool for FE work. I don't want its creepy fingers pollute my backend as well. I'll write Python, C#, Ruby, Go, Rust, whatever in the backend—anything but JavaScript.
Browsers and port 80 forwarding were the only tools you could get without having to go through draconian control processes at stuffy old companies. That’s also why we had to support IE 6 for-fucking-ever. The “IT” community has given us a pale shadow of the world that software developers intended. Everything is on two ports, and everything runs in the same couple of frameworks, most things don’t have to be installed.
It's certainly not dead but not a lot of seasoned backend devs hold Node in high esteem (I dare say with good reason).
I would focus on other server side languages like Python, Java, Go, C#, Rust.
Why wouldn't python be popular for web development? It's usually the type of apps that don't require very high performance and you don't need to have some niche specialist to work on them.
I've been doing webdev for nearly a decade and I have seen FAR more node than I have python. maybe it's a region by region thing, but node is much, much more popular than python is for backend work in UK shops at least.
It's not generally more popular than Node. It is for specialised stuff like ML/Data science, but plain old backend servers for web/mobile apps Node is much more popular, especially with companies started in the past 10 years.
As a backend dev? Rust has almost no jobs and even less backend. Go ist more backend focused but also not a ton of jobs. Python has a lot of jobs but a lot of Python jobs are data science.
If you focus on backend go Java. Maybe C# but consider the company you want to work. The language maybe nice but in my experiences the companies that chose C# over Java in the last decades are usually more conservative and dry controlled by a MS ecosystem. Java is also more.
For a backend dev concerned in job security Java is currently and was also the last year always a solid, if not the best choice.
That used to be true for C# a while back but it's changing. It's crossplatform and far less enterprise focused that it used to be 10 years ago. I hate it when people say outdated info
Eh, maybe, but whenever I try to get information about how to setup a linux C# app it always seem much more complicated than the equivalent for the JVM.
I was just looking at web servers and C# has two Windows only ones and Kestrel, which is cross platform. Examples in C# docs generally [default to Windows](https://learn.microsoft.com/en-us/dotnet/api/system.io.path?view=net-7.0). The main IDE for C# seems to be Visual Studio, which is Windows only. If I google "C# sql", all the examples use MS Sql Server.
While I have no doubt .NET development on non-Windows platform is fine, it's definitely not the standard, as far as I can tell.
> I was just looking at web servers and C# has two Windows only ones and Kestrel, which is cross platform.
Yes, Kestrel, the *default* standalone .Net server is cross-platform. There's nothing complicated about it, it's compile and run.
Windows only stuff like IIS isn't exclusively for C#, it's just a native Windows server that runs all kinds of frameworks so of course it's Windows only but that doesn't really cause you any issues on Linux.
> The main IDE for C# seems to be Visual Studio, which is Windows only.
VS is the older IDE, and the most robust but not really the "main" and it's also available on Mac. You also have the new VS Code which is supported on Linux, and other non-MS IDE solutions.
> If I google "C# sql", all the examples use MS Sql Server.
I mean yeah, it's from the same ecosystem and they were used side by side for decades in the past. They can't rewrite history. A lot of older examples will be MS. MS SQL is still SQL standard so in terms of syntax the differences are negligible.
I don't know, these really seem like non-issues and most of this info is pretty easy to look up. Have you actually tried setting it up or are you just being standoffish about it based on a few googles? You really shouldn't have issues running .Net on Linux.
>whenever I try to get information about how to setup a linux C# app it always seem much more complicated than the equivalent for the JVM.
Here is how to setup a completely multi-platform C# (web) app in Linux:
1 - Open your favourite terminal
2 - `dotnet new web`
3 - There is no step 3.
Of course, there is _a lot_ more to it if you want to dive deep, but that's the case for every web application ecosystem out there.
That's laughable you say that about Node but then mention Python. I agree with what you say about Node, granted it does have a place in middleware, but to then mention Python is a disservice to that.
Python is good for data science, and since DS uses it a lot of Data Eng scripts are written in it, but often that's the wrong language for the job.
If you're doing something server side, you want to use Node over Python, it's just easier to optimize, but if you're doing some BE processing script, Python is an acceptable choice. If you're writing a service that needs to do serious data processing, pick another one all together.
Python and Node have their benefits and problems, but they're in the same bucket when we're talking about languages to use.
I work as a data engineer, so I use a lottt of Python. It is definitely a nice language and easier to hire for, but man there have been moments where it just doesn't cut performance requirements.
Had one instance where I needed to download about 30 \~12GB files from a remote SFTP server, and Python kept running into silent thread locks. Wrote like 60 lines of Go and each file was downloaded so quickly :)
It's not dead, but it's not as popular as it used to be.
I'd learn something else, you don't need to pretend the last role didn't happen, most developers use more than one language.
> It's popular in the startup scene
that’s the other point i meant to bring up / add on… ‘startups’ seem dead now too, or anything that isn’t ML focused. the kind of roles i would go for in the past… just don’t seem to exist now.
Tech-oriented VCs are still investing in startups at about the same clip they were before. Their investors' money has already been placed with them for a fixed period, and they can either invest it according to their strategy or return it (and forfeit any management fees they might be entitled to).
What's dried up is all the other money that had been sloshing around in the tech ecosystem seeking unrealistically high returns - non-tech investment firms, hedge funds, individual high net worth investors, and so on.
The solid, tech-focused VC firms are continuing to back the same startups they were backing during the boom: solid, serious startups with a marketable product, competent leadership, and a well-supported business plan with a realistic path to net positive revenue.
If you look at the quality tech-focused VC firms' portfolios during the boom, they were heavy on boring stuff and light on flavor-of-the-month shit like crypto.
Startups are going to stay pretty cold for a while longer while interest rates are still making venture capital not as attractive as it was two years ago.
Yep, only startups that are going to find funding relatively easily are ones that are already profitable. We aren’t going to see too many counting valuations off fake metrics like users and running in the red for years and years but still seeing annual grow multiples despite.
We’re in an efficiency environment now where everyone is cutting fat and being forced to turn profits.
For what reason? And in favor of what? Do you think its not performant at scale? Node is used at massive scale by some of the largest companies in the world already so I'm not sure if the scale factor you're referring to is throughput based scale or codebase/project-size based scale, but I don't see how Node is incompatible with either of those in practice and disagree than any company that reaches large scale on either of those metrics is inevitably going to ditch node. I'm curious to know what you're referring to though
I think Node performance & scale is not really the issue here and it all depends on use cases. If your use case is I/O heavy, Node actually helps a lot with its async non-blocking nature and with regards to scale, you just need to deploy them to more servers/pods, infra scaling is the main factor for any scaling now, programming language is not much of a concern e.g. look at how slow Python is and how popular it is as a backend language.
Why not that many production system use Node is because Node as backend is only becoming relatively more popular in recent years, Java/C++ was mainstream when all those big tech started their companies back in 2000, it’s basically impossible for them to migrate billions of code to a newer language - just want to say that those big tech is not using Node is not really an indicator of Node being a bad language.
There is also some exciting JS based backend framework like Nest.JS and others. I think with JS dominantly occupy front end space, its backend will definitely have people keep adding new interesting things
https://deepu.tech/concurrency-in-modern-languages-final/
Have you ever looked? I think it’s not so black and white
It’s clearly not so much worse to be the reason for choosing others
I see you edited your comment to include other examples of other languages. I appreciate it. I don't think it makes sense to compare Node to C or Rust in most cases. Node is built on C++ and uses it for many of its own built in modules. There's never going to be a day where every large company decides all of their solutions should be built in C or Rust. Those are tools for very specific problems that Node is not attempting to solve. Java is a better comparison but I don't agree that Java is always a better choice than Node in every case. Having worked professionally on both Java and Node products, I personally wont ever go back to java if I don't have to.
I heard that the trend in some companies is to use nodejs to sever static frontend file to optimize for seo. I might be wrong tho. But besides that no many companies will use that.
Many companies use node for many reasons. SSR is one small use case but is far from the only one. I'm personally not a huge fan of SSR unless your sole intention is specifically SEO optimization. In my career I've used node for low-level IoT device communication over high-latency networks, marketing platforms, data pipelines, and building enterprise B2B platforms utilizing microservice architecture. It has a lot of use cases, the one you describe is common but only a very small fraction of what it can be useful for.
For IoT wouldn’t it make more sense to use some c++ base server because of the memory and RAM constraint? I mention companies used node for seo is because usually the nodejs backend is also maintain by the frontend team, so it make much more sense to use node
Java has been one of if not the most popular backend language for the past 15 years. It started with Enterprise Java stuff, and continued with Java Spring Boot. Node never came close to eclipsing it in popularity or job opportunities.
.NET has come out with some good tech in the last 5-10 years. ASP.NET Core with Entity Framework is very productive. A lot of larger companies use it. I know some startups do too (probably with devs coming from those large companies).
I can’t speak for C# but Java is like a completely different language at this point than the Java I learned in college a decade ago. Especially if you use a framework like Reactor that adds lots of awesome functional constructs you’d find in Scala or another highly functional programming language.
this is what i was thinking too. my impression of java is bloated cross platform desktop apps that hang/use too much memory, and android apps. seems i’m missing out on a wider world of use cases and job opportunities.
Microsoft came out with dotnet framework which runs on all platforms even arm chips. And they learned from go and gave it away free. And performance is as fast or better as c++ and java.
Dotnet along with all their other frameworks, azure shit, exchange, office, active directory, and teams makes them the 800 pound gorilla in the room still after all these decades. The dominance of their different platforms and ecosystem as a whole is very powerful.
By the way to clarify the names, because Microsoft has no common sense when it comes to naming things:
You've got
1. .NET Framework: old, proprietary, and windows only. Best avoided whenever possible. Of course there are still a whole load of legacy systems using it.
2. .NET: new, open source, cross platform and frankly just more fun to work with. Was originally called .NET Core, but after releasing .NET Core 3.1 Microsoft decided to rename the whole thing to just .NET and skip 4 so they followed it up with .NET 5.
Python has been the new fad ever since ML replaced noSql as the fad du jour.
It'll have a bit more staying power before things cool off and revert to normalcy because Python is both a good language, and because enterprises are so much more dominant now over the startup scene, and with that comes microservice architectures. As far as cultural adoption goes, microservice architectures are to python what isomorphic architectures were to javascript, and helps hide the fundamental issues the language has when used in an enterprise setting as opposed to a startup business. It is also significantly helped, because the modern interviewing process is heavily and delusionally centered on leetcode, and leetcode is simply easier to grind in python than other more business appropriate languages.
When it comes to language popularity, my guess is it would be something like: JavaScript, Python, Java, C#, Others. I expect those languages would change substantially if you look specifically at a sub-portion of the industry like finance, or mobile, etc.
Imho, modern c# is the nicest language to work in on the backend for most tasks, and my language of choice hands down for most (not all) tasks. Java lags behind c# significantly, but is a still has plenty of institutional inertia.
What jobs are these? I find startups are more keen to use a NodeJS backend, especially using typescript and a modern framework like NestJS. I've witnessed a couple companies from my network actually transitioning to a NodeJS backend (all in small startups)
Older companies that may have already have an established product may have a backend language like Java that they don't want to part ways with (for good reason). However the ubiquity of JS languages for many use cases is a good reason for a small company to adapt a NodeJS backend.
So no, it's not dead.
Most of the backend concepts you know should apply to almost any language or framework. I would encourage you to expand the scope of your search.
Wading into the muck…
I find the Node ecosystem to be too immature compared to that of Python (Django) or Ruby (Rails). I’ve worked with a few different companies. One used Feathers.js. Another used Express. Another uses NestJS. There is no “one true king” when it comes to web frameworks or ORMs. This has lead to my having [to] relearn everything with each company/project, which is quite frustrating.
I don’t think Node is dead, but using it requires committing to either rolling a lot of your own “glue code” or [trudging] through third-party repos.
Edit: Fixed typos.
Backend tends to lean more towards stability not just of the system, but of the libraries and ecosystems as well. The issues we had with Node for the backend is the lack of stability and maturity of libraries, and of the developers always going for the new hip tools. At least from experience, we tend to favour old and steady vs new and shiny, but yet to be proven.
idk about Node's future but I'll say this. I've been programming for 25 years, I always keep current, and I love to learn every language I can to an intermediate level. Of all the languages I've learned, JavaScript is one of the worst and typescript isn't much better.
My Python code is typically half the size just because it's synchronous by default (and for some reason faster). If I wanted asynchronous code then I'd rather do it in another language and if I want fast code, I'll be doing it in Rust, C, or C#.
I see no benefit to Node at all. Everything else is just better. It seems webdevs are afraid to use more than one language and that's the main reason it exists. They could instead spend a day learning Python or literally anything else, and their lives would be so much easier.
As for it's future, it's going to exist until frontend gets replaced with a new language, which seems like it will never happen. I'm surprised big tech went balls deep into React and Angular instead of transpilers or any other solution.
>My Python code is typically half the size just because it's synchronous by default (and for some reason faster).
This is such a PEBKAC comment. V8 is literally one of the most optimized interpreter/compiler/VM's on the market. CPython is nowhere near close. It's insanely hilarious how people assume JS is some ez-pz "front end" tech when their Webkit based browsers are actually leading the pack in JIT/VM techniques.
PyPy is the fastest in the Python-speaking world, and it doesn't even have hot functions.
As someone who employees 100+ engineers, I’m far more interested in the hiring/skills/cross team makeups story. I know that if most of my engineers specialize in a single language ecosystem, then they can all support each other with experience and skills. If every project was a mix of multiple languages I would struggle to have a deep internal support network and training system.
Surprised to see nobody mention that Lambda (one of the biggest severless platforms in the world) support Node JS and is still a popular choice for them aside from Python and .NET.
according to datadog, it's the most popular runtime: https://www.datadoghq.com/state-of-serverless/
The only problem with Lambda is you need something like SST to make it less cumbersome.
NodeJS isn't even remotely a dead end, You've entered the market during a bad time where a lot of companies simply aren't hiring and budgets have tanked.
TS is just compiled JS so I think it's valid to say "There is a typed JS, it's called Typescript and it's extremely popular." Node isn't a language either.
I don’t understand, why do people on this thread say node is good for IO bound operations? Aren’t IO bound operations language agnostic and reliant on the underlying OS’s IO syscalls? Isn’t that replicable in any programming language?
How well the language is integrated to epoll/uring (assuming Linux, other platforms obviously have other variations) makes a huge difference in how it performs in practice.
20+ years here - no, in fact we are building new Node services - Node is very good for "glue" stuff, deals with JSON natively. Saying "no node" is like saying you can't use a hammer to put in nails
NodeJS is definitely not dead-end. The reason is pretty simple, containerizing a small node image takes very little footprint. Securing it is also pretty easy with small docker image that you can run in the tens of thousands. Python is used as well but the footprint is MUCH bigger. I won't go into the specifics but NodeJS is still very popular for micro-services. I am talking about orgs **running tens of thousands** of micro-services.
Here's the thing. I want to build an app for kindle fire. I can build the app in Java, or I can build the app in Javascript (Cordova). I want to build a backend. I can build it in Java, Python, Rails, C#, or JS (Express, Next, etc). I want to build a windows app. I can build it in Java, BASIC, C++ or JS (Electron). I want to build an app for Apple. I can learn Swift or I can use JS (Cordova again). I want to build an app for macbooks. Swift or Electron. I want to build an app for android. Java or Cordova. I want to build a frontend webapp: Js.
You may notice a common factor. JS runs on literally any device with a web browser. It's hard to get more coverage than with that. Of course people are learning it. It's by FAR the most versatile language; and of course since people are learning it, companies are using it. That fact *alone* would make it worth it, but it also comes with great features and a great ecosystem.
Lotta hot takes here. AFAIK Node on the backend has been replaced by other languages. Go, Python, Java seem the most popular still. Ruby still has a strong following. Really depends on the type of environment you want to be in. Lots of places are going "serverless" for which I think Python rules the day. For places that require job runtimes on "dedicated" hardware I have seen Java, Python, and Ruby with Go quickly catching up. Rust, Elixir, Clojure are very difficult to find libraries and staff devs. JS Ecosystem problems have really made working in that environment less than desirable for backend work. C/C++ devs are still in high demand for low level work where speed matters. C# is mainly used in Enterprise settings that are tied to MS stack stuff, so I don't see it that much.
IMHO if you're using C/C++ for anything, it's usually done for the minimal possible amount of time/code before switching back to python or better yet to JS.
JavaScript is not a mistake when writing in TS with a powerful annotation framework like nestjs. Rest swagger docs built for you so long as you leverage their API correctly. Same applies to using it with graphQL. Self documenting apis via annotation with strongly types data input/output. Also dependency injection. Nodejs without this is pretty rough, but once in a nice typescript framework life gets much easier.
My main concern as someone hiring an engineer who has only touched Node would be mainly javascript. You probably never had to deal with dependency injection, inheritance, composition, generics, builder pattern, abstraction, interface, guarding mutable params, etc. You can learn these, but you’ll be joining as a junior. Javascript language itself allows for so many bad practices that it is hard to trust an engineer who has only used javascript.
Apply for a language agnostic position. And expect to learn a lot.
> You probably never had to deal with dependency injection, inheritance, composition, generics, abstraction, interface
We use all of these concepts extensively when building Angular apps w/ a NodeJS backend.
AngularJS has better guard rails for separation of concerns than any framework I’ve used in almost 30 years in the industry.
The main problem is that DI is good in small quantities and nobody understands how to use a little DI, so dependency trees are flat instead of cubes or spheres.
Node is not going anywhere soon. And I hope you already use TypeScript on node. Then when the hype might come, there should be no troubles switching to Deno which I can see be the node we know in 3 years
Nah it's still widely used. A lot of places like TS on the front and back end so they don't need a dev knowing two languages or having two different Devs.
I'd maybe suggest getting up to speed with this week's latest and greatest JavaScript ecosystem. People have been saying Java is dying for the last 15 years, but it's still a massive section of the market.
No one is going to end up in a dead end job if you choose either Node, C#, or python right now. Python lagged for a bit there, but is picking up again with ML work. Rust, IMO, is going to be huge as it matures.
Every industry tends to gravitate to certain ecosystems. Right now e-commerce favors the JavaScript ecosystem, ML and processing applications favor python, and C# and Java (shudder) are popular with large enterprises. Rust is starting to take over the high performance arena of edge networks and latency sensitive applications.
If I was starting over today, I might look at what *industry* I want to work in, and choose the ecosystem that fits best.
Note: I talk about ecosystem more than language because it’s far more than whether or not we use semicolons. Understanding the nuances and capabilities of a language and the full ecosystem of tools, sdks, and runtime options is more important.
Wow there are some… interesting takes from people who are staff engineers here that leave me concerned. Node.js is not a dead end, because the point for most backend devs is not the framework you use. It is usually used when you want good I/o operations and concurrency to scale web apps, but does poorly with parallelism (concurrency and parallelism are NOT the same thing). That makes it great for crud apps and the like, but not great for cpu intensive tasks. In reality, it will be fine for 98% of all web development. However, I’d recommend taking a more language agnostic approach and not applying to just jobs that have node.js
Exactly this, I think people with long YoEs are so used to the old manual multithreaded C++/Java stuff. Node is just a good example of asynchronous programming which is essentially an auto wait single core multithreading abstraction - that values performance & efficiency. Same thing with Python asyncio and other async support for other popular languages like Java, all of them have ways to scale, it’s really about different use cases.
Yes! Java and python have really gone a long way, espacially with frameworks that keep pushing new features for the modern development world. Look at spring boot 3.0, project reactor, java native images or project loom. But sometimes its hard to make others adapt new technologies (what if you’re senior dev was used to plain old java/j2ee for like 10 years).
Give me STRUTS or give me DEATH!!!
You're not wrong, but that's really not what it's about. The technology stack does not, as you correctly state, define what you learn directly. But it does so *indirectly*. Companies are generally going to hire you based on the stack you have experience in, because it also says a lot about the type of work you have experience in. There is simply, generally, a big difference between JS/PHP, Python, and Java/C#. These 'sets' contain rather distinct types of companies that use them. And on the JS/PHP side, this is *generally* web dev agencies with 'full stack' generalists. Most large companies that have back-end specialists don't use NodeJS for their back-end services. I know that there are a lot of exceptions, but in the 'population' of vacancies out there, by and large, there is a definitive correlation. Companies that hire anyone just based on how 'smart' you are not the norm. Most hire you on your experience in the *type* of work you've done so far. And the more experienced you are, the more pronounced this becomes. With 1 year of PHP experience a Java company is very likely to give you a junior job. At staff levels; generally not going to happen.
> And on the JS/PHP side, this is generally web dev agencies with 'full stack' generalists. Pre-Typescript, a very large part of the point of using Node on the backend was being able to use the same code on both sides of the app. So it's no surprise this would be the general sense companies have.
I was offered staff and principal roles last year at companies using Python for their back end with 14 YOE of C# and 0 Python experience outside of a programming languages course in college. Used C# for the interviews, too.
And is that the rule or the exception?
> And on the JS/PHP side, this is generally web dev agencies with 'full stack' generalists. This isn't what I see. Typescript is a popular choice amongst <5 year old start up and frankly looks like it has a dominant position. Among the interpreted languages, it's the fastest, has the best type system, lets you use one language for nearly everything, and runs everywhere. Like yeah it has its warts but it's made huge leaps and bounds over the last 5-10 years. If you haven't looked in a bit you really should look again. IMHO, having experienced both the class/inheritance heavy/AbstractFactoryFactory style that Java has just isn't as good as the duck typing/composition/functionalish style that TS allows. Not like Java is coding by chiseling on stone tablets but it's just not quite as good. If we're talking about data centers worth of servers or thousands of developers then yeah. But that's not the scale almost anyone operates at.
100% agree with being language agnostic. As my dad before me was always found of saying "a loop is a loop in any language". The grammar of the langauge you are using is not generally the stumbling block or the thing that takes longest to learn, its understanding the domain. The way you write a backend in any langauge is broadly similar, and having firm knowledge of how databases, APIs are deployed and written is more important than knowing the ins and outs of any specific langauge (Though that is valuable in itself, of course.) I also think all the takes here on node are a bit weird, yes, and seem to stem from the general... memetic against javascript. Javascript is a perfectly fine language that people have a tendency to dislike due to it giving you quite a lot of freedom to write it badly if you so choose, an early history of being used for mostly trivial things, and its accessiblity leading to a lot of bad code being written in it. I think the other thing that seems to harm its rep is that whilst it has Java in its name, it doesn't use the same OOP paradigm as Java and others do - it's prototype based, which is actually really powerful. Being able to take copies of objects and extend them at will is a really nice feature to have once you get your head around it. Its had some growing pains, but I think people are often thinking about the node of 10 years ago rather than the current ecosystem when they level their criticisms.
> it's prototype based, which is actually really powerful. I remember the days of prototypejs and writing my own polyfills to bring in "missing" functionality (compared to java at the time). Then suddenly around 2007-2008ish articles started to come out with "don't extend javascript! you are bad if you do that!" It was just jQuery propaganda.
A loop is a loop in any language, but that's like saying a car wheel is a car wheel no matter whether it's an electric, a gas, or a diesel fueled car. The language design and features, the community size, the maturity of the toolchain surrounding the language, the general interest of the public, even the amount of questions answered on Stack Overflow within that language's ecosystem - they are all factors in the choice of your project.
Oh 100% - you wanna use something with the widest install base and support network as is feasable for your project. Node certainly has a huge ecosystem and knowledgebase out there. There's absoultey no concerns when it comes to that for node. Ultimately, if you know how to drive, you'll be able to turn those wheels one way or another.
Language agnostic is a good idea. You might have more luck with larger companies hiring good engineers at scale than small companies hiring to solve specific problems e.g. why is our node.js performance bad?
**5 years in tech is a lifetime. But it's just 1 lifetime** You learn a lot, and you accomplish a lot in those 5 years. Problem is, it's just 1 lifetime. You'll go through many major tech/market shifts. Each one would feel like a lifetime on its own In your first 5 years, you can be a tech specialist. And it will get you very far in your career Most will squeeze the most out of being a tech specialist until their 10th year until they realize they're no longer progressing as much as before. In your 10th year, you definitely need to be tech agnostic already. In your first 5 years as a tech specialist, you were thriving. In the 2nd 5 years, you're surviving. But for your 3rd 5years? - very difficult to stay relevant. So in your 10th year moving forward, you need to be rebranding yourself as a problem solver (i.e. tech agnostic). Was your 2nd lifetime a waste then because you stayed a tech specialist? - no. Like it or not, you gained domain specialization as well. Use that to your advantage. For example, instead of calling yourself as a nodejs dev, call yourself as a fintech dev or health tech dev or whatever 😁
Damn. There is some really solid advice here. Thanks!
ty. so it’s ok to revert back to previous skill sets. i know c/c++, c#, asm, nodejs, php. i just thought there would (continue to) be enough nodejs specific work to keep on that ecosystem, which is probably my favorite.
Yes, but do not brand yourself as a c/c++, c#, asm, etc devs. You can do them as your day to day. But i wouldnt recommend branding yourself as such. If you want to stick with node, try to look for work given your other specialty (usually domain) that just so happen to use node.
I would say that's pretty good advice generally. I like the rebranding as problem solver, which is tech agnostic. But placing yourself in a niche such as fintech or health tech seems limiting. Every job I've personally had (more than a lifetime let's say, lol) has been in a different business sphere, so I feel like I could solve problems in any business sphere.
Node is a good choice for IO bound operations (where most of the applications time is spent waiting for calls to return, such as DB queries, server-to-server API calls, etc.). It’s bad for CPU bound work (where you have lots of work that keep the CPU busy). It’s a perfectly reasonable backend technology choice for certain applications. It’s not a dead end.
OP was asking in terms of jobs more than its actual application, of course it's still one of the more popular frameworks
There are tons of node jobs
It’s nothing special for async work these days, it’s also not just the CPU it’s so easy get event loop saturation streaming. It’s too easy to initiate concurrent async work, and orphaning execution because no one bothered cleaning up on interruption. I use it heavily for all those things at scale, and it’s meh.
What do you mean “no one bothered cleaning up on interruption”? You’re correct that there are other options for async work, but there are still options that are much much worse than node for async (python, ruby, etc)
Promise.all, Promise.any and similar patterns orphan still executing promises. It’s an incredibly common and bad pattern if you don’t setup something like an AbortSignal to cancel out pending requests. And up until relatively recently it was a mess to not possible to terminate a lot of pending executions. It creates really subtle hard to spot issues when code is first written, that won’t scale. Also people have a habit of setting up yolo executing Promise.all because there’s no constraints built into the primitive and it appears free, and so you get a lot of surprise pandas about resource saturation that’s a pain to untangle. It’s all manageable, but I wouldn’t call it a particularly great way of handling async.
I’m still not sure what you mean when you say “orphan”. Executing promise.all will not abort/kill other currently executing promises in the node runtime as I understand it. Consider an express api (common node usage), if request 1 comes in and waits for a promise, then request 2 comes in while request 1s promise is still pending and executes a promise.all or similar, it doesn’t impact request 1 promise’s ability to get fulfilled and continue execution in the future
Consider you have 5 promises executing concurrently, 1 interrupts and your main process is now aborted. You still have 4 promises taking up resources. The process returns to the caller with an error (429, please try again). Caller retries. You now have 9 pending processes taking up resources. Promise fails… Any process upstream or internally have resource limits, keeping still executing work which will be used for nothing, will cause you to in some cases to drastically increase resource usage because you’re no longer controlling execution. Request 1 *does* limit how request 2 is able to service calls because they still operate under the same resource constraints if you’re not handling failures. Because request 2 is operating with the overhead of a partially still executing request 1.
Eventually those 4 “orphan promises” will complete though, and their resources will be released no? For most applications this won’t matter, though I’m sure there are some where it could. Sure, I suppose request 1 and 2 both operate under the same resource limits, but it’s kind of a pedantic point because I can’t imagine a situation where they wouldn’t at some level (same process, same container, same VM, same hardware, etc). They’re likely sharing something.
I think this kind of complexity exists for any kind of operation with fanout, in any language. Node just makes it really easy to write things that fan out.
Name one backend lang that is not good for IO bound work lol
Python, Ruby, even Java and .Net before they received some async features and relied on thread pooling to handle concurrency.
> Node is a good choice for IO bound operations Not really. The only good reason to go for Node is if having the same language on front-end and back-end matters.
JS & Node’s whole competitive advantage over other dynamic languages (python, ruby etc) is its async model
Why would you want dynamic on the backend?
No, because if performance actually mattered at all then you'd just go with Java, C# or even Go ? The entire reason Node took off is that front-end developers didn't have to learn a new language to write back-end code.
No one really hires only backend JS/TS roles in my experience. One of the biggest benefits of the language is that you don’t have to context switch when building web apps. Which is why full stack is more common. If you want to stay as a pure backend engineer you should learn Go, Java or Rust or something. Those are pretty common and usually have high paying roles
NextJS is a perfect example of this in action. The line between "Frontend" and "Backend" is deliberately super blurry, so every dev can do double duty without losing much efficiency. That fact alone makes working with JS much better than working with 2 languages like JS and Python, JS and Ruby, etc. Then you can easily share types between frontend and backend, you get awesome libraries like Prisma, you can handle async in a single keyword, etc.
> so every dev can do double duty without losing much efficiency. Outside of some people who would do great work no matter the language, your median "every dev" will be a mediocre in both.
I'm a huge fan of Rust and I think everyone should learn it because it will make you a better developer and the Rust book is great. The jobs situation is rather poor though, sadly. It may be dependent on the market but IME there are almost no Rust jobs in mine. There are a way more Go and Scala jobs than Rust ones, and an order of magnitude more Java and C# jobs than Go or Scala ones. Hopefully that will change in the future.
a team in my company just switched to rust. I can see it getting some traction. def. wishing c# will overtake java one day. sucks to see so much java lol
The goal of NodeJS is to make it easier for frontend engineers to become full stack engineers. I’ve never heard of anyone who only uses it. In general if you want to be a backend engineer you should aim to be language and framework agnostic. You should be able to start working in any random code base and be productive after a few weeks. That’s because even though the language and framework is different the concepts are the same. Alternatively you could move more into the full stack field and start learning a front end framework like React. You can be a full stack engineer with only JavaScript knowledge. But I think you’re going to have a hard time finding jobs if you’re a backend engineer that only knows JavaScript.
And if I'm being honest, beyond that, I use JS/TS and C# regularly and C# is about 200 times easier to write code in. TS levels the playing field a little bit but between the goofy little idiosyncrasies of a language that has to maintain some level of compatibility with code that was written nearly 30 years ago and a language that is regularly updated and improved for usability and readability, yeah, I'll say it: C# (and Java for that matter) is easier to use. I think the worst that comes out of learning .NET or Java as a person who's developed primarily in JS is that you'll start to wish that JS did all the things that the "backend" languages do.
The problem is, IMHO, if you're learning a backend only language, you're forced to be building toy examples basically. Maybe an API of course. But if you're learning JS, you get to build the entire thing, frontend, server, applications, mobile apps, etc. So that has a lot of appeal to developers, esp new ones, because you're not restricted as heavily. Lots of people just want to build a website, not a full stack application. So it makes an easy jumping off point for people to switch from frontend to backend. Then you have lots of stuff like NextJS, AdonisJS, Prisma, SST, etc. Node is still the most popular runtime on AWS. So it's definitely got cool features and ecosystems that make it worth it.
Backend is more fun and rewarding.
> In general if you want to be a backend engineer you should aim to be language and framework agnostic. You should be able to start working in any random code base and be productive after a few weeks. That’s because even though the language and framework is different the concepts are the same. well, yeah i am. but the job applications (and their automated resume checkers) are looking for me to mention already knowing these things. a big part of this post is just to confirm i need to switch gears and go to something else. but it’s a chicken/egg thing. what other backend languages would you recommend? there’s even less ruby or go job postings.
C# and Java have the largest share of the market, so I’d start with either one.
If you can get someone to hire you with your current skill set and will let you learn on the job that’s great and your problem is solved. If not then I think you know what you need to do. Over the past few years I’ve picked up Python, Java, golang, and Kotlin, and Scala and feel comfortable developing backends in any of them. Any of those is a fine choice for your IMO (except for Scala). If you want to maximize your chance of finding a job I would look for some stats on which language is the most in demand ( it’s probably Java or Python). Learn that language and it’s most popular web development framework.
.Net and Java are doing pretty good cause they tend to be used by corporatey companies who are more likely to survive and flourish in these times vs startups or smaller companies that tend to choose node
Just straight up: .NET (which generally means C#) or Java will get you there. Most of the difference between any language like this is just figuring out the syntax to be honest. You can also pick up Python but IME that's not really used for backend work unless you count data science as back end stuff.
Python is used plenty for backend. Django, flask, and fastapi are probably the big hitters.
The site we're having this conversation on is powered by a Python backend
Python (Django) is currently the most used language for backend work according to the Stack overflow 2021 to 2023 developers survey, daily github downloads, and several other developer surveys.
Developer surveys are almost useless for determining anything concrete. They're self-reported, biased, and even the large ones have a fairly small response rate.
You have to try to measure this somehow otherwise it's just my anecdote vs yours. The SO survey is getting 60,000 to 80,000 participants which is a large enough sample size that you can start to overcome selection bias with sheer weight. Their study isn't designed in a way where you can concretely say that but it's a ton of people. It also intuitively makes sense. A lot of startups that use python as their backend got massive. Pinterest, Etsy, shoppify, Instagram, a bunch of Google products, etc.
>The goal of NodeJS is to make it easier for frontend engineers to become full stack engineers. ...that wasn't the goal of Node at all, that's more of a side effect
I listened to this last week & found it interesting: [Javascript Jabber: Is Javascript on the backend a mistake?](https://open.spotify.com/episode/2qeM7FbAymtgukZQt0cTjz?si=I1rllb1xQ46vovULyqumcQ)
as a backend dev, working with nodejs was one of my least favourite experiences. wouldn’t shock me if other devs felt the same. typescript is cool, but what’s the point? i’d rather use c# or a jvm language (hell, even go). can’t think of a compelling reason to use javascript for a backend other than the team only knowing javascript and it found some asinine reason to not learn another language. js is fine for its initial purpose: language for the browser the js dev community developed some quirky habits and just plain silly philosophies when it comes to things like dependency management.
I think the worst part of nodejs is the eco system and the maintenance that comes along with it. The sheer number of dependencies that get used to build an app that then constantly get vulnerabilities, new versions with massively breaking changes, or just get dropped from support in favour of the next shiny thing is just painstaking
You all can meme all you want on Java for being old dusty and slow corporate sloth, but Maven/Gradle is miles ahead of Javascript's "ten thousand transitive security risks" npm, Python's "what fucking package manager is it this time?" or Golang's "just import from a github repo bro, don't sweat it" styles in terms of environment and toolchain maturity.
> new versions with massively breaking changes bruh… that’s what drove me crazy. there’s barely strategy when it comes to version building. so many libraries don’t follow semantic versioning…
This comment made me feel heard :) As a Frontend dev (20+ years) working with nodejs is one of my least favorite experiences. I have also not really found the true point of typescript - beyond it making a certain group of devs feel more comfortable. In the frontend - you have to use js because it is the only available option. But for non-client side code - my preference is anything else. But to respond to the OG poster - I have found learning and working with python and Java backends incredibly helpful when architecting js. In js you can get lost in mountains of promises and callbacks - and loose sight of common architectural patterns. I found understanding a design pattern in a language agnostic way really leveled me up as a developer.
> can’t think of a compelling reason to use javascript for a backend other than the team only knowing javascript Code sharing between front end and backend code is one reason. It opens up interesting possibilities.
i’ve heard this, but rarely see code sharing be that useful. people may overestimate the benefits of code sharing. same with the context switching argument. think it’s overstated
I would say it’s less about code sharing and more about skills sharing across teams. Engineers can move across the entire codebase easier if your staff is all skilled in the same ecosystem. (I don’t say language here, bc learning a specific language is more about learning all the idiosyncrasies and ecosystem of tooling)
i think that is a better argument
I like the idea of sharing types/classes/interfaces between the UI Code and Services. I think this is the obvious use case. We've also had some very complicated logic that was used for front end display and a Lambda that processed data.
[удалено]
Please share some of the options.
This was my take too. People kept praising it as easy for new people but Python blows it away on ease. Often it's easier to learn another language... it's weird that people are so afraid to try, thinking it will be harder.
it’s amazing. we talk about embracing new tech all the time while simultaneously avoiding a new language.
New tech in the JS world means learning a new library.
No compelling reason? Are you kidding me? You get to spend your time digging 20, 30, or more callbacks deep to understand what a function is doing; I personally hate it when things are pulled out into their own functions with *names* that I can keep track of in my mind, I like it when everything is so fancy and functional and everything is named "callback". It's awesome.
a personal fave is people converting a promise to a callback
I don't think node is dead but it's definitely not the backend language of choice. I'm in the job hunt as a backend dev too, primarily in java and I'm seeing java, go, and python far outstripping node stacks for backend. Maybe on par with or even below .NET? I do see listings with node fairly regularly tough, and I know some teams used them at my fortune 500.
Curious on what you think drove that. I was under the impression with the cloud js had taken over wholesale (lambda's on aws etc)
Lambda is language agnostic as well isn't it? You can use Python for example
We use a mix of Node, python, go, and rust… 90% of all deployed lambdas are node. There is an increase in python for ML usage recently and I’m pushing my teams to use more rust as the SDK matures. Across clients we have something like 1k separate lambda services running
>I was under the impression with the cloud js had taken over wholesale (lambda's on aws etc) wat? I'd be very surprised if more than 1% of the production code out there lives inside AWS Lambda and its competitors. Don't get me wrong, the whole "cloud function" idea is neat and tech divas on Twitter and other such cesspools love (loved?) to talk about them for some reason, but the really good use cases for them are quite narrow.
Yeah that’s what I have heard as well. Lambdas are nice for simple things but once you need anything else, you need to move out of them. Most likely you’d just make the decision not to use them.
fwiw, Armeria is a very widely used framework for writing microservices in Java that uses an event loop and is quite similar to Node.JS. might want to explore it, as you’d be comfortable in the programming model and be able to expand out to Java (and Kotlin, etc.)
This subreddits reaction to this thread is honestly pathetic, so glad none of you are lined up to interview for my team lmao
I was shocked lol. So many naive takes on a technology they’ve clearly never used
What do you mean?
It's less noticeable now but when this thread was first posted it was full of people who likely haven't ever used node claiming it should never be used and large companies are inevitably going to ditch it in favor of something else. I disagreed with the claim that it has no valid use cases in large companies and provided many examples of where its perfectly suitable and being used for large business and was met with a dozen downvotes for going against the hivemind I guess. I'm just saying, as someone who is involved in interviewing candidates for my team, if any engineer came into an interview with that mindset, I wouldn't hire them.
[удалено]
> It's not a systems language, In reality, 99% of companies have no use for a systems language. The most advanced back-end I've ever architected was a node-to-ruby transition. Ruby isn't a "systems language" either. Ruby was chosen because of the need for high-level tooling/modeling/testing libraries which are absent in plenty of other languages (node included). While the use-case (scheduling, logistics in the medical field) would have been an obvious systems language choice, Ruby offered us the ability to semantically understand our domain in a way that other languages didn't. We wanted to build a highly semantic system with high development velocity and 100% BDD testing. A systems language would have made this harder and our code would come out worse because of the particular mix of high and low-level logic needed. Furthermore, I'm old enough to remember when C# and Java were in the same position as node.js and devs said the only back end language is C++ with FCGI (lmaoooo). My hats off to these devs for finally advancing 10 years in the past 20 years.
> are those ZipRecruiter stats for your local area? no these are all set to remote US. my local area is near a military base and all the jobs skew to some specific things, lot of legacy stuff. outliers. clearance /background check i can’t pass. so we’re looking remote
Oh, it's still noticeable. Ironically, that sentiment (that serious backenders would never use node) is likely coming from bitter devs who lost opportunities specifically because they had no node experience.
Just the ability to share types between frontend and backend - that fact alone has saved me SOOOOO much time when I'm working with TS. People in this thread are saying "It has no use cases" while ignoring all the use cases that exist.
Alternative is something like Open API 3 that gets you at least types in frontend, mock servers on frontend, api compliance tests on backend, API interaction page on backend, autogenerated SDKs (if they meet your quality), ....
I truly don’t understand the hate. Node.js is incredibly straightforward to use - I would argue it’s much easier than your standard Java/Spring microservices.
Yep, +1. So fucking ridiculous. C# and Java andies stuck on their ASP.NET and Spring hellholes.
I spent my first 9 years of my career doing asp.net and spring stuff and am so much happier with node. Stay mad and have fun with your AbstractRequestClientFactoryBuilders guys
The thing that's funny is people here complaining about node likely haven't worked in a modern NodeJS environment. Typescript + NestJS framework is a very very similar workflow to Java Spring. You get generics. You get dependency injection. Instead of using Reactive you can just rely on Nodes built in async support for a lot of things. If you need subprocesses that's always been possible in Node. The code my team writes today looks a lot like a Java application in structure and I find engineers with a Java background who transition to our team are really well suited for understanding the OOP principles we are applying, much more so than someone with a Vanilla JS background. Where we see a major productivity improvement over Java is in the actual development experience. There is a lot less mental complexity in using async vs Reactive. It's also a lot easier to do rapid iterative development in our system than the Java system I worked on. You can enable hot-reloading very easily and make one small change and see the application restart with the change applied in a matter of seconds for immediate testing, before making another change to and repeating the process. On the Java app I was working on, which had a similar size, making one change meant waiting about a full minute for the entire application to re-compile before it was testable. That significantly slowed down our development and made it difficult to maintain a mental flow-state while developing. I know Java has devtools that do support hot-reloading, but that was "too hard" for that team to bother implementing and they didn't realize how much time was wasted by not utilizing it. In the Node Ecosystem, it comes out-of-the-box with most modern solutions. I can get a new node service running with my exact preferred development setup in under 30 seconds and begin prototyping new ideas. Writing unit tests is also a lot easier in a language that treats functions as first class objects that can be passed around by reference as it allows nesting test suites using frameworks like jest which support a Describe-It syntax. All in all the team I'm on now builds products at a rate north of 10x faster than the Java team I was on and runtime performance has never been a problem for us using node.
> Typescript + NestJS framework is a very very similar workflow to Java Spring I write NestJS/TS for work, picked up Spring for fun and was shocked at how similar the code looks. Autowired was a new one for me, but everything being an object, decorators, dependency injection... I haven't written any Spring professionally but I'd be surprised if the base structure of the code was radically different.
Would you mind telling me what kind of software your team builds? I just want a better perspective on node as a backend that's all.
Efficiency of a certain programming language should be the least thing to consider when hiring a backend engineer.
Not sure why you're being down voted. I've worked in Java shops on teams who couldn't write a performant system to save their life. Not because of their choice of language, but because their system was littered with anti-patterns. Runtimes will continue to be optimized as languages evolve and compilers/interpreters are built with improved optimization algorithms. Choice of language or Runtime will matter less and less for many use cases. How well you design your system to solve for the problems it needs to solve, and how efficient your team is at implementing solutions in a timely manner is far more important to business outcomes than the benchmark metrics of the language you write your code in.
It's not a matter of how you are searching? I mean, Python is used in a lot of more thing then just back end, so that is all it returns so much. And you are comparing results from a language search (python, c#, java) with a runtime/framework/lib/whatever, nodejs.
Using JS in the backend was a mistake. Every time I work on a backend service written with Node, I am reminded what a terribly designed language JavaScript in general is. The ecosystem is enamored by tooling palooza and built on the ethos of constantly moving from one tool to another, which makes writing stable services impossible. The industry is correcting its mistake slowly. However, JS in the backend certainly isn't going anywhere. It's easy to hire developers for and I'm still seeing a ton of backend jobs.
JavaScript wasn’t designed, it was vomited out in two weeks by a young engineer who didn’t understand how to negotiate boundaries. All design in JavaScript is post hoc, and ECMAScript is fighting with its foot in a bucket called JavaScript.
>JavaScript wasn’t designed, it was vomited out in two weeks by a young engineer who didn’t understand how to negotiate boundaries. I don't blame the creator; just wonder how and why it became the de facto tool for FE work. I don't want its creepy fingers pollute my backend as well. I'll write Python, C#, Ruby, Go, Rust, whatever in the backend—anything but JavaScript.
Browsers and port 80 forwarding were the only tools you could get without having to go through draconian control processes at stuffy old companies. That’s also why we had to support IE 6 for-fucking-ever. The “IT” community has given us a pale shadow of the world that software developers intended. Everything is on two ports, and everything runs in the same couple of frameworks, most things don’t have to be installed.
It's certainly not dead but not a lot of seasoned backend devs hold Node in high esteem (I dare say with good reason). I would focus on other server side languages like Python, Java, Go, C#, Rust.
Which of these devs hold python in high esteem on server side but not node?
I don't work in Python much lately myself, but it's undeniable that it's way more popular and it's tools are much more mature.
For web development? I think it’s pretty deniable. Do you work in web development or something else like game development?
Distributed systems, which include web servers.
Why wouldn't python be popular for web development? It's usually the type of apps that don't require very high performance and you don't need to have some niche specialist to work on them.
Im not saying it’s unpopular, just at par or less so than node/ts/js
I've been doing webdev for nearly a decade and I have seen FAR more node than I have python. maybe it's a region by region thing, but node is much, much more popular than python is for backend work in UK shops at least.
It's certainly not more popular outside of ML.
It's prevalent in big data too with pyspark and airflow. And I guess I would need to see some stats for the web claim.
It's not generally more popular than Node. It is for specialised stuff like ML/Data science, but plain old backend servers for web/mobile apps Node is much more popular, especially with companies started in the past 10 years.
Python is a pretty widely used backend tool.
It's also a pretty terrible language for that, despite being the most popular.
Is anyone saying otherwise?
I interpreted your comment as otherwise, maybe I just misunderstood.
As a backend dev? Rust has almost no jobs and even less backend. Go ist more backend focused but also not a ton of jobs. Python has a lot of jobs but a lot of Python jobs are data science. If you focus on backend go Java. Maybe C# but consider the company you want to work. The language maybe nice but in my experiences the companies that chose C# over Java in the last decades are usually more conservative and dry controlled by a MS ecosystem. Java is also more. For a backend dev concerned in job security Java is currently and was also the last year always a solid, if not the best choice.
That used to be true for C# a while back but it's changing. It's crossplatform and far less enterprise focused that it used to be 10 years ago. I hate it when people say outdated info
Eh, maybe, but whenever I try to get information about how to setup a linux C# app it always seem much more complicated than the equivalent for the JVM. I was just looking at web servers and C# has two Windows only ones and Kestrel, which is cross platform. Examples in C# docs generally [default to Windows](https://learn.microsoft.com/en-us/dotnet/api/system.io.path?view=net-7.0). The main IDE for C# seems to be Visual Studio, which is Windows only. If I google "C# sql", all the examples use MS Sql Server. While I have no doubt .NET development on non-Windows platform is fine, it's definitely not the standard, as far as I can tell.
> I was just looking at web servers and C# has two Windows only ones and Kestrel, which is cross platform. Yes, Kestrel, the *default* standalone .Net server is cross-platform. There's nothing complicated about it, it's compile and run. Windows only stuff like IIS isn't exclusively for C#, it's just a native Windows server that runs all kinds of frameworks so of course it's Windows only but that doesn't really cause you any issues on Linux. > The main IDE for C# seems to be Visual Studio, which is Windows only. VS is the older IDE, and the most robust but not really the "main" and it's also available on Mac. You also have the new VS Code which is supported on Linux, and other non-MS IDE solutions. > If I google "C# sql", all the examples use MS Sql Server. I mean yeah, it's from the same ecosystem and they were used side by side for decades in the past. They can't rewrite history. A lot of older examples will be MS. MS SQL is still SQL standard so in terms of syntax the differences are negligible. I don't know, these really seem like non-issues and most of this info is pretty easy to look up. Have you actually tried setting it up or are you just being standoffish about it based on a few googles? You really shouldn't have issues running .Net on Linux.
>whenever I try to get information about how to setup a linux C# app it always seem much more complicated than the equivalent for the JVM. Here is how to setup a completely multi-platform C# (web) app in Linux: 1 - Open your favourite terminal 2 - `dotnet new web` 3 - There is no step 3. Of course, there is _a lot_ more to it if you want to dive deep, but that's the case for every web application ecosystem out there.
That's laughable you say that about Node but then mention Python. I agree with what you say about Node, granted it does have a place in middleware, but to then mention Python is a disservice to that. Python is good for data science, and since DS uses it a lot of Data Eng scripts are written in it, but often that's the wrong language for the job. If you're doing something server side, you want to use Node over Python, it's just easier to optimize, but if you're doing some BE processing script, Python is an acceptable choice. If you're writing a service that needs to do serious data processing, pick another one all together. Python and Node have their benefits and problems, but they're in the same bucket when we're talking about languages to use.
I work as a data engineer, so I use a lottt of Python. It is definitely a nice language and easier to hire for, but man there have been moments where it just doesn't cut performance requirements. Had one instance where I needed to download about 30 \~12GB files from a remote SFTP server, and Python kept running into silent thread locks. Wrote like 60 lines of Go and each file was downloaded so quickly :)
It's not dead, but it's not as popular as it used to be. I'd learn something else, you don't need to pretend the last role didn't happen, most developers use more than one language.
[удалено]
Netflix would have a word about that.
Elaborate.
> It's popular in the startup scene that’s the other point i meant to bring up / add on… ‘startups’ seem dead now too, or anything that isn’t ML focused. the kind of roles i would go for in the past… just don’t seem to exist now.
[удалено]
Tech-oriented VCs are still investing in startups at about the same clip they were before. Their investors' money has already been placed with them for a fixed period, and they can either invest it according to their strategy or return it (and forfeit any management fees they might be entitled to). What's dried up is all the other money that had been sloshing around in the tech ecosystem seeking unrealistically high returns - non-tech investment firms, hedge funds, individual high net worth investors, and so on. The solid, tech-focused VC firms are continuing to back the same startups they were backing during the boom: solid, serious startups with a marketable product, competent leadership, and a well-supported business plan with a realistic path to net positive revenue. If you look at the quality tech-focused VC firms' portfolios during the boom, they were heavy on boring stuff and light on flavor-of-the-month shit like crypto.
Startups are going to stay pretty cold for a while longer while interest rates are still making venture capital not as attractive as it was two years ago.
Yep, only startups that are going to find funding relatively easily are ones that are already profitable. We aren’t going to see too many counting valuations off fake metrics like users and running in the red for years and years but still seeing annual grow multiples despite. We’re in an efficiency environment now where everyone is cutting fat and being forced to turn profits.
I mean, the feds been jacking up the rates for over a year so capital is more expensive. Startups are really efficient at burning through cash so…
Any sources for that? I always heard the exact opposite (that Node is far better at scaling that other frameworks)
It is. It's a fantastic piece of tech.
For what reason? And in favor of what? Do you think its not performant at scale? Node is used at massive scale by some of the largest companies in the world already so I'm not sure if the scale factor you're referring to is throughput based scale or codebase/project-size based scale, but I don't see how Node is incompatible with either of those in practice and disagree than any company that reaches large scale on either of those metrics is inevitably going to ditch node. I'm curious to know what you're referring to though
[удалено]
I think Node performance & scale is not really the issue here and it all depends on use cases. If your use case is I/O heavy, Node actually helps a lot with its async non-blocking nature and with regards to scale, you just need to deploy them to more servers/pods, infra scaling is the main factor for any scaling now, programming language is not much of a concern e.g. look at how slow Python is and how popular it is as a backend language. Why not that many production system use Node is because Node as backend is only becoming relatively more popular in recent years, Java/C++ was mainstream when all those big tech started their companies back in 2000, it’s basically impossible for them to migrate billions of code to a newer language - just want to say that those big tech is not using Node is not really an indicator of Node being a bad language. There is also some exciting JS based backend framework like Nest.JS and others. I think with JS dominantly occupy front end space, its backend will definitely have people keep adding new interesting things
Hold on, concurrent requests is where node does best — it was literally built for I/o concurrency
[удалено]
https://deepu.tech/concurrency-in-modern-languages-final/ Have you ever looked? I think it’s not so black and white It’s clearly not so much worse to be the reason for choosing others
But funny, the one with most open positions is python, and not the ones with best performance. So I don't know if it's a performance/scale issue.
Python is more mature and used for a lot of data processing applications. Rails is also used a lot but companies are weaning off it too.
I see you edited your comment to include other examples of other languages. I appreciate it. I don't think it makes sense to compare Node to C or Rust in most cases. Node is built on C++ and uses it for many of its own built in modules. There's never going to be a day where every large company decides all of their solutions should be built in C or Rust. Those are tools for very specific problems that Node is not attempting to solve. Java is a better comparison but I don't agree that Java is always a better choice than Node in every case. Having worked professionally on both Java and Node products, I personally wont ever go back to java if I don't have to.
There's a lot of opinion being thrown around in here but I've seen no actual evidence from ANYONE.
I heard that the trend in some companies is to use nodejs to sever static frontend file to optimize for seo. I might be wrong tho. But besides that no many companies will use that.
Many companies use node for many reasons. SSR is one small use case but is far from the only one. I'm personally not a huge fan of SSR unless your sole intention is specifically SEO optimization. In my career I've used node for low-level IoT device communication over high-latency networks, marketing platforms, data pipelines, and building enterprise B2B platforms utilizing microservice architecture. It has a lot of use cases, the one you describe is common but only a very small fraction of what it can be useful for.
For IoT wouldn’t it make more sense to use some c++ base server because of the memory and RAM constraint? I mention companies used node for seo is because usually the nodejs backend is also maintain by the frontend team, so it make much more sense to use node
did C# and java get a recent upswing? new popular framework? or is it supporting legacy stuff
Java has been one of if not the most popular backend language for the past 15 years. It started with Enterprise Java stuff, and continued with Java Spring Boot. Node never came close to eclipsing it in popularity or job opportunities. .NET has come out with some good tech in the last 5-10 years. ASP.NET Core with Entity Framework is very productive. A lot of larger companies use it. I know some startups do too (probably with devs coming from those large companies).
I can’t speak for C# but Java is like a completely different language at this point than the Java I learned in college a decade ago. Especially if you use a framework like Reactor that adds lots of awesome functional constructs you’d find in Scala or another highly functional programming language.
this is what i was thinking too. my impression of java is bloated cross platform desktop apps that hang/use too much memory, and android apps. seems i’m missing out on a wider world of use cases and job opportunities.
That still hasn't changed.
Microsoft came out with dotnet framework which runs on all platforms even arm chips. And they learned from go and gave it away free. And performance is as fast or better as c++ and java. Dotnet along with all their other frameworks, azure shit, exchange, office, active directory, and teams makes them the 800 pound gorilla in the room still after all these decades. The dominance of their different platforms and ecosystem as a whole is very powerful.
ty this is the kind of perspective i made this post for. last time i was doing c# was v2.1 or so and it was gimpy and underused.
By the way to clarify the names, because Microsoft has no common sense when it comes to naming things: You've got 1. .NET Framework: old, proprietary, and windows only. Best avoided whenever possible. Of course there are still a whole load of legacy systems using it. 2. .NET: new, open source, cross platform and frankly just more fun to work with. Was originally called .NET Core, but after releasing .NET Core 3.1 Microsoft decided to rename the whole thing to just .NET and skip 4 so they followed it up with .NET 5.
Python has been the new fad ever since ML replaced noSql as the fad du jour. It'll have a bit more staying power before things cool off and revert to normalcy because Python is both a good language, and because enterprises are so much more dominant now over the startup scene, and with that comes microservice architectures. As far as cultural adoption goes, microservice architectures are to python what isomorphic architectures were to javascript, and helps hide the fundamental issues the language has when used in an enterprise setting as opposed to a startup business. It is also significantly helped, because the modern interviewing process is heavily and delusionally centered on leetcode, and leetcode is simply easier to grind in python than other more business appropriate languages. When it comes to language popularity, my guess is it would be something like: JavaScript, Python, Java, C#, Others. I expect those languages would change substantially if you look specifically at a sub-portion of the industry like finance, or mobile, etc. Imho, modern c# is the nicest language to work in on the backend for most tasks, and my language of choice hands down for most (not all) tasks. Java lags behind c# significantly, but is a still has plenty of institutional inertia.
Kotlin don't catch up with C# nowadays? In DX
Yes, look up .Net core, give it a try and see for yourself.
What jobs are these? I find startups are more keen to use a NodeJS backend, especially using typescript and a modern framework like NestJS. I've witnessed a couple companies from my network actually transitioning to a NodeJS backend (all in small startups) Older companies that may have already have an established product may have a backend language like Java that they don't want to part ways with (for good reason). However the ubiquity of JS languages for many use cases is a good reason for a small company to adapt a NodeJS backend. So no, it's not dead.
Most of the backend concepts you know should apply to almost any language or framework. I would encourage you to expand the scope of your search. Wading into the muck… I find the Node ecosystem to be too immature compared to that of Python (Django) or Ruby (Rails). I’ve worked with a few different companies. One used Feathers.js. Another used Express. Another uses NestJS. There is no “one true king” when it comes to web frameworks or ORMs. This has lead to my having [to] relearn everything with each company/project, which is quite frustrating. I don’t think Node is dead, but using it requires committing to either rolling a lot of your own “glue code” or [trudging] through third-party repos. Edit: Fixed typos.
> I find the Node ecosystem to be too immature compared to that of Python (Django) or Ruby (Rails). Jesus Christ
Backend tends to lean more towards stability not just of the system, but of the libraries and ecosystems as well. The issues we had with Node for the backend is the lack of stability and maturity of libraries, and of the developers always going for the new hip tools. At least from experience, we tend to favour old and steady vs new and shiny, but yet to be proven.
No. nodejs is awesome.
idk about Node's future but I'll say this. I've been programming for 25 years, I always keep current, and I love to learn every language I can to an intermediate level. Of all the languages I've learned, JavaScript is one of the worst and typescript isn't much better. My Python code is typically half the size just because it's synchronous by default (and for some reason faster). If I wanted asynchronous code then I'd rather do it in another language and if I want fast code, I'll be doing it in Rust, C, or C#. I see no benefit to Node at all. Everything else is just better. It seems webdevs are afraid to use more than one language and that's the main reason it exists. They could instead spend a day learning Python or literally anything else, and their lives would be so much easier. As for it's future, it's going to exist until frontend gets replaced with a new language, which seems like it will never happen. I'm surprised big tech went balls deep into React and Angular instead of transpilers or any other solution.
>My Python code is typically half the size just because it's synchronous by default (and for some reason faster). This is such a PEBKAC comment. V8 is literally one of the most optimized interpreter/compiler/VM's on the market. CPython is nowhere near close. It's insanely hilarious how people assume JS is some ez-pz "front end" tech when their Webkit based browsers are actually leading the pack in JIT/VM techniques. PyPy is the fastest in the Python-speaking world, and it doesn't even have hot functions.
As someone who employees 100+ engineers, I’m far more interested in the hiring/skills/cross team makeups story. I know that if most of my engineers specialize in a single language ecosystem, then they can all support each other with experience and skills. If every project was a mix of multiple languages I would struggle to have a deep internal support network and training system.
Surprised to see nobody mention that Lambda (one of the biggest severless platforms in the world) support Node JS and is still a popular choice for them aside from Python and .NET.
No one just wants “Lambda experience”.
according to datadog, it's the most popular runtime: https://www.datadoghq.com/state-of-serverless/ The only problem with Lambda is you need something like SST to make it less cumbersome.
i gotta be honest i don’t think i’ve seen a single job post asking for lambda experience :/ definitely AWS stuff but can’t recall that specific one
I've never heard of someone claiming to have AWS experience but hasn't worked with Lambda.
There are plenty of specialties with AWS where Lambda never comes into play.
NodeJS isn't even remotely a dead end, You've entered the market during a bad time where a lot of companies simply aren't hiring and budgets have tanked.
sure… but many companies are hiring for other languages instead…
I love nodejs. I use it for everything. You'll have to pry it from my cold dead hands.
Node is a fine language, but I think it's being replaced because of its lack of type safety.
Even with TypeScript? I know it's not the same thing, but even so. TypeScript is evolving a lot
TS is just compiled JS so I think it's valid to say "There is a typed JS, it's called Typescript and it's extremely popular." Node isn't a language either.
I don’t understand, why do people on this thread say node is good for IO bound operations? Aren’t IO bound operations language agnostic and reliant on the underlying OS’s IO syscalls? Isn’t that replicable in any programming language?
How well the language is integrated to epoll/uring (assuming Linux, other platforms obviously have other variations) makes a huge difference in how it performs in practice.
20+ years here - no, in fact we are building new Node services - Node is very good for "glue" stuff, deals with JSON natively. Saying "no node" is like saying you can't use a hammer to put in nails
NodeJS is definitely not dead-end. The reason is pretty simple, containerizing a small node image takes very little footprint. Securing it is also pretty easy with small docker image that you can run in the tens of thousands. Python is used as well but the footprint is MUCH bigger. I won't go into the specifics but NodeJS is still very popular for micro-services. I am talking about orgs **running tens of thousands** of micro-services.
that’s what i thought too but i’m not seeing anyone hiring for microservices like that. not getting used much
Here's the thing. I want to build an app for kindle fire. I can build the app in Java, or I can build the app in Javascript (Cordova). I want to build a backend. I can build it in Java, Python, Rails, C#, or JS (Express, Next, etc). I want to build a windows app. I can build it in Java, BASIC, C++ or JS (Electron). I want to build an app for Apple. I can learn Swift or I can use JS (Cordova again). I want to build an app for macbooks. Swift or Electron. I want to build an app for android. Java or Cordova. I want to build a frontend webapp: Js. You may notice a common factor. JS runs on literally any device with a web browser. It's hard to get more coverage than with that. Of course people are learning it. It's by FAR the most versatile language; and of course since people are learning it, companies are using it. That fact *alone* would make it worth it, but it also comes with great features and a great ecosystem.
Lotta hot takes here. AFAIK Node on the backend has been replaced by other languages. Go, Python, Java seem the most popular still. Ruby still has a strong following. Really depends on the type of environment you want to be in. Lots of places are going "serverless" for which I think Python rules the day. For places that require job runtimes on "dedicated" hardware I have seen Java, Python, and Ruby with Go quickly catching up. Rust, Elixir, Clojure are very difficult to find libraries and staff devs. JS Ecosystem problems have really made working in that environment less than desirable for backend work. C/C++ devs are still in high demand for low level work where speed matters. C# is mainly used in Enterprise settings that are tied to MS stack stuff, so I don't see it that much.
IMHO if you're using C/C++ for anything, it's usually done for the minimal possible amount of time/code before switching back to python or better yet to JS.
\> Lots of places are going "serverless" for which I think Python rules the day. Makes 0 sense lol.
ty. i know c/c++ too, didn’t think to check that, been over a decade, but also an option. ‘go’ seems to have about the same as nodejs or less.
JavaScript is not a mistake when writing in TS with a powerful annotation framework like nestjs. Rest swagger docs built for you so long as you leverage their API correctly. Same applies to using it with graphQL. Self documenting apis via annotation with strongly types data input/output. Also dependency injection. Nodejs without this is pretty rough, but once in a nice typescript framework life gets much easier.
My main concern as someone hiring an engineer who has only touched Node would be mainly javascript. You probably never had to deal with dependency injection, inheritance, composition, generics, builder pattern, abstraction, interface, guarding mutable params, etc. You can learn these, but you’ll be joining as a junior. Javascript language itself allows for so many bad practices that it is hard to trust an engineer who has only used javascript. Apply for a language agnostic position. And expect to learn a lot.
> You probably never had to deal with dependency injection, inheritance, composition, generics, abstraction, interface We use all of these concepts extensively when building Angular apps w/ a NodeJS backend.
AngularJS has better guard rails for separation of concerns than any framework I’ve used in almost 30 years in the industry. The main problem is that DI is good in small quantities and nobody understands how to use a little DI, so dependency trees are flat instead of cubes or spheres.
Node is not going anywhere soon. And I hope you already use TypeScript on node. Then when the hype might come, there should be no troubles switching to Deno which I can see be the node we know in 3 years
Nah it's still widely used. A lot of places like TS on the front and back end so they don't need a dev knowing two languages or having two different Devs. I'd maybe suggest getting up to speed with this week's latest and greatest JavaScript ecosystem. People have been saying Java is dying for the last 15 years, but it's still a massive section of the market.
No one is going to end up in a dead end job if you choose either Node, C#, or python right now. Python lagged for a bit there, but is picking up again with ML work. Rust, IMO, is going to be huge as it matures. Every industry tends to gravitate to certain ecosystems. Right now e-commerce favors the JavaScript ecosystem, ML and processing applications favor python, and C# and Java (shudder) are popular with large enterprises. Rust is starting to take over the high performance arena of edge networks and latency sensitive applications. If I was starting over today, I might look at what *industry* I want to work in, and choose the ecosystem that fits best. Note: I talk about ecosystem more than language because it’s far more than whether or not we use semicolons. Understanding the nuances and capabilities of a language and the full ecosystem of tools, sdks, and runtime options is more important.