The History and Future of Bridgetown

September 2021 Update: We’re in the process of revising our website and just released a brand-new roadmap. Check it out!

Circa 2020:

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.

It’s early days yet, but our goal is to keep adding new features at a steady and predictable pace, grow the open source community around the project, and ensure a lively future for a top-tier Ruby-based static site generator moving forward.

Roadmap

As of spring 2020, here is the vision for where Bridgetown is headed. And this is just a start! If you have ideas and feature requests (and code!) to contribute, let’s do it!

(You also might want to take a look at our Project Goals page.)

  • ✅ DONE! Retool the codebase into a monorepo of multiple gems (like Rails/Spree/etc.)
  • ✅ DONE! Streamline internals to remove deprecated or legacy code paths and reduce confusing configuration options.
  • ✅ DONE! Improve default site file/folder structure to bring Bridgetown in line with other popular static site generators.
  • ✅ DONE! Add a bridgetown console command to interactively interact with the site data and plugins (just like the Rails console).
  • ✅ DONE! Remove the aging asset pipeline and regroup around a modern solution: Webpack. (Similar to how Rails adopted Webpack and distanced itself from Sprockets.) Check out the preliminary documentation here.
  • ✅ DONE! Integrate pagination features directly into the monorepo. Preliminary docs here.
  • ✅ DONE! Add streamlined taxonomy pages (for categories, tags, and other metadata) solution (called Prototype Pages).
  • ✅ DONE! Move most site data vars to a reloadable file (aka _data/site_metadata.yml) and support env-specific settings (development vs. production).
  • ✳️ DONE! External theme support is nearly here with the arrival of Source Manifests in Bridgetown 0.13. Stay tuned for an official guide on how to build modern themes for the next release of Bridgetown.
  • ✳️ DONE! Auto-reload plugins during development. (No more stop-and-restart every 5 seconds!)
  • ✳️ DONE! Liquid Components — this would build upon the new render tag functionality and add a ton of new features to make component-based design and authoring a reality, bringing Ruby/Liquid syntax closer to the world of React & Vue.
  • ✳️ DONE! Officially-sanctioned site testing framework to verify content and functionality after new builds.
  • ✳️ IN PROGRESS… Modernize various aspects of the codebase, incrementally improving the developer experience (DX) on a number of different fronts.
  • ✳️ IN PROGRESS… Ensure all documentation, configuration, and deployment recommendations are fully up-to-date and in line with best practices encouraged by the web development industry.
  • Straightforward support for third-party data APIs (think GraphQL as a first-class citizen).
  • Easy multilingual setup right out of the box.
  • Support additional template languages popular in the Ruby community such as ERB, HAML, and Slim.
  • Simple webhooks — allow remote webhooks to be pinged after a successful build.
    • “Private” pages — aka put a website section behind a randomized URL that changes frequently and then allow that to be pinged to a webhook somewhere.
  • Investigate potentially huge wins regarding headless CMS + Bridgetown integrations as officially recommended plugins.

And generally speaking, as an open source project we want to be good stewards of the codebase and community, which starts with adhering to a predictable release schedule. Based on SemVer, our goal is to strive for:

  • Major releases every three to six months (1.0, 2.0, 3.0, etc.)
  • Minor releases twice a month (1.2, 1.3, 1.4, etc.)
  • Patch releases in between as needed (1.3.2, 1.3.3, etc.)

We also want to ensure Bridgetown is a reliable partner for commercial solution providers by ensuring their frontline work with clients goes well and feedback flows positively into the Bridgetown feature set. What does this mean in a nutshell? It means if you make a living building websites using Bridgetown and run into major workflow hiccups, we want to know about it.

So, ready to try out Bridgetown for yourself?

Get Started