bridgetownrb / bridgetown

A next-generation progressive site generator & fullstack framework, powered by Ruby
https://www.bridgetownrb.com
MIT License
1.16k stars 113 forks source link

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

Open jaredcwhite opened 1 year ago

jaredcwhite commented 1 year ago

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:

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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.