So, introducing Bridgetown. What is it?
It's a static site generator.
Yes, like Jekyll.
…the reason it's a lot like Jekyll is because…
…it is Jekyll. (Well, kind of.)
Let me explain. Or rather, let our About page do the talking:
Bridgetown started life as a fork of the granddaddy of static site generators, Jekyll. Jekyll came to prominence in the early 2010s due to its slick integration with GitHub, powering thousands of websites for developer tools. In the years since it has grown to provide a popular foundation for a wide variety of sites across the web.
But as the concepts of modern static site generation and the Jamstack came to the forefront, a whole new generation of tools rose up, like Hugo, Eleventy, Gatsby, and many more. In the face of all this new competition, Jekyll chose to focus on maintaining extensive backwards-compatibility and a paired-down feature set—noble goals for an open source project generally speaking, but ones that were at odds with meaningful portions of the web developer community.
So in March 2020, Portland-based web studio Whitefusion started on Bridgetown, a fork of Jekyll with a brand new set of project goals and a future roadmap. Whitefusion's multi-year experience producing and deploying numerous Jekyll-based websites furnishes a seasoned take on the unique needs of web agencies and their clients.
That's a fairly long-winded way of saying: I (Jared) have been building a plethora of advanced websites with Jekyll for quite a while now—yet as much as I have loved working with it, it's definitely started to show its age. After an amicable conversation with the Jekyll core team, I decided to take on the exciting (but incredibly daunting!) task of "forking" Jekyll and using it as the starting point for a reimagined Ruby-based website framework: Bridgetown. And not just me, but I'm betting the entire future of my web studio Whitefusion on this technology.
In a short amount of time, Bridgetown has introduced a slew of new features, cleaned out deprecated or confusing configuration options, and laid the groundwork for major improvements to the manner in which static sites get built for Rubyists and beyond. Our premise is simple: we don't just want Bridgetown to be a good Ruby-based tool for generating sites. We want it to be good, period.
That's why all these changes being made to the codebase now, while perhaps painful in the short term for anyone wanting to quickly migrate from Jekyll to Bridgetown, are vital and necessary, because we're planning for the next ten years of Jamstack technology innovation.
Part of the reason people turn to software frameworks to build things is to get good defaults. You want something that comes with everything you need to start off right so you don't have to reinvent the wheel or get lost in an industry dead end. This is an active and ongoing focus for Bridgetown, from how the software gets installed, to configuring typical settings and plugins, to best practices in building and deploying the final site.
In the year 2020, as the Jamstack phenomenon has taken off like a rocket along with all the ways the web community is pushing the tech forward, a sane person might argue that it's time to give up using a Ruby-based framework entirely and switch to using Eleventy, or Gatsby, or Hugo, or Next.js, or Nuxt, or…the list goes on. Listen, I get that, I really do! There are already too many static site generators out there.
But I’m crazy enough to believe in the bones of the Jekyll software and essential stack choices: Ruby as a delightful, productive language; the power of Liquid templates for rapid layout and prototyping (and soon components!); Kramdown with all its awesome enhancements to Markdown; Gem-based plugins, convention over configuration, etc.). In fact, having now read through every code file and test in the process of making substantial changes and adding new features to Bridgetown, the strength of this technology stack is clearer to me than ever before.
Today, this has become a reality:
gem install bridgetown -N
bridgetown new amazing_website
And you don't have to abandon Ruby to do it.