Rubyists Assemble! We're currently raising funds to help drive the launch of 1.0! Join the effort today ▸

Announcing Bridgetown’s Public Roadmap for 2021-2022

Jared White Jared White on September 2, 2021

When the Bridgetown project first launched in April of 2020, the mission was clear: modernize and reimagine Jekyll as an exemplary Jamstack-style Ruby website framework which can compete favorably with the best options on the market.

Since that time, we’ve accomplished much. Let’s see what was listed—and since accomplished—on our original roadmap:

  • ☑️ Retool the codebase into a monorepo of multiple gems (like Rails/Spree/etc.)
  • ☑️ Improve the default site file/folder structure to bring Bridgetown in line with other popular static site generators.
  • ☑️ Add a console command to interactively interact with site data and plugins (like the Rails console).
  • ☑️ Remove the aging asset pipeline and regroup around a modern solution: Webpack.
    • ☑️ Add additional commands to further cement the Webpack build process into the Bridgetown build process.
  • ☑️ Ensure documentation, configuration, and deployment recommendations are fully up-to-date and in line with best practices encouraged by the web development industry.
  • ☑️ Add the ability for any Bridgetown plugin gem to provide content/design, aka “themes” but in a way that’s composable and more flexible.
  • ☑️ Add a ton of new features to make component-based design and authoring a reality, bringing Ruby/Liquid (and since ERB, etc. -Ed.) syntax closer to the world of React & Vue.
  • ☑️ Straightforward support for third-party data APIs (think GraphQL as a first-class citizen).
  • ☑️ Add a streamlined pagination and archive page (for category and tags) solution to Bridgetown Core.
  • ☑️ Move most site-level data vars to a reloadable file and allow for env-specific settings.
  • ☑️ Auto-reload plugins during development. (No more stop-and-restart every 5 seconds!)
  • ☑️ Official site testing framework to verify content and functionality after new builds.

We’ve delivered on all of that—and a whole lot more—in only 16 months. Sixteen months! All open source, all entirely funded by the core team and our amazing GitHub Sponsors community.

But that’s just the beginning.

We’re ready to kick it up a notch and embark on the next 16 months of Bridgetown development, bringing the project to a complete 1.0 production-ready status which will power the next generation of fast and ergonomic Ruby-powered websites and web applications.

We are organizing our work around these three tracks:

  • The Platform Track
  • The Content Authoring Track
  • The Experiences Track

The Platform Track

These are the core architectural features Bridgetown needs to be successful across all site builds and deployments. They will comprise the bulk of the initial effort under our revised roadmap to get Bridgetown to a solid 1.0.

Included in this track are:

  • Switching the built-in server from WEBrick to Rack + Puma, along with Roda to handle intelligent serving of static assets (more on Roda below).
  • Migrating away from relying on yarn as the principal CLI tool and standardizing around the bin/bridgetown stub + Rake integration. (We’ll still use Yarn for installing and bundling frontend dependencies.)
  • Putting the finishing touches on a huge effort we’ve been calling “The Great Content Re-alignment” — aka replacing the aging Jekyll-derived content engine with the new Resource engine (which among other things supports conceptual consistency, relationship modeling, and taxonomies).
  • Enabling dynamic rendering of specific data and resources within Bridgetown, thus opening the doors to SSR (Server-Side Rendering) and other fascinating use cases.
  • Resolving a number of deprecations, alterations, and needed fixes in order to arrive at API stability for 1.0 and beyond.

The Content Authoring Track

These are features needed to make Bridgetown the perfect choice for advanced content authoring requirements.

  • Implementing robust multilingual and localization features (i18n), continuing under-the-hood work we’ve already undertaken.
  • Creating integration points and even full gems to provide turn-key solutions for headless CMSes like Prismic and Strapi.
  • Adding advanced interactions with file-based content structures and Git state (think jekyll-compose on steroids along with WordPress-style status and revision control)…allowing third-parties to build their own Ruby-based “CMS” solutions.
  • Providing publishing lifecycle and webhooks so Bridgetown seamlessly fits into a larger editorial pipeline.

The Experiences Track

