Bridgetown 1.1 “Belmont” Has Landed
We’re pleased to announce the release of Bridgetown 1.1 “Belmont”.
Read the release notes or installation instructions, or to upgrade from a previous version of 1.0, simply bump up the version numbers in your Gemfile
and run:
$ bundle update bridgetown
# or
$ bundle update bridgetown bridgetown-routes
You’ll also need to run bin/bridgetown esbuild|webpack update
to get the latest default configuration of esbuild or Webpack installed.
Check out our initial beta announcement for a full rundown of what’s new in v1.1. The TL;DR version is:
- I18n: you can create multilingual websites featuring multiple locales with URLs to match (aka
/en/products/widget
,/es/products/widget
, etc.). - HTML & XML Inspectors: modify your rendered markup after the fact with some Nokogiri magic!
- Sass support within esbuild/PostCSS bundling: we forget to mention this in the beta announcement! Bootstrap and Bulma users rejoice, you’re stuck with Webpack no longer…
- Your choice of automated installations of Lit, Shoelace, Ruby2JS, and Open Props. Oh yeah.
- Phrase highlighting in Markdown (aka highlighed text) via
::
or==
, along with a default syntax highlighting stylesheet.
We’re also excited about publishing our first round of documentation on how to migrate from Jekyll to Bridgetown! If there’s anything we can add to improve the migration guide, let us know.
Please visit our Community page to learn how to submit feedback, request help, and report issues. And a big shout out to our contributors and all who help make Bridgetown a thriving and growing community.
As Per Usual, More Changes are in Store… #
In our “Cherry Blossoms 2022 Edition” of what’s coming next for Bridgetown, we talked about a few ecosystem additions and improvements coincidng with the release of Bridgetown 1.1 such as an ActiveRecord plugin.
Well…it turns out that will have to wait for Bridgetown 1.2.
Here’s the deal: Bridgetown’s Builder-based plugin system is an evolution from Jekyll’s plugin architecture. And Roda meanwhile has its own robust plugin ecosystem. Both solutions are fine, but as I’ve been going deeper and deeper into building web applications and pulling in various Ruby gems using the Bridgetown + Roda “metaframework”, it has become clear to me that a canonical method of configuring and extending codebases using an understandable and comprehensive initialization process was necessary. The ad hoc method of adding various gems and throwing various “requires” and initialization steps in a Ruby file here or there simply wasn’t cutting the mustard. Things like dotenv, Mail, Stripe, Turbo & CableReady, etc.
So work is now underway on a new initialization process which is self-aware of which pieces can be shared between static builds and the Roda server, and which pieces are server-only (or static-only, although I suspect that’s much more rare). In addition, the way Bridgetown plugins get built will change a little—the ultimate goal being that the bridgetown_plugins
group within Bundler will no longer be necessary as dependencies/initializers will be defined in a concrete file with a straightforward DSL. Yes, just like how Roda-specific plugins work today.
We also have a few tricks up our sleeves for component rendering, testing, and even preview in tools like Storybook. Ongoing experiments there look quite promising.
While I’m disappointed to have to backtrack a little in what I’d promised earlier this year, I anticipate it will all start to come together sooner rather than later. The plan for the Bridgetown 1.2 release (shortly before the start of Q4 2022) is that will be laser-focused on enhancements to Roda, SSR, Components, and Gem integrations, which should prove to be a welcome improvement to Bridgetown as a framework for building fast, stable, maintainable, and understandable web applications.
In the meantime, enjoy the release of Bridgetown 1.1…
…and to Whet Your Appetite… #
I recently migrated my business website from Netlify to Render, and in the process I needed to handle contact form submissions directly since I could no longer use Netlify Forms. Bridgetown Routes (and the upcoming Roda Turbo plugin) to the rescue!
Here’s the src/_routes/contact-form.serb
route file in its entirety. In a nutshell, I render the bottom template portion twice: once in text form and one as HTML. I then make sure the “bot check” field was submitted correctly, otherwise I use Turbo to swap the field out for one with an error notice. If all is well, I use the Mail gem to deliver the contact message to myself, and finally update the contact form modal by re-rendering the ContactModal
component with Turbo.
~~~{%
r.post "reset" do
sleep 1 # intentionally allow modal to close on the frontend first
turbo_stream.replace "contact-modal", render(ContactModal.new step: 1)
end
r.is do
render_with =>
text_message
render_with(
data: { layout: :emails }
) =>
html_message
next html_message if r.params[:preview]
if r.params[:bot_check] != "11" && r.params[:bot_check] != "eleven"
next turbo_stream.replace_all(
"#contact-modal sl-input[name=bot_check]",
ContactModal.new(step: 1).bot_check(error: true)
)
end
mail = Mail.deliver do
to "Jared White <jared@whitefusion.studio>"
from "Jared White <jared@whitefusion.studio>"
subject "Whitefusion Contact Form"
text_part do
body text_message
end
html_part do
content_type "text/html; charset=UTF-8"
body html_message
end
end
turbo_stream.update "contact-modal", render(ContactModal.new step: 2)
end
%}~~~
# Whitefusion Contact Form
## Email Address
{{ r.params[:email] }}
## Message
{{ r.params[:message] }}
And because the website code is public on GitHub, you can check it out here.
This may be a fairly simple example in the end, but getting the ecosystem moving in concert up to this point has been quite the journey. I can’t wait share more with you all. ☺️