"Your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should."
- Jurassic Park. Also, what I think about every time I learn about a "feature" of javascript (like all of the examples in this post) that allows you to do things that would cause any other compiler developer to laugh you out of the room.
Babel usually only processes code you write so, assuming that the developer isn’t relying on document.all being falsy or similar makes sense: !document.all === true is surprising and the sort of thing that should be banned with lint rules.
Also, a lot of compilers have ways to enable normally unsafe transformations: in sbcl, for example, if you (declare (safety 0)), the compiler will just automatically trust your type declarations and generate machine code that is unsafe if this assumption isn’t true: it’s useful because sometimes “correct” behavior has an unacceptable performance cost.
In theory dependencies shouldn't matter, because normally only your own code goes through Babel; library code has typically already been transformed into least-common-denominator JavaScript
Most of these are pretty hard to do by accident... I didn't even know about maybe a third of these things, and I've been writing JavaScript for 10 years
A significant exception to all of the generalizations I've been making is iterableIsArray:
> When using an iterable object (in array destructuring, for-of or spreads), assume that it is an array.
Violating this one is neither an anti-pattern nor hard to do by accident. It would mean a significant shift in practices for a project, and it would have to allow for some really exceptional optimizations if I were going to even consider enabling it
Undefined behavior is overhyped. Most undefined behavior is perfectly defined and supported on the particular platforms being developed for. The official C specification is not a platform.
8 comments
[ 22.3 ms ] story [ 1982 ms ] thread- Jurassic Park. Also, what I think about every time I learn about a "feature" of javascript (like all of the examples in this post) that allows you to do things that would cause any other compiler developer to laugh you out of the room.
I'm assuming if you're writing Babel plugins maybe you want to turn some of these features off so you can make it do alternative behaviour?
Also, a lot of compilers have ways to enable normally unsafe transformations: in sbcl, for example, if you (declare (safety 0)), the compiler will just automatically trust your type declarations and generate machine code that is unsafe if this assumption isn’t true: it’s useful because sometimes “correct” behavior has an unacceptable performance cost.
Of course, I would still feel pretty nervous turning these on in a large multi-dev codebase unless some corresponding linter rules were also in place.
Except when you’re doing them by mistake, or because a dependency happened to be clever and you missed it.
See also: UB in every C and C++ code base.
Most of these are pretty hard to do by accident... I didn't even know about maybe a third of these things, and I've been writing JavaScript for 10 years
A significant exception to all of the generalizations I've been making is iterableIsArray:
> When using an iterable object (in array destructuring, for-of or spreads), assume that it is an array.
Violating this one is neither an anti-pattern nor hard to do by accident. It would mean a significant shift in practices for a project, and it would have to allow for some really exceptional optimizations if I were going to even consider enabling it