Kent C. Dodds is a well-known JavaScript developer who has done myriad development courses and training. He's also done outreach for Remix. He's spoken at tons of conferences and his now working on creating EpicWeb.dev which helps developers become epic web developers.

The Jabber crew starts out talking about learning, teaching, and EpicWeb.dev before going into the changes in the web platform and progressive enhancement and eventually Remix.

AJ

Dan

Steve

Kent

Hello, everybody. Welcome to another exciting episode of JavaScript Javer. Today, Chuck is in Florida and joining the warm sun there, I assume. My name is Steve Edwards. I am the host with the face for radio and the voice for being a mime, but you're stuck with me. I'm still your host. Today with me on our panel, we have Dan Shapir.

 

Hi from still warm and sunny Tel Aviv.

 

I am so jealous. Well, it's actually sunny here still. It's like mid October in Oregon and everybody's going, where's our cool weather? I'm like, yes, I

 

Oh,

 

love it.

 

we did have a few drops of rain, but it was warm rain. We were walking around in t-shirts. We still walk around in t-shirts, so, you know. Got to love the Israeli weather.

 

Oh yes. And then coming from the purple room, AJ O'Neill. Yes.

 

Hahaha

 

the jungle of

 

Ha

 

tabs,

 

ha ha

 

that's browser tabs, not tab the soft drink for anybody who might be thinking that.

 

I don't think

 

And

 

anybody's

 

finally,

 

thinking that.

 

well, if you grew up in the 80s, maybe you are. And finally, our guest, the one, the only, the JavaScript guru, Kent C. Dodds. How you doing, Kent?.

 

Hey everybody, I'm super happy to be here.

 

And we

 

Alrighty,

 

are super

 

so

 

happy to have you.

 

yes, we are, we are. So before we get going, for those of us who might not know who Kent C. Dodds is, Kent, why don't you give a little background

 

Ha!

 

on who you

 

Who

 

are?

 

are they?

 

Who are those people?

 

There are definitely plenty of people listening right now who don't know who I am, I'm sure. Yeah, so I am a software developer. I've been in the business. I graduated in 2014, started doing software development a little bit before that. So I've been about a decade almost doing this web stuff. And I've worked at a number of companies, probably the most recognizable would be PayPal. I was there for a couple of years, apps to millions of people all over the world. And then I decided to go full-time teacher and I spent three years as a full-time educator. I built testingjavascript.com and epicreact.dev. And then I spent a year as a co-founder and director of developer experience at Remix, which we'll talk about today. And then a couple months ago, or about a month ago, I left Remix to go back to full-time teaching really big, big project I've been wanting to work on for years and I just can't do it all. So I have to focus all of my time on epicweb.dev and that's what I'm working on now.

 

So epicweb.dev is that the URL of epicweb.dev?

 

Yes, yeah, so the idea is we want to turn you into an epic web dev.

 

Brilliant.

 

Cool, yeah,

 

Hehehe

 

maybe

 

All right, so

 

I

 

Dan,

 

finally

 

we'll turn the

 

will

 

show

 

be

 

over

 

one.

 

to you.

 

Ha ha ha 

 

No, yeah, well, Kent, you brought up Epic Web.dev, so now we have to talk about that. So what is it? I mean, what are you building?

 

Yeah, so I've been teaching web topics since even before I graduated in 2014. I gave my first workshop on AngularJS to my classmates. I convinced Firebase to sponsor pizza so people would show up. And so teaching has just been a big part of what I've been doing forever. And for many years, I've just taught lots of different topics on the things that I was particularly interested in, So for a long time I've wanted to have just one place that had all of the knowledge that I have about the web in one place and in a cohesive format so that somebody could start having no knowledge of how to program at all, going all the way to having all the knowledge that I have. Basically being able to be a full stack engineer, building apps on their own or at a big enterprise company like I've done before. And so that's kind of the idea of Epic Web Dev. Whatever you're thinking it is, it's multiply its size and scope by about 10 because it is enormous. And I'm planning on working on it for the next two, maybe three years before it's actually completed. As far as like what it's like, anybody who's taken epic-react.dev, gone through that curriculum, knows that when I say it's big, I mean it, That series of workshops should take people about 14 weeks to complete. This one I'm thinking could take six months to a year to complete for anybody going through at a dedicated pace. And the specifics of how it works is you have workshops that have exercises and you work through each one of these exercises paired with videos from me until you get through it all and stuff, so it's pretty big and I, there's more to say about it, but I'll stop talking now.

 

No, cool. It's really interesting. But just to understand exactly what you're describing, this is going to be an online course that I'm going to, let's say, if I enroll to that, is that something that I do at my own pace in your website? Or is it something that also involves kind of, I don't know, online real-time sessions? Or is that something

 

Yeah.

 

that exists but is optional? include.

 

Yeah, great question. So there will be a number of pieces of content on there. I actually just published today the first piece of content that's a blog post. It's called the Web's Next Transformation. I'd love to talk about that some more as well. But there will also be podcasts, there will be interviews that I will do with experts to evaluate what I have built and give me feedback on that. And then the main bulk of it, what you're paying for is these self-paced workshops where I give you a GitHub repo that you clone. So we're gonna have beginner material on here. So there'll be like, I've never done any software development in my life. And so for those people, we'll probably have some in browser exercises and stuff like that. And then I'll also teach how to like set up a development environment and everything. And so then you get to that point and now we're cloning GitHub repos and stuff. and you're running it locally on your machine in the same work environment that you are going to be working in as a regular developer. I know there are a lot of really cool education sites that have these very interesting in-browser editors and stuff, and I think that's interesting, but I'm interested in helping you develop the skills that you're going to be using on the job, and you're not gonna be using an in-browser editor like on the job. So I want you working in the environment that you're gonna be working in, so that's why we have you download a repo. to work in your own IDE. Yeah, actually that's a very important aspect to what I do. On Epic React, part of the copy that we have on the homepage is talking about how important it is that this is going to be hard and it needs to be hard because learning has to be hard. You cannot learn easily. If your experience in learning is easy, then you're probably not actually learning. And so, especially for complicated stuff like web development. The trick for an instructor is how to give people enough of a challenge that they actually learn, but not so much that they give up. And so that is the skill that I've developed over the several years that I've been doing this. And so yes, Epic Web Dev will be hard, but there will be enough guidance there. Another thing that I do, just on the side, it's not something you pay for, but I do the office hours every Friday that I'm available. and people can just come in and ask me questions and things. But what I do in preparation for creating Epic React or what Epic Web Dev is going to do is I will actually develop the workshops and then deliver these workshops at least three times each so that I have some experience of actually teaching it with people so I can preemptively answer the questions that people are asking. I also get feedback on each one of the exercises. And so I have feedback, probably 10 to 20,000 items of feedback that people have given me on exercises so that I can really solidify them before I actually record them. And so what you actually get from Epic Web Dev is very solid teaching so that you can retain what you're learning and I can preemptively answer the questions that you have. In addition to just the videos, there's also written instruction that can be updated and reworded as people provide feedback as well. Yeah, it's pretty big. And I should also mention that, well, like I said, it is, there is so much in there. It will probably be 20 to 30 workshops. So there is a lot that we're gonna be covering for sure.

 

So if somebody is interested in expanding their knowledge, so is it like they pick and choose the workshops that they want or is it like you have like recommended curriculum for getting from certain point A to a certain point B, how do you actually pick what it is that you need to learn, especially when you don't know what it is that you need to learn?

 

Yeah, well, see, that's the thing is a lot of people don't know what they need to learn in and they think they do. And so for Epic React, for example, we have there are 11 workshops in total. Well, the content that can be represented by a level workshop is technically there are eight, but the last one can be split into four. But yeah, so the way we structure that is for one tier, the lower tier, you get like two or three workshops a couple more and then the last year you get all of them. And I've had a lot of people who say, I just wanna be able to pick and choose the workshops that I want. And that's, I understand what's driving that. You wanna be able to save money and just focus on the things that you want. But a lot of people just, I have had people who've been working with React for six or seven years, and they will go through the beginner material and be blown away by how much they learn. So I'm sorry, but you need this beginner material too. In my mind, the right way to learn something on the job is to just learn as much as you need to know for the job that you're trying to do and then push forward. Because we could spend our entire lives learning every single little thing there is, but if we never actually ship anything, then what good is it anyway? And so it's a very natural and I think a reasonable way to learn is just to learn the bare minimum for what you need for what you're doing and then ship. But when you're like, okay, no, I really wanna level up, I wanna learn this stuff, then there are just like so many holes in our knowledge of like the necessary learnings for shipping. There are so many holes that are left there that even going through the beginning material is going to be useful to you. So we don't really know what the pricing structure is going to be or how we deliver all of this stuff ultimately. And so I'm not gonna make any promises on that, but it will probably be similar to what we've had, with Epic React where each tier just unlocks more of the content and you won't be able to just pick and choose.

 

Yeah.

 

And I should also mention that because this is going to take

 

you

 

such a long time for me to create, I am going to probably release it in chunks because I need to make this sustainable, like I need to make money as we go. But the way that I'm going to release this is I need to actually work backwards so that I can say, okay, so here's the final thing, and we'll just work on some stuff to get there, and then I'll work backwards to you, what does it take to get to that point? And we'll build all the stuff to get to that point. So I will probably release the most advanced stuff first, and then we'll go to the intermediate stuff and the beginner stuff. And then I will quit, and I will never do anything ever again, because I'll just be done.

 

