Read the Docs
@@ -257,7 +257,7 @@ Bridgetown's philosophy is if we take the time to build what you'll actually nee
### Sky-High Plugin Architecture
- Bridgetown might just be the easiest way to get started learning and writing Ruby code. Craft custom plugins to enhance your site build and content with a straightforward DSL and make huge strides in only a few lines! If you already have experience writing Rails apps, you should feel right at home. (Yes, we love Active Support too!)
+ Bridgetown might just be the easiest way to get started learning and writing Ruby code. Craft custom plugins to enhance your site build and content with a straightforward DSL and make huge strides in only a few lines! And if you already have experience writing Ruby apps in other frameworks, you should feel right at home.
Read the Docs
@@ -278,7 +278,7 @@ Bridgetown's philosophy is if we take the time to build what you'll actually nee
-Then when you're ready, [bundled configurations](/docs/bundled-configurations) and [plugins](/plugins) can take you even farther. Add SEO/social graph support, news feeds, inlined SVGs, asset management integration, headless CMS integration, automated testing, islands architecture, Turbo, Shoelace, Lit SSR + Hydration, and a whole lot more.
+Then when you're ready, [bundled configurations](/docs/bundled-configurations) and [plugins](/plugins) can take you even farther. Add SEO/social graph support, news feeds, inlined SVGs, asset management integration, headless CMS integration, automated testing, islands architecture, Shoelace, Lit SSR + Hydration, and a whole lot more.
{:style="text-align:center; margin-top:3rem; margin-left:auto; margin-right:auto; max-width:50em"}
diff --git a/bridgetown-website/src/_partials/_footer.serb b/bridgetown-website/src/_partials/_footer.serb
index 4215d3142..27b0ac71e 100644
--- a/bridgetown-website/src/_partials/_footer.serb
+++ b/bridgetown-website/src/_partials/_footer.serb
@@ -23,7 +23,7 @@
- Contribute on GitHub
+ Contribute & Participate
@@ -34,7 +34,7 @@
- Discussions on GitHub
+ Community Site Discussions
Discord Chat
diff --git a/bridgetown-website/src/_posts/2020/2020-05-07-postcss-tailwind-plugins-oh-my.md b/bridgetown-website/src/_posts/2020/2020-05-07-postcss-tailwind-plugins-oh-my.md
index 9bdcf2150..d3ded96de 100644
--- a/bridgetown-website/src/_posts/2020/2020-05-07-postcss-tailwind-plugins-oh-my.md
+++ b/bridgetown-website/src/_posts/2020/2020-05-07-postcss-tailwind-plugins-oh-my.md
@@ -5,12 +5,17 @@ author: jared
category: news
---
+{%@ Note type: :warning do %}
+ #### This post is a bit outdated!
+ Since writing this post, automations were added to Bridgetown. To start using Tailwind CSS with Bridgetown, check out the [community-maintained automation](https://github.com/bridgetownrb/tailwindcss-automation).
+{% end %}
+
Personally, [I'm a Bulma man myself](https://bulma.io), but I understand there are a ton of you out there who love [Tailwind CSS](https://tailwindcss.com) and won't give it up until they pry it out of your cold, dead hands.
So I'm pleased as Ruby-colored punch to [highlight this breezy tutorial by Andrew Mason][andrewm-blog] all about how you can quickly and easily set up a new Bridgetown website with Tailwind CSS and PostCSS.
From the [article][andrewm-blog]:
-
+
> If you have had Ruby/Rails/Jekyll experience, you should feel right at home with Bridgetown. Bridgetown also removes the barrier to entry for integrating webpack and all the goodies the JavaScript community has to offer.
[andrewm-blog]: https://andrewm.codes/blog/build-and-deploy-a-static-site-with-ruby-bridgetown-tailwindcss-and-netlify/
diff --git a/bridgetown-website/src/_posts/2021/2021-10-24-era-of-bridgetown-v1.md b/bridgetown-website/src/_posts/2021/2021-10-24-era-of-bridgetown-v1.md
index f9a735263..99f68da0e 100644
--- a/bridgetown-website/src/_posts/2021/2021-10-24-era-of-bridgetown-v1.md
+++ b/bridgetown-website/src/_posts/2021/2021-10-24-era-of-bridgetown-v1.md
@@ -122,7 +122,7 @@ This is a contrived example of course, but you can easily imagine loading a spec
You can even use placeholders in folder names! A route saved to `src/_routes/books/[id]/chapter/[chapter_id].erb` would match to something like `/books/234259/chapter/5` and let you access `r.params[:id]` and `r.params[:chapter_id]`. Pretty nifty.
-Testing is straightforward as well. Simply place `.test.rb` files alongside your routes, and you’ll be able to use Capybara to write **fast** integration tests including interactions requiring Javascript (assuming Cupite is also installed).
+Testing is straightforward as well. Simply place `.test.rb` files alongside your routes, and you’ll be able to use Capybara to write **fast** integration tests including interactions requiring Javascript (assuming Cuprite is also installed).
Rest assured, a **full setup guide & tutorial** for all this stuff is on its way. ([Want to get it sooner?](https://fundraising.bridgetownrb.com) 😉)
diff --git a/bridgetown-website/src/_posts/2024/2024-02-22-road-to-bridgetown-2.0-escaping-burnout.md b/bridgetown-website/src/_posts/2024/2024-02-22-road-to-bridgetown-2.0-escaping-burnout.md
new file mode 100644
index 000000000..ea9790a51
--- /dev/null
+++ b/bridgetown-website/src/_posts/2024/2024-02-22-road-to-bridgetown-2.0-escaping-burnout.md
@@ -0,0 +1,91 @@
+---
+date: Thu, 22 Feb 2024 09:20:27 -0800
+title: Road to Bridgetown 2.0, Part 1 (Stuck in Burnout Marsh)
+subtitle: In 2023 I very nearly walked away from Ruby. But after time to think and reflect, I arrived at a plan to make working on Bridgetown “fun” again. Now a new day dawns, and the ecosystem is poised to enter the next stage of this journey.
+author: jared
+category: future
+---
+
+**TL;DR:** Bridgetown 2.0 is now under active development! We have a new [Community discussion site](https://community.bridgetown.pub), based on Lemmy! Stay tuned for additional announcements coming soon of what’s next for the ecosystem! And now, on with the post…
+
+----
+
+A little known area of Bridgetown, upriver from where the tourists typically spend their time on vacation, is a treacherous stretch of water known as Burnout Marsh. My boat got mired there during the back half of 2023, and I barely escaped with my life.
+
+All right, enough of that clumsy metaphor. 😄 I didn’t want to have to write this post, believe me. I’d much rather just get on to all the juicy technical stuff that’s fun to talk about. Blog posts about “maintainer burnout” are as exciting to read as watching paint dry. It’s a bit akin to the celebrity complaining about how they have to hire security because they’re just so gosh darn famous. Like, dude, you’re famous OK? Quit yer whining before you look like an asshole.
+
+But the fact remains that maintainer burnout _is_ a thing, and it affects a lot of open source software projects. Everyone’s burnout looks a little different, and mine was no different in that way. A little bit of this (weird, weird time in the tech industry), a little bit of that (too many other irons in the fire), but mostly a particular thing (to be revealed momentarily) which affected the worst possible facet of my role as a maintainer of Ruby-based software: _my love of Ruby_. 😱
+
+Truth be told, **I nearly walked away.** 😞
+
+And the reason is both complex and simple. Here’s the simple version: the social degradation of 37signals in general and David Heinemeier Hansson (DHH) in particular nearly robbed me of all the joy I felt programming in Ruby. 😬
+
+Now nearly as distasteful to me as wallowing in “maintainer burnout” territory is wallowing in “framework authors taking potshots” territory. So you can imagine I’m _doubly_ not feeling great about where this is headed. I’ve written some version of this post over and over again in my head, and more than once in my drafts folder which _you’ll_ never see let me tell you right now. But like ripping off a Band-Aid, some things just have to be done. So here it goes.
+
+### The 37signals Problem
+
+I was aghast when the meltdown at 37signals happened in 2021. It was widely covered at the time, perhaps best by Casey Newton in several pieces such as [Behind the controversy at Basecamp](https://www.theverge.com/2021/4/27/22406673/basecamp-political-speech-policy-controversy) and [Inside the all-hands meeting that led to a third of Basecamp employees quitting](https://www.theverge.com/2021/5/3/22418208/basecamp-all-hands-meeting-employee-resignations-buyouts-implosion). At the time, I thought _surely_ there would need to be some reckoning with how DHH conducts himself within open source projects as well such as Rails and Hotwire. Perhaps Rails could set up a more transparent governance structure, or at the very least announce DHH stepping down from a position of influence for a while (while making a very public stand around proper Code of Conduct (CoC) etiquette).
+
+Not only did none of that happen 🤨, but DHH made a _huge_ stink about not being properly invited to keynote RailsConf again right away, leading to [RailsConf and DHH going their separate ways](https://thenewstack.io/railsconf-and-dhh-go-their-separate-ways/) and the eventual formation of the “Rails Foundation” and Rails World conferences. So…no such reckoning. DHH would maintain an iron grip on Rails indefinitely (this new foundation really just solidifying his personal influence rather than offering any sort of real check on his power or ego), and in fact go forward to “compete” with RubyCentral and RailsConf. 😩
+
+As if this wasn’t all bad enough, the next shoe to drop dropped…and in a very public way as these things are wont to do. Out of the blue, without warning to any regular contributors or other community members, 37signals (aka DHH) simply decided to remove TypeScript from the Hotwire Turbo codebase. Again, no opportunity for discussion, no time for a heads up or any sort of guidance on how it might affect existing contributions. Just **boom**, here’s the PR, insta-merge within hours, [self-congratulatory DHH post on HEY World](https://world.hey.com/dhh/turbo-8-is-dropping-typescript-70165c01), done. 😳
+
+Folks, **this is not how you run an open source software project**. Somebody’s hobby project on GitHub that’s really just their own little playground, sure, I guess. But not something as consequential as, oh I dunno, _the frontend stack of the Ruby on Rails framework_ and a tool used even outside of Rails by other frameworks! 🤪
+
+Note carefully that none of what I’m saying or about to say has any bearing on the _merits_ of removing TypeScript. We can debate those merits at our leisure, and anyone who knows me knows I’m no big fan of TypeScript. But that’s not what this is about. This is about how people govern open source projects and conduct themselves among peers.
+
+Needless to say, this move to unexpectedly rip TypeScript out of Turbo generally went down like a lead balloon, and things got heated fast. That’s never a good sign (when long-time regular contributors to a project are themselves feeling pretty grumpy), and it eventually led to this seminal issue: [Remove DHH for CoC Violations · Issue \#977](https://github.com/hotwired/turbo/issues/977).
+
+To be very clear, nobody’s claiming that making the decision to remove TypeScript was a CoC violation, but the _manner_ in which it was done: with _zero_ involvement of the community and no consideration whatsoever (active hostility in fact) of broad feedback about the decision. I want to quote DHH’s posted response to this claim of CoC violation in full, because there simply is no way for me to read this without feeling enraged once again, and I want you to feel enraged too:
+
+> “This is elevating a disagreement of a technical decision to a level of nonsense that has no place here. This project has been founded, funded, and maintained predominantly by the resources and investment of 37signals. We will set the direction as we see fit, accepting input and contributions as they're presented, but with no guarantee of concurrence or merging. All the best finding a project that's more to your liking in direction or leadership or otherwise somewhere else 👋”
+
+Notice all the very specific language DHH employs here:
+
+* “nonsense” — regular readers of his blog know this to be code for “woke lefties” who would dare challenge his alt-right “edgelord” positioning on a variety of topics. Every time DHH’s political machinations are being publicly challenged, you’ll see the accusations of “nonsense” trotted out ([here’s but one example](https://world.hey.com/dhh/may-shopify-s-immunity-spread-to-the-whole-herd-7bd855ce)…stochastic terrorism is “nonsense” in DHH-speak, a product of “woke scolds”).
+* “founded, funded, and maintained by…37signals” — in other words, you, dear contributor to the Turbo repo, don’t actually matter if you aren’t specifically part of the business entity known as 37signals. This is technically open source, sure, but the benefits mostly flow in a single direction. 37signals gets all the benefits of _your_ efforts to improve _their_ codebase, yet meanwhile you get none of the power. Yes, you get to use their code in the end, but that’s it. That’s the only benefit. _Whoop-dee-frickin’-doo._
+* “We will set the direction as we see fit” — and by “we” he means himself. DHH. The big kahuna.
+* “All the best finding a project that's more to your liking” — aka if you don’t like how I run things, _fuck you_.
+
+Folks, there are times when situations are complicated, nuanced, with no real good guys or bad guys, and it’s genuinely hard to parse out what’s really going on and how to process the myriad of factors in order to arrive at a comprehensive decision.
+
+**This is not one of those times.** 😅
+
+Clearly what we witnessed in this debacle is _far_ from a shining example of how one should govern an “open source” project. Perhaps it would be better described as “source available” — use the code, but don’t count on the stewards of the code to care for the needs of the community. And to get real specific, I am convinced that yes, DHH has indeed been in violation of his own CoC, and the real tragedy is _nobody has the power to call him on his own bullshit_. DHH is co-owner of 37signals, and 37signals controls all Hotwire intellectual property.
+
+Personally, I find DHH’s continued stranglehold over the Rails and Hotwire frameworks nauseating and thoroughly unacceptable. But ultimately, that’s not the hardest part of it for me. It’s all the carrying water for him that’s gone on in the broader community. People—and yes, good people all—still keep promoting Rails (and Rails World), keep releasing Ruby code and educational resources that prop up Rails as much if not more so as Ruby, and essentially keep DHH on his pedestal.
+
+**It’s enough to make you just want to up and quit Ruby.** Which I very nearly did. 😭
+
+But, y’know, I gave myself lots of time to think and reflect. I chatted a lot with my close friends and fellow Bridgetown team mates. I mused on ways I might be able to make Bridgetown “fun” again, both in terms of ongoing maintenance as well as future feature development. I waited to see if maybe I could get my boat unstuck and past Burnout Marsh and start heading downriver towards calmer waters again.
+
+**And now I’ve arrived here.** 😌
+
+----
+
+### What’s Next for Bridgetown in 2024
+
+This post kicks off a short blog series outlining some of the approach we’re taking to construct the next major release of Bridgetown, version 2.0. But it’s also an announcement: we have a new [Community site](https://community.bridgetown.pub) y’all! 🙌
+
+Part of my general burnout in 2023 was just dealing with the absolute insanity which seems to have taken over the computer industry…not the least of which is the rapid “enshittification” of commercial social networks. It really got me paranoid—not only worrying about which services were actively going sideways (*cough* Reddit *cough*) but which might implode next in the future. Bridgetown has relied heavily on Discord, and to a lesser extent GitHub Discussions, and, well, I’ve been growing increasingly antsy about each.
+
+So rather than wait for more shitty developments and scramble to react to them, I decided to be proactive and set up a new [Bridgetown Community site](https://community.bridgetown.pub), based on Lemmy. This serves as a replacement to GitHub Discussions, and an adjunct to Discord. We’ll still rely on Discord for chit-chat (at least until something can serve as a truly suitable substitute) but look to the Community site for longer forum-style posts, technical conversations, tutorials, and something “bloggy” that’s a bit less formal than posting here on the main blog. There are some interesting tidbits there already, and I look forward to more folks in the Bridgetown ecosystem commenting there going forward!
+
+So let’s wrap up with a brief mention of what we’re announcing today as part of the “Road to Bridgetown 2.0” push. If you read my diatribe above, what I’ll say next probably won’t come as much of a shock.
+
+**We’ve begun the process of de-37signals-ifying Bridgetown.** (Now there’s a mouthful! 😆)
+
+Here’s what this means. We have put an immediate stop to integrating any more dependencies run by 37signals in Bridgetown. In practical terms, this means no additional embrace of libraries like Active Support, and no continued investment in bundled configurations such as Turbo or Stimulus (in fact we’ll be removing these for Bridgetown 2.0). And over time (this will be very much an incremental thing), we will either _remove_ our internal dependency on Rails libraries like Active Support or _vendor_ specific code we can’t easily replace.
+
+This is certainly not ideal. The Bridgetown codebase, and community at large, has benefited from the features provided by Active Support, Turbo, and other 37signals-run projects. But as DHH so emphatically put it, “all the best finding a project that's more to your liking in direction or leadership or otherwise somewhere else 👋”. So that’s _exactly_ what we are doing. We’ll be looking at other libraries — or in certain cases just building our own solutions — to replace the functionality we had relied on from 37signals.
+
+We take Bridgetown’s own [Code of Conduct](https://github.com/bridgetownrb/bridgetown/blob/main/CODE_OF_CONDUCT.md) seriously, and part of that approach means we need to be careful we don’t pull in third-party dependencies from open source projects which are themselves in violation of _their_ CoCs. We’re not in the business of policing the internet, nor can we ever vouch for all other open source projects we might ever touch in some way. But it was a _strategic decision_ originally to embrace codebases run by 37signals, and it is another strategic decision to let them go. I’ve talked about this at length with the rest of the Bridgetown core team, and we are in agreement that it’s in the best long-term interests of the Bridgetown project to take a public stand on this.
+
+So that is merely one aspect of the work that’s ongoing as we head towards Bridgetown 2.0. But thankfully, there’s a lot more that will no doubt prove more exciting and hopeful, from a minimum requirements bump to Ruby 3.1 and Node 20 to a _huge_ performance boost in development in the form of Signals-based Fast Refresh. More on that in the next blog post.
+
+The big takeaway is that I’m feeling more pumped about the future of Bridgetown than I have in many months. Between sorting out feelings of disappointment around past events, and coming up with a list of improvements to the project and the ecosystem I’m very excited to be moving forward on, a new day has dawned. 🌞
+
+**Bridgetown 2.0 represents a sort of clean break**, not just because we can remove deprecated APIs, streamline aspects of the codebase, and improve features in ways that will help make the framework faster and more stable, but because version 0.x represents an experiment, 1.0 represents something stable yet still new, and 2.0 represents _longevity_. Bridgetown is here to stay. We have a full major version bump looming. And we hope you’ll stick around to see what comes next. 🤓
+
+_Want to discuss this post? [Jump over to our Community site and add your comment](https://community.bridgetown.pub/post/11)_ 🔗
+{: style="text-align:center; margin-block-start: 1.5lh"}
diff --git a/bridgetown-website/src/_posts/2024/2024-02-29-road-to-bridgetown-2.0-new-baselines.md b/bridgetown-website/src/_posts/2024/2024-02-29-road-to-bridgetown-2.0-new-baselines.md
new file mode 100644
index 000000000..0e674b6a0
--- /dev/null
+++ b/bridgetown-website/src/_posts/2024/2024-02-29-road-to-bridgetown-2.0-new-baselines.md
@@ -0,0 +1,88 @@
+---
+date: Thu, 29 Feb 2024 08:14:56 -0800
+title: Road to Bridgetown 2.0, Part 2 (New Baselines)
+subtitle: Announcing a solid set of defaults we believe will make Bridgetown that much more robust, appealing, and ready to tackle the challenges of tomorrow.
+author: jared
+category: future
+---
+
+> “And blood-black nothingness began to spin…a system of cells interlinked within cells interlinked within cells interlinked within one stem…and dreadfully distinct against the dark, a tall white fountain played.”
+{: style="text-align:center; margin-inline: 1.25vw"}
+
+OK OK, not that [baseline](https://www.youtube.com/watch?v=1h-seEowtDw). 😜
+
+Rather, what we're talking about are **technology baselines**. Minimum language version requirements. Language syntaxes. Tool dependencies. That sort of thing.
+
+The **Bridgetown 2.0** release cycle lets us reset some of these baselines, moving the framework into a more modern era without sacrificing developer experience or causing major upgrade headaches. For the most part, you should be able to keep your projects running with few (if any) changes. But of course, with a little spit and polish, you'll be able to take full advantage of improvements lower in the stack.
+
+Let's step through the various baselines we'll be providing in Bridgetown 2.0.
+
+### Ruby 3.1
+
+Bridgetown 3.1 will require a **minimum Ruby version of 3.1**. Our policy is that for each major version number increment (in this case, v2), we will move the minimum Ruby version to two yearly releases prior to the current one. Since today's Ruby version is 3.3, that allows us to support Ruby 3.1 and 3.2 as well.
+
+Because we're moving from the past minimum of Ruby 2.7 to 3.1, this opens up a whole new world of Ruby v3 syntax and functionality being made available to the Bridgetown ecosystem. I wrote about [some of my favorite Ruby 3.1 features](https://www.fullstackruby.dev/ruby-3-fundamentals/2021/01/06/everything-you-need-to-know-about-destructuring-in-ruby-3/) over two years ago! And even more has happened since with the releases of Ruby 3.2 and 3.3. (YJIT, anyone?)
+
+We suspect many Bridgetown projects are already on Ruby 3, and for those still using Ruby 2.7, the upgrade process to switch to at least 3.1 should be fairly smooth.
+
+### Node 20
+
+Until recently, for a good window of time it seemed like the particular version of Node you happened to be running wasn't a huge deal since Bridgetown's use of Node has been almost exclusively relegated to compiling frontend assets.
+
+While that will continue to be the case, we are making some specific, intentional changes to *how* Bridgetown integrates with Node. In order to streamline these efforts, it makes sense to standardize on newer versions of Node.
+
+As of the time of this writing Node 21 is the current production release, but as we suspect Node 22 is right around the corner (based on Node's yearly release schedule), we are jumping the gun just a tad and going with **Node 20** as our baseline (since essentially that will be two versions prior to current once Bridgetown 2.0 is released later in Q2).
+
+Which brings us to:
+
+### ESM
+
+The JavaScript NPM ecosystem has been stumbling towards its goal of coalescing around ES Modules (ESM), rather than CommonJS, for quite a long time now. It feels like we've arrived at the moment when it's now or never, so let's do it now. For those of you only vaguely aware of what the differences are, here it is in a nutshell:
+
+```js
+const path = require("path") // CommonJS
+
+import path from "path" // ESM
+```
+
+Yes, for those of you asking, ESM has been the _only_ way you write JavaScript for client-side purposes (since ES6 anyway). Yet Node's historical CommonJS manner of importing and exporting modules and packages has persisted on the server. The end is nigh though, as universal ESM syntax has been embraced more and more throughout the ecosystem.
+
+There are two ways to instruct Node to use ESM instead of CommonJS. You can name JavaScript file extensions as `.mjs`. Or you can add `"type": "module"` to your `package.json` file.
+
+For Bridgetown 2.0, **we will be opting for that latter option**, and all configuration files for tools like esbuild and PostCSS will be supplied in ESM format. CommonJS will still work in your existing projects, but for all new projects, it will be all ESM, all the time! 👏
+
+### Farewell Yarn
+
+When the Bridgetown framework first launched in 2020, many people considered Yarn to be a better package manager than Node's built-in `npm` solution. Many frameworks had built up around it, and even Ruby on Rails had embraced it.
+
+But time doesn't stand still, and neither did npm because at this point, it works just as well as "classic" Yarn and newer versions of Yarn ended up causing headaches due to changing designs, syntax, and feature-set sweet spots.
+
+So in Bridgetown 2.0, we're greatly simplifying and **migrating to using npm by default**. You still have the *option* of keeping classic Yarn around for use in your existing Bridgetown projects—or you can switch over to npm or even another popular package manager, [pnpm](https://pnpm.io/). We'll focus on npm out of the box, but switching to pnpm should you wish it will be straightforward (we've actually supported it in the most recent v1.x releases anyway).
+
+### Farewell Webpack
+
+Bridgetown has defaulted to using esbuild for its frontend bundler for some time now, but with Bridgetown 2.0 **we'll be removing official support for Webpack**. This does mean we recommend migrating your projects from Webpack over to esbuild *as soon as possible*, since we have no guarantee Webpack will continue to work once Bridgetown 2.0 arrives.
+
+The writing has been on the wall for some time, as the entire web industry generally pivots away from Webpack and towards more modern solutions like esbuild (Vite, Turbopack, and Parcel being some other popular options).
+
+The good news is that we continue to feel *extremely* satisfied with our embrace of esbuild. I personally like to say that esbuild is the "last bundler" I'll ever use. And I really believe that. I see no reason years from now why esbuild won't still be perfectly adequate to perform the sorts of lightweight frontend bundling and asset pipeline tasks Bridgetown users typically require. It's nice to have that level of confidence in a framework dependency.
+
+### ERB by Default
+
+And last but certainly not least, we'll be switching away from Liquid as our default out-of-the-box template engine and over to ERB. Bridgetown is a Ruby framework after all, and **ERB is the template language most Rubyists are familiar with**. The reason we ever defaulted to Liquid in the first place was an historical one…Jekyll defaulted to Liquid—and in fact _only_ supports Liquid (you have to install a third-party plugin to get some sort of ERB support). But with Bridgetown having supported ERB for years now, it makes sense to go ERB-first.
+
+However, we have a few tricks up our sleeve—some extra features in the works to bring [Serbea-like pipelines over to ERB](https://www.serbea.dev/#add-pipelines-to-any-ruby-templates), as well as a new DSL based on procs & heredocs called **Streamlined** you can use instead of ERB in certain parts of your codebase to generate complicated HTML quickly and efficiently. (This is essentially our answer to "tag builders.")
+
+And for that **maximum cool factor**, we'll be unveiling an optional, first-party solution to server-rendering **web components** which can later be hydrated and become interactive on the client-side. We've already offered a solution of sorts along these lines with our [integration of Lit-based web components](https://www.bridgetownrb.com/docs/components/lit). However, this new solution will provide a whole new component format—one which takes further advantage of Ruby as well as the proposed [HTML Modules](https://github.com/WICG/webcomponents/blob/gh-pages/proposals/html-modules-explainer.md) spec. *Ooo…exciting!*
+
+(Note that we'll be retiring first-party support for Haml and Slim. I don't wish to step on anybody's toes, but template syntaxes based around indentation/whitespace rules just aren't on the radar of frontend developers by and large. I would argue they feel more like an artifact of Ruby's past than anything modern developers are looking for. Let's rally around writing HTML templates in ways which frontend devs can feel comfortable with and get up to speed on quickly.)
+
+### Wrap Up
+
+So there you have it: **Ruby 3.1. Node 20. npm. esbuild. ERB and a whole lot more.** A solid set of defaults we believe will make Bridgetown that much more robust, appealing, and ready to tackle the challenges of tomorrow.
+
+There are also some efforts underway to streamline parts of Bridgetown's internals to make it easier for contributors and maintainers. Besides simply removing a handful of small deprecations, we're in the process of completely moving away from Cucumber and towards standard Minitest for integration tests to bring them in line with the rest of the automated test suite. You can [read more about these efforts](https://community.bridgetown.pub/post/10) on the community site.
+
+Along with quality-of-life and maintenance improvements, we hope to make progress in increasing the build performance of Bridgetown. Perhaps not so much in production per se (where, to be honest, it's less critical—the difference in your site rebuilding in CI in 12 seconds vs. 6 actually doesn't matter much), *but most definitely in development*. We all know how frustrating it can be to make a small text change and then have to wait seconds—maybe even tens of seconds!—before the page will refresh in your browser. We have a solution in mind called **Fast Refresh** based on the principles of Signals, using the [Signalize gem](https://github.com/whitefusionhq/signalize) which is a Ruby port of Preact Signals. It's not quite an "incremental build" type of solution, but it'll get us where we need to go. More on all that in the next installment of *Road to Bridgetown 2.0*.
+
+Until then, [hop on over to our community site and let us know](https://community.bridgetown.pub/post/12) what you're most excited about regarding these changes in Bridgetown 2.0. As always, your feedback is most welcome!