Aaron & Colleen from Hammerstone

Andrew

This is remote Ruby.

Colleen

Have you any remote ideas

Aaron

to the

Colleen

meaning of the word?

Jason

Yo. Oh my gosh. Alright?

Andrew

Yeah. I couldn't press the recording now. Got it button.

Jason

Oh, got it. No pun intended. We're Christopher List today.

Andrew

Yes. He is in the ether somewhere.

Jason

He's probably, hopefully, almost to my house. I would not rule out him actually, like, joining us before it's over. But

Andrew

Feel like Chris is not a fast driver. That's my impression of him.

Jason

That's interesting. Because he does have one of those, like, minis that are, like I don't know how to describe it.

Andrew

Like, from the Italian job?

Jason

Not from the Italian Job, but what do they call, like, the John Cooper? They're the decked out ones. I think he has one of those. I'm gonna sound like a

Andrew

real idiot if he doesn't. But Well, no one will ever know if he doesn't.

Jason

That's true. But no. I guess Chris is like an average driver. Maybe Chris just likes the option to go fast.

Andrew

Okay. Like Ricky Bobby.

Jason

Yeah. I wanna go fast.

Andrew

Yeah. I understand the desire and need to go fast. You have a home? I have a home. That's where my heart is.

Oh, my sweet god. Yeah. Since I'm on my chest.

Jason

This is boring me. Let's move on. So we have special guests today. We have Colleen and Aaron from Hammerstone. And I feel like there's a lot of things both of you, like, together and individually are involved in.

So I'm going to let you introduce yourselves, and I'm going to start with Colleen.

Colleen

Alright. Well, I'm super pumped to be here to chat with you guys today. My name is Colleen. As you said, I am a Rails developer and consultant, and I have 2 products. I have simple file upload dot com, which is predominantly a Heroku add on, and then cofounder of hammerstone.dev, which is the visual query builder, which is pretty awesome.

Jason

Fantastic. And Aaron, how about you, my friend?

Aaron

Yeah. Thanks for having me. My name is Aaron. And like Colleen said, we're cofounders at Hammerstone. I also have a full time job at a little company called Tuple that you guys might have heard of.

So, yeah, I am a Laravel developer and so I'm excited to be here and talk about Rails and Laravel. But, yeah, we're working together. Colleen and I are working together on a query builder for both ecosystems. And, yeah, just excited to be here, talk databases, query builders, whatever you guys wanna talk about.

Andrew

Tuple, is that like a Ray thing in Python. Right?

Aaron

Yeah. Yeah. Yeah. Exactly.

Andrew

So Okay. Cool. Just wanna make sure.

Jason

Scrape your it's something collectiony. I like it. It's a numeral. So let's see here. Where do we start?

So we were just at rails comp together. I'm treading here because I don't wanna bring up any any bad vibes. Bring it up. But y'all had a workshop around, like, advanced active record. And I know there are some WiFi troubles, but let's maybe chat about what that workshop was about and, like, some of the things you're covering in it.

Colleen

Yeah. So the purpose of the workshop was actually to kind of introduce Rails developers to AREL, which sits between active record and your database, and it's really what powers active record. So kind of what happened, it's kind of a really interesting genesis of how this all came out. Aaron had originally built the query builder in Laravel, which is PHP?

Aaron

Yes. It's PHP. You should

Andrew

know that by now. I do. I want proofreading work. I wanted to know too. Thank you for asking.

Colleen

And the constructs of the language are just very different than the constructs of the way we write Ruby. And so we tried very hard to keep basically the architecture of how this thing works the same. I kept bumping up against these edges with active record. It just wasn't powerful enough to build out SQL fragments the way I needed them, but I didn't want to actually use SQL strings because one of the things about the query builder that's so great is you can use it for whatever database. So that is how I got introduced to Arial and just started, like, really getting into it.

And it's a really cool API.

Jason

That's cool. We've talked, like, a 100 times about this, but it finally just clicked with me why you would want to use strings for that because you're supporting multiple databases. The thing I'm usually locked into is, like, we just use Postgres at work. So, like, I just always use Postgres. I don't even consider that other databases exist.

So maybe for those listening who aren't super familiar with AREL, would you mind maybe just kinda giving a high level overview of, like we know it sits between, like, active record and the database. What are some of the things that it gives us?

Colleen

So ARAL is an abstract syntax tree. And from a very high level, what that means is it builds out these nodes, and then it puts the nodes together to form your SQL. So you always start with, like, your AREL table, which is gonna be your model back table. But what is so interesting about it is you get this incredible granularity with SQL. So if you think of active record, if you do contact where name equals name Colleen, you're gonna get select contact where name is Colleen.

But there's no way in active record to actually break that into 2 pieces. So you can't separate the select statement from what you are trying to select, which means you don't really have as much control over the keys. And so what we were finding since we were building up these queries, Averill gives you the power to just get that little SQL query fragment, and then as you are building up so our query builder little bit of a step aside here, but our query builder is really powerful because it can walk through your models, like, all of your attributes and nested models. So we have this, like, recursive situation where we basically put these nodes together. And because we're able to separate the full, like, kind of what you get from active record from just a SQL fragment, we're able to control how you build those nodes when you come out of the recursion.

Jason

