Aaron Francis

Ian & Aaron are joined by Sam Selikoff to discuss React Server Actions & Server Components, why it's important to have one set of opinions, and yes, the infamous SQL Injection Slide at NextConf. Sponsored by LaraJobs & Screencasting.com. Sent questions or feedback to mostlytechnicalpodcast@gmail.com.

Watch on YouTube →

Transcript

Ian

00:00:00 – 00:00:05

Alright. Welcome back, everyone. We are here with, I guess it's emergency episode.

Aaron

00:00:05 – 00:00:07

Emergency pod.

Sam

00:00:09 – 00:00:11

Emergency pod. I've always loved it.

Aaron

00:00:11 – 00:00:21

Yeah. Usually usually, they're for, I think they're usually for, like, political happenings, but this is, you know, this is the biggest thing that's happened in our world in a long time.

Ian

00:00:21 – 00:00:46

So Breaking news. Breaking news on Twitter. So we're here with Sam Selakoff, you know, buddy of mine for a while now. And so we figured since we've we're partially a React show at this point, since we seem to talk about React every week, And Sam's a React, guru, and he became the main character on Twitter this week. That week He's

Aaron

00:00:46 – 00:01:13

the most memed man on the Internet this week. This is the man that put a sequel injection attack inside of a button, and he is here to tell us why it's a great idea, apparently. This is this was my favorite this is my favorite week on the Internet because, like, you and I have been Internet friends for a while. You and Ian are, like, in person friends, but I'm like, I know that guy. That guy in every single meme, I'm like, yeah.

Aaron

00:01:13 – 00:01:20

It's actually pretty funny. So emergency pod to get you here to to talk about it, but we're gonna talk about a lot of stuff.

Sam

00:01:21 – 00:01:28

Nice. Yeah. I was saying that too. I was open I was at still at the conference in San Francisco, and every time I open up Twitter, it was just like my fate. I was like, I know that guy.

Sam

00:01:28 – 00:01:33

I was like, alright. I'm getting tired of this. Yeah. No. It was it was actually a blast.

Sam

00:01:33 – 00:01:37

It was a lot of fun. And, yeah. We'll we'll definitely talk all about it. So

Ian

00:01:38 – 00:02:08

So maybe you could lay the groundwork a little bit because, I mean so just baseline what you do and you're connecting to React and then where you were, you know, when this happened. At first, I didn't realize it was, like, real time. Then I was like, oh, like, he's at a conference doing this, and then, like, it's all blowing up and everything. So give give us your quick little background because some of our audience definitely isn't in the React world and might not know you, and then we can dive into I'm sure they've seen your face at this point, but they might not know who you are and what you do. So

Sam

00:02:08 – 00:02:28

Definitely. And, we wanna cross post this to our podcast too. So just to kinda lay the groundwork because I think the conversation will be good for both, you know, folks who are back end Laravel developers and then folks who follow us who identify more as front end developers. I think there's like a lot of good stuff that we can talk about. So, you know, I started program about 10 years ago.

Sam

00:02:28 – 00:02:59

I actually learned MVC through Symphony. So Pearl was my first language, but PHP was my first, like, web framework, experience. And, basically, kind of fell in love with front end early on just from some work projects that were pretty, like, dynamic, I guess, like heavy, rich clients. There was like a survey that I built at this financial software company, and it was using d three to do data visualization. And I was using Backbone at the time.

Sam

00:03:00 – 00:03:35

And Backbone didn't have, like, a router, so I wanted to be able to send the survey around to everyone in the company, have them, like, click on clients or quarters and have the data visualization, like, charts update and then push, you know, searches and filters to the URL so they could share some subpart of the survey. And so, that's kinda when I fell in love with JavaScript and realized that's, like, the part of web development that I love the most. And, you know, the DataViz stuff was fun. I think you have a accounting background, Aaron. I was studying, like, finance and economics.

Sam

00:03:35 – 00:04:06

And so, when I first started learning programming, that was, like, really fun for me to be able to do some of that stuff in the browser and then make it do exactly what I want with SVG and interactions and all that good stuff. So I started doing backbone and Laravel as the back end or not Laravel, PHP Symphony at the time. I kinda wish I would have found Laravel back then. My history could have been very different. I didn't even know it existed, but this was, like, in 20 this would have been in, like, 2012, 2013.

Ian

00:04:07 – 00:04:13

Yeah. It was I guess it was Laravel was maybe just out. Yeah. So Laravel's 10 ish.

Sam

00:04:13 – 00:04:18

So Yeah. But Symphony was pretty hip back then. Right? My brother used it. That's why I learned it.

Sam

00:04:18 – 00:04:18

So Right.

Aaron

00:04:19 – 00:04:21

It's cool it was cool enough.

Ian

00:04:21 – 00:04:21

It's Yeah.

Aaron

00:04:21 – 00:04:23

There's no Laravel, but it was cool enough.

Sam

00:04:23 – 00:04:57

Exactly. So anyways, I started doing more and more on the front end and then kind of found Amber. And Amber was, like, kind of a logical conclusion of, like, where my interests were pointing me towards because it had a built in router. It had you know, it basically fully embraced, like, the SPA model where your first the first thing you wanna do is start making rich client side stuff. And, again, because of the kinds of things I was building, I was like, this is the most important part of this app.

Sam

00:04:57 – 00:05:27

And so this is what I want a tool that's kinda good for, I guess, or like built for. It's built to build interactive UIs on the web. And, basically, most of my jobs before I started working for myself were, like, internal back office apps or, you know, and then eventually I worked at TED with Ryan and we were building tools to help the team run the conference. And there was all sorts of stuff like that where, you know, we used Ember there as well. And I remember us adding an Ember front end to, like, a Rails back end.

Sam

00:05:28 – 00:06:07

And, the only thing that we did was basically put the Ember app instead of the view the templates from rails, the ERB templates. And it was this long list of attendees that was like a master detail UI. And at the conference, this woman we worked with was, like, trying to find people and she would be able to use it on iPad, click somebody, and then see the detail. And then she realized, like, the side scrolling, the the navigation list of all the people didn't reset because, you know, Amber was doing just partial rerendering of the detail view, but the the, the list of attendees and the parents stayed the same. So it preserved, like, the scroll position.

Sam

00:06:07 – 00:06:39

And that, like, blew her mind. That was, like, the most useful thing to her in that moment, at the conference. And so this is always kind of like, the things that really got me going working and that's why I kind of went down the the rich JavaScript path or whatever. And so Ember was kind of how I cut my teeth on, like, UI development and learning how to do state in the browser and all the things that go along with that. And, eventually started using React, you know, and, that's kinda where I am today.

Sam

00:06:39 – 00:06:39

Ian

00:06:41 – 00:06:48

Yeah. So and you do, like, build UI, the course, I guess, what I guess, like, a video

Sam

00:06:49 – 00:06:52

You just be casting site. Yeah. It's like a screen casting site. We make we make courses.

Aaron

00:06:53 – 00:06:54

Launched something. Right?

Sam

00:06:54 – 00:06:56

We just launched a remix course. Yep.

Aaron

00:06:56 – 00:06:58

Yeah. That's what I thought. Okay. Yeah. Yeah.

Aaron

00:06:58 – 00:07:07

Well, we'll we'll need to talk about that too because I've been I just found out that your podcast exists, so I've been binging the back I've been binging back episodes, and so I feel like I've

Sam

00:07:07 – 00:07:07

Oh, wow.

Aaron

00:07:08 – 00:07:09

Caught up on the past,

Sam

00:07:09 – 00:07:09

you know, 4

Aaron

00:07:09 – 00:07:13

or 5 months and Awesome. Too. Yeah. It's been fun.

Ian

00:07:13 – 00:07:29

So I guess for your audience too, maybe we'll just quick intro ourselves so that everybody's on the same page. But, yeah. I'm Ian Landsman. I'm, been selling a help desk product for 20 years, all PHP. You know, it's Laravel.

Ian

00:07:30 – 00:07:36

Taylor of Laravel worked here for a while. I run the Laravel job board and a bit of Yeah.

Sam

00:07:36 – 00:07:38

You knew Taylor, like, when he started Laravel. Right?

Ian

00:07:39 – 00:07:41

Yeah. Just a little bit after. Yeah. He worked with

Aaron

00:07:42 – 00:07:43

Ian is the godfather.

Sam

00:07:43 – 00:07:46

Yeah. That's right. That's how I think about it. Community. The godfather.

Ian

00:07:46 – 00:07:57

Yeah. So, so, yeah, it's kind of, in the Laravel circles is my main thing. Do not like JavaScript. Do not like the front end JavaScript. I'd like to avoid it Mhmm.

Ian

00:07:57 – 00:08:10

As much as possible. Although, I do also understand the benefits of it and like to have things work magically. I just don't like to necessarily be in there. I like to drop a component in and have it work magically. I don't necessarily want to write the component.

Ian

00:08:11 – 00:08:11

Aaron

00:08:12 – 00:08:14

Hate the JavaScript. Love the component. I There

Sam

00:08:14 – 00:08:16

you go. Hey. Yeah. That's music to my ears, man. I'm

Aaron

00:08:17 – 00:08:21

Kinda how I feel. Yeah. Yep. Yeah. Hi.

Aaron

00:08:21 – 00:08:34

I'm Aaron. This is my voice. I always feel like when you're when you got 3 people on a podcast and they all kinda sound the same, you never know who's who. So I'm I'm Erin. I'm a developer educator at a database company called Planet Scale.

Aaron

00:08:34 – 00:08:49

So I make a lot of, YouTube videos, these days. So we got a lot of video stuff we could talk about too. But Absolutely. Yeah. Laravel developer, also primarily back end, not a big front end, guy.

Aaron

00:08:49 – 00:08:57

And, yeah, that's probably enough. Love love making the videos. Love teaching. So we You have great

Sam

00:08:57 – 00:08:57

with those.

Aaron

00:08:58 – 00:09:02

Yeah. Thanks. I really I appreciate that. That's a lot of fun. Yeah.

Sam

00:09:02 – 00:10:08

I I was gonna say one I've been thinking about well, I've been thinking about this sort of thing for a while, but one way we could kind of kick off the conversation or at least one way I think about I can talk about the conference talk soon, but I was thinking to set some context, like, so I ended up kind of being, like, a front end developer or whatever. And the front end ecosystem, JavaScript ecosystem, you know, as folks who are more back end developers have pointed out, is really fragmented. It feels like there's a lot of wheel reinventing going on, and it's confusing why people would use some tools or setups, when, you know, more established tool sets exist like Ruby on Rails, like Laravel that give you so much more out of the box. And I think one one way I've started to think about this is like kind of going back to my story of how I even became like more in the front end community is basically that story. And one way I've thought about putting it is high floor versus high ceiling.

Sam

00:10:09 – 00:10:43

So if you think this is kind of, I'm just working workshopping this, but just let me split off for a little bit. If you think about starting with a established framework, like a Laravel, you're starting off at an extremely high floor. Right? And if you go back to the development of something like Laravel or Ruby on Rails, there's a floor there that keeps getting raised up with every release, every feature, every new package. So that, you know, DHH talks about this a lot in his keynotes where he says Ruby on Rails about conceptual compression, doing more with less.

Sam

00:10:44 – 00:11:33

