Middleman and Static Site Generators

Welcome back, everyone. This is The ChangeLog. I'm your host, Adam Stacoviak. This is episode 169.

And on today's show, we're talking to Thomas Reynolds, the maker of Middleman. We wanted to have this conversation for quite a while. We're Rubyists at our core here at The ChangeLog, and we use Middleman every single week to ship ChangeLog Weekly. We built that in Middleman.

We're also building another site for Beyond Code in Middleman. Check that out at beyondcode.tv. That's our brief interview series we shoot at conferences after parties. But Rubyists at our core here at The ChangeLog, we love Middleman.

Great conversation today with Thomas. We have three awesome sponsors, CodeChip, Toptal, and DigitalOcean. Our first sponsor for the show is CodeChip. They've launched a brand new feature called Organizations.

And I've talked to several teams who love this new feature because now you can create teams, set permissions for specific team members, and improve collaboration in your continuous delivery workflows. You can maintain centralized control over your organization's projects and teams with this brand new feature. Save 20% off any premium plan you choose for three months by using the code THECHANGELOGPODCAST. Again, that code is THECHANGELOGPODCAST.

You'll save 20% off any premium plan you choose for three months at codechip.comslashthechangelog to get started. And now on to the show. All right, we're back. We've got a great show lined up for you today.

We have been wanting to talk about Middleman forever. And when I say forever, it's like the sandlot forever. I've been using Middleman for a long time. Jared, how about you?

Have you been using Middleman for a while? Actually, my first time with Middleman was when you brought me in on ChangeLog Weekly. Okay, so that was... Which was maybe six or seven months ago.

Well, luckily we have a new season coming up lately. Yeah. So we got Thomas Reynolds on the line here. He is the creator of Middleman.

Thomas, say what's up. Hey, how you doing, all? So you're the Technical Director at Instrument. It's an independent digital creative agency.

Is that your thing or somebody else's thing? That's somebody else's thing. We're a company of about 100, 110 people in Portland, Oregon. We're all centrally located.

No remote workers. And we just do really high-end digital marketing. Nice, man. Also the creator of Middleman and a foodie, book nerd, writer, and obviously a Rubyist because you couldn't be the creator of Middleman without being a Rubyist first, right?

Yeah, doesn't happen accidentally. So for those listening, Middleman is a Ruby gem. It's a static site generator. And how long has it been around, Thomas?

In its current stable form, it's been out for three years. I just checked on GitHub. Time since first commit in the repo is just a little over seven years. Wow.

I was gonna say, it feels like so long. Ancient open-source roots at this point. Yeah, definitely. If you get past five, it's getting into the...

It's like the carter or something classic. Yeah, no, it's like marriage. Like, it's just, I wake up every day and I do it, and I keep doing it every single day. And it'll always probably be here with me.

There you go. So before we kick off the full-on show and dive deep into Middleman, let's figure out who you are a bit. Kind of give us a bit about who you are. You already mentioned Instrument and the things you do there.

So kind of give us a bit about your history and who you are as a software developer. Yeah, so I've been in software development and mostly agency stuff for about 16 years now. I got started really young. Kind of grew up with the internet and was able to, you know, be a kid in high school and actually contribute to open source and also, you know, to just fan sites and stuff.

So I got my start programming, making levels for TIE Fighter, the flight sim video game from PC way back in the day. And then I moved from there to like fan sites for that. And eventually it was like, oh, hey, I need to learn this SQL thing. Hey, I need to learn this HTML, whatever, 3 or whatever it was back then.

So yeah, I got my start just doing super nerdy stuff on the internet. Did that for a couple of years and I went off to school for a CS degree and then realized I was writing less code at school than I had been in my own free time. So I kind of dropped out, switched to like a liberal, a more liberal degree and just, you know, with a lot of reading, which was a lot more fun for me. And then put my passion back into software development on like the open source side.

Since becoming a full grown adult, I've been doing agency stuff now. So boy, probably like eight to 10 years, pretty much nonstop. So I've never really done any product stuff. I've never really done any startup stuff.

I just kind of like the heavy churn and like frequent new kinds of ideas that you have to do like in an agency lifestyle. You ever got the itch, the startup itch? Uh, no, not really. I'm from Portland.

You get away from that stuff. So I'm happy. I'm happy. Just, I don't know.

I like doing new things. I probably get a little bit bored other than middleman. I tend to like discard side projects. So yeah.

So we got Thomas Reynolds online here. He is the creator of Middleman. Thomas, say what's up? Hey, how are you doing all?

