There’s one use case where == is still commonly used: == null matches both null and undefined. Lint rules that block == usually allows the null case as an exception.
But if every single comparison used in a file is a triple =, then any compression algo worth its weight in salt will compress that bloat away during transmission
The real issue is all the precious precious RAM those extra = use on the client device once received and unpacked!
Gzip is old-school. The majority of modern sites use Brotli now. It’s slower to compress, but that’s not normally an issue for static resources (CSS, JS, etc) because they can be pre-compressed during the build and the web server serves the pre-compressed files instead of dynamically compressing them.
The recommended ESLint rules catch most of the bad stuff, and these days this is all you need in your ESLint config to enable them:
import {defineConfig} from 'eslint/config'; import js from '@eslint/js' export default defineConfig([ js.configs.recommended, ];There’s one use case where
==is still commonly used:== nullmatches bothnullandundefined. Lint rules that block==usually allows thenullcase as an exception.So you’re saying the jank has become structural?
I wonder how much bandwidth is wasted on the extra
=, since it survives minification 😅But if every single comparison used in a file is a triple =, then any compression algo worth its weight in salt will compress that bloat away during transmission
The real issue is all the precious precious RAM those extra = use on the client device once received and unpacked!
Gzip (any properly configured static server will serve compressed assets) probably compresses them down so probably a single extra byte per file
Gzip is old-school. The majority of modern sites use Brotli now. It’s slower to compress, but that’s not normally an issue for static resources (CSS, JS, etc) because they can be pre-compressed during the build and the web server serves the pre-compressed files instead of dynamically compressing them.