i'll qualify that i've mostly worked with smaller teams (up to a dozen-ish people) but anecdotally i just have not seen many serious production bugs that an eslint rule would've prevented

the configuration is my real issue. it's never just eslint, it always seems to need like eight other dependencies alongside it

i think my hottest javascript take is that eslint is not worth its weight as a dependency

i also don't think an app developer building a new tool to solve a problem is any more innovation than an end user who can't program cobbling together a solution from multiple existing tools that all support the same ubiquitous formats

the counterpoint is: ubiquitous formats increase innovation by enabling developers to build atop an ecosystem of existing tools rather than recreating everything from scratch.

consider how much easier it'd be to make a new javascript framework using jsx than a bespoke template syntax, for instance.

"o mario, mario, wherefore art thou mario?"

"skill issue" is a sociopathic way to describe someone falling onto the train tracks

i even think you're understating it. like, how many of these people who are outraged to hear about ICE killing a *dog* care at all when cops kill black *people*?

cosigned. the only time i ever use it is if a library makes me

not using it. in order of preference:

1. if i know the popover trigger position (like flush right in a centered main nav bar with max-width) then calc()

2. if it's non-essential (like turning footnotes into sidenotes on my blog) then @supports

3. if i can assume JS is available then floating-ui

yeah i wouldn't say that a database is *never* the answer. imo it's descriptive: a file is useful to the extent that you can do things with it, and "database" tends to describe a kind of file that end users can't do anything with (if they can access it at all). but that's not like a law of physics!

i really like the way @chrisshank.com put it here

nah i think DBs in any form (including my beloved CRDTs) are almost always a "least worst" option for end user software.

if i have a plain text file i can read it, i can edit it, i can open it in ~any program. the barrier to doing anything useful with a sqlite db or an automerge doc is way higher.

thank you! i'm glad, it was your idea in the first place 😄

i don't really think it's a "rule", it's just an explanation for why the function behaves this way.

imo the much bigger gotcha would be for .every to return false when called on an empty array. how would you explain that design decision?