So you're the technical director at Instrument. It's an independent digital creative agency. Is that your thing or is somebody else's thing? That's someone else's thing.

We're a company of about a hundred, 110 people in Portland, Oregon. We're all centrally located. No remote workers. And we just do really high end digital marketing.

Nice man. Also the creator of Middleman and a foodie, book nerd, writer, and obviously a Rubyist because you couldn't be the creator of Middleman without being a Rubyist first, right? Yeah, doesn't happen accidentally. So for those listening, Middleman is a Ruby gem.

It's a static site generator. And how long has it been around, Thomas? In its current stable form, it's been out for three years. I just checked on GitHub.

Time since first commit in the repo is just a little over seven years. Wow. That's it feels like so long. Ancient open source roots at this point.

Yeah, definitely. If you get past five, it's getting into the, it's like the car or something classic. Yeah, no, it's like marriage. Like it's just, I wake up every day and I do it and I keep doing it every single day and then it'll always probably be here with me.

There you go. So before we kick off the full-on show and dive deep into Middleman, let's figure out who you are a bit. Kind of give us a bit about who you are. You already mentioned Instrument and the things you do there.

So kind of give us a bit about your history and who you are as a software developer. Yeah, so, I've been in software development and mostly agency stuff for about 16 years now. I got started really young. Kind of grew up with the internet and was able to, you know, be a kid in high school and actually contribute to open source and also, you know, to just fan sites and stuff.

So I got my start programming, making levels for TIE Fighter, the flight sim video game from PC way back in the day. And then I moved from there to like fan sites for that. And eventually it was like, oh, hey, I need to learn this SQL thing. Hey, I need to learn this HTML, whatever 3 or whatever it was back then.

So yeah, I got my start just like just doing super nerdy stuff on the internet. Did that for a couple of years and I went off to school for a CS degree and then realized I was writing less code at school than I had been in my own free time. So I kind of dropped out, switched to like a liberal, a more liberal degree and just, you know, with a lot of reading, which was a lot more fun for me. And then put my passion back into software development on like the open source side.

Since becoming a full grown adult, I've been doing agency stuff now for, oh boy, probably like eight to 10 years, pretty much nonstop. So I've never really done any product stuff. I've never really done any startup stuff. I just kind of like the heavy churn and like frequent new kinds of ideas that you have to do, like in an agency lifestyle.

You ever got the itch, the startup itch? No, not really. I'm in Portland. You get away from that stuff.

So I'm happy. I'm happy. Just, I don't know. I like doing new things.

I probably get a little bit bored. Other than Middleman. I tend to like discard side projects. So, yeah.

So we got Thomas Reynolds on the line here. He is the creator of Middleman. Thomas, say what's up. Hey, how you doing, all?

So you're the technical director at Instrument. It's an independent digital creative agency. Is that your thing or somebody else's thing? That's somebody else's thing.

We're a company of about a hundred, 110 people in Portland, Oregon. We're all centrally located. No remote workers. And we just do really high-end digital marketing.

Nice, man. Also the creator of Middleman and a foodie, book nerd, writer, and obviously a Rubyist because you couldn't be the creator I gotta imagine a lot of that's playing back into your full-time. A little bit. I pretty much do nothing but JavaScript on my day job.

I manage a team of people as well. But, you know, for the most part, I tried to, I had tried to keep the two separate. You know, I didn't want to, like, you know, I made this thing, therefore we should use it, especially before it got enough popularity to kind of justify that kind of stuff. So I've always just kind of left it on the side if people ask about it in like Slack or something.

I'll be like, oh yeah, I know how that thing works. But yeah, maybe in the last year, we actually have been hiring people and they've come in the door knowing it. So now we do tend to use it on a lot more projects. And I'm a little more hands-on with like actually adding features or, you know, fixing specific bugs from people in-house.

So you said the original crux that was sort of, originally somewhat of a fork of Staticmatic, the problems initially were, you know, HTML email driven. Is that when it was, that was obviously Middleman version 1. How has Middleman changed over the years in terms of the problems it's been solving and the evolving problems it's been solving? Yeah, so I just looked, you know, 1 and 2 were these kind of small releases that I don't know how many people were actually using it.

Probably people who moved on from Staticmatic. There's also a period of time where Jekyll went completely unmaintained other than like the Octopress work that was happening. So I think got a lot of people from there. But I just looked it up and we've been on the stable, current stable branch since 2012.

