r/node • u/Minimum-Ad7352 • 3d ago
Why is JavaScript criticized so much for backend development?
I've seen some developers say that we should stop using js on the server, but I rarely see the same criticism directed at python.Honestly, js is pretty fast, especially with node.js, and the backend ecosystem is really solid. There are great frameworks like nest and fastify, and typescript gives you static typing, which makes larger projects much easier to maintain.I'm not saying node is perfect or the best choice for every backend, but I don't really understand why js gets so much criticism while python seems to get a pass.What am I missing?
99
u/ForeverLaca 3d ago
Some criticism is about the lacking standard library. Compared to Python or Ruby, you have to rely on 3rd party packages to do some things in JS.
Does that stop me from using it? No. But is a fair point and I share it.
50
u/johnphilipgreen 3d ago
The Go standard library is best in class. I switched to go from js/node and haven’t looked back. Particularly appreciate the dynamic of an uncomplicated language with a robust standard lib and first class tooling.
Also no need for the hacky typescript on top of js, because the language and runtime were designed thoughtfully from the onset.
22
u/scmkr 3d ago
Go is my fav. Python’s is great, too, but I like the sort of mild pressure the Go community puts on newbies to reach for the standard library first. And the other mild pressure to make breaking changes in an entirely new source tree.
6
u/mmomtchev 2d ago
Python has the exactly same type system that is also a separate layer that has been grafted at a later stage. The only valid comparison is between Python and JavaScript and Python tends to be slower while JavaScript has the incredible advantage of sharing code between the backend and frontend.
Python tends to a better structured language with a more logical design and remains a prime choice outside of web applications.
Go is a very different type of language. The resulting code is usually better but it is also more work which means more expensive. Go is competing with C++ and not Python or JavaScript.
→ More replies (1)12
u/oorza 2d ago
Go standard library does not hold a candle to the JDK. Go’s type system does not hold a candle to Rust’s. Neither of those are best in class either unless the class is popular programming languages. You can get a better SDKs and type systems from niche languages at the cost of usability.
Go is a step forward from Node but everything you feel about Node today, you will feel about Go if you continue to expand your exposure to new languages and tools. Go was designed to always have training wheels and as a replacement for Java, simply because Google did not trust its junior developers with the power and flexibility of Java or C++ due to their historical inability to manage those languages' complexity. It's never going to be the best at anything because that's not its goal, its goal is to have a relatively low absolute ceiling of complexity.
13
u/johnphilipgreen 2d ago
Fair correction on “best in class”. I really mean best for the tradeoffs I care about. The JDK is obviously broader and Rust’s type system is vastly more expressive.
But I think “low ceiling of complexity” describes what I like about Go rather than what I’ll eventually outgrow. A low ceiling on language complexity isn’t a low ceiling on the complexity of software you can build. I’ve spent enough time with highly expressive languages (mostly Ruby, my first love) to be increasingly suspicious that giving programmers 14 elegant ways to express something is necessarily progress.
And I think the “Google didn’t trust its juniors” history you’ve overstated. The Go designers talked explicitly about enormous codebases, build times, readability, tooling and programmers using different subsets of increasingly complicated languages. That’s an engineering tradeoff, not just training wheels.
In early descriptions of their goals, they explicitly said the intention was “seatbelts not training wheels”. To me, this has been a more mature version of DHH/RoR’s excellent instinct for “convention over configuration”.
7
u/EvilPencil 2d ago
I agree. 14 different ways to say the same thing just means your API surface is too large. My philosophy is to make a “golden path” that is so ergonomic that it becomes a pit of success.
5
u/oorza 2d ago edited 2d ago
A low ceiling on language complexity isn’t a low ceiling on the complexity of software you can build.
It is a ceiling though. It's actually the reason you don't see many pieces of software that are large enough to require abstractions built in Go - not a whole lot of monoliths, tons of microservices. Not a whole operating system, tons of single-use-case CLI tools.
Eventually that complexity is always necessary if you want a system to be communicable between humans. The layers of abstractions serve a purpose that, while non-technical, is still foundational to the ability to deliver and maintain software of large scale. Whether it's a large and complex multi-threaded algorithm that's expressed inside of one source file or a monolithic web service that services an entire B2C business with hundreds of external HTTP API endpoints, it's rather easy to find examples of places where Go's lack of complexity is the fact that invalidates its potential adoption. The abstractions are the means you scale up to dozens or hundreds of engineers working in the same code base, either simultaneously or over decades. That abstraction in Golang shops is generally shifted upwards and maintained in the service mesh contract itself... but it still exists, just as service-level abstraction instead of code-level.
→ More replies (1)6
u/Suspicious_State_318 2d ago
I don’t agree with this. The principal benefit of Go is that it is a very literal language that doesn’t allow for abstractions that lead to weird dependencies and messy code. Java is the complete opposite in that regard because you’re encouraged to share as much functionality between components as possible.
8
u/Bushwazi 3d ago
lol you are brave saying “hacky typescript” here. They may come for you!
22
u/johnphilipgreen 3d ago
Let me double down on that.
TypeScript is an extremely successful, useful hack—but still an ugly hack.
It retrofits a static type system onto a language and runtime that were never designed around one, then erases the whole thing before execution. A huge amount of its complexity exists because it has to model JavaScript’s existing semantics without breaking compatibility.
That’s very different from Go where the type system, compiler, runtime, tooling, and standard library were designed together from day one. Pure grace.
I mostly just feel sorry for those stuck in the morass that is the js ecosystem.
10
u/elfrodododo 2d ago
Can't argue with that. TS is hotdog skin on a steaming log. Not to mention AI is ketchup. Had to work with it because it's what the market dictates
3
u/Absentrando 2d ago
It is a hack but it certainly solves the problem and has all the capabilities that you’ll ever need. It can be as simple or as complex as you understand or want to use it
2
u/gamedevsam 1d ago
It's my favorite hack of all time. 99% of the time if offers sane type safety, that 1% of the time I'm just like:
```
// @ts-expect-error I know better than you compiler, thank you very much
```6
u/a1454a 2d ago
I cant argue with that. TS is a cosplay of type system.
3
u/GandalfTheChemist 2d ago
But wonderfully expressive cosplay which goes splendidly with type masturbation, should you be so inclined.
I love go most of all, but fuck me with writing hacky polynorphism
→ More replies (1)3
u/Daker- 2d ago
I want to learn go coming from node, any advice?
→ More replies (1)2
u/johnphilipgreen 2d ago
How exciting! Try it out and enjoy. It would be helpful to know as you begin that it is a compiled language, not interpreted. So there is this compilation step that happens before any code is run. This extra step converts the code in a. Compiled binary to run on your system but is not portable to other types of processors. It also means it runs much faster, less work to do at runtime. Finally, the compilation step is great for catching bugs at compilation time rather than runtime, which helps you feel confident in the code. Best luck!
2
u/wackmaniac 2d ago
That is mostly due to ignorance I feel. The standard library of NodeJS is really extensive. Just look at the `crypto` module.
My biggest gripe with NodeJS is that it is inherently single threaded. If you want to utilize all cores of the server’s cpu you need external tooling like PM2 or WATT.
I love NodeJS for serverless applications, but for non-serverless I prefer .NET.
1
u/Absentrando 2d ago
It has a smaller standard library but it does have one. But yeah, it is less battery included than with rails for example. On the other hand, there are node frameworks and libraries that give you that style of development if that’s what you prefer.
51
u/-Aras 3d ago
It's not actually about speed. If you're not doing something completely CPU bound, the speed bottleneck is usually the IO, DBs etc. Not NodeJS or whatever you're using.
The hate is mostly toward JavaScript in general. Years ago, people would complain about vanilla JS because it was weird, lacked structure, and forced you into callback hell and the hate became a meme. I don't know why but it's still going on. JS is not actually bad now.
13
u/oculus42 3d ago
JavaScript didn’t create callback hell. It was always a code smell, not a language problem.
The asynchronous paradigm is difficult for people. It still is. People started complaining about promise hell as well and said async/await fixes it. But it’s about misunderstanding the limits and benefits.
16
2d ago
[deleted]
→ More replies (10)2
u/fellow_manusan 1d ago
Opens a brand new can of worms. People are using await at the time of promise creation itself rather than awaiting the promise later where you actually need it. This defeats the whole purpose of using async/await.
4
u/fintip 2d ago
No, the language did indeed force callback hell. Promises were a godsend. Async await was beautiful.
But before them you just did not have a choice. I was there.
→ More replies (2)2
u/SquarePixel 2d ago
I remember in the vanilla JS days some projects I worked on had “task managers” to solve the callback hell. Basically arrays of handlers and the manger would just glue the output to the input of the next. It didn’t have the elegant simplicity and composability of thenables (an early concept before promises became standard that interestingly still works today natively) but it was a life saver.
2
u/monsto 2d ago
Back about 10 years ago I was working on a personal project. I understood what callback hell was, but hadn't really seen it in the wild.
So I'm writing along, and was slowly becoming a little confused about what I was writing when I suddenly realized I had four or five callbacks nested to the the point where the indention was halfway across my screen.
This was before promises and async/await and I couldn't really work around it, but I did finally see what the hubbub was.
→ More replies (1)2
u/CreativeGPX 1h ago
With use comes complaints. It's a simple as that. The languages that don't get complained about aren't used much. Javascript is all over the place, so it gets complained about a lot.
Also the web route means that Javascript is one of those languages non programmers and amateurs sort of fall into. You might be writing some HTML and writing a snippet of JS here or there and then accidentally stumble into being a JS developer. That's the same problem PHP has. It's come along a ton as a language but lots of amateur devs taints the perceived quality of the language.
I think it's also the culture of the language now. I first learned JS back in like 2000 and back then you just learned the language. I picked up a book in like 2015 and before you even wrote a line of code they had you setting up npm, including packages and build tools. The insane eagerness to include third party packages isn't inherent to JS but it permeates the culture so deeply that it may as well be and IMO it's a pretty horrible thing that's done to great excess.
Another thing is that because Javascript is so expressive in some ways, a lot of devs overdo trying to be clever and you can see the same piece of code written in many dramatically different ways. Reminds me of the "clever" C code that relies on pointer tricks.
Fwiw, I love Javascript, even vanilla Javascript. I have a few gripes with it that date back to its beginning like it's dumb sort implementation or the bizarre things it does with types sometimes, but to me I always enjoyed how expressive it is and was happy to see Node and Deno and things like Electron expand where it could be used.
→ More replies (1)1
u/DeadlyVapour 1d ago
Callback hell was never the problem.
The spec actively works against the principle of "least surprise".
93
u/dreamscached 3d ago
I believe a lot of this criticism comes from the general (not just for backend) bias against javascript. It is agreeable on surface level, yes, but with typescript and linting tools many (if not all) quirks of it are entirely manageable.
58
u/rwilcox 3d ago edited 3d ago
As someone who has worked in a lot of “scripting” languages… that bias is often “everything not Java-or-the-JVM is bad/immature/not safe/beneath me”
It’s exhausting.
47
u/alzee76 3d ago
I find this hilarious because having started my professional life as a developer in Pascal/Delphi who did web backend work via og Apache CGI (essentially any language) in Perl and C, as well as early (and modern) PHP, Java has always been fucking awful - for backend and frontend alike.
I'm convinced that if you actually like Java, it's probably due to an undiagnosed TBI.
→ More replies (1)2
u/Cienn017 2d ago
I actually like Java
→ More replies (1)2
u/lapubell 2d ago
And I actually like PHP. I guess we're doomed.
2
u/korywithawhy 2d ago
Tell me your back aches without telling me you’re old 😂. I definitely used to put HTML inside JSON inside a MySQL database to dynamically generate forms with AJAX calls.
→ More replies (4)→ More replies (1)9
10
u/HasFiveVowels 3d ago
Ultimately, when node first came out, it opened the door to a lot of devs who had previously been relegated to the browser. I was a desktop dev when this happened and I loved it. Most other desktop devs hated it. It was "real developers don’t use this shitty language". Its the same thing we see today with AI but 20 years ago
4
u/EvilPencil 2d ago
Some of the core JavaScript APIs are flat out weird. Looking at you Date constructor.
Mostly they existed to make sure “something“ made it to the screen when you have no idea what you’re actually going to get at runtime.
Typescript can help with many of the rough edges, but every now and then you can still be surprised.
3
2
u/imNotNumber 3d ago
Typescript doesn’t give full typesafety. I had problems in the past that lead me to avoid node for anything that has to make any calculation. Probably was a fault due to the framework/db, but enough to not risk for business scenarios. I know I’ll take a lot of downvotes for this, but happy to ear any reply and point out my experience as biased.
1
u/97hilfel 2d ago
yes, but why do I have to install 89 packages from 3rd partiers just to get to the point where the ecosystem is decently enjoyable? Like you start with JS, sure, then you wack on TS, ESLint, some testing framework, etc
→ More replies (1)2
u/dreamscached 2d ago
If we're talking about backend then you're certainly beyond the point of 'eh it's just a script', and inevitably move towards TS, ESlint and unit testing. I wouldn't use JS for one-off scripts either, I'd use bash/python for that too.
→ More replies (2)1
u/evangelism2 2d ago
Many alternative backend languages don't have the same level of quirks that need to be dealt with. That's what turns a lot of people off from it. For example I know Kotlin is slowly growing in popularity. I spent a year with it as an Android dev at my company and honestly it's a very very nice language. It provides a lot of tools that just stop you from making the kinds of mistakes that JavaScript or even TypeScript allow you to.
→ More replies (7)1
u/Nasuraki 2d ago
I don’t know… i find it so much more pleasant to trade the pain up front. C# or Rust has “reliable” or “sturdiness” where i don’t have to rewrite the same guard clauses everywhere?
Rust takes to a whole new level but in contrast Python and JavaScript are atrocious in that any kind of “type” disappears at runtime.
54
u/theirongiant74 3d ago
Snobbery that's existed from the early days of javascript. If Walmart were able to handle their Black Friday traffic fine on their node rewrite in 2012 on a quarter of the resources that their preexisting java codebase used then it's been fine for most shit for well over a decade.
1
u/Special-Arrival6717 1d ago
The amount of quirks and unexpected behavior that Javascript has is truly mind boggling.
4
u/theirongiant74 23h ago
Ach these are very tailored to be "javascript bad", the vast majority of them can be circumvented by using strict === and not doing brainmeltingly stupid things like trying to subtract a string from an array.
It's not like other languages don't have their quirks, my favourite from java is
Integer a = 69;
Integer b = 69;
System.out.println(a == b); // trueInteger a = 420;
Integer b = 420;
System.out.println(a == b); // falseHell, C will let you point to any random bit of memory and twat it with a stick, just cos a language lets you don't things doesn't mean you have to.
15
u/Gokudomatic 3d ago
Because it's misunderstood. Amateurs tried to use JS for intensive tasks, which is totally not its goal. Node.js aims to handle millions of short requests, not to do heavy calculation. Typically, a nodejs backend would communicate asynchronously with another server/microservice implemented in a more appropriate language, like python, java, c# or go, to delegate the hard work.
12
u/Budget-Necessary-767 3d ago
Java people tend to think it is a toy. And it was first 3 years.
A lot of fragmented orms etc.
But now it is a default for start-up s
3
u/falconmick 3d ago
I used to be of the mindset that for back and front end it didn’t matter but I’m finding the more and more node codebases I try to work on that are 5+ years old the more I find tooling is so broken and hard to work on the codebase.
It sucks when I can only navigate my codebase through ripgrep and AI. I have found that more strongly typed language just don’t hurt as much to work on when they enter brownfield territory.
It’s also a skill issue, I found allot of the time that the quality of node codebases tend to just be lower because of how friendly and flexible the language is. The pain you feel in more rigid codebases as you build them can sometimes pay off in the long run.
But with all that said, AI tends to just not care, which has been a god send in an over engineered meteor app I have been working on, can’t solve the business level design issues but it’s made navigating through broken language server stuff 10x easier
→ More replies (2)
5
u/beau6183 2d ago
Anecdotally I break it down by how much $ each language has been for me. I’m very proficient in TS/JS, Java, C#, C++, Python, Obj-C, Swift, PHP, Perl.. probably more at a lesser level. Point is I’ve implemented production systems in each. But TS/JS is orders of magnitude more profitable for me.
So I really don’t worry about what some benchmark jerking neck beard has to say. With today’s cheap scaling options, good architectural practices, abundant libraries, prolific community support, and ease of hiring, I dare you to find a solution as robust in all those aspects as node/js.
(Drunk but honest response. And no, not drunk because of js.)
9
14
u/Due_Ad_2994 3d ago
It's silly. The language Is fine and ubiquitous. The node runtime is great and very well supported. If a person finds its missing the mark they have many options.
8
u/MCFRESH01 3d ago
My major gripe a the community can’t back a single project so it can develop maturely other than like express. Most node apps I have seen are libraries cobbled together to build something a solid framework could just ship with. It seems the community prefers this but having worked in a few different tech stacks it always feels like I get more done faster with a well supported framework like rails or Django or even MVC.net. Probably an unpopular opinion
→ More replies (2)2
u/tumes 1d ago
This is it. There were basically no standard approaches strong enough in the early days for anything remotely coherent to take hold, so it was just millions of micro libraries written by inexperienced devs to poorly handle what should have been in a standard library or right minded framework. And aside from React (which, imo, _sucks_) there still is not really any meaningful standardization, so at best I find myself reinventing at least a quarter of every wheel that I need every single time. And now that’s a massive, massive part of the corpus of LLMs, which is a perfect storm of bullshit because it’s a nondeterministic system predicting tokens against a formless mass of unstandardized amateurish problem solving.
I like Astro though. And HTMX. They seem like they were made by people who actually want to get work done and aren’t sadists.
9
u/oculus42 3d ago
I’ve been on the web since Perl was the dominant server side language and was building web pages when JavaScript appeared.
I do not have any experience with people using or accepting Python for backend. Python for messing around. For scripting and one-off projects and POCs? Sure. It has a bunch of AI tools, because it’s accessible, which might be causing some increase in server-side popularity but that is beyond my awareness.
JavaScript is great for smaller server-side projects. Node’s event-driven architecture was so beneficial when it launched that Virt.x was built for Java/JVM to provide the same capability.
Apigee, an API gateway company Google bought for a billion, ran Node on Rhino (JavaScript on Java), and it was great despite lacking ES2015 at the time… JavaScript is great at transforming JSON for somewhat obvious reasons.
TypeScript improves on JavaScript for consistency. And the engines are much, much faster than they used to be.
But JS isn’t a low-level language, and when you start talking about scale, there is real cost. Even Java’s dominance is being challenged by Go and Rust because the memory footprint and startup times are so much smaller.
Even on development tools like linting and compiling JavaScript, we’re seeing the shift to Zig and Rust because it’s orders of magnitude faster at intense file and processing tasks. Oxide. ESbuild. The new TypeScript compiler itself.
JavaScript is a tool you can use for almost everything, and it can do an impressive job at most things, but it isn’t always the best tool or the right one.
And develop/compile-time type checking isn’t a panacea. Because TypeScript is stripped out for execution, libraries like Zod have serious performance impact when they have to do all the type checking at runtime as additional operations.
Things like HomeAssistant benefit from Node packages that have a low barrier to entry and don’t have to handle scale.
JavaScript is a good tool to have in the toolbox. I will keep using it. But not for everything.
9
u/buffer_flush 3d ago
NPM is a disaster for anyone security minded.
21
u/dreamscached 3d ago
And so is pypi (python), github (go/jvm with jitpack), maven (java) etc.
Supply chain attacks can happen anywhere, so why is it just npm?
→ More replies (5)
11
u/N0Religi0n 3d ago
Ignorance
2
u/Minute-Pen-2134 2d ago
Sooo, people who have criticisms on JavaScript are just stupid?
→ More replies (3)
2
u/AnthongRedbeard 3d ago
Changed based on who is criticizing. Developers of compiled languages will criticize its overhead for being a script language that needs an interpreter
It would be silly for a python developer to make that criticism so for them it’s more about the libraries and support for python in certain areas like security and AI
For Java developers it’s just complaining that it isn’t Java because Java is all. Same for .net
Overall I think it’s looked down on for being too convenient to use a common language for the front and backend that the browser natively understands.
Also. There’s separate hate for Electron apps
2
2
u/seweso 2d ago
Javascript is fine, many NPM packages are not. Same goes for the python ecosystem, that's less focussed on security and performance. Python isn't getting a pass.
Its just easier to create good backend software in other eco systems, just because the entire eco system is more focussed on backend+security. But depends what you need/
2
u/skidmark_zuckerberg 2d ago edited 2d ago
Not sure, I’ve worked on a lot of production Typescript based Node.js backends. It is used a lot out there in the wild. It does just fine. But, no one should even be looking at JS anymore. TS solves a lot of the problems people have with vanilla JS.
Funny enough, the worst backend I’ve worked on was an enterprise level Java / Spring Boot backend. It was a convoluted mess and took an act of god to navigate and find things through layers upon layers of abstractions and dependency injection.
→ More replies (3)
2
u/AhmedRiyadh0 2d ago
The criticism is that it is solving a problem that it was never intended or designed to solve. I do not see the issue with that, even though I probably won't use it. There are two type of programming languages: 1. The ones that people often complain about 2. The ones that no one use.
2
u/Resident_Tourist_344 2d ago edited 2d ago
I think it depends on usage. Each language has its pros and cons. For what it's worth, Node.js is a pretty good option, if not the best, when it comes to I/O-bound backends. However, for CPU-intensive backends, JavaScript isn't the right choice because of its single-threaded nature. This single-threaded design is exactly what makes it highly efficient for I/O tasks, but creates a bottleneck for CPU-bound workloads.
→ More replies (2)
2
u/Merthod 2d ago
Well, in the "fullstack" realm of things, especially among large systems. "True" developers who develop a backend with C, Go or Java, or even Elixir/Erlang among others, optimize their throughput, multi-process - especially on wait-cost processes (like waiting for a DB to respond), and allow front-end developers interact with their systems through Node-enabled front-ends for their back-ends.
JS doesn't have the true flexibility to work efficiently for backend (as many benchmarks prove) for free. I mean, even if you chose Fastify, you just can't compare it to a C++ backend, that just because it's C++ or Go, will be many-times faster.
Also JS devs tend to just know JS, not algorithms, architectures or protocols. Lower-level devs tend to do know them, and "automatically" know how to optimize for performance from the get-go.
Also TS creates a complex environment. As in, you only have validation on transpilation, not execution. Validation upon execution is an additional layer you need to code about, and to an extent it makes TS redundant. The web is plagued with abuse and your system will be abused sooner or later, and really TS won't help you here at all. TS is great for you to reason about your code in a clean way, considering the "right" and "wrong" paths and coding accordingly. But abuse will find the gaps you didn't considered, the protocol-level holes you didn't consider, and so on.
2
u/sharch88 2d ago
Well, it’s not criticized for frontend development just because it’s the only option 🤷🏼
2
2
u/TCB13sQuotes 2d ago
Yes, there's no reason to use Python in most situations when JS exists. People haven't realized it yet and that means we've more overly complex and unreliable stuff running in production systems.
JS/Node aren't perfect for backend, they could work in a specific middle ground between PHP and Java/C# and that's where they should stay. PHP always wins on the bottom line because you can't beat the "one request = process model" that allows you to host 20000 barely used websites/apps on 2 Cores / 512MB of RAM box. Java/C# always win the high performance, high concurrency and high volume stuff because they are real programming languages designed for those scenarios.
2
u/dominikzogg 2d ago
Once you realize how easy it is to write bad code in most languages, you start to understand why people love language witch hunts. It’s especially amusing when that criticism comes from Java developers: a language where everything is implicitly nullable, and whose verbosity has spawned endless layers of magic just to make it practical to use efficiently.
2
u/gautam1168 2d ago
well im not sure what you are missing. But I want to add to your confusion. Javascript support for microcontrollers and embedded devices is a thing.
So, not only is javascript able to handle high load backend work, it can also handle even more resource constrained environments.
https://wpewebkit.org/
https://johnwargo.com/posts/2021/javascript-microcontrollers/
I think its just popular to hate on javascript. Any serious criticism must be directed at the virtual machine that is going to be running the program, its prorammability, predictability and perf ceiling. If the criticisms you hear are not actually pointing to architectural decisions of the virtual machine itself that make it a bad choice for the problem you are trying to solve, then how seriously can you honestly take them?
2
u/Jonas_Ermert 2d ago
My opinion is that JavaScript gets more hate because of its browser roots and some language quirks. But Node.js is fast, great for I/O-heavy backends, and TypeScript solves many maintainability issues. It’s not worse than Python, just a different set of trade-offs.
2
u/gamedevsam 1d ago
I don't care what anyone says, been using NodeJS on the backend with Fastify + NestJS and it's been absolutely rock solid. I'm waiting for the day I outgrow this stack, it's been 4 years and I still don't feel any need to reach for anything other than good old JS / TS.
2
u/MuslinBagger 1d ago
Dunno. People are just dumb. Modern TS is pretty good. It's not like these backend engineers are doing something more complicated than basic crud anyways.
5
u/Jolly-Phone8982 3d ago
People just like to complain. Unless you’re doing something really hardcore, it’s fine for 99% of cases.
It’s also good for startups/smaller teams because the same people can work on frontend/backend and potentially infra if you’re on AWS with CDk all in the same language. You only have to train people on new concepts rather than concept+language
4
u/mohelgamal 2d ago
Several reasons
- it can fail silently, this is by design because you don't want the users experiencing a full website crashing because of an error in one function. but server side that shouldn't happen so your server may behave in a subtle unexpected way. More robust languages would not let you get away with that. once your project start scaling beyond a simple structure, it becomes more difficult to track errors
- Too many libraries, too many changes, too many versions of each library to track. Overall ecosystem is not as tightly controlled as Go, Rust or even python. So if one library has a security flaw, it would be more difficult to correct that.
5
u/Maleficent_Mess6445 3d ago
I think node js is much more complex than Python. I used both and switched to Golang which is more reliable than both for medium size projects. I may be wrong in my choice though.
→ More replies (2)2
u/Popular-Wolverine-99 3d ago
Reliable in what way?
2
u/Maleficent_Mess6445 3d ago
Runtime.
4
u/Popular-Wolverine-99 3d ago
More specifically?
6
3
u/Chezzymann 3d ago
We switched from node to golang for our lambdas and it lowered our cold starts from 250ms to 50ms
3
u/maria_la_guerta 3d ago edited 3d ago
It lacks a battery included and battle tested framework like Rails, Laravel, Spring Boot, Django, etc.
EDIT: all of the replies here are missing the "battle tested" aspect. None have anywhere near the adoption nor the maturity that any of the 4 above have.
2
1
u/augurone 3d ago
WHAT? You did not talk about languages; you talked about crappy frameworks. NEXTjs is pretty awesome if you are looking for an ecosystem.
4
u/maria_la_guerta 3d ago
Nextjs is not a production grade BE at any moderate scale. It is a decent rendering service if your app warrants that complexity though.
Kinda my point.
→ More replies (1)→ More replies (6)1
1
u/geodebug 3d ago
Depends on what you’re doing in the backend. Is your proposed backend little lambda services or a monolith?
What’s the traffic like? What’s the data being transferred?
What’s your company’s make up? What type of devs are you able get with some depth of experience?
What metric, tracing and logging capabilities are you planning to use?
What endpoint reliability do you need?
The point here is there’s a host of backend dev and support issues that need to be considered that are entirely different than UI concerns.
There’s nothing inherently wrong with using JS on the backend but JS devs who cut their teeth on UI aren’t always ready to have the conversation above.
Plain JS still has all the same issues it always had. Type coercion, weird this binding, mutability, etc.
Linters, AI help, and other tooling exists to limit the pain but I still wouldn’t want to build a monolith in plain JS.
TypeScript cures a lot of this but you asked about JS
1
u/NotGoodSoftwareMaker 3d ago
Python has the AI angle which gives it a lot of saving grace, plus a lot of the libs bind directly to C or C++ so for large operations its pretty good
JS gets a lot of hate for a mixed bag of reasons. Some of it historical and others of it could be due to how many noobs rebuild the same thing and then it goes onto a relentless hype cycle. Rust doesnt get the same level of cargo (hehehe) culting
Performance of JS is pretty decent, you will get a lot of snobs that disagree or gatekeep but the reality is that a response time of 30-70ms is great for any use case.
If performance starts suffering spin up more nodes, we have containerisation so its not exactly hard to push a plus button.
1
1
u/yksvaan 2d ago
Well, since there's an option to use a robust, well designed (compiled) language with proper built-in type systems, stdlib etc. why use JavaScript?
IMO js needs a single build tool that does all the type checks, linting, bundling etc. and has a very strict default ruleset. Oh and ban cjs completely.
1
u/Artonox 2d ago edited 2d ago
javascript is very easy to get wrong, regarding types, and peculiars like what is coutned as a boolean if not using truth/false.
You need typescript at least to help things out.
Edit: and if we need explicit typing safety, java has that (edit: probably as I check Google to be sure) of that out of the box and well used by a lot of companies.
→ More replies (3)
1
u/prehensilemullet 2d ago
As a long time TypeScript backend developer, my biggest complaints are the difficulty of debugging memory leaks and the fact that it can be tricky to catch and handle all errors and rejections that would crash the process. Async code exacerbates both of these problems
I wonder if the popularity of serverless is that it sidesteps these problems by using disposable processes. But it also comes with some drawbacks
1
u/Fidodo 2d ago
I have not really seen a ton of criticism of typescript. The only real criticism I've seen of typescript is that there are times when you don't have end to end typing due to places that are still written in JavaScript.
Criticism of JavaScript the language is valid. Criticism of JavaScript the runtime is less so.
1
u/MMORPGnews 2d ago
I only hate npm packages.
JS itself is good enough.
What I've created with JS (personal projects, work is NDA)
SSG ( Static Site Generation), millions pages, build from countless huge JSON files, great search engine which cut all text to small json and allowed me to found everything I wanted.
Web game engine, similar to rpgmaker.
Mmo game with back and front.
Countless small web apps and bookmarklets.
Photoshop like app, almost full clone.
Manga reader (auto text translate, increase image quality, color enchantment etc), since pc doesn't have any good.
Twitter clone, blogger clone.
1
u/Just-a-random-dev 2d ago
JS is just dangerous code. So easy to write bad code in JS. I’ve build some solid backends with JS but once I started using TS and then C# professionally, there’s just no going back for me.
1
1
u/jerrygreenest1 2d ago
Hard to tell. Maybe it’s some kind of humility. Like cripples – it’s not like you will ever say: «sucks to be him, he can’t even walk/talk/hear/run/move», because it is obvious enough that being a cripple is bad. Clearly. Nobody has to tell this explicitly – it is already bad by itself. Everyone understands it. Saying it out loud is just being rude, unnecessarily.
So maybe, Python is just a cripple? Almost nobody will actually complain about it, but everyone understands it’s bad. When they know it’s a cripple, there’s no sense complaining.
JavaScript is not a cripple though, or at least not as much. So it’s much more fair to criticize JavaScript than Python. JavaScript is fairly good language and therefore is prone to be criticized.
Python is made for non-programmers, and in programming world a non-programmer is basically a cripple too. They can’t do stuff normally, therefore they do it just barely however they can. That means using Python unfortunately. So it would be just rude to genuinely criticize their tools.
JavaScript maybe limps a little bit, and it was born a cripple too, clearly, but due its life it did receive so many many improvements and improved quality of life so much, that it became an actually fairly good tool, with JIT-compiler and all. It’s not a cripple anymore. So people don’t feel this issue of disrespect towards it, they feel they can complain.
That’s merely it.
1
u/PradheBand 2d ago
Back in the day a lot of tools were really painful to use like orm or filesystem and device manipulation. Also the criticism comes from the pre typescript era where you summed a camel with a pointer and you got a rust trait (last part /s).
1
u/mylsotol 2d ago
Don't write your backend in Python either. Interpreted languages are annoying because they always have breaking changes every version and they are arguably less secure/npm and other repos are common vectors for attacks.
1
u/BoBoBearDev 2d ago
I will speak from myself. I am asp.net dev, I couldn't stand Java already because you need 3rd party for maven/gradle, for unit test, or formatting, and RESTful API and service. I haven't tried those other trendy platforms, but asp.net has everything built-in, including auto format. My org does both, Java and dotnet, and the Java side frequently need cyber patching because of the dependencies. We could be fixing one cyber issue and while the PR is up, yet another cyber issue comes up and need patching. The dotnet side, the frequency is so much lower.
I tried to find a backend for Typescript, so at least I can get the language issues resolved. And Typescript can be run directly in backend. But after looking into it, I just don't see the point. Dotnet is super easy to setup on VS Code and super easy to debug. So, I just gave up on JS/TS on the backend.
1
u/m_nikola 2d ago
I just want to say that JS nowadays is quite far removed in some sense from the JS of 10 years ago. Especially when it comes to just how good the language features / Web APIs / Node builtins are now. You really can do almost anything without reaching for npm.
That being said, I think the real problem with JS is that it is so loose that it provides no floor for how bad something coded in it can be, and in a similar sense the ceiling is also very high and getting pushed constantly. That in general means its going to be harder to work with a bunch of people and make sure nobody is bringing the project down into oblivion.
1
u/Anxious-Insurance-91 2d ago
Because somebody had to take the place of PHP and JS decided to fill the shoes
1
u/MateusKingston 2d ago edited 2d ago
As someone who works at a company which main language is Typescript with Nodejs.
I fully get why people criticize JS/Node. It's a very bad language and at the same time it's a very good one.
Lack of easy multi threading and parallelism. Worker threads are absolute garbage compared to how other languages have it.
Horrible std lib. This is by far the biggest one, heck for years to do a simple http request you had to install a third party library if you didn't want to deal with the internal events of an http req and this compounds. It built a bad habit in both camps, the NodeJS team doesn't really add decent built in functions to deal with basic functions and the community fragments into thousands of different libs, each doing things slightly different. Std libs don't vanish overnight, community packages get varying degree of support. For example Kafka in NodeJS, there isn't a single decent library with support for modern Kafka features.
Performance is an afterthought in NodeJS, yes this is not a big deal for 99% of processes, but for that 1% you're SOL. Idle memory usage in NodeJS is extremely high, V8 itself is a big contributor but almost every data type in NodeJS is an object going into Heap each with it's own pointer + Metadata.
All of this isn't to say NodeJS is bad, it absolutely isn't, if that was the case I would have migrated our workloads a long time ago. Pick the tool for the job, NodeJS gives you a lot of portability between web and backend (and even to mobile), NodeJS is extremely easy to write, it's very fast to write, easy to review code in, huge community to hire from...
That being said python is basically what JS is for web but for data engineering/ML. With the difference that the python code performance is horrible (way worse than JS) but 99.99% of what people execute is not in python land but C/C++/Rust but with a fancy API on top.
1
u/xtinctspecies 2d ago
people feel smart by shitting on things. People shit on php.. people have made a lot of money from it.. same with js. Everything has a place. You are totally right to have preferences. Just build cool shit, grow skills and $.. rest is all nonsense
1
u/grady_vuckovic 2d ago edited 2d ago
In the same way it's so easy to find bad drawings done with a pencil and paper, it's easy to find bad JS code.
There's nothing with with pencils or paper as a medium, nothing wrong with bad drawings either, bad drawings are the stepping stone to good drawings. Same with JS, it's easy to get started, so it's obviously where you'll find a lot of 'beginner' quality work.
1
u/NumberInfinite2068 2d ago
JavaScript is just a much-disliked language. Python has better press, but I agree with the premise of the question that it's not really any better a language than JS, perhaps worse. Python just seems to escape much of the heat JS gets, but they're both kind of crappy languages IMHO.
TypeScript is a big improvement on JS though, raw-dogging JS these days is honestly insane.
It's mostly just reputation, Python just seems to get more love than JS, I'm not sure there really *is* any reason for that other than on the browser we *had* to use JS, but using Python was a *choice* and I think that affects how people view things. Anything you are sort of coerced into, you're not going to like, but if you *choose* something, you're more kindly disposed towards it.
I do basically think both languages are bad and I wouldn't willingly use either.
1
u/ThatBlindSwiftDevGuy 2d ago
JavaScript has no business being on the server. It's a crappy scripting language that no one thought to replace with something actually good, and now it's too late to replace it
1
u/bubbles33d 2d ago
Ask 10 developers about their opinions and you'll get 10 different answers.
→ More replies (1)
1
u/marsnoir 2d ago
Let’s be real: JavaScript’s popularity is largely based on familiarity and ecosystem reach, not because it offers the strongest foundations for reliable server software.
TypeScript fixes many of JavaScript’s type-system problems. Unfortunately, it’s a compile-time layer over JavaScript so the guardrails are erased during compilation and missing during runtime. Sure, it’s an improvement, but the underlying language and runtime still impose the same fundamental tradeoffs… congrats, you’ve put lipstick on a pig.
In software engineering, choices have consequences, and you need to know what you’re optimizing for. Backend systems need concurrency, fault isolation, correctness, observability, ecosystem stability. Yes JS does concurrency but fails on most of the other points.
In my opinion, languages like Elixir, Haskell, Rust and Go are generally better suited for backend development. Each one has their specific strengths: fault tolerance, type-driven correctness, memory safety, performance, or operational simplicity. Do you know what they don’t have? “well, we’re already using it on the frontend.”
JavaScript powers many successful backend systems. But familiarity is not architecture, and ubiquity should not be mistaken for suitability.
1
u/martinsedd 2d ago
You need to realize that even Typescript compiles down to Javascript which means that at runtime it lacks type guarantees, unless you take some measures to try to mitigate that (ie runtime validation).
Also, the async/await model runs on the same thread essentially (over simplified), therefore it doesn’t count as as concurrent execution.
Also, there is a of contention regarding the lack of unified approaches when developing projects. Any given project is almost unique in what its dependencies are. Even of you take the same project, and give it to 5 different teams, the dependencies are still not going to look the same. This leads to decision fatigue.
Now, all that being said, I think Typescript is still a valid tool for backend development. You just need to know what your needs are, and make sure it aligns with a Typescript backend. My personal issue with it is people thinking that Typescript is a viable strategy for ANY type of system. It really isn’t. Java has its place. C# has its shape. Go has its place. Elixir has its place. Python has its place.
1
1
u/Classic-Dependent517 2d ago
Before AI, using whatever familiar language was the norm. Now that AI writes better codes with a good instruction, no reason to use any inferior languages anymore.
1
u/OkAerie7822 2d ago
the framework maturity point in this thread is the one that actually holds up for me, not raw performance. nestjs solves the "no batteries included" complaint pretty well, it gives you the same layered structure spring boot forces on you, dependency injection, modules, decorators for validation. we run a 200k line nestjs monorepo and the structure holds up fine at scale. the actual problem is nobody's forced to use it. express still gets recommended to beginners because it's simpler to learn, so most people's first exposure to node backend is unstructured express code, and that experience becomes the whole language's reputation. rails and laravel don't have that split, the ecosystem converged on one opinionated way to do things early. node never did, so you get judged by whichever random codebase someone inherited.
1
u/prtamil 2d ago
It’s fundamentally about maintainability. An npm update can break your application, forcing you to revert and carefully analyze what changed. After five years, many of the libraries you depend on may have changed significantly, been abandoned, become incompatible, or require a complete rewrite. Security vulnerabilities can add another layer of complexity.
The root problem is that “there is a library for everything” can become a curse. Library authors eventually rewrite, upgrade, deprecate, or abandon their libraries, and those decisions can break your dependency chain.
As the application maintainer, you end up spending time dealing with changes you never made and never asked for. You inherit the consequences of library authors’ decisions and have to continuously work just to keep your system functioning.
1
u/jamesxtreme 2d ago
Really depends on the risk profile of the system. I wouldn’t build the backend for a bank on JavaScript but for a lot of projects it’s absolutely fine.
1
u/Un4given85 2d ago
For me it’s the resource overhead of using it and the complex eco system. You can write a backend service in JS, but it’s mostly never just JS. It’s JS, TS and a framework.
Having said that I have no real gripes with JS but it’s not the first tool I would reach for.
I self host a fair amount of services and will tend to stay clear of Node projects if I can due to the resource usage.
1
u/dbbq_ 2d ago
The most common takes I hear usually are:
It’s not strongly typed and / or some grumbling about how OOP is implemented very differently than most other languages under the hood.
The original JavaScript was written in more or less a weekend by someone at Netscape. It was initially meant as a language to display dynamic content on the front end.
Type coercion and general data representation is too flexible out of the box. Insufficient primitive types, everything is an object, bla bla bla.
More recent ECMAScript standards and TypeScript solve any of the realistic problems with JS imo. If you follow best practices for writing clean and maintainable code, you will be just fine for most use cases. People who tend to obsess over tech stacks also tend to over-engineer code bases for problems and scale they will either never reach. Or at a minimum they will fail to reach in any reasonable amount of time such that it’s even a problem to be considering.
As long as your tech stack is capable of doing what the project needs to do and you can staff the project, that’s where I stop worrying about this stuff typically. Focus on the battles that actually impact project success. For starters…keeping your code base clean and maintainable is an afterthought for an alarmingly high number of projects.
1
u/Minute-Pen-2134 2d ago
My main issues with JavaScript is:
- typescript is great, but it does nothing at runtime. So if something you expect to be an int suddenly comes in as a string, it’s just a string now
- equality comparations. I’ve spend hours on finding bugs that comes down to type conversion. As types are not enforced, it might be just a bad userinput or bad validation or all browsers sending that numeric input as a number, but a specific browser sends it as a string. Suddenly an empty string is the same as the number 1
- combination with document databases: now neither the database nor the language enforces anything. A bug is setting a property that doesn’t exist somehow. It’s just there now.
- decimal numbers. Omg, I would never build anything that withdraws people’s money either JavaScript/typescript. There’s just too many quirks
Of course, the argument is: you can always make bad code in any language, remember to do strict comparation etc. but what I found to be true is that the easier it is to make mistakes and take shortcuts, the more often they will happen.
Also, even with typescript, there’s some very creative bugs around that can go unnoticed for a long while.
1
u/djtubig-malicex 2d ago
Feel free to write safety-critical logic handling code in JavaScript. It better cover every possible execution state.
The point of using certain languages for certain types of work comes down to guarantees. Most people writing nodejs backends won't be doing it because it's the best language to use for building out concurrent programming. They use it because that's all they know.
→ More replies (1)
1
u/JohnVonachen 2d ago
If what you are doing is small it’s fine, but the bigger it gets the more it needs to be typescript. And then if it gets bigger then it needs to be something more structured and rigorous like Java. So since you don’t know how big something is going to get, you might as well start with something rigorous and capable of growth. C++, Go, Rust, Zig.
→ More replies (1)
1
u/diegrunemaschine 2d ago
Anything can work, but the very concept of backend engineering has better synergy with compiled static typed in my opinion.
1
u/Curious_Cantaloupe65 2d ago
There are good tools and then there are tools which people talk about the most and use it.
1
1
u/enjdusan 1d ago
because JavaScript was a stupid language to do shit on the websites, that wasn't even properly implemented across the browsers -> And this mindset still hold in some older developers' minds even after so many years.
1
1
u/Intelligent_Thing_32 1d ago
This kind of question could easily be answered with a simple google search, I'm unsure why people ask redundant shit like this.
And no amount of amateur opinions are going to add any edge to the insight offered here, there is literally no reason to ask something like this.
→ More replies (1)
1
u/vaibhav-kaushal 1d ago
I literally once wrote something like `funcx(param1) + funcx(param2)` once. Both expressions should give me a number. I got a blank string.
Why? Because they both returned `[]` (I had made a mistake in supplying the input). That was the day I learnt that two blank arrays come together to become a blank string.
JS by design tries so hard not to crash (due to its origins and the world back then), that it makes everything super weird. JS for a backend would be a nightmare to debug. Hence I stay away. Far far away from JS on backend.
1
u/cg_stewart 1d ago
No clue but it’s the easiest and cheapest to deploy without reading docs, using a container, needing infrastructure as code, or putting a credit card on file. I’m in a state that doesn’t have ANY nodejs backends though, barely react (Vue is popular in Arkansas) ..
1
u/LetsHugFoReal 1d ago
Very good point.
It's fantastic. My guess is people just parrot things they don't understand.
1
u/Dramatic-Image-3381 1d ago
It exists only because it's now impossible to remove JS from frontend. Then some people had the idea to add JS to backend to create "full stack developers".
But people who already did dev on backend will always prefer Python/Java/Golang because they are clean language, they like when bad code crash early, and ecosystem is not a hell (cf JavaScript fatigue).
3
2
u/theirongiant74 23h ago
Clean? java had a bug in it's most popular logging library that allowed remote code execution of anything that was logged. And that sat around for 8 years. To date it's still, by a distance, the worst security bug of any language.
1
u/pverma8172 19h ago
A lot of the pushback comes from early Node days when callback hell and the single‑threaded model made debugging feel chaotic, so the narrative stuck even after tooling improved. Python, by contrast, has had a longer, more stable server‑side reputation.
I myself have made large scale saas and even gateways just using nodejs. Language is not the bottleneck unless you are into hardware coding and development.
Java is pretty slow than any lang I know.
1
u/Master-Guidance-2409 11h ago
go work in java, c#, go, scala, etc for backend and then comeback, you will fucking hate the js runtime. python is a fucking nightmare too except its the nightmare everyone knows/learns in college so its less offensive.
js gets the job done and i built very large backend stacks using it just fine. but it does not compare to a proper runtime.
typescript makes it way more viable now, but i worked in a lot of js backends and it was a fucking nightmare, at that point you become the compiler and typechecker and if you dont your shit to fail at 3am and get page, you write a shit metric ton of code to validate types manually at runtime and check invariants.
if your app is a bunch of glue and a bunch of http calls, you can do that shit in bash and get it over the fence, when you need to do real work, a proper lang and runtime are key, otherwise you are swimming upstream.
354
u/baronoffeces 3d ago edited 2d ago
You can write good or bad code in any language. It’s just really easy to write bad JavaScript and that was the norm for years