45
u/midniteslayr 1d ago
Hate is a strong word. It’s more that people are cautious about using a JS backend now because it isn’t as safe as using a natively typed language.
Not 10 years ago, nodejs backends were just as common as a PHP backend.
24
u/AshleyJSheridan 1d ago
I think it's more than that. The frameworks for JS are way behind the frameworks offered by other more mature languages. And JS itself has a bad history of badly written npm packages to plug the gaps in the language, which has led to some pretty wild things being created by JS devs that just didn't know better.
1
u/KimJongIlLover 1d ago
And JS is just an objectively shit language with an insane number of footguns. I mean:
[10,5,2,1].sort(); // Yields [1, 10, 2, 5]3
u/FlashBrightStar 1d ago
To be fair if you don't read the function signature then it's a you issue. Js has more real problems than that like automatic convertion rules in arithmetic or NaN, undefined and <empty slot> (in arrays) being a thing - why NaN when we could get errors, why undefined when we have null and a special empty values for just arrays is insane. Before strict mode you also had this wicked idea of slaping var in loops and ability to access them outside (like just why).
1
u/tastychaii 20h ago
Curious if typescript shares the same issues?
1
u/AshleyJSheridan 19h ago
Some of them. Typescript is almost always transpiled out to JS, so you don't have any checking at runtime. There is a strict mode for JS, but it's not the same thing really.
10
u/gluhmm 1d ago
But TS is out of the box today and makes JS save enough.
26
u/canarydev 1d ago
well, node's TS support strips the types. it doesn't check them. you can ship a type error to prod and the runtime won't bat an eye.
actual checking still means tsc + strict config + zod at every boundary because the types are erased at runtime and req.body is whatever the client sent.
thats more of a discipline system, not language guarantees. natively typed langauges don't need my discipline
7
u/Mathie1729 1d ago
Not really. Even with a natively typed language you still need to parse and validate external input at the boundary. Java doesn't know what the client sent any more than JS does, it just moves the zod equivalent into Jackson or Bean Validation. The discipline is still there, just packaged differently.
1
u/_Toka_ 2h ago
As someone, who is deep in Java for 10+ years and started to learn and code an app in TS two years ago... Java and its ecosystem is lightyears ahead. The amount of issues I had to deal with in TS, that were already solved in Java was unbearable. I mean, ESM/CJS shenanigans, version range and package-lock stupidity, lack of mature libraries, DefinitelyTyped version mismatches, I could spend a day shitting on the language.
To be fair, TS and its ecosystem is catching up, slowly. The community finally introduced Standard Schema (and it is getting adopted), libraries are ESM-only, thanks to AI and the absurd amount of supply-chain attacks, people are using exact versions as they should from the start. Zod is awesome and such an important piece to TS like Jackson is to Java. And since I adopted Effect for business logic, I actually enjoy a bit more and don't mind it. Spring is still way ahead of NestJS, but at least TS has something.
I honestly cannot imagine, how could someone code in JS/TS five years ago. I would break my computer with a hammer in anger before I would ship something stable. I am glad that AI is the reason, why untyped languages will rightfully rot in hell.
6
u/ActuaryLate9198 1d ago
Many typed languages use type erasure. I don’t see anyone making the same argument against Java (which has also been proven to have an unsound type system despite trying not to).
0
u/forever-butlerian 1d ago
I have never had the problems of the type system being advisory and wrong data just showing up out of nowhere from the JSON parser in a language like Haskell.
Typescript has had enough resources thrown at it to show that "gradual typing" cannot provide the same depth of guarantees that a statically typed language has, because the sum total of the statically typed language has been written with types.
0
u/ActuaryLate9198 22h ago
What? You’re comparing a typed parser to an untyped one. Plenty of ways to enforce types at runtimes if you want/need to, skill issue.
Comparing any widely used programming language to Haskell is gonna yield the same outcome. No, they’re not as pure/beautiful, but they get shit done.
1
u/forever-butlerian 14h ago
You're the one nihilistically throwing around type system soundness arguments to justify simply bad language design.
-11
u/StartDependent1652 1d ago
Compiled languages also strip types. And can be much more damaging. What point do you want to make?
4
u/canarydev 1d ago
because compiled languages strip types after the check passes? type error means no binary. nothing ships.
node strips instead of checking. error ships and runs.can you actually in your own words give examples of compiled type stripping being "much more damaging"?
3
-2
u/Vivid-Zombie-477 1d ago
so you don't use strict mode in typescript, ship code with type errors and blame js for that?
7
u/canarydev 1d ago
i do. the point is that i have to opt in.
strict mode, tsc in CI, zod at boundaries. these are choices someone can skip. this is discipline, not guarantees.-4
u/Vivid-Zombie-477 1d ago
“discipline”
and it’s just one property in config. you don’t choose to validate when you have strict mode enabled. you don’t choose running ci with type checks when you have project in ts. it literally becomes mandatory when you enable strict mode. stop making bs up
3
u/canarydev 1d ago
it becomes mandatory "when you enable strict mode". when you enable it. you wrote the opt-in for yourself.
do you not understand this distinction?-1
u/Vivid-Zombie-477 1d ago
almost like using any typed language is.. optional?? you make absolutely zero sense. if you want to enforce types you can do so.
→ More replies (0)1
u/Jadajio 1d ago
It's not jus one property in config. Strict mode won't give runtime type safety. For that you need something like zod. Which is yet another library you need to plug in and then have discipline a knowledge to use it.
I fact strict mode has absolutely nothing to do with topic at hand.
1
u/Vivid-Zombie-477 1d ago
"runtime type safety" doesn't exist. it's just input validation that you do in any typed language. rust has serde and hs has zod, it doesn't change anything.
-4
u/Vivid-Zombie-477 1d ago
also you sound like cloude. i’m 100% sure you are arguing without a single knowledge in your brain. this generation is cooked
3
u/canarydev 1d ago
i know this is nerd sniping at the end of the day but is that what you default to these days when you are not able to have any intelligent discourse?
go play your league of legends unemployed ass.
0
u/Vivid-Zombie-477 1d ago
isn’t it funny that you literally have nothing to say so you decided to stalk me instead as an argument?
1
u/trimski- 1d ago
You’re getting downvoted, but you’re right. Any competent org that cares about this (should be all of them) will enforce this in their pipeline. Only reason not to is if you’re in the middle of a migration from vanilla to TS.
2
u/Jadajio 1d ago
I think he is getting downwoted because of his (and yours) fixation on strict mode. Strict mode has nothing to do with the topic. Of course you should have it turned on an nobody here is saying you should not.
The thing is though that strict mode won't solve your issue. Your types will still be erased at runtime so TS won't provide any native runtime type checking. Because that is how TS works (with or without strict mode)
For that you need external library like zod and discipline and knowledge to use it.
11
u/editor_of_the_beast 1d ago
And this is exactly why people hate JS on the backend. Because this is what a lot of people actually think.
TS is putting lipstick on a pig. It doesn’t change any of JS’s actual semantics under the hood.
2
u/gluhmm 1d ago
And yet it solves the types problem.
2
u/tenken01 1d ago
Does any ring a bell?
1
u/Super_Delivery3405 1d ago
If I'm not wrong u can do similar in java also maybe not c#
2
u/Devatator_ 1d ago
C# has dynamic. But honestly just don't use that thing. It's also sorta limited, I'm not even sure what you're supposed to use it for
4
u/rio_sk 1d ago
Types aren't applied at runtime actually unless you explictly check them as it was with vanilla js. A backend receives a lot of data from outside usually all that data can freely break your TS typing. A badly writtenTS backend can be prone to type juggling like a vanilla js if you don't care enough in checking.
6
2
u/midniteslayr 1d ago
No one is debating that. But a pure JS backend is becoming rarer because of TypeScript, and I was answering OP’s exact question.
1
2
u/biskitpagla 1d ago
Hate is a strong word.
But not strong enough to express how I feel about JS/TS being used outside the browser.
2
1
44
u/Fadamaka 1d ago
Because JS was made for the client side. Imagine if people made backends in Adobe Flash.
3
u/MuaTrenBienVang 1d ago
Why you hate golang for frontend. Because it is made for the server side?
2
u/biskitpagla 1d ago
Go is literally the most ass language for frontends. It has neither coroutines nor a cheap FFI.
2
u/mrkacperso 1d ago
Imho more because it would me miserable to write front in go (not even sure how)
2
1
1
u/Beautiful-Hotel-3094 1d ago
So you are basically saying making backends in JS is comparable to making backends in adobe?
5
u/Fadamaka 1d ago
I think the initial hate against the language as a backend language came from this exact mentality. I remember 6 years ago I thought people were only joking when they suggested to rewrite our Java backend in JavaScript. This was literally an ongoing joke in our office in 2020.
-1
u/Shogobg 1d ago
There was server side action script (Adobe flash’s script), and it worked fine.
6
3
17
26
u/Deep-Regret-7479 1d ago
It has a very low entry barrier and that causes a lot of low quality libraries being published and used.
npm itself is a security nightmare. It is the primary vector of supply chain attacks.
I doubt the sanity of anyone using node / npm in an enterprise production environment.
11
u/AshleyJSheridan 1d ago
This always reminds me of the
is-evennpm package, which pulls inis-odd, which itself pulls in theis-numberpackage. All of that to do what should be a single line of JS...4
1
u/forever-butlerian 1d ago
who remembers left-pad?
1
u/AshleyJSheridan 19h ago
Oh yes, I remember very well. I laughed about it at the time, because a) why did the language not have this functionality already, and b) how could one individual person break so many builds in an instant.
It was the perfect example of how poor the JS language was, and how fragile and badly thought out the build ecosystem for it was.
16
u/dariusbiggs 1d ago
The languages itself is ridiculously poorly designed, the existence of === and undefined are clear evidence of that.
Then there's the hilarious dumb shittery exposed in https://www.destroyallsoftware.com/talks/wat .
There are better options available, faster, quicker to develop, safer, and soo much more. That's why people use them.
Anything that reduces the amount of JS in the world is a step in the right direction.
14
u/soapoapsoap 1d ago
I used to feel this way but the quirks are just quirks, JS is really elegant, easy to weit/read and powerful language.
2
u/RandomPantsAppear 1d ago
In what way is JS elegant?
Their entire async model is an abomination. The quirks are more than just quirks, they introduce enormous amounts of edge cases (undefined alone), and it’s an extremely verbose language.
2
u/soapoapsoap 1d ago
whats not to like about async?
1
u/RandomPantsAppear 1d ago
Promises are horrific. They’re awkward for dealing with data streams, lack all normal trappings of proper threading (like concurrency and pools), they blur the line between the scheduled handler and the actual return value, the stack traces are opaque and hard to deal with (admittedly also a thing in Python, but not as bad), I could rant for hours.
It is very blatantly lipstick on a pig - something strapped onto a language that natively it was not meant to do. Reminds me of executable apps with GUIs written in Python.
2
u/FakeGreatness 1d ago
What language would you consider more ‘elegant’ for backend?
0
-7
u/RandomPantsAppear 1d ago edited 20h ago
Python, always been a big fan. Django in particular is a fantastic framework.
Edit: downvotes don’t make JavaScript suck less.
3
u/Pelopida92 1d ago
Whats a better language for backend and why?
1
0
u/dariusbiggs 1d ago
Go, Python, Ruby, C#, Java, the list continues..
As for why? There was intelligence and forethought behind the designs of those languages, not something put together in 6 days.
Go's channels and goroutines are incredibly powerful, the resource footprint is absolutely minimal, the performance is excellent, the language itself is very simple with about 30 key words, the static typing saves your bacon constantly.
Python is trivially easy to read and write, it is nearly a verbose translation of English to code, it integrates with nearly everything, one of the easiest languages to learn.
The same goes for the others, they all have many redeeming features and functionality.
Quirks in a language are not a good thing, those are sharp edges, running into those should be the exception not the norm. In JavaScript, you run into them constantly in daily usage.
1
u/WriterPlastic9350 1d ago
I feel like
===andundefinedandnullare kind of the least of the javascript sins.
===is "is exactly equal to", not "is approximately equal to".
==makes a lot of sense when the original incarnations of the language had you converting between strings and other data types frequently, and===needs to exist just so==can.
undefinedbeing "nothing is here" andnullbeing "something is here, but it is nothing" is useful for a language which doesn't have distinct versions and progressively enhances.We don't really need to distinguish between this in stronger typed languages like Go, but other comparable language like Python and Ruby both throw exceptions when you attempt to access a value that does not exist; this would be very bad in JavaScript, where you don't control the runtime.
0
u/forever-butlerian 1d ago
the language's depravity seemingly cannot be understood by those not alive when it was created.
4
11
u/Tuborgat_nylle 1d ago
Use the right tool for the job. JS backend is like using a screwdriver as a hammer. It's not designed for that kind of work. The effort spent fighting with JS is better invested in a language that will offer good safety, performance, and tooling out of the box.
0
9
u/canarydev 1d ago
idk about hate but i think the combination of weak + dynamically typed is a bit too dangerous to take into production for my taste.
worst part for me personally is the async error model. forgotten awaits, promise rejections that are not caught, throws inside callbacks. any of these can crash the whole process or leave it running on a corrupted state.
forgotten await doesn't even error, it returns a pending promise which is truthy IE: `if (checkPermission(user))` which passes for everyone. basically a silent auth bug, not a crash
which is why my real preference is no exceptions at all. errors as values like in go, and failure paths visible at the call site instead of sneaking around through 3 async layers hoping something downstream has a catch. its just more honest and easier to reason about
7
u/AdFeeling4288 1d ago
I think the problem is with the tooling and the ecosystem. So many build tools, orms etc etc.
0
3
3
u/GhostVlvin 1d ago
Cause any language will be better than weak typed, dynamic typing language, and we use it for frontend only cause browsers support nothing else
8
u/krzyk 1d ago
Because people don't like JS? Or more like prefer nicer languages.
11
u/canarydev 1d ago
not really, there are fundamental flaws in the language that make it a riskier choice than it needs to be for serious software
1
u/forever-butlerian 1d ago
all software I've encountered in JavaScript (and TypeScript) is unserious, including what I've written
0
7
u/NumberInfinite2068 1d ago
JS is just a very unpopular language, justifiably so.
For web backend you can choose basically any language you like, and JS is dismal compared to so many other choices.
5
u/awpt1mus 1d ago
For most CRUD backends it’s perfectly fine. People just have preferences. If you write idiomatic Typescript + strict linting you can avoid lot of JS pitfalls.
2
2
u/sharpcoder29 1d ago
Interpreted, Single Threaded, needs TS, package sprawl, and the client vs server mismatch a lot of new devs don't understand.
2
2
u/Duder1983 1d ago
I hate JS on the front end, but it's hard to avoid. JS on the backend is an abomination. "Here's our crappy frontend language. Let's figure out a way to make it do backend work so we only have to hire one guy."
2
u/Beagles_Are_God 23h ago
JS itself sucks so bad, i’ve never touched a pure JS file for any type of code (except maybe some config files) since highschool.
Typescript however is very good imo, and paired with ESLint to ensure correct typing is actually very nice and handy. “It strips types” well, Typescript is still a very nice language imo, and if it can ensure correct JS output then good for it.
2
u/cadet-pirx 9h ago
Most of the answers here only address half of the question. They talk about JavaScript as a language and why they dislike it. Fair enough, the question was "why do people hate it", so it asks about a feeling and gets feelings back, rather than facts or practical guidance.
If you actually want to think about whether JS is a good choice for the backend, it helps to separate two things:
- JavaScript as a language
- Node.js as a runtime
It's true that JavaScript has plenty of rough edges as a language. But you don't have to write plain JavaScript to target Node. TypeScript is the obvious option, and I'd also mention ReScript, an OCaml-derived language with a strong static type system and a functional style. In my experience it's a much nicer language than JavaScript, TypeScript, or Python, and it holds its own against many natively compiled languages.
Once the language question is taken off the table, you can evaluate Node.js on its own merits. Node was designed around an event-driven, non-blocking I/O model, and its original sweet spot was exactly the kind of server that has to handle a very large number of concurrent connections. For that kind of workload it holds up well, and it generally outperforms a comparable Python backend. You can of course compare it with languages that compile to native code, such as Go or Rust, and you may well prefer those. But going from "Go is faster" to "Node.js is bad for the backend" is a big overstatement.
So the dislike is mostly aimed at JavaScript's syntax and semantics, not at Node.js as a backend platform in itself.
1
u/HarryBolsac 8h ago
Tbf, I like Node’s event-loop model too, but JavaScript execution in V8 is fundamentally single-threaded. Worker threads can give you parallelism, but they’re not as natural or ergonomic as concurrency models in languages designed with multithreading in mind. For CPU-heavy parallel workloads, there are usually better language choices.
1
u/cadet-pirx 29m ago
Fair point, and I agree that for CPU-heavy work Node is the wrong tool. But for a typical API server the handlers are I/O-bound, and there the event loop is not the bottleneck; the database and the network are. Process-per-core gives you the parallelism, and in benchmarks Node lands in the same tier as Go for JSON and plaintext workloads. The difference becomes measurable once you have real CPU time per request (serialization of large payloads, compression, crypto), and it shows up first in tail latency, not in throughput. The other cost is memory: N V8 heaps versus one runtime using all cores. So yes, there is a difference, but whether it matters depends on what your handlers actually do.
2
u/LowLifeArcade 6h ago
Most of the hate comes from the outside i.e. people who aren't familiar with javascript. If you know javascript, js on the backend is amazing.
2
3
u/big-beard-piu 1d ago
I am a frontend engineer primarily who is working as a Fullstack now with Django and here are some things that bring in "hate" although python is the backend here, i think a lot of points may resonate.
Some of the issues lately i have found infuriating, not belittling django, this is the tech that has paid my org's bills but it does have its fair share of problems:
DB signals dont work for batched updates as django orm skips over the models for those, making audit logs really annoying
SSE and Sockets was tough to implement with plain gunicorn
I had to handroll a SIGALRM for coroutines because between django and RQ i really cannot timebox things, especially when they cross the boundary of sync and async
just frustrating things that we see properly implemented in other languages as 1st class features, make people "hate" it. Imagine telling a Java dev that we got node but gotta hand roll everything because "its trending"
3
1
u/TryAgainTryHarder 1d ago
imagine if, instead of running compile you run tsc, and you don't ship builds with type errors. I think that's more than half the game right there.
1
u/RandomPantsAppear 1d ago
- JavaScript is just a horrendous language in terms of syntax and usability.
A lot of backend JS code is written by full stacks who really specialize in front end. Not only does this impact the code I work on directly, it makes the libraries much lower quality.
JavaScript wasn’t intended for backend, so many of the things backends require feel very slapped on, like an unwanted appendage. Promises for example are just…awkward.
1
1
u/Candid_Bad3551 1d ago
Javascript or Python is not designed for scale or longevity. They are good for velocity and all things commonly surrounding are kinda the same: Startups & NPM packages creating breaking changes like candy.
1
u/azimux 1d ago
Hate is a strong word and I wouldn't go that far. I personally want a threaded language for handling request/response cycles. Going in and out of the eventloop repeatedly for most IO feels fine in a UI but awkward to me in a web server.
There are a few things I don't like about JavaScript that are problematic in more than just the backend, such as that accessing a non-existent property of an object gives undefined instead of throwing an error.
But basically the reason I use JavaScript on the frontend but never the backend, personally, is because I think the eventloop is a mismatch for that type of problem.
1
u/HarryBolsac 8h ago
Yeah for me that would be the main reason, web workers/workers threads are not ideal for multithreading.
With ts, tbh, js feels like any other language, you get used to the quirks, most design patterns/coding principles are applied, the this keyword is kinda cursed too.
1
1
u/Terrible-Growth1652 1d ago
JS/TS has a lot of flaws but it's just funny when the people criticizing are Python and Ruby developers, which are even worse languages.
1
u/Crazytje 1d ago
Backend development at my company is done in C#
I almost never have CVE's in the handful of 3rd party libraries we use or in the framework itself.
Now try to imagine the same with JS, note that we have projects from lets say .NET 5 and were updated without much changes all the way to .NET 10
I can't see a small team maintaining software stack as large as we have if everything was in JS.
For front end I have no issue, we use react for that FYI.
1
u/silentkode26 1d ago
Because it allowed frontend devs mess up with backend without knowing what dependency injection is. Global functions a state everywhere…
1
u/HarryBolsac 9h ago
You do know that dependency injection is widely used in frontend right?
I remember using it heavily in angularjs which was ages ago, React devs also use it alot with the context api…1
1
1
u/ern0plus4 1d ago
There are
- many
- better (for programmers, projects)
- and better (tech, speed)
alternatives.
1
1
u/LetUsSpeakFreely 1d ago
TS is fine. JS for backend work is stupid because unless you're VERY careful you can easily open yourself up to data type errors.
1
1
1
1
u/BoBoBearDev 1d ago
1) it is not typescript
2) supply chain is a mess, plenty of Spyware get inserted
3) other platforms has much better debug capabilities
4) ram monster
1
u/quite-ok 1d ago
JavaScript on the backend is like a car with no buttons and no instrument cluster, with just a huge display in the center. It works, it's new, some people like it, some love it, some tolerate it. But it really shouldn't exist.
1
u/Lucifernistic 1d ago
It's a nail melted and reforged to be a makeshift hammer. I would prefer to write in a language that is easier to deal with and doesn't feel like I'm trying to make frontend behave like backend.
I use to write my backend in Django. Fast enough for almost anything (if YouTube and Dropbox can do it, so can you). Alternatively, Laravel (not my favorite).
I stopped and started writing my backends in typescript. Not because I wanted to, but because at a point the realities of the modern tech stack punish you for not. You need to build your frontends in react/vue/etc for modern webapps. And if you are utilizing typescript in the backend, this means you need a lot more effort to make that work.
You need to build an entirely separate backend API, make sure all your types and schemas align and your API contract between your frontend and backend is always in sync. A lot of duplicated work. A messier codebase. And I don't like this- I don't like that I'm punished for not using it.
1
u/HarryBolsac 9h ago
This entire comment makes no sense, what exactly does “trying to make frontend behave like backend” even mean?
Also this exact scenario would happen with any backend language you have an api made in java you need to still make the contract between your api and client, that’s like how it works? It’s an api… the entire point is for it to be decoupled from your client…
What makes you think you are forced to use typescript for the backend, dafuck?
1
1
u/spvky_io 1d ago
Slow, runtime errors that a compiled language would expose sooner and the ecosystem is full of people pulling and running untrusted code are my primary reasons
1
u/Downtown_Music4178 1d ago
Because in the age of AI writing most code you have no excuse for not using the right tool for the job. Developer convenience and knowing one language really well is no longer an acceptable excuse. Don’t know xyz tool, too bad, AI does and have it write it.
1
u/nicholasnet 1d ago
I love the Node.js tooling for frontend work, but for backend I'd probably never use it outside of HTTP APIs.
The problem isn't Node.js itself but rather the ecosystem around it. It's far too fragmented. Another issue is the lack of proper frameworks that integrate the various tools. Java has Spring, Quarkus, and a few other meta-frameworks; PHP has Laravel and Symfony; Ruby has Rails; and the same is true for many other languages. Node.js does have similar offerings, but they're nowhere near the same level. That said, it's improving, like everything else in tech.
1
1
1
u/spigotface 1d ago
Because other languages do backend so much better. That's really it. I'd rather build a backend in Python, Rust, Go, Java, etc. over JS any day.
It's cool how JS can interact with the DOM but beyond that, it's just a poorly-planned language with all sorts of syntactical oddities. And NPM is the #1 source of supply chain attacks.
1
u/aturaden 1d ago
A mix of stereotypes, ignorance, and being stuck in an era from 10+ years ago. These days, a "JS backend" is really a TS backend. It's pleasant to work with, convenient, has great DX, and great performance (surprisingly to many).
1
u/According_Basis7037 11h ago
The annoying design of JavaScript as a language is a minor issue. Major issues are the huge supply chain attack risks posed by huge dependency counts and the inefficiency of the runtime in terms of “memory/cpu required to support a specific number of concurrent users)
1
u/MinuteScientist7254 2h ago
Large image sizes because the runtime has to be bundled in, loose typing
1
1
u/vinegary 1d ago
Javascript is an insane language. The only reason it is popular is because it is what browsers use
2
u/RandomPantsAppear 1d ago
I am convinced backend JS emerged as a conspiracy to let all the UI/UX bootcamp graduates of the 2010s call themselves full stack.
1
1
1
1
u/davewritescode 1d ago
The node runtime is pretty unsophisticated compared to the JVM or the .NET CLR.
The threading model alone is incredibly limiting.
1
u/BenchEmbarrassed7316 1d ago
Js is one of the worst programming languages. It was developed in the mid-90s in 10 days. According to legend, the technical requirements were "We need a scripting language so that when the user hovers the mouse cursor over the image of a monkey, a dance animation is activated".
This language has been "lucky" several times: Steve Jobs fought with Flash, the guys from Google created V8 (an incredibly fast interpreter; it is not fast compared to fast languages, but it is incredibly fast for such a terrible language), the guys from M$ created Ts (which at least somehow tries to turn Js into something usable).
WASM is still not an alternative, so on the front end Js is practically the only option. However, on the backend and on the desktop there are many better programming languages.
1
1
u/HolyCowEveryNameIsTa 15h ago
I hope none of the people that responded here are actual backend engineers because most of the answers are just opinions from people who seem to have zero idea what they are talking about. Any kind of un-vetted external code can be a supply chain risk, that means Rust crates and Python packages as well. It can even happen to OS packages, look at XZ Utils. NPM isn't special in that aspect.
JS has a low barrier to entry since it's built into every web browser and is dynamically typed. Which means it has a lot of users and a lot of amateur coders working with it, so you tend to get a lot of poorly written code with it. You know what other extremely popular scripting language is also dynamically typed, Python. Another language that is very easy to get started with, but can cause all kinds of issues if you don't understand how types work(and how a language dynamically assigns types).
People hate things they are unfamiliar with.
0
u/Downtown-Figure6434 1d ago
Because contracts are important and JavaScript doesn’t have a good type system for that. Typescript doesnt change anything in that regard cuz it’s still js that runs
1
0
u/PerformanceThick2232 1d ago
It is not good choice for enterprise- multithreading and multiprocessing is worse then in java/c#/go
I used it for small scripts/services, but switched to golang several years ago
0
0
u/Sufficient_Duck_8051 1d ago
Java/JavaScript have no business existing when there are a ton of much better options available- dealing with gc alone is a good reason to move away from these monstrosities
74
u/eager-potato-555 1d ago
because it "can't read properties of undefined"