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.
On JavaScript's Weirdness
51–60 of 85 posts
Re: On JavaScript's Weirdness
#52I 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…
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
#53Earlier 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.
Re: On JavaScript's Weirdness
#54While 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.
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
#55Earlier 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.
Re: On JavaScript's Weirdness
#56Earlier 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.
Re: On JavaScript's Weirdness
#57I 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 (value == null)Re: On JavaScript's Weirdness
#58While 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.
Re: On JavaScript's Weirdness
#59Many 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…
Re: On JavaScript's Weirdness
#60I 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.
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?