Cool. So, like, we have AREL and active record. For the Laravel side of that, are you having to rely on any kind of external libraries? Or does what Laravel give you handle everything you need?

Aaron

Fortunately, it handles everything we need. But it is in a little bit different way. So we don't have the concept of ARL. We don't have an abstract syntax tree that drives our rim, which is called Eloquent. But there are 2 levels in Laravel as well.

So there's the Eloquent ORM builder, and then underneath that, there's a base, like, database query builder. And so we have 2 different levels as well. But in Laravel, what we're finding is so, like, Colleen is building up nodes and kind of passing the nodes around. What I'm doing is I'm just basically passing the query builder object around. So I'm passing a reference to the query as it is built in the life cycle of the query builder, if that makes sense.

So if a user says, I want people named Aaron that live in Texas and are over the age of 30, we go through that row by row by row, and we bind the user's input in. And in Laravel, I'm passing the bound query object around and binding new stuff into it as we go. So I'm not building nodes. I'm just building on to a query object.

Jason

I'm trying to, with my very limited knowledge, figure out which one is easier to work with, if there is one between the 2.

Colleen

This is such an interesting question. And I think, Aaron, the big difference we found is in Laravel, the where statement takes a closure or something like

Aaron

that? The where statement can take a closure. So instead of saying, you know, where name equals Aaron, you can pass in a closure or a callback in some languages, and you can do some more complicated stuff inside the callback. So our Eloquent builder, our active record implementation is extremely powerful and flexible in that you can basically pass closures around anywhere you want. And so we use that to kind of do some of the more low level stuff.

So instead of saying name equals Aaron, we actually in a closure that's bound with the user's input to be executed later. So we have a little bit more flexibility, I think, than Colleen was finding with active record.

Jason

What I hear is what I just wanted to be affirmed, and that is Laravel has everything, but we can save that for another podcast.

Andrew

I'm having a life crisis now that you've now that you've explained this.

Jason

So both of these query builders for their perspective frameworks, where kind of are y'all in the process of launching each side?

Colleen

So for Rails, we're actually already doing a presale, and we've actually sold a couple licenses to people that strongly feel this pain. And we're gonna start integrating in customer apps in a couple weeks. So we're there. Like, we're done.

Jason

Alright.

Colleen

It's really exciting. Yeah. It's super cool.

Aaron

On the Laravel side, we have some people using it in their apps already. So we've been in this spot for a long time. So what we offer is a back end component which in our world is called like a composer package, and you also start to believe a gem. And then we have front end packages that speak the exact same data transfer language. So we have a React front end, we have a Vue 2 and a Vue 3 front end, and we have a Hotwire front end.

And we've been in this world for a while where the front ends are not configurable enough to match people's apps, and so they would get it installed and be like, hey. It works great. It doesn't look anything like my app. It's like, well, you have to eject all of the components and recreate it all yourself. It's like, that's never gonna work.

And so our very first sale on the Laravel side ran into that, and so we've been working pretty hard to make it customizable on the front end. And just this week, actually just yesterday, I had a call with him and showed him the new front end and he was like, this is perfect, and I saw him tweet today that he was shipping it to production already. So we have several people who have bought one of our plugins that works in an admin interface and he's the first one that bought and is using the full on Laravel Vue 2 totally customizable thing. So we're shipping, and it feels so much better now to have that kinda out the door and into production.

Andrew

Did you use, like, CSS variables to make it customizable or did you kind of go with a more manual approach?

Aaron

That is a good question. So the problem is we have this giant nested recursive generative UI. So on the back end, when you say name equals Aaron, you're telling the front end put a text field there. And when you're saying framework is Rails or Laravel, you're telling the front end put a drop down there. And so we kinda have to control the whole thing, and so we end up with this massive set of nested components.

So the question What we do now What we do now is, because it is all full on front end frameworks, is we wrap everything in a renderless component. So all of our individual components are wrapped in renderless components. So that now in the life cycle, we're looking up as a renderless component is being rendered, we're looking up in a theme object what classes they wanna use for it. If they wanna swap out the actual Vue or React component, we let them do that, and we give them a couple other hooks that they can, like, use to customize it. And so we now have this concept of a theme object, and then all of our libraries, Vue 2, 3, and React, all are inspecting this theme object as they're rendering.

Andrew

I just I'm always interested in how people are kinda shipping these, like, customizable things because I have to customize something. If you give me something, I'm going to customize it. So I'm always curious how, like, developers are building up these systems where customizability is, like, forefront. And so that's cool. That's really interesting.

Jason

Are y'all able to share the front end libraries between both the rails and Laravel 1, or are they actually shipping separately?

Colleen

The answer is yes. But we have Hotwire Turbo, Vue, and React. So we should be able to use all of those front ends in Rails.

Aaron

And then on the Laravel side, we're obviously not using Hotwire. But, yeah, the v2, v3, and React all actually live in the same monorepo, and we've been working with some incredible contractors who have been helping us build that out. And those libraries actually share some type definitions, which is over my head, but they all work not only together with each other, like Vue 2, Vue 3, and React all kinda share a core, but they all speak the same language and Laravel and Rails emit the same JSON that the front ends are expecting, and they talk back and forth the same way. So yeah. Cool.

