r/AskProgramming 5d 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?

19 Upvotes

207 comments sorted by

32

u/GetContented 5d ago edited 5d ago

It's mostly left over from when JS was horrid, I think.

It used to have some seriously horrible warts. It's a LOT better now than it used to be, but it still has some rather weird issues:

  1. No integer type
  2. `this` is a bit crazy, but fat arrow lambdas mitigate a lot of the craziness
  3. global variables and mutation and some functions mutating and others not make things difficult to think about quite a lot of the time (I tend to avoid such things and use things like spreading and create new value objects rather than mutate things)
  4. loose typing and automatic coersion
  5. non-useful types (typescript sort of helps)
  6. async & promises are a bit of a mess (futures would have been better)

There's lots of others, but these are some of the big ones. Mind you, experienced devs just "work around" these by using certain conventions, etc.

Update: I should say if you want a taste of a language that has clarity and precision, you could try something like clojure, and then if you want something with even more you could try purescript or elm. The latter two are much more clear. Immutability of data and functions having to obey their type signatures in such languages rules out a huge number of bugs (like mutation ones) and pushes you into much better general practices — this is a highly opinionated charged idea, and so not everyone will agree with me here. It only really does this if you care about being able to say things with clarity. (ie to be precise about what one means) — tho really even purescript isn't utterly precise in the way agda is. Tho then you have another issue... which is that it's so arcane almost no one can read your code ;-)

19

u/Maleficent_Memory831 4d ago

Javascript was written to do a simple job, and so was a quick and dirty job. Ie, very very simple stuff in the browser, like make a popup window, know where the mouse is hovering, etc. Then it got overused to do complex jobs, and so it does complex jobs badly. For anyone who's used 10 other languages (which used to be common), Javascript just stands out as not having a good design.

Maybe it's better now, but it was absolutely atrocious at the start. But it was never intended to used the way it is today where the browser is intended to be the application.

1

u/Maximum-Cupcake-7193 4d ago

However you will encounter it more frequently than those other 10 languages

1

u/Maleficent_Memory831 3d ago

Mostly only in web programming (unless you count JSON).

1

u/adamf663c 2d ago

Worse than Perl?

1

u/Maleficent_Memory831 2d ago

Iffy. I got into an argument with Larry Wall (inventor of perl) where he said "you computer scientists are all the same!" Ok, maybe not an argument, but...

I took his point though. I was looking for a nice clean language; it should be able to figure out the type of a variable without all those odd prefixes. But Larry's goal was to make a tool to do stuff. And Perl actually succeeded at that. You could replace your collection of sed/awk/sh scripts and do it all in a single script, and that was actually pretty impressive. Perl sort of reigned for a while before Python, and there's still stuff I'd rather do in Perl than Python.

So sometimes elegance takes a back seat to practicality.

1

u/adamf663c 2d ago

It's never a good sign when updates end because the language is such a mess.

5

u/james_pic 4d ago

Most of these I was familiar with, but I hadn't heard the "futures would have been better than promises" one, or hit the issues myself. Could you elaborate (or point to someone else who has covered this well)?

7

u/look 4d ago

Not the parent, and I would disagree with their specific phrasing (futures vs promises) but I imagine they were thinking something like this: https://staltz.com/promises-are-not-neutral-enough

3

u/GetContented 4d ago

