| OP Here. This got more engagement than expected, some of the bits I've picked up in discussion: "Recommends skipping build step then mentions Tailwind": We use static-tailwind, a version with no build step, in development. "Recommends hyperscript, a new non-js syntax" - Agree this isn't perfect & would prefer something which uses js. Was going to use Alpine but also have found that to be quite brittle in production. Nor do I love any of the libraries on unsuckjs.com, which has a good collection. We're working on something here which we'll launch at some point. "OP should look at the recent Rails updates" - Been using Rails for 10+ years - everything we build is on top of Rails - I'll write a post on HTML First Rails at some point. I think they'll get there but currently all the named libraries (Turbo, Hotwire, Strada, Stimulus etc) are 1. Rails specific, and 2. Have a high learning curve. One of the points of HTML First is to avoid framework lock-in. "This is a blog spam post written by an author that has no credibility in the space": Brutal |
https://github.com/tonyennis145/dumb-tailwind/
Is it this? (A 3.9 MB CSS file?)
My personal gripe with build steps is not the build step itself, rather the unreliability of the JavaScript ecosystem and the often head-scratchingly opaque error messages.
Build steps such as a hypothetical `css-compile` don't address limitations of browsers, but limitations of network connections that may struggle to download (and frankly, at 3.9 MB, devices that struggle to parse) large amounts of CSS and JavaScript.
Even if browsers can download multiple files at once, they can't download files they don't know about, which is why ES modules in the browser haven't taken off as a way to eliminate the build step.