Live data from Hacker News

On JavaScript's Weirdness

stack-auth.com

51–60 of 85 posts

Re: On JavaScript's Weirdness

#51

While interesting and possibly helpful to new coders, are these quirks of the language still relevant when most development in Javascript is done using a framework (React, Vue, etc) these days? How often do these "gotchas" factor into "modern" Javascript development, especially in production? These type of articles seem to critique mechanics of the language that don't come up as often in practice.

It's worse in a framework, in the framework you need to know the oddities of the language as well as how the framework manages them.

Re: On JavaScript's Weirdness

#52
post #18

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 does…

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.

Re: On JavaScript's Weirdness

#53
post #16

Earlier quoted context omitted.

Since I started using Prettier, I've moved permanently into the no-semicolons camp. Prettier catches ASI hazards and inserts semicolons where needed, and I've never seen it fail. Whichever camp you're in though, put it in your linter, don't leave it to chance. React code is full of array destructuring, that particular hazard is prone to bite you if you ignore it (tho it's still a little contrived if your usual style…

The rules are not that many, you can omit semicolons everywhere except 1. Before open square bracket 2. Before open parenthesis. That's it, those are the only 2 edge cases.

Instead of learning a rule and then memorizing exceptions to it, you could just learn a rule with no exceptions.

Re: On JavaScript's Weirdness

#54

While interesting and possibly helpful to new coders, are these quirks of the language still relevant when most development in Javascript is done using a framework (React, Vue, etc) these days? How often do these "gotchas" factor into "modern" Javascript development, especially in production? These type of articles seem to critique mechanics of the language that don't come up as often in practice.

You are right, these quirks are not something you struggle with very often. The only one that has been troublesome at some point during my now 8 years as a professional, mainly Javascript with Vue, web developer is the automatic semicolon insertion example.

The simplest fixes for it is to just insert semicolons yourself, always use const, and not start any lines with [ or (.

Re: On JavaScript's Weirdness

#55
post #16

Earlier quoted context omitted.

The rules are not that many, you can omit semicolons everywhere except 1. Before open square bracket 2. Before open parenthesis. That's it, those are the only 2 edge cases.

Instead of learning a rule and then memorizing exceptions to it, you could just learn a rule with no exceptions.

I dont need to memorize anything, the 2 rules are inferable from how js works and you will get typescript (not even linter) flagging lines starting with those brackets anyway.

Re: On JavaScript's Weirdness

#56
post #16

Earlier quoted context omitted.

Since I started using Prettier, I've moved permanently into the no-semicolons camp. Prettier catches ASI hazards and inserts semicolons where needed, and I've never seen it fail. Whichever camp you're in though, put it in your linter, don't leave it to chance. React code is full of array destructuring, that particular hazard is prone to bite you if you ignore it (tho it's still a little contrived if your usual style…

The rules are not that many, you can omit semicolons everywhere except 1. Before open square bracket 2. Before open parenthesis. That's it, those are the only 2 edge cases.

No, there are quite a lot of other edge cases. E.g. you also need them before backticks and in many places in class bodies.

Re: On JavaScript's Weirdness

#57
post #18

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 does…

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

  if (value == null)

Re: On JavaScript's Weirdness

#58

While interesting and possibly helpful to new coders, are these quirks of the language still relevant when most development in Javascript is done using a framework (React, Vue, etc) these days? How often do these "gotchas" factor into "modern" Javascript development, especially in production? These type of articles seem to critique mechanics of the language that don't come up as often in practice.

Quirks in this article and others like it are not something that would be encountered under normal circumstances unless the programmer is doing something silly (like skipping semicolons, ever touching eval, or relying on type conversions). Now, second point about loops (actually scopes and value declaration) is a core part of the language and needs to be learned, framework or no framework.

Re: On JavaScript's Weirdness

#59

Many mistakes in section 2. The author seems to fundamentally misunderstand block scoping vs lexical scoping, and interactions when deferring execution to the next run of the event loop. In the first example: for (let i = 0; i console.log(i)); } // prints "0 1 2" — as expected let i = 0; for (i = 0; i console.log(i)); } // prints "3 3 3" — what? i's scope is outside the for loop in the second example, and the setTime…

For anyone who wants to see some more explanations/experimentations around for loop semantics, this Chrome Developers video is great:

https://www.youtube.com/watch?v=Nzokr6Boeaw

Re: On JavaScript's Weirdness

#60
post #18

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 does…

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?

Post reply on HN