No, it does sound

 

I...

 

like a herculean task, I have to say. It's daunting, let's put it this

 

Yeah,

 

way.

 

it kind of is.

 

I'm kind of...

 

Yeah, yeah,

 

Yeah, the

 

yeah

 

thing is, I'm kind of curious by the way, is Epic React part of this or is it like a separate entity or how, what will be the relation between the two?

 

Yeah, great question. A lot of people wondered that about testingjavascript.com as well. So no, it will not be, the current plan is it will not be included. They will be separate. And Epic React and testing JavaScript will continue to serve people very helpfully for years to come, I expect. I will definitely, so the idea is that right now I am building a application that we're going to be building as part of the workshops. Oh, and one other thing I didn't mention is the entire thing, I'm building the entire thing in the open. So if you want to, you can watch me build the whole thing and then maybe you don't need the course, I guess, because you watch the whole thing be built. Many, many hours of watching my live streams. But so right now I'm building the app we're going to use and I am including in this app everything that like 90% of the web apps today are going to need, right? So we're talking about like regular CRUD, we're doing databases and authentication real time stuff, image hosting, translation, internationalization, all of the things that you would need at 90% of the web apps on the web today. So,

 

By the way, what are you

 

yeah.

 

using as infrastructure? I assume remix.

 

Yeah, yeah, good question. So Remix is gonna be the framework. The infrastructure is going to be on fly.io. That's what I deployed my personal website to and it's amazing. Very transferable knowledge there because it's just a node app and a Postgres database. Right now I'm using SQLite. SQLite is actually very surprisingly powerful. I think it's definitely production ready. So we may stick with SQLite, but we'll see. My personal site uses Postgres and Redis, but yeah, we may just go with SQLite. And then, yeah. Yeah, yeah, that's great, AJ. I actually deploy my personal site to six regions all over the world. And the reason I chose Fly was because Fly supported Postgres clusters with read replicas in each one of those regions in a very nice way. And so that's a great point. I definitely plan on deploying to multiple regions. We need to make sure that when we're talking about what things were meant to do, that we don't let that hold ourselves back because if we did, on JavaScript right now, because JavaScript was totally not meant to do what we're doing with it today. And I think that SQLite is actually seeing its own, coming to the next level of what it can do. There's this technology called LightStream that is really interesting or LightFS that enables you to have read replicas and synchronization of SQLite databases in multiple regions all over the world. I'm still exploring that. One reason why I really like SQLite is because it's just so darn easy to develop with. I don't even have to start up a Docker container with Postgres running on my machine and worry about ports and all of that stuff. So I really like SQLite for that reason, and especially when we're talking about teaching people who've never programmed a day in their life, it sure would be nice to not have to deal with all that stuff too. But again, that's not gonna hold me back from really doing what you're gonna do in the real world either. to explore it further. Mm-hmm. I agree. Mm-hmm. Hmm. Yeah, well, so that's why what I'm building is very important that it's real world, because in my opinion, if I can build something that is real world enough, then anything, any knowledge that you need for building this site will be enough for what you need to learn to be a full stack web dev. So the idea is, and specifically what I'm building, I'm calling it Rocket Rental. It's going with the epic theme of space and everything, It's like a toro.com, so where you can rent out your car or whatever to people. This, you can rent out your spaceship. And so it's going to have a lot of stuff in this for people to, or to, if it works for this site, then it probably will work for what people are doing. Now, of course, I'm not going to have millions of users and stuff, but I have deployed to millions of users and I know what environments like that are like. They're very complicated. But for the purposes of what we're doing, I'm pretty confident that by the time I'm finished, I will have something where I can pull workshops out of that for at least 20 to 30 workshops out of that. So that's the idea is I build this website or this app, and then we turn it into a bunch of workshops.

 

If I can take the discussion to a slightly different direction. You know, so last week we actually interviewed Diego Mauro. I think I'm pronouncing his name correctly. Who exactly the kind of person that's the target audience for your course. He told us the story of how literally he went from zero to hero within something like less than a year. From not effectively not knowing any web development to getting his first web development job. you know, something along these lines and he's now at the stage where he's actually expanding his knowledge as he works. And

 

Hmm.

 

one thing that I brought up with him and I, and he had like, he found his way but I'm not sure that it was the ideal solution and I'm wondering how you're going where the person gets stuck. And I'm sure you've had to deal with it in the context of Epic React. I mean, this is not new to you, but if I'm just thinking about the amount of times where I've learned a new concept and I ran into some roadblock and being able to actually reach out and ask someone who I knew was knowledgeable in that specific domain all the difference in the world.

 

Hmm.

 

And by the way, he did bring up several situations in which he literally almost gave up exactly

 

Mm-hmm.

 

because he didn't have somebody who he could reach out to and ask. And then eventually, he did find somebody, and that kind of resolved his issue for him. So I'm wondering how you're tackling that in the context of both Epic React and now Epic Web.

 

Yeah, yeah, sure. So that is challenging for sure. It is very helpful to be able to have people who can guide you. And I've certainly had people like that in my career. I've never really had a person that I went to on a regular basis asking questions and things, but it can be helpful if you can find something like that. So what I'm doing with Epic React is where you can, a person who wants to go through the material with other people for accountability reasons as well as being able to talk with each other about things, they can put a group together, I facilitate that, and then they go through the material together on a schedule that I have a recommended schedule that people can use. And then that helps a lot with the accountability of actually completing the course because how many of us have unfinished courses we've purchased, I think most of us do. And so that helps with accountability, but also being able to talk with people about the material as well, because maybe one person gets concept A and the other gets concept B, and together they can get them both. And then also my office hours that I do on Fridays can help people as well if they are working together and they can't figure it out together, then they can come talk to me and I can point them in the right direction. And then my Discord server, the KCD community on Discord, there are a lot of really knowledgeable people on there that can help each other. And I just encourage people to help other people because that is the best way for you to solidify in your mind the knowledge that you have is by teaching other people and answering other people's questions. And so through all of that combination, hopefully we take care of things. I think it's really important that I teach only the things that I know and understand. I know that sometimes an instructor will get invited to teach about some concept or some topic they know nothing about, and so they'll study about it for two weeks, and then they'll teach it, and then they'll move on. That is not what I do. I'm gonna teach you what I actually know. And I'll make sure that I deliver this content to real people many times pre-emptively answer the questions that people are going to have as they're going through trying to Apply this these learnings to their own projects

 

So in that context, and perhaps it's also kind of a segue to our next topic of conversation, it seems that while a lot of the foundations of web development kind of remain, I don't know if I'd call them static, but stable. You know, like HTML is what it is, and so is CSS. They might be getting new features and capabilities, but the old stuff still works. the concepts remain true. Same with JavaScript mostly. But if you're looking at the frameworks, for example, that are built on top of this web platform and the ones that we are using to build those web applications these days, these seem to be changing and mutating and expanding rate. So the question in this context is both for you potentially, both as an instructor and as the content curator, I guess, is like decide how do you decide what to put in, what to keep out, and how do you keep on top of all these changes in the industry?

 

That's a great question. So for Epic Web specifically, what I put in is what's required for building the app. And so that's a really good test for me, is like if it's required to know to build this app, then it's going to be included. If it's not, then it probably won't. And so that's actually why not all of the concepts that are in Epic React will end up in Epic Web, because it's not all of those things do you need. Like a good example is some of the patterns components. We probably won't need to learn that to build an app. That's mostly for library developers and maybe the component library developers at your company. Probably, like, maybe we'll get into some of that, but probably not. So that's my test of, like, do I include it or not? It's do I use it when I have this app? So as far as, like, the fact that things are moving so fast and changing a lot, you do have to put your flag in the ground at some point. Rails apps that are just fine. And that's, they're,

 

and

 

they're

 

chuck.

 

like, cooler things that you could do, better user experiences you could offer and stuff, but the app works and you're shipping and probably making money off of it. So that's okay, I guess. So yeah, we are gonna have to stick our flag in the ground at some point. Betting on remakes is kind of tricky because it is fairly new and so there will probably be changes. I'm hoping that all those, the more significant changes will happen before I have to start recording my videos. But, you know, things will inevitably change. The platform gets new capabilities. And so new frameworks take advantage of some of these capabilities. You know, you were talking about, talking with Mishko recently, he's got QUIC and QUIC would not work without service workers, just like would not be a viable solution. platform changes, libraries and frameworks take advantage of those platform features and we gotta record some new videos. So for the most part, the thing I like about Remix is that it's so focused on the web platform itself that lots of the knowledge that you gain in learning about Remix is transferable to whatever it is that you're doing. And hopefully we're able to maintain some of that stability that the web platform does have. So like I said, new features are coming and stuff, ways to do things, but the old ways will continue to work. And that's what I hope to be able to focus on, is using fewer libraries that kind of come in and out of fashion and more web platform stuff that's more stable.

 

So now you put me in kind of a crossroads, because on the one hand, we can talk about remix, which was one of the main topics that we brought you on to speak about. But you've also brought up the concept of building on the web infrastructure itself, which kind of leads to the topic of progressive enhancement, which you've also recently blogged about. So we can also go down that route. So

 