So we want to have a high floor, and that's kind of like where we're starting the whole process of, like, working on these frameworks. And, on the other hand, if you put yourself in my shoes back when I was working on that survey, I had an idea for this UI I wanted to build. And I had an idea for the end state, the ceiling, and I I didn't wanna be limited by anything. So I knew I had to just drop down to JavaScript because I wanted to be able to use all the browser APIs as opposed to an abstraction that, you know, maybe a back end tool gave me or some other library gave me. I mean, I even ended up ditching, like, charting libraries to use d 3 because d 3 is in that same level of abstraction where you just get raw access to SVG elements and all the JavaScript that you would ever need because you have access to the full set of browser APIs.

Sam

00:11:34 – 00:11:57

And so that's kind of one way I've been thinking about this. And if you think about the JavaScript folks who have an idea for a UI they wanna build, like Trello, let's say, when it first comes out. We're building Trello. We have an idea for the UI, the user experience, how we want that part to be like the differentiator, the novel part of this product, then or a Figma or whatever it is. Right?

Sam

00:11:57 – 00:12:32

But I think Trello is a good example because that's something that we could build today. Then you want a tool that's gonna help you do that and feel like you can build that without restriction. Whereas, you know, again, as folks like y'all have pointed out, I think rightfully so, if you're starting a new company and you need to get something quick, you wanna hire a floor to start out with. And then if you look at how both ecosystems have developed over time, the Laravels and the rails, which start off on a high floor, have basically been trying to raise the ceiling with things like turbo links or what is it? Livewire

Ian

00:12:32 – 00:12:32

Mhmm.

Sam

00:12:32 – 00:13:13

Or all of these abstractions that have come to Rails and Laravel to make it so that we can get more of the rich interaction on top of this high floor. And so they've been trying to raise the ceiling, but it's not gonna be the same unless you drop down a JavaScript and then you lose some of that cohesion in the integration. Whereas the JavaScript folks said, let's start with a high ceiling, which has a really low floor because we gave up all the stuff that these integrated server side conventional frameworks give us, And let's try to raise the floor. So we're starting with a high ceiling and let's try to raise the floor. So that's kinda how I see the 2 ecosystems having started and growing over time, and they serve different needs.

Sam

00:13:14 – 00:13:30

But, ultimately, I think we're all trying to have tools that give us a high floor and a high ceiling. It's just that the front end system has focused more on the ceiling and the back end system has focused more on the floor historically. So that's kind of like I'm just workshopping that, but that's kinda how I've been thinking about things.

Aaron

00:13:30 – 00:13:33

What do you got, Ian? What do you I know I know you're ready.

Ian

00:13:34 – 00:13:50

That part seems fine. Like, I think that's I I think it to me, it's kinda I I've been taking it more even simpler than that, I think, in the sense of just, like, in terms of what's going on and, like, you know, the JavaScript putting SQL in the JavaScript on the front end and all that stuff. Like,

Sam

00:13:51 – 00:13:52

we'll get to that. We'll we'll

Ian

00:13:52 – 00:13:52

we'll we'll

Aaron

00:13:52 – 00:13:55

saying that and not let you defend it, but we're gonna

Ian

00:13:55 – 00:13:58

keep saying it. Yeah. But, like No. I'll defend it. Don't worry.

Ian

00:13:58 – 00:14:13

No. No. I I actually I'll yeah. I'm not even concerned with that in the sense of, like, obviously, everybody was going crazy on it, but I'm sure I was very confident that there wasn't, like, a SQL injection vector. I would have been very surprised if they were putting something like that out there.

Ian

00:14:13 – 00:14:45

But but I just think that there's all these JavaScript developers, and they just wanna stay in JavaScript. Just like I'm a Laravel developer, and I just wanna stay in Laravel. So, like, I like LiveWire because I can stay, like, 90% of the time in Laravel and only go to JavaScript when I have to. And then if you're a JavaScript developer, you wanna stay in JavaScript and only go to thinking about the database or, you know, what back end systems when you have to. And so if we can shove that stuff in the JavaScript as much as possible, then I don't have to think about what the server is doing in server side code.

Ian

00:14:45 – 00:15:16

I can just stay in my JavaScript land and know that I can query something from here or whatever and get the data back and do all the weird JavaScript array slicing and whatever you do in JavaScript, and all that stuff, without having to leave the zone I'm comfortable with. And since now we've made so many JavaScript developers because, like, the world's gone a little bit haywire with, like, everything is a SPA and, like Mhmm. Everything is ultra reactive all the time. Right? That you have all these people who have become JavaScript developers, and it's like, yeah.

Ian

00:15:16 – 00:15:26

Well, we just wanna do the other parts of the coding stack from here. We don't wanna go over and learn Laravel or Rails or all those things. So that's, I guess, my That

Sam

00:15:26 – 00:15:34

is a simpler explanation, and it's also totally valid. I mean, DHH always talks about how much he loves Ruby. And so that's Right. That's totally Right. Why he

Ian

00:15:34 – 00:15:37

needs to know how to stay in Ruby. Right? You know.

Sam

00:15:37 – 00:15:58

But but it is I do think it's interesting because because everyone in the react community was in other community. Well, everyone who created all these front end tools were using back end tools or back end server side languages first. So for me, I I enjoyed Symphony. And then I started using Rails at my job, and I really liked I mean, Ruby is awesome. It's awesome.

Sam

00:15:58 – 00:16:12

And Rails is awesome. And, I didn't have a problem with Ruby. And the only reason I use JavaScript is because I wanted to animate SVGs when you hovered them or clicked on them. So that was something you can't do with Ruby. Yeah.

Sam

00:16:12 – 00:16:27

Unless you write CoffeeScript or you know, which was a terrible idea ultimately in in retrospect. But, I wanted I that was my motivation. I wanted to animate a pie chart when you hovered it with a mouse. That's what I was trying to do. So, yeah.

Sam

00:16:27 – 00:16:28

Humble beginnings.

Aaron

00:16:29 – 00:16:40

Yeah. I like I like the I like the floor ceiling analogy. I would I would extend it to say that the JavaScript floor is, like, underground. Y'all it's like Oh, yeah. It's below the basement.

Aaron

00:16:41 – 00:16:42

It's way down there.

Sam

00:16:42 – 00:16:45

It doesn't pass the inspection code anymore for a house.

Aaron

00:16:45 – 00:17:00

Digging. Y'all gotta just stop digging at some point. But yeah. So I like that. I do think, when you start to talk about, like, turbo and Livewire, which is which are very similar to, you know, live view over in the Phoenix, Elixir world.

Aaron

00:17:00 – 00:17:32

Same kind of like Mhmm. Even h t m x is is very similar to these ideas where it's, you know, primarily server rendered sent over and then morphed out to be, you know, the front end. I can understand, I think, the argument there that the ceiling is a little bit lower because of the things that you you can do, not with those technologies, but just with the paradigm itself of, like, we're gonna send some new HTML over the wire and morph it in. Like, yeah, you can't really do a hover animation in that case. Not very not very performantly.

Aaron

00:17:33 – 00:18:19

But I do I also think that there's, like, there's another paradigm that is sealing less, and that's, with a little bit of protocol glue in the middle, and then you with a little bit of protocol glue in the middle, and then you put your whatever, you know, React, Vue, Svelte. You put your that front end, on the front end. And then you have you're back into, like, the the limitless ceiling world of I can just use react for anything I want, but I still get the power of, you know, queues and database drivers and emails and cron jobs and all of that from my Laravel or Rails application. So I feel like that's a little bit like, if you're trying to do HTML over the wire, I get it. Yeah.

Aaron

00:18:19 – 00:18:25

You're gonna get stuck at some point, maybe. But otherwise Mhmm. You could go full React land.

Sam

00:18:26 – 00:18:47

Yes. And, yeah. So inertia is nice because it it, takes care of the protocol, basically, and it makes that as, like, invisible as possible. And that's basically what we were doing with SPAs. If you think about it, our first video screencasting site, which is embermap.com was an ember SPA, with a rails API back end.

Sam

00:18:47 – 00:19:32

And so we used rails for sending emails and for doing jobs and for authentication and database, you know, active record, all that stuff. And so the protocols, you spent more time back then because something like inertia didn't exist or this the APIs or even GraphQL was another way to kind of solve that problem, to kind of try to minimize the the loss there in productivity. But, I guess this kinda leads to my talk at NextConft last week, which is really about it was it's more about it's about React. It was at Next Conf because Next is, like, the first implementation of kind of a newer set of APIs coming to React. But, hold on.

Ian

00:19:32 – 00:19:43

Hold on. Can we can we stop for one second? I've I've avoided this for a very long time. Very, very long time. But I guess in this conversation, I'm gonna have to actually know what the hell next is.

Ian

00:19:43 – 00:19:47

Like, could you give me the, like, one minute explanation of what the hell next is? Because, like, I

Aaron

00:19:48 – 00:19:49

seconds. Make it 30 seconds.

Ian

00:19:49 – 00:19:55

I've literally avoided this intentionally the for a year or 5 years or whatever it's been going on.

Aaron

00:19:55 – 00:20:05

Ian, there's no better there's no better cohost for me than you. Alright. Give us 30

Ian

00:20:05 – 00:20:06

seconds. What is it? It's like

Sam

00:20:07 – 00:20:15

Laravel 1.0 or whatever. I got it. You know? For, for react server side though, executed. Well, that was the big thing.

Sam

00:20:15 – 00:20:28

So react has the ability to do server side rendering, but setting it up to do so in a tool chain Was tricky. Was complicated. And so Next was the first to package it together. Okay.

Aaron

00:20:29 – 00:20:34

So Next is a framework on top of React.

Ian

00:20:35 – 00:20:38

Mhmm. Is it client side also?

Sam

00:20:38 – 00:20:44

It's like a it's like no. Doesn't doesn't view you all use view. Right? Doesn't view have Nuxt? It's kinda like that.

Ian

00:20:45 – 00:20:46

I don't know anything about it.

Sam

00:20:46 – 00:20:47

For React. But I've

Ian

00:20:47 – 00:20:52

never I've never used Nuxt. I'm not sure I understand anymore now. So So So it just it

Sam

00:20:52 – 00:20:57

just adds it like, React by itself just renders. Right. And it knows

Ian

00:20:57 – 00:21:00

So it, like, provides routing and stuff like that too.

Sam

00:21:00 – 00:21:11

Right? Exactly. Routing, conventions around file system names, and Okay. Bundler set up so you can import, you know, modules from other modules because JavaScript is

Aaron

00:21:11 – 00:21:13

Just turtles all the way down.

Sam

00:21:13 – 00:21:30

Right. You know, it's funny because you start using JavaScript and you're, like, coming from Ruby and you're, like, well, yeah, Ruby has, like, you can import packages. Like, it has a concept of packages, like, every other freaking programming language. Yep. And, like, JavaScript didn't have that for a long time.

Sam

00:21:30 – 00:21:58

They act actually, who the cats who let created ember, like, spearheaded all of that. But it's because JavaScript, the language has many, many run times. It originally only ran in the browser, then it started running on the server with node. Right. And even if you're not writing it an HTTP server with JavaScript, you still want to do things on the server like prerender your React app into HTML so that it can be served up on a CDN or something like that, which is, like, kind of what Next did at the beginning.

Sam

00:21:58 – 00:22:01

Mhmm. So, anyways, getting, I'm not

Aaron

00:22:02 – 00:22:06

tell me what is next. Now that now that now that you know, explain it back to me.

