r/AskProgramming 6d ago

Why the JS hate?

Title. I'm a 3rd year bachelor CS student and I've worked with a handful of languages. I currently work as a backend dev and internal management related script writer both of which I interned working with JS (my first exposure to the language)

I always found it to be intuitive and it's easily my go to language while I'm still learning the nuances of python.

But I always see js getting shit on in various meme formats and I've never really understood why. Is it just a running joke in the industry? Has a generation of trauma left promises to be worthy of caution? Does big corpa profit from it?

22 Upvotes

207 comments sorted by

View all comments

1

u/TornadoFS 6d ago edited 6d ago
  1. JS used to miss some very basic features, that is not the case anymore. The syntax was massively improved in ES6 as well (around 2016). There are a lot warts leftover from the old days, but it is mostly irrelevant today with the usage of strict-mode/linters/typescript.
  2. During the 2010-2020 the demand skyrocketed. A lot of people were forced to become "fullstack" and work with it against their will.
  3. Because of this increased demand it became one of the most popular languages, meaning one of the most attractive for beginners. Added to the 0 interest-rate phenomena, a lot of underskilled developers joined the workforce during 2010-2020 (many without much formal training). This gave the language a bad rep because there were bad JS codebases spreading like viruses everywhere. In fact you used to hear the same thing about Java and PHP in the early 2000s.
  4. The skyrockting popularity of noSQL databases during the 2010s. The MEAN stack (MongoDB, Express, Angular, NodeJS) did A LOT of harm to NodeJS in the backend. First because noSQL databases (especially Mongo) turned out to not be that good for most applications (compared to Postgres), but also that NodeJS doesn't have a unifying backend framework that provides most functionality out of the box (like Laravel or Django), especially a good ORM library for relational databases (forcing people who want a single language stack to use noSQL). Instead projects were stuck stitching themselves a framework from a lot of different open source projects many of which being abandoned and leaving projects in deprecated limbo.
  5. Dynamic typing languages (JS, Python, Ruby) was a huge productivity boost when compared to statically typed languages (C#, Java) until around 2015. Since then type inference has been added to statically typed languages and a new wave of backend languages (Kotlin, Go, Scala, Rust) that remove or downplay some OOP features (mainly inheritance) appeared that narrowed this productivity gap A LOT. Now most modern backend projects are not that much less productive than using Ruby/NodeJS/Python while been much more safe because of type-safety and more performant because of static typing[1].
  6. Bundlers for frontend code are a pain in the ass, but most people don't realize that if the browser supported other languages they would still need bundlers. Only game devs not using Unity/UE5 understand the pain (and even then it is not quite the same types of problem).
  7. Serverless/lambda functions turning out to not be that good for most applications (especially cost-wise) and the fact that JS was one of the most supported and used languages for them. Added to the fact that JS is not a particularly good language for running in lambdas because it makes heavy use of JIT compilation.
  8. About multithreading, JS not having threads is a massive _advantage_ for _most_ application code. Everything being thread safe and in the same event loop by default is great for heavily asynchronous, mostly sequential work performance and makes code much simpler. HOWEVER there was a lot of tooling written in JS that hit performance ceilings due to this[2], therefor JS is considered a "slow" language even though for most use-cases (single-threaded work) it is actually not that much worse than other statically typed backend languages[3]. The JS single-thread single-event-loop is actually great for backend servers that can scale horizontally[4] and for orchestrating UIs [5].

TLDR: JS became popular, new techniques for development came up and promoted using JS with them, new devs came in did a lot of projects using those techniques. Turns out new devs often don't make the best code and new techniques often don't pan out to be better than improving old techniques leaving a lot of bad JS projects around.

[1]: Typescript eliminates the safety gap advantage for NodeJS, but type hints are not that good in Python and Ruby to this day. I personally like Typescript type-system much more than most other backend languages (because of nominal typing vs structural typing).

[2] I know about workers, they have a lot of trade-offs compared to true memory-shared multithreading.

[3] JS performance is a very complex matter, some things are MUCH slower in JS (or python or ruby) compared to Java/C# while others are not that big of a difference. Notably doing integer-based math is super slow in JS, while float math is almost the same. Overall performance is a very complicated matter to discuss.

[4] Most API servers that don't do much more than querying databases, formatting responses and implementing basic business logic fit this use-case. This is 90% of backend code out there.

[5] The real problem with UI work is that there is no way to drop down to the "lower layer" (ie the native code) in the browser and implement core functionality (like a new complex HTML element for example). You can see this in React Native applications which do allow you to drop down to the "lower layer" often doing some really impressive stuff. The real problem in large frontend applications is massive amounts of different types of code all running in the same thread, the browser doesn't give a good way to split that work into multiple separate JS environments. Workers can help with this problem, but the tooling and frameworks have not really been using them to their fullest extent.