3 ms·

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

by rs186 2y ago

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.

sapiogram 2y ago
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%.
- deleted 2y ago
  [deleted]
- rs186 2y ago
  Yes, and the first one is eval, something that one should not use outside extraordinary situations.
Philpax 2y ago
You should have probably read the post.
- rs186 2y ago
  I did.
lenerdenator 2y ago
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.
- hombre_fatal 2y ago
  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?
  - lenerdenator 2y ago
    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.
- tshaddox 2y ago
  > 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?
- jmull 2y ago
  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.
max23_ 2y ago
Maybe it is outdated practice but I still use == operator for null or undefined check. if (value == null)
- jeeyoungk 2y ago
  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.

by rs186 2y ago

sapiogram 2y ago

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%.

deleted 2y ago
[deleted]
rs186 2y ago
Yes, and the first one is eval, something that one should not use outside extraordinary situations.

Philpax 2y ago

You should have probably read the post.

rs186 2y ago
I did.

lenerdenator 2y ago

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.

hombre_fatal 2y ago
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?
- lenerdenator 2y ago
  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.
tshaddox 2y ago
> 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?
jmull 2y ago
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.

max23_ 2y ago

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

jeeyoungk 2y ago
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.