Yeah, let's do that

 

where

 

one

 

were?

 

first. That will lead naturally into remix, I think.

 

Oh cool. Then do we want to talk about progressive enhancement or is there anything to speak about even before that?

 

I think we can go, I'm trying to think of a good way to transition. You could say, well, you were talking about the web platform and you

 

Ha!

 

just published this blog post about how we built for the web.

 

We'll keep that

 

Then I

 

in,

 

can

 

we won't edit

 

go from

 

it

 

there.

 

out because it's too funny.

 

Here's what you can say, Dan.

 

Hahaha

 

We're all about the raw. We want to rip back the covers and show how things really work.

 

Alright.

 

No, but seriously, I'm about 2 thirds of the way into this blog post you recently posted. And it's really interesting because it comes on top of a lot of Twitter discussions and threads and even a bit of flame wars about how modern framework-based web applications should be built and what the approach should be and whether certain techniques are actually solutions or perhaps just stop gaps and whatnot. And this always falls back on the discussion of frameworks versus the underlying platform itself. You know, we have somebody like Alex Russell, who to an extent even dislikes the fact that we're using frameworks at all,

 

Mm-hmm.

 

rather than preferring the built-in capabilities of the platform. What is progressive enhancement and why should we care?

 

Yeah, yeah, so this blog post, the web's next transformation or transformation or transition. Yeah, I use those two interchangeably. It's transition is the correct. I just noticed my slides use the word transformation. But yeah, so I'm giving this both as a talk and as well as the blog post I just published today. But it kind of gives you a little bit hand wavy tour web applications since the beginning of the web over 25 years ago. The web, fun fact actually, web or HTML 1.0 was never standardized. We started with HTML 2.0. I don't know what that says about our industry, but it was standardized in 1995. And JS came only three months after that. And then HTTP was standardized even later in 96. And then CSS came a few months after that. how that all got started, but ultimately, the web is over 25 years old. And what's interesting is, actually another thing that's interesting is that XML HTTP request wasn't standardized until 2016. So we were using it like a decade before that. So that's kind of welcome to the web where we don't care whether it's standardized or not. But from the very beginning, we did have the standard of anchor tags and form elements. between pages on the web and you can make communicate back to the web server on the web with forms. And so once we got that then we had the ability to actually build web applications. And we had a couple different architectures that we've had over the last 25 years where that as the web progressed or as the function or capabilities of the web pop form progressed we were able to do than we could before. And so the blog post kind of takes you through each one of these and specifically shows you different use cases of code and talks about which side of the network those pieces of code are written and run. And so I specifically focus on persistence, so interacting with the database, routing, taking a URL and calling the right code for it, So calling into the data persistence layer and interacting with that data, sending that back to wherever it's supposed to go, data mutation, and then rendering logic. So what should be rendered based on the data that we have? And then UI feedback as that network tab, like it doesn't matter how fast your network connection is, somebody's network connection can be slow.

 

Thanks for watching!

 

Or it doesn't matter how fast your server is, like you don't get to control the network connection so that UI feedback is important too. to start it off, we had multi-page apps. That's how we started. That was like the only way to do it, unless you wanted to have the user install some plugin on their browser. And that was the persistence, the routing, data fetching and mutation and rendering, that was all on the backend. Like that was the only place it could be. We did have JavaScript on the front end, and maybe there was somebody in there like throwing up a spinner when you hit submit on a form, but that probably didn't really happen. that I ever saw.

 

את הילדות של אספי

 

Yeah, yeah, exactly.

 

and Cold

 

And

 

Fusion.

 

like, we talk about those as good old days, but some people are still working in that. And so, MPAs aren't like gone. People are still building multi-page apps, for sure.

 

You know, for so many cases, that's actually, well, actually that augmented, which is your next step actually, is

 

Mm-hmm.

 

the technically correct solution. I mean, so many times these days I see people, I'm kind of jumping the gun, but so many times these days I'm seeing people implementing stuff as single page applications where, you know, from a technical perspective, served from being a multi-page application. But again, I'm kind of jumping the gun. And so as you said, as you described, we kind of started with doing everything on the back end. And then I have to throw this in as well. Something like, I don't know, 13, 14, maybe even 15 years ago, I gave a talk somewhere about the fact that the tech world is kind of a yo-yo where the whole client server, where everything end because it's a mainframe, then everything moving to the front end because it's PCs, then everything moving back to the back end because of client server, and then everything moving back to the front end and then to the back end again because of the web. And it's so amusing how that pendulum keeps on swinging from side to side. Because every time we swing too far to one way, and then we run into all sorts of problems which kind of gets the pendulum swinging the other way, but then again, it swings too far and you know, that's the way it is, I guess.

 

Yeah, you know, I like to think of it more as an upward spiral than a pendulum, because I do think that things get better, or at least some things get better with each transition. Maybe some other things get worse. But I do think that there it's not like we're just doing this just to do it. Like there are actual pain points. And in particular, for MPAs, the pain point was we didn't have control over UI feedback. So as the user clicked on, you know, submitted a form, we couldn't very easily put some spinner in place or whatever. You could, but nobody ever did. It was just not a very common thing that we could do very easily. So you couldn't have multiple, imagine if every time you like a tweet, you get a full page refresh.

 

Yeah, I really like that example that you gave in the blog post. I think that

 

Yeah.

 

that exactly highlights the problem. Both of the response

 

Yeah.

 

time, the indication to the user and the fact that the state of local HTML elements is not preserved between navigation.

 

Mm-hmm. Yes, yeah, exactly. And the web platform is working on that. We're trying to have navigation, where you can have animated navigation with the page transitions API and stuff. But it's not here, and it certainly wasn't over a decade ago when we were doing MPAs primarily. And so for this reason, we transitioned. We transitioned to progressively enhanced multi-page apps. I call this a PIMPA. I don't think anybody's ever called it that, but now we're gonna start calling it that. It's a full follow.

 

I think we just

 

But

 

called it jQuery.

 

yeah, yeah, yeah. jQuery spaghetti was another one for sure. But the idea here was now we want to write some code on the client and we're going to have all of the existing code that we already had. Nothing changes on the server or nothing's removed from the server because progressive enhancement is about having a baseline of functional app. And then you use the capabilities of the browser to enhance the experience. And so this kind of happened around the time Microsoft Office web team came up with this XML HTTP request thing and people started using it and then Google Calendar and Gmail came out and they were the big, like first, probably the biggest apps to first use AJAX. And

 

I've got

 

with

 

an

 

that.

 

interesting story to tell you about it sometime.

 

hehe

 

One of my claims to fame is I think I myself created the first, effectively PWA, with all this stuff somewhere in the late 90s. But that's a story for another day.

 

Wow, yeah, that's impressive. Sounds dangerous.

 

Yes it was.

 

Yeah, fun.

 

IE4 would crash.

 

I imagine it would. Yeah, so Pempa is, you keep all the same server code, but you actually add more because now we have to have API routes for handling these AJAX requests that our client is going to be doing. So you have more code on the backend, and then you also have code on the front end. So you have routing code that you're gonna do prevent default when the user clicks on a link. You have data fetching code for when the user gets onto a page, we gotta go get the data for that page. Because the server render, you know, for getting the initial page, that document request, it's gonna have all the data and everything, it's fine. But if you navigate to another page, you gotta have some way to get the data for that page. So we've got data fetching logic now. Your forms are gonna prevent default, so we're gonna have, you know, on the client as well. And then we have rendering logic on the client and this is the big pain right here. So you have some Rails template on the backend here. Actually, can I pause really quick? My son is trying to get my attention.

 

Should we have told him no? Can't hear you, AJ.

 

the advantage of having grown up kids. Although I can tell you there are a lot of disadvantages as well.

 

Me too.

 

There is a saying in Hebrew, little children, little problems, big children, big problems. AJ you're muted by the way. Yeah. How old is he, Ken?

 

Uh, he's my youngest, he's five.

 

Oh wow.

 

Yeah, so my wife is getting us ready for our trip tomorrow and so he feeling like he needed some adult attention decided to come down to

 

and

 

me.

 

he is correct

 

Yeah.

 

by definition

 

Yeah, exactly. So I left off talking, just getting into the rendering bit so I think we can chop in a pretty good spot

 

Yeah,

 

here.

 

no problem.

 

So the rendering logic is the really tricky piece You have to have a functional app and then you progressively enhance, right? So you add JavaScript to make it better. And if we're talking about the GitHub issues UI, for example, when I land on the GitHub issues UI, if it's got comments in there or something, then the server, the Rails backend that they've got is going to have some sort of template that will generate each one of those rows of comments. And then I decide I want to add a comment, so I'm gonna type in, I hit enter. I need to have some way on the client to render that new comment. So what that means is I have to have a template on the client that will, you know, and then do the DOM append or whatever needs to happen. So here's the unfortunate bit. We've got this Rails template and then we've got this JavaScript template. These cannot be shared. There's gonna be logic there. There's gonna, all sorts of things are gonna have to be duplicated between not only different sides of the network tab, but also different languages completely. And this was an enormous problem for progressively enhanced multi-page apps. And this is why we actually didn't hang out in this phase for all, well, I guess we did hang out there for quite a while, but a lot of people really hated it. Yeah.

 

