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