I think that's when it really kind of took off. And that's when I was also doing Rails stuff on the side and I wanted to align the two kind of workflows. So rather than just being like, it's a whole separate tool, I wanted it to be like conceptually, you could come directly over from Rails and then, you know, you can just make a static site or you can put a static site in your Rails if you want to like keep, you know, one piece separate or a little more secure. So yeah, I think version 3 was like the big leap forward, built it on top of some of the Murb stuff, which eventually became into Rails.

But I used a lot of other tooling. We still use internally for a lot of our code, the Padrino library. That's like a Sinatra-like for Rails. And then whenever we have like a discussion on API, we try to go check out Rails API and make sure we're keeping things as similar as possible so we can bring people over from the rest of the Ruby community.

Do you mean things like rendering partials, different helpers that are available in Rails that people sort of, some people can just simply copy and paste views potentially back into a Rails app? Yeah, I mean, we still have like a huge reliance on YAML for like configuration. We have all the helpers, like you said, like your normal link helpers, your localization helpers, we bring over directly. We support, I think, every templating language that could possibly exist in some fashion.

So definitely all the Ruby stuff, most of the JavaScript stuff, pretty much any language that can be, you know, shelled out to and come back, we support that. Very cool. So there have been tons of these tools over the years. We've mentioned a few here.

I think there was one called Stasis. There's been a lot of them. Webby was one. I think I used Webby back in the day.

All Ruby tools. And yet Middleman was that? Serve? Serve.

I don't know that one. It's not being maintained now, but it was one that was one that John Long had mentioned. We talked about that on the Octopus show with with Mathis. Very cool.

So Middleman has stood out from the crowd. It's kind of been more successful. It's gotten more. It's obviously been sustained longer, but it has more excitement around it.

More people using it. Big players like Thoughtbot. And there's a couple more on your website that I can't think about right now. MailChimp.

MailChimp, thank you. So can you attribute that to anything in particular? Was it, you know, pure luck or is there something about Middleman that stands out from the crowd? Yeah, I actually think I have a kind of different opinion about open source from the rest, at least the modern kind of JavaScript crowd, which I don't think things should be throwaway.

I think there's responsibility attached to saying, you know, I want you to spend your days and hopefully not your nights coding with my thing. And that, you know, it kind of sucks when you have to maintain that for years and years and years. But that's like the bargain you're making by publicly saying, hey, go use my thing. I put it on GitHub.

So I think what I contribute most of the Middleman success to is basically stability and respect for people's time. So, you know, we've been at 3.0 stable for a little over three years now and the APIs are pretty much the same. If you can make a site like a year ago, it's gonna be exactly the same now. Things aren't going to change under your feet and you're just gonna have like a stable platform.

It's not that complicated. The things we do are pretty self-contained. So we just do those things well and get out of your way as quickly as possible. And we've done it for three years.

So, you know, there wasn't like, oh, I got to switch. And there will be soon. But there wasn't like, I got to switch to the Rails 4 rewrite. Like, what am I gonna do with myself?

I'm glad you said that because that's actually an issue I've had with the static generators over the years is that I would build something, let's say a one off, simple static site for somebody and then have to go back and like make an update or something like that to it. And then, you know, building it locally or something like that becomes an issue because the latest version breaks things. And then I got to spend another hour or so trying to fix things or link to helpers or just weird things have changed in the APIs of like the little things. And the stability to me was a big thing for Middleman because I'd gone through Staticmatic and several others.

And then finally, you know, I'm using something like Middleman, you know, almost every time I do something static, unless it's actually really static and never having to deal with those those issues where I don't touch it for six months and it's still the same. You know, I just run it. Yeah, we want to fight that whole hype churn cycle. Like there's no reason for that.

There's so few really revolutionary ideas. And you know what? I like, you know, take the Ember community's stance on it. Like if they're really revolutionary, we'll fold it in and we'll do it stably slowly over time and we'll document it well.

But I'm not going to jump on the hype train, you know, and break your site from a year ago. It's great. We have tools like Bundler now that kind of protect us from a lot of that kind of, you know, come back to a thing six months later and it's not working anymore. But, you know, you should also be able to do bundle update and not have your entire world explode.

I like that. So you have this commitment to reliability and stability and you've been doing that over the years. That's pretty rare in open source. Very.

And so I wonder, like, what, why? Like, what do you get out of it? I don't know what I get out of it. Inertia.

I like doing it. I don't know. So we have a couple of community outlets from Middleman. So there's like public chat channels.

There's a public forum. What else is there? I don't remember. There was an email group at some point.

But basically, I don't go there. Like I set up these systems for the community to, you know, self-help. And then I only responds on GitHub pull requests or Twitter harassment. And I think that's also another thing.

