Why don't more developers “use the platform”?

For years, “use the platform” has been the standard plea from people who care about web performance, standards, and accessibility. The pitch is simple: if the browser can do it, why re-create it in JavaScript and end up with slower, clunkier code? But the answer is messier than the slogan suggests.

A lot of the hesitation is historical. Browsers spent years lagging behind the libraries and frameworks built on top of them, and tools like jQuery existed because important APIs simply weren’t there yet. Even when support arrived, developers often had to wait for old holdouts like IE6 to disappear before they could rely on the new stuff. The web is more evergreen now — Safari is called out as “debatable,” though it updates about seven times a year — but until the 2020s, the platform was uneven enough that rolling your own was often the sensible move.

Then there’s habit. If someone spends all day searching npm for React components, that’s where the reflex goes. The ecosystem also did a lot to blur the line between platform and library: packages frequently wrapped lower-level browser APIs in friendlier forms, with better documentation, examples, and screenshots than the platform itself often had. MDN is now the default reference, with web.dev as a more forward-looking companion, but before that, web knowledge was scattered across blogs, StackOverflow, and sites like CSS Tricks. Sometimes the library page was simply more inviting than the browser docs.

And sometimes developers just enjoy building the thing. The article’s modal-dialog example captures the lure nicely: once you start down that road, you’re into scroll locking, Esc handling, focus traps, returning focus, animations, and themes. That sounds like a maintenance headache to one engineer and a satisfying puzzle to another. The same instinct helped many people learn the platform in the first place, including the author, who spent years working on tooling for IndexedDB, WebSQL, and other storage APIs through PouchDB before getting involved in standards work on IndexedDB itself.

Not all of this is noble curiosity. Some of it is just not understanding the platform well enough. JavaScript often becomes the default hammer when CSS or a browser API would have been the cleaner answer, especially for developers who never dug into the details. The author points to ClickHouse as a non-web example: a disagreement over JSON storage turned out to be wrong on both sides once the docs were read and a benchmark was run. The platform already compressed the data, and the supposed workaround was just a worse version of what the database could do on its own.

AI coding adds a fresh wrinkle. In the optimistic version, models know enough about the platform to pick the right API and avoid unnecessary custom code. In the pessimistic one, they happily generate more duplicated, non-idiomatic glue and make the over-engineering worse. Either way, the old argument isn’t going away. As long as platforms exist, some developers will keep bypassing them, and some others will keep trying to talk them back.