Jason

Yeah. I feel like that would be a tricky thing to get started with, but something that could pay, like, huge dividends as you continue to build upon it. For the Rails side, are you mounting a Rails engine to access the query builder? How does one access it once it's in the app?

Colleen

So right now, it's an NPM package and a Ruby Gem, and then then it's there.

Jason

Okay. Do you have to, like, mount it or anything to access the query builder, or how does all that work on the rail side?

Colleen

No. No. I mean, you have to there's so what it does is we keep the state on the front end. If you're using Hotwire Turbo, which is a little different than we had to make some customizations to get it to work with Hotwire Turbo, so it's a little different than the other front ends. But we managed to stay mostly on the front end, so we just publish, like, the filter is saved, the filter is unstable, the filter is stable.

So then you as the develop you integrate it. You can do whatever you want once you have the filter. So you just render it as a turbo frame. It's just render the turbo frame. So that's how you physically are able to see it by rendering the turbo, and then you just listen for the events in your stimulus controllers.

Aaron

And it may be helpful to explain, like, what we ship to the end developer. So I think on both Colleen and my side, what the end developer so, like, if y'all were integrating refine into your app, what you would end up with is a base class, you would end up with an abstract class that we wrote that you would extend. So our class is just called filter or whatever, and then you would write user filter, product filter, company filter. And in those filters, you would tell us, like, what's the starting point? And usually, it's just like the user table or the contacts table, but you can add scoping if you want, whatever.

So you tell us what the starting point is, and then you tell us which attributes should we expose to your end users. So you say, well, first name, last name, number of projects, referral source, that kind of thing. And then you've extended our base class with your class, implemented those few methods, and then all the data that goes out to the front end, our front end will pick up on it and build that interface for them.

Jason

That makes sense. Cool. Thank you for explaining that. So it may be a little early to ask this question, but I am also curious what it's like trying to, like, maintain feature parity between the 2. Has that been a problem yet, or are we still kinda, like, early on, we haven't experienced that as much?

Colleen

That's a good question. I think what's interesting is we have myself, we have Aaron, we have 3 contractors. So we have a lot of people kind of working on this, and I do think it's something we're trying to be really diligent about because right now, I'm building it out for a big client as a consulting project. So I'm adding features really quickly. And so making sure, like, everyone both packages are up to date.

It's definitely an interesting challenge.

Aaron

Yeah. It's a lot of fun to, like, be able to develop all of these things together, but there is a little bit of coordination complexity, especially from my point of view, especially between the back ends and front ends. So then you start thinking about the different versionings, right? So you have a Laravel version, a Rails version, and a front end version, and they all have to always speak the same language. So that data transfer objects that we're sending back and forth always has to work, and you have to start thinking about backwards compatibility and stuff like that.

So feature parity between Colleen and I is not so bad. I think feature parity between the front ends and the back ends, that's been a little bit harder. And it's possible to do graceful upgrades where, like, some things work on the back end that don't yet work on the front end. It's just you can't go the other way around. Everything that used to work on the front end has to continue to work on the back end because you don't know what version of the library the people are using on the front end.

And so that's something that I'm thinking a lot about is like versioning. How do do we do the back ends and the front ends major version together? So do we make a commitment to our people that version 1 of Laravel is always gonna work with version 1 of Vue? And if we do a major of Laravel, we have to do a major of all the front ends, and we should definitely do a major of rails at the same time. So, I don't know.

It's a lot of coordination complexity. Some of it has been fun so far. I don't know. It's a lot of coordination complexity. Some of it has been fun so far.

I think some of it will be a nightmare, but I don't think we're quite there yet.

Jason

Yeah. That's interesting considering, like, does a new version of Laravel come out and change something structurally important to it? Do you then have to release a new major version? And rails is on a different schedule. That is that does sound fun and a nightmare, like, all in one.

So I'm excited to hear how that works.

Andrew

Just so you know, I want them all the same version. That would be what I want. Well, that would make more sense to me because, especially in Rails, I'm used to upgrading a gem, and then also if it has a corresponding NPM package, they're usually the same version. If they're not the same version, this happened a lot with the webpacker days where people would upgrade the gem, and they're like, I don't understand it's not working. And that's because they forgot to upgrade the NPM package to the same version.

To me, and I feel like to a lot of other people who I've discussed this with, it's a lot more clear when they both just need to be the same version. And so there's no question of, like, oh, well, the gem got upgraded, but the NPM version is the same. When is that gonna get upgraded?

Colleen

Yeah. That's great feedback. So, basically, you're saying, if I upgraded the gem, even if the NPM package didn't change, I should still version it so they're exactly the same. If it's 1.1, it should be 1 yes. That's good.

Aaron

Does that apply to majors or minors as well? So if your Ruby Gem, say, is on 2.1 and your React NPM is on 2.0, does that make you nervous or are you fine with a major being the same and a minor being different?

Andrew

I think it would be fine with it, but it would make more sense to me if they were the same in my brain. Because it was just like it feels like less to juggle it. Yeah. As soon as reflex does it.

Jason

And it makes it easy because they've had some not major, but heavy changes, even like 3.1 to 3.2. And it is nice just knowing, like, I'm just gonna upgrade both, and I don't have to question if there's a difference in the 2. Right. And they do as well is when you install the gym, like, with bundle install, it actually spits out a message, make sure you've upgraded to or you have the matching version NPM. Yeah.

