feat: "Buildless" option, import maps, timestamped asset URLs

[jaredcwhite]

With modern ESM becoming ubiquitous and services like esm.sh providing literally "esbuild in the cloud" (or you can self-host which is pretty freaking great),

with vanilla CSS becoming a true powerhouse (even nesting is finally within our grasp!),

with declarative Shadow DOM providing a straightforward, server-driven, browser-native way of building scoped UI components,

and with polyfill-free import maps soon to have landed in all browsers (yes, including Safari!)…

…I think it's time to jump on the "buildless frontend" train. Seriously.

Not that any of our existing esbuild pipeline is going anywhere (heck, we're still supporting Webpack!), but I think we should make this a true option. This means at least four things:

• A configuration / site template option for a buildless frontend. This could also mean making Node completely optional…aka going back to a 100% pure Ruby project just like the old days.
• A way to manage import maps with a nice DSL. Not saying we should blindly copy Rails 7's "pin" nomenclature, but we can at least evaluate their approach and see what makes sense (or doesn't).
• Ability to timestamp the asset URLs so new site builds will load update JS/CSS entry points. I'm not sure if that carries over to their imports though…may have to play with this a bit.
• Relevant documentation around how to interface with a CDN like esm.sh or setting up your own self-hosted version.

Probably would be a good idea to come up with somewhat of a working "demo" project (maybe even take an existing site out in the wild) and go buildless to see what's needed to get everything running smoothly.

Questions / comments / suggestions most welcome!

[mkasberg]

I'd love to see this happen. Might even be interested in contributing a few small PRs to help with the effort! In particular, I like "making Node completely optional". I have a few sites that I still run on Jekyll without Node and wouldn't want to switch to Bridgetown if doing so forced me to pull Node in.

[KonnorRogers]

Ability to timestamp the asset URLs so new site builds will load update JS/CSS entry points. I'm not sure if that carries over to their imports though…may have to play with this a bit

just my 2 cents, but timestamps shouldn’t be the default behavior. Read the file and attach either a SHA or MD5 based on the file contents that way you don’t churn on every build.

As for JS dependencies, whatever approach it’d be a good idea to grab pinned URLs for versions so that you don’t even need to bother with attaching hashes.

Example:

when you got to cdn.skypack.dev you can find “optimized” or “pinned” URLs.

https://cdn.skypack.dev/lit

yes….I’ve thought way too much about this….

[jaredcwhite]

@KonnorRogers good point, a hash would be better, although I still haven't worked out how possible dependency imports (in repo) would work. I suppose that's why import maps come in handy, they can translate bare idents to hashed paths.

Pinned versions for third-party deps, yep.

[sandstrom]

Small thought on this piece:

Ability to timestamp the asset URLs so new site builds will load update JS/CSS entry points. I'm not sure if that carries over to their imports though…may have to play with this a bit.

I'd say generally you want to add hashes to "assets referenced in assets", for example a CSS file with background-image: url("/images/my-bg.svg");. If you don't you cannot use the (common) practice of using 1+ year expiry and use hash as a part of the filename for cache invalidation.

That said, it would likely make sense to rely on existing tooling for this, e.g. LightningCSS, postCSS or some other existing project in the CSS/JS ecosystem.

So I'm still positive to what's proposed here. Just wanted to mention this thing regarding images and fonts referenced in CSS files.