These are features and educational resources needed to improve both the DX (Developer Experience) and UX (User Experience) of Bridgetown-based websites and web applications. This is admittedly the most “fuzzy” category, but nevertheless is a vital aspect of our overall mission.

  • Launching an entirely new logo/brand and website for Bridgetown to promote the project, showcase real-world usage, provide world-class documentation to developers, and advocate for Ruby as a premier choice for web developers.
  • Promotion of well-produced themes and theme-like plugins which give teams a huge leg up in starting new Bridgetown sites.
  • Ensuring Bridgetown defaults, recommended best practices, and officially supported ecosystem tooling are aligned with the latest standards and features of the web platform (high-quality semantic HTML, truly modern framework-less CSS, vanilla JavaScript with optional partial hydration) along with examples of effectively using platform-aligned third-party projects (such as Lit for web components, Hotwire/Turbo for SPA-like navigation and inline updates, etc.).
  • Partnering with and supporting other Ruby-based projects which have goals and use-cases that mesh well with Bridgetown and its approach to web development.
  • Moving ahead with architectural advances which would allow Bridgetown to facilitate site interactivity through a bona fide backend (aka write your serverless-less code here folks!), powered by the wicked-fast Roda framework. This is the ultimate culmination of the DREAMstack concept (Delightful Ruby Expressing APIs & Markup).
    • Much of the work done for the above will also make Bridgetown + Rails monorepos a legit developer story.
  • Along those lines, researching and pioneering new tools and practices around production deployments so we achieve many of the DX and global performance advantages of Jamstack’s “serverless” principles without the many accompanying downsides. Think CDN-like containerization of the backend, static + backend configurations which build and deploy simultaneously, robust connectivity with distributed databases and key-value stores (aka Redis), and other such concerns.

Now You Know Why We Need Your Help

We fully recognize that this is a highly ambitious roadmap which will stretch the capacity of our all-volunteer core team. Open source software doesn’t just emerge fully-baked out of exciting ideas. Actual humans with complicated lives have to put in the long, hard hours to turn Issue dreams into PR reality.

Some folks have asked me (Jared) why we couldn’t form a corporation, raise a seed round, hire people, and turn Bridgetown into a commercial enterprise.

I believe strongly that the best open source software is produced out of genuine grassroots community, as well as in conjunction with products which provide tangible benefits. Ideally, the developers, authors, and marketers using Bridgetown out in the real world to produce websites and applications would contribute back to Bridgetown to make it better. Some of the time that’s exactly what does happen, and it’s awesome.

But in order to move fast without breaking things, we need to infuse the core team with some basic capital to aid in platform-wide improvements and brand development and push the project forward. I’ve been floored by the support we’ve already received in the form of GitHub Sponsorship (huge shoutout to our Founding Members! 🙌). It’s evolved beyond “coffee money” and into the realm of seriously helping to pay the bills. And of course I treasure the ability of my (Jared’s) freelance web studio, Whitefusion, to act effectively as a “corporate backer” of Bridgetown.

Nevertheless, in order to accomplish the above roadmap in a timely and quality fashion, more is required. That’s where you come in!

Very soon we will officially launch a crowdfunding campaign designed to get us over the hump to releasing Bridgetown 1.0, launching the new website, and providing Rubyists with a clean, modern, and fast web framework they feel confident will be actively developed and well supported long into the future.

How much are we talking about here? We’re eyeing a minimum fundraising goal of US $5,000 to implement the first stage of our new roadmap. Depending on the success of this process, we will embark on additional fundraising opportunities down the road. To some, this might seem like a drop in the bucket compared to the operating budgets of many big-name startups in the #webdev space. To others, that might sound outlandish for a relatively new open source project with a modest star count. For us, it’s simply an experiment. Will it succeed? You be the judge!

Let the Festivities Begin!

We will share our detailed development strategy (aka line-by-line project plan) for the first fundraising effort later this month as well as the ability to contribute through one-time GitHub sponsorship packages or PayPal. In the meantime, please follow us on Twitter and join the Discord so you won’t miss a thing.

We’re incredibly excited about the future of Bridgetown and Ruby, and we can’t wait to see what you build with it.