It's a nice little touch.

Andrew

I guess if you didn't want to have them in the same version, that, like, after install message could be the place where, like, okay. Just so you know, like, this gem version is compatible with this NPM version and up.

Aaron

Smart. We could totally do that as well. Yeah. This is really helpful. Thanks for saying that.

Colleen

That's good feedback.

Andrew

Cool. I'll send you guys a bill.

Jason

So I wanna take even another step backwards. So how did we end up in a place where you're both working on a product for 2 different frameworks? I would be curious, kinda just hear the beginnings of Refine. And how y'all met? How did this start?

Aaron

Yeah. So the beginnings of Refine started at an old day job that I had, and I got it specifically excluded from my employment agreement because I thought this is something I think I could do for a long, long time. And so it started because I was at this company and people kept asking for more and more power when filtering the data. So it was a property tax company, and they would be like, hey, can you show us all of our clients that are in Dallas County and the assessed value is under 300,000 and our fee rate is 40%. And I'd be like, I mean, yeah, I gotta build a new piece of UI every time you come and ask me for that, or I have to run it manually myself.

And I didn't wanna run these things all the time. And so I kept adding more and more form fields, and they kept asking for more. You know, the more you give them, the more they want. And so finally, I was like, I'm just gonna bite the bullet and make a flexible query builder. And so that's kind of where it started.

And then I extracted it, rewrote the whole thing multiple times now, actually. And now we have this general query builder that can be used for basically any purposes with a much nicer developer interface than the one that I originally wrote. And so I was working on this, and, actually, a friend of Colleen and my our our friend Sean started working on it with us. And so he and I were working on it for a while, and we got interest from a big client in the Ruby world. So a friend of ours knew that Sean and I were working on this and came to us and said, Hey, I met this client, they really need a query builder.

Can y'all do it for them? And I was like, man, this thing is written in Laravel and you're talking about a Rails client. It's like, yeah, yeah, yeah, I know. They'll pay you to do it and then you get to keep the IP. So what if you just came over and kind of ported it from Laravel to rails?

And Sean and I were like, I mean, I guess so. Like, we wanted to end up with 2 versions, so why not do it on someone else's dime? So we needed to find a contractor, and Colleen was the contractor. And we had met, I think, a few years before at a little bootstrap retreat conference kind of thing. And so we pulled Colleen in and worked with her for about a year, and I'll let her tell the story.

But I think the problem just just deeply embedded itself in Colleen's brain and she learned to love this recursive generative madness. And so since then, Sean got this amazing job that he loves and has decided to step back. And so it's me and Colleen and she's full on cofounder. She switched from she still works at that big client, but she and I are the 2 cofounders now, and that's kind of the origin story. Did I miss anything, Colleen?

Colleen

That's pretty good. I think some of the kind of funny points here is I think when they first hired me as a I was originally just as a normal consultant, we thought this was not gonna be a big deal. Like, we're like, oh, porting me from Laravel to rails? How hard can that be? It was in fact a big deal.

So I think it was really fun and kinda crazy. And some of the stuff like, this whole thing we were talking about earlier with this accepting a callback and these where clauses, that caused me a lot of stress. And the problem just kept getting more and more interesting and more and more complicated. And dealing with big data and like how do we solve these issues. And it was just great fun, and I was really into it.

And also funny, like, I didn't know Aaron. I had met you once for, like, 10 minutes, kinda like, high five. Nice to meet you. So it was kind of a big step to go from consulting for someone you don't know to founding a company with them. But I think we got to know each other better while we were working together while I was building out the product, and it was just so much fun.

Like, what more can you ask for in life than to build something that's fun with people you enjoy? I think launching a product like this with 1, 2, 3, 4, 5 different repos is a whole thing. Maybe wasn't

Aaron

Don't do it. Don't do it.

Colleen

The most yeah. Don't do it. So it certainly has complicated the situation having 2 back ends and 3 front ends, but we're having a good time.

Aaron

The first time that Colleen DM'd me one morning and she said, hey. So I was thinking about query builder last night while I was walking, and I was like, yeah, you were. We gotcha. I know you were thinking about it. It's fun, isn't it?

She's like, yeah. I just can't, like, I just can't stop thinking about this one problem. Welcome. So good to have you.

Jason

That rules. I think that's a great story, and I think it's cool because I've got the chance to hang out with both of you. And, like, it's always fun. So I think it's cool that you get to experience that, like, working together.

Chris

I I just wanna take a minute to thank our sponsor, Honeybadger. They are not only my favorite error and uptime monitoring service, but they've also added several awesome new features, one of those being the public status pages. So it makes perfect sense that your error and uptime monitoring tool can have a public status page for you to communicate any downtime outages with your customers. So whether US east 1 is down or you forgot to add a configuration file, Honeybadger is there for you to help communicate any downtime or outages with your customers. Plus, they've also added SSL certificate monitoring.