Like if you're just in the trenches there, like, you know, managing the forum day in, day out, I think it'll. And, you know, you get to see people telling you that you kind of ruined their weekend because you wrote some bad bug. I think it maybe drags on you a little bit more. But I try to keep myself completely separate from that.

And people in the community have stepped up and been those kind of like community leaders. And it all works out for everyone. Now look at the forum now. It's pretty active.

I mean, a lot of people in there. I mean, I'm not diving into a lot of these notes here, but I'm just scrolling this endless scroll. A lot of stuff. A lot of stuff happened.

Yeah, a lot of that is just holes in documentation where all of our documentations on GitHub is all community contributed to. So I did like a bunch of the big chunks of initial writing, but it's all kind of maintained itself through people, you know, not quite being able to parse a sentence or, you know, I'm not making the right point that they're trying to get to or, you know, put something on the wrong page. But you're never gonna be able to document everything. Again, kind of like the Ember model.

I went with like a plain text tutorial style for my documentation as opposed to API docs, which are a little more provide better coverage, but are kind of harder to understand if you don't know what's going on I found some clients through Toptal and it hasn't been that hard to find because they have a lot of choice. And even more than that, there's enough choice and I can actually be a little selective about what kinds of things I want to be working on. So I use that as a way to sort of hone my skills and go towards the technologies I think are worth investing in for the future. So whether it's including new front-end frameworks or doing a little DevOps work on the side, I usually am able to find clients who have the needs of the things I want to get better at.

So that's been truly useful. All right, that was Daniel Lazant, a listener of the ChangeLog and also a freelance software developer with Toptal. If you want to follow in Daniel's footsteps, go to Toptal.com slash developers. That's T-O-P-T-A-L dot com slash developers to learn more about what Toptal is all about and tell them the ChangeLog sent you.

All right, everybody, we're back speaking with Thomas Reynolds about Middleman. And Thomas, you've been working on Middleman 4 for a while now. You've recently published a blog post entitled My Weird Ruby, wherein you say over the past year, I've been rewriting large portions of the Middleman codebase to better reflect how I like to write code. As opposed to the silly version of mine.

Oh, typo. Typo exposed. Breaking news here on ChangeLog. There's a typo in a blog post.

As opposed to the silly version of the old person six years ago. So you've been rewriting a lot since you've learned things. You've changed your style and that's kind of dramatically affected the Middleman codebase. Can you speak to that?

Yeah, absolutely. So kind of like I said, I do a lot of JavaScript at work. I do Ruby for Middleman. I have done Clojure.

I have done Java and got into some Haskell. And I like to try as many different languages as possible. And, you know, there's always good ideas you can bring them all back. So I can write another post later and call my weird JavaScript because it's equally silly, but it's kind of got the same gist.

Yeah, like when I started Middleman, Ruby was getting popular, but Ruby is also kind of a minefield of features. Some great stuff in there. There's some stuff you should never, ever use. I think, you know, like Rails 2 had a bunch of these like just mix-ins forever or, you know, duck typing and all these kind of very famously Ruby features that you probably wouldn't want to use in production like message.

Yeah, that was a good one. Yeah, so, you know, that's how Middleman 2 looked like. That's how Middleman 3 pretty much looks like with some more inspiration from Rails 3, which has a lot more of it's kind of, they have a completely crazy mix-in inheritance chain thing that's still in there that I don't understand. But that's what it looks like Rails.

But, you know, it's been two, three years since that stable version. I've just been making bug fixes on there. And then I spend most of my day doing other languages. So I've just come up with a bunch of things, seen a bunch of things on other languages that I like and I want to bring them back.

So every time I would fix a bug in the stable branch of Middleman, I would realize that this could have been solved. Like I would have, if I just used something from Haskell, if I just used something from Clojure, this would never have been a problem. So I think the biggest one for me is maturing as a developer and deciding that I actually do like static typing. And, you know, all the loose typing of Ruby was a really big selling point when it was first coming out because people are coming out of the Java world and such.

But you know what? Those things caught bugs. They caught bugs without writing tests. And I think being able to type your code, especially public code that other people are going to want to interact with as like a public API, is a really good approach.

So I discovered this library about a year ago called Contracts, which uses a lot of metaprogramming magic to wrap every single variable and every single method with like a little wrapper and then you define what kind of things should go into the function and what kind of things are coming out of the function. And this little wrapper will check them and throw exceptions if you're in like dev mode or test mode. And so that just allows you to say, you know, there's a lot of places where in Middleman and in Ruby, you say, here's a method, it's called, you know, I'm looking at one here, find. It could take a symbol.

