Welcome to another episode of Compressed FM, a podcast all about web design and development with a little bit of zest.In today's episode, we have Aaron Francis joining us to talk about Laravel versus full stack JavaScript.
Web development and design, who would have guessed?Well, we can do them both, even add a little zest.So turn up the volume, get ready for the best.Let's get it started in this episode of Compressed.
Hello, my name is Amy Dutton and I am on the lead team with the Redwood JS Core team.
Hey y'all, my name is Brad Garropy.I'm a full stack developer at Atlassian working on Confluence.
And today's episode is sponsored by WorkOS.And if you have done any type of app development, you'll know that authentication is hard and WorkOS provides an elegant solution for managing auth for your application.
So they have a great setup with AuthKit, whether you wanna use a hosted solution or customize your login pages, WorkOS is a fantastic solution and it works for both full stack JavaScript and Laravel. So today's guest is Aaron Francis.
Aaron, welcome to the show.
Yeah, thanks for having me.I'm excited.I'm excited to be here to represent Laravel.I'm honored to be here.
Yeah, and I think, I think you're talking to two people at this point, who are like, very curious about learning or diving into Laravel.We're not curious, not antagonistic in any way.
Amy, I know, has had some hands on experience and myself, I'm trying to kind of find the JavaScript equivalent to Laravel.
Yeah, so I am in the process of building a gigantic Laravel application.It started as a full stack JavaScript application and kind of hit up against some of the edges of it and thought, what does this look like in Laravel?
And so I've been building out in Laravel.So anyways, your content has come up with all the video stuff and some of the things that you're producing right now with SQLite.
And so when we're talking about trying to compare things, you're one of the first names that we thought that we would want to reach out to and have a conversation with.
Yeah, I mean, thank you.That's an honor.And I'm excited to be here.I'm curious, what is your experience been with Laravel?Do you love it?
Yeah, I do.I actually do.Yeah.And we did an episode a couple weeks ago, where I was just kind of talking about some of the fun parts for me, that are really pain points, I think, in the JavaScript ecosystem that we haven't quite figured out yet.
And then some of the pain points that I hit with Laravel, And actually, I had a huge breakthrough today, or last week, because of chat GPT.So this was kind of interesting, too.And I won't talk too much, because I want to hear your thoughts on things.
But this is the first time that I've tried to level up in a framework or something that I'm not familiar with when AI has been available.And so it's been really interesting trying to hit an error and then I go ask AI.
And some of it's like, I don't have the experience yet with Layerable to know exactly what is right and what's wrong from what it's telling me, but at least it'll point me in the right direction in terms of documentation.
But one of the things that I was running up to with Frontend was I wanted to prop drill like you can with React or pass state around and was having a really hard time doing that with Alpine and Livewire.
And so finally I just went to chat GPT and I said, I know React really well.I'm trying to learn Livewire and Alpine.What are the middle models?What are the things that I need to know?And just that question alone unlocked
so much for me, because it was like, well, React is state-based, you're passing props around and things like that, whereas Alpine and Livewire, you're focusing more on events.
So when something happens, you want to dispatch an event, and then you want to be able to handle that event.And so once that unlocked in my brain, I was like, Oh, this all makes sense.
And I feel like I've been so much more productive once I finally understood that.
That's great.That's a, that's a great question for chat GPT.I like that.I'm going to steal that prompt for myself in the future.
Yeah, it was really good.So let's take a step back even though I kind of jumped ahead with Laravel.So you got, you're out on your own doing video content now.
Oh yeah. I'm out there, baby.So yeah, you know, so it's me and me and my friend Steve.And we both got laid off in a big round of layoffs at the company we were at.I think they let go of like half the company.
And Steve and I were on the marketing side.And, you know, sales and marketing all got let go, which is, you know, kind of a surprise.But Sales and marketing all got let go.And Steve and I were like, shoot, what are we going to do now?
And so, you know, we took we both took like a week or two to do some interviews.
We actually we actually took some interviews together, which was really it was just really both adorable and kind of funny that like we're interviewing as this, you know, this package.And that came from the company side.
They're like, hey, we'd love to bring you and Steve both on.Do you want to hop on an interview together?Like, sure.
So during that process, a lot of people were like, Hey, can you come do YouTube at our company, which is what we were doing at the old company.And it was just kind of like, I mean, yeah, we could, but do we want to do that again?
Like, do we just want to play the same song again?Or do we want to try a little bit something a little bit outside of the comfort zone.And so we decided, hey, we could, we could try to do this on our own.And if it fails, like, What a great story.
And we could go back.We could go back to any of these companies and be like, hey, we tried to live the dream and it didn't work.And who's going to like fault us for that?
You know, whereas if we were to go to a company, go get like a W2 and then be like three months in and then quit like that feels that feels icky.That feels like you should have just not started because
you know, now you're quitting three months in and you're putting a lot of people in a bind.
And so it just seems like now is the time for us to try this, you know, so probably the worst time ever from a family perspective, but from like a professional perspective, it's the best time ever.
And so we decided, great, let's set up a, let's set up a little company.So we're a we're try hard studios.
And so it's me and Steve and Steve is like the producer and I do a lot of like the on screen work and stuff like a lot of the teaching and education and it's been going great.It's such a freaking blast.We're having a lot of fun.So yeah, it's working.
And I guess you know, I'm a full time.I don't know what I am a full time educator probably is what I would say.
Now you guys aren't in the same city, right?
No, not even in the same state.Fortunately, he is in, where is he?Where's Boise, Idaho, and I'm in Dallas.
Oh, that's very different.Yeah, I just want to point that out because a lot of times it seems like with video production, it'll be easier because then somebody can shoot me doing things.
And if you're not in the same location, you're having to share video files, which can sometimes be quite large.
Sure can.Yep, indeed.So for like our launch video, where so you know, we put out this video that was like, Hey, we're here's what we're doing.We're going out on our own.Steve flew down here.Because he's like a he's a proper video guy.
And so he like, packed up all his equipment that I couldn't even tell you what they all do, and in a special bag that has these cool compartments, and then flew down here.
And he rented an Airbnb, and we set up a scene and a couple scenes in that Airbnb.And he's got lights with curtains taped over half the light.And I'm like, what are you doing?
So anytime we do need to do stuff in person, he's going to he's probably going to fly down here.Like we're doing another in-person shoot in a couple of weeks and he's going to fly down here.
And so, yeah, it's a little it's a little bit of a bummer that he doesn't live here.I'm trying to convince him to move.But one, Dallas is not that great.And two, he's got a kid.So I don't think it's going to happen.
What does your production process look like?Because your videos are some of the most polished videos that I've seen online.Oh, thanks.
Yeah, so from my side, so there are two sides.There's me and then Steve, and we've got to ship it over the wall.From my side, everything I do is pretty much in here.And this is my studio.Weirdly, this is a one-bedroom apartment that nobody lives in.
I don't live here.I have a home full of children, which is why I have an apartment. So this is this is a one bedroom apartment.This is the bedroom that I have turned into this recording studio.And so behind me is this wall that I built.
And behind that wall are the windows that look out over the pool.And I was like, Well, I don't want windows in here.And so I built a wall.And so now this is my backdrop.So everything I do, I do in here.And
Yeah, a lot of my work is like screen casting, screen recording.And so, you know, I think it is important that things be high quality.This is over the top, just because that's kind of our brand and kind of my vibe.
But yeah, I just I've got the screen off to the right right here.So it looks correct when I'm like looking over here.And then on video, I'm looking at the code, which I think is helpful.
And yeah, I've got a, you know, good mic, good camera, and Steve actually helped me light the space so that I look legit in here.And then the way that I do it is I'm pretty, I'm in all aspects of life, I'm pretty normie, I'm pretty basic.
And so I just record everything in ScreenFlow, and then I ship the ScreenFlow file off to Steve. And then what he does is he on his supercomputer, you know, we've just bought him like a five thousand dollar computer or something stupid.
He exports it all on his side to like Apple ProRes or something like that, and then throws it into Final Cut.And then he starts doing the edits over there.And so we're like when I say that we're normie, like we use iMessage to communicate.
We use Google Drive to share files.So it's like, you know, we're trying to keep it as simple as possible.And that goes a long way.
Nice.Now, like, what are you doing to actually monetize your business?I'm really curious, because I'm pretty sure there's like a SQLite course in the works.Are you doing contract video?Are you trying to kind of diversify income?
Are you just kind of putting all your eggs in one basket?
No, we're trying to put our eggs in as many baskets as possible.I think the big basket right now is the SQLite course.And so I am working on, in fact, I've got, you know, the next video to record right here.
I'm working on the SQLite course as, as we speak.I mean, before and after this podcast. That's what I'm working on right now.And the setup with that is kind of interesting.
We have partnered with Terso, which is a SQLite company, and Terso is sponsoring the course.And what that means is they have given us a certain amount of money that allows Steve and I to, you know, live in the meantime.
And then what we will do is I'm like producing the course, and then we're going to have links to Terso and Terso branding and all that on the course site.But the actual course content is not like a how to use Terso.
So the model is basically, hey, I want to teach, I, Aaron, want to teach how to use SQLite. I'm going to teach you the nitty gritty, I'm going to teach you everything vanilla.
And to the extent that Terso or LibSQL, which is their fork, to the extent that Terso is easier, better, faster, I will mention it and say like, here's how you would do it.If you're on Terso, this is actually a lot easier.
And so I'm hoping that that keeps the purity between you get education, but also Terso gets a lot of value out of people that want to learn SQLite, but maybe want an easier route. And so in the end, we will sell the course to end users as well.
So that that launch is coming up soon.
Sweet.What's the launch date?Do you have anything set in stone?
I mean, it's kind of stone.I don't know if that's how stone works.But I think our goal right now is the 27th, which is next Thursday.So yeah, awesome for you.Terrifying.I still got a bunch of videos I got to record.But yeah, I'm very, very excited.
I've got you know, I've got what's left of the docs here with my notes and some docs over there.
I still can't believe you printed those.That's wild.
Oh, yeah, of course, man.Let's see.So like this is these are the docs on vacuuming.And so you can see I've got all my highlights there.This is a great blog post by somebody.
But I've also printed out optimizing SQL lite for servers and it has a bunch of good.So I've got all those highlighted as well.It's just like, Man, there's just so much, there's just so much information, just kind of at the surface.
And it's almost like you have to just walk out into the field and pick up the gold off of the ground.It's like, they made this available to me.
And so I really enjoy these, you know, these back here, those are all my sequel slash Postgres and some Redis books.Nobody reads anything. Nobody reads anything.
And so I can put in a lot of work and apply things I've learned plus things I've experienced and turn that into a course.And everybody's like, you're a genius.I'm like, well, I read the docs.So it's kind of nice.It's kind of like a cheat code.
And you can say it as much as you want.And nobody's ever going to go and actually read the docs.So it's my open secret that I learn a lot of stuff by reading.
I have heard so much lately about SQLite.It feels like maybe it's your great marketing.I know SQLite's been around for a while, but why all of a sudden are people interested in this?Like why is Terso able to create an entire business around it?
Yeah, it's been around for 1000 years.It's been around for 1000 web years, which is 24 human years.So, you know, it was originally written back in 2000 by literally a guy who was needed a database for like a battleship, like an actual, you know,
military battleship.So he needed something.He needed something that was offline and robust.
And it's funny, because he said something like, if I had known you weren't supposed to write a database from scratch, I wouldn't have, but I didn't know that you weren't supposed to do that.
And now it's literally the most used database in the world with like trillions of databases out there.And so So one thing it has going for it is it is incredibly stable.It is just unbelievably stable.
For every line of library code, there are 600 lines of test code.And so we're out here arguing about, should we have unit tests?And they're like, not only are we going to have tests, we're going to have 600x the tests.
And I'm like, wow, good for you guys.And so it's gone through trial by fire.Because you have to imagine back in the day, and even now, where do SQLite databases really shine?They shine on embedded environments, right?
So back in the day, it's like, hey, I need a database for my freaking Palm Pilot.What kind of database am I going to put on a Palm Pilot?I'm going to put SQLite.
And then you get into this world where it's like, OK, the battery could die at literally any moment. Or on some devices, the media, the storage could be ripped out at literally any moment.
And so you're in these extremely hostile environments where it's like anything and everything will go wrong.And when you have a trillion databases, an edge case becomes run of the mill, like it just happens all the time.
And so stuff like that, where they You know, you can pull the media out and you won't get a corrupt database.The battery could die and you won't get a corrupt database because of how insanely battle tested it is.
And so I think that's one of the things is it's incredibly stable.They're very, very committed to backwards compatibility, sometimes to a fault, but it has earned them the archival format of the Library of Congress.
So like in the United States, the Library of Congress keeps track of a bunch of stuff, who knows what it is, but the archival format is SQLite database.
And so it just kind of over 25 years, it has gained this credibility of we're not going anywhere and we're super good at what we do. Then I think the other side is the hardware that we all use has caught up.
So one of the, you know, the drawbacks of SQLite is it's embedded.It's not client server.And so you can't have, you know, 50 web servers connecting to one massive database server.It's like, well, the database kind of has to live on the same machine.
And so it's embedded right next to it.Tersa is changing that a little bit, but vanilla SQLite, it lives right next door.There's no network overhead, which is awesome. But that means you're kind of limited on the scale.
But these days, disks have gotten bigger, faster and cheaper, importantly, you know, faster, but also machines have gotten bigger, faster and cheaper.And so you can scale up vertically a long way before you need to start adding new machines.And
I kind of think that most web apps would live fine with SQLite as the primary database.At least most of the stuff that I feel like we're building, like GitHub couldn't run on SQLite.
But most of the stuff that we're building where it's like, man, we would be just like totally out of our minds to imagine we would get thousands of requests a second.It's like, yeah, SQLite can do that in its sleep.
And so it's kind of like, there's a narrative around it of, hey, guys, how many, like, what's your actual load?Because if your actual load is under thousands per second, you're probably fine.
And I think all of those things have conspired to like, hey, why don't we use SQLite?Also, MySQL is having a bunch of regressions and Oracle's like kind of fumbling the bag there.
And so there's a lot of things that are going on where it's like, maybe SQLite is great until you need to move off of it because you have so much money. It's like, okay, sure.
I love that.I'll just add one quick thing.It is running a maintaining a framework.As soon as you install Redwood, you have access via a SQLite database.Like that's what we offer out of the box.
So we have support for Postgres, but you don't have to do anything and SQLite is right there.So it's fantastic.
Yep, I talked to DHH a while back about SQLite in Rails, and that was one of his big things, was he was like, I want to lower the bar to entry as much as possible, and I don't want people to not become web developers because they couldn't get a MySQL or Postgres container or something up and running locally.
There are a million reasons you might fall off the path of becoming a web developer, but if we can remove the database as one, that's great. Great, let's keep people on the straight and narrow and SQLite is really good at that.
Laravel has just recently moved to SQLite as default database driver.
That's awesome.Yeah, I was going to kind of ask something on the flip side, like, is there anywhere where SQLite isn't the right choice?And kind of conversely, how does SQLite do in a distributor serverless environment?
Yeah, there are lots of, well, there are a few categories where it doesn't fit, which may encompass a lot of places.So like I said, it is embedded, so it's not client server.
And so with that, you, let's see, if you need multiple concurrent writers, that is not possible with SQLite. And I will say as a way to enrich that statement, you might not need multiple concurrent writers.
And so if you are, again, thousands of requests or thousands of queries per second, I did a benchmark last night just for giggles on my MacBook.So it's a little bit different.It's not a server, but it's on my MacBook.
And it was like 90,000 reads a second and like 5,000 writes a second or something like that.And I'm like, man, if I ever got to a point where that was a problem, that would totally rule.But yeah, like multiple concurrent writers, that's a problem.
You just there's no there's no way around that.The other thing is, there's no fine grained locking.So that is, you know, another kind of corollary to the single writer.
Like when it comes time to write, you just got to lock it so that that one person can write so you can't do like table or row or anything like that. Can't do fine-grained permissions either.
So if you want to like grant or authorize people to do certain things, it's just really not a thing.Can't do... I think libsql has the ability to do encryption at rest, but regular traditional SQLite doesn't.
Libsql is Terso's fork, but yeah, yeah, yeah, yeah, yeah.And then I'm trying to think, what are the others?Huge amounts of data.So theoretically, SQLite can hold 281 terabytes of data, but come on.
Like, it's a single file, for goodness sakes, like, there's nowhere that you're going to be able to put a single 281 terabyte file.
And so I think the rule of thumb is that once you get beyond maybe a terabyte, that would be a good time to start looking at a client server database.And of course, is client server versus embedded, you can't access SQLite over the network.
I mean, so you got to kind of like SSH into the server and then poke around there.I think lib SQL has some options for that because they do some cool stuff with like embedded replicas, which are very awesome.
But yeah, with traditional SQLite, there's no way to be like, hey, I'm on my machine here.I want to connect to prod and just like do something dangerous, which maybe that's a good idea.
So yeah, there are several places that SQLite falls over, and I don't think it's a panacea.I think it should be considered by more applications than it currently is.
And so I take it Terso probably comes in here and solves some of these issues for us.Is that like, can you talk about what Terso adds to the sequel light universe?
Yeah, totally.So torso ads.So the reason that they forked sequel light sequel light is open source in a strict legal definition in a like community definition, we'd call it source available, because the source is available.
And they actually waive all copyrights.But what they don't do is they don't accept any outside contributions.And like, I can't super fault them for that.Because One, it's like a giant C library that I understand is written in kind of an obscure way.
The patterns of the C library are very particular to the author, who is a very particular person.So I can't fault them too much, especially because they have this like,
brutal and ruthless commitment to stability and compatibility, that they don't just want everybody like submitting PRs and they just kind of want to do it all themselves.
I think it's like three guys and they're committed to maintaining it through 2050.So like, I can't really fault them for that.Like they're still pushing forward.They just don't want outside help.
So Terso forked it as LibSQL and it is open source and open contribution.And they do accept contributions from the outside world with their explicit stated goal to be merging it back into SQLite if that's ever allowed.
I don't think it will be, but that's interesting nonetheless.One thing that Terso does, so like SQLite's a file and it's got to live next to your application because there's no network, right?
It's just a C library and you call it and it opens the file and it does the stuff.
which makes it incredibly fast, because we're talking, you know, microseconds instead of like, even if your database server and your app server are next to each other, that's still milliseconds, like the speed of light and fiber, all that still exists.
So having it right next to you is a huge advantage.But How do you get the data to another server?Or how do you get the data to a backup location or something like that?
And so one thing that Terso slash lib SQL does is this thing called embedded replicas, which is just incredibly cool.So you can have, let's say four app servers. And they all have these embedded replicas of the database.
And so your reads are just right next to each other, like it's like the app and the database file right next to each other on four different servers.And when you go to write, libsql can see that and forward the right somewhere.
And so that's a way that you can have sort of client server with sort of SQL lite and your rights will get replicated back out back to your embedded replicas.And so that's one of the things that they're doing.
They've got a whole, you know, they've got lib SQL, then they've got a whole platform layer around it where you can like create databases via API call and all of that kind of stuff, which is very interesting.
But they have also added some like just recently they announced SQLite vectors.
And so they're really pushing forward, but are still constrained in a good way by some of the SQLite architecture, which is like, hey, it's got to be right, right next to you.And that's a good thing.
Very cool.So how did you even get interested in SQLite?Is that just through Layerable?
No, that's a good question.So I came out of a database company that was a MySQL platform and I kind of have there, I kind of carved out a spot kind of like in the mindshare of people as a database educator. And I really enjoy it.
I have this intrinsic desire to play with databases.And I think I am in a unique position in that I never got a computer science degree.I'm not a DBA.I just happen to know, like, and enjoy learning about databases.
And so that puts me in this interesting place where most of the database education comes from DBAs, which are really low in the stack. Or it's people really high in the stack that's like, ah, the database is behind the curtain.
Don't worry about the database.And you're like, I kind of want to know how to use the database.Like, I don't want to, I don't want to know how to administer the database.But I'd like to know, like, what's going on behind the curtain.
And so I have kind of found this meaty middle where it's like, I'm not a DBA, but I'm also not just an API user.I am an application developer that wants to know how to drive a database really efficiently and effectively.
And so I've carved out this spot in the market of like, I will teach you databases as an application developer who really understands databases so that you can be an application developer to make your apps really, really fast.
And so coming out of the old company, I started looking around and I was like, Why don't I do another database?So the old company was a MySQL platform.And I thought,
hey, let's take one step to the left or one step to the right and see what else is out there.And that's kind of where I landed on on SQLite.And one of the early interviews that I had after I got laid off was with Glauber, the CEO of Terso.
And we got on the call and he was like, hey, man, I can't hire you.And I was like, what are we doing on the call?
He's like, but I'm here to tell you, I think you should go out on your own and I think you should do that and we will be your first client.And that's part of when I was like, Oh, man, I could do this.
And so that's kind of what settled SQLite being the first one.And then, you know, I had a ton of interviews with Postgres companies, and that was obviously the next one.And so that's what's coming later in the fall.
Yeah, I feel like I feel like I've been hearing a lot about SQLite mostly through the Remix community, because Remix likes to host on
fly.io and fly offers distributed SQL lite where they'll do those read replicas sitting right next to your application.Again, kind of solving that, you know, it's not a networked database problem.And I think it was just the pure speed of it all.
That was just like, yeah, this is real fast.
Mm hmm.Yeah, I just saw on my YouTube channel.I've been talking to people at the SQLite world, and I just it's not out yet, but it will be in two days.I just talked to Kent C. Dodds about his experience with, you know, distributed SQLite.
And it's he's on fly.He's obviously remix.He's on fly.He's using SQLite.So he is like the archetype of what you're talking about.And it was really it's really interesting.It's very compelling.He makes a he makes a very good argument for it.
I didn't need convincing, but he convinced me that it's a great idea.
That's funny.So you pulled out, well, Kent's name, Remix. We talked a little bit about Laravel, so let's have the conversation.Laravel for full stack JavaScript.
Oh man.So how were you first introduced to Laravel?
Yeah, I picked up Laravel in 2014, maybe, maybe 2013.And I found it, I've been a PHP developer for, if I'm 35, then I've been a PHP developer for like, 25 years, which means I was a 10-year-old PHP developer, which is accurate.
No, honestly, just raw.I've never, to my great, I don't know, credit maybe?I've never dug into WordPress.
Isn't that crazy?I know, it's not.PHP was my first.Yes.And it's because of WordPress.Every PHP developer comes through WordPress.I did not.So I started with just like, you know, plain PHP and then
Shortly thereafter, well, shortly, you know, once I became an adult and I started like doing more PHP, I picked up a framework called Yee, which is just impossible to say, Y-I-I, and it was great. And no, I did do cake.
I did do cake at a job, but I picked up ye first and use that for a little while.And it was great.And then noticed that Laravel had a lot of affordances that he didn't have.
And so I switched over to Laravel in 2013 or 14 and have stuck with it ever since.
Very cool.And that was like version two.
It's like, oh, gosh, no, it was not that early.I think it was like four point something.Yeah.
And now you're an expert.
Yes.Now I know, love and trust Laravel and I'm I'm too far gone to do anything else.
Yeah, so let me ask this question.What are some of the we'll start with the good things.What are some of the great things about Laravel that you're like, no choice.This is it.
Hands down.Okay, let's see.It's about to become hardcore history is about to become a four hour podcast.
So here we go. there's something nice about a benevolent dictator, i.e.Taylor, who is ours.There's something nice about a benevolent dictator who their only product is Laravel.And so what I mean by that is in the Rails world, they have DHH, right?
But DHH has base camp and hay and campfire and the 37 signals umbrella to say nothing of being an actual race car driver, right?So DHH has a lot of stuff going on.Taylor has a lot of stuff going on, but everything that
that Laravel LLC, or maybe like Laravel Holdings Inc, everything that they're doing is for the benefit and edification of Laravel developers.
And so how that expresses itself is, we have an incredible number of first party open source packages to do things.And I can describe some of those in a little bit.But we also have first party SaaS offerings.
which I think is relatively unique in the framework world.
I feel like Fly.io has adopted Elixir just a little bit, but it's still like Fly.io is trying to be all things to all people, whereas Laravel Vapor or Laravel Forge, maybe a little bit less, but Laravel Vapor is the hosting for serverless Laravel.
And it's written by the same guy that wrote the Laravel framework.And so you know that it's going to work.
And so that permeates the entire ecosystem in that you can pick up any first party Laravel package and plug it into Laravel and just know that it's going to work. And all of the affordances are there and we still get the benefit.
So Ruby has the benefit that Rails is extracted from real life products, which I think is pretty important.Laravel is extracted from real life products too.It just so happens that the products all benefit Laravel developers.
And so that makes for a really tight ecosystem from very beginning, like setting up your development environment.We have Laravel Herd, which means you don't have to muck around with homebrew or anything like that.
You can download Laravel Herd for free and you can get PHP and your database and node.You can get all that stuff, all your environment totally configured on your local machine.
We also have first party, you know, Docker containers and other stuff like that. all the way through to production with Laravel Vapor or Laravel Forge, we have the entire lifecycle covered.
So that's kind of like from the ecosystem level, from the framework level, it's just everything you need to build a modern web application is provided.And I think importantly, everything is primarily driver based.
So when you when I say like Laravel has everything you might need, including something.I'll say, let's choose sending emails.
What I traditionally hear as pushback from that is like, well, in another ecosystem, we would just pull down a package to send emails with, pick one, Postmark or Resend.Resend is big in Next.js, right?
We would pull down the Resend package to send emails, And I'm like, that's great.I love that.I love that for y'all.But here's the difference is like Laravel provides a lot of structure around these things.And then you can plug in a driver.
So you can still plug in the recent driver or the postmark or the SES or Mailgun, MailChimp, any of those, you can plug those in.
But what Laravel provides is a nice way to construct mail objects, a nice way to build out HTML and plain text email, a nice way to have markdown email, a nice way to render mail in the browser during development, a nice way to like trap mail in development so you don't actually send it and you can view it on a different tab and see what mail would go out but is not going out because we have like this trap driver.
And so that's like, that's maybe the best thing about Laravel is everything that you would need for a web application.So we're talking ORM, queues, cron jobs, scheduling, mail, authentication, social authentication, all of that stuff is available.
And if you want to use a different providers, like you want to use Upstash as your cache, you know, infrastructure, you can just plug in the Upstash, you know, connection string or whatever it is for Upstash.
But you still get all of the integration of the first party Laravel affordances.And so that's a little bit I know that in other communities, specifically JavaScript, they like to like grab packages and build out their own thing.
I find that having all of those things already glued together reduces the amount of friction between like,
All right, if I want to queue an email to send that has a reference to the user model, and I need to get a notification if it failed, like I can do all of that in Laravel without having to like glue any packages together.
And so that's the thing that keeps me coming back is it allows me to build out my idea and not build out an integration between my ORM of the week and my cue driver of the week and say like, hey, you guys really should talk to each other.
It's just like, I'm not going to do any of that.
Yeah, and then you have to worry about compatibility issues when one package upgrades and the other one doesn't.
Yes, and it makes learning a lot harder because you're like, well, okay, I'm using Prisma and I'm using Resend and I'm using Next.js, but the app router and it's like, oh my goodness, there's not going to be an article for that.
Like there's not going to be documentation for that because there's infinitely many permutations. Yeah.Yeah.
So I want to talk about kind of like then the other side, like it's absolutely, totally clear that Laravel handles back end and everything you could need so, so well.But I think Amy and I both come at this situation from a front end perspective.
And so in one of your latest videos, you had that awesome graph where like the network was in the middle, right?The Laravel thing starts on the back inside and it crosses and it fades out, you know, kind of shortly across that network graph.Yep.
in the react world, they're trying to do all sorts of crazy things with these react server components.
Bridget network gap, right?So let's say you're you want to use Laravel for your back end, because it gives you everything first party here it is.And on your front end, you're like, well, I still want to use react. Mm hmm.
Don't you lose something over that network now because now you're just treating Laravel like a headless API and your react is kind of just like like a regular spa application or even a multi page application where you're just hitting this Laravel API or am I missing something there?
I can't say for sure.I could talk about it, but I don't know if you're missing something or not.I don't know, honestly, if you're losing anything.That would be something I think someone on the front end would have to decide.
So that would be something y'all would have to decide if you're losing.But I can describe, I think, what the ideal
pairing of those two things is so I am sensitive to the fact that react provides a great front end experience when done well, I'm totally I don't discount that at all.
And I understand and this was in the this was in that video, I understand that you can go way further on the front end with react, I happen to like view j s a whole lot, but react and view same idea, you can just do so much more.
then you can with Laravel plus Blade, then you can go further than you can with Rails plus Hotwire or whatever they use over there.And so I'm super sensitive to that.
What I wish was more in discussion in front end communities is the back end exists, like the powerful back ends exist, and should be taken advantage of.And I think a way to do that, there are a couple ways to do that.
I think you could live with Laravel on the backend and just provide a dumb or a simple API.And then you could just have whatever you wanna use React on the front end.I don't even know, create React app or something to create like a SPA, right?
You could also have a full-on Remix app that has its own little, I don't fully understand what happens behind the network on Remix, but I understand that there are like loaders and stuff, right? And I think those loaders can hit a Laravel API.
And so you can still get some of those, like whatever it is about Remix that you love, where it bridges that network gap, you can still keep some of that and just have your Remix on 3000 and your Laravel on 3001 or something like that.
And Remix and Laravel talk to each other across the network.
That's, that's totally fine with me, you can still you can do that with Next.js and server actions, as well as server components, who knows what to call anything, you can do that with with Next.js.
Also, I think a so that would be somewhat treating Laravel as a dumb API, which is fine.It's not disparaging to say it's a dumb API, it's still incredibly powerful.And I think that's right. totally fine way to go.
You can also plug something like InertiaJS in the middle, which if you can imagine the area of the stack that Remix carves out is that network with just a little bit of a hook into the front end side and a little bit of a hook into the back end side.
Inertia does the same thing, except the hooks are more agnostic.So you can have Inertia hook into a React, or a Vue, or a Svelte.And then on the back end, you can have Inertia hook into a Rails, or a Phoenix, or a Laravel.
And what it does is it provides that bridge over the network
such that you get a SPA feeling, but you still get server-side routing and you get a lot of those nice, you get a lot of those nice things about either one without some of the painful stuff, which I think client-side routing is painful.
I think it's prone to a lot of bugs and I feel like Inertia has covered that really, really well.And I do like being able to define my routes on the backend and define my data that's being sent out on the backend on the Laravel side.
And so you have plenty of options to combine the two.
And I think my great desire for the web community as one community, which is not true, you know, we're a bunch of little, we're a bunch of little fiefdoms, but as one giant web community, I wish that the conversation was more like, hey, React slash Vue are awesome on the front end.
How can we marry it to an awesome backend instead of, I'll take it from our side, instead of saying Laravel is everything and should be used
for everywhere or instead of reacting react is everything it should be used everywhere and then you get to the back end and it's an empty warehouse and they're like just put all the stuff you want in here and you're like I thought there was something built already and you're like no but you can build anything and so that's kind of that's kind of where I see it and they're like.
there are great HTML over the wire things, and I have no problem with HTML over the wire.I think HTMX, Turbo, Livewire, Liveview is all incredibly interesting and has a place.
And I think the ceiling that Livewire, Liveview, all of that, the ceiling that they're running into is continually being upped with stuff like Alpine.And so you can, with enough care and attention, you can make a good experience using any technology.
Some of it is preference, some of it is flavor, and some of it is like, pragmatism, like if I were a react developer and I had to go to the back end and figure out how to do cron jobs, I would be like, guys, there's got to be a better way, right?
And so that's kind of that's kind of my point of view on the whole thing.
So, okay, you said a key word for me.The way I view it is that, look, JavaScript will always be here because it runs in the browser, right?We're gonna have to deal with JavaScript, but we have a lot of choices for backend languages.
So if I could snap my fingers and have the backend of my dreams, it would be a JavaScript backend.
Do you have any hands-on experience with Adonis, or do you think there's a JavaScript competitor to Laravel that might have a better chance of uniting the frontend and the backend?
Yeah, a few thoughts on that.One, first of all, no, I don't have a hands-on experience with Adonis.I have read their documentation and find it very compelling, but I don't have, I've never used it.
The thing that I continually see is people clamoring to use a single language across the whole stack. And again, that's something that I can mentally assent to, but it's not a thing for me.I don't super care.
Frankly, I like using PHP on the back end and JavaScript on the front end.I kind of feel like it puts me in a different world, and it's easy to remember, oh, okay, this is all front end, this is all back end.
I kind of like that, and maybe it's because I'm 1,000 years old at this point, but that makes me happy.
So to the extent that JavaScript folks want to use JavaScript and now TypeScript on the backend, that leads us to what's a backend framework that's written in JavaScript.I think Adonis is amazing.I think that because it looks a lot like Laravel.
It's like, well, that's why I think it's awesome because it lines up with something that I already like.And so can my opinion be trusted?Not really.I just think it looks like Laravel.I'm like, hell yeah, that rules.
I think I have continually heard from enough JavaScript people that I trust their opinions.I've heard enough that that doesn't match the ethos of the community.And I don't understand that.
I understand what they are saying, but I cannot emotionally arrive at that for myself because what they are saying that I believe to be true is the JavaScript community really likes to put stuff together on their own. Irrefutable, frankly.
I mean, you just watch these projects happen.And it's like, y'all love putting stuff together on your own.I can't get there myself.And so is Adonis gonna win?It doesn't seem like it.And that breaks my heart, because I don't understand.
But people will look at Adonis and be like, ah, this ORM is not the way I would do it.And then they go put in Drizzle.And then a month later, they put in Prisma.And then a month later, they put in Kaisley.And I'm like, guys, what's going on?
And it's not a disparagement.It's just I don't, I fully don't understand it.I cannot mentally get there.I cannot emotionally get there to be like, I want to do that.So Adonis seems great.
It just doesn't seem like it's like, it doesn't seem like anyone cares, which is really sad to me.
I can't reconcile the fact that it's like in the JavaScript ecosystem, I constantly hear, we're looking for the laravel of JavaScript.
We want JavaScript to solve all these things, but then all of the marketing language, all the like businesses, they all talk about composability.
We want you to be able to have the freedom of choice, pick out the best solution for what you're trying to configure.You have that freedom. And it's like, well, what is it?
Do you want somebody that's going to help make these choices and configurations for me?Or do you really want to be able to swap out your ORM every week?
And so I haven't quite figured out how the community is going to shake out and what the answer is going to be.
Yeah, I saw a video recently of like, why isn't there a Laravel for JavaScript?And the thesis was, because we don't want it, we like putting our tools together.And the funny thing is, like, it's very, very, very subtle.
But if you watch it, the funny thing is, at some point, he says something like, we really like composable tools, we like choosing the best thing possible.And then he goes to the web page for like, his stack or his you know, flavor of choice.
And he says something like, actually, we don't use Prisma.We've swapped that out for Drizzle.And I'm like, that's what I'm saying.That's exactly what I'm talking about.
You are, you're mentioning that you have like created this bespoke framework of beautiful objects.And then you go to the webpage and you're like, actually, that's old.We've swapped our ORM.And I hear we've swapped our ORM.Like,
might as well rewrite the whole thing.And so that's where I'm, I just, I can't, as much as I've tried and I'm an empath by nature, I just can't figure out why that is appealing because it's not appealing to me.
I do, however, respect that it is appealing to other people, just not me.
Well, and the other side of it that I've heard is we don't have a DHH or Taylor Orwell or any of those things that to represent and say, here's the way I have the truth.
And I think, um, just like, candidly, because this is, you know, a podcast, not like people are actually gonna listen, hopefully, hopefully, I think candidly, Vercel is kind of doing a little bit of harm there, because it is so focused on getting people to spend money, like,
they own Next.js.And from what I've seen, it's very difficult to get all of the magic of Next.js in other places.Like I'm watching Dax Rad on Twitter, try to like host Next.js through SST.
And it's like, we've got to come up with these 14 different constructs to get all this stuff working.And I'm like, well, that seems bad. Like I could take, I could take Laravel and I could spin up a droplet and drop it on there and it just works.
But Forge does it for me, which is nice.
And so I do feel like there's a little bit of a tension in the JavaScript world with Vercel being the 800 pound gorilla, where it's like, they are spending all of this money on marketing, but their solution from the outside seems very complex.
And so they, what is it?They suppress our medicine, they sell us our cures, whatever it is, it seems like you have to put it on Vercel.And so.
So I don't know, that's just an outsider's perspective and watching Dax try to figure out how to host Next.js somewhere else.
Well, and Vercel is like, I'm going to collect them all mode, because they also sponsor Astro and Svelte, SvelteKit, we have Next.So who knows?
They're hoovering them all up.Yeah.Vue is the only bastion of freedom left in the front end ecosystem, apparently.
Yeah, I do.I do think we're reaching critical mass or at least a level of pragmatism where we're like, okay, fine.NPM is big enough.We have enough choices.Let's stop continuing to make choices.Let's find the right thing.
And you have independent efforts, like Kent C. Dodd's Epic Stack to try to glue something together.But it is it's glued together.Kent's not trying to sell you a product that is this is how you should build apps.It's just
Hey, I made some choices and I put them together and I highly recommend this.But we do need somebody to come in and say, maybe I'll try to make a product out of this or try to do something to sell this to you.
And Vercel did that in a way through hosting, I guess.I guess you could kind of argue the same thing for Laravel.It's like, oh, look, here's this free framework.And by the way, we can host it for you.
But they just got so invested in building for the ecosystem rather than you see for sell just kind of wrapping companies like up stash, you know, for storage clients and things like that, and just reselling it to you at the end of the day.
Yeah, I think there's an opportunity.And I think frankly, Kent is most poised to do this.Again, I'm an outsider.What do I know about anything?
I think Kent is most poised to do this in that he can take a collection of packages and wrap them up and add some taste to it.And he could market it as a framework.And I think
I haven't looked at the epic stack very much, but I view the epic stack a little bit as like a starter kit almost, which is great.Starter kits are awesome.They, they help you start.That's a good thing.
I think he could go a step further and wrap it all up and make it an actual framework. And that is not totally different than how Laravel started.
There's a PHP framework called Symfony that provides a lot of great core fundamental components, including the HTTP layer and turning things into requests and responses and some of the command line stuff.They've got a ton of these great primitives.
And it's reductive to say that Taylor came in and added taste to symphony.That's not fair.But what Taylor did was, in the beginning, a lot of the underlying components were symphony components that he extended.
He extended the symphony components and definitely added taste, yes, but made them all much more cohesive. And so additionally, there's a package in the PHP ecosystem called fly system, I think, and it's an abstraction over cloud storage providers.
And what Taylor did with Laravel is he pulled in fly system, and then built a layer on top of it that made it Laravel esque and cohesive with the rest of the framework.
but still relies on fly system to do that negotiation of, well, this is going to B2 and this is going to S3 and this is going to R2.And so we have to do all that a little bit differently, but Laravel sits on top of that and takes advantage of that.
I think Kent could do the exact same thing and be like, yeah, it uses, let's say drizzle under the hood, but I have my own layer on top of it that also speaks with my Q job layer, which uses this Q job driver under the hood, but it's all Epic web.
And here are the docs for Epic web.You don't need to go check the docs for drizzle or whatever.You have one place to come for documentation.
And that's one thing I do also love about Laravel is like, if I'm worried about the database or the file system or the queues or the crons or the email or the auth or the whatever, I can go to Laravel.com.
And like, maybe if I get down in the weeds, I need to go to fly systems, get hub and look up some, you know, esoteric thing, but like file storage, there's like 12 pages of docs on that on Laravel.And so I don't know what Kent is up to.
I think he's got the mind share and the talent to do it.I don't know if that's what he wants to do.And I don't know if it would work, frankly, but I think it's an interesting idea.
Yeah, that is interesting.Redwood has tried to do some of that stuff like it packages, Prisma and storybook and what kind of just V that's in transition, but it's pulled in a lot of those pieces that you have to set up for configuration.
And I think what sets it apart from a starter kit is the fact that when there are upgrades, we handle all those things for you.But I feel that when you're talking about documentation, it's like, should we include all this stuff on ours?
Because then we're maintaining documentation for code that we didn't really write.
And so then that gets a little fuzzy sometimes.But it is it is kind of a weird line to walk there.
Well, look, we keep talking about this stuff.This is probably I feel like the third or fourth episode that we've been kind of talking about this.And so I think it's a good sign for the future, ultimately.
I hope so.And it's fun seeing like how people are approaching the same problems from a different angle, where I would say like Laravel's approaching that from more of a back end first.
And then you have other people that are approaching it from a front end first.And, you know, Aaron, I really appreciate what you were saying about like, it doesn't have to be either or it can be both and, which is kind of an exciting place to land.
Yeah, that's a that's another thing that I really appreciate about the Laravel ecosystem.And I think primarily Taylor, and this stands opposed, this is opposite of DHH.And I happen to respect DHH a lot, but DHH is very anti JavaScript.
And that's fine.Like, that's, that's totally okay.I get where that's coming from. But Taylor, I think, to his great credit, and I don't know if it's like, I don't know if he's being magnanimous or if he's just being ruthlessly strategic.
He looked at it and he's like, people want to use React.We got to have a good story.We've got to have a way for people to do that.
And I won't make any judgments on if that's because he just wants to embrace the React world or he wants to like conquer the entire web world, including like letting React people use the back end.
But regardless, the outcome is awesome in that you can come to Laravel and keep your strongly held beliefs about React on the front end and be very happy and very productive.And I think that's a great place for us to land.
Awesome.I know we're about a time, so I will go ahead and call it.But Aaron, I thank you so much for joining us today.It's been a pleasure.Yeah.
Thanks for having me.Yeah.
So if you are listening on your podcatcher of choice, please leave a rating and review.It helps other listeners find episodes like this one and bring on other guests and fantastic sponsors like WorkOS.For now, that's all we got.