So like many of us use these days, Let's Encrypt certificates expire every 90 days. And if for some reason you're a week away from expiring an SSL certificate, they can let you know ahead of time so that you can take care of it without any outages for your customers. Plus, managing the errors and things inside of Honeybadger has gotten even easier with Honeybadger actions, which you can use to automatically assign errors to yourself or another team member, add tags to different error classes, and more. And they also have batch actions, which you can use on the search results to help manage your backlog of work to do. So Honeybadger is the place to check out for error and uptime monitoring, and it's only getting better.

So check them out at honeybadger.io.

Jason

I do want to shift gears a little bit and actually talk about some products you both have separately, if that would be cool. First, with a simple file upload. So you were saying it's a predominantly kind of use with Heroku, but how long have you been working on simple file upload, kind of? What does it do? Where did it come from?

We'd love to hear that.

Colleen

Yeah. Awesome. Yeah. So I've had SimpleFile upload, I think, for a little over a year. Okay.

I've been selling it for a little over a year. I've been working on it a lot longer than that. Sure. Everyone who has a side project appreciates how that goes. You're like, oh, I have this idea.

I'm gonna work on it a little bit. So I've been selling it for about a year. It's in the Heroku marketplace. It is also available outside the Heroku marketplace. And I mean, it's literally that.

It's like a file uploader that you can add to your site just by adding one line of JavaScript and the class simple file upload to a hidden input.

Jason

Cool. So it's not real specific then. It is actually anything

Colleen

Yeah. At the

Andrew

front end. Anything.

Colleen

Mhmm.

Jason

Yeah. That's amazing.

Colleen

It's a whole different product. Yeah. That's it.

Jason

That's cool. I will say that is a pain point for me or always has been is UI for uploading. The browser, somehow in 2022, still functions like trash when it comes to file uploads. And I feel like I'm reinventing the wheel every time. And so I think that is a cool opportunity to build something for

Colleen

Yeah. And I think that's kinda why I built it because I was independent, and it was like company after company after company needed file uploading. And every time, it was just such a pain. Like, I was just I really think, like, the UI struggles with that. Yeah.

Never have again. Now I can just drop the widget in. I'm good.

Jason

Yes. I built my 2 100th image uploader a couple years ago, and I was really proud of it. And I told myself I'm never gonna do this again. And so now I just try to avoid using images at all costs.

Colleen

There's a solution.

Aaron

Yeah. I'm

Colleen

Just avoid the problem.

Jason

Yeah. I'm really good at that. We built one in house at Podia that's, like, React based, and it's really good for what we need. But there's just there's so many edge cases too with all that. Like, I'm multiple files, single files.

So I think that's I think it's really cool. How has adoption been over the past year?

Colleen

So I have noticed there is a direct correlation to how much I actually market it and how many people actually sign up. So when I first launched it, like, it it shot up really quickly. And I think one of the huge benefits so the service is not just like the uploader. It uploads so basically, you drop a file, it uploads its direct upload to s 3, and it returns to you URL, and it can resize on demand. And I have client side image resizing.

So in the beginning, like, it was phenomenal. It shot up really quickly. And then as I got more and more into Hammerstone, I just didn't have the time. Like, I just 2 side projects and a full time job? No.

It was not.

Jason

Yeah. That's so overwhelming.

Colleen

Yeah. I didn't have time for it, so it's kind of sat for about 6 months pretty stagnant. But I just hired someone to help me with marketing. So I'm pretty excited about that. So is he

Chris

yeah. Is

Jason

he the head of marketing at Tupelo?

Colleen

It's not, but, I know him.

Jason

That's awesome. Yeah. I love that. I'm very much impressed that you've not only shipped 1 product, but 2 products on the side. So all the admiration and applause for me.

And, Aaron, I think you have more than the one I'm about to talk about, but I want to talk about Torchlight because both Andrew and I have used it, swear by it, think it is a bright spot in a very dark world of textile lighting. So we've talked about the podcast before, but maybe for those who haven't heard that episode, would you maybe mind just kinda same thing? What does Torchlight do kind of how you've been working on it? Where did you get the idea? All that good stuff.

Aaron

Yeah. Sure. So Torchlight is a syntax highlighter. I mean, that's the basis of it. But it's a little bit different because it is not an in client syntax highlighter.

So it doesn't run-in your browser. And that's a little bit weird because all the other ones do. So highlight. Js, prism, I think those are the 2 biggest ones. Those run-in the browser, and that's usually pretty great.

You're kinda limited there because all the stuff you would have to ship to the browser and the power of the browser to actually do proper getting the code into an AST, they kinda just do regex matching, which, you know, most of the time works great. What Torchlight does is it's a syntax highlighter that lives at a central service, and then I have clients that call out to that API. So it's an API that does syntax highlighting. And so I've got couple different types of Laravel clients, I've got a standalone CLI, I've got some JavaScript stuff. And the power that you can get when you're actually running on a server or in node.

It runs on Vercel, so it's serverless, but it's still in node. The power that you can get is so much more than when you're in a browser. And so what I'm able to do, the Versus Code syntax highlighting stuff is all open source. And so there's some cool packages that add a little bit of scaffolding around that. One of them is called Shiki.

And Shiki is a node only syntax highlighter. You can get it in the browser, but it's massive and it's Wasm and whatever. So what I did is I took SheikY and added even more around it and put it at an API. And now, depending on the client you use, the client will gather up the code blocks on your site or on the page that's being loaded, send it off to the API, and it will send back highlighted code blocks. And so what that means is every single language the Versus code supports, I can also support with Torchlight.