Yeah, I think there were like two, let's call them interim solutions. One which was to really limit the stuff that you did on the front end to mostly

 

Yeah.

 

just, like you said, to spinners. So at the end of the day, you still did most of the heavy lifting on the back end and not on the front end. The front end was stuff that usually was not associated with routing, for example. So

 

Mm.

 

you as long as you were able to stay within the same URL within the same address, you were kind of OK. So that's one thing that I think most of these applications did. And there were some interesting attempts, which I think ultimately all failed, of kind of compiling back end code into JavaScript. I seem to

 

Mm-hmm.

 

recall that kind of stuff, that you write your code, let's say, in ASP.NET, and then that ASP.NET automatically generates JavaScript for you that does the front end stuff.

 

Yeah, I-I-

 

that's not a route that ever became truly popular. I think Aguilar

 

Yeah, I-

 

came along and swept all that away.

 

Mm-hmm. Hmm. Oh my word, yeah. Yeah, yeah, I used GWT at USAA during one of my internships and boy, that was so awful. I did not like that at all, GWT. So yeah, so it was not a pleasant time from a developer experience standpoint, but we got an improved user experience, right? No more full page refresh when we favored a tweet. So that's good, I guess. But this is the reason why single page apps became a thing. Because they're like, we need to have this user experience, but by golly, this DX is awful. So let's just, instead of duplicating templates on the server and the client, let's just delete the templates from the server. And in fact, we'll also delete all the server rendering altogether. So we can delete a lot of other data fetching mutation code as well, by deleting all this rendering code, like lots of routing codes as well. for your app, at least for getting the web app for the document request is literally just like for anything that doesn't match a static file, just send them this index HTML with a 200 and we'll just pretend that 404s don't exist. And that's the de facto standard now. Most web developers who are working on projects are working in a single page app. So we got rid of the code duplication, which is great, but we made everything else worse. So if we're thinking about the document request, that is way worse, way worse, because now you have to download the file, you have to download the JavaScript, and then you have to do the routing, and maybe you have to download more JavaScript because you're code splitting, and then you do the data fetching in your component, and then you get the data back and you do the rendering, and oh, you rendered an image, now we gotta go get the image. This waterfall effect just destroyed the user experience But we sure did improve the developer experience by deleting

 

I'll

 

this

 

tell you

 

code

 

something.

 

duplication.

 

It kind of, no, I'll tell you something, AJ. It kind of, and Kent, it kind of worked for a while. It kind of worked until more or less 2007, or even 2010, before the mobile web became a thing. Because

 

Hmm.

 

when you were working primarily on the desktop, you kind of could get by with this sort of a behavior. there was still degradation user experience. Suddenly you had the whole concept of that flash of white because of the empty body HTML that was just triggered to load everything. That happened on the desktop as well. But where it became totally unusable, I think, is the mobile web. When on the mobile

 

for sure.

 

web with mobile devices, and by the way, from my perspective, it's interesting. Wix used to work this way. When I joined Wix back in 2014, then the way Wix worked was using what is known as client-side rendering, or CSR, of doing these single-page applications, but doing all the rendering on the client side. And like I said, it kind of worked, because when I joined back then, something like 70% or 80% of sessions came from desktops. But then mobile really took off like a rocket. And when you've got mobile connectivity and mobile performance, especially on Android, and especially on the lower end Android devices, it just can't fly.

 

Well, and unfortunately, single page apps are not necessarily more performant. Well, yeah, just what you said. It's not just how much you're downloading, but how much you're executing as well for those low end devices too. And so we went from running a bunch of code on our beefy servers to running a bunch of code on these teeny devices that, yeah, maybe that's more compute than what we sent people to the moon with, but it's still a problem. This was definitely an improvement for the developer, for anybody who wanted that user experience that we were looking for that drove us to the Pempa. But yeah, like Eji was saying, it's not actually all that great from a developer experience standpoint compared to an MPA. It is definitely improved from a Pempa, but not from an MPA. That's the progressively enhanced, that's progressively

 

That's

 

enhanced

 

having

 

multi-page

 

the templates

 

apps.

 

on both ends, of doing rendering both on the back end and on the front end, using separate code bases and even using distinct programming languages.

 

Mm-hmm. Yeah, so that. Yeah.

 

But it's beyond cuteness. I mean, we had a real problem. I mean, keeping

 

There

 

those

 

was,

 

templates

 

it was,

 

in

 

yeah.

 

sync was effectively impossible. It was not possible to add features when you had to implement every single feature twice. In two different

 

Yes.

 

programming languages, two different developers, it was just not workable. You know that famous story of how Angular came to be because they worked on some project months and then Mishko came and proposed Angular, the first iteration of it, implemented it in less than six weeks because he could only,

 

Mm-hmm.

 

he only had to do it on the one side, not implement everything twice.

 

Yeah, yeah, exactly. And he did it by himself and they had a team. So it definitely was an enormous improvement from that standpoint. Oh yeah, I agree with you.

 

It's even worse than that. No, service workers came along a long time later.

 

much later.

 

Yeah, the bigger issue from the get-go was search engines. I mean, when you were doing those client-side rendered single-page applications, initially, the search bots just couldn't handle that, which resulted in awful hacks of, again, kind of having to, again, generate thing twice just because of the search engines. The only benefit being that the version that you created for the search engine, you didn't really care about layout and stuff like that. It was just basically pushing out the content.

 

Mm-hmm.

 

So yeah, so there were a whole bunch of issues. But you're absolutely correct, Ajay, that when we moved to that place, the ways. And it

 

Hmm.

 

wasn't really always obvious to the people, to the developers who were doing it, what they were losing in the process.

 

Yes, and this is actually very important because when you enter a transition, you don't typically understand all of the trade-offs that you're making because nobody's done it before. It's like when you were dating, you feel Twitter-pated about this person, they're amazing, and then eventually you learn all their warts and you're like, oh, gee, they're not so great. And then you move on to somebody else and you're like, wow, they're amazing. And then you find out later they've got problems. And I think this is the same way in technology. Yeah, exactly. Because they are settling with you despite your flaws.

 

Yeah, my wife chose me for who I am and she's been trying to fix me ever since.

 

Yeah, well in any case, we did, for a lot of people, for a lot of people the problems that Spas had were not big enough problems to justify either going with a poor user experience with a plain MPA or the terrible developer experience with code duplication across these different languages. So they just went with Spas, they're like, oh, I'm behind my login screen anyway, or who cares about status codes, whatever. They just didn't realize the impact that it was. And I don't think that, for a lot of them, I don't think that they're wrong. And especially with more modern implementations of single page apps where you have static site generation, for some use cases, that's sufficient. There are a lot of really significant shortcomings to static site generation, and there are very few use cases that can leverage that effectively, especially considering can be your SSG server

 

Yeah,

 

as well.

 

but with static site generation, at least you're not delivering an empty HTML. I mean,

 

Yeah,

 

yeah,

 

it's better than the empty HTML for sure.

 

because like you said, because as you said, there are actually two things that kill you with this type of an approach. One is the processing, which is especially problematic on low-end devices, but potentially even more significant, at least from the user initial perspective, again, like you said, the waterfall. One

 

Mm-hmm.

 

of the things that people don't realize about HTML, when you put the content into HTML, HTML is streaming. And the browser uses it as it comes down the pipe. So as soon as the browser encounters that image tag in the HTML that's still downloading, it's immediately going to start downloading that image.

 

Hmm.

 

that single page application model, that spam model that we just described with client-side rendering, like you said, you first download the entire HTML. When that's done, you download and parse the JavaScript. When that's done, you download and parse some Ajax. And when that's done, that's when you finally can start downloading your images. So

 

Mm-hmm.

 

like your images are like round four versus

 

Ja.

 

from the get-go. And you know we've

 

Mm-hmm.

 

got tricks and hacks to work around it and whatnot, but at the end of the day, I recently tweeted that if you're using a single-page application, a client-side rendered, the client-side rendered approach, and you know a lot of people still are, you're not going to have good performance. And if you're on mobile,

 

Mm-hmm. Yeah, well, and the other thing is, a lot of people will say, well, yeah, you just use SSG and now you get your image right away. But can you imagine trying to do static site generation for Twitter or Amazon or so many of the

 

Yeah,

 

other

 

but for me,

 

sites in the world?

 

I have to say that SSG is just a certain optimization on SSR.

 

Yeah.

 

So let's get to that before

 

Yeah,

 

mentioning.

 

yeah. So I would say that... Oh yeah. like so much faster to render. That's exactly what they're doing. Yeah, yeah, sure. They've got client side transitions for sure, but when you land on that page, you better believe that they're optimized. The amount of money that they lose for not being optimized

 

Thanks for watching!

 

is significant. So I think we'll move on from there.

 

Yeah, and because we're kind of jumping the gun here, because there are certain interesting optimizations on all the models that you could talk about, like edge computing and the gem stack

 

Mm-hmm.

 

and stuff like that. But I think, again, these are optimizations on top of the basic approach. So I would prefer

 

Mm-hmm.

 

that we first talk about the next stage before we

 

Yeah.

 

get into these details.

 

Yeah, sure. So the next transition that I'm really excited about and observing in the web frameworks and everything that's happening is what I'm calling progressively enhanced single page apps. So we

 

I

 

had

 

apologize

 

