Going Buildless

If you are going to use a build tool and you decide to create a new one written in JS, then please write it in standard JS (i.e. what Web browsers implement; nothing to do with standardjs.com) that calls standardized APIs (again, all browsers—the things that everyone already has installed—implement them). Please don't code directly against e.g. proprietary Node APIs.

If you have a stupid simple HTML+CSS+JS project that nevertheless uses a build tool for some reason, a contributor should be able to clone the repo, open the README, read the instructions on how to build it and not encounter "first, install bun" (or whatever); in 90+% of cases, those instructions don't actually need be anything more complicated than "First, open the build script in a browser tab. Now drag and drop the project folder onto the build tool." You can double up and make that build script your README if you want—call it README.html.

It's baffling the numbers of folks who decided to focus on JS development because they wanted to draw on their familiarity/desire for developing for the browser and out of recognition that being able to create browser-based apps and deploy to users without making them install anything is a huge boon... and then went on to make a bunch of shoddy tooling that despite itself being nominally written in JS still requires you to download a bunch of other stuff to run it and doesn't leverage the standard JS runtime that everyone _already_ has installed.

This guy unironically wrote an entire article about how to "get simplicity back" and avoid using server-side processing by doing a bunch of crazy convoluted JavaScript crap which runs on "the edge" (i.e. a server).

You can't make this up.

Most of my web projects these days are vanilla. I'd been dabbling on simple things for years, but it took a big leap a few months ago when I discovered Web Components are still a thing and have come a long way since 2012. We're finishing up re-writing an app at work that went from a ~17 dependency Vue app to a ~2 dependency (d3js) Web Component app. The codebase is a joy to work on. No more dependency hell. We don't even need npm. The code, as committed to git, will probably still run unmodified on browsers in 20 years. It's a great feeling.

A few tips:

* If you have a lot of JS files and want excellent performance you may still be able to skip a build step by leveraging `modulepreload`

* If you want some typing while still running without a build step, you can use JSDoc to embed TypeScript annotations for your JS[0].

* If you really want to have a mostly HTML site but don't want to manually duplicate code, I've had decent success with a technique I call "tuplates"[1][2]. Basically it's a very simple templating tool where the output is intended to be committed to git. It uses comments so it's language agnostic.

* If you go web components I highly recommend these best practices[3]. A lot of them were confusing for me at first but just keep them on your radar as you're learning.

[0]: https://www.typescriptlang.org/docs/handbook/jsdoc-supported...

[1]: Description: https://github.com/anderspitman/tuplates-js/blob/master/READ...

[2]: Latest implementation: https://github.com/anderspitman/tuplates

[3]: https://web.dev/articles/custom-elements-best-practices

I'm currently working on a dashboard-type SPA, with no build tools. Just a single file of HTML, a single file of CSS, a bunch of plain JS files with an import map, and a single dependency on d3 (also imported as a module). In total about 10Kloc.

I have to say, it's been a few years since I last did front-end dev work, and I was really pleasantly surprised by how much better CSS and Javascript became. All in all, it's been a really positive experience.

>The obvious tradeoff for a buildless workflow is performance. We use bundlers mostly to concatenate files for fewer network requests

generally small parallel requests perform better than large single requests in a modern situation - modern browsers, HTTP 2+ etc. - in my experience - but there can be a lot of caveats about that statement.

However the import statements in the css are not downloaded in parallel last time I checked - and probably never would be because of ways css works, so this using import statements inside css instead of having a build of a single css is actually the worst possible solution I think (ok there is probably something even worse that you could build if you really wanted to but worst "reasonable" solution)

I begrudging tried tailwind css recently. I was shocked to find that when using a CSS framework where you embed all of our styling in HTML, I STILL needed a css build process to do trivial things like customize the default link color.

Except for CSS via Sass I have not used a build process in all these years.

And recently I rewrote our CSS to use modern syntax and nesting and variables and etc. - no more Sass!

It worked great but then customers started to complain and send messed up screenshots.

Turns out a lot of Android phones are using an older browser and a couple of customers were locked into old versions of Chrome by corporate policy.

Fortunately this was all nesting rules. So renaming the css file to scss and running it though Sass fixed the issues.

Hey wouldn't it be nice to go back to simpler times?

adds more complexity

I am going build less for a recent project. The main difference for me is jsdoc vs typescript. There was a large initial learning curve, and the syntax is ugly, and having to duplicate all my TS types from the backend as JS doc types on the front end sucks, but at the end of the day it does work.

I was surprised how well module imports work in modern browsers.

I've never used css preprocessors before, so that wasn't an issue for me. I also have never nested CSS files, so that also wasn't an issue for me.

Another pain point is not having type safety on my front end calls to my backend. With TS I could use Zod on the front end as well and have type checks in place before I make those API calls. While obviously js doc tries to ensure at compile time that things are the correct shape, that isn't the same level of assurance.

Esbuild in serve mode is a very good emulation of "buildless". Sad that its model, vs the usual fiddly file watching, isn't used more.

I'll always start vanilla / build-less with best intentions. In fact, I often start sans JS too if I can get away with it.

But inevitably the complexity of my projects increase. My patience with focus, refresh, review cycle crashes. My first stop is usually vite, just for hot reload at first, but then for raw imports, and I do like nested CSS. When I find myself beginning to roll my own reactivity I tend to read up on the latest state of vue and svelte and drop whichever one feels right into the mix. It goes on.

All with the best intentions.

What is a build for? The article does not really articulate it.

* Dependency management (use libs so you dont have to write/maintain that code yourself) * Code generation (we use that for added typesafety: jOOQ the SQL eDSL, and OpenAPI3 for generated clients + server-side DTOs) * Compilation (compile higher-level languages with strong type-safety guarantees, e.g. Kotlin, Elm, Haskell, Rust, TypeScript; to lower-level or dyn-typed/quirky languages, e.g. JS, WASM, byte-code, binaries)

Three pretty important advantages!

Sure builds come with added complexity, so it is a trade off. But when carefully picking technologies this can greatly pay back the cost of complexity.

Now, if you compile, say, JS to JS (less to CSS) with brittle build tools such as npm (shell commands in a string in a JSON called packages.json), and low quality dependencies, then the advantage your build step probably negative.

Why do we avoid build tools again? Webdevs comes up with the most arbitrary goals, I swear to God.

Do you not run a script to deploy your software in whatever way? If you do then what's the difference if the script builds some things as well and not just uploading?

Articles like this remind me how little the browser environment has moved on in recent times. Now all the work is done by the frameworks.

You logged on via telnet, not ftp. And you tested with "telnet webserver 80".

I sshed into my personal site vps this morning, created a file with vim, pasted in the html and added some styles by copying them from a php file in the same directory.

All on the server!

Do I get nerd creds now? <3