And it's just a massive number. And so I'm kind of sitting on top of this, like, hugely funded, massively maintained ecosystem. And so when somebody's like, hey, I want this super obscure language. Great. Can you find me the Versus Code plugin that lets that work in Versus Code?

And then I can add that language grammar on the server, and then we're ready to go with highlighting. And so once I got that, like, I feel like step 1 was get the highlighting just right because all these new syntax, all these new language features were coming out in PHP 8, and all of the highlighters were just missing them completely. So you're trying to do these, like, super cool blog posts, these sexy documentation sites and your code highlighting just looks like crap. It's like half of it is bright green and you're like, this is totally wrong and it's incredibly frustrating. And does it matter?

Probably not, but it's super matters. And so I feel like step 1 was get the highlighting right. Just I want it to look like Versus Code. If it works in Versus Code, it should work on my website. And then I realized, wait, this is actually parsing stuff down into tokens that I can inspect along the way.

So it's not just, this is a string that we think is a function. I know exactly what kind of language token this is for every different language that I'm highlighting. And so the next thing I did was I thought, I really want to be able to control Like the reason that I'm using syntax highlighting is because I'm writing a blog post, I'm writing documentation, and each of those has different context. And so if I have a code block and I'm trying to draw attention to a specific line, but still show surrounding context, I wanna highlight that line or I wanna blur the lines behind it. And the solution for every other syntax highlighter that does this is they put some sort of inscrutable characters at the very top.

They'll put 1 comma 3 comma 5, and that's highlight lines 135. But it never says that, you don't know that. And then the other problem is that mucks up your editing. Right? Because if you're writing, let's say you're writing Ruby and the syntax that you use to highlight the lines is not Ruby, now your code block is all weird.

So what I figured out is I can put annotations inside of actual code comments. So if you're writing Ruby, you put a Ruby comment in and you say highlight this line. If you're writing PHP, you put a proper PHP comment in that says highlight this line or this line was deleted and this line was added, so put a red background and a green background. And so now I've got all these different annotations to help you communicate your ideas when you're writing either documentation or blog posts, but it's valid syntax. Like, it's actual Ruby code.

It's actual PHP code. And so I'm parsing out all these comments and taking apart annotations and highlighting it and sending it back so that you can communicate your ideas better, but you don't have to, like it's not a pain to get there. You're not targeting things in a really obscure and painful way.

Jason

Is as absurd as this sounds, even just having syntax highlighting that doesn't, like, flash when my blog post load is I don't know. It just means a lot to me. I think it's a really fantastic idea. And also, I haven't really thought about why I don't really like the other ones besides, like, what I just mentioned. But, yeah, if everything is reg x, okay, PHP has a new version.

Somebody's gotta go update that reg x. If you never update that package, you will never get that new version.

Aaron

Bingo. It's a

Jason

lot of moving parts. What kind of response have you gotten from releasing this product?

Aaron

Yeah. So it's been incredibly positive. I built this because I was super annoyed and petty and thought this should look better. I'm going to make it look better. And then I kinda released it as a thing and people were like, yeah, I really wanna use this.

And that was exciting and it also blew my mind. It's used on larabel.com, which is probably the biggest site. It's used on Fathom Analytics website, Larabelle News, and just dozens of different places that I never would have expected. It's been incredible. As of now, it is a kind of hybrid prepaid thing.

If you're a company, you should pay for it, and if you're just an individual, it's totally free. That is gonna go away. It's all gonna be free, and I'm going to basically try to blitz the market. I feel like and I think every developer feels this way. I feel like I have a technologically superior product to whatever else is out there.

And I don't know that I'm gaining much by charging, I don't know, $14 a month to businesses. And if you want to, as an individual, you can pay $5 a month. Who's that helping? Not me. I mean, I'm never gonna make it on $14 a month.

What I could make it on is owning the entire syntax highlighting mindshare and ecosystem and then doing something interesting with that. So that's the plan. I've gotten a company to redesign the site. I'm working on moving all of the rendering actually to fly dot io because Vercel is good. If I'm gonna make it free and also introduce an option to where you can have a client side highlighting, it still hits the API, but it's gonna be done from the client side in case you can't hook into your static site generator or whatever.

I need to have presence all over the world so that that flash that you mentioned, if somebody does use the client side, is 15 milliseconds and not a 100 because that's not viable. So, yeah, we have a lot of big plans for that. It's gonna be totally free available from the client side, but none of the server side stuff will go away because I think for static sites and for people that wanna hook in to, like, Laravel middleware, Ruby middleware, that kind of thing. I think that's more valuable. And then, hopefully, take over the world.

I mean, that's the plan. We'll see if it works, but that's the plan.

Jason

I think that's not too ambitious. That's good. So I have no experience with serverless. You're talking about, like, serverless functions. And I'm like, yeah, I know that's a thing that exists.

What I'm interested in is if you make the service free, is it very costly to use serverless functions in that type of environment? What's that like?

Aaron

