Hacker News Reader

Comment by rs186 | Hacker News Reader

I can pretty confidently say that every article I have seen in the past 5 years that complain about weirdness of JavaScript is about things that you would never do in a modern, production-level codebase. Many of these issues are about pre-ES6, outdated practice (e.g. eval, using == operator) that are almost certainly going to be flagged by a linter. Very occasionally, you do get hit by some weirdness, but likely doesn't take more than a few minutes to figure out. And if you write in TypeScript, like almost every serious new project created these days, most of these questions don't exist at all.

Which is why I don't bother reading these posts any more.

View on HN

If you actually opened the article, I think you would find it interesting. I agree that a well-configured eslint catches 99% of the weirdness, but this article tries to be about the remaining 1%.

Yes, and the first one is eval, something that one should not use outside extraordinary situations.

If the language needs a linter to keep otherwise-competent developers from introducing potentially maddening bugs into the codebase, it's weird.

JS was developed in a hurry and has been extended into doing things it was never meant to do, and it shows.

If weird means out of norm, that's not the case. Every language either has a linter or would benefit from a linter because all languages have warts or idiosyncratic behavior.

Some languages are so error-prone and hard to use they even ship with static analysis and type-checking built in, like Rust and C! (And they still have linters on top of that!)

Perhaps post a language you think is exceptional to this?

Every language could benefit from a linter.

Given how accessible and widespread it is, it's hard not to make mistakes in JS without a linter.

Can you shoot your foot off with C or Rust? Sure. But they're systems programming languages for the most part, and aren't realistically proposed as tools in the "move fast and break things" world of web development where JS rules supreme. Ruby and Python are also used in web dev, albeit on the back-end, and they're not as idiosyncratic as JS.

> If the language needs a linter to keep otherwise-competent developers from introducing potentially maddening bugs into the codebase, it's weird.

This is an odd way to phrase things. A better way to look at this is that there are programming tasks which can be easily automated and tasks which cannot be easily automated. The ones which can be easily automated should be, so that humans can focus on the ones which cannot be easily automated. Do you not run automated tests, since those same tests could be done over and over by hand?

That's not really a useful way to think of it.

Javascript could not have been released perfect for all current and future uses. Thus it either needed to change or fall out of use.

It changed.

The linting is simply part of a migration mechanism that allows for the change to happen. Compatibility is maintained for existing code, while on-going and future development can avoid the bad/obsolete parts. It's not random that eslint has such fine-grained configurability -- it allows each code base to migrate at whatever rate makes sense for it.

So all this is simply a product of javascript's longevity, which itself is a testament to its utility and flexibility. You call it "weird" but it would be a damn shame if it wasn't as useful and flexible as it is.

You should have probably read the post.

I did.

Maybe it is outdated practice but I still use == operator for null or undefined check.

  if (value == null)

yes `== null` is quite convenient for the null or undefined check.

In general, the whole `==` versus `===` is a silly argument in a typescript codebase, because if you know the types of the arguments, `==` behaves predictably.

Reply on news.ycombinator.com