Any path for using bridgetown without Webpacker & NodeJS?

[delonnewman]

Part of the attraction, for me, of using tools like Jekyll & Bridgetown is to avoid to the fullest extend possible the complexity that is all too common in the JS ecosystem these days (at least for my simple brain). Is there any path or suggestions for making use of Bridgetown without Webpacker & NodeJS?

I'd be open to solutions like writing plugins or making contributions to the core project. Thank you!

[jaredcwhite]

I understand where you're coming from, believe me!

I don't think there's all that much complexity unless you try to push things in wild directions. To be honest, not having a frontend build step actually introduces complexity. How do you add Shoelace? Lit? Ruby2JS? Bulma? A search component? A carousel?

Bridgetown's goal is for 80% of use cases 80% of the time, you just type a yarn add command, stick an import in your index.js and maybe index.css, and that's it. You can go from zero to frontend hero in minutes. Would it be any easier with import maps and CDNs and no local Node install? Maybe at first, but then you quickly fall off a cliff.

We're definitely looking into implementing esbuild as a faster alternative to Webpack with a simpler config. But it'll still require Node, and I just don't see that changing any time soon. Believe me, I'll be the first to jump on a better, widely-supported JS CLI alternative to Node if/when it's on the market.

[delonnewman]

I guess Webpacker is my primary concern. I would love to never have to learn it. Thanks again!

[jaredcwhite]

Yeah, I think a lot of mistakes were made with how Webpacker set up the interface between Rails and Webpack. Bridgetown ships with a decent default Webpack config and it's actually inherited by the file you have in your main project area, so it's pretty trivial to make slight adjustments if and when it's necessary. And we always manage the Webpack process under-the-hood so you never have to figure out how to run it yourself simultaneously.

[delonnewman]

You make a good point regarding the NPM ecosystem. One approach for that I've been considering is packaging it in a gem the way Julia does, that way you can at least have one build process (https://www.juliapackages.com/p/nodejs).

[timburgan]

Is there any more thought on this? 🙏

With Rails, I'm happily avoiding webpacker and esbuild by using tailwindcss-rails, turbo-rails, stimulus-rails and importmap-rails gems

[jaredcwhite]

@timburgan Always on the look out for options regarding this stuff. I personally wouldn't choose to the use that stack. In particular I actively dislike Tailwind. Many other projects I do like are an order of magnitude easier to use with esbuild. We've seen huge gains in stability and performance using esbuild, so I'm in no rush to remove it. But we're getting closer to feeling comfortable introducing an option to start a new project without a frontend Node-based bundler. I would want to make sure that onboarding process doesn't steer folks in the wrong direction though. For example, import maps only just became natively supported in all browsers, and I consider the Rails-recommend polyfill unacceptable. Once we feel comfortable recommending native import maps, and we're able to offer folks docs recommending NPM package hosts such as ESM.sh which offer locally-installable binaries (should folks wish it…again, I personally would not ship a production app reliant on third-party JS CDNs), it'll make this path easier.

[asecondwill]

im avoiding node on rails too, its been dreamy. agree with @jaredcwhite ref tailwind so i'm running dartsass and importmaps.

Just tried to deploy my first bridgetown project to render and of course yarn is blowing up.