Hey, folks, welcome to another episode of the Ruby Rogues podcast. This
week, on your panel, we've got a yush nuatya and I'm Charles max
Wood from Top End Devs. So a USh, you're kind of our expert
guest or expert host or however you want to swing that cat. And yeah,
we're talking about Bridgetown. Now. We lined this up before you were
a host on the show because we were talking about the Codex, the Rails
and hot Wire Codex and then you know you, it came up that you
were on the Bridgetown courteen and I was like, well, cool, because
I've been wanting to talk about it. So yeah, it's good to be
back. It's good to be on the other side of the metaphorical table,
all right, as a guest rather than a host. But yeah, let's
let's bridge down. So yeah, yeah, might you want to start,
Well, we have a grand tradition on this show starting with a definition,
So why don't you tell us what Bridgetown is? Right, So, Bridgetown
is what we call a progressive site generator. So hi VALENTINEO, Hey there,
yeah, we just got started. Yeah awesome. So let me read
out the tagline from the website. We call it a next generation progressive site
generator and full stack framework powered by Ruby, which is a mouthful to what
the hell does that actually mean. Well, it's kind of like a successor
to Jackal. It was foked from Jackal four point two, but it's kind
of turned into something that's a lot more than just that. So it's still
like primarily a static side generator, like I would say, all the features
and everything are geared towards like I would say, ninety percent of it is
geared towards just building static sites, And we refactored quite a lot from Jackal.
So like obviously the whole world a static side generation kind of evolved quite
a bit from when Jackal first arrived on the scene, and a lot of
quirks under the hood, where you know, things like a collection of posts
in Jackal is kind of like a custom collection but not really, it's slightly
different in different ways. And then yeah, there's like a whole it was
just under the hood very messy in certain ways. So we kind of refactored
the entire generation engine. So the way like the content is either red off
disc or like acquired from some other source and and built into this site,
and then the site has written the actual website with HDL pages written to disk
for you to do as you want. So I say, we rewrote it.
Jared that Chaffie started the project. He rewrote this whole thing. And
then a common use case is also like, you know, you have like
n statics item and suddenly need one tiny bit of dynamic functionality. Like let's
say you have a marketing website and you want to put a contact us form
on it, and you need some weight for that form to like an endpoint
for that to submit to which sends an email to yourself or something like that.
So we used a framework called Roda, which is like, uh,
it's kind of like a toolkit to build a framework rather than a fully formed
framework in its own right, and using we kind of plugged that into bridge
down and now you have the ability to write a few dynamic endpoints in addition
to your static site. So we kind of cater to this whole use case
where you kind of most of your content is static, but you need a
little bit of dynamic functionality, and we'll provide that to you in the context
of like a Ruby full stack framework. You don't need to go reaching for
lambda functions and all that stuff, because that kind of goes against our philosophy
of like everything should live in the single repot and everything should be runnable locally.
Yeah, we've had Jeremy Evans on to talk about RHODA, and I
mean I remember back in the day when Jacko came out. I mean the
use case that everybody used was a blog, right, and so you were
talking about how you have this collection of posts and it kind of, you
know, does magical things for your posts, and yeah, I mean that
was very much how it was used. That's how I mean, that's what
Tom wrote it for, was so that he could run his blog on it,
and so yeah, it made sense. But yeah, the I guess
those limitations are the things that kind of kept me from like fully adopting it.
So you know, you look at something like top end devs, right,
because I've used static site generators to run top end or dev chat,
dot tv top end devs right, and then I've moved it back to a
rails app I think three times now, and so you're right, we're now
on the third time. And the reason is is because I have other dynamic
stuff I want to pull into it, And the other end of it is
is if I have a rails app and I want a blog or something like
that, the bridgetown does well, then you know that's the hiccup. On
the other end is Okay, how do I integrate the two so that every
time I change, say the layout on one, I don't have to change
it on the other because I may want it to live under top endevs dot
com slash blog as opposed to having blogged on top endevs dot com, right,
so I can get the SEO and the other benefits of having a part
of the website. So those are kinds of the things that I've been looking
at with it. But I have to say a couple of the things that
I do really like about it are that it seems to have a lot more
options and it seems a lot more friendly to front end manipulation. Right,
so if I want to bring in a hot wire and wire things in,
that's not terribly hard. Jeckle. You kind of had to play with it
a little bit, I guess, to make it really nicely do that.
And then yeah, I didn't realize that you had kind of the dynamic aspect
of it with Rhoda. So yeah, I mean, let's say that I
want to give this another look, right, because you've kind of gotten my
interest here, Like where do I start and how do I make it do
what I want without having it be a giant pain in my rear end because
I maintain two systems. Yeah, of course, so a lot of that,
like the dynamics stuff is still like early days, so there will be
like teething trouble. It's not going to be as soon with Asraels. It's
just such a mature framework. But honestly, the best way to get started
just gem install Bridge Down. Bridge Down knew my site. Honestly, the
best way to do it is just get your hands dead and you'll see a
directory structure out there that'll instantly look familiar for anyone from the Jackal world.
That'll be like end points for service side stuff and all that kind of created
for you. And the docks are really good. Like one of the things
that attracted me to the Bridge Down project early on before us on the Court
team was that the docks were so good. And I think I first stumbled
upon the project was like literally two or three months old, and I didn't
realize how new. It was looking at the docks, I thought, this
is like years old. So we're very proud of the quality of the documentation.
So yeah, just create a site. Got a bridge down arb dot
com. Check out our docks. You should find whatever you need out there.
And it just to take the point that you said earlier on about like
a bridge on being a bit more friendly towards the front end. So that
was actually think when the framework was first launched, I think the title or
something about it being like a webpack aware static side generator or something, and
yes, that was always a core thing for us, was like we needed
something on the front end that was built in that because no one wants to
wrangle Webpack and yes build. I mean, I blame half my gray hairs
to just having to use Webpack and Webpacker. But we've got a pretty good
set up right out of the box. So if you need to install,
like, we've got a good es BIL set up. Now we're deprecating Webpack,
but if you need to install anything on the front end, we've got
like NPM and es build and all that just already set up for you,
so you don't have to deal with any of that, right Valentino. Have
you used Bridgetown, you know, I haven't. The last time I did
a static site with within Ruby it was it was with Middleman. Yeah,
the Middleman, Jim. I'm curious because like it has a lot of similarities
to Middleman, and I'm curious like maybe if you, like, if you're
aware of Middleman, maybe how like you can dissuade some of the older like
Ruby heads like us, right, like, hey, what does it bring
that Middletown you know or Middleman like kind of uh swears straight away, and
maybe some of the highlights from it. So I'm aware of middle Van,
I'm aware of its existence. I've probably browsed its website once a couple of
years ago. But I couldn't give you a good critique because I just I
just don't know middle Line well enough. So I can I can talk to
the strength of Bridgetown, but I couldn't compare it to Middleman because I've never
used it, gotcha, Yeah, I mean the deployment's aspect of it.
It's very much like a build local, you know, and then deploy static,
whereas it seems Bridgetown is much more built up around uh, you know,
having that dynamic key aspect of it, like it'll augment it, right,
Yeah, that's true. But I mean if you wanted to use it
purely as a static side generator, you still can. In fact, all
my bridge on websites are purely static. I don't think I've got dynamic functionality
on any of them because I haven't needed it. So with bridgetown, we
kind of we we like to promote render dot com as a preferred host just
because all I already like it. And yeah, it's once you set it
up, what Rendell will just will trigger a build every time you do it
get which is pretty normal, and then it'll it'll just run a bridge down
build a bridge down bridge on deployed rather, which will generate the side and
write it to disc and then it'll uh each take your output folder and deploy
that to a CD. And so you don't really need to do a whole
lot. It's uh And we have something we have something a feature of bridge
down called bundled configuration. So that's kind of like workflows or recipes or whatever
that you can run to configure certain things. And what we have one for
render our concert. When you run that, it will create a render dot
yamal file which is like infrastructure as code. So then literally all you need
to do is link your repositoraty render and point it to that file and that's
it and you have a website up, up and running. Gotcha. Yeah,
you know this. This looks a lot more featurage than middle man does.
Uh. You know. Again, like we keep saying, like focusing
on the front end aspects of it, seems like you can build like maybe
some JavaScript apps potentially. Yeah, you can. Nothing stopping you from doing
any of that. Yeah. I mean, Ruby is always going to be
front and center. So we have features like you can write components which are
just Ruby classes which is built right, and we have like a concert of
Bridgetown components so you don't need to pull in like a third party thing for
that is just there. So Ruby will always be front and center, and
it's quite easy to also do quite advanced things like you can hook into the
build process and start doing like dynamics stuff at build time. So one of
my websites, which is f slash forty two dot com, which is like
a photo gallery, so if you want to look at it, its f
s l a s H four two dot com it's a photo gallery at like
a lot of my photography on there, And all I need to do is
really copy paste photo photo files into the repository and run the build. And
then I have Ruby code that reads the photos off disc, extracts exit information
things like like shutter speed and all all that stuff, extracts it from the
file, writes it to a Yamel file, and dynamically adds HTML pages to
the build, and then when the build concludes, writes those HTML pages out.
So for each like album or each photograph, I'm not creating those pages
manually. That's just all done by Ruby cuts. All I need to do
is copy the photos in place and run and run the build. So like
that's pretty like advanced advancedge Ruby code that I've just hooked into the build process.
So I'm imagining something similar with like a JSON file or something. If
you just have a you know, kind of a how do I put it?
A static or an you know, it doesn't change very often, so
I'm comfortable committing the data to the repo. You can do the same kind
of thing, right, It's the same idea as the markdown with Jack,
Right, yeah, exactly. I have another blog post, I just commit
more data, yeah, exactly. The difference here is is that I'm just
copying photo files into place, and then there's Ruby good that's reading and doing
some stuff with us photofiles. Because yeah, there's no there's obviously nothing built
into handle JPEGs, right, well, handle JPEGs in the way that I
want them handled. You can obviously just paste them in and reference them in
your HTML. Right, So you've got some kind of renderer or data extractor
that you've yeah, yeah, data data extractor basically. And then and then
a dynamic way to add pages to the to the build, because I don't
want to manually create a new marked a HTML file for each and every photograph.
I've just got some code in there that generates those pages for me at
built time and adds them into the I think it's a site top pages collection,
and then when the site is output, it'll just render at all those
pages. That's cool, It's really cool. Yeah, Because like we unified
the concept of like collections from like I said earlier, Jackal kind of treated
different types of collections slightly differently, like posts is treated slightly differently to a
custom collection and stuff. We kind of unified all that, and now we
have built in collections like pages and data and posts. Those are built in.
You get them out of the box for free, but they behave in
the exact same way as a custom collection would behave. So that just makes
doing advanced things like this, like when you're manipulating the build, it just
makes it a whole lot easier. That makes sense. So in essence,
you know, kind of the how do I put it the the blog you
know that we typically see for for sites like this, things like this,
right that it just does that natively naturally. How far can you push it?
So what I'm imagining is okay, so I have a different kind of
entity. I mean you've talked about you know, images, So I can
write my own plug in for it that does the image thing. Can I
build like like to take payments on it or to restrict access to content you
know, to members or right, because I'm imagining, okay, how far
do I push this? That might be easier than writing a fully blown rails
app. Yeah, you can push it as far as you want if you
want to do payments and start out with the rude op thing is. Therefore,
that's where you you can write all that. I think a couple of
years ago we'd run like a virtual Bridgetown conf I think at the end of
two and I'd given a demo as part of my talk, and I think
the demo was a simple photo gallery where you can buy photos. I didn't
actually integrated stripe or anything. I just kind of fake the payment stuff.
But the demo is basically that that you have the static thing with which lets
you view the photo gallery, and then you have this little dynamic buy button
where you can buy the photo and obviously just fake the back end stuff,
but like I demonstrated how it can be done. So yeah, absolutely,
with regards to payall in content, of course you can do that as well.
So actually Jared, who runs Who's the Start of the bridge Down project,
still runs it to a large degree, just released a CSS course that
is fully built on Bridgetown. If I could actually find the link to that
that would have that would be quite useful. But yeah, essentially it's all
just a Bridgetown app and he's it's a subscription service, so he's built like
payments and he's honestly pay all his articles because it's a subscription cost. And
that's all all done using bridge down. So yeah, you can push it
as far as you want. It just depends on how far do you want
to push it until you start wishing you had rails. But you can still
you can still plug rails in because Roda is rack r plant, so you
can still you can plug and you can mount rails as an app within it.
Yeah. I got a bunch of questions here, Yeah, because I
mean I think of like typically like we have like some core tenants. More
thinking about like static sites, right, like where we have like you know,
SEO is probably like the number one like thing that people start thinking about
when they just want to get like some static marketing page up right. And
I guess the next one would be like, you know, the caching layer,
Like what what is provided like to just like make sure that all of
the files are like g zip compressed or whatever and optimized for like the server
layer to be able to you know, other like plugins and stuff for this
kind of stuff is just come out of the box, like you know what
what what? I guess optimizations are built in that like gives you that peace
of mind like oh, yeah, I should use bridge down and I don't
have to worry about all this stuff. Yeah, absolutely, So actually we
don't build any of that stuff into the framework because like again ninety it is
aimed at static files and the way to host them is just dump them on
a CD and if you have static HTML files on a CD and a lot
of any decent CD and automatically gs up your files and cash them properly before
sending them down anyway. And then like with render dot com, which is
my preferred host, you can set cashing headers and stuff manually using the YAML
infrastructure as code pingy. So yeah, we don't handle that in the framework.
The dynamic stuff again is very much kind of like a bull to on,
so we don't have anything built in for that. But yeah, it's
it's a truly reach for and most of your content is static and you don't
have to worry about that if you're hosting it on a CD, and so
yeah, we don't do it in the framework. Well, I'm just going
to throw into that a lot of the SEO stuff. I mean, some
of it's just your content, right, but some of it is also like
meta tags in your HTML and things like that, and so you're going to
see a lot more of that in your layouts and themes as opposed to from
the framework itself. Right, Yeah, we do have a bridge down SEO
plug in which generates a bunch of those meta tags for you. So that's
one of the plugs that kind of reach for when I'm starting a new site.
Anyway, I think I'm pretty sure it's the first party plug and so
it's uh, let me just double check that. So like then you yeah,
bridge down se O tag. It's a it's a first party plug and
it's under the Bridgetown organization on on GitHub and yeah, then you're just like
dropping an e ERB tag or a liquid tag in your in your layout and
it'll pull stuff out from configurations. Uh and it's all in the read me
and it'll just generate those matter tags for you. Awesome problem. So right
yeah, And another huge advantage of bridge doown over Jackal as you can use
r V. Jackal is liquid only, and I low the liquid. I
mean, it's it's great when you're kind of when you use as a writing
templates because you can't give users the ability to execute rub on your app.
But if you're writing your own templates, then e r V all the way.
Oh yeah, and yeah, we were still currently Bridge down is still
defaulting to liquid, but in Bridge Down two point zero, we're gonna switch
the default to ERB. Liquid will still be there as an option, but
the default will be ER because that's I just think it's the way forward.
Yeah, you know, I always despise get hub pages yea templating Yeah,
honestly all of the crop that comes with jackyl, which I do see,
like you have you provide easy deployment to our configuration with get hub pages,
which is really fun. Yeah, we do it well, it's a pain
to kind of maintain that keeps breaking, and it like I die a little
bit inside every time someone in the bridge down this god off? How can
I get this work in get hub pages. I'm like really, like,
I mean, render dot com it's free, it's the exact same thing.
It's free, but it actually works, right, So how does render dot
com work? I mean, we don't have to dive into much of this,
but like I was always under the assumption that they, like, yeah,
there's like kind of the up charge for like location observability, like a
non observability, but location like where you want to deploy it to, like
fly that style. No, Render's just your standard platform as a service.
It's kind of like HEROICU, but living in twenty twenty four not twenty fourteen,
and yeah, shots fired right. It's it's just a platform of the
service, and they offer stating sites for free. So instead of like on
Heroca, you kind of think of each thing as a site, on render
dot com, you think of like you think in the within a concept of
services. So like let's say a rails application, you would have a web
service which is a Rails app. You'd have a database service, you'd have
a background job service, and you'd have a redis service. So you have
four services on render dot com which comprise one application or one site. But
for a static side, you just need one static site service and that will
when you link it ticket have repository and it'll do the build and deploy for
you every time you do a get push. Also, things get a bit
more complicated when you want to do dynamic stockers. Then you need a second
service that that handles the dynamic things. Essentially, what you'd have is one
instance of your application running statically and another instance of your application running dynamically,
and then you just like punch holes through one to kind of call the other
when needed. So like through your static site, you can You've probably host
a dynamic thing at like API dot Example dot com, and then your static
side just calls out to API at example dot com for the dynamics stuff.
So that's yeah, that's how n that works. It just their model just
kind of fits my brain really well, just the concept of services. I
just like how that kind of is conceptualized, because yeah, I just understand
it quite well. Right. One thing that I'm wondering about with the deployment
story on this is, yeah, going back to the example that I used
before right where it's hey, look, you know, I'd like to have
a blog on top endevs dot com right, top endevs dot com slash blog,
and I don't necessarily want to have to manage all of the different fields
and have my database and do the thing. Plus, statically rendered files tend
to you know, they load faster. There are a lot of good reasons
to do it that way. Is there a way to deploy it up underneath
a rails app? And do you typically just add it to your Rails repo
in some way and have it build into a folder or do you deplay it
separately and then use I don't know, engine X or something to say and
this folder loads this other thing. You all those are valid approaches for me
personally, I'd probably keep it in a separate repo and either have engine X
to kind of take care of the routing, or I would just bite the
bullet and host on a subdomain just because I'm lazy that way. So yeah,
for example, my my app's ctagun dot email is a rails app,
but the blog, the product blog is at blog dot ctagun dot email,
and that's a bridge down app. I mean I could have hosted on like
ford slash blog and then done some funky stuff with redirects or rl rewrites to
kind of make that work, but I just seemed cleaner. So I do
lose some of the SEO benefits show, but it's just cleaner that way.
So that's how I would do that. Whether you don't want to mix it
up with your rail streeper, probably not, depending on how your use cases
actually set up. I mean you could. I know, I know that
Jared has done it with Jackel in the past, where he's kind of had
rails and jackals sitting side by side. I mean there's no nothing stopping you
from doing that. There's no technical reason why you shouldn't. I probably just
wouldn't because it's against just my sensibilities to a point where it's a personal thing
I have. There's no technical reason not. It's just a personal thing.
I don't want to be mixing those two. No. Yeah, I was
doing research for this and I made me think of high voltage from Popo,
which I guess there it's a maintenance mound, which is kind of a bummer,
but maybe this opportunity here for bridge humplug in for rails. Yeah,
we were working on something, but then Jared kind of lost interest and it's
probably not gonna happen because his so the thing is it's like Bridgetown is like
I would say eighty to ninety percent Jared White, probably ten eight percent me
and then two percent other contributors. So it's still very much his show.
I'm quite happy to just support him in any way he needs, which also
and because it's like it's all volunteer stuff, it does mean that the things
that him and I are interested in are the things that get done, and
his interest in rails is dwindling pretty significantly, and I don't have ambassive interest
in integrating rails with bridgetowns. If we have contributors that want to come in
and help us out with it, we'd be more than happy. But I
don't think it's something that's on either of our radars at this point. But
that said, one of the legacy bits we're kind of carrying from Jackal is
the fact that the web server was kind of hardcoded into the tool itself,
So jack because Jackaloni used a web server for development, so they had hard
coded webrick in there as part of literally built within Jackel. Yeah, as
part of bridge Down. One point, Jared ripped out Jackal and put Puma
in because we needed Puma for for Rhoda. So but now we were in
a position where Puma is kind of built into Bridgetown, and I wasn't particularly
happy with that. So I've taken some steps to make Bridgetown just generic rack
compliant. So we want to be at a point where you can or you
can bring any rack compliant webserver you want and bolt it onto Bridgetown. We'll
obviously still supply Puma as a default, but once we get to that point,
Bridgetown will be like any other rack app. So you could just put
it in alongside your ears Reaper or whatever mount and just mounted as a as
A as A as an engine in your roots dot RB in rails. So
there is a pot to that. It's just uh yeah, we'll we'll get
the we'll get that soon enough. Yeah. I found a few posts as
well when I looked at this last that we're using a gem called Rails reverse
Proxy, And effectively, what it does is it takes the request to rails
at slash blog, slash whatever, and it just knows that that has to
get passed off to your bridgetown instance or jeckl or Hugo or whatever you're running
in the you know that's running somewhere else. But it'll just hand it off
and then you know, return the response. Yeah. But the downside to
that is that then if you're layout on your main page changes and you want
it to look the same, you have to make the change in both places.
Yeah, exactly, So that's always going to be. It like a
tricky thing if you're handling two separate repositories. It comes down they're like,
yeah, whether you want to run it as whether you want to run it
as two different projects, or you want to run it as a single project,
because I think if you're trying to run it as a single project and
using two different tools, that's probably going to get gnarly at some point or
the other. So, like going back to my Skatagun example, I had
this Skatagun blog which is bridge on power, and the app it solid is
reels Powered. I treat them as independent products. So the blog has the
same color scheme and like fonts and design language as the app, but it
doesn't share any of the layouts or design or anything like that. So it's
just a very It's just it's got a similar look and feel, but it
doesn't share any components or code or anything like that. And that was intentional,
just because I wanted to run them because I wanted to avoid that exact
problem that I make a change in one place and then I'd have to make
a change in another repository. I didn't want to do that, right.
So one thing that I'm gonna whine about here for a minute is lately I've
gotten very much into tailwind and I really like it. I've paid for tailwind
Ui, so I use a lot of the stuff that's in there. But
one thing that I found with like podcast show notes is that if I type
them into like the tricks editor or something, when it renders it out,
it doesn't add the tailwind classes to the right, to the paragraph tags or
the header tags or whatever, right, And that that's something that I would
like to be able to do. And so what I find myself doing is
effectively finding ways to add those styles in some other way underlike the dot tricks
whatever content class. Right, So tricks content class H one looks a lot
like in H one out of tailwind, right, But I have to go
and I have to kind of handcode that myself, and that's been a huge
pain. So does bridgetown give you ways of doing that when you render stuff
out? As far as I get the whole like wrapper around things in the
layout is going to have all that stuff, and I have that in rails.
But you know, from my markdown or wherever I'm pulling the content from,
can I tell it to build it out that way? Short answer is
no, because unless you're handcoding HTML and putting the classes in, which would
be like, yeah, it's like writing HTML, we don't provide anyway.
Can't do that in knockdown because we just use cram down as a renderer.
So I think whatever way you can add custom classes to a cramm down file,
you'd be able to do it that way. We don't have anything specific
and bridge down for that, and I doubt there will ever be, because
Jared and I have both vocal opponents of the whole tailwind approach with utility and
things like that. I would I want hold my breath and that it's unlikely
to happen. I think that is like that is one thing that I don't
want to say never, but I think if even if someone proposed some functionality
to make that happen, I think Jared and I both both would just put
a stop to it at that. Sorry, this is not happening in bridge
Down. I don't want to put words in his marth either, But that
is just one thing where I think we would probably draw a line, and
that because I think I just don't think it's a good approach for web development,
and I get why people like it and I don't. I don't want
to dissue it people from from using it. It's a very like just for
me personally, I think you should give CSS the respect it deserves. And
I like the concept of separating styling from from from content. So everything in
bridge Shan will always kind of be in the spring it of the open Web,
which is you write your content, which which is an HTM, or
you style it using CSS and you add a dynamic functionality on top of that
using JavaScript. So that will always be like a core tenet of Bridgetown.
And mixing up your CSS and HTML to me, in my opinion, goes
against the spirit of the open Web. So you don't want to be my
friend anymore. I got it. It's okay, Yeah, I got that.
Understand what you're saying, and I can only imagine what a headache it
would be to try and make something like that work. But yeah, I
mean there's always ways around it, right, like oh yeah, yeah,
But I think again, if you if you're if you're wrestling against the tool,
you're probably in my opinion, not doing something, not doing something right.
Yeah, because I think one workaround in Bridgetown might be to because I
said earlier, we have the concept of Bridgetown components, which is just Ruby
classes, so you could just use those to define your styles in there,
say you can you have a methad which returns all the tailwind style classes that
you need and then just call that in the HTML template, So that that
would be one way of going about it within Bridgetown, within right within the
tools that are provided, and I think using them in the spirit that they
are meant to be used. Valentino, you said you had a lot of
questions, so and then I keep jumping in with mindt Yeah, I wanted
to touch on THEMING because like I feel like next to like SEO, maybe
theming is like the next frontier. Yeah, it's uh, it's a bit
sad at how few community creative themes are out there for Bridgetown. It's something
we we've tried to push a number of times for the community to create a
few more themes, but it hasn't been something that's materialized. I mean there's
a few out there. I think there might be a GitHub tag Bridgetown Themes
or something like that. I think there might be something on the Bridge Down
website as well. But yeah, it's it's a bit of a shame that
there's not more out there. We have an API for themes, we have
a guide and how to create them as well. It's just I think the
tool is not popular enough to have a wider variety of themes. So yeah,
if you're listening and you want to use bridge down and you like it,
please create more themes. What is that process? Like, I'm curious,
Like I see, like there's there's you basically create a new plug in,
but like what happens after that? Yeah, it's just so we have
a plugin generator. You generate a plug and you read the dogs, follow
the instructions and how to create a theme. You publish it to GitHub,
and I think you add a tag to it. I think kind of remember
the tag is. I think it's either just bridge down dash plug in a
bridge down dash them or something like that, and it will show up on
our website. Yeah, there's not a massive process to it. You just
publish it on GitHub and then anyone can use it. It's just it's just
true. It's the same as publishing a Ruby gem. So yeah, you'd
have to create a gem and push it to Ruby gems as well. But
yeah, it's it's literally just like creating a gem. Gotcha? And is
that like a you know, you pick your CSS or like JavaScript, like
all the asset bundling, like that's the responsibility of the plug in kind of
thing. Yeah, yeah, is there, like you know, because what
I would love is, like, you know, something like Bootstrap or something
like that apply to the Yeah, I mean, I think I'm pretty sure
you can can figure Bootstrap using the like the thing I mentioned earlier, bundled
configurations. So let me check. Do we have Bootstrap? You know,
we don't have Bootstrap, but we could. Yeah, that's easy enough,
so we have you can configure things like shoelace, open props, things like
that. We're just running one command. I'm surprised we don't have Balma in
there. Actually, something we should probably add. So yeah, Balma is
my favorite CSS framework if I was going to use on, which is in
fact, actually very rarely that I actually even use the framework. But yeah,
I mean, these things can be installed quite easily because you have h
NPM there, so you can install them and they'll they'll be there in your
build for you to use just a couple of in a couple of commands.
So even if you don't have it, like even if though there are no
community created things that there are a few, but not a lot, stuff
like Bootstrap and Balma, you can configure very easily and the and you have
all that power at your fingertips. Yeah, I do see that in the
front end bunneling section here. Now you just you know, yarn ad the
framework of your choice and then included yeah styles, Yeah that's cool. Where
do you take it from here? I mean it looks pretty feature complete,
like, uh, yeah, we have we have. We have a few
Road to Bridgetown two point zero blog posts that have been published, so if
you check out the Bridgetown blog you'll see some of the things we're working on.
So one of the things for me is getting Bridge down to be racked
the Pliant so we're not relying on a specific server. Jared is working on
like speeding up how the hot reload works in development, so right now you
kind of rebuild the entire website every time you make a change, which for
bigger sites is not very efficient. So he's working on something that does like
incremental bills so your hot reload when you're developing is super snappy. But a
whole bunch of other stuff like small improvements as well. I think the big
one is we're aiming to drop our dependency and active support. It probably won't
happen for bridge down two pointer over long term, we want to drop our
dependency on active support. Is there a reason for that? Jared's written out
along blog posts about it, for himing the reasons were largely personal, but
that my view on it is, uh, I think there's a lot of
there's a lot of scope for different ideas in the Ruby community. We've kind
of gone too close to rails with bridge down a number of times, I
think, with with the use of things like active support and stuff like that.
I think we were just trying to just fly very close to Rails.
But I think it's good to have different ideas around the Ruby community. So
we're just trying to see what what else we can come up with that doesn't
have a hard dependency on on Rails framework, and just try to try to
have a few different trains of thoughts, different solutions to problems. So you
see what that takes us. Really Yeah, but the reason for dropping actor
support was a largely personal thing by Jared because of his disillusionment with Rails and
with thirty seven signals. So yeah, like I said, he's ninety percent
of bridge down, so there's no point in going in a direction that he
wasn't happy with of motivated to work on because it's still largely a volunteer driven
thing. He doesn't get paid for it. We have a small number of
githubsponsors, but it's very much a labor of love. So I'm quite happy
to support him with whatever direction he wants to take the project in. So
one thing that I'm wondering about with some of these static sites, they do
a great job on a bunch of stuff, but one of them is search.
Right, So if you have a large amount of stuff in your website,
you know people are gonna want to find it. So do you recommend
something like Algolia or some of these engines out there that kind of hook into
your site, or do you push people more toward hey, you know,
here's a really simple way to do it with the Rota implementation that you have,
or and where where do people end up for that? So we recommend
like a JavaScript approach. I think Algolia is one of the We have search
on the Bridge Down website, which is a Bridge Down powered website, and
it's not so it's not a service side, it's not a server powered search.
It's client only. I am just trying to see where Yeah, but
see, if you use Algolia, you're using their back end to do the
search, right, So bridge on it's using the bridge down quick Search plug
in which runs Lunar dot l u n r dot GS. So it's not
Algolia. That's my brother's probably just confusing myself. So this is purely client
sites. I think it builds like a gson document or something, and it
builds its own index statically exactly. It's a purely JavaScript powered search. L
U n R dot GS is a solution we're using, so h's and the
plug is called bridge down quick Search. It's another first party plug and so
yeah, that's that's what we recommend for search. But if you wanted something
a bit more involved, and again you can always just reach out for the
service, like any service side solution. Yeah, I always like Lunar.
Yeah, I didn't try. There's another. There's actually quite a few,
you know, JavaScript search client side search now which worked really well that are
very much like I think there's one like that's like an elastic search clone even
okay wow, And they're they're really easy to use, uh and it's pretty
wild like how fast they are. So besides kind of the cleanup on like
active support, getting rack support in. There are there other things that are
coming to bridgetown or nothing? Nothing big. We're pretty much like we want
to keep bridge down Core fairly slim, so we don't want to be putting
stuff in just for the heck of it. I think a lot of the
big features and stuff will be largely plug ins. So I think Jared had
an idea where he wanted to have like really good first party support for Flex.
Do you know the library flex p h l e X by Joel Drapper.
It's it's a way to write components using HTML. It's way it's a
way to write object oriented HTML using peer Ruby. I think, I mean,
I've got that completely wrong. It's something to do with writing. It's
like a DSL to write HTML using Ruby. It's like if view components had
a DSL. Okay, what what Valentino said? The Internet? It looks
cool. Yeah, So initially I think he proposed adding that to Core.
But then I said as something like I should live in a plug in.
So yes, there will probably at some point be a plug in, or
there might already be one that I'm not aware of because Flex isn't really for
me. But yes, things like that will always live in plugins. There
will be first party plugins under the bridge Down organization and GitHub so and we'll
have good support for them out of the box. But we're not looking to
add a whole lot into Bridgetown core. It's going to be largely incremental changes
and just getting it to a stable place because we don't want, uh,
we don't want to start making bridge On too complex because it's already it does
quite a lot, and I and just judging by the vibe, but the
bridge time count, people are just getting a bit daunted by it already.
So we definitely like our philosophy is very much the simple stuff will always be
simple. So we may have all the advanced of like service ide, rendering
and all in there for you to use, but if you want something as
simple as just a blog, that'll always still be very simple to do.
You're not going to stand in your way in any way, shape or form.
But honestly, when you have a lot of advanced features, people inevitably
tend to get distracted by those. So I can't think of anything that's like
a big feature that we have coming through the pipeline. It's all just going
to be like incremental stuff for the foreseeval anyway, unless unless someone has a
really solid proposal that we be the core team, like and like, okay,
then we can go ahead with that. But for now, there's nothing
that I'm aware of other than let's just keep cleaning this up and keep keep
stabilizing it. So the million dollar question here is can we use AI to
you know, generate static pages for us generation that to be yeah, to
uh just have a bot but right, like if there's a bridge town GPT,
right, I use it to just quickly uh spin up ideas. Yeah,
of course you can. Yeah, there's nothing stopping You're just writing Ruby.
Good you can do. You've got the whole power of Ruby at your
disposals. You can do whate value you want. All right, Bridge down
plugging coming, bridge down right. I'm kind of curious what's your story with
this? How did you wind up working on this project? Yeah? Good
question. So I think it was quite early on in my time with Ruby.
So for listeners who aren't familiar, and he started working with Ruby and
twenty twenty, I used to be a mobile developer for that, and I
spent the first half of the pandemic pretty much learning Ruby and rails and a
light. Sorry, we're glad you saw the light. Yeah, I'm glad
too. And I think I was. At some point I was doing something
with Jackel. I can't remember what it was now, and I was trying
to integrate web back with it, and I was losing the will to live
because integrating web back with Jackyl is not for the fainthearted. And while I
was just googling around, I think I found because at the time, bridge
down is marketed as like a Ruby powered web back aware stat excite generator,
and I just stumbled upon this thing and I was like, Okay, here
you go. Here's another tale that thinks it's better than Jackuler. I was
very unimpressed, just because of my skeptical, pessimistic nature, but it kind
of stuck in my brain. And then a few days later I got so
fed up as let me go give this an actual try, and I just
installed Bridgetown and that's when I realized it's actually a fok of Jackals. And
when I installed it and created a site, everything was super familiar. And
to get my old Jackal site to work, all I needed to do is
copy the files over and and that was it because it was just a fork
and the directory structure was so similar. I could get up and running with
Bridgetown super fast, and I was like, working, this is pretty cool,
and I just started customizing it in ways that I wanted. So I
think, yeah, when when I first used it, it was it had
SASS by default. But I was getting into post CSS at the time,
and I was I was reluctant to use a full blown preprocessor because even at
the time, I could see how good vanilla CSS was becoming, and I
liked the whole concert of post CSS where it just kind of lets you right
next generation CSS today, kind of like a babble kind of thing. So
Bridgetown had no support for post CSS. I customized my template to kind of
add it in there. I made a few other changes just start a personal
preference, and I wrote a blog post saying, I really love this new
tail Bridgetown. There's some things out of the box I didn't like. Say
here all the things I made like, I made to change it to my
liking, and I shed that around the Bridgetown community. I think at the
time they had a discourse and a discord and so I just shared it around
there. And I got a reply from Jarrett saying, if you wanted to
make a pull request for any of these things, we'd be happy to accept
it. So I pulled requests some of the stuff back, like I think
post CSS and stuff kind of remember now. But I made three or four
pull requests back into the Reaper from customizations I'd made just for myself, and
I just kind of got involved with issues. I was through us, commenting
on issues, commenting on pull requests, giving my opinion, just getting involved
with the community. And then I got a message from Jared one day.
And I should mentioned him a few times already. A Jared White is the
person who started Bridgetown back in April twenty twenty. He forked it from Jackyl
because of his own frustrations with Jackyl and it's kind of lack of progress.
And it was basically him and another guy, Connor Rogers, who's quite well
known in like front end circles, who were on the core team when I
joined. And yeah, I just got a message out of the blue from
Jared saying I really like a contributions or would you consider joining the core team?
And like, hell, yeah, why not? So yeah, that's
how I ended up on the core team. My contributions have been largely selfish,
I think, apart from maybe one or two things, I think literally
everything I've contributed has been stuff I wanted for myself, which is one way
of getting involved in open source. But I was also careful that I didn't
want to I didn't want to get tired of it. I didn't want to
start resenting the project because I'm freelancer. I don't have a job that has
a consistent paycheck coming in. Whatever I do on open sources stuff where I
could be building a client, but I'm not building a client. I'm doing
my own stuff instead, So it needed to be very much something that comes
from within. So that's why my contributions tend to go in in spurts,
like There'll be a couple of months where I'll make tons of contribution, then
I'll go a few months without making any. But behind the scenes, I'm
always like supporting Jared and the core team with decisions and things like that.
So yeah, my role is a bit weird with the project in the sense
that kind of there but not always there. It's very much a choose your
own involvement kind of thing, right, But Yeah, that's how I ended
up, and that's on the core team, and that's kind of like the
role that I play within it at the moment. I love that too,
because yeah, you start contributing in Yeah, yeah, that's the best way
to get involved with any project, right, he just start contributing. See
where that goes. And actually, another point I should make is my freelance
career is what I have is very much, well slightly indirectly thanks to Bridgetown,
because I was I had no contacts in the Ruby community whatsoever. And
I just ended up on the Bridgetown care team in December twenty twenty And it
was around jan twenty twenty one when I was trying to start freelancing and finding
clients and stuff like that, and wasn't really making much of a headway.
But there was someone who I had gotten contact through my work on Bridgetown,
was a chap named Mike Rogers, who is sadly no longer with us,
but he was also a contributor in Bridgetown and I had just got I'd got
in contact with him through my work on the project, and he retweeted someone
looking for Ruby and Rails freelancers and I think he sent that tweet directly to
me as well, because he knew I was looking for freelance work. And
I replied to that message and that was how I got my first contract,
which got me started with Rails freelancing. And it's been like it's always getting
a first clients always the hardest, right, And I was with that client
for well over a year. I'm still in touch with them. I'm still
like good good friends with them. And yes, I think Bridgetown was instrumental
in giving me a freelance career. That's the power of open source. All
right, Well, anything else we want to go into Valentino, No,
I think we've said it all. I mean, I be honest, I
didn't know much about Bridgetown before today. It looks awesome. It solves you
know, it solves a little bit more problems than my original solution of middleman.
So I'm excited to try this out in my next static project for sure.
Cool glad to hear it. Yeah, if you're travel you can always
reach out to me for help. And yeah, we just want to try
and make it as simple as possible to get started with static sites and have
the advanced functionality there when you need it. So yeah, I don't know
a whole lot about Middleman, but I can say with a fair amount of
certainty that you'd be happy with Bridge time. You know, it's funny,
there's a lot of similarities in some of the design decisions. I imagine some
some were pulled, you know, maybe copied. And that's great because you
know why repurpose. I rebuild it from scratch, and it does from from
my example of as a you know, Middleman user, it makes it easier.
Yeah, uh but yeah, I mean I love all of the you
know, you can have like data files that allow you to like use some
uh you know data objects in reference in your templates and gives you all of
the how to host static files and all that stuff is built in and yeah,
yeah that's actually stuffed. We just inherited from Jackel. Actually we just
that's like those conceptual decisions we just inherited from Jacqueline. They're good decisions,
so we just stuck with them. Like why change it if it if it
ain't broke right, Maybe maybe Middleman also stole it from Jack could be yeah
maybe, Yeah, I mean, like this whole just the whole ecosystem of
static side generators. Jackel is what kicked it all off, So I'm not
surprised that such a far reaching effect. Yeah, I'm curious if Middleman is
a fork of Jeckyll as well. It really wouldn't surprise me. I don't
think it is, but yeah, if it was. I don't think it
is either, but it wouldn't shock me if it were. Well, I'm
gonna push this into the picks Valentino, Why don't you start us off with
picks? Sure? Uh, yeah, I've got uh two picks today.
Last week I was at the uh there was a Ruby AI meet up in
New York City that I attended. It was awesome. It was hosted by
a company called sub Layer, which, if you're not familiar, is an
awesome company, awesome product Subplayer. They basically give you like some code generation
in a Ruby ecosystem, and they provide some awesome tools. I've been experimenting
with their blueprints, which basically let you save like code snippets as AI generation
like seeds. So if you have like common patterns that you use in all
of your applications or your teams, you can get AI to clone those patterns
and say, oh, I want a service object or I want, you
know, a factory or all these different patterns that evolve over time and you
can get it to code it in whatever styles that you have. So it's
really neat and yeah, I just had a ton of great people there.
Uh. My next pick is, uh from the Olympia chat team. Uh.
If you're not familiar, Olympia is like a you know, AI robots
on steroids. Uh. You basically get like a team of assistants that have
various purposes. Uh. So you can have a copywriter, you can have
marketing strategists, like all these different kinds of very specific assistance. Uh.
And there's just like so many incredible features in it, and they just keep
pumping it out. Like as an example, when I was, you know,
about to attend the uh you know event in New York City, I
just said, hey, here's a list of attendees, Like tell me who
I should like be connecting with, right like, and it goes and it
summarizes all the people and it was it was. It's just a fantastic tool.
Uh. Do you want to do research or even sense e neils for
you if you want, which is kind of wild, and all of the
systems can talk to each other. I could talk endlessly about it, but
I think we'll have popeyon soon so we can dig get in there. Actually,
oh awesome, Yeah, I'm looking forward to that. All right,
are you? What are your picks? So I've got one pick, which
is going to be pretty alien for I think most people in America, but
it's a thing that's happening in America. The Cricket twenty twenty World Cup starts
on Saturday in the United States and West Indies and the first match is USA
VERSUS Canada and Dallas, Texas. I know cricket's not a thing at all
in America, but given that the World Cup's happening there, and it's shortened
the form of the game. I mean, the traditional form lasts for five
days and only muppets like me enjoy that, but this is more like it's
a three and a half hour vision, way more fast paced. And I'm
aware of the popularity of another spot in America, which involves throwing a hard
ball and whacking it with the wooden stick and then chasing it around, and
cricket is basically the same thing. It's also chucking the hardball, whacking it
with the wooden stick and then chasing it around. So yeah, I don't
know if you're vaguely interested. Cricket World Cup starts on Saturday in America and
the biggest, I think one of the most valuable sporting events in the world
is India versus Pakistan at cricket and that's happening in New York City. They've
built like a temporary stadium in Central Park which can hold something like kind of
twenty five thirty thousand people or something like that, and it's primarily built for
the India verus Pakistan matches, like the flagship match, and they wanted to
have that in America. So that'll be interesting to see how that goes.
But yeah, that's my pick cool. And by cool, I mean it's
cricket. But okay, well, I mean, I mean, you like
baseball out there in America. I mean, crickets are not that different.
I don't follow baseball. So it's funny because this seems to be like a
new, like recurring thing because I know, like I was in Nashville and
they had like a you know, not the World Cup, but they had
like an international soccer event like where they built, uh, you know about
all the locals you know that you talk to, oh, like you know
what's happening down there, and they, you know, they're like some soccer
thing. I don't know, but but you know, it was packed.
It was like, this is funny, Yeah it is. I'd be I'd
be really curious to know, like when that India Pakistan match happens in New
York. I think it's just gonna be largely immigrants from those two countries.
I'd be absolutely astonished. And there are any like Americans there? All right,
Hey, look there three Americans in here. All right, all right,
I'm gonna put out a couple of picks. So I was doing a
board game pick. The one that I've been playing lately is Legendary, Marvel
Legendary. It's I've picked it before, but the other day we were playing
with one of the expand we have like six or seven of the expansions,
and the one that we were playing was the World War Hulk expansion, and
so Legendary has a board game geek weight of two point four to three.
So it's you know, people can pick it up not terribly outside the range
of you know, what you'd expect from a competitive game. The World War
Hulk Expansion has a board game Geek weight of two point three to three,
so it's slightly less complicated than regular Legendary And uh yeah, I mean it's
comic book characters, right, So you you have comic book heroes you recruit,
and then you have comic book villains that you're trying to defeat, and
they have some scheme that they're trying to accomplish, and so you're playing against
the game. And anyway, it's really fun. I really enjoy it.
It is a collaborative game, deck building game. And so I'm gonna I'm
gonna pick that a couple of other things that I'm gonna pick really quickly.
I don't know if I picked vat ruby yesterday we talked a lot a little
bit about Webpacker here, but I've been using vat Ruby and I'm liking it.
Is it blast me to say that I like it better than h Important
Maps and prop Shaft anyway, No, it's not really. I haven't used
reeat, but I mean important Maps and yes, but they're all quite frustratings.
I wouldn't be surprised. Yeah, there's a tool that does something better
than them. Yeah, vat is like magic, and I get the hot
module reloading that I want and everything else out of it. So I'm pretty
happy with it. And this setup wasn't heinous, so I'm gonna pick that.
I'm also gonna pick another gem at standard RB, which is the It's
a I think it's built on top of rubocop, but it essentially just does
your linting on your Ruby and it just follows a set like. You can't
configure it. It just gives you your linting, which honestly, I don't
want to make those decisions, right, So I've been pretty happy with that
as well. And then yeah, I guess the last pick is just Ruby
Geniuses. Go check it out rubygeniuses dot com. I'm still kind of bolting
some of the pieces together, but if you want to get together with other
rubyists and see what they're doing and see what's happening and get trained by people
you know, then definitely check it out. Yeah those are my picks.
This is awesome, are USh? Yeah thanks for letting me ramble on again.
That's two weeks in a row now it's just been me talking. That's
all good. Yeah, Yeah, trial by fire going on. But yeah,
it's good fun. It's yeah, it's just good to talk about Bridgetown
because, honestly, I think I just I find it a bit sad how
few people in the Ruby community are even aware that it exists. It's good
to chat about it, all right, Well, so next time, folks. Maxill