It could take a string. It could try to like turn those two into the same thing. It could take a regex. You never know.

And there's a lot of these kind of like open magical APIs throughout Rails in the Ruby world. I guess I didn't like that very much. So I went whole hog with this Contracts library and I added type information to every single variable and definition inside of my Middleman code. And what that gave me was an insane number of bug reports that my test suite, my test suite of, you know, something like 4,200 tests didn't catch.

Just like, and people were probably saying, oh yeah, like I know to put a symbol here. They don't know to put a symbol here. And the amount of documentation didn't need to figure that out. It's just, they're never going to look it up.

So that was like the first big refactor to Middleman 4. And it's completely, you know, opaque to the user. That's just for me, so I can catch bugs earlier. And so I feel a little safer when I'm working with this relatively large code base.

So that just begs the question, you know, you're basically adding like static type checking to Ruby. I guess, why not just, you know, try a different language? Yeah, that's just back to my stability thing. I mean, the roots are in the community.

My contributors speak Ruby. The big rewrite is always a terrible idea, especially if you're switching languages. You might as well just start a whole new thing. Now I've done a lot of work.

It's not a tiny code base, doing a lot of weird stuff. I feel like if I could, I would maybe have rewritten it in Clojure, but then at the time, getting Clojure up and running was kind of a pain. Nowadays, I think you can just run it right through Node, which is pretty cool. But at the time, it wasn't the best fit.

There have been rumors, you know, of gradual typing being added to future versions of Ruby. So this may be a feature that I just switch to the official support that comes down the road. I've never heard of this Contracts library. Can you tell me where it's at or talk about it a bit?

It's just called Contracts.Ruby. It's a little hard to find, but it's... I think that's the name. It's really hard to search for.

Yeah, so like it's not really typing. It's just designed by contracts concept, which is basically lightly enforced types. Like things will still work. It will be able to complain about it.

So I don't know where it came from, but the gentleman who runs it has started updating it a lot more recently. And there's third-party contributors adding code to it now. So it seems like it's kind of gaining a little popularity. I would never use it in production.

The whole point of this thing is, you know, it throws an exception during your test suite, not, you know, when someone's actually trying to use your code. Is this something to do part of Jared? Well, I heard of it in March when I read his blog post, but I haven't heard of it elsewhere. Okay, gotcha.

Yeah, so it's active. That's great. When I was using it, it actually was inactive. It would just been like an experiment that someone had put together.

So a little bit risky, but it's pretty easy to comment out. It's just every single one of these definitions starts with the keyword contract. It's a pretty easy search and replace to go back to the old buggy version. But I found I really enjoy it.

I'm looking to decorators in JavaScript to add some more functionality on the JavaScript side so I can add some type information, have a confidence test suite. So Evan and I are in a bit of a unique position because we have a site which we use to generate our weekly newsletter, Changelog Weekly, which is a Middleman 3 site. And we've also been working on a new site for our video series Beyond Code, which is a Middleman 4 site because I hopped on the beta because I like pain, I guess. Actually, that hasn't been too painful.

A few things. I can definitely attest to the fact that this Contracts piece is completely invisible to an end user because I would have never even known about it had it not been for this post. One thing I have felt as an end user is you've also introduced a lot of immutable data structures. Can you speak about that?

And then maybe I can give you a little bit of feedback from my perspective. Yeah, that also just comes from my experience in these kind of more functional languages. They tend to prevent a large class of bugs just because you're not doing weird loops and that much stuff. One bug we got a lot back in the day was we have this directory of data files and there's YAML information in it.

And so from the templating side, you can go ahead and say, you know, grab the first five people from this YAML file. And people would then go add another person to that array and then expect it to persist and also expect it to somehow sync You know, I just remember like you're on the plane and like the kiosk crashes with a Windows warning. I'd dread the day when I see like JavaScript crashed in Chrome as like my airplane warning. I think it's probably one of the worst languages you have to use on a reasonable basis.

So I would not, I would, I would go Ruby before JavaScript in a lot of cases for similar tasks, like task running or, you know, exactly something like middleman. So that leads me into the question about these about this, the front-end framework. So middleman seems like it could be a decent generator for an app that is an Ember or a Angular based, you know, back client. Is that the case or should you use their tools directly for these kind of things?

That's a good question. I would probably just say use their tools. The Ember command line tool is really, really good. It's really, really focused.