MP. MP. MP. MP. MP. MP. MP. MP. MP.

 

if

 

MP. MP. MP.

 

I'm

 

MP. MP. MP.

 

interrupting

 

MP.

 

you, but I think you kind of skipped a half step. I mean, because we were at client-side rendered, and before client-side rendered, we had SSR, but without, potentially without progressive enhancement, just as SSR. Don't you think?

 

Yeah, I think that Gatsby and Next.js with their SSG, instead of Excite Generation, and yeah, I guess Gatsby

 

Like, React

 

and Next both

 

at

 

support

 

SSR,

 

SSR.

 

React at SSR, theoretically at least, from, you know, way back when in 2017, I think.

 

Mm-hmm.

 

So.

 

Yeah, I would put that as kind of like a maybe,

 

Yeah.

 

it's really hard to place that. I think it's maybe a small bump, but I wouldn't call that a transition. Because,

 

I'll put it this

 

yeah.

 

way. The term has kind of fallen out of favor. I'm not hearing it used anymore. It was really big a while back about the concept of isomorphic code, about the concept

 

Yeah.

 

of what React enabled to an extent with the VDOM, the fact that you could take that same code that you ran on the client, the client-side rendered stuff, that for example, the Angular model. But now you could also run that same code on the server side. And you kind

 

Mm-hmm.

 

of solve that double template conundrum by running that same JavaScript. Now, it's TypeScript code on both ends, both on the server side and on the client side, so that if you did that transition, if you were already in the client and you did the transition, it was all handled client side. But if you press F5, then it was all server side and it was the same

 

Mm-hmm.

 

code and the same templates that did that thing. And I think we kind of got to that point before people kind of were thinking explicitly about progressive enhancement. At least that's the way that I personally am reading it. You might disagree with that.

 

Yeah, no, I agree that that does make sense and probably should be called out specifically. Maybe that to me, that was just, it's such a short-lived thing that I'm not really considering a transition because we are very quickly moving into what I'm calling progressively enhanced single-page apps or PESPAs, where the idea we are borrowing lots of that capability of SSR React or SvelteKit or Svelte or whatever it is that you're using or Angular now too. But the key here with a PESPA is that routing data fetching mutation and rendering is all shared across, that code for that is all shared across the network chasm. And in particular, it'd be really nice to have a framework for that. But for as far as what the behavior architecture looks like, your document request looks just like a Pempa. In fact, a Pespa is very similar to a Pempa, Progressively Enhanced Multi-page App. In many ways, the only distinguishing characteristic is that the code is shared and it's the same on both sides of the network chasm. So your document request looks very similar to even an MPA, except it just loads JavaScript when it's finished. Your client-side navigation looks very similar a PEMPA except you're routing logic on the server and the client or it's the same. You're rendering logic between the server and the client is the same. And so you don't have to worry about doing that duplication anymore. The same thing with what, another thing that really separates a PESPA from what these SSR SPAs are doing is that the mutation code is the same. Whether you're doing, and it's hand, it's the same whether or not JavaScript is on the page. And so what matters about this, it has nothing to do with the fact that we want this to work without JavaScript on the client. But everything to do with the fact that we want the mental model we had with MPAs. And so whether you're doing an inline mutation like favoriting a tweet or a redirect mutation like creating new GitHub repo, in either case, the mental model as far as the code that you write is going to be the same. And so this brings us back the simple mental model that we had with NPAs. Like it was, people who've been in this industry for 25 years or like even over a decade are like, my goodness, why is it so hard now? It is like building web apps is so much harder than it used to be. Why is it so hard? And the reason that it's so hard is because we lost the mental model by bringing everything into the client. And now we have caching to deal with. We have to cache the state that's actually on the server. If you can pretend that your app is written like an MPA, then your Redux store is actually just the database. There's no store there.

 

you

 

Everything lives in the timeline of a network request. And so with the PESPA, because of this particular architectural distinction, we can get this, the same mental model that we had with an MPA, where a network request is made to do some sort of mutation the page is updated automatically like it was with an MPA. You never thought about updating the data that was on the page with an MPA because you got a full page refresh and you regenerated the whole document with whatever the latest was. And so the PESPA architecture has a focus on that.

 

So to try to put it into a practical perspective, and please do correct me if I got it wrong, let's say I have a form on the page. Let's say to make things simpler, this is the first page that I'm going to go into. Let's say it's even the signup form. So it's like the very

 

Hmm.

 

first page. I get that first page directly because it by the server side. It's JavaScript code or TypeScript code but running on the server side, either at runtime or at build time, doesn't really matter. It downloads directly the HTML with that login form. Now the user fills in the form and clicks the Submit button. And this could be handled in either one of two ways. It could be handled by either doing an actual form submit that default functionality, not even having a JavaScript to intercept, just letting the browser do its thing and do the HTTP post. Or alternatively, it could be intercepted by some JavaScript that cancels the default behavior, instead wraps it up and does, let's say, some sort of an Ajax call, gets back the result, and updates the and does the routing and the updates And if I understand

 

Mm-hmm.

 

correctly, what you're saying is that with this new model, and I'm still I still haven't memorized the acronym that you're using,

 

Yeah, that's okay.

 

and the thing is that either one might happen and they're both okay. If for some reason the JavaScript hasn't loaded yet, then I'll use the default behavior. If the JavaScript has loaded, then I'll use the JavaScript-based behavior. And it might be a question of network timing, because the user clicked really quickly before the JavaScript downloaded. Or it could be like an intentional decision on the part of the developer saying, in this particular case, I don't feel like downloading the JavaScript. It's not needed. I'll just make do with the default behavior. functionality and I will use the JavaScript in this case, but not in that case. Am I getting it correct? Am I describing it correctly?

 

Yes, you're describing the behavior correctly, but the intent, I think, is a little different. So the point isn't that we want less JavaScript in the client, because we absolutely do. MPAs, there's a reason we're not just building everything as an MPA. We talked about that, full page refreshes and UI feedback control. So we do want client-side JavaScript. The reason that this matters is because it gives you the simple mental model of an MPA. pretending that there's no client-side JavaScript. And then you can go back in later and add in some nice little enhancements with just a tiny bit of code without making big architectural changes to the way that you're writing your code. And then when the application actually performs, then yeah, maybe there's a failure in loading the JavaScript or something like that, which actually surprisingly happens quite a bit. And it will perform just fine either way. And so that's a nice, But the real, the major benefit to this is that we get just a wonderfully simple mental model for building our application. And then on top of that, we also get a better user experience because the application is ready to go as soon as the HTML is downloaded, for the most part. Now there are certainly some applications that are totally not going to work without client-side JavaScript. But there are a lot of pieces of each of those applications that probably will work without client-side JavaScript. A good example of this is Figma, where you've got this canvas and you can't render canvas on a server and it may be like, you probably wouldn't even want to. I mean, you could probably pull up playwright and like render, you know, some image or something, like if you wanted to, uh, to, to speed up, um, the perceived performance there, I guess, um, there are optimizations you can make for sure, but, um, Ultimately, you're probably going to want to have clients that JavaScript for that. But there are a lot of, uh, features of Figma, um, that are like a lot of what Figma is, is not the canvas. And so there are other pieces that would benefit from a user experience standpoint from progressive enhancement. But really the major benefit here is a simpler mental model. Another thing though, is that PESPAs push a lot of code over to the server, like tons and tons of code. Most of the data mutation and data fetching code all goes onto the server. And by doing that, we also improve the performance for the user as well, because there's less code to download, less code to execute. And so like it ends up making it a lot faster from that

 

Yeah,

 

aspect

 

but

 

as well.

 

that kind of depends on the framework and how you're using it because at least for now, in so many cases, all the code, the framework code and the application code downloads the client side whether you really need it or not.

 

Yes, well, so I would say like, I know you're alluding to quick and resumability and just downloading the pieces that you want,

 

Not

 

which

 

just QUIC,

 

I think is great.

 

not just QUIC. I know that React is working in that direction as well with stuff like React server components and there's the concept of islands of hydration. So

 

Mm-hmm.

 

yeah, QUIC is kind of like for them it's kind of like front and center. They're kind of focusing on that. But they're not the only game in town in you know in dealing

 

Yeah.

 

with this issue.

 

For sure, and for me, that is another optimization that a PESPA could take advantage of. React certainly doesn't. So the next lead into this is like, now Remix is an implementation of a PESPA, like you get a PESPA out of Remix, but others are following, like SvelteKit is adopting the same behaviors. Solid Start also is doing this. But what I'm talking about is, we're taking probably 50% of the code that developers work on daily is around state management. And we're just throwing all of that away because we're pushing tons of code over to the server. And then we're adopting the mental model of an MPA. And so there's just a lot of things you don't have to think about when you have that mental model of an MPA. And so we push a lot of code over to the server, we delete a lot of code that just doesn't need to exist anymore. And then we can further optimize things architecture or the resumability

 

So again, if

 

or things

 

I'm pulling

 

if we want.

 

it to a practical example, something that I at least need those real life examples. So let's say I have a fairly standard CRUD application, which is just a sequence of forms. And in the old client-side rendered approach, I might have, I don't know, a Redux store in the client side containing all the data. it gets synced back to the server every once in a while. And I guess that's not the approach that you're going to take with something like with the remix. So with the remix, am I going effectively back to being a multi-page application? Every time I click on a form submit, it's going to do an actual form submit? Or is it going to do an Ajax call, but effectively not maintain or maintain a minimum amount of state in the client side, maybe just the component UI state and nothing beyond that, that the applicative state is all moving back to the backend. If so,

 