Ian

00:22:06 – 00:22:23

I get the concept. It's a a framework over React. Yeah. Still not totally sure if it also runs on the front end or if it's only for back end, but I I get the general idea of the it's providing all the glue stuff so that you could have routes and connections. Yeah.

Sam

00:22:24 – 00:22:24

It does run on the

Ian

00:22:24 – 00:22:29

back end. Of the packages and stuff like that. Okay. So it's just a back end. Mhmm.

Ian

00:22:29 – 00:22:29

But with

Sam

00:22:29 – 00:22:32

It's no. It's both. It runs both on the front end and the back end. End.

Ian

00:22:32 – 00:22:36

Yeah. Mhmm. Jobs are so close. You were so close. Yeah.

Sam

00:22:36 – 00:22:37

The way the easy way

Aaron

00:22:37 – 00:22:38

to think about

Ian

00:22:38 – 00:22:39

it is Right? Yeah.

Sam

00:22:41 – 00:23:00

The easy way to think about it is, like, you start off with an SPA. And, again, I think about it from Amber because, you know, when SPAs first came out like Trello, Trello didn't do, like, server side rendering because the value of Trello was not in, like, the pages showing up on Google or whatever. It was like, you have to drag the boxes to lanes or whatever. Yeah. So then eventually, you have that running.

Sam

00:23:00 – 00:23:22

And then it's like, well, now we have different boards. What if we could prerender them so that when you first see it, you get the HTML, the browser can get to the first paint faster and then load the JavaScript, which can hydrate, which is like adding all the drag listeners to the elements that are already there. Yeah. You know, that kind of thing. So that so that's how it does both the front and the back.

Sam

00:23:22 – 00:23:26

But, like, tailon css.com is a Next site. So they use Next. Right.

Aaron

00:23:26 – 00:23:31

They used to be they used to be one of us, and now they're may have abandoned us.

Ian

00:23:31 – 00:23:33

They're way over on the dark side now.

Aaron

00:23:33 – 00:23:36

They are on the dark side. They're all really all in on React.

Ian

00:23:38 – 00:23:40

Okay. So I think I interrupted you there, bro.

Aaron

00:23:40 – 00:23:42

So now that we don't know what next is.

Ian

00:23:42 – 00:23:44

Continue. No. We know. We're totally solid.

Sam

00:23:46 – 00:24:16

So, yeah, I, I was at next comp last week, and I gave a talk on about React, but it was at NextComp because React just introduced some new APIs. React's really gone through, like, kind of 3 phases of, like, big architectural changes, I guess you'd say. Mhmm. They have the class components and then they had hooks that let you just write function components. And then now they're introducing these APIs, server components, and server actions that are kind of like this third phase of the paradigm, I guess.

Sam

00:24:17 – 00:24:32

And Next JS is, like, the first framework to implement this new paradigm. So that's kind of what my talk was about. How Next is this, like, the future of react in next today. And all these are very new, but that that's what it was about. It was about the paradigm.

Sam

00:24:32 – 00:24:35

And so so I mean, yeah,

Ian

00:24:35 – 00:24:46

I mean, I'm just just for our listeners, React added new primitives, essentially. And then Next has implemented those primitives into something you can utilize.

Aaron

00:24:46 – 00:24:47

That seems right.

Ian

00:24:47 – 00:24:48

So to speak.

Sam

00:24:48 – 00:25:08

Yes. Okay. Yes. And the the the thing about server components and server actions, these new APIs, is that unlike previous APIs that have come to react, which were things like hooks, if you've ever seen, like, use state or use effect. I know about use Those were You don't know about you.

Ian

00:25:08 – 00:25:12

I know about you. That's the part of React, I actually know.

Sam

00:25:13 – 00:25:16

Dude, I know you've been slinging some reactions. I know you like it.

Ian

00:25:16 – 00:25:18

I know you gotta tell what you're fanboy on this podcast.

Sam

00:25:18 – 00:25:20

I know you're the godfather. I

Ian

00:25:20 – 00:25:20

know you're

Sam

00:25:20 – 00:25:24

the godfather of Laravel, so you gotta say you don't like react. But I know No. You know you.

Ian

00:25:24 – 00:25:27

That's me. That's me. Yeah.

Aaron

00:25:27 – 00:25:28

I don't like React.

Sam

00:25:29 – 00:25:32

You said you didn't like React at the beginning. Me? Just saying.

Ian

00:25:32 – 00:25:32

No. I like that.

Sam

00:25:32 – 00:25:34

I think you said that. Maybe you just don't like JavaScript.

Ian

00:25:34 – 00:25:41

Yeah. I don't like JavaScript. I said I don't like JavaScript. I like React. I mean, if I have to use JavaScript, I like React over you.

Ian

00:25:41 – 00:25:43

Yeah. But

Sam

00:25:46 – 00:26:02

So I can sum up my talk basically in, what you guys said earlier, which is you don't like implementing components, but you like using them, which is why we all started using any front front end stuff because you wanna go to radix and grab a drop down because it's nice.

Aaron

00:26:02 – 00:26:07

Hoisted hoisted by our own to him. He got us. He was he was so ready for that.

Ian

00:26:07 – 00:26:08

He was ready.

Aaron

00:26:08 – 00:26:10

Throw it back in our face.

Sam

00:26:10 – 00:26:19

So for the same reason that you all like using React and everyone does, when they get to use a library that solves their problems and they don't have to implement it.

Ian

00:26:19 – 00:26:25

Hold on, Aaron. You do like it cause you like your remotion which is along these lines of a few controls.

Aaron

00:26:26 – 00:26:27

Very, very good. Yes.

Ian

00:26:27 – 00:26:31

There we go. I love that. That's more of a full application more than the component, but still.

Aaron

00:26:31 – 00:26:32

Sam

00:26:32 – 00:26:46

agree. It's driving home the point. React enables really awesome abstractions on top of it. Right? And there's a there's a reason that remotion is written in React and not Vue because React's whole rendering model is effectively like frames.

Sam

00:26:46 – 00:27:03

Every frame per second or whatever, every render pass is a frame and the tree is guaranteed to be unique. And the way you change things is by making a new frame. It's how game engines work. And so tools like Remotion can exist because of the abstraction level of react. But but it is extremely low level.

Sam

00:27:03 – 00:27:18

And, you know, Aaron, I've heard you say, like, it feels like I don't need to know this stuff because I'm a fan of the pod. And I have a video from 2 years, 3 years ago when I was learning react. And I basically say all that same stuff. I'm like, am I doing something wrong? I wanna, like, load data and render a page after I click a link.

Sam

00:27:18 – 00:27:47

This is ridiculous. I feel like I'm using the wrong tool. And that video is called React as a programming language for UIs because I realized that React itself is really should be thought of more as a programming language, which means that application developers shouldn't be building apps with it. But there's this gap, with the framework ecosystem, which has nothing to do with, like, the floor and ceiling stuff. It just has to do with us not having a DHH or a tailor to glue all these pieces together.

Ian

00:27:47 – 00:27:47

So I

Sam

00:27:47 – 00:27:50

actually do I'm totally on board with all of that.

Aaron

00:27:50 – 00:28:08

I think that's a big part of what's going on in the JavaScript ecosystem is you've got a few big companies with untold amounts of money, and everybody's trying to, like, carve off their own portion of this massive ecosystem. And there's no one, like, editor, curator that has extremely good taste that's, like,

Sam

00:28:17 – 00:28:34

I mean, DHA is my dad. I'm a huge fan of conventions over configuration. Like, I've been wanting that in the JavaScript ecosystem forever. And, I'll be the first to say, like, even the frameworks today that are, the most mature in the React ecosystem don't have a dang model layer. They don't have a model library.

Sam

00:28:34 – 00:29:05

Like like fat controllers, skinny fat model skinny controllers, I think is one of the most important architectural takeaways from MVC. And everyone brings their own model layer, doesn't integrate with the controllers, and a lot of people don't even do that. So I think this is a huge gap in the application frameworks for React that has nothing to do with React as a UI library. Right. But it's the reality if you are a front end developer that, you have to you have to piece those things together.

Sam

00:29:05 – 00:29:20

And it's like you guys have said, like many people have said, it's a bad trade off to make in a lot of situations where you just wanna ship a product. So I'm totally on board with that side of the of the critique for sure. Yeah. Alright. So I'm trying to get Taylor to to start Laravel JS.

Sam

00:29:20 – 00:29:22

You know? I mean,

Aaron

00:29:23 – 00:29:30

how many Lambos does a guy need? If he did that, like, he could he could consolidate so much power under himself.

Ian

00:29:30 – 00:29:32

This is real godfather stuff we're talking about.

Aaron

00:29:32 – 00:29:36

Yeah. Seriously. We can't publish this now. This has to be backroom only.

Ian

00:29:37 – 00:29:37

No. We should

Aaron

00:29:37 – 00:29:38

But yeah. We should

Ian

00:29:38 – 00:29:39

get Taylor here.

Aaron

00:29:39 – 00:29:45

He really could. Here's here's a quick quick side note before we talk about how Sam is doing sequel injection live on stage.

Ian

00:29:45 – 00:29:46

Right.

Aaron

00:29:46 – 00:29:55

What's the deal with Adonis JS? Why does nobody use Love or know Adonis JS? Which is basically, see, that's that's what I don't understand.

Ian

00:29:55 – 00:29:57

I've seen the name, but that's

Aaron

00:29:57 – 00:30:04

It is it is Laravel, but in JavaScript, but it's just not, like, I don't know what it is. I don't know if they're bad at marketing

Ian

00:30:05 – 00:30:07

or Very Laravel y in their example.

Aaron

00:30:07 – 00:30:32

It's almost it's one it's almost a one to one copy of Laravel, but in JavaScript. And I don't know if it's just not sexy or there's no big company behind it or they're not, like People don't want to. Good at marketing or something, but this is the thing. It's like, this is a fully featured like, you need to write actual back end code because you're, like, building a real application. I feel like Adonis is that.

Aaron

00:30:32 – 00:30:53

But, you know, I feel I feel like a lot of the the JavaScript stuff that we see, especially in examples, is very infrastructure heavy and not very back end heavy. And so you'll see stuff like, hey, just call out to Supabase or call out to, you know, all these other hosted providers. And there is, like, a very, very thin back end. And so maybe that's

Ian

00:30:53 – 00:30:53

a part

Aaron

00:30:53 – 00:31:04

of it is JavaScript developers typically outsource the infrastructure, which is becoming more full featured, And so you just call APIs instead of having a back end.

Sam

00:31:05 – 00:31:30

Right. I think yes. I I think that there's some of that is true. I also think maybe it could be just a cultural thing where, maybe JavaScript developers, just the culture is not as onboard with just getting on to other people's opinions. Maybe we just needed a different personality to scream at us for 10 years the way Dale the the way DHH didn't say, you know, your app is not unique.

Sam

00:31:31 – 00:32:11

And the things that are different that don't matter is way better for us to just have one way to do it so you can move on. On the the back end as services thing, I will say, like, I had I don't know if you all have ever had this and if you've ever done any significant SBA work, but I did have a very magical experience when me and Ryan were at the TED conference. And Chris, the guy who owns TED, said, I need an app so I can send messages to speakers, on stage. And I need it in like, you know, half an hour. And I wanna be able to write messages from my computer, show it to them because they always take too long or whatever.

Sam

00:32:11 – 00:32:33