And, you know, if you're not writing a ton of HTML, you know, we don't solve a lot of problems for you. And if you're all client side, then we're not solving your routing or like your file structure problems for you either. So probably use their tools. But, you know, where we succeed now and we're seeing a lot of heavy usage is large like these blogs, these large documentation sites, a lot of like this kind of generated content from some other source.

So you have a file of Markdown files and you want a full localized documentation site. So, you know, people like Basho and Nest and a bunch of all these, you know, MailChimp build these large documentation portals kind of on middleman because they can just do a couple of loops, do a couple templates and get these large, large sites up the side. That said, I'm still trying to use it for my front-end work as well. So version four, probably the biggest feature that I use on a daily basis is this ability to run sub processes inside of middleman.

So basically what you say is I want you to boot up the Ember CLI web server and I want you to proxy from middleman to that. So if two thirds of your site and all of your CSS is in middleman, then you Ember returns JavaScript and we all just build this one cohesive whole. So I've been using Webpack a lot just because Webpack and Babel give me some nice tools on the front end to use modern JavaScript. And then that just fills kind of like the sprockets role in my middleman stack and then everything else is still middleman.

So we're experimenting with that. It's actually working pretty smoothly. Any other major middleman core features? I know a lot of it has been pulling out old cruft.

Is there, is there anything else that you're excited about for the new version? There's some light stuff. We switched to a Rails style environment split. So before you just had, you know, are you building?

Are you devving? Now it's like, do you want to build for staging? Do you want to build for hotfix branch? Do you want to build for production?

So that gives a little bit more control for multiple environments, for testing environments and. You know, using stuff like Travis to deploy builds that maybe not ready to go into production. The other big one, I think, is moving all of our base templating stuff to GitHub. So before you'd have to install a Ruby gem outside of Fundler, hope it's there globally and then initialize it through middleman.

Now you just give it a GitHub path or any Git path, and it'll just pull down that whole repo as like your starter template for a new project. And then it'll run your custom code. So it's a lot more similar to like Yeoman where we let everyone manage their own stuff rather than having to go through our like kind of Ruby gem pipeline. Do you think it's an issue since you mentioned, you know, who might be using middleman and what language we talked about languages and, you know, choices and whatnot is the fact that middleman is a Ruby gem.

Does that stop people from using it? Those who care about languages. Is there, is there competitors to middleman in other languages that sort of make you think, man, I kind of they're stealing my thunder here. Yeah.

I mean, the install setup story for Ruby has always been pretty hard. It's still really, really bad on windows. So yeah, it's kind of, it's kind of sucks. You know, the trade-off is this is a tool you use for work.

It's important. It's going to save you time. So spend the 30 minutes necessary to get your Ruby gem set up. But yeah, that's not great.

There's one in go. What was that called Jared? It's like a Hugo. It's like a Hugo.

Yeah. Super jealous of that because they get because go gets compiled to a single or not single, but it compiles to multi-platform binaries. So you just drag this file on your hard drive and everything's perfect. I'm not going to be right for that, but that's a pretty cool feature.

And then now this, the ubiquity of node gives something like a metalsmith or a couple of the other node ones. It feels more natural for a front person to install those libraries now or they probably already have node installed. Because if your audience is a designer or a front-end person, then you're a front. If you're coming from NPM, you're already in their world basically.

You're already in the tool set. Yeah. There's no change there. And I always wondered if, if Ruby would hurt you over time, considering that the people that are writing Rails apps typically aren't building middleman sites.

I guess Jared's an anomaly potentially, but it's typically somebody that's, you know, more of a front-end player than a back-end player. Right. Yeah. I mean, totally.

I think a lot of people do come from Rails and then we also have a lot of people who classify themselves as designers, but they can obviously code. And for them, they don't, they didn't pick a side on the language wars. So they don't really care if they're installing NPM or Node or Ruby. I think just on the Windows side, I think nodes first class support for Windows from the very beginning was a huge boon for its adoption.

I think that that served it really well. And I think Ruby's always had issues on Windows and, you know, there's been huge efforts to improve that, but it's always like after the fact, you know, it's kind of like a security practice. You can't just bolt security on afterwards onto your software. It has to be something that you think of from day one.

And it seems like, you know, cross-platform support is another one of those things that once you don't prioritize it early on, it's just really hard to get right later. I think the Ruby community has always suffered a bit from that. Yeah. I, as an aside, I just built a gaming PC for myself and I haven't been using windows for about a decade now.

So I'm recently back in the flow of everything on the window sites. Like I can actually test bugs now. It's amazing. But like everything sucks over here.