Yeah.

 

how is it managed on the backend in that case?

 

Yeah, yeah. Just to answer your question, it will work like AJAX, like a fetch request, because we do want that UI feedback control and no full page refresh. But what the standard behavior for a spa is to do a lot of logic for what APIs you're hitting and different things on the client. With Remix and just with PESPAs, a thin client here that just knows how to to re-implement the, or emulate the braze behavior of the browser. And so we prevent default and then just do the same thing the browser would have done. And that is like a couple hundred lines of code, of very complicated code, but if it's built for you and well tested, then go ahead and use it. In Remix, we call this the transition manager. And so that manages all of the states and then it manages updating the data that's on the page like the browser would in a full page refresh scenario. So with that thin amount of JavaScript, then we make the request and then your backend code, which in Remix is in the same file as your UI code, is going to handle talking to a database directly if you want to because it's backend or using a private key for some third party API because it's backend and you don't worry about sending private keys to the client. or talking to like 30 different services, like setting up a queued email or whatever. And typically, if you're gonna do something like this in a spa, then you have to have an API route for all of these things. And there's enough friction there that you're like, oh, I'll just do a fetch with these, like I can do that, I have cores or whatever. And so in any case, you end up with a lot more code on the client because you're basically re-implementing the transition manager all over the place. like React query, which helps a lot with that, but still, there's a lot of code that you don't have to write if you're using, if you have built things like a PESPA.

 

You know what seems to me now that when I'm listening to the way that you're describing it, is that effectively when we moved, we I'm talking us, the web development ecosystem, when we started transitioning past the client side rendered to also taking advantage of server side rendering, we kind of kept all the client side rendered baggage. client side talking to potentially even various microservices directly from the client side and managing the state logic on the client side. What you're saying is that you're basically, it's more than a technological shift, it's a mental shift of saying, let's throw away all this stuff that existed on the client side. submission endpoints, but instead of it being in the actual built-in browser functionality, the same endpoint is being hit by the Ajax call that's being generated for you by the

 

Yes, yeah, precisely. And Remix is just an implementation of a PESPA. And I don't think that you'd wanna build your own infrastructure or framework for a PESPA because we've already got one, it's Remix and it's great. And eventually Remix will also support other UI libraries. So if you're not into React, like that's, first of all, I'd say Remix turns React into something more akin to a template library than anything else. And so the things you don't like about React But additionally, Remix will eventually support Vue and it will support others. Somebody on the Remix team, Jacob, was just yesterday working with Enhance, which is this new fun web components thing, and building Remix support for Enhance just for the fun of it. So you'll get the PESPA behavior out of whatever UI library that you want because so much of what a PESPA is is just like some way to render some UI just wires up all of the routing and everything for you automatically, which is pretty stellar.

 

Yeah, the interesting thing here is that, you know, you might be trying to minimize the role of React, and that's a great thing. Don't get me wrong. But I'm not sure that React really wants to be minimized. Specifically,

 

Hehehe

 

they're adding a lot of functionality and capabilities that kind of push back against this minimization by forcing particular architectural like the React server side components.

 

Mm-hmm.

 

They kind of influence the way that you're doing these sort of things. Or the suspense mechanism, and the selective hydration, and the suspense boundaries, and stuff like that. Can you really ignore that all this baggage this type of progressive enhancement based meta framework.

 

Yeah, that's a great question. So React is doing a lot of really cool things and there's one feature coming soon to remakes called defer, which allows you to stream. Well, so first of all, you can stream right now, no problem, like you can, with remakes, you can stream HTML, but most of the time that doesn't matter or make much of a difference because by the time you start streaming, actually already got the HTML and like, that's gonna, you know, you're gonna save seconds, congratulations. But what's really cool about defer is that it takes advantage of suspense and concurrent features in React 18 so that you can actually start sending the HTML before certain bits of data have actually finished loading on the server. And so this is actually very, very cool. I want you to pay close attention to what happens. Let's imagine you are a product page, you've got this product page, you've got the title, you've got the description, and then you've got reviews. And we'll say that the reviews are really slow. I get, for some reason, the backend for that is really slow. So with the server rendering that page, you have two options. You can either wait for all of those reviews to show up before rendering the page, which is not gonna be good because you're gonna lose sales, or you can, well, I guess you've got three options, or you can just not render that page on the server at all which is also problematic for various reasons we already talked about. Or you can just say, well, I'm gonna just render the UI that's important, and then when the client shows up, then I'll go and make a fetch for those reviews. And that's probably what you would do.

 

Yeah, and that's effectively the gem stack approach.

 

Yes, exactly, yeah. Except the Jamstack doesn't typically, well, you would static site generate

 

Well,

 

that

 

yeah,

 

page,

 

although at

 

yeah.

 

a certain point in time, the guys doing gemstack decided that they're no longer going to be tied to static site generation. But then everybody

 

Yeah,

 

stopped.

 

because they saw the shortcomings.

 

Yeah, and then everybody stopped using the term gemstack. And then

 

Yeah,

 

the rise

 

yeah.

 

and fall of the term gemstack has been kind of meteoric on both ends, I have to say.

 

I'm glad that you see it that way, Dan. That's exactly how I see it as well. So yeah, so that's how you would do it with Jamstack. So here's the problem with that. So first you get onto that page, you've server rendered the stuff, you download the JavaScript, and now you're making the fetch. So this is like basically a document request in a spa, like hindsight render problem, right? So that's fine because most people aren't gonna look at the reviews right away. But what if we could make it so that we started for the reviews as soon as the document request showed up. And so that's what defer allows you to do. So in Remix, you have your loader function that runs on the server. As soon as the request comes in, Remix is like, okay, server, go get your data. And then it's waiting for the data to come back. But with server rendering, those reviews, that's a problem because we can't wait for those reviews because it takes too long. So what we do is instead we say, we'll send you back all of the data that's really important, but then we're actually, we're not gonna wait for the reviews. and then Remix is like, oh, you just gave me a promise. Okay, I'll go ahead and render the UI, and then in your UI you say, hey, for this particular thing, if it's a promise, then I want you to render this fallback. And so it sends the fallback and it streams that out. But the HTTP request continues or stays open while we're streaming stuff. And so when that promise finally resolves on the server, it sends the rest of that to the client and then React 18 streaming will swap out the fallback the latest stuff. And so in certain situations, you could actually save yourself 500 milliseconds, maybe a full second or two, by optimizing when you actually kicked off that initial request.

 

And I have to ask, why is it better than just doing it on the client side? Because the framework does the heavy lifting for me or?

 

So that is really nice. It actually feels like promise teleportation is what we call it. Because it's like, I had a promise here and now I have a promise here on the server and now on the client, it's amazing. But primarily because the user experience is so much better. And what's really cool about this is the API that Remix gives you for this is such that you could A-B test this. You could say, do my conversions really get better if I wait for the reviews or not? Because it's just a matter of like an if statement in your loader. Like if they're in this bucket, then do this behavior.

 

And is this a remix feature or is it a react feature or is it a remix feature

 

This is.

 

built on a react feature?

 

Yeah, exactly that. So React has this capability for streaming. Remix takes advantage of that capability to have this defer API. And so others will probably implement something similar to this eventually. It is not trivial, but it is, now you've got a reference implementation you can take a look at. But anyway, I brought all of this up just to say that React does have some unique things about it to the curb. A lot of people, especially if you're watching Twitter, you'd think that React is already dead and buried. That couldn't be further from the truth. React is still three times more widely used than all the others combined. So it's like, it is still so enormous.

 

Yeah, and jQuery, by the way, is still, I think, nine times more commonly used. I recently found out that jQuery UI is six times more commonly used than React. Things on the web never die. They hang

 

Yeah,

 

on forever.

 

well,

 

Once you've passed

 

that-

 

a certain threshold, I mean, Mootools is dead. But once you've passed a certain threshold, you'll be there forever.

 

No, I think we can explain the jQuery thing because of WordPress.

 

That's true as well, but WordPress is another thing that will never die. Yeah, that's...

 

No, that doesn't take it away, but let's have some distinction between code that developers are working with on a regular basis versus code that people use. There's a big difference. The fact that jQuery is being used by the web, that doesn't matter as much for us as developers and what we should be using our mind space with. or a hundred times more developers working with jQuery. That is not true. Right.

 

Oh

 

So,

 

yeah,

 

I'm going to

 

for

 

go ahead and

 

sure.

 

start the presentation. So, I'm going to go ahead and start the presentation.

 

But that said, there's this amusing saying, which like all amusing sayings has a significant grain of truth in it, which is that while JavaScript developers are busy picking frameworks, PHP developers are busy choosing which Lambo to buy.

 

Ah.

 

Because there are fewer of them, but they're kind of responsible for a bigger part of the web effectively.

 

So that, did that saying come around because somebody big in the PHP community posted a picture of their Lambo,

 

Probably.

 