I wanna be able to flash it. I wanna be able to show them their time left. And in, like, 13 minutes, me and Ryan created a Ember app and signed up for Firebase, which we had never used at the time, and imported it. And we had an Ember app with 2 routes. 1 was, like, admin where you could type things and flash different times, and the other one was, like, the stage.

Sam

00:32:33 – 00:32:58

And it was, like, the most magical developer experience I've ever had. And that was really significant for me because for the next several years, I was obsessed with this idea just, like as a philosophy of, like, okay. We need to go all in on the client and the back end needs to become as dumb as possible because this enables this incredible thing. And I wasn't writing migrations and I wasn't I didn't have to set up a I didn't have to do any, you know, I didn't have to do any of that. And I've been doing that for years.

Sam

00:32:58 – 00:33:30

So, that that I think a lot of front end developers probably have done something like that and has made them feel like it was only a matter of time before back end services became more and more commoditized and that the unique value offering was in the front end. And so we just want a tool and a setup that lets us just give me a CRUD interface. I can I can do my extra logic here and go to town, and I can get real time for free, all of those kinds of things? So I I think a lot of us have had experiences like that which led us to that. But That makes sense.

Sam

00:33:30 – 00:33:30

Zoom forward

Aaron

00:33:30 – 00:33:38

I I do feel like the Firebase thing is a big turning point where it's like, oh, the back end is just there. I'll just call an API, and everything just happens.

Sam

00:33:38 – 00:33:39

Do you feel like

Ian

00:33:39 – 00:33:58

I feel like kind of touching on I do feel like I wonder if that's an error. Like, if that's incorrect. Or at least I think in some parts of the ecosystem, that's incorrect, and it's kinda interesting because it's, like, in the b to b land where I live. K? Like The real world.

Ian

00:33:58 – 00:34:03

The front end is not at all anything like

Sam

00:34:03 – 00:34:03

that. Trader.

Ian

00:34:03 – 00:34:17

Yeah. Like, because people use horrible, terrible, atrocious front ends. Right? And, like, it's all about the back end and, like, the systems that integrate together and whatever business logic y kind of stuff's going on.

Aaron

00:34:18 – 00:34:23

And the background process automation running 24 hours a day. Yeah.

Ian

00:34:23 – 00:34:27

Doing whatever. Right? And so, that's not core offer.

Sam

00:34:27 – 00:34:32

So you're not just gonna shell that out to some some Yeah. You've kinda posting. Like, I mean, you

Ian

00:34:32 – 00:34:37

can't. Yeah. It's hard anyway. It's very hard. It's not just like you just sign up and, like, it does the magical business logic you want.

Ian

00:34:37 – 00:34:43

Right? It's like, yeah. It's a Right. It can abstract the database and store some data, but it doesn't know what to do with that data. Right?

Sam

00:34:43 – 00:34:44

So Yep.

Ian

00:34:45 – 00:35:05

So it's kinda interesting because then I do feel like maybe that's part of the stuff you see around that people get annoyed at is, like, JavaScript sort of end of things where, like, people build these sort of consumer simpler apps. It kind of pigeonholes you a little bit into that model of, like, where Yeah. A consumer app is defined more like that. I do think that's true. Like, the consumer app, the front end is a bigger advantage.

Ian

00:35:06 – 00:35:21

But then you are then limited in some of the other things you can maybe do. So there is this idea of, like, yeah, as React getting more into, like, back end capability, it's kinda interesting and maybe making it easier to open up some of those more complicated, applications.

Aaron

00:35:22 – 00:35:40

Yes. Yeah. My my my question is always, like, when I see, you know, abstract, you know, back end as a service, I'm like, alright. Well, where do you generate your CSV reports and zip them up and FTP them every night at midnight? Because that's like a process that's a process that, you know, these, you know, these dirty b to b SaaS apps have to do.

Aaron

00:35:40 – 00:36:04

It's like, well, we have to send this file to the local county government every morning at 6 AM. Like, that's an actual thing I used to have to do. And writing all of that stuff in some, like, some no code or, like, by cobbling together some APIs, I'm, like, I don't even know where I would get started with that. And that's the mental gap for me is where do you just write all where do you put all your your actual logic stuff?

Sam

00:36:04 – 00:36:10

Yep. So that was both that was a great segue into the talk. And Yeah. There we go.

Aaron

00:36:11 – 00:36:15

I professionals. We're good at this. Of course, there's a good segue. Yeah.

Sam

00:36:15 – 00:36:33

It's not your first time. It's not your first time. Ian, you said, I think this is an error. And I actually agree with you, and I think a lot of us do. So in the case of my app, my little stage presenter app at TED, it was perfect because I didn't run up against the constraints of Firebase.

Sam

00:36:33 – 00:36:56

Right? And the APIs that happened to have served our needs perfectly. And so it was a great solution for it. But, exactly like you guys say, you run into this boundary. So this is where it's like, if you invert the ceiling and floor thing and the ceiling is now how much back here.

Sam

00:36:56 – 00:37:01

I know this is getting crazy. I'm just and it just came to me right now. So just just roll with it.

Aaron

00:37:01 – 00:37:02

I'll keep going. I love it. Keep going.

Sam

00:37:03 – 00:37:55

If the ceiling is not how high the UI can be, the the the the maximum capabilities for your UI, but the ceiling is the maximum capabilities for your servers, your server side code, and everything you could possibly do in a server environment that had access to all the APIs that a server side language does, then it's actually the same problem. Because if you're using APIs from your react app, then you have a lower ceiling and then you have us doing rails and people doing Laravel and rails saying, well, what if, what if my database doesn't let me wrap up all my data into a CSV report and schedule a job at 6:6 AM every day? Then you've hit you've hit a limit. And so folks like that, like you guys and me in the past have wanted to make sure we could do everything we could because if I'm writing rails, I can do that. I've done exactly what you said with rails.

Sam

00:37:56 – 00:38:05

We had to do that kind of thing with Ebermap, and we had a rail server so we could do that. But now that we don't have a separate server, we have to use another service to Mhmm.

Ian

00:38:05 – 00:38:05

You

Sam

00:38:05 – 00:38:19

know, do x and y and z. And, I think exactly right is that that kind of middle Sam perspective of, like, the middle age, like, the it's like the develop it's like the the meme what is it? The

Aaron

00:38:20 – 00:38:21

The mid width top width.

Sam

00:38:21 – 00:38:23

Yeah. The mid width. Yeah. Yeah. Exactly.

Sam

00:38:24 – 00:38:44

The the left side of the mid width is write all your server code and all your JavaScript code. You know, JavaScript's best at handling the client and servers code is best at handling the server. Midway is, oh, we just need a fat fat client app and we can just delegate all back end services. And then the Jedi is like, no. Write all your server code in your server side and client and the client side.

Sam

00:38:44 – 00:39:17

So Yes. Exactly. For these reasons, React introduced server components and server actions. And so what they do is, just like you guys said, the best part of using React is just rendering the component and not implementing it. But because React runs on the client and has access to the entire set of browser APIs, then you can package those APIs up into a react component.

Sam

00:39:18 – 00:40:00

And so when you render a modal, you know, with radix, it can animate up, It can attach a keyboard listener so that when you hit escape, then it closes it. It can attach a click listener so that if you click outside the element, it dismisses it, and it can trap focus, and it can do anything that you need it to do because it is running in the browser. It's not an abstraction on top of JavaScript, blah blah blah, but it's packaged up in the React component interface. And that makes it fun for you to use and easy for you to use, and it makes it composable with other React components. So server components and server actions are doing exactly the same thing, but for server side

Aaron

00:40:00 – 00:40:08

Okay. Well, hang on. Alright. So I had you I had you at modals. I had you at click events, trapping, packaging.

Aaron

00:40:09 – 00:40:18

That all makes sense to me. Packages up a really complex modals, for example, combo boxes, like, for example, incredibly complex, just hysterical.

Sam

00:40:18 – 00:40:19

Mhmm.

Aaron

00:40:19 – 00:40:30

But when you package it up into a React component, you get this nice little surface area of, like, well, here's the thing I want you to show when you click. Great. Nice. Awesome. Love it.

Aaron

00:40:30 – 00:40:47

Good packaging. Good developer experience. Server actions and server components, how is that the same? And what is, like, the what is the thing that is being packaged? Is it server side code?

Sam

00:40:47 – 00:40:48

Yes.

Aaron

00:40:50 – 00:40:54

Much to consider. Okay. Tell me tell me tell me more.

Sam

00:40:54 – 00:41:06

So consider consider a Laravel app that serves a list a table of users when you visit the home page. K. Easy. Got it. So you define an index route.

Sam

00:41:06 – 00:41:13

You hit you make a request. The request comes in. The top of the controller starts running. The controller fetches the data using Eloquent from your database.

Ian

00:41:14 – 00:41:14

Right?

Aaron

00:41:14 – 00:41:16

It's it's Man, speaking my language.

Sam

00:41:16 – 00:41:25

It's an async function. Right? So when PHP runs, it runs you know, steps can take a long time. Right? JavaScript normally is not like this, but it has async await.

Sam

00:41:25 – 00:41:41

And in the server side context, that makes sense. So you await, okay. You, you, you fetch the data from the database and then you pass that data as an instance variable to a view, to blade template and you render the user table and then Laravel responds.

Aaron

00:41:41 – 00:41:45

Love it. That's that's the model. We should do that. Yeah. And

Ian

00:41:45 – 00:41:48

the and the podcast right here. But, oh.

Aaron

00:41:48 – 00:41:53

Yeah. I love it. If this is the before, we don't need an after. That's amazing. Alright.

Aaron

00:41:53 – 00:41:54

Keep going.

Sam

00:41:54 – 00:42:26

So, then then rails or, Laravel takes the blade template, compiles it in HTML, packages up an HTTP response, responds to the browser, and the browser renders it. So everything I just described can be packaged up. You can think of it as rendering a user table. If I were to render a user table, a server side user table as a react component, then you could put all those steps inside. But if I want to render it, then I could just render it.

Sam

00:42:26 – 00:42:43

And if you're using this new architecture, this new paradigm, then you have an index route that support that that renders, that serves up a user's table, but when it's rendered on the server, it does all of those steps and it does exactly the same thing that the Laravel app does.

Ian

00:42:44 – 00:42:50

Does it actually go all the way through to rendering the HTML on the server and then spitting out out the complete HTML?

Sam

00:42:50 – 00:42:50

Yes.

Ian

00:42:51 – 00:42:52

Or does it okay.

Sam

00:42:52 – 00:42:58

It does more than that, but that is the right way to think about it right now. Okay. Okay. So why would you do that?

Aaron

00:42:58 – 00:43:00

Did you get all that? Did you get that, Ian?

Ian

00:43:00 – 00:43:01

I got it. I I do have it.

Aaron

00:43:01 – 00:43:15

Okay. Okay. Okay. Tell explain explain it back to me, Ian, because the thing I didn't get was Yeah. Like, I I got the whole render pipeline, but then it was, like, if you wanna run now you have a function.

Aaron

00:43:15 – 00:43:17

I didn't get that part. So what happens?

Ian

00:43:17 – 00:43:45

I mean, I think it's just like if you were to think it's it's basically it's just doing it server side like Laravel would do it. But now it's executing you know, you could bundle up a custom Laravel component that, like or LiveWire full page component that, like, receives the HTTP request and then does whatever database stuff it needs to do and then renders the HTML and then spits that back to the browser. That could all be in one, like Okay.

