Reaching 1.0: Just What is a Next-Generation Progressive Site Generator?

Jared White on March 10, 2022

I’ve been giving a great deal of thought to trying to find the right “hook” for how to frame the news that Bridgetown has (finally!) reached 1.0 status.

There’s a lot we could say here, from the modern plugin & component system to the wide variety of template engines available, the advanced content modeling, dynamic routes, esbuild integration, bundled configurations & automations—but that’s all conveyed on the homepage and documentation elsewhere.

So instead, I would like to focus on our new tagline itself.

Bridgetown is a next-generation, progressive site generator & fullstack framework, powered by Ruby.

What does that string of buzzwords mean exactly? In this article I’d like to dive into the initial portion of that statement: next-generation, progressive site generator. Stay tuned for a future analysis of all the rest!

Next-Generation #

Bridgetown represents an evolution of thinking from previous generations of tools in this space, especially within the Ruby ecosystem. At heart, Bridgetown is essentially a modern rewrite of Jekyll—it started out as a fork in April 2020 but has since been thoroughly reworked and reimagined while adding a ton of new and unique features.

But besides just making building ambitious web projects far easier than with Jekyll while simultaneously allowing Ruby developers to leverage far more of their skillset, Bridgetown sets its sights farther afield. Ultimately we’re not here to compete with Jekyll, or Middleman, or Nanoc. We’re here to compete with Gatsby.

Lest you think that’s a wild piece of hyperbole, we’ve already received reports of people who have left the bewildering complexity and sluggishness of Gatsby behind (and similarly-over-engineered tools in other ecosystems) to focus on building Bridgetown sites instead. Right now it’s a trickle, not a flood. But we’ve only just arrived at 1.0 and still revving up the engines.

We’re here to extend a welcoming hand to struggling JavaScript & web developers of all stripes. Come on in, the water’s fine! Ruby is a phenomenal language for web development tools & frameworks, it’s very much alive and not going anywhere, and every day we’re dedicated to making this ecosystem even better.

The pace of progress on the web never stands still, and neither will Bridgetown. We have big plans for 1.1, 2.0, and beyond. The time to hop aboard this train is now.

Progressive Site Generator #

For quite some time, we’ve been familiar as web developers with the concept known as “progressive enhancement”. The idea is that as much as you can start with simple/standard HTML, and slowly build up your CSS and particularly JavaScript without completely breaking the experience for older browsers, slower networks, JavaScript disabled, etc., the better. In other words, you start with a principal baseline, and then “progressively enhance” the site content and functionality via whichever latest hotness in browser tech you wish.

I would like to introduce a new term into our developer lexicon, inspired very much by progressive enhancement but focused instead on the delivery mechanism of that HTML. I call it “Progressive Generation”.

In a Progressive Generation workflow, you aim to assemble the most basic form of HTML at the web server level: static files. Indeed, this very blog post you’re reading on the Bridgetown blog is just that: a static HTML file living on a web server (a CDN more specifically). This is exactly the type of output you get with a static site generator (SSG) which is the default mode of Bridgetown (and the only mode of Jekyll and other first-generation SSGs).

Next, you get to selectively decide how to progress from there when you need to add more dynamic features such as form submissions, user logins and persistence, e-commerce, paywalls, database access, etc. There are several routes available to you:

• SSR: known as Server-Side Rendering, this is where your HTML is not pre-built as static files, but where you render HTML in real-time before delivering it to the browser.
• CSR: known as Client-Side Rendering, this is where JavaScript libraries manipulate the DOM of the webpage based on user interactivity and API calls to backend or third-party services.
• Partial Hydration: this is essentially a hybrid of the two approaches. You start first with some combination of SSG & SSR, then “hydrate” certain components on the frontend to handle interactivity only if and when it’s needed.

In an ideal world, the tools & templates you use to construct the baseplate of your website through SSG and the ones you use for additional SSR are one and the same. However, until fairly recently, this was rare and non-obvious across our industry. While it’s true that JavaScript-based frameworks have been leading the way here, along that way they’ve forced us to adopt highly-opinionated, controversial, frontend-focused tools (React for example) as a necessity for such an approach…with much additional build complexity in tow. In addition, an overly-wrought focus on CSR rather than SSR via major frontend frameworks (resulting in SPA—Single-Page Application—architecture) has introduced numerous concerns in both UX & DX.

This fracturing of “best practices” in web development due to the rush to adopt (and over/mis-use) these types of frameworks has led to seminal articles on the topic such as The Great Divide and Second-guessing the modern web.

Embracing the Future Web via Progressive Generation #

I think the ultimate answer to these conundrums lies somewhere between the two possible extremes, and in particular I posit two major points of consideration:

• Progressive Generation advocates that HTML should be generated in multiple ways at various times depending on the use case. In the simplest case, it’s literally a “Zero Javascript” configuration. We must prioritize tools which don’t force you to ship any JavaScript to the client unless absolutely necessary.
• Progressive Generation advocates that the bulk of your website’s HTML can be generated by any type of tool, any type of framework, any type of programming language, and any type of hosting setup. In other words, requiring “everyone” to adopt a particular flavor of JavaScript/TypeScript running on a particular hosting provider offering a particular service flavor (serverless functions for example) goes against the grain of progressive generation.

If it sounds like I’m advocating for a sort of “lowest-common denominator” of where HTML originates for a website, why yes that’s exactly what I’m advocating for. This is in keeping with the spirit of the origins of the web. HTML & HTTP were expressly designed to allow any operating system, any computer system, any point on a global network to be able to participate in the HyperText revolution—regardless of the tools and processes used in the generation and serving up of that HyperText.

We MUST evolve dynamic functionality, interactivity, and DX on the web starting from that initial mindset, and Progressive Generation embodies that ethos. Progressive Generation + Progressive Enhancement for a Progressive Web which honors the past while embracing the future.

Conclusion #

It’s quite possible that Bridgetown is currently one of very few tools available today which fully embraces Progressive Generation. I certainly expect to see more on the horizon as time passes, but I feel very confident Bridgetown has an opportunity here to make some waves. Already we’re among the first to support SSR & partial hydration of Lit-based web components. And we’ve been hard at work experimenting with pushing the limits of both Hotwire Turbo and CableCar for wiring SSG, SSR, and CSR together. Expect to see much more in this space in the coming months.

I’ll go into further details regarding the “fullstack framework” embedded within Bridgetown in a future article. You don’t need to use it if all you need is an SSG. We’ll always prioritize ensuring Bridgetown is super-simple to get started with for a straightforward blog, marketing page, community resource, portfolio, etc. But when you need more, it’s there for you.

In closing: Bridgetown 1.0 is here! The DREAMstack has arrived. Now what are you gonna build with it? 😎

Share This Article