Yeah. Serverless is great. Serverless has drawbacks, of course. So serverless charges for compute, which is fine, but in this situation where the real hang up is if I allow it from the front end, which I'm going to, I can't take advantage of your server side caching. So all of our clients that I have, save a cache on inside your app, so that every time a page loads, you're not hitting the API.

You're only hitting the API for stuff that's stale. On the client side, I can't do that because every request is gonna be coming from a different browser. So now I'm suddenly opening myself up to two orders of magnitude different scale. Once you start doing that kind of scale on something like Vercel, the trade off really becomes ease of use and cost, right? Vercel could handle it without breaking a sweat.

I wouldn't even make a ripple in their pond. They're fine. But the issue then becomes, how much do I wanna pay for that? And so looking at something like Fly, and Fly is globally distributed servers. They own their own hardware, so it doesn't sit on top of AWS or anything that has a private network all between it.

So it's this really weird combo of serverless and serverful. But putting it on fly, I could run servers in Australia, three parts of the US, the UK, South America. I could do all of that for, I don't know, $100 a month or something like that. And they're gonna route all the requests to the most efficient server. That to me is kind of best of both worlds.

I think serverless is fantastic for ease of use. What you gain for ease of use with serverless, you sacrifice in billing predictability. And I don't have unlimited money. Surprise. And so I want a little more billing predictability than I want ease of use.

And Fly kind of splits the difference because it is predictable billing, but it's also pretty easy to use.

Jason

I've seen Fly mentioned a lot. I follow a lot of people in the Elixir world, and I know that FLY has made, like, a pretty big push. Like, I I'm pretty sure it's Chris McCord, creator of Phoenix works there now. So I'm definitely familiar with FLY, and I've never tried it out. But even this conversation, I have no side projects that need to be available at that scale, but I still am like, oh, I wanna try out FLY.

We have an ad I think put on it. Oh, lord. We could we could put Podia on it.

Aaron

I think Kitsy Dodds said that his personal site runs on fly, not for the global availability, just for the ease of deployment and the ease of use. And so one of their hooks is global deployment across actual servers. Another one of their hooks is actually just really easy to use. It's kinda like a new Heroku with targeting maybe one step down in the abstraction chain, maybe.

Jason

That makes sense. Heroku, obviously, a big topic of conversation with developers recently. So this is timely chatter. I had one more question I wanna cover. I guess this one really is more for Aaron.

I'm curious. You're a Laravel developer, but you came to RailsConf. I mean, you actually gave a workshop at RailsConf. You've been hanging out with us Rails developers recently. I'm curious just kind of what your experience has been like coming kind of from the outside world into this.

Yeah. Just general thoughts and experience.

Aaron

Universally positive. Yeah. I mean, I'm totally an outsider to y'all's community. I don't feel quite so much like that anymore now that I've been to RailsConf and met y'all in person. But, yeah, I feel like I have a lot of friends on the rails side.

Obviously, Colleen, Andrew Culver, and several of the people that I've known for a long time have been Rails developers. And then I don't know what happened. Maybe it was Torchlight or something, but I feel like I started to kinda get out of just the Laravel world on Twitter and started to meet some more, like, Jason, you and I had a call about Torchlight a long time ago. And I think that's kind of what started. I started to be introduced to these other people on Twitter.

And so, like, I would see you talking to somebody and I would interject myself or like some tweets or respond to something. And everyone has just been so friendly. When I found that at RailsConf as well, everyone was just extremely kind and pleasant and friendly. I was definitely the fish out of water there, but everyone made me feel super welcome, and it it would have been fine if people, like, kind of made fun of me for being there as, like, a Laravel developer. That would have been a good bit.

I would have gotten the joke and it would have been funny, but everyone was super nice. You're like, hey, we're super glad you're here. I wanna do Laravel. And it's like, oh, wow. Like, people know that I'm a Laravel person because they would say stuff like that, but they're not ribbing me for showing up.

So it's been universally positive. I'm just thrilled to be a part of it and have friends across communities, and y'all have been super welcoming. So way to go, Ruby. Way to go, Rails, I guess.

Andrew

Glad to hear that. Colleen, was he making snide comments about things that Laravel could do the whole time? That's what I really wanna know.

Colleen

No. He wasn't. He was well behaved.

Jason

People aren't making fun of you. I'm not making fun of you because I'm jealous. So that's why I have no side remarks.

Andrew

I wouldn't make fun of you to your face.

Jason

That is that is a true statement.

Aaron

That is of some comfort, I guess.

Andrew

No. I think it's anytime that you have someone of a different I can learn from I can learn from and take inspiration from and introduce into my community or into the work that I'm doing? So I think it was like, oh, Aaron's here. That's super cool that if I had a Laravel, I should I could have asked you. It's not like, oh, this guy, he doesn't understand.

We're over here writing enlightened Ruby. This guy is writing PHP. What the hell? You know? It's only like, what can I learn from this guy?

Aaron

I will say what you just said there is not at least online is not the standard refrain. Anytime you're online and you see somebody talking about PHP, a bunch of people are gonna chime in and say, well, I can't believe Do people still use PHP? Oh, wow. I guess, what a loser. They're still using PHP over at that company.

And so there is a little bit of that of we tool around online and everybody's like, PHP, give me a break. Call me when you pick up something real. And we see that a lot online, but I've never seen that from any of the Ruby people that I know and I didn't get that impression at all in person. So it's just this anonymized like PHP sucks that's out there. And so to not have ever been derided for using PHP by any of y'all, this is a nice place to hang.