Aaron

00:43:45 – 00:43:55

So we're saying a React server component A React server component is much like the Laravel blade Probably handler. Rendering Yes. Model.

Sam

00:43:55 – 00:43:55

Yes. Mhmm.

Ian

00:43:55 – 00:43:57

Yeah. So in that,

Aaron

00:43:57 – 00:43:59

it does it all on server. The server.

Sam

00:43:59 – 00:44:16

It does it all on the server and only on the server. This component only ever renders on the server. It only ever executes the body of the of the function, the steps, the await, the connection to the database, the processing of the blade template. It's in the server

Aaron

00:44:17 – 00:44:17

Got it.

Sam

00:44:17 – 00:44:25

With request and response. It's a single step do do do do and then it has a response. It's not rerendering the way React does on the client.

Aaron

00:44:26 – 00:44:31

And your you all's name for this is server. This would be a server component.

Sam

00:44:31 – 00:44:32

Yes. Yep.

Aaron

00:44:32 – 00:44:39

Which is different than a server action, which we'll talk about, I assume, at some point. But this is a server component. Got it. Okay. Cool.

Aaron

00:44:39 – 00:44:40

Got it. Alright. Carry on.

Sam

00:44:41 – 00:45:02

So why would you wanna do this? Right? Why would you wanna package up rendering a user table from a database in the React component interface? Well, for for one reason, like you guys were saying, people like using React components. They're easy.

Sam

00:45:02 – 00:45:03

They look like HTML.

Aaron

00:45:03 – 00:45:05

Never said it. Should have never said it.

Sam

00:45:07 – 00:45:29

They look a lot like HTML. You invoke them with angle brackets and you can customize them by passing props in the same way that you render HTML elements and customize them by passing attributes. And you can nest them. Right? In React, it's called children, but, you know, and, it's just nested HTML elements, I guess, in in HTML.

Sam

00:45:29 – 00:45:57

And, of course, this was all inspired by HTML so that it was familiar and felt fun to use for web developers. So that's where the component interface came from. But it proved to be a really useful way to expose APIs. And, again, over time, we can write that model today as a single component, which it really doesn't get much easier. I mean, it's basically what you would imagine it being if it if and when a model does come to HTML.

Sam

00:45:57 – 00:46:15

Right? How would HTML give you a model to use? They would give you a model and you would invoke it. You wouldn't, like, set up a portal in the top of your app to make sure it renders correctly with a z index on top of this. You wouldn't have to write more JavaScript to attach it to make sure that it listens for keyboard clicks and mouse clicks.

Sam

00:46:15 – 00:46:38

It would just all be contained in that interface. Right? So at this point, we have all those tools like useEffect and useState and React portals that enable an abstraction like a modal to just all be self contained. So the goal with server actions and server components is to do the same thing. So why would you wrap up rendering a user table on the server side into a component?

Sam

00:46:38 – 00:46:51

Well, for the same reasons that we wanted to do that with modal, because if I have a user table, now, how do I customize it? Well, maybe I can pass in a filter prop or a sort prop, and it's just like passing a prop to a react component.

Aaron

00:46:52 – 00:46:54

I see. Which is powerful.

Ian

00:46:54 – 00:47:14

This is all now just to get super old school on you guys for a second. This is all the same stuff that cold fusion had, like, literally 25 years ago. And I miss cold fusion all the time because, like, we've just been reinventing cold fusion for the past 25 years. And it's very funny to me because it was, like, just a graph tag. You drop a graph tag in, and it gives you a graph.

Ian

00:47:14 – 00:47:22

Mhmm. And you could pass a query into the graph tag as a prop. And you get that data graphed, and, like, we're just all we're we're getting back to what we had 25 years ago.

Aaron

00:47:22 – 00:47:28

Or There's always there's always a get off my lawn moment or, like, an old man yells a cloud moment, and it's always It's my

Ian

00:47:28 – 00:47:29

old man.

Aaron

00:47:29 – 00:47:33

It's always very fun. Yeah. So, yes, it's cold we're all back to cold fusion somehow. We're

Ian

00:47:33 – 00:47:36

getting there. We're getting there. But anyway, okay. So the packaging Yeah.

Sam

00:47:36 – 00:47:50

So it's it's about so so in the same way that the client components, which they're now called, which have have been called react components up to this point because there was no other there's not more than one kind. But now

Aaron

00:47:50 – 00:47:51

Y'all have gotta work on

Ian

00:47:51 – 00:48:01

this naming. Naming's yeah. This is not Otwell. This naming is not Otwell. We need to get they should pay Taylor an ungodly sum of money to come in and and, like, fix the name There you go.

Aaron

00:48:01 – 00:48:05

That was gonna go through. Name something, you you gotta live with it.

Ian

00:48:05 – 00:48:06

Yeah.

Aaron

00:48:06 – 00:48:11

So you gotta think ahead because if you're gonna be be changing all these names all the time, people are gonna get confused.

Ian

00:48:12 – 00:48:13

Okay.

Sam

00:48:13 – 00:48:48

But yeah. So, in the same way that yeah. Basically, the APIs that let us wrap up the browser APIs in the client side JavaScript that we want to write behind the React component interface, that's what these server components are doing. But the implementation of the server side components is running on the server, is in the server, and so you don't hit that ceiling anymore. And now you can author any server side code you want and still put it inside of your react app.

Sam

00:48:48 – 00:49:04

Right? So, again, just I was just kind of making that point back to the the getting rid of the back end as a service thing. This this this is solving, wrapping that logic up into the component interface because, a, it's fun and easy to use. It's familiar for web developers. It works well on the client.

Sam

00:49:08 – 00:49:37

B, because it's the same component interface, This is really the key point of this whole architecture. It composes with your client components. So we don't have to get into the details here, but this is kind of like to your point about well, we have inertia, and inertia lets us write client side JavaScript without limits on the front end and PHP without limits on the back end and it wires them together. Isn't that great? Why do we need anything else?

Sam

00:49:37 – 00:49:53

Because there's no limit in either environment. And it is true basically that when you're building a modern web experience, you basically do have 2 apps that you're building. Right? You have 2 apps. You have a server that is a handling requests.

Sam

00:49:53 – 00:50:14

It's dealing with requests and response and it's stateless. It's a stateless server and it just handles and spits it out. And then you have a client app that is a long lived stateful app that has a session. So, you know, it's it's it's not an HTTP session, but it has state associated with it over time. It's long lived.

Sam

00:50:14 – 00:51:00

It's like an iPhone app, but you need both these things to work together to deliver like a modern, you know, what people do on the web these days. And so something like inertia does help you write these 2 apps and tries to abstract away as much of their communication as possible. The reason react server components are different from just that is because since they are both wrapped, both the client side features and the server side features are wrapped in the same component interface, you can compose them together. And so now you can have a user table that fetches data from the database and renders, you know, an HTML table with dynamic data. And if you wanna put it in a model, then you just wrap it in a model.

Sam

00:51:00 – 00:51:24

You just it's it's a it's a it's a JSX file. It's a react it's your page is a JSX page, and you just import modal from radix and you wrap it. And now your server side rendered, server side generated user table is gonna show up in a modal with all of the client behavior that that modal has once once react kicks in on the client. So that is like that is the point of the whole paradigm, basically.

Ian

00:51:25 – 00:51:37

Right. So you end up with, like, a React a JSX file that has things that are gonna execute on the server, tags that are gonna execute on the server, and other tags that are gonna execute on on the client, but it's just one HTML looking page.

Sam

00:51:37 – 00:51:38

Exactly. It's a single React tree.

Ian

00:51:38 – 00:51:43

The React's whatever side of it's working at that moment is gonna do the right thing with the correct tags.

Sam

00:51:43 – 00:51:44

Exactly.

Ian

00:51:44 – 00:51:48

Leave the other stuff alone. And it's so it's basically cold fusion. That's the story.

Aaron

00:51:48 – 00:51:50

It's basically PHP. It's PHP.

Ian

00:51:51 – 00:51:52

But that's what a blade

Aaron

00:51:52 – 00:52:03

file it's just what a blade file is. It's just we separate ours by language. Right? So you have a blade file, and it's, like, well, this part's gonna render on the server because it's PHP, and this part's gonna render on the client because it's JavaScript.

Ian

00:52:03 – 00:52:15

So This goes all the way back to, like, I just wanna stay in JavaScript. Right? Like, if I just wanna stay in JavaScript, then I can just stay in React and JavaScript and not go between those two languages or whatever. But Yeah. You'll still have to learn all the same concept.

Ian

00:52:15 – 00:52:33

And, obviously, at some point, they'll be queuing and sending emails and whatever. I don't know if those things exist yet in the React server side stuff, but at some point, they will whether it's in a framework or in the core or whatever. And people have to learn what that is and all the sharp edges and all that stuff, too. But, yeah, I I get it. So it's just

Aaron

00:52:33 – 00:52:40

I get it. I get it. So React server components, I get it. I I see the appeal. It makes sense to me.

Aaron

00:52:40 – 00:52:58

I still think there's this entire chasm missing of, like, all the business logic and stuff. But in terms of, like, creating views and interfaces and stuff that, like, the actual view layer, React server components sound reasonable to me.

Sam

00:52:58 – 00:52:59

So yeah. I mean, I don't know

Ian

00:52:59 – 00:53:05

if they can could they I mean, does the component structure in such a way that the you would have components that are your business logic?

Sam

00:53:05 – 00:53:10

Yes. So so this is the thing. So No. No. No.

Sam

00:53:10 – 00:53:11

I'm

Aaron

00:53:11 – 00:53:12

I'm I'm on your

Ian

00:53:12 – 00:53:14

hand in your car. I'm taking I'm taking

Sam

00:53:14 – 00:53:17

my time on your hand. I'm trying to get you there. No.

Aaron

00:53:17 – 00:53:19

I appreciate you coming on today. It's

Ian

00:53:19 – 00:53:20

been fun.

Sam

00:53:21 – 00:53:53

It's not just about the view and rendering. So, yes, you need business logic and, yes, the JavaScript server side ecosystem doesn't have as mature a set of libraries to do all the thing. Like, I remember my one of my first rail side projects with my brother was it email it was called, like, call your mom dot com. And, you would set up an email reminder system and you could put it on a schedule. And so you said I wanna call my mom every week and, I would get an email every week and I could say call my aunt Julie every 3 months and remind me every morning to, you know, take drink water or whatever.

Sam

00:53:53 – 00:54:42

And there was this, like, recurrence library in Ruby and, it let us just do all that stuff and that's not going to be something that you get by using, like, a web service. And, again, the point of server components is not it's not at the same level as MVC or application architecture concerns. It is trying to let folks who are building those abstractions and libraries and packages wrap them up into the the same interface so that they're easier to use in the same way that react libraries on on the client UI libraries all wrap up their models and their drop downs and their dialogues into component so they're easy to use and they play well with the rest of the react ecosystem. So, that is the goal of server components. It is a it's a tool for to to it's a it's a building block.

Sam

00:54:42 – 00:54:59

It's like a missing primitive, you could say, in React that allows you to package up whatever you're doing on the server in a way that's easier and more fun to use, honestly, just like, again, rendering a model. So we talked about user table that renders it. A view logic. You're like, that's fine. What about the business concerns?

Sam

00:54:59 – 00:55:04

