Any path for using bridgetown without Webpacker & NodeJS? #436
-
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! |
Beta Was this translation helpful? Give feedback.
Replies: 6 comments 1 reply
-
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 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. |
Beta Was this translation helpful? Give feedback.
-
I guess Webpacker is my primary concern. I would love to never have to learn it. Thanks again! |
Beta Was this translation helpful? Give feedback.
-
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). |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
@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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
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 yourindex.js
and maybeindex.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 esbuil…