I’ve found Bridgetown rb.
I’m wondering, while i’ve seen some of us moving to golang 's Hugo, why don’t staying ruby ?
(Of course, this pushes me out of my confort zone… )
By chance, did someone tested it ? How does it compare to Jekyll ?
cheers
2 Likes
I’m wondering, while i’ve seen some of us moving to golang 's Hugo, why don’t staying ruby ?
It’s slow
Hmm haven’t heard of that before.
From skimming the site, Bridgetown looks modern and integrates well with frontend frameworks like React and Vue. And you need Node and Yarn to run it. I’m interested to try it out to see how it works. It might overcome speed and web app challenges that Jekyll wasn’t built for.
It may have a learning curve that makes it tough for beginners. You have to be comfortable working with both Ruby and Node to some extent, to set up and run/debug a site. While Jekyll is a plain Ruby approach, with some people adding Node to their projects if they need to.
If you want Vue-based static site, there is Nuxt and VuePress. If you want React-based, there is Next and Gatsby. I guess Bridgetown leads a new path where it doesn’t make that choice for you, yet it makes it easy for you either React or Vue or whatever.
And if you don’t want Vue or React in your site, and only have a few assets, then Bridgetown may not be a good fit. It’s main benefit seems like it had a flow bundles frontend assets with Webpack, which is not something that I need in my current sites.
1 Like
Regarding why choose one tool over another.
There are a ton of static site generators out there. Check on Jamstack website and related topics linked here.
Or you can find some articles comparing what these tools are good for, with some googling. Maybe some older forum topics here too on why use Jekyll etc.
Sometimes a tool is for when speed matters (Hugo claims to be the fastest). Sometimes it’s the ecosystem (theming, Python,Go/Ruby plugins that you write yourself). Sometimes its about installation (Hugo comes as a single binary to download). Sometimes its simplicity (on GH Pages you don’t need to configure a build step or manage dependencies - Jekyll runs for you already with a gem environment, which comes with limitations too).
For fun, I experimented with setting up the quickstart site and making a repo of it.
I wrote the steps I followed to create a new project - using the CLI and without having to install Bridgetown globally.
Resources
2 Likes
Hi all. We just published our latest take on the matter here:
TL;DR: Jekyll is no longer under active development (aka primarily occasional bugfixes and docs PR merges only). If you’re looking for a platform with a bright and rapidly progressing future, Bridgetown is it. 
AMA! (We also have a rockin’ Discord chat.)
1 Like
You mean that if I do not want to use any framework Bridgetown is just a useless complication?
I hoped for Bridgetown to have a KISS approach, while preserving the great extensibility for users, which makes Jekyll so great.
I wasn’t commenting using a framework but rather that Bridgetown is “webpack aware” so it’s strength is processing JS (whether your own or using a 3rd party package), as well as other webpack stuff like bundling CSS.
If you do want to use JS and you are already familiar with both Ruby and also Node, then Bridgetown can suit someone’s need well. But those are strong assumptions.
If your site needs no JS at all (most of my static sites don’t and are really fine being just static), then the fit feels bad and the overhead is too high to add webpack and Node to what is boils down to a Gem and Markdown/HTML site.
Yes Bridgetown will also use Webpack to handle CSS, but you can get gems to do that too like Jekyll does.
I only made one Bridgetown site and it was using a template, so my experience is deep enough to comment on all strengths and limitations of Bridgetown. What would be in Bridgetown’s favor is if there was a way to skip adding the .js files to the root and the webpack and package.json configs and to run the entire site with Ruby alone and no Node. I don’t know if it can do that.
Or maybe there will be a future version of Bridgetown which obscures then boilerplate code internally in the package, so your own project can have fewer files to maintain and one can rely on built-in defaults (going with the convention over configuration philosophy)