Libraries over browser features

Insightful post from Jeremy Keith today, about how many web developers seem over-keen to pull in dependencies without much critical thought—especially when those dependencies don't offer anything above & beyond what features are already natively supported by the web platform (that is, the browser).

I think this perspective of trust has been hammered into developers over the past maybe like 5 years of JavaScript development based almost exclusively on inequality of browser feature support. Things are looking good in 2022; but as recently as 2019, 4 of the 5 top web developer needs had to do with browser compatibility.

Browser compatibility is one of the underlying promises that libraries—especially the big ones that Jeremy references, like React and Bootstrap—make to developers. When I decide to rely on a JS framework or a utility library, I know that it's going to give me headaches when I come back to the project in 6 months. I know that every dependency incurs technical debt. But I do it because I'm on a budget and I can't spend my time reading through the caniuse.com page for Array.prototype.includes or MutationObserver. Lodash promises cross-platform compatibility right there at the bottom its homepage.

This approach isn't a sustainable practice, and I'm trying to do as little of it as I can. Jeremy is right to be suspicious of third-party code. Cross-browser compatibility has gotten a lot better, and campaigns like Interop 2022 are doing a lot to reduce the burden. It's getting better, but the exasperated I-just-want-it-to-work mindset is tough to uninstall.

Code Web

Next

Linear

Linear is a beautiful app with a thoughtfully designed and powerful interface that I just can't find a use for.

Previous

GraphQL & HTTP responses

GraphQL introduces a new layer on the client → database stack that makes HTTP status codes sorta irrelevant, and I'm not sure how I feel about that.