and now all of a sudden everybody thinks that Lambo, like PHP developers are crazy rich? That is not true. I would be very interested, like that meme actually bothers me a bit because I would be very interested to see what the pay rate for a PHP developer versus a JavaScript developer is. An actual like stat and I would expect I expect they're probably pretty similar

 

The thing is that I have a problem with all of these payments. We kind of took a detour, but we're there, so I'll mention it anyway. I think the whole concept of what is a web developer is so problematic. The term covers so much ground, and that makes all of these income comparisons really problematic.

 

Mm.

 

in WordPress is often called a web developer and somebody, I don't know, coding Gmail is called a web developer and they're certainly not doing the same thing

 

Mm-hmm.

 

and are probably, you know, not paid on the same grade or scale or whatever and it's really difficult to do comparisons between the two. Anyway, I

 

Yeah, well, and I'll just mention one

 

But

 

other

 

my

 

thing.

 

whole point, just to finish that, was that I still contend that once a technology becomes sufficiently, like passes a certain threshold on the web especially, it will never die which means that there will always be people doing React stuff, like forever.

 

Yeah, 100%.

 

whatever framework du jour, it's, you know, even if that framework becomes really successful, React is here to stay.

 

Oh yeah, 100%. And because React has such an enormous lead, it is here to stay for a very long time. So yeah, absolutely. And on top of that, React has not stopped innovating. You mentioned earlier in passing that React has selective hydration. It does with suspense boundaries. If you have multiple suspense boundaries, it will hydrate the ones that are, I'm not sure if it does this today, but they absolutely are working on this you interact with first is going to get hydrated first and it'll replay events and things.

 

I really will need to dig into how that works, because that seems to me to be a, well, obviously, suspend boundaries tend to be hard boundaries in context of managing state, not just framework state, but also applicative state. But still, the fact that the application is effectively initialized or executed in a different order based on user interaction seems like a source many potential bugs that it isn't even funny.

 

Hmm. Yeah, possibly, I don't know. I think that this is maybe one of the reasons why people complain about React a lot is because you can do some things wrong. Like there's the idiomatic React and people are like firing fetch requests and they're the render body of their function or whatever. But in any case, React is definitely innovating and so I think it's here to stay. But still, as I mentioned earlier, the ability to decide which UI library that you want to use is very interesting. And in the future, Remix will probably support a lot of these others that have taken different stances on how they optimize their rendering. But I would say all of that is exciting to talk about. Like, oh, hydration or selective hydration or resumability or whatever. For most of the time, I think, you're not saving as much as you could if you just first started with the architecture of a PESPA because that will improve the performance of your application a lot more than how many milliseconds you're saving on the type of hydration you're using.

 

Out of curiosity, how big is that remix core, whatever, that gives you that PISPA functionality that you need to get started?

 

Yeah, yeah, so I probably should break this down because you're gonna have the initial bit of React and React Dom, which I can't recall how big that is.

 

Ah,

 

I think

 

whatever.

 

altogether the hello world is of remixes, something like 50 kilobytes or something.

 

Okay.

 

And for like, if you've got a single page, so another thing to keep in mind is if you have a login screen or a marketing page super important that it's very fast and all of that. You can just not render your script tags and you don't get any JavaScript on those pages. So like if that's what you're going for, you can't get much faster than just not rendering the JavaScript, like okay. But even then, while the user is looking at the site and stuff, like sure, go ahead and download the JavaScript and progressively enhance the experience. That's the cool thing there is that the behavior is gonna be the same either way, it would be the same. The behavior will be different because full page refreshes and all that. But even if you wanted to, let's say that, oh, I really need to have this as fast as possible. I don't wanna hydrate. I don't wanna download it. JavaScript that's not needed or something. But I just need this one tiny little thing. You could shove JavaScript, a script tag, in your HTML. That still works. And so if you just needed this tiny little interactivity, you can go all Pempa on it

 

The thing

 

little

 

that

 

JavaScript

 

is clicking

 

in there if you

 

for

 

need.

 

me because of your explanation, which is associated with comments I've seen around remix for a while and I didn't totally get, is the fact that a lot of people, you know, they like remix because it kind of takes them back to the fundamentals of the web. The fact that you're working with forms as if they're forms. You're working with links as if they're just links. guess of this thin layer that Remix installs, which provides multi-page application-like behavior for a single page application type framework or library.

 

Yeah, I'd say it's multi-page app mental model with single page app capabilities.

 

So you're back to working with links, with forms, with stuff like that. You don't need

 

Yep.

 

to think about really more complicated mental model like Redux this or Mobix that.

 

Precisely, exactly. There is no state management, application state management to speak of when you're using Remix. You just don't need it. And that's like 30 to 50% of the code that the spot developers are working with every day is state management related. You just pretend that doesn't exist and that's what you get with Remix. And on top of that, Remix, so you get a better developer experience, And this is unique. Every other transition was improving one or the other. Going from MPA to PMPA, Progressively Enhanced Multi-Page App, that was 100% about the user experience. And then going from a PMPA, a PEMPA to an SPA, that was 100% about the developer experience. We weren't trying to improve the user experience there. We were just sick of template duplication. And now going from an SPA to a PESPA, that's giving us both a user experience and a developer experience improvement. And on like another thing, you mentioned you're just working with regular forms. This is even better than MPAs from the developer experience standpoint too. Like you get the simple mental model, but you also get the, with remix in particular, you get the form in the same file as the backend code that is going to be dealing with that form submission. And you get type safety across that network boundary as well, which is so, so nice. And so like it, you also get that on top of what the MPA offered as well. So yes, we are definitely spiraling upward, going back to the server, but also getting a lot of really, really nice things that you, I mean, in PHP, you could like do data loading in the template and stuff and stuff like that. But yeah, this is different in a very good way.

 

I think that the statement you just made about type safety is especially important, in particular, in the context of so many people, so many organizations moving over to TypeScript. I mean, like it or hate it. Or even AJ statically typed JavaScript with the JS doc. It doesn't really matter, because at the end of the day, it's syntactic sugar.

 

Mm-hmm.

 

The fact that you can guarantee that a particular field has a particular type and that type is preserved across the network is really powerful indeed.

 

Yeah, in fact, this is one of the things that GraphQL got really popular for. The other thing was data over-fetching and under-fetching problem. There's that tight coupling, so let's just say, let's have a marriage ceremony and now we have GraphQL.

 

By the way, I hope I

 

And remix.

 

don't upset anyone, but we kind of mentioned it in the context of gemstack, but it seems to me like GraphQL is kind of going away as well, at least from what I'm seeing. Is that your experience as well?

 

I'm actually observing that also. And there are probably various reasons for that. There's TRCP or TRPC. I can't remember which, yeah, TRPC.

 

Yeah, but I'm not sure that you even need that. I mean, if you're using

 

Yeah.

 

isomorphic code, which means that effectively you're compiling your front-end code and your back-end code together, which ensures type safety across both of them.

 

Mm-hmm.

 

And you might

 

Yeah.

 

just be using Ajax, and you're fine.

 

Yeah, so I think there are a couple of things. TRPC is one of them that I think some people are just like, oh, let's just go back to that. And it's really nice to get type safety. It's just this handy little library. I posted a link in the chat. If you go to trpc.io. I don't want to divert our attention over there. Remix also offers the same sort of type safety across the wire. And also because your loader and action, that code for loading data and mutating data only runs on the server, you don't have the data overfetching problem anymore there either because it's all happening on the server anyway. And you can filter down to specifically what your UI needs and just send that back from your loader. So you don't run into that problem either. But there is like, there are some other things that we use or that GraphQL can be really useful for even still. And at PayPal, we were working on this with so much data. And so identifying which service has the data you're looking for was really, really hard. And so GraphQL being a unifying API for that, they were still working

 

you

 

on it when I left, so I never actually used it, but I helped in conversations about it, and I'm pretty sure they

 

I totally

 

went with

 

agree.

 

it, and it

 

When you're

 

probably helped a lot.

 

bringing in data from a bunch of back end services, especially from different vendors,

 

Yes.

 

then using something like a GraphQL, which can normalize the data and you can slice and dice it before downloading everything, that's useful. But when you're

 

Yeah.

 

primarily using your own data from a sane amount of microservices, then the cost and complexities, from my experience, is often not worth it, and you run into all sorts of issues where you can't cache stuff, and

 

Mm-hmm.

 

it becomes an issue, and you need something like an Apollo server or whatever, and it becomes a real

 

Yeah,

 

hassle.

 

I completely agree. I never personally used GraphQL on anything of any great significance. And part of it was because of that. I would have used it at PayPal for sure because of that reason I talked about. But yeah, and actually no, I did use GraphQL on PayPal.me, that rewrite we did, that uses GraphQL. But lots of the problems that GraphQL solves problems you have when you're using remix or a PESPA architecture where you've pushed everything over the server anyway. And so you can absolutely use GraphQL if you want to in your loaders and actions, but there's not really much of a reason to introduce a bunch of complexity that GraphQL typically does introduce. So I have also observed, maybe it's just because of my own circles that I'm in, for GraphQL and that's to be expected with the hype cycle. So we would expect people to find where it's useful and use it there.

 

Hey guys, quick edit, jump in real quick. How much longer are we planning on going on? I know I gotta get back to work here pretty soon.

 

Yeah,

 

It's my paid gig.

 