I just tried to install like simple things and it's taking me like 15 clicks and I can't find the links. And like I get why, you know, it's just brew install Node is so easy. And like that, unless without some support from Microsoft, that'll never be, you know, a thing you can do on Windows. So there's always going to be, I think a barrier, which is kind of unfortunate, but I would love to see better Windows support from Ruby.

That's a hard, hard job. So I guess some questions about the core team and just how you formed the people that helped make middleman possible, but let's take a note from Jerry. We do have to take a quick sponsor break. So let's take that break real quick.

When we come back, let's talk a bit about the core team and start telling into some of our closing questions, which I'm sure that the internet is just dying to hear. So we'll take a break and we'll be back. I have yet to meet a single person who doesn't love Digital Ocean. If you've tried Digital Ocean, you know how awesome it is.

And here at the change log, everything we have runs on blazing fast SSD cloud servers from Digital Ocean. And I want you to use the code change log when you sign up today to get a free month, run a server with one gig of ram and 30 gigs of SSD drive space totally for free on digital ocean. Use the code change log. Again, that code is change log.

Use that when you sign up for a new account, head to digital ocean.com to sign up and tell them the change log sent you. All right, we're back with Thomas Reynolds, maker of middleman, been talking through quite a bit of history of static site generators, a bit of, uh, you know, go love there where you're, you're trying to figure out a good way to say that, but just like some, some impressedness, if that's a, that's a thing to say from you towards the community about the way they're doing things too. And I'm kind of curious on that note before we go into the core team thoughts and whatnot, but I'm curious if, um, if you were building a middleman today and it was ground zero, what would you build it in? That's a great question.

I would probably go with probably, uh, where I would build it. And I actually, I have some negative thoughts about go, such as their dependency management requiring Git, which is a little weird. But, uh, other than that, it's just, it's a really slim language and their whole goal is to have one way of doing everything. And that kind of aligns with, you know, a lot of the, uh, frustration from Ruby of having like on my own.

I think that exploring also helps me, you know, avoid getting burnt out or avoid just having this fear that I don't want to look at my own code anymore. Like you have to nip that in the bud. You have to refactor as soon as you start hating your own code. You can't just let it be there forever because you'll never go back.

That's interesting. We've, like I said, we talked about burnout several times on the show and it just seemed to me during the show that you've, you've, whether you've tried to purposefully or not, you've found something to avoid the burnout. Mhm. And Jerry, we had that call on curl, 17 years of curl.

I mean, that guy was like two hours a day. Um, and there's a commitment there. There's a commitment. Yeah, on average, two hours a day for 17 years.

That's like a long time. That's incredible. And it seems like somehow you've you've found um the secret to not getting burnt out. Yeah, that must just be my personality.

I've also been at the same job for like almost five or six years now too. Just, I don't know, walk away. You can always walk away. You can come back.

Just don't burn any bridges and just know, I've always known that I intend to support this for the long term. So, you know, again, keeping myself from burning out is super important to that. Right, and I said that guy met Daniel Sternberg. I always forget people's names.

I gotta go back on the list and look them up and not be offensive to people, but Daniel's pretty awesome. Shout out to Daniel. There was just uh that article going around by, I forget what library he was a developer of, but he's, you know, giving up active development because there's no money in it and try as he might, like, you know, people aren't getting rich off his work and he's not able, you know, to work this as a full-time job. Um, but I think it frustrates anyone at a high level in open source.

Some people are able to have like such a crucial piece that they can monetize it through support or, you know, contracting or even these special feature levels. It's kind of like a sidekick is a really good example. Um, but yeah, so, you know, I like working. I do agency work because I like to work, so I'd like to be on the beach where people use middleman, but I'm also probably just gonna go back to work next weekend.

Well, now's about the, uh, the time we turned over to our super awesome ending show questions. Um, the first question, I don't know, Joe, do you want to take it or me take it? Go for it, bro. This is the easy one.

Uh, maybe not. Maybe this is the easy one to ask. The easy one to ask. It's always easy to ask, right?

Yeah. So Thomas, you've been doing community for quite a while. I can't imagine that over these years you've, you've uh, got a list of people, whether you've made it purposefully or not, they're your heroes. Who out there in the programming world is your hero?

Um, yeah, I think I mentioned, I mean, as a group, I think the ember team has been spectacular. I think I really respect those, uh, all those folks for, you know, having a commitment to stability, having a commitment to documentation, um, and really guiding their community as like there's other bunch of shiny things around just basically saying, you know, we're gonna keep getting better and we're not going anywhere. Uh, their documentation has been, uh, an example I try to follow and their community management is even way, way better than mine. Uh, so that whole team is absolutely amazing.

