{ "archive_path": "archive/1791108236.37184", "base_url": "nolanlawson.com/2026/10/03/why-dont-more-developers-use-the-platform", "basename": "", "bookmarked_date": "2026-10-04 10:03", "canonical": { "archive_org_path": "https://web.archive.org/web/nolanlawson.com/2026/10/03/why-dont-more-developers-use-the-platform", "dom_path": "output.html", "favicon_path": "favicon.ico", "git_path": "git/", "google_favicon_path": "https://www.google.com/s2/favicons?domain=nolanlawson.com", "headers_path": "headers.json", "htmltotext_path": "htmltotext.txt", "index_path": "index.html", "media_path": "media/", "mercury_path": "mercury/content.html", "pdf_path": "output.pdf", "readability_path": "readability/content.html", "screenshot_path": "screenshot.png", "singlefile_path": "singlefile.html", "warc_path": "warc/", "wget_path": "nolanlawson.com/2026/10/03/why-dont-more-developers-use-the-platform/index.html" }, "domain": "nolanlawson.com", "extension": "", "hash": "14S7M3VGQTA7JVMMKK1T", "history": { "archive_org": [], "dom": [], "favicon": [ { "cmd": [ "curl", "--silent", "--location", "--compressed", "--max-time", "120", "--output", "favicon.ico", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36 ArchiveBox/0.7.4 (+https://github.com/ArchiveBox/ArchiveBox/) curl/curl 8.14.1 (x86_64-pc-linux-gnu)", "https://www.google.com/s2/favicons?domain=nolanlawson.com" ], "cmd_version": "curl 8.14.1 (x86_64-pc-linux-gnu)", "end_ts": "2026-10-04T10:04:48.175286+00:00", "index_texts": null, "output": "favicon.ico", "pwd": "/data/archive/1791108236.37184", "schema": "ArchiveResult", "start_ts": "2026-10-04T10:04:47.564542+00:00", "status": "succeeded" } ], "git": [], "headers": [ { "cmd": [ "curl", "--silent", "--location", "--compressed", "--head", "--max-time", "120", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36 ArchiveBox/0.7.4 (+https://github.com/ArchiveBox/ArchiveBox/) curl/curl 8.14.1 (x86_64-pc-linux-gnu)", "https://nolanlawson.com/2026/10/03/why-dont-more-developers-use-the-platform/" ], "cmd_version": "curl 8.14.1 (x86_64-pc-linux-gnu)", "end_ts": "2026-10-04T10:04:48.621017+00:00", "index_texts": null, "output": "headers.json", "pwd": "/data/archive/1791108236.37184", "schema": "ArchiveResult", "start_ts": "2026-10-04T10:04:48.183739+00:00", "status": "succeeded" } ], "htmltotext": [], "media": [], "mercury": [ { "cmd": [ "/app/node_modules/@postlight/parser/cli.js", "https://nolanlawson.com/2026/10/03/why-dont-more-developers-use-the-platform/" ], "cmd_version": "1.0.0", "end_ts": "2026-10-04T10:04:55.105109+00:00", "index_texts": null, "output": "mercury", "pwd": "/data/archive/1791108236.37184", "schema": "ArchiveResult", "start_ts": "2026-10-04T10:04:51.855311+00:00", "status": "succeeded" } ], "pdf": [], "readability": [ { "cmd": [ "/app/node_modules/readability-extractor/readability-extractor", "/tmp/tmpb_s0qtsj", "https://nolanlawson.com/2026/10/03/why-dont-more-developers-use-the-platform/" ], "cmd_version": "0.0.11", "end_ts": "2026-10-04T10:04:51.844997+00:00", "index_texts": [ "For years, advocates for web standards, performance, and accessibility have implored web developers to \u201cuse the platform\u201d. I\u2019ve often been one of those advocates.\nThe argument is simple: why build something yourself, in JavaScript, when the browser can do it for you? Whatever you build, it\u2019s likely to have poorer performance and worse usability than something the browser could just give you out-of-the-box.\nI think it\u2019s worth taking the other side, though, if for no other reason than to understand where the \u201cplatform-skeptic\u201d developers are coming from. If \u201cuse the platform\u201d is so obvious, then why do so many people seem to need convincing?\nThe most obvious reason is historical: for the longest time, browsers were playing catch-up with the ecosystem on top of them. Libraries like jQuery filled crucial gaps while browsers implemented equivalent APIs \u2013 and even then, you might have to wait for laggards like IE6 to age out before you could actually use them. Today, most browsers are evergreen (Safari is debatable, although ~7 times per year ain\u2019t bad), but up until the 2020s or so, web developers had to deal with a decidedly lumpy web. In that environment, rolling your own is a sensible choice.\nAnother reason is familiarity: when you\u2019re used to looking for React components on npm, that\u2019s what you tend to reach for, regardless of the problem at hand. If you search for \u201csticky positioning\u201d on npm, there\u2019s no package that says \u201cjust use CSS position: sticky, you dolt.\u201d\nAnd often, even with a robust standard, libraries on npm would fill a useful gap between framework ergonomics and the platform underneath it. I always found it intriguing that many React developers preferred to stick to JSX and React idioms \u2013 raw DOM APIs felt \u201cicky\u201d \u2013 but were perfectly happy to use lower-level libraries where raw DOM manipulations are common. For example, a virtual list library might happily use raw DOM APIs for pure performance, while exposing higher-level primitives that a novice React developer could better grasp. In a sense, the ecosystem of React components led to a natural division of labor where those with more expertise packaged up unfamiliar platform APIs in a more familiar form factor.\nSome of this effect was also driven by documentation. Many npm packages have lovingly detailed READMEs or websites with examples, tutorials, and screenshots. Whereas until MDN became cemented as the go-to place for web documentation (with web.dev as Google\u2019s more future-facing arm), documentation for the web platform was scattered across blogs, StackOverflow, and sites like CSS Tricks. And many of these sites would just tell you to use a well-known library like jQuery or GreenSock!\nThe Dragula site versus the Drag and Drop MDN page. Arguably the former is still more compelling.\nIf it were just about third-party libraries versus platform APIs, though, then I don\u2019t think it could fully explain the antipathy toward \u201cuse the platform.\u201d Developers who are lazy (or do I repeat myself?), and who just want a ready-made solution for whatever problem they\u2019re facing, are unlikely to care whether that solution comes from npm, the browser, or copied off of someone\u2019s random GitHub Gist. They want to solve their problem and move on. But there\u2019s a different source of anti-\u201cuse the platform\u201d that I want to explore.\nFor a certain type of developer, building things yourself is just more fun. And often the resulting code is easier to reason about, especially if you don\u2019t have an encyclopedic knowledge of the web platform. And once you\u2019ve built something, there can be a kind of IKEA effect where you want to maintain and tinker with your own homemade code.\nAs an example, let\u2019s imagine you\u2019re trying to build a modal dialog. You might visually understand how these are supposed to work: content appears on the screen, but the background is still visible although partially occluded, and maybe clicking outside the dialog dismisses it. So you might grab for position:absolute and z-index to position the dialog correctly \u2013 aha, but the background still scrolls, so you have to disable overflow on the body\u2026 And then if you understand something about accessibility, you realize you need to handle Esc to dismiss, and build a focus trap, and return focus to the element that launched the dialog, and\u2026\nFor many developers, what I just described sounds like a nightmare (and a good way to build something that only half-works). But for many developers, this sounds like fun! Think of how much you learn as you start building this thing. And think about how you could start putting your own spin on it by adding animations, themes, an optional \u201cclose\u201d button\u2026 Before you know it, you\u2019ve built a library that\u2019s ready to go on npm. That\u2019s way more fun than just grabbing and calling it a day \u2013 what a downer!\nAnd for many of us, before APIs like existed, this was how we learned the web platform! Many of the people who now advocate for \u201cuse the platform\u201d were once themselves authors of polyfills, shims, and libraries. I know because I\u2019m one myself! I spent years working on tooling for IndexedDB, WebSQL, and other browser storage APIs as part of my work on PouchDB, which eventually led to me feeling confident enough to sit in W3C standards meetings and even open issues and pull requests on the IndexedDB spec itself. Without the forcing function of a gap in the platform that needed to be filled, I don\u2019t know if I would have found the interest or motivation to get to that level of expertise.\nOf course, doing it yourself is not always an unalloyed good. Sometimes it just comes from pure ignorance. On the web platform in particular, I think one of the reasons there was such a proliferation of JavaScript solutions to problems that could be better solved by CSS, for example, is that many developers just didn\u2019t take the time to deeply understand how CSS works.\nAnd to be fair, CSS has historically been hard to understand! There\u2019s a reason the site is called \u201cCSS Tricks.\u201d Things like the clear fix, floats, and the min-width: 0 trick are hardly intuitive. Rather than trying to understand CSS\u2019s internal algorithm, it\u2019s often much easier to just imagine the imperative logic you want and then express it in JavaScript. Plus, for years CSS didn\u2019t have a straightforward way to express common patterns like line clamping, textarea resizing, scrollbar hiding, etc. So of course developers built it themselves using the tools they already understood.\nI don\u2019t even think this phenomenon of \u201cavoiding the platform\u201d is limited to the web. It can apply to any developer working on top of a platform they don\u2019t fully understand. For example, at my work, we use ClickHouse for storing various kinds of analytics data. At one point, my coworker and I disagreed about how to store large JSON data in a column: he built a system for compressing it before storage, whereas I put the data in a separate key-value store and only inserted the key into ClickHouse. It turned out we were both wrong! ClickHouse automatically compresses data, and as a columnar data store you actually get better compression across rows if you just let ClickHouse handle it. And the separate key-value store was just a poor man\u2019s version of what a columnar SELECT already does.\nI only realized these things after actually taking the time to thoroughly read the ClickHouse docs and then write a benchmark to prove my hypothesis. In the end I was shocked that we had built something that was slower and clunkier than what the platform itself could give us out-of-the-box. The parallels with JavaScript and the web platform were hard to ignore.\nI\u2019m sure that if you\u2019re a developer on iOS or Android, or someone building on top of a game engine, or really any kind of developer building on top of any platform layer, you probably have similar stories. There\u2019s a reason that the stereotype of the grizzled senior engineer is someone who can take a junior\u2019s baroque tangled mess of code and replace it with a single line. The more you learn, the more you\u2019re able to wield your knowledge of how the entire system works end-to-end to create the smallest possible contribution to it (and thus reduce your maintenance burden in the long run).\nI\u2019ve been trying really hard not to talk about AI this entire post (because I\u2019ve done it to death over the past year), but of course I can\u2019t help but wonder how AI coding will impact this phenomenon. I actually have both an optimistic and a pessimistic take:\n\nOptimistic: because LLMs have an encyclopedic knowledge of whatever platform you\u2019re working with, they can choose exactly the right platform API to deliver the experience the prompter asks for in vague English. And since this solution is likely faster and more correct than userland code, the agent will prefer it after rigorous testing and benchmarking. Furthermore, the \u201cIKEA effect\u201d goes away when developers are not actually writing the code themselves.\nPessimistic: because LLMs seem to love duplicating code \u2013 for example, ignoring helper functions that already exist in favor of writing their own for the umpteenth time \u2013 the amount of custom, non-platform-idiomatic code will skyrocket. Developers won\u2019t instruct their agents to test enough or to try enough alternatives, and will just commit the agent\u2019s first draft. And because it\u2019s always possible to add more epicycles, the agents will continue to iterate on over-engineered solutions that never should have existed in the first place.\n\nIn my own use of AI coding, I\u2019ve seen both phenomena happen. I\u2019d like to think that as models and coding harnesses get better we\u2019ll start to veer more towards the optimistic outcome, but I can\u2019t say for sure.\nIn any case, these are my longwinded and somewhat conflicting thoughts on \u201cuse the platform.\u201d As a mantra I love it, because it succinctly captures a feeling I have when I\u2019m looking at some overwrought pile of spaghetti code and thinking how much better and more elegant it would be if the author just understood the layers beneath them a bit better. At the same time, I\u2019ve been that author, and I\u2019ve felt the joy of building such beautiful, messy code (beautiful to me, anyway), so I think it\u2019s worth understanding where such developers are coming from. For that reason, I\u2019m sure we\u2019ll be hearing \u201cuse the platform\u201d for as long as there are platforms.\nYou can comment on the fediverse or Lobsters." ], "output": "readability", "pwd": "/data/archive/1791108236.37184", "schema": "ArchiveResult", "start_ts": "2026-10-04T10:04:50.214933+00:00", "status": "succeeded" } ], "screenshot": [], "singlefile": [], "title": [ { "cmd": [ "curl", "--silent", "--location", "--compressed", "--max-time", "120", "--user-agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36 ArchiveBox/0.7.4 (+https://github.com/ArchiveBox/ArchiveBox/) curl/curl 8.14.1 (x86_64-pc-linux-gnu)", "https://nolanlawson.com/2026/10/03/why-dont-more-developers-use-the-platform/" ], "cmd_version": "curl 8.14.1 (x86_64-pc-linux-gnu)", "end_ts": "2026-10-04T10:04:50.205158+00:00", "index_texts": null, "output": "Why don\u2019t more developers \u201cuse the platform\u201d? | Read the Tea Leaves", "pwd": "/data/archive/1791108236.37184", "schema": "ArchiveResult", "start_ts": "2026-10-04T10:04:50.188873+00:00", "status": "succeeded" } ], "wget": [ { "cmd": [ "wget", "--no-verbose", "--adjust-extension", "--convert-links", "--force-directories", "--span-hosts", "--no-parent", "-e", "robots=off", "--reject=js,mjs,woff,woff2,ttf,otf,eot,mp4,m4v,mov,webm,ogv,mkv,avi,flv", "--timeout=120", "--restrict-file-names=windows", "--page-requisites", "--user-agent=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36 ArchiveBox/0.7.4 (+https://github.com/ArchiveBox/ArchiveBox/) wget/GNU Wget 1.21.3", "--compression=auto", "--timestamping", "https://nolanlawson.com/2026/10/03/why-dont-more-developers-use-the-platform/" ], "cmd_version": "GNU Wget 1.21.3", "end_ts": "2026-10-04T10:04:50.180219+00:00", "index_texts": null, "output": "nolanlawson.com/2026/10/03/why-dont-more-developers-use-the-platform/index.html", "pwd": "/data/archive/1791108236.37184", "schema": "ArchiveResult", "start_ts": "2026-10-04T10:04:48.630389+00:00", "status": "succeeded" } ] }, "icons": null, "is_archived": true, "is_static": false, "latest": { "archive_org": null, "dom": null, "favicon": "favicon.ico", "git": null, "media": null, "pdf": null, "screenshot": null, "singlefile": null, "title": "Why don\u2019t more developers \u201cuse the platform\u201d? | Read the Tea Leaves", "warc": null, "wget": "nolanlawson.com/2026/10/03/why-dont-more-developers-use-the-platform/index.html" }, "link_dir": "/data/archive/1791108236.37184", "newest_archive_date": "2026-10-04T10:04:51.855311+00:00", "num_failures": 0, "num_outputs": 6, "oldest_archive_date": "2026-10-04T10:04:47.564542+00:00", "path": "/2026/10/03/why-dont-more-developers-use-the-platform/", "schema": "Link", "scheme": "https", "snapshot_id": "c127af32-0316-4e39-aeee-33837daa4344", "sources": [ "/data/sources/1791108236-import.txt" ], "tags": null, "tags_str": "", "timestamp": "1791108236.37184", "title": "Why don\u2019t more developers \u201cuse the platform\u201d? | Read the Tea Leaves", "updated": "2026-10-04T10:04:47.564079+00:00", "updated_date": "2026-10-04 10:04", "url": "https://nolanlawson.com/2026/10/03/why-dont-more-developers-use-the-platform/" }