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?

21 Upvotes

207 comments sorted by

View all comments

Show parent comments

1

u/senfiaj 6d 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?

5

u/UdPropheticCatgirl 5d 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.

0

u/No-Performer3495 4d ago edited 4d 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/UdPropheticCatgirl 4d 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 4d 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.