Um, yudakats is a, you know, he's a, he's a Ruby master. They use a middleman over there at Tilda. And I just kind of asked if you never look at my Ruby for fear of the look, the look of, uh, yeah, I should probably give up Ruby now and never do it again. Uh, but that whole group is awesome.

Very cool. Next up we mentioned contracts. We mentioned hamster. These are some Ruby gems that have kind of been not just on your radar, but in your toolkit lately.

But if you had a free weekend and you were going to go hack on some stuff, um, what projects have you excited? What's on your radar of cool open source projects that you want to check out? Uh, so I've been using Pixie.js, which is a front-end library for doing 2d graphics in WebGL. I've been using that at work and using that on the side.

And it's just this kind of, you know, flash-like layer that allows you to get back all kinds of amazing interaction and effects on the front end. So I would definitely go throw together some kind of crazy 3D experiment. Um, the whole project is open source and that whole team is also doing a great job of moving their project forward. Very interesting.

Pixie is the fastest kitten found as they say. Okay. That's amazing. And it's, you know, uh, every single time I have to fight with a browser to animate like a square, I get super angry and just want to throw the whole DOM and the whole browser out the window.

Um, so if I can find refuge in WebGL or find refuge in a, in a tool like that and pretend Flash still exists, uh, you know, that comforts me at night. Awesome. Uh, so for those out there that have listened to the show, you know, maybe they're like me and they've been following Middleman for years and they're new and they just met you for the first time here on the show. Um, and they want to help out.

They want to kind of dig in a little bit to Middleman. What's what the call to arms to the community, whether they're new to Middleman or not new to Middleman in ways they can step in and either look at version four or help out on the community. What are some ways to step in as the community can do to help out Middleman? Yeah, so I've always recommended that people just write about it or talk about it, you know, tweet about it, write about it, talk about it.

Um, everyone's going to have a unique use case. They're going to have a unique perspective and that all doesn't fit into the core documentation. So the more people, you know, I try to retweet. I can't say that word retweet as many blog posts as I can with these really interesting use cases.

Uh, I'm always surprised. Sometimes I see like middleman extensions that I would have never ever imagined could be written. And it's just really awesome to see. So, uh, the more you can just Google your question and you get an actual answer or even like a stack overflow answer, uh, the better it is for everyone.

You mentioned extensions. That's something we didn't really dive too deeply into the show about because this isn't a comprehensive show. Like here's what middleman is. Um, but maybe we can take a minute to mention the extensions of the project templates and the different deployment options you have.

I mean, you've got tons of extensions there made by the community. Some I can imagine are commissioned. Some that are just there because somebody needed it. And then you can also search those extensions as well.

So it's pretty easy to sort of limit down to some things you want. Like let's say you want to deploy with onto AWS. There's, there's extension for that. Yeah, absolutely.

Uh, that was something, you know, even in the Rails days, like the ability to have these plugins, these extensions was super powerful to take the load off the core team. So I've tried to follow that example. Uh, one of my philosophies with Middleman, which is pretty different for most static generators is, uh, we want you to write code. It may not be very complicated Ruby, but at least you have all the tools and the power that code gives you to make your dreams, you know, real.

We don't want to be like one of these generators that all you have is one config file or one JSON file and try to like fit your entire stack, your entire pipeline into, you know, that really rigorous structure. So as part of that, uh, we farm out as much information, as much API stuff as we can to the extension API and now let people do, you know, pretty much whatever they want. They can hook into most parts of the process. They can replace parts of the process.

They can hook into new project template generation. They can hook in and just, you know, add a single file to the page or to the site that doesn't exist. Like, you know, do an API request, get that bundle back, make that a static API resource here. There's all kinds of really good extensions because we've opened up as much uh Ruby access as possible to the extension libraries.

Cool. So yeah, some of the great ones. Um, deploy middleman deploy, which one of the core team members is actually the lead on. We'll deploy to everything.

You want to go to GitHub pages. You want to go to AWS. You want to go, you know, to any CDN. It's all built into that one package.

Um, but you don't have to worry about that. You don't have to talk to an ops guy. You can just get your website on the line. Very cool.

I'm hoping that one's been four compatible at this point. Yeah. So that's me slowly realizing that, uh, I'll go look at like third party extensions. Like, why did that break?

Like in my mind, I made no breaking API changes. So there's like a, you know, Ruby makes it relatively