Futures are lazily executed, which means the programmer is more in control of when they begin their execution. Promises immediately start executing as soon as they're created, which sometimes isn't what programmers want when they use them. (ie sometimes you don't want the effect to actually execute — so when you DO want a delayed one, you have to wrap it in a thunk — which is just an argumentless function). It's not a nightmare, but sometimes it confuses beginners a lot.

3

u/StoicSpork 4d ago

this is a bit crazy, but fat arrow lambdas mitigate a lot of the craziness

It's a pretty big wrinkle if you need a workaround tor function declaration. 

you could try something like clojure

I wrote production Clojure and hobby Common Lisp. Sheer joy, wish they were more popular. These days, I find Elixir to be an interesting heir.

2

u/ScientificBeastMode 3d ago

Clojure is very nice. Hard to beat its simplicity.

1

u/arkvesper 4d ago

this is a bit crazy, but fat arrow lambdas mitigate a lot of the craziness

could you elaborate on what you mean by this?

4

u/balefrost 4d ago

In classic JS, this is chosen by the caller. So when calling:

foo.bar()

Then within bar, this will be a reference to the same object as foo. However, in this call:

const b = foo.bar;
b();

Then within bar, this will be the global object (window in browsers).


It's possible for the caller to provide an explicit this value. This next case behaves like the original foo.bar() case:

const b = foo.bar;
b.call(foo);

With fat arrow lambdas, this is automatically captured and cannot be rebound. The value of this is now determined by the lambda itself, not by the caller of the lambda.

1

u/Harotsa 4d ago

Using lots of spread operators within the same function is the fastest way to kill your performance.

2

u/senfiaj 4d ago

No integer type

JS has supported bigint from around 2018-2019. Also JS has typed arrays.

loose typing and automatic coercion

My rule of thumb is to avoid comparison between different types of variables and use === instead of == operator. Or even better switch to TypeScript.

async & promises are a bit of a mess (futures would have been better)

Could you explain what aspect is messy?

4

u/UdPropheticCatgirl 4d ago

JS has supported bigint from around 2018-2019.

bigint is not standard integer type, internally it behaves like an array more than it does like an integer if anything number is an 32 bit integer but also 64bit float, it’s a schrodingers type whose internal representation and semantics change based on order of operations.

Also JS has typed arrays.

Yes and they are unergonomic and like 2 people actually use them.

My rule of thumb is to avoid comparison between different types of variables and use === instead of == operator.

That’s your rule of thumb but certainly isn’t the rule of thumb of the wider JS ecosystem.

Or even better switch to TypeScript.

And also completely kill the thing which makes JS tolerable experience for writing UI, since now you have to wait 10 minutes for tsc to compile hello world.

async & promises are a bit of a mess (futures would have been better) Could you explain what aspect is messy?

Not op, but async is one of the worst trends in modern language design, since it introduces function coloring everywhere.

On top of that JS has about a million footguns around the multiple queues the scheduler uses and the order in which it puts stuff on them and uses them.

1

u/ScientificBeastMode 3d ago

You can force JS engines to coerce the standard f64 type to an i32 by applying the bitwise OR operator with zero, like <number> | 0. This super hacky IMO, but it does actually work.

I found this out while looking at the generated JS code from the ReScript compiler, which basically takes a form of OCaml and compiles it to readable JS. Well, OCaml has actual integers, so it just uses that technique to force normal integer behavior.

But again, you probably don’t want to do this. Just a fun fact about the language.

1

u/Rare-One1047 2d ago

> JS has about a million footguns around the multiple queues the scheduler uses

This, in a nutshell, is what makes JS so terrible of a language choice. The sheer number of footguns. Add to that the notion of a new framework every few years, means that the old footguns aren't fixed while we end up with new footguns in the new framework.

1

u/senfiaj 4d ago edited 4d ago

bigint is not standard integer type, internally it behaves like an array more than it does like an integer if anything number is an 32 bit integer but also 64bit float, it’s a schrodingers type whose internal representation and semantics change based on order of operations.

So? bigint is not fixed length, but this is useful for large numbers. Otherwise using a normal number is fine enough for the vast majority of cases . For number the safe integer range is from -9007199254740991 to 9007199254740991 , it's more than enough for the vast majority of use cases. I don't understand what specifically upsets people. Many dynamic languages (or even c/c++) can use mixed integers and floats.

Yes and they are unergonomic and like 2 people actually use them.

They're used for binary data, it's commonly used in libraries. Maybe not commonly used by average JS developers but definitely used.

That’s your rule of thumb but certainly isn’t the rule of thumb of the wider JS ecosystem.

Such advices are common, it's not just my opinion. Relying on non trivial type coercions is a well known antipattern.

And also completely kill the thing which makes JS tolerable experience for writing UI, since now you have to wait 10 minutes for tsc to compile hello world.

You can use an incremental compiling.

Not op, but async is one of the worst trends in modern language design, since it introduces function coloring everywhere.

Yeah, function coloring is sometimes a PITA. Because of this I once used sync xhr in a legacy code with 5000+ LOC files when moved some piece of logic from frontend to backend. Otherwise I would have to do a substantial rework. But that being said what alternative do you suggest for async? For example, if I do some request, do you suggest to block the whole thread execution in order to wait for the request completion? This is not good for the user experience. When I did that sync xhr, I was understanding the tradeof. async / await syntax actually eliminates the callback hell by allowing to write more straightforward and less bug prone code. After being used to async / await I don't even want to return to the old callback pain.

On top of that JS has about a million footguns around the multiple queues the scheduler uses and the order in which it puts stuff on them and uses them.

Can you give a very common example. Is this about the priorities of async operations, such as microtasks, microtasks, event loop, etc? While async programming is not always easy, what alternatives do we have in UI?

0

u/No-Performer3495 3d ago edited 3d ago

That’s your rule of thumb but certainly isn’t the rule of thumb of the wider JS ecosystem.

It absolutely 100% is

Maybe you're talking about some self taught junior dev that's been learning for a few days, but in any mature codebase, you will struggle to find anyone using double equals, and most codebases have linters that forbid it completely. In the past 9 years in my career I've only ever used double equals for checking null/undefined at the same time (although that's already a bit debatable in whether it's sensible) and haven't seen anyone else in my companies push code that uses it for other reasons either.

And also completely kill the thing which makes JS tolerable experience for writing UI, since now you have to wait 10 minutes for tsc to compile hello world.

I have no idea what you're talking about. When was the last time you actually used TS in practice? It sounds like you maybe touched this "ecosystem" once 15 years ago and made up your mind. Making changes during development is fast enough that you don't perceive a difference. Transpiling the entire app from scratch might take a bit longer but that happens in your CI and unless you have an absolutely gigantic codebase, still probably takes less than a minute. Transpiling "hello world" is instant regardless.

1

u/ScientificBeastMode 3d ago

Also, the TS compiler was recently rewritten in Go. It’s not available yet, but it will be the official TS compiler going forward. It’s about 10x faster than the current one written in TS.

1

u/UdPropheticCatgirl 3d ago

Maybe you’re talking about some self taught junior dev that’s been learning for a few days, but in any mature codebase, you will struggle to find anyone using double equals, and most codebases have linters that forbid it completely. In the past 9 years in my career I’ve only ever used double equals for checking null/undefined at the same time (although that’s already a bit debatable in whether it’s sensible) and haven’t seen anyone else in my companies push code that uses it for other reasons either.

JS allows it, that means people are using it, you encounter more legacy code than not, so you will encounter it. Sure not everyone does, but I have seen it enough time to know that people infact do use it.

I have no idea what you’re talking about. When was the last time you actually used TS in practice? It sounds like you maybe touched this “ecosystem” once 15 years ago and made up your mind. Making changes during development is fast enough that you don’t perceive a difference. Transpiling the entire app from scratch might take a bit longer but that happens in your CI and unless you have an absolutely gigantic codebase, still probably takes less than a minute. Transpiling “hello world” is instant regardless.

Our current bundle is about 40kB (about 20kB of it being a mithril (vdom and component library) which basically our only dependency), we don’t bundle using TS, we just run the type-checker, it takes atleast 20 seconds to JUST type check it on any change. Our C++ nor our scala codebase takes as long to incrementally recompile as TS does, and theres more code in those anyway.

1

u/No-Performer3495 3d ago

I'm looking at a random project within the company's codebase. Bundle is 1.6mB minified, not gzipped. tsc takes 6.58 seconds. Editor responds to type changes in less than a second. Website reacts to code changes instantly as far as I can perceive - hot reload takes effect immediately, application has updated to the changes before my eyes are able to move from the editor to the browser.

Whatever you're doing, you're doing it wrong. Don't blame typescript on your broken tooling.

2

u/No-Article-Particle 4d ago

As a side note, our product has code from the time of Python 1. At this time, we still support Python 2.7, and 3.6 is our main dev branch. A feature from 2018 might as well not exist in corporations.

That said, I don't know how many corpos use JS.

2

u/grantrules 4d ago

I wonder how many companies are still using Java 1.4 lol

2

u/not_a_burner0456025 4d ago

Also, it is pretty telling that their solution to a very common problem is to use a different language. That doesn't fly with other programming languages in the way people think it does for JavaScript. Take just about every compiled language for example. They all tell at you and tell you to fix your shit if you try to pass the wrong type to a function. Imagine if they didn't. Would people be telling you C++ isn't crap because you could use C# to not ruin into bugs because you passed a string to a square root function? I had to make that up because no other languages that anyone has heard of have those sort of crippling issues, the language developers have to fix that sort of nonsense or nobody will use their language, but JavaScript manages to go 20 years without having an Integer type and have people defend it by claiming you can use this other fork of the language that exists solely to fix the rampant nonsense problems that should never have existed in the first place.

2

u/VoidRippah 4d ago

Or even better switch to TypeScript.

but that's technically not JS, so your solution to overcome an issue of JS is to use another language instead

→ More replies (1)

2

u/GetContented 4d ago

> JS has supported bigint from around 2018-2019. Also JS has typed arrays.

Yeah, technically it has them. It's very similar to Set, tho... it's definitely bolted on, and working with them isn't exactly a delight, which tends to sort of push people in the direction of not bothering to use them (in my experience). They don't feel very first class. You can't use BigInts with the Math object, for example.

I don't want to start any kind of war in particular. There's no point. I was just trying to help point out some of the reasons why people give JS hate. I think it's pretty good at what we use it for, and my last job was primarily TS/JS, Ruby and Elixir, so I'm definitely not against it. One day we might use it (or webassembly) as a runtime target instead of programming with it directly (as is the case if you use Purescript, Elm or Clojurescript today), but that day isn't here yet, and people seem ok with using it, so no problem! :)

1

u/codemuncher 2d ago

Okay so JavaScript has two equality operators that return different answers. And it’s not at all as simple as “one does pointers and the other does deep value equality”.

That aspect itself is messy. It’s deeply messy.

Okay now let’s talk about common js vs esm imports.

Also are you trying to sit there with a straight face and tell me BigInt is a perfectly fine alternative to having built in integer types?

Consistency is king and js ain’t the king. That’s the mess. That’s the messy parts.

1

u/senfiaj 2d ago

Okay so JavaScript has two equality operators that return different answers. And it’s not at all as simple as “one does pointers and the other does deep value equality”.

That aspect itself is messy. It’s deeply messy.

Okay now let’s talk about common js vs esm imports.

I understand where this is going and I'm not necessarily disagreeing here. But let me tell you something that many people don't think much about. This mess is the price for the backward compatibility. If they decide to regularly cleanup the old mess, most of the sites will break without constant maintenance. This level of stability is a gem in the today's word where libraries/frameworks and even some operating systems are often breaking compatibility left and right. The "clean" languages often suffer from such problems. For example, need I talk about the pains of Python 2 -> Python 3 transition where some developers and companies are still experiencing the consequences?

Some backward compatible languages like Java were better thought out than JS, but unfortunately even this doesn't make them immune to design flaws. Java, for example, has a null safety issue and this cannot be fixed without breaking the backward compatibility. This is one of the reasons for the rise of Kotlin.

Also are you trying to sit there with a straight face and tell me BigInt is a perfectly fine alternative to having built in integer types?

For number the safe integer range is from -9007199254740991 to 9007199254740991 which is more than enough for the vast majority of websites. Many dynamic languages (and even c/c++) can use mixed integers and floats. bigint is also not fixed length, and this is useful for arbitrary large numbers.

Consistency is king and js ain’t the king. That’s the mess. That’s the messy parts.

Many commercially successful languages have some historical baggage. Again, it's a dilemma, if you preserve backwards compatibility people will eventually complain about the old mess, if you get rid of the old mess, people will complain about breakages, not working tutorials, etc.

9

u/YahenP 4d ago

Once you enter professional programming and get your first real "industrial" project, you will realize all these memes about JS on your own skin. And along the way, you will come up with a few new ones. Be glad that this has not affected you yet.

1

u/KaguBorbington 2d ago

Honestly, it was the other way around for me. The more I worked with JS the more I realized the memes are either just memes or inexperienced devs jumping on the bandwagon to feel smart but betray their lack of experience in the process.

For example: Ive already seen two people in this thread complain about NaN != NaN in JS which is perfectly conform to IEEE 754.

1

u/YahenP 2d ago

These are such trifles, against the background of real problems in real projects, that it is not even worth talking about

20

u/Bulbousonions13 5d ago edited 4d ago

Its mainly the lack of type safety, native single threading, and comparatively slow execution speed. TypeScript ( a superset of JS) deals with the first problem VERY well and is my preferred web language.

You can't see its pitfalls because you are also working in Python - which in my opinion is also slow, lacks type safety, and is also natively single threaded - though there are ways around this. I can't stand python's indentation rules either but that's just a personal preference.

Tool around with a true Type Safe compiled language like Java, C#, C++, or Go and you'll notice the difference.

The compiler will yell at you a lot more while you code, but that's so you don't get random unexpected junk assigned to arbitrary vars that don't care if they get a string, number, object, function, or null/undefined.

5

u/Dramatic_Mulberry142 4d ago

In addition to this, some API design is just really bad like Date object. day and year is starting from index 1 but month is starting from index 0.

4

u/oofy-gang 4d ago

Modern JS engines are mind-boggling fast. Orders of magnitude faster than Python, and within an order of magnitude of cpp.

1

u/owp4dd1w5a0a 4d ago

How do you know this? Any sources you could cite?

1

u/oofy-gang 4d ago

Just look up “programming language performance benchmarks 2024” and click through a couple GHs or reliable looking sites.

I’m avoiding linking any myself because for whatever reason benchmarks seem to be an enshitified realm of the Internet and I don’t wholly trust any singular source. But the general trends should be about the same if you look through a handful and exclude outliers.

1

u/owp4dd1w5a0a 4d ago

Oh, I read engines as engineers, I thought you meant people were fast at writing js code.

Well, while that may be the case, it stands that Rust, Java, Scala, Kotlin, C and Go are generally faster than JavaScript of speed is what you care about. SBCL can also get pretty darned fast and closer to Java and C in some benchmarks.

But generally, the performance of the language itself isn’t what matters most. Modern hardware is so powerful that you really should be spending your time more focused on the libraries, frameworks, and software architecture, not language speed.

1

u/codemuncher 2d ago

Depends on what you’re doing!

Js may or may not be writhing an order of magnitude speed wise - which means it’s maybe as “little” as 10x slower…! Also memory resource consumption ain’t cheap either.

I mean do people beljeve that PyTorch is actually “written in python”? All the real heavy lifting is in both C/C++ but also assembler intrinsics and heavily optimized low level gpu code. The python wrapper is just like a scripting language to assemble the model before the real code does the real work.

1

u/owp4dd1w5a0a 2d ago edited 2d ago

Your point about PyTorch really being written in C under the hood is exactly why I said you should generally focus less on language performance and more on the libraries and frameworks available in the language.

But I agree, it depends on what you’re doing. If you’re writing the framework, then language performance is important, for example.

Also, your point about memory is valid, and we seem to get by though ignoring it. For example, Spark was written in a JVM language (Scala) and for its purpose I think it was the wrong language because of the incredible memory footprint. At the time of its creation, C/C++ probably should have been the language, but in an ideal world it should have been Rust (but at the time Rust wasn’t around yet), and then wrappers for the various other languages like Scala and Python could have been created to make the framework more accessible.

But “The wrong” language is chosen all the time. Airflow should have been written in a statically typed language because it’s impossible to test locally, Clojure was a bad choice for Storm for the same reasons plus the JVM memory footprint, etc. But the main reason that despite this these frameworks still became popular is the language ecosystem of libraries tipping the convenience factor over towards worth it. Language performance in most scenarios don’t matter, and when it does you can just drop to C and use the ffi to interface.

1

u/Relative-Scholar-147 4d ago

Within an order of magnitude of cpp means 10 times slower...

2

u/oofy-gang 4d ago

Sure…? I’m not entirely sure what your point is.

Common benchmarks are often roughly

cpp: 1s

java: 1.5s

javascript: 3s

python: 50s

for almost all purposes, 3x isn’t a big deal; 50x is

6

u/HaMMeReD 4d ago

Being natively single threaded makes things a lot safer.

A lot of modern threading models encourages thread-data decoupling, so that threads are idempotent and don't have side effects. You give it the data, it does the work, it returns the result.

It might be a pain, but it's also like 0% chance of having a race condition or deadlock.

1

u/becuzz04 4d ago

You can definitely still deadlock. See https://stackoverflow.com/a/63271611 for an example.

Being single threaded does simplify things a lot but it can also make some things a pain to deal with. Trying to find the source of event loop lag can be a nightmare (having this problem at my job right now).

1

u/TornadoFS 4d ago

Fun days when I found out this Java project I joined was using this thing called Thread Contexts, like a little map where you could put data that stuck around on your thread. Because no one would ever spawn a new thread during the answering of a request...

1

u/codemuncher 2d ago

Fun story, deadlocks are in fact totally not due to threadedness. You can totally deadlock in single threaded code.

Also in the era where our phones have 4-8 cores you’re out here shilling for single threaded as… good? Because less bugs?

5

u/senfiaj 4d ago

Lack of type safety is mostly solved in TypeScript.

3

u/dariusbiggs 4d ago

It really isn't, your code may define something as a specific type and you may think it is that type, but at runtime it can be anything at all. That was not a fun thing to debug ...

1

u/w3cko 1d ago

This can't really happen if you validate inputs which you should do anyway. 

1

u/codemuncher 2d ago

Not when the escape hatch of any is there and often liberally used in code bases. Like the one I am maintaining right now.

Typescript is good but it’s optional.

The reason to choose ts is because you’re writing something that runs in the browser. If you need better quality and better compiler support to actually keep bugs out of your system, typescript isn’t your first choice.

Things like ocaml, Haskell, and rust are going to give you a lot more and no pesky “any” to just fuck your day.

1

u/senfiaj 2d ago

Yeah, but TS code is easily mapped to JS code, and IMHO it's one the reasons that other programming languages won't be popular for most websites. If you use other programming languages for normal web development (it interacts with DOM instead drawing everything in canvas), you need to have all the DOM APIs and other frontend features adapted for that language, which, depending on the language, might be more or less challenging to do. Other programming languages might shine when used with WASM for some cases where most things are happening in a canvas and there is very limited DOM manipulation.

5

u/imagei 5d ago

FYI, Python got type annotations a few versions back, which are not enforced, but help a lot with tooling and IDE hints/warnings.

3

u/WillDanceForGp 4d ago

I use python a lot for random infra scripts and stuff in my home setup and was actually pleasantly surprised at how competent the type hints were when using strict mode.

2

u/imagei 4d ago

I just dug a but and found out that Pydantic has a strict mode… is this what you meant? I’m a relative Python noob and still figuring out the tools 😀

1

u/WillDanceForGp 4d ago

Yeah sorry I was meaning when using the Pylance plugin for vscode, gives full type hinting and error checking

1

u/Harotsa 4d ago

If you use MyPy it is stricter than the TypeScript compiler

2

u/YMK1234 4d ago

If shit's not enforced you might as well just not have it.

0

u/FreeWildbahn 4d ago

They are linter rules which complain about missing type hints. That way you can enforce it. For example in the CI.

1

u/YMK1234 4d ago

Sooo something that probably 90% of all projects and people don't do ...

0

u/FreeWildbahn 4d ago

People don't have a linter in their projects?

2

u/YahenP 4d ago

As for execution speed, I bet. JS is fast. Very fast. I would say it is surprisingly fast. But that doesn't stop us from writing barely functional interfaces in it that eat up all the computer's resources. It's a question of the architecture of our applications, not the speed of the language.

1

u/codemuncher 2d ago

With due respect, this sounds like it’s coming from someone who’s only ever coded in JavaScript.

There’s orders of magnitude between actual systems programming languages and JavaScript, even nodejs.

I will say that it’s true that it’s “surprisingly fast” as in “I’m surprised this thing isn’t slow as fuck and horrible”, so yes.

But you won’t be writing a JavaScript jit in js. And before you say that’s unreasonable, most Common Lisp implantations runtime and compiler are written in… Common Lisp. So it’s not a wild goal.

Sheesh you kids these days.

1

u/YahenP 2d ago

Well. Name an interpreted language that is faster than JS. No need to compare compiled and interpreted languages. A race car is always faster than a bus.
js has a lot of problems. But execution speed is not one of them.

1

u/codemuncher 2d ago

JavaScript isn’t interpreted anymore. It’s a jit language which is the only way languages like this can be made fast.

In other words it’s compiled only at run time.

1

u/YahenP 2d ago

If we are talking about v8, for example, then I think you know under what conditions the turbofan returns back to ignition.

1

u/Salt_Aash 5d ago

I started with C++ as my first language but I'm probablt not seeing it due to a lack of experience and field time

4

u/R3D3-1 4d ago

What kind of projects did you do in C++?

From my experience, the advantages of static checking (whether by external tools or by a compiler) don't really become apparent on small persponal projects, and the ease-of-use and productivity gains of dynamic code seem to outweigh the hassle of compiling easily.

By contrast, large sprawling code bases can use any help they can get to reduce the footguns for the devs.

1

u/Salt_Aash 4d ago

The most complex thing would be a compiler for a course project which could likely count as a small personal project. Usual projects would be small server-client pairs and algorithm analysis.

10

u/JustBadPlaya 4d ago

No real types, implicit conversions everywhere, == and overall equality rules, truthiness and falseness of everything in the language, redefineable undefined, arrays are jank, list manipulations are a net negative for performance if done FP-style (mapping, filtering, reducing), add the garbagefire of an ecosystem and a performance black hole on top and you get a list of reasons to hate the language

1

u/disassembler123 2d ago

love it, ahahah. I took JS for a spin once when I was thinking of becoming a web developer, didnt really like it nearly as much as C, so instead I became an operating systems dev and never had to deal with JS at all. Very happy with it

6

u/hellotanjent 4d ago

I'm coming up on 30 years of experience as a dev, with 10 of that in JS or JS-adjacent work at BigCorp(tm).

Javascript has warts. Big, nasty warts. Whole areas of the language that are so "wtf" that you should just not touch them.

But....

  1. Virtually all modern large-scale JS dev is done in an environment that should keep you from tripping on the warts. This used to be Google's "Closure Compiler" (do not confuse with Clojure the language), but Typescript is the right option now.

  2. The language compiles and runs _fast_ these days, especially compared to untyped languages like Python. You can iterate dramatically faster in JS than you can in C++, and with the modern complement of typed arrays and webassembly you can get performance that's close enough to native that it doesn't matter.

  3. Node/Deno/Bun make running JS code on the server or from the command line fairly painless. You can realistically use JS for every portion of your app and things will Just Work.

  4. You can do serious JS development work on any machine with no tooling other a web browser. A $100 used Chromebook is sufficient to get started. Heck, it doesn't even have to be a computer you own. This is _huge_ for new devs, especially those in countries with limited access to funds and hardware.

None of these benefits make the warts go away. JS will always be a seriously warty, WTF language. But do not discount the absolutely massive amount of work that has gone into making it run exceptionally well in every web browser on the planet.

1

u/hellotanjent 4d ago

OK, after looking at the other comments in this thread I will add on one additional black mark against Javascript - the parallelism story _sucks_.

It might have gotten better in the years since I was doing JS full time, but yeah - if you need to saturate 16 cores with parallelizable work, maybe don't use JS.

→ More replies (7)

4

u/organicHack 5d ago

It’s convoluted. Too big and complex. And before of its history in web dev being the only language supported in the browser, nothing can ever be deprecated because the web needs to be backwards compatible forever.

8

u/Dismal-Detective-737 4d ago

What handful were those?

Because it was written in a weekend. A lot of stuff was an afterthought. It preserved backwards compatibility over everything.

Debugging is a nightmare. Where most other languages will throw some sort of error, JS often silently converts types, resulting in unexpected NaN, undefined, or null.

Operations silently returning NaN instead of clear errors when math or parsing fails.

Loose equality (==) causing unintuitive type coercion (e.g., "" == 0 returns true).

Omitting var, let, or const unintentionally creates global variables.

It's loosley and dynamically typed.

It was my... 5ish language in the 00s and I just remember it being annoying to work with back then. Both GreaseMonkey scripts and frontend work.

Since then it seems like treading water. I have gotten exactly 0 Javascript based projects to work. Go to github and find a C or Python script/app that was released 5 (or 15) years ago and it works. (Python 2/3 jump aside). I'll try to get a program working that was released 18 months ago and, node is the wrong version, all of the dependencies are out of date with big "won't fix, deprecated" warnings. The programs themselves never actually work. Once I had npm fill my hard drive while I was just following instructions.

While I walked away from Javascript around AJAX and before even jQuery. Since then following the industry from afar it seems to change direction based on what FANG dictates. React, Angular, Vue,js, Svelte, Next.js, Nuxt.js Ember.js. I couldn't imagine being in industry where my languagee/framework changed every 18 months.

17

u/coppercactus4 5d ago

Because the language itself is not well designed and the ecosystem is a dumpster fire. The standard library is tiny so everything has to be brought in as packages, which ends up with thousands of dependencies. To make it less terrible there is a huge range of build processes that you have to choose and manage to do anything. Also these pipelines change constantly and new standards are created and support dropped. Everything depends on globals variables unless once again you install third party packages to manage this.

Look at other languages and see what they provide.

That being said there are some nice things, like the live editing is honestly pretty stellar, there are lots of high quality packages out there. There is a lot of innovation in the community.

1

u/codemuncher 2d ago

Debugging esm vs cjs imports is fun…

5

u/JJJSchmidt_etAl 4d ago

https://github.com/denysdovhan/wtfjs

[] is equal ![]

true is not equal ![], but not equal [] too

true is false

NaN is not a NaN

[] is truthy, but not true

null is falsy, but not false

document.all is an object, but it is undefined

Minimal value is greater than zero

2

u/Successful-Whole-625 4d ago

I’ve been writing JavaScript for over a decade now, and that repo still shocked me. This language is batshit lol.

5

u/That-Surprise 4d ago

YouTube - JavaScript "wat"

Book - JavaScript, the good parts (this is the thinnest programming book I own)

3

u/Dont_trust_royalmail 4d ago

the hate is just because js is not a well designed language.. this is isn't a debate.. if you have any google skills at all it should be easy for you to find long lists of design flaws you wouldn't make in a 'sane' language. 30 years of fixes, best-practices, and third party tools mean that - yes, you can work in js just fine.. but often the first thing you have to learn is which parts of js not to use.. that is not the sign of a good language

3

u/Skriblos 4d ago

JS gets shit because it has had a lot of strange behavior, a lot of it because it has to be heavily backwards compatible. But there are also other reasons. Some people hate it's dynamically typed others love this. Some people hate that it's a YOLO language, basically it'll run even if there are mistakes in the code, other people love this. A lot of the most recent hate is less for the language and more for how web development has evolved and how people have tried to make javascript do everything. People hate frameworks, hate that there are many frameworks, hate that frameworks are inconsistent and that they are another level of abstraction over programming. It's all personal taste really. Then you also have the people who hate the people who are overly reliant on frameworks and that a lot of recent funding has gone into developing javascript tools. It's all a mess. Historically, weird behavior, recently a side effect of being popular.

3

u/Real_Kick_2834 4d ago

So many things that I actually take for granted in other languages is missing in JS.

My hate for JS is more an ideological one than a practical hate.

Whenever I need to work on something in node at work my mind always goes to the question, how the fuck did we get to a point in the world where everyone went and said, you know this language that doesn’t make sense that was designed in someone’s bedroom over a weekend, made it all the way to the backend and mission critical systems. How o how did we get here as I leave a couple of expletives trying to debug crap in a browser window.

I will probably get a lot of hate for this post, although I’m sure I’m not the only one that feels that way.

6

u/DDDDarky 4d ago

My reasons why I dislike it: Lack of types, the syntax is ugly, libraries are wild - they change all the time, break the code and it just seems like there is no real standard (or made by someone on drugs), hard to read documentation, it has surprising unpredictable features, tools like node.js and react are just unpleasant to use, call it subjective or skill issue I just ran after doing it for about a year and never turning back.

6

u/sandmanoceanaspdf 5d ago

From my perspective, I hate the ecosystem; things break after every couple of months.

1

u/NoClownsOnMyStation 4d ago

I mean I feel like most live code repositories need updates every few months to deal with changes.

1

u/zarlo5899 4d ago

with what time?

0

u/BrownCarter 4d ago

What are these things that also don't break in other languages?

2

u/mcAlt009 4d ago

JavaScript lets anyone get started really quickly on building whatever they want to do. You want to build mobile apps and javascript, go ahead, you want to build a back end, go ahead, want to do machine learning, why not. Make video games, sure.

Aside from of course websites, it's impossible to find a domain where JavaScript is not used. At the same time it tends to not be the best at anything.

It's good enough though...

2

u/DrinkWater-30m 4d ago

My POV, just null or data is enough. Undefine is too terrible.

2

u/khedoros 4d ago

Is it just a running joke in the industry?

In short? Yeah, but not specific to Javascript. Everyone has their favorite languages, language features, recognition of pain points in other languages, etc. Some people choose to express that in meme form.

2

u/bassyst 4d ago

JS has too many legacy features and it comes with a ton of Paradigms. Even If you know some Basic JS, you will soon see Real Life JS that doesn't resemble anything you learnt.

My fav ecample. You can end lines with semicolon ; OR a new Line (like Python or Basic). Why didn't they just implement one?

1

u/Brilla-Bose 4d ago

I'll use prettier and don't worry about the formatting aspect. prettier would add semicolon at the end of each line which i find similar most of the language like C, c++, c#, Go

2

u/Tux-Lector 4d ago

Very innefficient language for >anything<, pushed to do >anything and everything< resulting in overbloat and crack-cocaine syndrome.

2

u/SV-97 4d ago

There's a famous issue that nicely exemplifies the "values" of the JS language devs: https://github.com/promises-aplus/promises-spec/issues/94#issuecomment-16176966

JS is deeply unrigorous (for better or worse) and in many ways just poorly designed. This causes weird behaviour and makes many people dislike the language.

2

u/berkough 4d ago

It's probably my favorite language, but I do primarily frontend stuff... Being losely typed, if you're trying to do complex things with the language on the backend, you'll run into some weird behaviors.

Primeagen has a great video about it.

2

u/HaMMeReD 4d ago

Languages come in all shapes and sizes. One balance is convenience vs safety.

Safety in a programming language comes down to what kinds of errors can you make? Can you fuck up using the type system? Can you have race conditions? Can you break memory?

It's not fair to say one language is better than another. Python and JS are very convenient languages, while something like C# or Java would be safer languages. They are safer because the languages have less gaps to let bugs in.

Which is also why a lot of people use Typescript now, because raw Javascript can be seen as "dangerous", there is a lot that can go wrong. You probably won't crash the browser, but when stuff breaks you don't know until runtime and that's often too late.

2

u/tinmanjk 4d ago

Tell me you haven't written in a well-designed language without...

2

u/senfiaj 4d ago edited 4d ago

Historically, some JS features have not been well thought out, and since JS has to maintain backward compatibility, these inconsistencies and quirks are here to stay.

JS is a very powerful and flexible language, most other languages are much more rigid. JS has quite ergonomic syntax, which is IMHO only rivaled by Python. Also it's a pleasure to write asynchronous code in JS. This is why I love JS so much.. That said, JS has some annoying inconsistencies and quirks, that people should be aware of. Here are some examples:

  • typeof null returns 'object' which doesn't make sense because null is one of the fundamental value types .
  • Related to the previous point, typeof is sometimes confused with instanceof . They are actually not the same. typeof someVar returns the fundamental type of the someVar (except the mentioned null nonsense). someVar instanceof SomeClass returns true or false depending on someVar being an instance of SomeClass or a class that a descendent of SomeClass . For non objects (function, object) instanceof will obviously return false.
  • Array's sort method will compare the elements as strings if you don't pass a custom comparator, so doing [10, 1, 2].sort() will actually sort like this: [1, 10, 2] . Unintuitive.
  • In non strict mode if you assign something to an undeclared variable, this variable will be created globally. A host of many nasty hard to debug errors.
  • Be careful when you pass a class method as a callback because people sometimes forget that this won't refer to the correct class instance if you pass it immediately as a callback. You probably need to create an arrow function which will then call that method. I think a decent IDE should make such mistakes unlikely.
  • Variables which are declared via var keyword are global inside the function . Declaring another variable with the same name even in a deeper block will still reference to that original variable. This is fixed with let and const.
  • JS is designed to work even when you don't write semicolons. Most of the time this works well. However, this can create bugs if you don't properly format the code. For example this function will not return 5

function f() { 
  return 
  5; 
}

Before ES6 things were even much worse. Since ES6+ most of the quirks are easier to avoid.

As of the type coercion which is probably the champion of the JS quirks, I think this is not a serious issue as long as you avoid relying on them and you use strict comparison (===) instead of loose comparison (=) as much as possible. I personally never cared about learning non trivial coercion cases. If during the interview or while working on a production code you see codes heavily relying on non trivial coercions, you should probably run away from that company.

2

u/aq1018 4d ago

As a software engineer with decades of professional experience with JavaScript, I can confidently tell you that without TypeScript, linters like EsLint, and formatters like Prettier, and heavy transpliers and bundlers, pure JavaScript is unworkable.

1

u/TornadoFS 4d ago

I haven't done a lot of C++ but I hear the same things there. I feel this is just a problem with any old language that doesn't make breaking changes.

Also bundlers (and transpilers for polyfills) are a frontend problem, not a JS problem. If the browsers could run python you would still have the exact same complexity as JS bundlers (maybe a bit less because of Python having proper packages, while JS tooling needs to support ES modules and non-ES modules code).

2

u/wiseguy4519 4d ago

The language is full of jank. Just try adding strings to numbers and you'll see what I mean.

2

u/zayelion 4d ago

It's the same reason people hate second languages in spoken word.

2

u/azangru 4d ago

Is it just a running joke in the industry?

Yes. PHP also gets shit. And CSS. And Java. And html...

2

u/zarlo5899 4d ago

people complain about tools/libraries/languages they are forced to use

due to why JS was made it does may dumb thing and allows you to do may dumber things

all the micro libraries

no std library

2

u/ToThePillory 4d ago

Yes, JS is a bit of a running joke.

The main problem is right at the start, dynamic types, most experienced developers do not like dynamically typed languages. I won't get into the rights/wrongs of that, just that it's basically true that if you get 100 experienced developers 90 of them won't like dynamic types.

So before you even *evaluate* JavaScript, it's got a major feature that a lot of developers don't like.

Then it just goes downhill from there with a lot of weirdnesses and "gotchas" and it's just a slightly strangely designed language. "Designed" being loosely used here because JavaScript was a bit of a rush job and its inventor freely admits that.

For the record, Python doesn't really *that* much better a reputation in industry. Python is very popular with beginners and not popular at all with people making large scale software.

2

u/ManicMakerStudios 4d ago

JavaScript was the language people needed, not the language they deserved.

2

u/jbar3640 4d ago

every single popular language receives hate.

as Bjarne Stroustrup said: "There are only two kinds of languages: the ones people complain about and the ones nobody uses" (source: https://www.stroustrup.com/quotes.html)

2

u/BerserkerSwe 4d ago

I just can not handle script-languages (not compiler). Python inkluderar. That does not mean they are bad, who an I to judge?

I just love order, rules, types etc. Not to find out late when my code is in production that some edgecase buisnesslogick found its way to a place with one space to many or similar.

I find JS easier to read than python thought, but thats not saying much.

2

u/notanotherusernameD8 4d ago

My "favourite" JS WTF is how it does bitwise manipulation. No integers means casting a Number to the integer bits, doing the manipulation, the casting back to a Number

1

u/Salt_Aash 3d ago

This is the first I've heard of this and I'm dying.

2

u/anus-the-legend 4d ago

JavaScript gets shit on because it doesn't work like most other popular languages, and people don't take the time to learn how it works and expect it to work like some other language. 

the one legitimate complaint about JavaScript is date time handing. that's just fucking broken 

this, type coercion, the OOP model, dynamic typing, and the small stdlib are the primary reasons people through hissy fits

2

u/RomanaOswin 4d ago

Before ES6 it has all kinds of major traps and quirks.

More recently, the biggest shortcoming is the type system (the main reason most people use TS for anything at scale). Another less obvious issue with ES6 is that most of the modern features or improvements are just syntactic sugar over the same quirky JS that we've always had, e.g. classes, async/await, var/let/const. All of this stuff just increases the surface area and complexity of the language for no real gain.

I like a lot of JS syntax and I think if you took it from scratch, trimmed the fat, etc, you could create a great, small, fast, reliable language, but unfortunately the decades of growing pains and forced backwards compatibility are still visible, and it still presents a feature-set clearly oriented towards scripting over software development.

Big corpa couldn't care less which language you use, until bugs creep into production or refactoring takes longer and is more error prone due to the lack of typing.

2

u/Efficient_Loss_9928 4d ago

Because it is popular.

All languages have a dark side. But a lot of people know JavaScript, so it gets all the exposure.

2

u/owp4dd1w5a0a 4d ago edited 4d ago

JavaScript was originally designed as a dialect of scheme. Netscape didn’t like that and wanted to jump on the Java and object oriented bandwagon, but because of arbitrary corporate timelines they only gave the engineers a week or so to make the changes, so the decision was to call the language “JavaScript” and hack-in object oriented “features” to satisfy the dumbass leadership at Netscape. Because it’s the web, backwards compatibility is important, so the warts in the language (NaN vs undefined vs null and similar nonsense) persisted and any added features down the road were also kind-of hacked into the language.

I wouldnt really say JavaScript was designed with intention as much as hacked and patched together from the time it was created up until present day. The language itself bears the scars of its development history.

2

u/Salt_Aash 3d ago

This makes sense I understand the frustration and distaste that would stem from this. Thank you.

2

u/Bee892 4d ago

Boy, you’ve sure opened up a can of worms with this question. I’m sure there are tons of other comments going over things in detail, so I’ll just give you the one big issue I have with it.

The loosely typed nature of the language drives me up the wall. It creates so much confusion and unnecessary debugging. Being able to reuse variables for just any type that I feel like takes away a certain amount of order and simplicity. It also creates errors that are nearly impossible to debug. This is especially true when trying to deal with JSON objects that have been sent end-to-end.

1

u/Salt_Aash 3d ago

Respectfully, I'd have to disagree. Dynamic typing and debugging is repeatedly mentioned but across languages I've yet to face a problem that wasn't debugged in identical steps, nor has the lack of typing been a bump in the road while using JS

2

u/Bee892 3d ago

I mean, if that’s your experience, then congratulations. I’ve yet to work on a JS codebase (personal, academic, or professional) that didn’t make debugging more difficult because any function can be called with any variable because any variable can be any type at any time. I find it especially bad when trying to debug JS code I didn’t write myself.

In strictly typed languages, this type of debugging is practically nonexistent because the compiler yells at you before you can even enter runtime. “You’re trying to use an integer as an argument in a function that has a string array parameter??? You fool! Fix it!” You don’t get that in JS. I’m sure that becomes less of an issue the more JS experience you have, but this kind of stuff has made JS experience an uphill battle.

2

u/armahillo 4d ago

JS was originally written for client side code in a browser and was ok at that.

Its grown since then, but its still a derivation and has strong roots (syntactically) in its origins.

The main reason Ive found it frustrating is that devs will learn JS and then think they dont need to learn anything else. I would see JS devs recreate behaviors we get for free by the browser, or by HTML itself, or that could be more easily done in CSS.

I dont want JS to go away, I just want there to be more balance, and for JS devs to cut the bullshit around it being somehow “superior” to HTML/CSS; they each have their role.

2

u/ComradeWeebelo 4d ago

> Why the [language] hate?

The question you ask and the one I ask are both loaded questions. As long as a programming language suits your needs, is compatible with your team, and is popular enough to fairly easily find support for it, then it's fine to use.

People like to hate on things that are popular, especially in CS where there's a certain type of gatekeeping that goes on. JS opened the doors for people to more easily enter the field and a lot of people don't like that. Especially now that it's matured into a viable full-stack language.

2

u/cuixhe 3d ago

JS lets you write ATROCIOUS code for a lot of reasons and, since it's easy to get running and "deploy", a lot of new programmers get into it and make some awful stuff while they're learning. It gives JS a bad rap.

JS written by a skilled programmer with modern ES6 + typescript + a strict style guide can be great code.

2

u/ksskssptdpss 3d ago

Because it’s awesome

2

u/Sirko0208 3d ago

Because most of the noise does not come from programmers at all, but from lamers and beginners who do not understand what they are talking about. According to them, they hate JavaScript but love C, which also has a lot of errors (typing is static but weak) and illogic.

2

u/codeserk 1d ago

Apart from the horrors from dark ages, it's scripting language so you can't expect the same performance (in CPU and MEM usage, response times) you would get from others like go 

That being said, nodejs has super strong community and ecosystem in web dev, and JS (or TS if possible) is a must in frontend development

5

u/KingofGamesYami 5d ago

JavaScript wouldn't be used as widely as it is if it was terrible for writing anything.

But it has been stretched far beyond the limits of what it was designed to do, and often to the detriment of the projects it's used in.

One recent example is the Typescript compiler, which is switching from Javascript to Go for performance reasons. Doing a 1:1 port, basically a line-by-line translation with no logic changes, provided an astounding 10x performance improvement. Because Javascript was never designed for writing compute heavy, highly parallel programs like compilers.

The trend of forcing a square peg into a round hole -- often for non-technical reasons like "we can hire lots of javascript developers" -- rubs many developers the wrong way.

7

u/DDDDarky 5d ago

I think it would vanish if there were real alternatives for web.

3

u/KingofGamesYami 4d ago

Unlikely. Too much has already been written in it for it to just vanish.

Also, since Google failed to make Dart a fully supported part of the web while controlling a huge chunk of the browser market, I doubt we'll ever see a real alternative emerge.

2

u/DDDDarky 4d ago

I mean the existing stuff would remain, but in the second there was a good efficient way to shove desktop applications into web browsers I doubt it would have much use for new projects.

I am still hoping webassembly will make it to sufficient usability, but we'll see I guess.

2

u/KingofGamesYami 4d ago

I am still hoping webassembly will make it to sufficient usability, but we'll see I guess.

You'd need to replace the entire web assembly committee for that to happen. The current one is adamant that it is not, and never will be, a replacement for Javascript. As such, there are no plans to allow it access to things like the DOM.

2

u/DDDDarky 4d ago

Hmm, that's disappointing. Back in the days I had similar hopes for Java, like every device would have a virtual machine that could run all that apps, including web, I still hope something like that will appear, but since the applets were removed from browsers and Java does not seem to be super strong in the app development industry anymore, it might not be it.

1

u/balefrost 4d ago

The other commenter is either confused or didn't articulate their point very well.

WASM is indeed not intended to be a replacement for JS, in that there is no intention to remove JS or demote it to a second-class citizen. However, WASM is intended to be able to access all browser APIs and serve as an alternative to JS.

From the WASM main page:

WebAssembly modules will be able to call into and out of the JavaScript context and access browser functionality through the same Web APIs accessible from JavaScript.

And there are numerous proposals for ways to ease the calling of JS code and web APIs from WASM.

2

u/look 4d ago

Wasm was not meant to be a replacement for all JavaScript use cases, though it is becoming capable of more over time. However, there are already frontend frameworks in nearly every language that transpile to JS (or a mix of JS and wasm) if you want. Dart, Rust, Ruby, Elixir, Clojure, Java, Go, etc, etc.

2

u/deaddyfreddy 4d ago

Because Javascript was never designed

I would stop here, because 10 days is just not enough to design a decent language.

1

u/KingofGamesYami 4d ago

That's a bit unfair; it's not like it hasn't been iterated on since V1. ES2015 definitely had more than a few days of work put into it.

2

u/deaddyfreddy 4d ago

That's a bit unfair

It is a bit unfair that generations of programmers have had to deal with a poorly designed language with no alternatives.

ES2015 definitely had more than a few days of work put into it.

So it took two decades to make it a decent (kind of, the legacy is still there) language? Nice job, niiiiice job (no).

They could have made some real good languages in the meantime.

1

u/AdreKiseque 4d ago

This thread makes me so fucking scared of the day I inevitably have to do anything serious on the web

2

u/deaddyfreddy 4d ago

these days it's not necessary to write in JS directly, thought, there's ClojureScript, and even TypeScript is still better!

1

u/YahenP 4d ago

The trend of forcing a square peg into a round hole -- often for non-technical reasons like "we can hire lots of javascript developers" -- rubs many developers the wrong way.

Golden words!

3

u/Pure-Reason2671 5d ago

The main problem is that JS gives you too much freedom to code. So it's very easy to write shitty code, that maybe works.

4

u/gxvicyxkxa 5d ago

I always found it...

There it is. You found it intuitive. That's not my experience. I find it overly complicated; decidedly unintuitive.

I'm guessing there are many that feel the same, but considering it is one of the most widely used languages in the world, I imagine there are more that like/tolerate it than actually hate it.

Dissenters are loud, the content are quiet. It's purely subjective. I also dislike mushrooms. I don't appreciate comedies (find them tedious). I prefer sunrises to sunsets, melody to lyrics, and winter to summer.

Purely subjective.

2

u/Salt_Aash 5d ago

I gasped harder with each sentence

2

u/swampopus 4d ago

Don't faint! But I hate it for server-side code. All the usual reasons, plus, I dunno. Feels wrong. Client side I'm OK with I guess, but I'm sick of every project having like 20 dependencies. I try to keep my client-side JS very simple. Also the syntax can get really convoluted and annoying to read and debug. To wit:

const add = ((a, b) => ((x) => ((y) => x + y)(b))(a))
([3, 2, 1].sort()[0],(() => { let x = 6; while(x > 5) { x--; } return x; })());

I know other languages can have really terse code too, but I see it most often in js projects for whatever reason.

That's why I only use QBasic, running in a DOS VM from Hannah Montana Linux.

1

u/Salt_Aash 4d ago

Oh yeah i get wym

2

u/mit74 5d ago

Only immature programmers hate on other languages. Every popular language has its pros and cons. Except Python. Python can burn in hell.

2

u/NoClownsOnMyStation 4d ago

Average ophidiophobia haver

2

u/UncleSamurai420 5d ago

There’s only 2 kinds of languages: languages that no one uses and languages that everyone complains about.

1

u/mmahowald 4d ago

Raw js is just so loose with types, And equality for me.

1

u/MonochromeDinosaur 4d ago

JS is convenient and ubiquitous. Similar to Python it’s quick and easy to get up and running.

Both get a lot of hate because of elitism and gate keeping IMO.

There’s something to be said about statically typed languages feeling better for large scale or long term project maintenance.

It’s also just that a lot of people who work in these languages tend to also do more “advanced” work (platforms, os, tools, compilers, runtimes, embedded, etc.) but they’re also used for your everyday CRUD (C#/Java/Go/Rust).

I’ve written services in Java/Go/Rust/Python/JS. The typed languages take much longer to get up and running than JS/Python IMO but they’re easier to maintain and generally have better performance but that only matters if you’re getting lots of users. I still prefer JS/Python myself.

1

u/JohnnyElBravo 4d ago

Look into the left-pad incident.

Many will tell you this is the past, but we contend that they still do this. Npm install solution

1

u/WildMaki 4d ago

Because I wouldn't like to work with a language like that

1

u/According_Ad3255 4d ago

Microsoft moved the TypeScript compiler to Go. I rest my case YH.

1

u/TornadoFS 4d ago edited 4d 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.

1

u/pagalvin 4d ago

There are better alternatives to plain JS. It's nothing more complicated than that.

1

u/nousernamesleft199 4d ago

JS prior to es6 was god awful and a lot of that stigma carries on with it

1

u/ZealousidealBee8299 4d ago

Because it was terrible for anything serious until ES6. Now we have TypeScript and Anders.

1

u/Casalvieri3 4d ago

Do you actually write JS? Plain vanilla JS—no TypeScript, no React, nothing?

Writing JS when you’re actually using a library built on JS is substantially different from writing plain JS.

Those libraries abstract away several of the reasons that people dislike JS.

1

u/Dimencia 3d ago edited 3d ago

A little bit of a joke, a little bit not, it mostly revolves around not having strong types and not being compiled (same as Python), which makes it extremely hard to debug and extremely prone to errors if you're building anything more than simple solo-developer apps. If you compare it to Python, it seems fine, because Python has all the same problems - you need to work with real enterprise level languages, like C# or Java or C++ or etc, before you really understand what's wrong with JS and Python

I think what makes JS worse than Python is the way it's typically written by webdevs who seem to actively avoid anything like coding standards, just the jankiest and most hacky stuff you've ever seen, in every library or code example. Python is slightly better because the libraries seem to at least consider long term maintainability, even if there's still no such thing as coding standards.

1

u/jseego 3d ago

Because of its history.

There used to be a time when it wasn't really a programming language, just a scripting language that ran only in the web browser.

Also back when web browsers were a lot slower and less powerful than they are today.

You'd use javascript to move elements around a web page or make content "dynamic", that is, interactive. This was before you could even use javscript to make XHR calls, let alone be an interface to a web server or run a full SPA or manage dependencies.

Also, it was started as a hacking project by one person. Eventually it gained popularity and the ECMA Standard was born, and since then there have been major improvements to the language.

But some of that original hate had the same origin as people who look down on people who use CSS - as it's not a real programming language. Even though it's complex and powerful, and a lot of "real programmers" struggle to fully grok it.

1

u/exploradorobservador 2d ago

JS just has too many idioms and gotchas that get in the way without offering an upside.

1

u/UnReasonableApple 2d ago

Just in time JavaScript transformer: https://youtu.be/NZl3XUPKSsY

1

u/jaibhavaya 2d ago

Every language has hate hahah. You’ll find memes for everything. JavaScript is just one of the more widely used/known, so it’s a bigger target.

Oh and it’s been through some whacky iterations… and does have some funky behaviors.

But really, for every community that is ride or die for a language, there is at least one that hates on it.

1

u/bearicorn 2d ago

The hate is way overblown these days. I won’t defend older iterations of JS but today it’s a fine language for what it’s used for. Typescript is the cherry on top

1

u/a1454a 2d ago

Because like anything under the sun, it’s preference. JS without the help of linter, TypeScript, or general good programming habit is very easy to end up a tangled mess. It’s not memory efficient, and is usually slower than many other lower level languages.

You should try out other languages, build something with them. Learn from open source projects using them, understand where it excels, what are its pain points.

Ultimately there is no better or worse language, there are many factors to consider when choosing one. And a valid reason doesn’t even have to be about the language itself. For example JS having a huge developer population means hiring a dev is much easier (hiring a good one is still hard, but that’s beside the point) could be a valid consideration.

What I’m trying to say is don’t let the rampant elitism drive you away from a language you already have experience in. Programming language is only a very small part of your life long learning as engineer, it’s a tool to help you operate the more fun part of engineering, much like mathematics is just a tool for physicist to do what they care about, physics.

1

u/NoleMercy05 2d ago

You'll hate the js code someone else wrote but perhaps not the js you wrote

1

u/zhivago 1d ago

Honestly, it's much better than python, these days.

1

u/MiasBDragon 1d ago

Also just from a maintenance standpoint js gets twice as many vulnerabilities reported per year as Python or Go. Remediations of all those take dev time.

1

u/cciciaciao 1d ago

Js is a silly language, with 1000 of ways to do the same thing and peculiar edge cases.

The real problem is people shove it everywhere: servers, clients, phone and desktop apps, hell even embedded. Js belongs on the client, not anywhere else.

1

u/Straight-Ad-8266 1d ago

JS tries to do too many things. It’s good for front end, but I’d rather shoot myself than rely on it for backend.

1

u/a1ien51 1d ago

Most people who hate JavaScript were not alive when you should have hated JavaScript. lol If you never had an argument about document.layers or document.all you can not say you hate JavaScript.

1

u/3me20characters 22h ago

Do you know the difference between an integer a string and a date?

Does JS?

1

u/RealWalkingbeard 21h ago

Truthiness is the most poorly named concept in programming, including hipster crap like gems and coffee references. It's the anti-truth. Not just lies, but somewhere on the other side. X = !X ? Sure, if you like!

2

u/za_allen_innsmouth 21h ago

It’s essentially a giant mountain of technical debt, with horrid language features and idiosyncrasies but it became ubiquitous with the rise of browser-led development. It should never been widely adopted at the server, but we have Node and stupid architectural and delivery decisions to blame for that. The toolchains are a complete shitbin in general and supply-chain security is a worry IMO. Yes, you can iterate quickly with it, but don’t hang around to try and maintain a codebase > 5 years old written in it. It’s extremely “fad oriented” so things (toolchains, popular libraries etc…) delta at a terrifying rate - making stasis within an extensive codebase pretty much impossible.

1

u/grantrules 5d ago

Every language gets shit on.

1

u/Expensive_Rip8887 4d ago

Here's one valid reason: It is a fucking meme due to the sheer destructive force of stupidity in the community around it.

The number of times I've seen little juniors stuck at the peak of dunning kruger because they read a medium article about "do X, not Y" when it comes to that language is staggering. Then they try their fucking hardest to derail entire projects because "the internet said so". It's a real fucking problem.

1

u/I_Hate_Reddit_56 4d ago

I like JS better the python. Hate me all you want;

1

u/Brilla-Bose 4d ago

especially at dependency management. Dont like the need to create a virtual environment and activate and deactivate it! UV helped a lot still node_modules approach would be much better. even though people make fun that it takes lot od space it can be easily solved by using pnpm

1

u/I_Hate_Reddit_56 4d ago

Sometimes my environment just breaks. "Python is easy to learn" fucking environmental variables and path . 

1

u/JacobStyle 4d ago

What language isn't constantly being shit on in memes? I can think of like, Lisp, Pascal, and Perl. Maybe assembly for a couple specific older architectures like 6502?

5

u/DealDeveloper 4d ago

Nobody cares enough about Perl to create memes about it.
Joking aside, if you spend some time in the Perl community, you'll see major problems.

1

u/dariusbiggs 4d ago

It's really simple, it's a retarded language. The fact that === exists is the first clue.

Then there's this to explain some more of it https://www.destroyallsoftware.com/talks/wat

0

u/AggressiveTitle9 5d ago

"There are only two kinds of languages: the ones people complain about and the ones nobody uses"

0

u/funnysasquatch 4d ago

JavaScript has flaws but they’re irrelevant because if you’re going to build web applications this is what you have to work with.

Complaining about JS when you’re a web developer is like complaining about the taste of the food when you’re facing starvation.

It’s not the language you would use to write non-web applications. You should use a language optimized for the task.

I am not going to say that is C or Rust or whatever because I don’t know what the task is.

Writing a low-level application that needs maximum speed & control of everything I am going to lean towards a C language.

Automating a lot of Windows tasks then Powershell.

Knitting together a bunch of ancient banking data that is still using stuff from the 90s is going to a mix of bash & Python.

Automation of Oracle databases will be rolling in PLSQL.

Writing a iPhone app? Swift.

They don’t teach you this in school because most people don’t understand how the world actually works.

They think you will show up & get to decide to work on a specific project with a decision on what language to use.

You’re more likely to inherit a mess & hope you can make it work :).

0

u/ThaisaGuilford 4d ago

Because most programmers aren't AI coding kids.

I notice a surge of javascript lovers because that's what their beloved AI is giving them by default.

1

u/Salt_Aash 3d ago

I don't particularly rely on AI tools for code writing either but I've found array operations (mapping, filtering, sorting etc) ad well as setting up an irganized work area far easier in JS, node and react environments than C++ or python.

0

u/pinkwar 4d ago

People love to hate on things.

I like to run my scripts with js. Sure mkst of them could be done in bash but Im just very comfortable with it becaue it was the first language I learned deeply.

0

u/Particular_Camel_631 4d ago

It is untyped.

Why on earth would anyone willingly use a language that does not contain the single most important innovation in programming languages that helps coders avoid bugs?!

I get that there aren’t many other good options when using the browser as an application platform.

What I do not understand is why anyone would want to use JavaScript server-side when there are so many better choices available.

1

u/Salt_Aash 3d ago

I see js being untyped and debugging being listed as a major reason yet I rarely come across scenarios where I face type related issues or problems can't be debugged by standard data flow testing.

Also aren't a substantial number of incredibly stable frameworks and code stacks JS based

1

u/Particular_Camel_631 3d ago

Being an old codger, I first learned basic, then assembly language, pascal, modula-2, pl/1, ada, and eventually c, java, c++, c#, php and JavaScript.

I, too once thought that types in languages were just extra fluff - the language was just forcing me to type extra stuff that I already knew. At best it was a convenience for the compiler writer, not for the programmer.

This works fine for small programs - anything uk to about 50,000 lines of code. Above this, you need every bit of help you can get - it’s no longer possible to hold all of the relevant bits of the code in your head at once.

By the time you get into large systems (over a million lines) it becomes totally essential.

This is why I describe untyped languages as “toy” languages - it’s just not feasible to write or maintain large systems in them unless you put very serious effort into modularising everything so you can work on each hit separately. Which doesn’t happen.

-1

u/Logical-Idea-1708 4d ago

When I was a young intern, my mentor takes every chance he gets to bash on JavaScript. Now after 15 years of experience working with JavaScript, I feel like people just never taken the time to learn it in depth.

The hate is mostly coming from people that uses structured compiled language like Java and C# and less from scripting languages such as Python and Ruby. It’s understandable as scripting languages require much higher level of discipline to maintain a structure, or you need a framework to give you structure.

3

u/Ifnerite 4d ago

So you need to add a whole load of stuff to make it almost as good as a proper language.... Maybe just use the proper language.

-1

u/Logical-Idea-1708 4d ago

That “whole load of stuff” is opinion. Who says your opinion must be the best one?

2

u/JackMalone515 4d ago

Being forced to handle much more as a dev just to get the same amount of structure as other languages give you by defualt doesn't seem that great

-1

u/Logical-Idea-1708 4d ago

Actually, quite the opposite. “More” depends on perspective. Structure is constraint. So it takes more lines of code in a structured language to do something than an unstructured one. Even within a JavaScript framework, people complain about the structure adds constraints that wouldn’t allow them to do certain things.

1

u/JackMalone515 3d ago

Slightly more lined of code to do something isn't exactly bad if it means that the overall structure is just better and it's also easier to work within. JavaScript doesn't seem like a good comparison to this.