as far as stuff I wanted to share, I talked about Epic Web, talked about remakes and Pespas and all of that. I'm pretty satisfied. Dan, was there anything else that you wanted to talk about?

 

Well, they're not really, you know, we kind of touched on them, like the React server components and how they might fit in, but it's not really that important. I think we can start to wrap up fairly soon.

 

Cool.

 

All right, well with that, we will start to wrap up. We've gone way long today, but only because there was so much good stuff to talk about.

 

I think we will need to have a glossary of your terminology. I still can't remember all your acronyms.

 

Ha!

 

We will need to put them in the show notes. Yeah, it's a problem. I'm barely hanging on with MPAs and SPAs. Ha.

 

Yeah, you know

 

and pampas and pespas and...

 

Yeah, you know, so the challenge, a lot of people actually criticize me for naming things. I've been known to name things. And as a professional hype cyclist, just kidding, but I found that it's just a lot easier for people to talk about something and for something to become popular when it has a name. And like, whether or not we have an acronym, it's just like, do you wanna say progressively enhanced single page app or do you wanna say PESPA? I think after a while we get used to the acronyms. So yeah. Yeah. Yeah AJ. Yeah, okay.

 

Well, Kent, you touched on one of the two hardest things in computer science, right? One of them is naming things.

 

Cache invalidation.

 

The other is cache and validation and also off by one errors.

 

Yeah, all two of those.

 

Yeah, yeah, that's the ultimate good one. But yeah, but on a serious note, I mean the whole concept of, what's the name? the Gang of Four who wrote the design patterns. The whole concept of design patterns is about the fact that by naming things, we create a common vocabulary that enables us to more effectively and efficiently exchange ideas and teach. And

 

Mm-hmm.

 

it's much easier to say, I'm using such and such pattern rather than starting to explain the details of the architecture. And likewise, in that

 

Exactly.

 

context, what here with the progressive enhancement and whatever the acronym is, is a design pattern, is a design pattern for web applications.

 

Yes, exactly. So,

 

Alrighty,

 

but yeah,

 

well,

 

a

 

without.

 

glossary would probably be helpful.

 

Hahaha

 

Ha ha ha.

 

Glossary, yes. Yes, if you could write one up for us, Kent, and submit it, we'll include it in the show notes.

 

Sure.

 

Homework.

 

Thanks for watching! All righty, well thanks for coming on Kent and enlightening us with everything you're working on. We will have links for as much as we can in the show notes and also Kent's promised glossary. With that, we'll move on to picks. Picks are things that we'd like to talk about that may or may not be tech related, could be food, books, you name it. AJ always has some interesting picks, so we'll start with him.

 

How is that going? Is your project actually running? I know that you're effectively building a four-wheeler. You know that if I take that to the logical conclusion, you might as well just buy a new four-wheeler. So let me get this right, you bought one four wheeler, you kept taking parts off of that four wheeler, putting in new parts and using the old parts to build another four wheeler and now you have two four wheelers and you're not sure which one is the original one. because it's a philosophical question now. Yeah.

 

Thank you for mentioning AHA. I got that acronym from Cher, she is, and I mentioned it in the article. But yeah, the original acronym wasn't an acronym, it was just like the name. I called it Moist, and yeah, definitely, yep. So I asked on Twitter, like, who can come up with a better acronym? And Cher was like, avoid hasty abstractions, sounds good.

 

Oh, I thought you were being Cher like the musician, like Sonny and Cher.

 

Yeah, that was good. Thank you.

 

All right, Dan, what do you got for us?

 

Unfortunately, this time around I don't have that much, so I'll pick two, I have two picks that I already picked before, maybe I'll expand on one of them a little bit. The first one I think I already mentioned that I'm going to be speaking at this conference in Australia in December, it's Web Directions Summit 2022, it's on the first and second of December. it. So many great people, Tejas who we've had on the show and Vitaly also known as Smashing, Mr Smashing and Thomas Steiner who we also had on the show and Henry Elvetica. So many great people will be there and also me. And the great thing about it is that since we're something our flight. We're going to take this opportunity to actually tour Australia for something like three weeks and I have to say that just preparing for it is Australia just looks to be awesome. I can't you know this it looks hopefully this is going to be one of our best trips ever. It's also going to be the first time in a like in a really long time that my wife and I have gone enough to stay at home now. And so that's going to be my first pick. And if you can attend this conference, it looks like it's going to be great, so I highly recommend it. Web Directions Summit 2022 is going to be my first pick. My second pick is going to be that pick that I pick each and every time, which is the ongoing war in Ukraine. What's recording this, the Ukrainians apparently blew up the bridge that the Russians built to Crimea and in retaliation or in response the Russians are firing just missiles and drones intentionally at civilian targets all over Ukraine, you know killing people, blowing up power really awful and what can I say anything that you can do to help the Ukrainian people please do and that would be my second pick for today

 

Alrighty, I will go and save the guests for last, although I prefer to think of me as the best for last, but I won't split hairs there. A couple picks, one, you know, along the lines of the humor is an article that I saw on Wired Magazine via Hacker News. Neurosys, neuroscientists unravel the mystery of why you can't tickle yourself. And it's quite an interesting article that were done and I forget where it's at but really sort of one of those funny things about why you can't tickle yourself but other people can tickle you. They measure brain activity before and during and after and so on. So quite fascinating. And then we get to the dad jokes of the week. I share dad jokes that meet my very high standard of publishing. So these meet my high standards. So first of all, I was pretty lonely. I was dealing with loneliness at one point in my life. And then I glued a cup of coffee on top of my car. And then everybody started waving at me. couldn't figure out why, figured maybe they just liked the coffee. You know, I have a I got a smoker a little while ago, it's a Green Mountain Grill, not the trigger that most people associate with smokers. And ribs is one of the favorite things I like to cook Costco, some really good ones that are already pre seasoned. But when I eat them, I only eat the second, third, fifth, seventh, and 11 ones because I'd like prime ribs.

 

That's it.

 

And then finally, did you know that if you eat an entire cake without cutting it, you technically only had one piece.

 

Or you could just bake a really big cake. And then the pieces

 

That's true.

 

will be big as well.

 

Yeah.

 

I think you're missing the point there, but anyway,

 

Hahaha!

 

okay.

 

I'm out.

 

Those are my jokes of the week. Kent, to you for the

 

All

 

final

 

right,

 

picks.

 

I do have picks. So my first pick is Epic Web. If you haven't already gone over to see what that's all about, I encourage you to do so, epicweb.dev. And then, and actually maybe I'll put a link in here for my introduction blog post that explains a little bit more what it is and has a frequently asked questions and stuff in there too. I also created the Call Kent podcast. This is where you can go to my website and ask me a question right in the browser. record your question and then I listen to your question, I respond to it, and then my server just sticks them together with the magic of FFmpeg with some bumpers and stuff and puts it up on a podcast. So I've got over 100 episodes on that. And yeah, it's pretty much a week daily thing for me. So check out the Call Kent podcast.

 

That's

 

And

 

really

 

then

 

cool.

 

I also, it is cool. Yeah, it's actually pretty fun. It's a good way to be able to answer the questions that people are asking I'm doing it because it's pretty quick for me. So yeah, it's great. And then. Oh yeah, it's all open source. So if you wanna build your own business out of it, go for it. My GitHub, you just go to github.com slash kentzydodd slash kentzydodds.com and it's all up there. It's all remix. So yeah. And I guess I should mention if you go there and you're like, wow, this website is way over engineered, you're wrong, it's over scoped. That's the difference. Developer blogs don't have a podcast software feature involved, which eventually I could turn into a product. I've got like four products in my website. So yeah, I also made a map on Google Maps that has every conference I've traveled to as well as those that I'm going to. So I've got seven conferences scheduled in the future that are in person and two more that are remote, but those don't go on the map. in person, check out that. And yeah, it's actually kind of fun. And then the last thing is another podcast, it's not mine. It is called Build Your House Yourself University. And it's, oh, I should actually look at who produced this. Her name is, shoot, I don't know what her name is, but she's really good, really, really good. And so if you are looking into building a house or you're just interested in what it takes to build a house and like, and there it is, then it's a very well produced podcast. She's not even like a professional house builder. She's just building a house herself and sharing what she's learning and she's research is really well. And I'm just impressed by the quality of the podcast itself. So those are my picks.

 

All right. So with that, we will wrap up this marathon of a podcast. Thank you to Kent for coming on and telling us what you've been working on lately and and going down rabbit holes, as we always like to do on the podcast. Thanks, Dan and AJ. And if, before I forget, other than Epic Webber, there are other ways that people can get a hold of you or give you money or yell at you.

 

Yeah,

 

What's the best way to do that?

 

so best way to keep up with what I'm doing is Twitter. I'm at Kenzie Dodds. I also have a newsletter, so that's even better. So you don't miss anything that's most important. So you just go to kenziedodds.com, scroll down to the bottom, give me your email. And then there's the Discord server as well. It's a good place to keep up with what I'm doing. So yeah. And then

 

All right,

 

there's,

 

excellent.

 

if you want to learn testing, testingjavascript.com is good. If you want to learn React, epicreact.dev is a good spot for that too, as far as giving me money.

 

Always good. All right. Well, thank you for that. We will wrap it up and talk to everybody next time on JavaScript Javascript.

 

Thanks everyone, see ya.

 

Bye!