Bullet Train Goes Open-Source

April 6, 2022

Learn more →

Transcript

Aaron
00:00:00 – 00:00:29
Okay. We need to talk about Laravel. Everyone loved the first episode of the show, but I got a handful of DMs saying, Erin, we gotta talk about Andrew's pronunciation of Laravel.
Andrew
00:00:32 – 00:00:58
I caught on to that actually myself just because you listen to the edited podcast that comes back, and I kinda picked up on that. And I'm, like, I have this thing where I do all my a's that way probably because I studied Japanese or whatever, and I still feel like I'm right this minute, I feel like I'm gonna say the word, and I'm gonna say it wrong. Let's see if I can get it right to Laravel. Laravel.
Aaron
00:00:58 – 00:01:02
Yep. Laravel. Laravel. Yeah. That's perfect.
Aaron
00:01:02 – 00:01:17
You're not the first person to do that. You're not the last person to do that. That's been a well, like a well trod path in the Laravel community. I think even Taylor's wife has in her bio, it's pronounced Laravel. Like, she has it phonetically spelled out in her bio.
Aaron
00:01:17 – 00:01:26
I didn't wanna correct you on air and be that bad guy. But then I got a bunch of people DMing me being like, hey, man. What's going on with this Laravel stuff?
Andrew
00:01:26 – 00:01:37
Are you even with us, Aaron? Do your job. No. So let's do it this way. Nobody's gonna have to hear this part when we do it because we have Paul.
Andrew
00:01:38 – 00:01:48
We'll talk about Paul in The Close. But, yeah, every time I say it wrong, just stop me. I'll rerecord it, and Paul will make it all good.
Aaron
00:01:49 – 00:01:57
Every time you say Laravel, he'll put in Laravel, so instead of hearing Laravel, you'll hear Laravel. So it's perfect. Yeah. Exactly. Oh, I see.
Aaron
00:01:57 – 00:01:58
Edit. That sounded so perfect.
Andrew
00:01:59 – 00:02:09
Yeah. Exactly. I'll send him one clip of me saying Laravel, and he'll just he'll paste that over every time I mispronounce it. That is funny. You should've corrected me, Aaron.
Andrew
00:02:09 – 00:02:10
I thought you were my friend.
Aaron
00:02:10 – 00:02:11
I am your friend. That's why
Andrew
00:02:11 – 00:02:12
I corrected
Aaron
00:02:12 – 00:02:18
you now. With that out of the way, you just got back from a conference, Sin City Ruby.
Andrew
00:02:18 – 00:02:32
I did. I was at Sin City Ruby. I actually presented at Sin City Ruby, not the important part of that conference, but it was awesome. I love small conferences, and this was small. It was the first time Jason Sweat.
Andrew
00:02:32 – 00:03:01
He has a podcast called Code with Jason. He also writes great articles in the Ruby ecosystem, and this is the first time he ran this conference. It's a bit of a funny story. I forget the exact details, so I might fudge it here a bit, but I think he had booked the conference room for a workshop or something that he was thinking about running. I forget where it was, if it was RubyConf last year that we had been chatting about that, but he was, like, yeah, I'm thinking about doing this, like, workshop, whatever.
Andrew
00:03:01 – 00:03:17
And so he booked the hotel, booked the conference room, and then for one reason or another decided to pivot, and he still has his conference room. So he's like, I guess I'm doing a Ruby conference. And so Amazing. Yes. And it was amazing.
Andrew
00:03:17 – 00:03:46
So Las Vegas, not my favorite city. Some people love it. Jason Sharnes, in the introduction to his talk, kind of talked about all the incredible life experiences he had had there over the years, but the one thing I do love about Vegas is all the people and all the friendships I've made there over the years. And it's not just Jason's conference this time, but for many years, Mike Taber and Rob Walling's conference, MicroConf, has been run from the Tropicana, and I think there was another hotel in there. I I barely remember it.
Andrew
00:03:46 – 00:04:19
But it was at the Trop for many years. It's not anymore, but that means that I have met and made so many friends in that hotel. And so anytime somebody wants to run something in Vegas, I'm gonna go. That was true this time as well that it's not about Vegas, it's about the people, and it was an absolutely incredible group of folks that were there. So it was the presentations were really good, very high quality, I love a single track conference, and it was awesome.
Andrew
00:04:20 – 00:04:22
In fact, Colleen, your business partner
Aaron
00:04:23 – 00:04:23
Mhmm.
Andrew
00:04:23 – 00:04:27
Gave a presentation there that was absolutely awesome.
Aaron
00:04:27 – 00:04:37
I wanna hear about this. So I saw it go down on Twitter and I was just, like, totally amped for her, and it seemed like it went really well. But tell me, did she crush it?
Andrew
00:04:37 – 00:04:53
Yeah. I mean, Colleen always does. This is for anybody that's a conference organizer, you just get Colleen on the list because Seriously. She overachieves on talk prep. So what she was talking about specifically in this was just getting into the details of AREL.
Andrew
00:04:53 – 00:04:58
She would do a better job of explaining it, obviously, than I would, but it's an abstraction around SQL.
Aaron
00:04:58 – 00:05:07
It is the nodes upon which active record sits. So it's like the more language level that sits on top of SQL but under active record.
Andrew
00:05:07 – 00:05:34
Yes. That's correct. And so, obviously, she's in an upper percentile for sure of folks that have worked with that component because of the work that she's done on the query builder that y'all build. So, yeah, perfect person to give that talk and probably, I would guess that that it is a presentation that put that layer kinda on the radar for a bunch of people. And there were a bunch of talks like that that were just very technical in nature.
Andrew
00:05:35 – 00:06:00
There was stuff about Sidekick and different approaches to managing queuing and things like that. It was a fantastic conference. So big round of applause, I think, for Jason. Everybody really deeply appreciated, I think, what he put together. There are a lot of things right now in the Rails ecosystem that feel like, hey, we're kind of in the midst of a Rails renaissance.
Andrew
00:06:01 – 00:06:27
Really? Absolutely. Yeah. I think it it is. And when you have the group of people that we had together at that conference all hanging out and chatting about our vision for the future of rails and, like, the ecosystem, I I mean, obviously, everybody wasn't there and represented, but just the core group that showed up at that conference, these were the folks like, there was definite excitement, I think, just looking around and being, like, yeah, we've got the people.
Andrew
00:06:27 – 00:06:35
We've got the people and this is just a small subset of them, but these are some great people, so let's go. Let's do this thing.
Aaron
00:06:36 – 00:07:02
That's great. I was following it on Twitter for a number of reasons, but one is I feel like a lot of people that I know and like were there. I feel like I knew probably 30% of the attendees, and they're all, like, super rails people, but I was watching Jason Charms and his coworker, Andrea. I was watching her, I was watching Colleen, I was watching you, Jason Sweat, and I was like, man, this is cool. Like, I'm amped for these people.
Aaron
00:07:02 – 00:07:13
And then I saw Jason Charnes did a video at the end where all the people were, like, cheering and, like, Ruby, and I was, I thought, okay. There's a little bit of energy there. I like to see that. I'm happy for that.
Andrew
00:07:13 – 00:07:22
Yeah. It was a great thing. So I'm appreciative to everybody. We had people traveling in from, like, the Baltic States and Europe. There were folks coming in from the UK.
Andrew
00:07:23 – 00:07:25
Yeah. It was a really great experience.
Aaron
00:07:25 – 00:07:43
So I wanna talk about your presentation as a way to Why? What'd you hear? I heard great things. But what I heard was it was a massive announcement for Bullet Train, a fundamental shift. I saw that you so, we'll get to it in a second, build the anticipation here.
Aaron
00:07:43 – 00:08:00
I saw that you announced it and then you went on Twitter and announced it, and people were just super amped for you, and some were confused because it's a big shift in the Bullet Train story. Tell me about your talk and what you announced, and then we'll dive in a little bit more.
Andrew
00:08:00 – 00:08:45
Yeah. So I had to be a little vague in the title of the talk when Jason reached out because there was no way that I could title the talk without giving away what the whole point of the talk was. But the purpose of the talk and the focus of the talk was just that we had gotten to the point in the bullet train business to basically hit a milestone and a goal that we had been working toward for a long time, and that was making bullet train our SaaS in a box starter kit an open source MIT licensed SaaS framework. So that was it. And so it was really interesting because that's kinda like the thing you don't do when you go to a software conference.
Andrew
00:08:45 – 00:09:01
You don't go to the software conference and be, like, get on the speaking list and then talk about your proprietary thing. Right. So I couldn't bury the lead. I had to basically start the presentation with, hey, I'm here to talk about Bullet Train. Why is that okay?
Andrew
00:09:01 – 00:09:14
Because Bullet Train's this giant open source project now. So you may or may not be familiar with it. Let's just go through and show you what Bullet Train looks like today as part of this release that we're working on. So that was the talk.
Aaron
00:09:14 – 00:09:18
First of all, congratulations on the big release.
Andrew
00:09:18 – 00:09:18
Thank you.
Aaron
00:09:18 – 00:09:48
But that's a great setup to talk about the journey. So, if that's the end, that's present day, I want to go back to the beginning because there's some Laravel lore in the Bullet Train story, as well, and I want to walk through how we ended up here. And then if your whole life is Bullet Train and you just open sourced it, what's the plan moving forward? So, let's start all the way at the beginning and tell me, like, what is bullet train?
Andrew
00:09:49 – 00:10:14
Yeah. So I know we covered this a bit in the last episode when we were just introducing sort of who we are and what we work on. In this context, I think bullet train started it has let's see if I get it right here. Laravel Spark in the DNA. It was inspired by Spark, especially what Spark was at that point in time, which has changed over time.
Andrew
00:10:15 – 00:10:56
And now well, spoiler, Now bullet train is also changing, and it kinda pattern matches the evolution of that specific package. I can only speak to that in a sort of limited sense because I haven't used Spark and I I've only sort of kept a cursory glance on it over the years, but what bullet train started as was a full fledged SaaS in a box. So it was the idea that you needed teams, you needed memberships, you needed authentication, and you needed subscriptions. I would say that is, like, the absolute core of it. In our case, we also wanted to make sure that we had, like, a really slick template so the UI was great out of the box.
Andrew
00:10:56 – 00:12:00
And then almost as soon as I released it, I started getting pulled in the direction of developer aids, developer tooling, developer experience, and that led to the development of super scaffolding, which was basically an alternative path. Probably at that time, I could customize the rail scaffolds or whatever so that it does our templates, but my vision was kind of bigger than that. But I think the important thing to note about that is everything up until that point was very much in the vein of Assassin the Box. And then all of a sudden there was this, like, alternative thing that bullet train was getting pulled in the direction of by its creator, by me, and that was developer tooling. And I think that sort of dual purpose was not necessarily good in the long run.
Andrew
00:12:00 – 00:12:03
And what I mean by that is you're fighting 2 battles.
Aaron
00:12:03 – 00:12:04
Yeah.
Andrew
00:12:04 – 00:12:43
That's all I mean to say by it, is you're not focused on one thing, you're doing 2 things at the same time. And there was probably room for a little bit more differentiation between those two pieces of bullet train, that there's these SaaS in the box features and then there's all this developer experience tooling and stuff that you're trying to do there. So in the current version of Bullet Train now, that is very distinct. So maybe give a little bit of background here because I think you'll be more familiar with it. Maybe lay the groundwork with talking about Spark and then how Spark sort of evolved and some of the other things that came into play?
Aaron
00:12:44 – 00:13:04
Yeah. So originally, and this is years years ago at this point, originally, Spark was a starter kit. That's kind of the general term for it. Spark was a starter kit for Laravel SaaS. And in its original incarnation, it handled a lot more than it does now.
Aaron
00:13:04 – 00:13:49
Some of its functionality has been factored out into a different package called Jetstream, but in its original incarnation, it handled teams and membership, team invitations, billing, changing plans, all of that kind of stuff. And it was a paid product, just like Bullet Train, and it was great. I think what happened is that Taylor realized he was making a lot of decisions in terms of tech stack. He was making a lot of decisions on behalf of his consumers, so the people that bought the product, that kind of forced them into his way of doing things in, basically, Vue. Js, the front end Vue.
Aaron
00:13:50 – 00:14:16
And that made it hard for them to customize, like, the admin interface. And I think it was called Kiosk at the time. It was, like, the place where your customers go to, like, update their profile picture, change their email address, update their billing plan. And so he had this all in one package called Spark, and this is, I don't know, 5 years ago, that did all of these things. It was great, but it was not very flexible.
Aaron
00:14:17 – 00:15:35
It kind of lived as an add on to your app, but it was also your user's admin and settings interface, and so it was a weird mismatch of who controls this, how do I customize it, and, like, how do I, as the developer, buy this thing and get a head start, but then still be able to and split Spark out into what is now more closely akin to a Stripe checkout, but native to your app. And so, you define everything in your app and the Spark landing page or the Spark admin interface is a fully self contained front end. So it doesn't matter if you use React for your app, Spark is still going to use Vue, but you never touch it. It's not your problem. And the really nice team management features, invitations, 2 factor auth, all of that stuff, got split out into a package called Jetstream, which is fully open source and, importantly, has different tech stacks within Jetstream.
Aaron
00:15:36 – 00:16:00
So you can have Jetstream Vue Inertia, you can have Jetstream LiveWire, and so that's all community managed. And so he gets a little bit of extra help on that to help manage those different stacks. But then the paid part is still Spark, and that's the subscription management. So that's kind of the Laravel side of it, and it sounds like you may be headed that direction.
Andrew
00:16:01 – 00:16:19
Yeah. Absolutely. So I think it still remains to be seen how it all sort of plays out, but definitely, there needed to be a split between all of that. Well, on the subscription side in particular, that was a huge part of bullet train initially. Right?
Andrew
00:16:19 – 00:16:42
It was a huge part of what people would say, oh, this is such a pain to set up, all that stuff. But over the years, integration with a payment provider and I'll just we'll use Stripe as the concrete example because I think they lead the charge here. Integrating with Stripe has gotten easier and easier and easier in some ways. Some people will be like, what are you talking about? It has gotten more complicated.
Andrew
00:16:42 – 00:16:54
I have to have webhooks. I have to have all this whatever. The abstractions are more complicated whatever. That's not untrue. It has as they have solved more and more complicated problems.
Andrew
00:16:55 – 00:17:32
There's a reason why the abstractions need to get bigger and, in some cases, more abstract or whatever. But in terms of how much responsibility your application has for pieces of the either checkout process or the customer portal subscription management, the amount of responsibility that your application actually has for those things, if you integrate with Stripe in the recommended way, it's almost nothing now. It's very, very little. And so I was sort of watching this because they have Stripe checkout. Right?
Andrew
00:17:32 – 00:17:49
So it's a it's a hosted checkout page and automatic support for things like Apple Pay. Now, I think I just saw today, ACH. ACH. So you've got that. And then the customer portal is really crazy.
Andrew
00:17:49 – 00:18:20
You just open up on your app. You're like, hey, I want this customer to be able to manage their subscription, and it sends you back a link and you redirect there, and they get, like, this full portal for managing their account, their subscription, their billing details, their cards, all of this stuff. And so because those two components exist, I knew that probably the stuff that we were doing before was actually too much responsibility within Mhmm. Kadoku or a Bullet Train app. Kadoku was the precursor to Bullet Train.
Andrew
00:18:20 – 00:18:44
It's an open source library. And one implementation that I saw in particular was Derek Riemer on SavvyCal. Mhmm. When I signed up, I could see his dependency on Stripe checkout and the Stripe customer portal and that this was a very thin integration. And I sent him a DM and I'm like, do me a favor, can you just send me your table structure?
Andrew
00:18:44 – 00:18:55
Like, domain modeling, right, classic? Andrew Culver sort of question. Send me your table structure. I just want to see what your integration with Stripe looks like in terms of the data model. He's like, it's basically nothing.
Andrew
00:18:56 – 00:19:15
And he sent it over to me and he was right. I'll probably mess up the details on this, but, I mean, it was basically I don't even remember if there was a subscriptions table. There was so little persisted in the local app because everything's managed on Stripe. It's in the Stripe system. All you need to know is I'll just give you an example.
Andrew
00:19:15 – 00:19:36
Like, what's their customer ID, and is their subscription active, and what plan are they on? That's all you need to know locally in order to do, like, plan enforcement or bouncing into a payment page or a renewal page, whatever. On the payment side, that huge responsibility that we had previously basically doesn't exist anymore. Does that make sense?
Aaron
00:19:36 – 00:19:54
Yeah. You felt like that as a value proposition for Bullet Train was kinda being carved away and, if I may say so, rightly so, carved away to Stripe, who can spend 1,000,000 of dollars making the checkout page better every single day. So you felt like that was being carved out of your offering.
Andrew
00:19:54 – 00:20:53
So isn't this crazy that the value proposition of Absolutely. Let Bullet Train handle that or Spark or whatever starter kit you're using. And then over time, they got so good at doing their job that it doesn't even make sense for your starter kit developer to maintain that responsibility anymore. And so that was one piece, and I think that's one of the reasons why when we could extract the billing stuff and now we're just gonna have a package called bullet train billing, And it's this super thin layer, but actually its responsibility is much more focused not on checkout and managing subscriptions and stuff like that. All its responsibility is now is allowing you to specify for all your plans and all your add ons what rights does that grant a user on a monthly basis, on a yearly basis?
Andrew
00:20:53 – 00:21:07
What's the upgrade path? What's the when do we prompt somebody to upgrade? What are the plan limits? And then enforcing that in the application, that's now our responsibility because Stripe will never be able to do that for us. Correct.
Andrew
00:21:07 – 00:21:17
So, kudoku is no more and bullet train billing is like this enforcement of what grants they have because of the package that they bought.
Aaron
00:21:17 – 00:21:28
So is bullet train billing now, like, there's obviously some functional code there, but basically, like, a place to put a DSL of, like, here's the plan, here's where it gets them, here's the plan, here's where it gets them.
Andrew
00:21:28 – 00:21:45
Yeah. It's a YAML file. Yeah. It's you have a configuration file and you even specify things like, for example, if you wanna limit team members, you do that by limiting memberships. You're just like, this model, they get 5 of those and it's a hard limit or it's a soft limit, and you let them go over.
Andrew
00:21:45 – 00:21:54
And then we'll handle issuing an email that says, hey, you probably gotta upgrade next month. But it's a totally different package. So that's amazing. Thank you, Stripe.
Aaron
00:21:54 – 00:21:54
Here's Stripe.
Andrew
00:21:54 – 00:22:02
Thank you to the other providers. Stripe really leading the charge on that one. Yeah. And that's where everybody needs to go. That's the only people we wanna integrate with going forward.
Andrew
00:22:02 – 00:22:47
So that's the billing side. And then I think on the other side, you've got, I think, regardless, we have all these features in bullet train that are almost, like, valuable regardless of whether or not you're building a SaaS. It really yeah, everybody talks about SaaS in a box and SaaS starter kit and SaaS template, but the reality is bullet train is much more a software framework than it is anything to do with SaaS. Because even when you're building internal tools, you need teams and invitations and memberships. It's really just like a higher level framework, and so that was basically the other piece.
Andrew
00:22:47 – 00:23:28
And the big shift on the other side of bullet train distribution is that we had originally shipped bullet train as a starter repository. You basically fork the repo and all of Bullet Train was in there. And over the years, as the surface area of Bullet Train grew, it basically became untenable to ship updates in that environment. We had this workflow where people would, like, fork the repo and then they'd merge from upstream, But as the surface area grew, it just became less and less feasible and maintainable to do that. And so that was where I realized, like, we got to do something different.
Andrew
00:23:28 – 00:23:56
I was actually against using engines, which is a facility that we have in Rails, which is basically like little mini applications that you can plug into your core Rails app. So you think of things like Nova, like our version of Nova. We have like Rails admin and administrate and all of that. Those are typically implemented as engines that you plug on. The classic engine example is like a blog system that you can plug on to your app.
Andrew
00:23:56 – 00:24:01
Interesting. Yeah. Yeah. And I didn't have a good experience implementing engines. Kudoku was an engine.
Andrew
00:24:01 – 00:24:20
I hated working on kudoku. And the developer workflow was just it didn't feel right. I didn't like it. And there was a developer at ClickFunnels, big bullet train customer, that his name's Eric Pittman, he's a senior software engineer at ClickFunnels, and he reached out to me. He's like, hey, can we hop on a call?
Andrew
00:24:20 – 00:24:30
I got a question for you. I maybe have a suggestion, whatever. He starts talking about engines and and how much he liked them and how much he thought they could improve bullet train. I'm like, wait a minute. What?
Andrew
00:24:30 – 00:24:42
I've been telling people for years that engines are the wrong answer, don't wanna do them, whatever. I respect the heck out of you, and you love them? That was a big part of what you did at your last job.
Aaron
00:24:42 – 00:24:43
I missing here?
Andrew
00:24:43 – 00:24:49
What am I missing? Tell me. Tell me. And so he gave me the spiel, and I said, That's fine. I'll look at it this weekend.
Andrew
00:24:49 – 00:25:21
It was on a Friday. And so I woke up the next morning, it was a Saturday morning, and I read through all the docs. And there was this one nuanced detail. When I was reading through the whole documentation making sure, like, I can't miss anything, There was this one nuance detail and this is, like, super deep in the weeds of, like, Rails land, but actually I can say this because the concept would be easily understandable to anybody in any programming environment. There's this subtle difference between 2 modes that an engine can have.
Andrew
00:25:22 – 00:26:08
And all of the ones that I just explained to you before were the concept of a mountable engine. A full application, isolated, namespace isolated, all the tables have namespaces on them, Totally isolated that you can bolt onto your application, and it gets its own set of routes and all of this stuff. That is a mountable engine in Rails. And that, I think, is what everybody has experience with if they've played with engines because that's what the documentation encourages you to do. Because it does good things, like isolates by namespace and all of these good object oriented things.
Aaron
00:26:08 – 00:26:09
Which you didn't want any of.
Andrew
00:26:09 – 00:26:36
Which I always found such a pain to work with in the context of kudoku, the subscription gem or the Stripe integration gem. But once that was, like, put right in my face, and I'm like, well, wait, but what's the alternative? And it turns out the alternative I mean, there's also engines that don't do anything and they're also a pain. But there's this sweet spot in the middle that I realized, and it's not mountable. It's called full.
Andrew
00:26:37 – 00:26:47
K? Which is less full than mountable. Mountable is that little bit extra. And a full engine is almost like a mountable. You can ship style sheets.
Andrew
00:26:47 – 00:27:02
You can ship views. You can ship controllers. You can ship models, all of this stuff. And it's just like the same concept, a Rails app in a Rails app, except there's no name space isolation. And that, as soon as I realized it, I sat down, like, what?
Andrew
00:27:03 – 00:27:49
I started doing a proof of concept and, like, breaking whatever it was, pushed it out into an engine. I'm like and the whole app runs, and all the tests pass. And I realized at that point, I basically got addicted too because it was so clean. I could see the repository getting the starter kit, the starter template, the starter repo. I could see it getting so much smaller and cleaner and easier to digest and more modular and the bigger pieces of the functionality that bullet train shipped becoming more optional.
Andrew
00:27:50 – 00:28:23
And so basically, that was at some point in, like, I wanna say late January, early February or something, and I just went absolutely nuts over the next couple months after that using that technique, that thing that Eric had basically pointed out to me, like, it doesn't have to be painful or at least got me to take a second look at it. Using that technique was able to, like, get bullet train down from whatever it was, like, 40,000 lines of code down to, like, under 10. And all of that stuff now lives out in these packages that people can include.
Aaron
00:28:24 – 00:28:41
Okay. So let me ask a couple of questions here as the outsider. So you were in the situation with Bullet Train where people had to start with Bullet Train because they had to fork Bullet Train, and Bullet Train had to be upstream, and they could merge in updates.
Andrew
00:28:41 – 00:28:46
Yeah. And that was a big challenge to the business. Right? Because you have to get to people before they start.
Aaron
00:28:46 – 00:29:00
Yeah. And, technically, I mean, they're you're upstream from them and they have to merge everything in and make sure everything works. Alright. So that's where you were. You ended up in this engine situation.
Aaron
00:29:01 – 00:29:15
My question is, what's the value of an engine versus a gem? Because from our side, everything from Delarable side, everything that we do ends up in the equivalent of gems, which is just composer packages.
Andrew
00:29:15 – 00:29:30
So do our engines. So all of these engines are distributed as gems, and the engine is just a particular structure of how it integrates with the application. So Rails has this API. Okay. So what
Aaron
00:29:30 – 00:29:56
does that buy you, being an engine in a gym? Does it buy you automatic registration by the rails framework so that if you just put things in the right spot, rails is going to pick it up because it sees that it's an engine? Is that what it is? So, like, if you want to ship migrations or whatever, and you register yourself as an engine, and you migrations in the migrations folder, you're done, you don't have to do anything else? Is that the whole bit?
Andrew
00:29:56 – 00:30:29
Yep, That's exactly right. So, I mean, there is a command in that specific case that has to be run downstream to import them into the local application from the engine, but, yes, that's generally the idea. And it's the same with models, views, controllers, all of that stuff, concerns, all of these little pieces that make up the core components of a Rails app, those things can just be thrown into an engine. And then depending on whether it's a mountable engine or a full engine, but if it's a full engine, like what we're doing for Bullet Train and not everybody will agree with that. Right?
Andrew
00:30:29 – 00:30:44
Some people will be like, no no no. Bullet Train should be mountable. It should have namespace isolation and all this. You're gonna have all these collisions. They might be right in theory, like from computer science land and the ivory tower, they might be right, but we never would have been able to do it.
Andrew
00:30:44 – 00:31:03
It never would have happened. We wouldn't be where we are. If somebody else wants to do that, have at it. But we're doing the best that we can with the stuff that we've got, and no namespace isolation is in my estimation. I think it's actually gonna be better in the long term anyway, but that's what's coming basically.
Andrew
00:31:03 – 00:31:15
Like, we can just copy stuff out of the core repo into this Ruby Gem that isn't that provides an engine, and then people hook in the Ruby Gem, and that stuff just lives in their app.
Aaron
00:31:16 – 00:31:32
Okay. So that's helpful for me to understand. So the things that you're shipping in this engine so let me I'll say it back to you to make sure I have it. So, like, in an engine, you basically ship a app directory structure? Exactly.
Aaron
00:31:32 – 00:31:36
And rails kind of looks at it and says, great, I'll just merge these two things together.
Andrew
00:31:37 – 00:31:37
Correct.
Aaron
00:31:37 – 00:31:54
Right? The engine and and your app. Okay. So the things that you're shipping as Bullet Train, are they base models from which everyone extends? Are they controllers from which people extend or expose directly as endpoints in their app?
Aaron
00:31:55 – 00:32:05
Are they views that they publish and then modify? Or, are they views that are just loaded without modifications? So, like, what are the things that you're shipping?
Andrew
00:32:05 – 00:32:16
I love this. We're really getting into the thick of it here. Yeah. So let's answer both of those separately. So we'll talk first about classes, and then we'll talk about views.
Andrew
00:32:16 – 00:32:32
Okay. Because we deal with them in 2 different ways, and there's different tools for dealing with both. For classes, the way that we do it so we have this concept called concerns, which I can't remember traits. In PHP, do you have traits and mix ins?
Aaron
00:32:32 – 00:32:35
We have traits. We have language level traits,
Andrew
00:32:35 – 00:33:12
and then we do our own mix ins, but yeah. So active support provides this concept of a concern, which is a module that has somebody can correct me if I'm wrong on this, but I think it's basically syntactic sugar for modules that you can mix into a model, so we call those concerns. The way that I specifically chose to implement things, if something doesn't need any sort of injection point for local modification, I just allow that class to live in the gem. It's there. There is a workflow for customizing that.
Andrew
00:33:12 – 00:33:40
We call it eject, and I'll I'll talk about that when I explain what we're doing with views. But there is a little bit of foresight that goes into it. And if you look in the bullet train starter repository and you look in the app models directory, you'll see 4 models. You'll see user, team, membership, and invitation. And the reason those 4 models exist there is basically to be open to extension.
Andrew
00:33:41 – 00:34:18
They're really stubs, but they're so commonly customized and extended in a local application that it didn't make sense to obfuscate those models and leave them out in some gem engine that provides them. I knew that they needed to be in the local repo. What they didn't need to have in the local repo is all their base behaviors. And so at the top of the user and top of the team, there is a user's base. There is a membership base.
Andrew
00:34:18 – 00:34:23
There is a team base as a concern that gets mixed into that model that provides
Aaron
00:34:24 – 00:34:36
all the framework behaviors. You ship user base, team base, membership base, and then application developers mix in your concerns into their domain models that are user membership team?
Andrew
00:34:36 – 00:34:43
Yeah. And in fact, they don't even have to because we have a starter repository that has all that stuff already in
Aaron
00:34:43 – 00:34:44
place. Gotcha.
Andrew
00:34:44 – 00:35:13
Okay. So the starter repository is still very much akin to, like, what bullet train was historically, something that you fork and you update via Gotcha. You know, upstream merges. But the surface area of that repository is so minimal now that it is more tenable, it's more manageable. Foreseeably, people could manage updates to that starter repository via that upstream repository.
Andrew
00:35:13 – 00:35:23
They could do the merge and get their updates that way, and sometimes there's merge conflicts, whatever, but it the surface area of that is gonna be small enough that it's actually feasible to do that.
Aaron
00:35:23 – 00:35:45
And if people didn't start by forking it, they still have access to all of that functionality by way of concern. And so if if they look if they look at your starter kit and they're like, well, I'm already 6 months in, but I wanna mix in bullet train now, which if that's a good idea, I don't know, they would be able to do that because you ship concerns.
Andrew
00:35:46 – 00:36:18
I think in some ways, we're trying to serve those people in a different way. Yes. Technically, they could potentially or possibly do that. I think the challenge would be all of our stuff depends on a particular UI layer, our theme, kind of, component layer. And so anything that you're shipping that has, like, views or whatever, you'd have to have that as a dependency because it's depending on certain components and partials being present that are being provided by a theme gem.
Andrew
00:36:18 – 00:37:10
And that's not to say that you couldn't do that, you could, but there's another level where we're trying to serve people that aren't bullet train customers. This is really important, I think, and that is with core gems. So for all the packages that we have, incoming webhooks, outgoing webhooks, roles, things like that, anytime we can, if there's a complicated piece of logic or functionality that we provide, like outgoing webhooks is an example, we do all of the, like, person can add an endpoint, and when an endpoint gets added, if there's an event that happens on a certain model, we issue an event, and then that event tries to get delivered, and we do the reattempts, and all of this stuff. And in bullet train, there's like a UI layer for it. The user can see all of this stuff.
Andrew
00:37:10 – 00:37:12
Right? It's awesome. It's a killer feature.
Aaron
00:37:12 – 00:37:12
It's amazing.
Andrew
00:37:12 – 00:37:35
Oh, yeah. It sounds like something that would be in bullet train pro, but just philosophically, we need to be in a world going forward where all the software frameworks have an API, a REST API, and outgoing webhooks. This is table stakes for being a good citizen. It's just my opinion, but it's table stakes for being a good citizen of the Internet. You wanna put software out now?
Andrew
00:37:35 – 00:37:54
My hope is that this encourages more and more frameworks to ship this as a feature because I want more and more applications on the Internet to have a REST API and outgoing webhooks so that we can glue more of these pieces together akin to, like, what you used to be able to do with AppleScript and stuff like that.
Aaron
00:37:54 – 00:38:18
Oh, man. Those were the days. I will say I fully agree that REST API outgoing webhooks would be great features for every application. I also agree that one person needs to bear the brunt of that pain. So I do think it is ideal that it's a framework or kit level feature because it's not easy.
Aaron
00:38:18 – 00:38:40
You know, you wrote it. It's not easy. And I think the table stakes are increasing, and we still want solo or mostly solo developers to be able to ship stuff. And so the more that these frameworks and kits can take off of their plate, the better. So if you're listening and thinking, well, I don't have an API or webhooks, I can't ship it yet.
Aaron
00:38:40 – 00:38:49
That is incorrect. Please ship your thing, and hopefully these frameworks and kits will come along with more and more of these undifferentiated heavy lifting features.
Andrew
00:38:50 – 00:38:56
Yeah. Yeah. Absolutely. I think my call to action is for framework developers. That's the goal there.
Andrew
00:38:56 – 00:39:36
So in situations where we can, there's a bunch of complicated logic and we get some incredible contributions to it. We just got a PR for our webhook stuff from an incredible developer where they're basically, like, improving the infrastructure. Has nothing to do with the presentation layer, the UI, the controllers, any of that stuff that we have to have in a Rails app in order for users to see it. It's just around properly implementing webhooks, and that is an opportunity for us to extract, to separate the layer. So we have outgoing webhooks and then we have outgoing webhooks core.
Andrew
00:39:37 – 00:40:26
And the hope is in the bullet train ecosystem that as often as we can, we do this with Bullet Train roles and we do it with Bullet Train outgoing webhooks core right now, is to ship packages that can be used by anybody, not just Bullet Train applications, so that we can hopefully encourage in the same way that we have consolidated on Devise and Can Can Can and these other things. We'd like to provide some of these libraries that hopefully can be used by people that aren't using starter kits or even using competitive starter kits. My hope is that the competitive starter kits use these components, and we just whatever. Whatever can be shared, let's share. The other starter kits have their own vision and their own sort of thing that they're trying to put out there, sometimes different technology choices, all of that stuff.
Andrew
00:40:26 – 00:40:47
But there's no reason why we shouldn't rally around as many common components as possible because then you sidestep the fragmentation and fragmented effort and all of that stuff. So whether it plays out that way in the long term, who knows? But I I think it's the right approach. It's definitely what we wanted to do from a bullet train perspective.
Aaron
00:40:48 – 00:41:26
Okay. So this is interesting to me, and you've said it once or twice, but we haven't really gotten into it specifically, but you said Bullet Train Pro. So, the model, as far as I understand it, the model is Train Open Source and Bullet Train Pro. And on the now, it used to just be Bullet Train was a paid thing, now it's Open Source slash Pro. On the open source side, you are leading a modular charge for let's say, standardization, best in class components for rails, in general.
Aaron
00:41:26 – 00:41:57
So, you're taking what was Bullet Train a SaaS in a box starter kit, and you're making Bullet Train an organization meta framework tool. So the things that Rails has not standardized, which to my amazement is stuff like the user model. I'll never understand that Rails doesn't provide a user model. User model authentication, which, again, I don't understand. You're standardizing some of that.
Aaron
00:41:57 – 00:42:33
Well, yes. You're trying to standardize some of that and trying to modularize, which is a hard word to say, some of that in hopes that you can spread that far and wide by now being open source. And not only is it open source, but it's not secretly tied to Bullet Train Pro, in that you can use it in any sort of starter kit or non starter kit or anything. So does that accurately describe the vision for Bullet Train Open Source as an organization before we move to Pro?
Andrew
00:42:33 – 00:43:08
Yeah. I think it does. I think the other big thing is just trying to introduce a new level of software development generally, like, just to similar to what Jetstream does, but I would like to see in all of the ecosystems, I would like there to be higher level frameworks. So, yeah, you're right, like, there is that very low level of demarcation in Rails, like, it doesn't ship almost any models. It doesn't ship almost any controllers, if any, and Vue's extremely limited.
Andrew
00:43:08 – 00:43:40
And so I think on the open source side, it's just like it's been a bunch of years, we're ready for a higher level thing. And so that's really the difference, like, we still call it the SaaS in a box and the SaaS template and all of that stuff because that's been our positioning historically and it's hard to step away from that when that's your intake channel. Right? Like, for for new customers, that's how people find you. But I do think that over the coming years, the positioning will change from being a SaaS starter kit or a SaaS template.
Andrew
00:43:41 – 00:43:48
Yeah, that'll be a thing that you can get in the Bullet Train ecosystem, but Bullet Train's a framework. It's really a higher level framework.
Aaron
00:43:48 – 00:44:23
That was my next crazy observation was we've been comparing Bullet Train to Jetstream and Spark, and I would like to posit that perhaps Bullet Train is closer to Laravel than it is to Jetstream or Spark because and this is something that I've always, as an outsider, been a little bit confused about, the place where Rails draws the line on what is common to man, So the place where they draw the line on things that we ship, I feel like is a lot lower than where Laravel draws the line. Like, Laravel
Andrew
00:44:24 – 00:44:24
Yep.
Aaron
00:44:24 – 00:44:54
Ships a user model, they ship authentication, they ship all kinds of stuff that is common to almost every single web application, Laravel's like, Yeah, I mean, you gotta do it, so we'll do it. We'll do it for you. Where there's this ethos in Rails, from my perspective, of it's not that hard, you should do it yourself, you're a professional. So it's like, you can figure out a user model, you can do that by yourself, you're a professional. It's like, yeah, but I don't want to do it by myself.
Aaron
00:44:54 – 00:45:51
And so now, Bullet Train comes in, and it's weird because you've been this centralized one unit thing. You're now splitting out into all of these different modules, we'll say, but different packages. I could see a future in which it all comes back together, and Bullet Train is a web application framework that sits on top of Rails in the same way that Laravel started as a PHP application framework that sat on top of Symfony and still relies on Symfony for a lot of its core components, but has since built an entire ecosystem around itself. But you're in this unique spot between you are kind of like a starter kit, but you're also, like, your own web application framework. And I'm curious to see how that plays out, what kind of traction you're gonna get on the open source side.
Aaron
00:45:51 – 00:46:10
And I think it's going to be good. Like, I think it's going to be a lot of traction, and I'm curious to see how that is going to come to fruition. Are people eventually going to say, like, yeah, we're a bullet train app, when they mean we're a Rails app that uses primarily bullet train modules and concepts? Is that a future you see happening?
Andrew
00:46:11 – 00:46:55
I think they start from the starter kit in the foreseeable future. I think that the pipeline to something becoming a bullet train app is that very thin sort of application template that we ship, and I think that there may be opportunities. The opportunities to generalize components of bullet train for use in applications that didn't start as bullet train applications may actually come from the folks that are looking over with envy from an application. Some of my friends are like this, right, where they didn't use bullet train for something, they spun it up, and they say have a friend here in Los Angeles who's like, I wish we had been able to use bullet train. They weren't able to for one reason or another.
Andrew
00:46:55 – 00:47:25
But now they look over and they're like, hey, I wish I were getting that feature. Every time we ship something, they're like, I wish I were getting that. And so it may be some of those folks that are looking over with envy at certain features or components or libraries that are available that will either do the effort themselves or send an engineer from their team to try to generalize things such that they can take advantage of it in their application. And when they do that, if they do that, then it would benefit the ecosystem generally. I think we are sort of tied up.
Andrew
00:47:26 – 00:47:48
We have a lot of work and a lot of responsibility to kind of just make the happy path a really fantastic experience for people. So, I think if there's something really obvious, we'll try to generalize it and make it available to everybody, But I think our primary focus is going to be on folks that are in a position to start from that starter template.
Aaron
00:47:48 – 00:47:53
That makes sense. Okay. I buy that. That's helpful. I think you are correct.
Aaron
00:47:53 – 00:48:14
That's the place to start and as time goes on, I think your sphere of influence will increase. But I think that is the correct place to focus in the beginning. Real quick, I want to talk about to round out the bullet train deep dive. I wanna talk about bullet train pro. So you have to make money because you like to eat food and have a house to live in.
Aaron
00:48:14 – 00:48:30
So Bullet Train has been your big thing, and now a huge chunk of it is free and open source. So what did you partition into Bullet Train Pro and kind of how did you think about how am I gonna carve this up?
Andrew
00:48:30 – 00:49:19
Yeah. So I think I would be remiss not to mention that Bullet Train and the open source effort around Bullet Train has an incredible sponsor. So this is something that's been in the works for a long time. We had a company reach out, a co founder at that business in particular, that reached out from ClickFunnels, huge hosting platform, ecommerce service, and they had been using Bullet Train internally for some project that they were doing just kind of as like a side concern, and they used bullet train for it. They had used some of my other open source stuff earlier in the business and then they had used bullet train and I didn't really know what they were doing with it, but they circle back around.
Andrew
00:49:20 – 00:49:59
Todd Dickerson reached out and said, hey, this worked really, really well, and we would like to use this more sort of on a broader scale within the ClickFunnels organization. What does that look like? Are there people that can help us? Is there a way that we can partner up on this? And so the way that that conversation basically evolved was such that they became the sponsors for the effort of open sourcing bullet train and making this more broadly available in the community, and therefore, a better long term choice for them to build things within their business on that foundation.
Andrew
00:49:59 – 00:50:45
And so that has to be said because you asked the the financial question, how do you go from making a bunch of money on something commercial and then, like, just turn off that tap, release it freely, how is that sustainable? It's sustainable through sponsorship, and so that's fantastic. We benefit from that relationship in so many ways because having an organization as complex and as sophisticated as ClickFunnels using your software framework gets you the kind of feedback, the kind of rubber meets the road, does this thing work. It gives you that feedback loop on a level that indie SaaS projects just don't. Right?
Andrew
00:50:45 – 00:51:09
So it's good. It's good that it's good for the the indie SaaS folks, but also getting that larger organization using something, standardizing it across a team, and then giving you feedback. Yep, this is good, this part's working really well, this thing could be better, and then having folks like Eric Pittman giving you feedback on, like, maybe you could structure it differently. That's been huge. Can't emphasize that one enough.
Andrew
00:51:09 – 00:51:11
And so that gives us a little bit
Aaron
00:51:11 – 00:51:35
Well, hang on one second. So you've said sponsorship, and I think for other people listening, when they hear sponsorship, they hear GitHub Sponsors. So I'm gonna open a $1, a $5, you know, a $20, and maybe a $100 plan and I'm going to be on EZ Street. Is that the shape of this you're saying sponsorship, so is that what you're talking
Andrew
00:51:36 – 00:51:42
about? No. Absolutely not. And we have that. I think I have a link on the website right now that says, you can sponsor Bullet Train.
Andrew
00:51:42 – 00:52:06
And I put the floor at $499 a month. If you wanna sponsor Bullet Train, you want a logo in the repo, you wanna help us move the needle, that's $500 a month. And I think practically speaking, we've sponsored people in the past as a commercial organization, and none of the sponsorship amounts that we talk about in open source move the needle, I think, for people meaningfully.
Aaron
00:52:06 – 00:52:07
I agree.
Andrew
00:52:07 – 00:52:38
I don't know. We need to have a conversation about that, and maybe we can be a little bit more open about what the shape of our sponsorships look like in the future, but, no, it's definitely more of a partnership. Right? So bullet train has historically and I think this is another piece of, like, oh, but how can you just give away for free the thing that you've been selling and then what happens to your revenue? Bullet Train has always been a business in which we were available to people to help.
Andrew
00:52:38 – 00:53:09
We weren't a consultancy Sure. But we provided consulting services. And so the services side of our business was what allowed us to really test that our abstractions would go the mile. We got to handhold deployments into some incredible environments that just increased my confidence that, like, we've got the thing or a thing, like, a real legitimate solution for people, and I can give this to people with confidence. And so there's that consulting side of the business that provides revenue and continues to provide revenue.
Andrew
00:53:10 – 00:53:34
And then I would say with ClickFunnels, it's definitely more of a partnership. We work very closely with them on both the consulting side and this side in which they provide sponsorship, and it doesn't look like what you typically think of as, like, open source sponsorship. Even when we have other people come through the door and say, like, yeah, we'll sponsor you for $500 a month. That's great. We love it.
Andrew
00:53:34 – 00:53:39
You'll get your logo in the repo, But ClickFunnels, they're our number one.
Aaron
00:53:39 – 00:53:52
Yeah. They're your patron almost. And I think that's important for people to understand because when I heard you say sponsor, I thought, he's saying sponsor, but he's not talking about GitHub Sponsors here.
Andrew
00:53:53 – 00:53:54
And I think I don't want
Aaron
00:53:54 – 00:54:10
to paint a picture that, like, you can make your living off of GitHub Sponsors. I think only Caleb Porzio does that. But I mean, I just wanna be clear for so everyone understands. So in the last maybe couple of minutes here, what did you carve out into Pro?
Andrew
00:54:11 – 00:54:46
Yeah. So the way that it stands right now, even the billing piece, and this is actually the same as Laravel, we carved out the billing piece to continue being a paid component. K. We also have because we're such a high level framework, we can build on top of things like our reactivity, our UI, and some of that stuff to provide features like we have this real time chat module that you can just like throw on top of your app. Say you have a project and that project has some milestones, and you're, like, well, we want people to be able to chat about the milestones, you can scaffold a real time chat thread on there.
Andrew
00:54:46 – 00:55:12
And when you do that, you also get an inbox for every user where if you have scaffolded conversations onto like 10 different models, they have a consolidated place where they can see their different conversations across different models. So great. And when somebody sends an a message to that thread, if you're not signed into the system, you get an email notification. And so you're standing in line at Starbucks, and you're like, hey, sweet. My bullet train app.
Andrew
00:55:13 – 00:55:23
Aaron shot me a message. Hey, I'm gonna reply to the email and be like, Aaron, I'm getting a coffee. I'll be with you soon. And the email goes through a Rails
Aaron
00:55:23 – 00:55:26
We parse inbound emails?
Andrew
00:55:26 – 00:55:43
Well, that's a Rails feature. So we're leveraging action inbox, I think it's called or whatever. And it comes in, gets read, and then gets appended to the message thread. So that's a feature. That's a a thing called conversations, is what we call that, and that's available in Bullet Train Pro.
Andrew
00:55:43 – 00:55:54
And then there's some other stuff, like, we had a Kanban board demo that we did just to demonstrate some of our reactivity and JavaScript stuff, and people were like, yeah, no, but we want the Kanban board.
Aaron
00:55:55 – 00:55:58
And Cool demo. I would like to have it, please.
Andrew
00:55:59 – 00:56:42
Yes. There are some very visible change log around models and activities. So it's powered by an open source thing called PaperTrail, but then we provide a UI layer on top of it. And one of the killer features of our audit log is that, sure, it's one thing to look at a particular project and be like, hey, what changes have been made on this project model? But wouldn't it be nice if all of the changes that happened for all of the models within that project, all of the milestones and tasks and things like that, Wouldn't it be nice if they could roll up into the activity log?
Andrew
00:56:42 – 00:57:00
And so that's how we have it implemented. So that also is one of those features that's available as part of Bullet Train Pro. And we haven't announced the pricing on that one yet, but I have been telling people even the pricing for Bullet Train Pro will be less than what we've charged for Bullet Train historically. So the level of
Aaron
00:57:00 – 00:57:02
Which historically was how much?
Andrew
00:57:02 – 00:57:18
We used to charge for Bullet Train. It started at 9.50 a year, and then eventually, we raised the price to 14.50 a year, 1450. Mhmm. And so whatever the pricing ends up being around Bullet Train Pro, it's gonna be less than that.
Aaron
00:57:18 – 00:57:27
Wow. That's amazing. I'm curious. So billing makes sense. Conversations sound incredibly complex and powerful.
Aaron
00:57:27 – 00:57:41
Makes sense. So, like, audit trail, how did you come down on that one? It's compliance flavored, so there's, like, heavy, you know, enterprise y, business y, but, like, how did you land on that one?
Andrew
00:57:42 – 00:58:20
It is just a matter of, I think, how much active development we're doing on something and how much effort it would take to support. So there is a little bit of watch this space with some of these things where it's like, hey, just because it's Bullet Train Pro today doesn't mean it's gonna be Bullet Train Pro a year from now. Ideally, we keep going up the stack, and we build more and more sophisticated components. And maybe something like the audit trail ends up in open source. So I don't know really something had to be paid.
Andrew
00:58:20 – 00:58:36
Right? Like, we don't wanna totally nuke the business. Yeah. So there had to be some things. Philosophically, stuff like webhooks and API were important for me to be in the open source, so we carve out some other stuff.
Aaron
00:58:36 – 00:58:49
Cool. That makes perfect sense to me. You gotta draw the line somewhere. Yep. And, yeah, if you have philosophical and, from your perspective, ethical duties to the Internet, you don't wanna put those behind the paywall.
Aaron
00:58:49 – 00:58:55
Like, you don't wanna put the thing the thing that you said every single app in the world should have, you shouldn't put that one behind the paywall.
Andrew
00:58:55 – 00:59:11
Yeah. I think in particular, we didn't touch on it, but one north star for me on bullet train development is students. And Interesting. I just think of how much I benefited from stuff that I got free on the Internet. Yeah.
Andrew
00:59:11 – 00:59:41
For better or for worse. And so if we can make stuff free on the Internet, legally, it can get put into educational materials, You can get your kids started on it at a young age if they have a knack for, you know, like computers and software development and stuff like that. I met a 12 year old at Sin City Ruby who not only presented at the conference and did an incredible job, but just had a real knack for development, had an enthusiasm for Vim. And Amazing. Yeah.
Andrew
00:59:41 – 00:59:43
My hope is by
Aaron
00:59:43 – 00:59:44
That was us.
Andrew
00:59:45 – 00:59:45
Yes.
Aaron
00:59:45 – 00:59:47
That was us a long time ago.
Andrew
00:59:47 – 01:00:06
And so we gotta get folks started on, I think, at this point, higher level artifacts or constructs, and that's why I want this to be open source. And I hope to see other ecosystems, similar things follow suit. We don't have to be the only people doing it and shipping it at this level, open source. There can be many more.
Aaron
01:00:06 – 01:00:53
I think that's a great topic to dive into another day because I think a lot of the young people entering into our world are headed towards JavaScript and the JavaScript frameworks over there. And I think the more that Rails and Laravel and Django, the more that they can provide in way of easy onboarding and speed to shippable products, the more talent we'll continue to get. It's not a talent war, but if everyone is going to the JavaScript ecosystems, like, eventually, we're going to have a pipeline problem. And so I think that's probably a wise decision with a lot of foresight there.
Andrew
01:00:54 – 01:01:04
Yeah. We can dig into that one more, I think, even deeper another time. I have some hot takes on that that I I don't wanna get flamed for. So
Aaron
01:01:04 – 01:01:10
I'm so ready for them. We're framework friends, so you gotta be careful how hot your takes get.
Andrew
01:01:10 – 01:01:12
We're friends with everyone.
Aaron
01:01:12 – 01:01:13
That's right.
Andrew
01:01:13 – 01:01:14
We'll have to get each other.
Aaron
01:01:14 – 01:01:23
And we'll have to get Kent C. Dodds on here to talk to us about JavaScript. Okay. Anything else on bullet train before we wrap it today?
Andrew
01:01:24 – 01:01:30
No. I really appreciate all the questions and the opportunity to kinda share this one with the world, so thanks for that, Aaron.
Aaron
01:01:30 – 01:01:34
Yeah. This is a big moment in bullet train history for you, so I'm glad we got to talk about it.
Andrew
01:01:35 – 01:01:38
Framework Friends is edited by Paul Barr at Peachtree Sound.
Aaron
01:01:39 – 01:01:41
Our intro music was created by Corey Griffin.
Andrew
01:01:42 – 01:01:43
You can find us at frameworkfriends.com.
Aaron
01:01:44 – 01:01:51
Andrew's on Twitter at Andrew Culver. And Aaron is on Twitter at aaron d Francis.
Me

Thanks for reading! My name is Aaron and I write, make videos, and generally try really hard.

If you ever have any questions or want to chat, I'm always on Twitter.

You can find me on YouTube on my personal channel or the Try Hard Studios channel.

If you love podcasts, I got you covered. You can listen to me on Mostly Technical.