Simon Willison on no-build wedev:
\n\n\nIf you've found web development frustrating over the past 5-10 years, here's something that has worked worked great for me: give yourself permission to avoid any form of frontend build system (so no npm / React / TypeScript / JSX / Babel / Vite / Tailwind etc) and code in HTML and JavaScript like it's 2009.
\n
This blog has a \"backend\" build process to produce the static HTML. But, the frontend is pretty much build-free.
\nWeb development with \"vanilla\" JavaScript has gotten pretty good in the last decade, thanks to Modules, dynamic import(), Custom Elements, and a pile of other relatively recent APIs.
The easy path at work these days tends to be Next.js, but I kind of hate it. All my side projects start with touch index.{html,js,css}. I roll on from there with maybe a live-reload HTTP server pointed at the directory (e.g. npx reload src).
That said, I have started playing with carefully re-introducing some build tooling for a few side projects - but, only for external dependencies. I've tinkered a bit with using esbuild to compose bundles as JS modules importable by the rest of my unbundled modules.
\nThe nice thing about this is that I can treat those external dependencies as standalone utility modules without infecting the rest of my project with build machinery. I can even just check in a copy of the built asset to keep the project stable and usable, years later.
\n", "body": "\nSimon Willison on [no-build wedev](https://simonwillison.net/2025/May/31/no-build/):\n\n> If you've found web development frustrating over the past 5-10 years, here's something that has worked worked great for me: give yourself permission to avoid any form of frontend build system (so no npm / React / TypeScript / JSX / Babel / Vite / Tailwind etc) and code in HTML and JavaScript like it's 2009.\n\nThis blog has a [\"backend\" build process](https://github.com/lmorchard/blog.lmorchard.com/blob/main/index.js) to produce the static HTML. But, [the frontend](https://github.com/lmorchard/blog.lmorchard.com/blob/main/content/public/index.js) is pretty much build-free. \n\nWeb development with \"vanilla\" JavaScript has gotten pretty good in the last decade, thanks to [Modules](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules), [dynamic `import()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import), [Custom Elements](https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_custom_elements), and a pile of other relatively recent APIs. \n\nThe easy path at work these days tends to be Next.js, but I kind of hate it. All my side projects start with `touch index.{html,js,css}`. I roll on from there with maybe a live-reload HTTP server pointed at the directory (e.g. `npx reload src`).\n\nThat said, I have started playing with carefully re-introducing *some* build tooling for [a few side projects](https://blog.lmorchard.com/2025/04/25/sketches-as-web-components/index.html) - but, only for external dependencies. I've tinkered a bit with [using esbuild to compose bundles as JS modules](https://github.com/lmorchard/sketches-v03/blob/main/build.js) importable by the rest of my unbundled modules. \n\nThe nice thing about this is that I can treat those external dependencies as standalone utility modules without infecting the rest of my project with build machinery. I can even just check in a copy of the built asset to keep the project stable and usable, years later.", "parentPath": "./content/posts/2025", "path": "2025/05/31/no-build-webdev", "needsBuild": true, "prevPostPath": "2025/05/29/miscellanea", "prevPostTitle": "Miscellanea for 2025-05-29", "nextPostPath": "2025/05/31/miscellanea", "nextPostTitle": "Miscellanea for 2025-05-31" }