# 'Hello «Bridgetown» rb' ( fork )?

**URL:** <https://talk.jekyllrb.com/t/hello-bridgetown-rb-fork/5980>\
**Category:** Share\
**Created:** [May 3, 2021, 7:39am UTC](https://talk.jekyllrb.com/t/hello-bridgetown-rb-fork/5980 "2021-05-03T07:39:10Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![jordila](https://yyz2.discourse-cdn.com/flex030/user_avatar/talk.jekyllrb.com/jordila/32/3488_2.png) [@jordila](https://talk.jekyllrb.com/u/jordila)\
**Post date:** [May 3, 2021, 7:39am UTC](https://talk.jekyllrb.com/t/hello-bridgetown-rb-fork/5980/1 "2021-05-03T07:39:11Z")

</div>

![bridgetown-ruby](https://canada1.discourse-cdn.com/flex030/uploads/jekyllrb/original/2X/1/194febc8cf3388189a9197138a7685bb7362d869.png)

I’ve found [Bridgetown rb](https://www.bridgetownrb.com).  
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

---

<div class="post-metadata">

**Author:** ![jordila](https://yyz2.discourse-cdn.com/flex030/user_avatar/talk.jekyllrb.com/jordila/32/3488_2.png) [@jordila](https://talk.jekyllrb.com/u/jordila)\
**Post date:** [May 3, 2021, 7:59am UTC](https://talk.jekyllrb.com/t/hello-bridgetown-rb-fork/5980/2 "2021-05-03T07:59:34Z")

</div>

> [@jordila](#):
>
> I’ve found [Bridgetown rb](https://www.bridgetown.com).  
> I’m wondering, while i’ve seen some of us moving to golang 's Hugo, why don’t staying _ruby_ ?

well, testing …

 ![image](https://canada1.discourse-cdn.com/flex030/uploads/jekyllrb/original/2X/5/52b940d5322f78a3c630c5ccf0a08b06d71367d2.png)

 ![image](https://canada1.discourse-cdn.com/flex030/uploads/jekyllrb/original/2X/2/23d2fb7bb6b017691eb98353e0c3a2fed2c149d2.png)

Let’s give Bridgestown a chance in our toolbox … ?

---

<div class="post-metadata">

**Author:** ![victorb](https://yyz2.discourse-cdn.com/flex030/user_avatar/talk.jekyllrb.com/victorb/32/5112_2.png) [@victorb](https://talk.jekyllrb.com/u/victorb)\
**Post date:** [May 6, 2021, 6:22pm UTC](https://talk.jekyllrb.com/t/hello-bridgetown-rb-fork/5980/3 "2021-05-06T18:22:42Z")

</div>

> I’m wondering, while i’ve seen some of us moving to golang 's Hugo, why don’t staying _ruby_ ?

It’s slow

---

<div class="post-metadata">

**Author:** ![MichaelCurrin](https://yyz2.discourse-cdn.com/flex030/user_avatar/talk.jekyllrb.com/michaelcurrin/32/2340_2.png) [@MichaelCurrin](https://talk.jekyllrb.com/u/MichaelCurrin)\
**Post date:** [May 7, 2021, 8:45pm UTC](https://talk.jekyllrb.com/t/hello-bridgetown-rb-fork/5980/4 "2021-05-07T20:45:33Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![MichaelCurrin](https://yyz2.discourse-cdn.com/flex030/user_avatar/talk.jekyllrb.com/michaelcurrin/32/2340_2.png) [@MichaelCurrin](https://talk.jekyllrb.com/u/MichaelCurrin)\
**Post date:** [May 7, 2021, 8:49pm UTC](https://talk.jekyllrb.com/t/hello-bridgetown-rb-fork/5980/5 "2021-05-07T20:49:50Z")

</div>

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](https://michaelcurrin.github.io/coding-blog/2019/09/04/site-building-tools.html).

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).

---

<div class="post-metadata">

**Author:** ![MichaelCurrin](https://yyz2.discourse-cdn.com/flex030/user_avatar/talk.jekyllrb.com/michaelcurrin/32/2340_2.png) [@MichaelCurrin](https://talk.jekyllrb.com/u/MichaelCurrin)\
**Post date:** [May 9, 2021, 2:45pm UTC](https://talk.jekyllrb.com/t/hello-bridgetown-rb-fork/5980/6 "2021-05-09T14:45:50Z")

</div>

For fun, I experimented with setting up the quickstart site and making a repo of it.

> **[MichaelCurrin/bridgetown-quickstart](https://github.com/MichaelCurrin/bridgetown-quickstart)**
>
> Contribute to MichaelCurrin/bridgetown-quickstart development by creating an account on GitHub.

* * *

I wrote the steps I followed to create a new project - using the CLI and without having to install Bridgetown globally.

> **[Bridgetown](https://michaelcurrin.github.io/code-cookbook/recipes/ruby/gems/bridgetown.html)**
>
> Reusable code patterns which you can use as reference or copy to your project

* * *

Resources

> **[Bridgetown](https://michaelcurrin.github.io/dev-resources/resources/ruby/gems/bridgetown.html)**
>
> Links to resources around programming languages, developers tools and services

---

<div class="post-metadata">

**Author:** ![jordila](https://yyz2.discourse-cdn.com/flex030/user_avatar/talk.jekyllrb.com/jordila/32/3488_2.png) [@jordila](https://talk.jekyllrb.com/u/jordila)\
**Post date:** [May 31, 2021, 10:58am UTC](https://talk.jekyllrb.com/t/hello-bridgetown-rb-fork/5980/7 "2021-05-31T10:58:03Z")

</div>

BTW, [here the ‘fork’ authors… explaining “the why” ?](https://www.youtube.com/watch?v=btOuSOZd-6c)

---

<div class="post-metadata">

**Author:** ![jaredcwhite](https://yyz2.discourse-cdn.com/flex030/user_avatar/talk.jekyllrb.com/jaredcwhite/32/2102_2.png) [@jaredcwhite](https://talk.jekyllrb.com/u/jaredcwhite)\
**Post date:** [June 1, 2021, 5:01pm UTC](https://talk.jekyllrb.com/t/hello-bridgetown-rb-fork/5980/8 "2021-06-01T17:01:11Z")

</div>

Hi all. We just published our latest take on the matter here:

> **[Embracing Ruby, the Best Language for Building Websites, in Bridgetown 0.21](https://www.bridgetownrb.com/release/embracing-ruby-in-0.21/#a-note-about-jekyll)**
>
> Support for ViewComponent is finally here, along with numerous advances which fuel high-level design thinking. The powerful combination of Ruby and Bridgetown today enables tiny teams to compete favorably with much larger competitors.

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.)

---

<div class="post-metadata">

**Author:** ![xplosionmind](https://yyz2.discourse-cdn.com/flex030/user_avatar/talk.jekyllrb.com/xplosionmind/32/4041_2.png) [@xplosionmind](https://talk.jekyllrb.com/u/xplosionmind)\
**Post date:** [October 28, 2021, 5:41am UTC](https://talk.jekyllrb.com/t/hello-bridgetown-rb-fork/5980/9 "2021-10-28T05:41:18Z")

</div>

> [@MichaelCurrin](#):
>
> 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.

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](https://en.wikipedia.org/wiki/KISS_principle "KISS principle on Wikipedia") approach, while preserving the great extensibility for users, which makes Jekyll so great.

---

<div class="post-metadata">

**Author:** ![MichaelCurrin](https://yyz2.discourse-cdn.com/flex030/user_avatar/talk.jekyllrb.com/michaelcurrin/32/2340_2.png) [@MichaelCurrin](https://talk.jekyllrb.com/u/MichaelCurrin)\
**Post date:** [October 31, 2021, 5:18am UTC](https://talk.jekyllrb.com/t/hello-bridgetown-rb-fork/5980/10 "2021-10-31T05:18:36Z")

</div>

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)