I like this place.

Andrew

I also guarantee you that all those people chirping online wouldn't almost the majority would never have said say it to your face. If you're like, I'm a PHP developer. They're not gonna be like, and start going off in your face because why would they? We live in a society. I mean, some of them will for sure, but I don't know.

I think it's just when you're anonymous, you feel like, oh, well, I can be a dick. But we're glad you're here.

Aaron

I'm glad to be here. Thank you.

Jason

Very much so. And I lied. Colleen, I actually have one more thing I wanted to talk about if we have time. Sure. You are a speaker at the SAS Rails conference.

Andrew Colbert announced this past week. And I am just kind of curious if you have some ideas about what you're wanting to talk about at the conference and just kind of your overall excitement for the conference.

Colleen

I am so excited for this conference. So I live in San Diego. So on Thursday, I actually took the train up to LA, which who knew you could do that? Apparently, you can do that. And checked out the venue and checked out LA with Andrew and just had the best time.

The hotel, the venue is gonna be amazing. The whole experience is gonna be top notch. And yeah. So I just started thinking about what I wanna speak on. And the concept of the conference is this intersection between rails and business.

So I am probably going to kind of lean into that and talk about Hammerstone stuff specifically because it's such a good intersection of these two things. Yeah. I'm super pumped. We're gonna have so much fun, Jason. I'm so happy you're speaking too.

Jason

I was really honored. I was, like, taken aback that Andrew would ask me to speak. So we met last Friday and, like, riffed on what I talked about, and we landed on I'll be talking about the rails renaissance, which is Yeah. Yes. I'm really excited about that.

Andrew kind of dropped that phrase, and I was like, I feel like I could do that because, like, Aaron and I had a call one time, like, when you're talking about torchlight, I think we said in the first half hour, I talked about, like, all the things I wish Rails did that Laravel does, but then also, like, now I I see a lot of things that Rails is doing well. So there's a lot for me to talk about to choose from, so I'm really excited about that.

Colleen

Nice. Yeah. I think I want my focus to be, like, inspirational. In terms of, like, you have new people who wanna build businesses, what is the best way to get there? How do you get there as quickly as possible?

And I just think rails provide so much that people who are like, oh, we all know the refrain. Like, people aren't using Rails or everything is JavaScript. Like, they're really missing out on an opportunity.

Jason

You're right. There's a lot of chatter online on the Hacker News Mhmm. Where I see people saying things like, I've been building SaaS apps and node, and I built a rails that the other day, and I just forgot how quick it is or how simple it is. And I don't know that. It warms my heart a little bit.

It's like the feeling people get watching This Is Us. I get reading those comments on Hacker News. They'll be excited I'm excited.

Andrew

I'll be there. Are you?

Colleen

On the same

Andrew

team, but I'll be there.

Colleen

You're gonna be there? Nice.

Andrew

I'll be there. Awesome. Front row. That's my spot. Front row.

Jason

The topic of, like, inspiring people to build businesses is such a fantastic topic. I also think that is part of how rails continues to stay relevant and evolve is people still building things on rails. Like, much like, they're they'll have so many people building SaaS apps and things. And it's very evident to me that, like, a lot of the community, like, not only came from, like, how thought well thought out the framework is, but just it's really Thrive because people are building real businesses. And, yeah.

Yeah. I think it's a wonderful topic.

Colleen

Thanks. I'm just making it up as I sit here and talk to you. But it's not even like building a business. It's like building your life. If you think of how these things are connected, the work you do and how you make money, like, it's building your life.

It's like designing your life the way you want. And software, specifically rails in this case, can, like, help you get there.

Andrew

I kid you not. I just got chills.

Aaron

There you go.

Colleen

Same. Alright. That's the topic then. I'm in.

Jason

Yeah. And I feel like that is a, like, fantastic preview of well, I guess, it's hard to get tickets now, but I

Colleen

was gonna say it's sold out.

Jason

If you find them. Good luck. Well, this has been a fun chat, and I appreciate both of you taking the time to sit down and talk about this myriad of topics. I alluded to it earlier, but I know both of you are on podcasts. I think you have multiple podcasts.

So wanna give you both an opportunity just to maybe share some places people can find you online. Colleen, if you wanna go first.

Colleen

Yeah. So you can find me on Twitter. Best way to find me at leanyburger. And then Aaron and I have a podcast together. That is the Hammerstone Dev Podcast.

And then I have another podcast called Software Social.

Andrew

Which is so good, by the way.

Aaron

Thanks. You can find me on Twitter at Aaron d Francis. I don't know what a leanie burger is, but you can find me at Aaron D Francis on Twitter. And if you wanna hear Colleen and I talk a bunch more, hammerstone.dev/podcast. And then I have another podcast about frameworks.

So it's about Rails and Laravel and Django and Phoenix, and you can find that at frameworkfriends.com. That's me and Andrew Colbert.

Jason

That's a true Awesome. So good. Thanks. Well, again, thank you both for joining us. And Andrew, anything you want to throw into the ether before we burn this to the ground?

Andrew

Go build cool stuff, people.