So this is the thing. This is where server actions come in, and this is the SQL injection slide. Oh.

Ian

00:55:06 – 00:55:07

Alright. Where was that?

Aaron

00:55:07 – 00:55:09

Here we go. Yeah. Insert into bookmarks.

Sam

00:55:10 – 00:55:23

That's right. So in the talk, I'm explaining how to make, like, a news story. You know, it's like a it's like a magazine or whatever. It has it was Apple News. I was clipping things from Apple News.

Sam

00:55:25 – 00:56:10

I got, like, midnight the night before I talk because I was frantically trying to finish my keynotes. And, you have your articles and then you wanna add something that does like a mutation, you know, which what's common way people call these days in front end, but it's just you wanna write back to the database or you wanna trigger an email or what whatever. So in this case, you wanna write back to the database. You click bookmark and you wanna get the current user from the session and then save this bookmark to their back end. So you add a bookmark, and normally, you might have an on click, and this is where you kind of get out of the react tree, the UI, and you hit a API endpoint, or like this is what inertia would do.

Sam

00:56:10 – 00:56:19

Right? Inertia, you would on click and then that routes you. Inertia is gonna route you to some server side controller, let's say. That's like an action. It's like a it's a create.

Sam

00:56:19 – 00:56:37

It's a post on the bookmarks controller or something like that. Right? And so when you click that, you make an API request. It sends a post message to slash bookmarks, and then you write your PHP code that says insert into bookmarks and then return success true. That goes back to the client and then you can say, oh, it's pending.

Sam

00:56:37 – 00:56:41

Oh, it's good to go. Okay. It's saved. And then you rerender it and That's awesome.

Ian

00:56:43 – 00:56:44

I love it.

Aaron

00:56:44 – 00:56:47

So That's exactly as in fact, that's exactly what I would do.

Ian

00:56:47 – 00:56:47

Yeah. So beautiful.

Sam

00:56:47 – 00:56:52

Nailed it. Yeah. So what's the what's the what's the problem with this?

Ian

00:56:54 – 00:56:57

No. No problem. No. You can't

Aaron

00:56:57 – 00:56:59

set me up like that. No problem. No problem.

Ian

00:56:59 – 00:57:00

It's all perfect.

Sam

00:57:00 – 00:57:15

So the way to the way I think about it is, again, do you guys know what React portals are? Where they, like, create something? I think Vue, they all have this now where if you need to make a drop down or or a modal, you Like jumping around

Aaron

00:57:15 – 00:57:15

the dot.

Ian

00:57:15 – 00:57:16

The dot.

Sam

00:57:16 – 00:57:27

Yeah. For sure. Before all these frameworks had the ability to do that, then to use a model, there was always a second step. Right? You had to set up that part, that container, and give it like an ID to this thing.

Sam

00:57:27 – 00:57:47

It's like it's like spooky action at a distance. Right? Because you have a modal here, but you actually have the modal container somewhere up here. So if I want to copy the modal and use it again, I have to be aware of it actually has an implicit dependency or maybe an explicit dependent, but it has a dependency outside of the component boundary. So I can't just copy and paste the model around.

Sam

00:57:47 – 00:58:23

So if you think about the button in the inertia app, if I wanted to copy a bookmark button into a new place, do I just copy the bookmark? Well, what is the dependency there? There there's a dependency on the API server and the the specific route that it's hitting for it all to work for the full stack feature to actually work. So the action has leaked outside of the component boundary, and so we lose the benefits of that packaging, that slim interface. And you can't just you can't copy it around your app as easy, maybe whatever.

Sam

00:58:23 – 00:58:49

Right? So that's that's like the goal. So server actions fix that problem. You can think of a server action as in your in your view template instead of making a request to an end point, and then that end point hitting a controller in your Laravel app that runs the post method. What if you could import that post method?

Sam

00:58:49 – 00:59:06

What if you could have a what if your bookmark component could import post from bookmarks controller and say on submit equals bookmarkscontroller.post. And then you export that.

Aaron

00:59:06 – 00:59:15

So you're carrying around you're carrying around the the action with the UI or, I guess, the component. Exactly.

Sam

00:59:15 – 00:59:31

And now if you have that inside of the component and you export that and share that, I can copy your bookmark component and render it. And when I submit it, it's just gonna use that code because it's importing it directly.

Ian

00:59:35 – 00:59:54

It's like, Livewire Vault. It's like what Taylor is trying to do with Vault. Like, you have the business logic, let's say, the server side code at the top of the file, and you have the HTML at the bottom of the file, it's all one file. You could take that file and move it around and it would all work exactly the same.

Sam

00:59:55 – 00:59:56

And then the things that

Aaron

00:59:57 – 01:00:20

So is the is the primary benefit because I haven't seen anybody talk about the primary benefit. I've just seen people talk about how cool it is. Like, I don't get it. So is the primary benefit this thing you're describing here, where everything is is collocated together in terms of, like, the front end initiator and the back end responder are all kind of together in the same actual file.

Sam

01:00:20 – 01:00:43

So in this case, there actually is no front end code. So in my example so I was kind of talking to you through this case of of the inertia app where the inertia app has the Vue app running on the client. Right? And then when you press a button, it's like an SPA mode, and it's gonna use a fetch request to hit the API endpoint. Right?

Sam

01:00:44 – 01:01:17

Yes. So what if instead your inertia view, like rendering UI layer, never started running view on the front end, and it just pre rendered that button on the server and had HTML. Right? And then when you submit the form, it makes, like, an HTTP request, but the form has, like, an action pointing to a specific route that your server can route to this to run the code that you imported and attach directly, if that makes sense.

Aaron

01:01:18 – 01:01:24

Okay. So this is this is the bun this is the bundler thing where what you're writing is not what is being

Sam

01:01:25 – 01:01:25

Served up.

Aaron

01:01:27 – 01:01:29

Not the form in which it's Exactly. Served.

Sam

01:01:29 – 01:02:08

And so it's like, if you could import that post con that bookmarks controller dot post method, and then you had a server endpoint in your Laravel app that was like slash actions. And anytime your front end makes a request to it, even a HTTP request, but let's just let's just say a AJAX request or whatever, because that doesn't really matter. It's not running on the client. It goes to that endpoint and then your your server's able to look up, oh, when they make a request to actions with these this, like, ID or something, we get the bookmarks controller dot post method. We run that code on the server, and then we return the result.

Sam

01:02:08 – 01:02:31

And now your bookmark now your bookmark deconstructed it for you. The bookmark now doesn't have any of that spooky action at a distance. If you were to put that bookmark component that had the server action, like, it could be importing from the file, could just be right there because, you know, in JavaScript, it's all JavaScript. So you could you could write that there. That's what, like, that use server directive is.

Sam

01:02:32 – 01:02:57

But either way, conceptually, it's the same thing. If you could put it all inside of that bookmark component, then you could share it. And anytime someone rendered it with the angle brackets, they'd be getting the server side logic for the mutation. Right, which could have a direct handle to a database because it's running only in the server, and, that's it. So you've you've put all of those concerns inside the boundary.

Sam

01:02:57 – 01:03:12

And so now you can just render the component and it can basically come bundled with the server side mutation that it needs to do to work. You don't need to make sure there's an API server set up or whatever. Right? So that's that's the idea. And, well, yeah.

Sam

01:03:12 – 01:03:13

What do you think?

Ian

01:03:14 – 01:03:14

Yeah.

Sam

01:03:14 – 01:03:15

Do you

Aaron

01:03:15 – 01:03:16

I don't know, Ian.

Sam

01:03:16 – 01:03:17

I I

Ian

01:03:17 – 01:03:35

I guess my only thing is does, yeah. I mean, I think it makes sense in all that part of it. I do wonder, like, do you think it's, like, a I haven't dug, like, super deep into the actual, like, API of it, but is it a practical thing? Because there's like there's like okay. Let's put some SQL here to insert, write a bookmark, row.

Ian

01:03:35 – 01:03:43

Great. Like, that's very straightforward. It's a single line. Fine. But then you get into, like, a real application that's got, like, well, we have to authorize.

Ian

01:03:43 – 01:03:54

Can this person even do this? And then we have to try to insert it. But what if it fails? And maybe we have some other case in that. So, like, that it's actually, like, 20 lines of code is, like, the real amount of code you'd actually need to do this.

Ian

01:03:54 – 01:04:09

Like, does it start to break down when you get into, like, that type of a real world implementation as opposed to, like, the conference talk implementation of, like, yeah. We didn't do some still line of SQL, and that's cool. And it inserts. Like, I guess, how does that look when you when you actually

Sam

01:04:09 – 01:04:20

feel a little more real? So to bring it to the example in in the talk, I was building this bookmark on this Travis Kelce Taylor Swift slide and, wanted to bookmark it to save

Aaron

01:04:20 – 01:04:20

it. Classic.

Sam

01:04:20 – 01:04:42

And so Yeah. Originally, we had an API endpoint that inserted the bookmark and and the button was making an AJAX request to that a point. Then I show how this is like a coupling here. And if we can just import the action and put it directly in here, then we've encapsulated all the logic inside the bookmark component. Right?

Sam

01:04:43 – 01:05:14

And, first of all, all that is rendering and the server action is executing on the server. So it's not it does hydrate and it ends up using Ajax, but that's kind of besides the point. Because, the SQL code that ran is actually it's like a template tag literal. So it was never running on the client because some folks were looking at the the slide that was going around Twitter and saying, like, you're you're you're you're running this, like, code on the client. That's not what was happening because it was a server action.

Sam

01:05:14 – 01:05:27

And the the SQL tag function sanitizes the input, so there was no injection either. It's it The function actually, it was running that through a function. But so that setting that aside, that was just fine. I mean, it was it was just for fun. Right?

Sam

01:05:27 – 01:05:55

I mean, I was making a simple point. Yeah. But there's no injection and you're not running SQL on the client. But to your point about the application concerns and the maintainability and the scalability of it, One way to think about this is like before we were just writing API endpoints so that these things talk to each other and we use things like inertia to try to minimize how much of that we even have to think about. I just really wanna run this server side code when I click on this button.

Sam

01:05:55 – 01:06:13

And inertia has a way for me to do that. I can do that by myself. And this is like one step further. It's just removing that conceptually altogether so that you can just import a function and invoke it the same way you would anywhere in your program. So And then elsewhere Exactly.

Sam

01:06:13 – 01:06:55

So the function that you run when you submit the form or click the button, we're removing we've removed this network, the the details of how to pass the arguments and call it in response to an event, because that was a technological limitation that we didn't have before. So now we've removed that limitation so that we can just pass functions. But when it comes to things like design, like co design and maintainability and reuse, all of the lessons still apply from before. So, again, going back to my rails days, fat models, skinny controllers. If you have a controller that's a couple lines long, make sure there's a current user, try to insert it, return an error if not, otherwise, render the success or whatever.

Sam

01:06:56 – 01:07:13

The new the new to do you created, the new post, that's fine. That's like a couple lines of code. Yeah. Throw that in your in your, post method of your rails app. But as your app grows, like you said, there's more and more logic, and people's controller methods did get really long, and that was messy and hard to maintain.

Sam

01:07:13 – 01:07:51

And the answer was fat model skinny controller. So you create domain objects so that your controller just says something like send an email and then, you know, it's like a e a mailer dot send this message here. The mailer class has the logic and that's somewhere else and it knows how to connect to AWS or whatever and it knows how to turn this into the right format and actually send it or enqueue a job if that's what it needs to do because it's a mailer and then it returns to success. So your controller would still be slim. And so, again, it's not really it's it's a different level than MVC.

Sam

01:07:51 – 01:08:13

But as folks use this, it's you you can bring all of that design print. So instead of SQL, obviously, you would probably use like I like ORM. So I would use an ORM there. And then if the logic became more complicated, you could extract it into these kind of domain objects for the for the sake of maintainability and and clarity. But, server components, yes.

Aaron

01:08:13 – 01:08:26

Alright. So let let me let me try this on you. So let let me try this. Rack server action is the controller Yes. Level layer portion slice

Sam

01:08:26 – 01:08:27

Exactly.

Aaron

01:08:27 – 01:08:53

Coupled with coupled with some sort of view or initiator or whatever, whether that's a, you know, React client or or React client component or React server component. Yes. You know, regardless. You bundle it all together. And now your your view and your controller are nice and neat and coupled, not in a bad way, but like in a way that you can carry them around together.

Aaron

01:08:54 – 01:09:05

Exactly. What is still missing that is yet to be, like, either talked about very much or invented is the rest of, like, the

Sam

01:09:05 – 01:09:06

The model air.

Aaron

01:09:06 – 01:09:14

The fat models Right. The cues, all of, like, the actual, you know, under iceberg part of, like, the business logic.

Sam

01:09:14 – 01:09:15

Right.

Aaron

01:09:15 – 01:09:21

And so what I'm I think I think that is probably the answer to my main question, which is, like, why would anyone do this?

Sam

01:09:21 – 01:09:22

Yeah. This

Aaron

01:09:22 – 01:09:42

feels like this this feels like terrible spaghetti. But the answer is not the answer is not you're gonna shove all your logic in your views. The answer is you're gonna have bookmark service or bookmark model dot create. You're gonna have 1 or 2 or 3 lines that would be more analogous to a controller Exactly. Than it is your entire domain's logic.

Aaron

01:09:43 – 01:09:45

That should still be someone else, and we need somebody

Sam

01:09:45 – 01:09:46

Exactly. In

Aaron

01:09:46 – 01:09:54

the JavaScript ecosystem champion that and teach everybody. Put all of this in a reasonable place, not in your React server action.

Sam

01:09:54 – 01:10:08

Yes. Exactly. That's I'm glad you said that because that's a great analogy. Imagine so right now when you have methods in your Laravel controller, you have controller methods in your Laravel app, How do you hit them? You have to make a HTTP request to them somehow.

Sam

01:10:08 – 01:10:19

You click a link or you submit a form. If you're not using JavaScript, links and forms are the only way that the browser your browser can interact with your Laravel app.

Ian

01:10:19 – 01:10:20

Mhmm.

Sam

01:10:20 – 01:10:36

What if you could write on hover? What if you could write on hover, run this controller post method or bookmarks create method? And you just had a way in PHP to do that so that you could just right? That's that's Livewire. That's that's that is but that's that's the deal

Ian

01:10:36 – 01:10:37

of Livewire. Yeah. That's the deal.

Sam

01:10:37 – 01:10:38

Yes. That's why

Aaron

01:10:38 – 01:10:39

we like it.

Sam

01:10:41 – 01:10:47

So anyways, that that that's that's kind of the idea. That's that's kind of the idea. But, yes. In terms of

Ian

01:10:47 – 01:10:54

Are there are there, I was just gonna ask, are there people working on, like, is there an ORM already or are there

Sam

01:10:54 – 01:10:55

Yeah. Are

Ian

01:10:55 – 01:10:57

there other There's 7 ORMs. Yeah.

Aaron

01:10:57 – 01:11:00

There's there's an ORM for every day of the week, man.

Sam

01:11:00 – 01:11:39

Yeah. So the model layer is I think, going back to earlier, the model layer is the thing that the biggest missing piece in terms of a coherent one. Prisma is pretty good, and it has a lot it has relational ideas of relations, relationships, and foreign keys and, you know, transactions and all that stuff. And I will say, like, you do do less in the back end, like, even when we had our full rails app serving up for Ember map, and we weren't trying to get rid of the back end and only make an Ember app. Right?

Sam

01:11:39 – 01:12:11

We had a full rails app, which was great when you had to do anything custom. A lot of the stuff that you used to do, you would do more stuff on the client because it's interactive. You wanna filter it fast down or whatever. And, a lot of the it it feels like these days, I need the full power less way less often than when I was writing rails apps, let's just say. But, anyways, that setting that aside, there are tons of libraries in the node ecosystem that let you organize I mean, there's lots of yeah.

Sam

01:12:11 – 01:12:48

There's lots of really huge node apps that are well designed from a object oriented, you know, separation of concerns, maintainability perspective. But because React server component is not trying to solve that problem, they're trying to give you a primitive that lets you distribute these in a way that composes because so far everyone's been doing server side data fetching in their own way, and so I can't bring down these components and add them. I have to use my framework specific ways to fetch data and to write data. That's the problem they're trying to solve. But there's definitely still problems in the model layer that need to be solved.

Sam

01:12:49 – 01:13:46

And so kinda how I end the talk actually is talking about, like, what this future would look like. And so, imagine, like, you could have if you had a form library that was opinionated about your database design in the way I'm sure there's like form 4 helpers, something equivalent to form 4 from rails and Laravel where the form helpers in Laravel comprehend your models and relationships. Right? So if you need to create a form to create, you know, a user with 3 to dos, like the form helpers map it to your database so that you can render it. You type in the data and you hit submit and it knows how to take the graph of data from the form in HTML and map it to the right places in your databases, setting up the foreign keys, that only is as coherent and consistent because all of those abstractions know about the other ones.

Sam

01:13:46 – 01:13:58

You have to have eloquent. You have to have a database that has foreign keys, and you have to have a form helper that makes assumptions about the name of the model and what data it it gets. Right? And so that's that's incredible. It's super powerful.

Sam

01:13:58 – 01:14:23

So what would that look like in react? Well, you could have basically the same thing. So you could render a form input, a component. You could say, like, this is, like, user dot first name, and I could just render that. Let's say I just bring in postgres and an ORM like Prisma, and now there's like a Prisma, like, there's like a a form library that works.

Sam

01:14:23 – 01:14:36

That's like those 3 are a package together. That's one package is a new library. I install that. It tells me how to set up my database in the same way rails would, and it gives me form components that let me render those. This is a cool thing.

Sam

01:14:37 – 01:15:02

So now I render a form and I say, I say input type email. And where's the data coming from again is a server component. So I just pass in props. I say user dot find 1 basically, but it's just 1 user ID 1. So just rendering email input with user ID 1 and field password, I get server side rendering.

Sam

01:15:02 – 01:15:14

It fetches the database and it wastes it, and it does it again. It's HTTP request and response. So the first time you load that, it's doing it so you get HTML from the server. Right? And it renders that data from the database right there.

Sam

01:15:14 – 01:15:48

I didn't have to set anything else literally as easy as rendering a model, and it does all of that. Then the react app starts running on the client because it does hydrate in any client behavior you have. I put my cursor in the input and I add a character. I type in a, And this input has, a listener for keyboard events. And as soon as it changes, it also has a server action that knows how to update that field in the database, and it renders a spinner while that's happening on the client.

Sam

01:15:48 – 01:16:07

And it's all in that component. So that is, like, the dream. Right? All of this functionality end to end, a complete end to end feature can be packaged inside of a component. And the more opinions that these people have about your architecture, the more powerful and rails like in Laravel, like these abstractions will become.

Sam

01:16:07 – 01:16:24

But even with 3rd party services like adding Stripe to your app, with Stripe, maybe you have a UI component, but you're also used to, okay, now we gotta set up the server side component. If they make a server component that has server actions, you could just render Stripe checkout just the way you render modal, and that's it. That's all you have to do.

Ian

01:16:24 – 01:16:25

Right. It's all being connected.

Sam

01:16:25 – 01:16:38

And and again, it can have access to environment secrets because it's running on the server. So maybe there's an environment variable that it uses. It it's all encapsulated in the in the component boundary. So that to me is like that's kind of the dream. Right?

Sam

01:16:38 – 01:16:53

It's kind of like one way you could say this is like, I love using Tailwind UI components and radix components, modals and drop downs and, you know, going to town on the UI. It's easy. It's fun. It's like the easiest and funnest part of my job. Right?

Sam

01:16:53 – 01:16:59

What if you could build a whole app out of React components? That's like, that's one way to think about all this.

Ian

01:16:59 – 01:17:01

Just kind of piecing it together.

Sam

01:17:01 – 01:17:19

And all the details, just like inertia abstracted some of the details between client server communication. These really take it another level because it's just it's just components and composition. And there's, like, there's more cool stuff that comes out of this model, but that is really that's kind of the way I'm thinking about it. So

Aaron

01:17:19 – 01:17:21

Okay. So you're ready for my hot take on that?

Sam

01:17:21 – 01:17:21

Yes. I'm ready.

Ian

01:17:21 – 01:17:22

I'm ready. Let's go.

Aaron

01:17:22 – 01:17:52

Here here's my hot take on that. That sounds awesome. Nobody you said that's the dream, and you said if this, you know, library did exist or whatever. I think my hot take on that is somebody needs somebody needs to have those opinions and enforce them. Because what you described of, oh, if there was this library that had, like, you know, Prisma and Postgres and a form all kinda wrapped up together, well, the what is what's gonna happen is people are gonna be like, well, I wanna use Drizzle.

Aaron

01:17:52 – 01:17:57

Yeah. I wanna use Drizzle with it. I wanna use Keisley with it. I wanna use MySQL. I wanna use SQLite.

Aaron

01:17:57 – 01:18:53

And then suddenly, you're back to this situation where you are inventing from scratch, or maybe you're inventing from 8 different, you know, well battle tested libraries, you're inventing your own meta framework where you're then maintaining, like, oh, okay. Well, I have this form field thing that interacts, you know, with my Prisma. Prisma just upgraded to 5 point o, so I gotta make sure that my form field thing is and so what I think needs to happen, what could make someone fabulously wealthy if they could pull it off correctly, is they could take all of those good opinions that you just shared and say, this is the way we do it. And, like, kind of the thing that I feel like Laravel did so well was it does use, you know, it does use third party libraries very heavily under the hood. Like, our, you know, file system our cloud file system thing is built on top of I think it's called Flysystem.

Aaron

01:18:53 – 01:19:08

Mhmm. But it's like, yeah, you don't actually need to know that Fly System really exists. You just use Laravel's file system. Right? And our HTTP, you know, request response is built on top of Symfony's HTTP classes.

Aaron

01:19:08 – 01:19:39

And it's like, well, yeah. You don't really need to know that those exist. But the great thing that we get out of that is that our models and our queues and our, controllers and our scheduling, they all know about each other. And so everything works exactly as you're describing. The thing that's missing, I think, on y'all's side is that one that one, like, one set of opinions that's, like, you you're gonna use you have to use Prisma.

Aaron

01:19:39 – 01:19:42

In fact, you may not even know you're using Prisma, because we've built

Sam

01:19:42 – 01:19:44

You've built the highest component. You know?

Aaron

01:19:45 – 01:19:57

A single opinionated interface on top of all of these really good libraries. Right. But now you're using, you know, you're using Sam Eval or whatever you wanna name your thing. But, like, somebody has to make those decisions for you.

Ian

01:19:57 – 01:20:02

It seems like this provides the tool to allow that to exist.

Sam

01:20:02 – 01:20:03

Exactly. Before, it would

Ian

01:20:03 – 01:20:10

be very hard for that to exist, whereas now they can be organized in such a way that it could exist.

Sam

01:20:10 – 01:20:32

Yes. I think I think this is out of that. Exactly. Like, this from React's perspective, the the library maintainers and designers, this was a missing primitive for that level of composition behind the set of opinions and that could also wrap the server side actions and rendering and fetching inside of the same component interface. So that is my hope that it will provide that.

Sam

01:20:32 – 01:21:08

I don't think that excuses the JavaScript community for the last 10 years of not having stronger opinions because you didn't need server components and actions. You didn't need to build an app out of components even if it's enables some really amazing things that we weren't able to do with any other technology, like putting the user table in the model in the same tree, in the same file. Like, there's no other technology that lets you do that. But, that's not an excuse for not having more opinions because people did spend a lot of time wheel reinventing. But, that is I think where we're gonna head because in the same way that we render a model and we don't care.

Sam

01:21:08 – 01:21:26

Let's say the model has collision detection. And so if you're at the bottom of the screen, it'll render on top. You know, there's some hook underneath, like, use window width or use window height that it's using. And when those first came out, people had strong opinions about them. Now they're packaged inside of the model, and so we don't care.

Sam

01:21:26 – 01:21:38

So if you get the abstraction right, then people don't care about those low level things. And they're not gonna say, I wanna use Drizzle and not Prisma. Right? So, that's, that is the hope. That is the goal.

Sam

01:21:38 – 01:21:41

At least from my perspective. That's what I want to see. That's what a lot of us want to see. So,

Ian

01:21:42 – 01:22:00

so just gonna wrap it up here. Gone. This is we're gonna have, like, 6 hours of podcast this week. But, but, you know, one thing I did wanna just touch on is, like, normally, when you become the main character on Twitter, it's terrible. Like, you don't wanna become the main character on Twitter.

Ian

01:22:00 – 01:22:14

It's horrible. But I feel like you've actually you kinda, like, this worked out not so bad for you because, like, the idea got a lot of criticism and then people were also having fun with it. And I don't think I saw anybody, like, complain about you at all. No. Like, this damn guy's an idiot.

Ian

01:22:14 – 01:22:17

They were just, like It was a blast. Great. So I thought that was really cool.

Sam

01:22:17 – 01:22:17

It was fun.

Ian

01:22:17 – 01:22:20

People people kept messing with the memes.

Sam

01:22:20 – 01:22:25

Yeah. Exactly. People kept messaging me over the weekend. Like, they're like, are you okay? Hope you're doing alright with this.

Sam

01:22:25 – 01:22:32

I was like, are you kidding? This is this is hilarious. Like, yeah. I did not take any of it personal. I mean, people are like, these guys are idiots or whatever.

Sam

01:22:32 – 01:22:33

I mean, it doesn't

Ian

01:22:33 – 01:22:33

For sure.

Sam

01:22:33 – 01:22:39

Yeah. It In the outshark. I liked it. A lot of people were curious about it. I think a lot of people will be interested in the talk because of it.

Sam

01:22:39 – 01:22:42

So that's great. You know? I had I had no problem at all.

Ian

01:22:42 – 01:22:48

Generating hey. You're on here because of it. Right? Like, you would have thought initially how the react episode. Right?

Ian

01:22:48 – 01:23:00

But it's like, oh, there's like this thing going on and people are getting upset by it, but it's like kinda cool to talk about and learn more about it and that's what we've done. So, alright, man. Well, thanks for coming on. Really appreciate it.

Aaron

01:23:01 – 01:23:07

Since this is going on 2 feeds, we should say where each feed can be found in case we wanna cross pollinate listeners.

Sam

01:23:07 – 01:23:08

Perfect. You go first.

Ian

01:23:08 – 01:23:16

Sam, why don't you where's where alright. I'll go first. So, obviously, you could find us on, mostly mostly TechPod.

Aaron

01:23:16 – 01:23:20

Goodness. This is our first podcast episode. Actually currently. Mostly Tech

Ian

01:23:20 – 01:23:33

Pod at Twitter, mostlytechnical.com. You can email us at mostlytechnicalpodcast@gmail.com. And definitely I'll just give a thing for Sam here too to check out build UI which is his, screen,

Sam

01:23:34 – 01:23:35

video courses

Ian

01:23:36 – 01:23:44

on React. Video courses on React and, Tailwind and other tech along those lines. So definitely check that out.

Sam

01:23:44 – 01:23:44

Thanks, man.

Ian

01:23:44 – 01:23:48

And, yeah, Sam, what'd you say? Where you can you can find your, podcast?

Sam

01:23:48 – 01:24:04

Yeah. So we'll put this on Frontend First, and that's mine and Ryan's podcast. We do some interviews, but mostly just us talking about kinda what we're working on. So front end first dot f m is our website. And, yeah, I'm excited to have helped make the mostly technical podcast a little more technical.

Sam

01:24:04 – 01:24:06

This might be your most technical episode ever, actually.

Aaron

01:24:06 – 01:24:07

This is by far

Ian

01:24:07 – 01:24:08

our most technical.

Aaron

01:24:09 – 01:24:21

Yeah. So If you're if you're listening on the front end first feed, most of the time, Ian just talk about nonsense. Sock. Seinfeld were on podcasts. So, yeah, this is our definitely most most technical one.

Sam

01:24:21 – 01:24:24

It's a it's a fun one. Yes. We definitely

Ian

01:24:24 – 01:24:35

Describing describing, technical concepts over audio is not always the easiest. But I think for the most part, it came through pretty well there, and we understood what was going on. So,

Sam

01:24:35 – 01:24:36

that's a good thought.

Aaron

01:24:36 – 01:24:51

I won't admit to this publicly even though this is on 2 podcasts, but I've been I've been moved a little bit. I I I wouldn't even call it a I wouldn't even call it Woah. I wouldn't call it a step. I would just call it a slight lean, maybe. And I'm not even just a lean.

Aaron

01:24:51 – 01:24:51

Just

Ian

01:24:51 – 01:24:52

You gotta hook it up. I get it.

Aaron

01:24:52 – 01:24:54

I get it. I get it

Ian

01:24:54 – 01:24:54

a little bit

Sam

01:24:54 – 01:24:56

more. You just you made my day, buddy.

Aaron

01:24:56 – 01:25:02

You made my day. Yeah. I don't wanna hear about it ever again, so don't bring this back to me. I don't want you to clip this

Ian

01:25:02 – 01:25:04

part on Twitter, but, yeah,

Aaron

01:25:05 – 01:25:06

it makes a little more sense.

Ian

01:25:06 – 01:25:06

It makes a little more sense.

Sam

01:25:06 – 01:25:16

Listen. I gotta say before we go. Aaron, you got a skincare routine or something just to bring back the mostly part of mostly technical. Your face all looks great on camera, man. Do you have this problem?

Sam

01:25:16 – 01:25:23

Because we both make videos. You wake up and you're like, you know, I don't know. You gotta you gotta be looking sharp for these cameras with these HD 4 k video. It's true.

Aaron

01:25:23 – 01:25:24

It's true.

Sam

01:25:24 – 01:25:28

And you're always, like, so put together. I mean, you go to a sauna or a spa or something. What's the what's the secret?

Aaron

01:25:28 – 01:25:40

You know you know, I don't. I took Accutane when I was 16, and I think it's still paying off. But sometimes this is another secret, so this is nobody's listening at this point.

Ian

01:25:40 – 01:25:40

We're an hour

Aaron

01:25:40 – 01:25:41

and a half in. So it's just us.

Ian

01:25:41 – 01:25:44

We could do we could do a full skincare apology. Yeah.

Aaron

01:25:44 – 01:25:49

Sometimes if I get sometimes if I get a bad one and I have to record, I I use my wife's concealer.

Sam

01:25:49 – 01:25:53

Oh, nice. For sure. You know what? I've been this close to asking some of my girlfriends, like,

Aaron

01:25:53 – 01:25:53

you

Sam

01:25:53 – 01:26:09

know, I had to do a last video for the remix course. And I had, like, I was playing with my friend's dog and we got in, like, a biting match because I, you know, we were, like, chasing Classically, and and and I lost and I little and I was like, I'm this close to going to Rite Aid and asking what do women do, for this sort

Ian

01:26:09 – 01:26:09

of thing.

Sam

01:26:09 – 01:26:13

But I haven't crossed that bridge yet, but I'm sure once you do, it's just, you know, you're there.

Aaron

01:26:13 – 01:26:22

It's it makes honestly, like, it just makes, yeah. It makes me feel good. But more importantly, it's, like, consistent. Right? It's consistency.

Aaron

01:26:22 – 01:26:37

Yes. So I can continue to record and not be like, oh, that was the day he had the massive zit on his head, and then, oh, this must be a different day, because he doesn't have that anymore. And the funniest thing that had happened was, you know, I had I had a a big one one day, and I went out to my wife and I was like, hey.

Ian

01:26:37 – 01:26:40

Where's our makeup? She was like, what

Aaron

01:26:40 – 01:26:40

do you mean?

Ian

01:26:42 – 01:26:43

She's like, dude.

Sam

01:26:43 – 01:26:44

Oh, I love it.

Aaron

01:26:44 – 01:26:45

Yeah. Things like you do

Sam

01:26:45 – 01:26:46

need to keep talking.

Aaron

01:26:46 – 01:26:50

You just, like, you just put a dot on it and then you kinda it just goes away.

Ian

01:26:50 – 01:26:52

They have the technology.

Aaron

01:26:52 – 01:26:53

It's amazing.

Sam

01:26:53 – 01:26:53

That's it's amazing.

Aaron

01:26:53 – 01:26:58

But, no, beyond that, I just use a bar of Dove soap on my face like a caveman.

Sam

01:26:59 – 01:27:07

It's pretty good, man. Well, dude, I really do like I I really have been enjoying following your your video work this year, man. YouTube is tough. Thanks. And, YouTube is tough.

Sam

01:27:07 – 01:27:11

It's really tough. We could we could do a 6 hour pod on that. But,

Aaron

01:27:11 – 01:27:18

we gotta do a whole another one because I've been listening to you talk about top of funnel being YouTube, and it's boy. It's tough.

Sam

01:27:18 – 01:27:18

It is.

Ian

01:27:18 – 01:27:28

Yeah. You guys yeah. That would be a great one. I'd I'd love to see you guys do a, video video oriented, something on YouTube at some point point would be cool for screencasting.com and

Aaron

01:27:28 – 01:27:28

Yeah.

Ian

01:27:29 – 01:27:32

Kinda go back and forth there and that stuff. So Nice.

Sam

01:27:32 – 01:27:34

Awesome, guys. That was so much fun.

Ian

01:27:34 – 01:27:35

Appreciate it.

Aaron

01:27:35 – 01:27:36

Yeah. Thanks for coming. This was great.

Sam

01:27:36 – 01:27:37

Absolutely. Alright.

Ian

01:27:37 – 01:27:38

Talk to you later.

Sam

01:27:38 – 01:27:38

Alright. Bye.

The SQL Injection Slide with Sam Selikoff

Transcript

Not enough emails?