Ryan Florence Talks About Bringing Web 1.0 Philosophies Back With Remix

Ryan’s background as a musician taught him many lessons that would eventually apply to his current career. As a musician, he learned about composition, sales, and even programming so he could build his band a website.

Ryan also had an actual sales job where he learned that you can do something so well that you’ll be unable to do it anymore. In sales that meant being good at generating leads which lead to a lot of clients which lead to ceasing to generate leads. But, that eventually lead to you have no clients because you let your stream of leads dry up.

It’s easy to become so narrowly focused on what’s in front of you that you get blindsided by what’s coming down the pipeline 6 months from now.

React changed the front-end landscape. We went from having a mutation-based approach to a functional approach. But, React has made it so easy to write code that we are forgetting our fundamentals. React websites are becoming bloated.

Remix’s goal is to bring back the Web 1.0 ways of doing things that lead to lean, performant websites. It’s Web 1.0 that is progressively enhanced with React and React Router.

“The technology that sticks, and wins, is the technology that can sneak its way into your existing stack because no one wants to rewrite!” Remix is built on this philosophy, allowing you to incrementally incorporate Remix into your existing application.

—-

Resources

• Michael Jackson’s YouTube video on component composition
• Remix

Ryan Florence

• Twitter
• Website

Joel Hooks

• Twitter
• Website

Transcript

Joel Hooks:
Hey Ryan.

Ryan Florence:
Hey Joel.

Joel Hooks:
I want to start out with the important questions. We've got a lot to talk about here, and nerd down on things that are interesting to both of us in tech. But first, I'm really curious, what is Mooky Proofed?

Ryan Florence:
Mooky Proofed is my band from I guess high school and the first part of college. It was a little punk rock band.

Joel Hooks:
What?

Ryan Florence:
Oh, what does Mooky Proofed mean?

Joel Hooks:
Yeah. What is... It's your band, I think that's good to know too, but where does that name come from? I've never heard that phrase before, so I'm curious.

Ryan Florence:
Well, I was reading an article by Korn, when I was a teenager, a long time ago, and they said that Korn, the band name is not cool as just a name. It's the band that makes it cool. I wasn't really somebody who listened to Korn, but they always say that, you pick the name that you hate the least. You're never going to your band name, so just pick the one you hate the least. So, we were all sitting around trying to decide on a band name, and I don't know why it was sitting around in our drummer's basement, where we practiced, they had a David Letterman, I don't know if it was in a magazine, I don't even know anymore, but you had a top 10 list that David Letterman would always do.

Ryan Florence:
There were just some ridiculous ones on there of word combinations that were the top 10 worst word combinations, and one of them was Pants Happy. I can't remember the other ones, but Mooky Proofed was one of them, and we all thought that it was funny. Because one of the girls that one of us in the band liked, we joked that her name was Mooky, as a code word. So, when we saw Mooky proofed, she had recently basically dumped me, and so I was Mooky Proofed at that point, because she had-

Joel Hooks:
Nice.

Ryan Florence:
Anyway, it was just a combination of some things that we thought was hilarious, and that was the name of our band.

Joel Hooks:
Do you think there's some similarity, because you've named a lot of things at this point, just as a developer, right? I'd say that's one of the hardest things. Is there any similarity there in naming things as a developer and naming your band?

Ryan Florence:
Yeah, pick the variable name you hate the least.

Joel Hooks:
Yeah, right? The least worst.

Ryan Florence:
And you're never going to it. In six months, it's not going to make sense anymore, so don't worry about it.

Joel Hooks:
Is there any other crossover? You've played in a band and music as part of your life, and I know you still play music, and I don't know if you're in a band or not, but is there anything... Was there anything crossover or anything you learned from that experience playing in a band, that you've carried over as a developer?

Ryan Florence:
Yes. First of all, that's the reason I even got into web development is, I was making my band's website and all the websites for all the bands that we played shows with back in the mid '90s. I think that's the only reason people played shows with me, is because they knew that I'd build them a website.

Joel Hooks:
Nice, [crosstalk 00:02:53].

Ryan Florence:
This was before JavaScript, before CSS, font tags, center tags, it was amazing. So similarities, I've always joked around that my favorite developers to work with are musicians. I think there's composition that happens in both music and development, and I think it's the same part of your brain. When you're writing a song, when you're putting a song together, you've got all these little pieces. If you do them in the wrong order, it's not going to flow, it's not going to sound good. The verse, the chorus, the bridge, the solos, all that stuff, how much reverb... You put reverb on things to make it feel like it goes in the background. There's just so much about composing music, putting all these pieces together, to try to have one overall idea or story or emotion that a song is trying to get.

Ryan Florence:
Software for me feels... I don't get super into the details of how to bubble sort. I still barely even know what that means, or how to reverse a linked list. I would never pass a Google interview, which is why I'm probably self-employed. But, I always like to stay at a higher level of, what's the goal here? What are the main pieces? What are the big components of this thing, the big parts? Then, how do they talk to each other? How do you arrange them together? That always feels the same as writing a song.

Joel Hooks:
I always call it glue coding, because I'm the same. I would just fall flat on any sort... I'm frankly not that interested in that sort of low... I don't want to code a database. I just want to use it to get stuff done. Personally, that's what I enjoy. Thankfully, other people are out there that have that low level thinking, and can do a really super, optimized bubble sort. Thank you so much for that-

Ryan Florence:
Yeah, that's why I think React can be fast, or Svelte can be fast or that our databases are fast. You need that stuff, but it's just not where I live.

Joel Hooks:
Yeah. You need both too, right? You have to have people that are thinking those deep, deep thoughts, and then people that are gluing those thoughts together and making something that other people can understand and use.

Ryan Florence:
Yep.

Joel Hooks:
From what I understand, you also spent a little bit of time in the sales world as one of your early career paths.

Ryan Florence:
Yeah. I guess that's relevant too, when you asked about my band. I had to sell my band, I had to market my band, and we actually did a good job. We were one of the few local bands that even made money. With the way my development career has gone, sales has been a pretty big deal. I actually was in normal sales before software development.

Joel Hooks:
I got a quote, and I just wanted to see this phrase, and it really stuck with me because I thought it was really interesting. I've seen a bit of the explanation, but I wanted to see what your take was. Somebody told you, and I think it was in your time as a sales person where, "It worked so well, I quit doing it." I was wondering what that means. "It worked so well that I just quit doing it," what does that mean? How has that carried over for you?

Ryan Florence:
So, you're selling life insurance.

Joel Hooks:
Sounds fun.

Ryan Florence:
So, you want to find someone to sell to. Well, people who are married and don't have kids yet generally don't have life insurance, because they don't really have a whole lot of dependents or anything that. So, one of the techniques that I learned from my boss when I was selling that stuff was, go through the paper, that's how old I am, and you could see people who had recently had babies. People used to put that in the newspaper. Maybe they still do. So, we had these stupid little baby spoons that we would send to them and be like, "Hey, congratulations on the baby. I'm just some random guy who sells life insurance, but if you died, maybe you want your spouse to have a couple of hundred thousand dollars to take care of this kid and deal with that for a while. Maybe they don't want to work for the next five years and just deal with the grief and raise the kid a bit."

Ryan Florence:
It worked so well that I was getting a bunch of clients and stuff. Then, you get busy with those clients, and you quit thinking like, "Well, how do I... I have all these clients, so I don't actually need to be doing these baby spoon things anymore." So, because the baby spoons marketing works so well, you quit sending baby spoons because you're so busy with actually selling to people. But then what happens is, you quit having people to sell insurance to, because you quit doing the thing that worked so well.

Joel Hooks:
Yeah, the stream runs dry.

Ryan Florence:
Exactly. So the idea is, it's a habit, it's a thing you do, that is the reason that you're successful, but you then take it for granted and not realize that that's what you need to do. So, like with React training, our public workshops have always turned into private workshops. If we ever stop doing public workshops, our leads for private workshops would just go into the toilet. But, when we'd go on a tour, we'd get a whole bunch of leads, and we do a whole bunch of private workshops for the next two or three months, and we would quit doing public workshops, and then no more revenue at all on either side, because we weren't doing the public workshops anymore, because we were so busy with the private ones.

Joel Hooks:
Yeah, you have to balance it out.

Ryan Florence:
Yeah.

Joel Hooks:
I'm wondering, is there any habits or practices from day-to-day development? It makes sense totally from the business perspective to me anyway, I feel that for sure, but I'm wondering, just patterns and practices as developers that we rely on early, and then it just works, and so we forget about it, and then we end up in the weeds somehow.

Ryan Florence:
Probably. I'm having a hard time thinking anything. Well, we already joked about naming variables, right?

Joel Hooks:
Yeah.

Ryan Florence:
I don't know if it applies as well for me there. But, you might get upset with TypeScript. You start using TypeScript for a while or linting, you put in a linter, and it's easy to start complaining about that thing, like, "Oh my gosh. I spent 90% of my time just getting these type generics or generic types right." You start to feel like that's the thing in your way. Where, you actually get rid of all those types, you remember, "Oh yeah, I used to spend all of my time with runtime errors and having no clue what I need to update when I change an API."

Joel Hooks:
One of the things I was thinking about when I was conjuring up the question was this idea, we have frameworks and we have all this cool stuff, and we've layered it on top of these core primitives.

Ryan Florence:
Oh, that's good.

Joel Hooks:
I feel like we get so far away a lot of times from the fundamentals of what drive the web. People say use the platform, and I love frameworks, I love them, love them, love them, love them in the sense that we're talking about, but I also feel like I forget that that sometimes maybe I could just use straight up HTML and CSS and accomplish the job. That's just one area that felt like kind of that same thing to me.

Ryan Florence:
Or vice versa. It could go the opposite way too, where you're you start to think, "All of these big bloated frameworks are dumb and we shouldn't use them," and saying like, "I'm just going to use HTML, and I'm just going to go to my database and kick out this stuff." Now guess what? You've got a bunch of cross site scripting attack vectors in your code, because you didn't realize that React automatically escapes that stuff for you.

Joel Hooks:
Yeah. I think you can get that tunnel vision, and that's the problem, right? You get so narrowly focused on your current preferences or the current urgent needs and then forget like, either way, what's coming next and what do I do in six months? What's coming down the pipe?

Ryan Florence:
Yep.

Joel Hooks:
That's good advice. So, what's the best text editor and why is it them?

Ryan Florence:
Exactly.

Joel Hooks:
I'm just kidding. I know that's your opinion. We don't even need to talk about that.

Ryan Florence:
I'm using VS code these days. I'm a VS code guy.

Joel Hooks:
Why would you convert though? As a long time... What was the tipping point where you were like, "Okay, I'll just do it. That's fine."

Ryan Florence:
To switch to VS code or to learn VS code?

Joel Hooks:
Yeah, yeah, to switch to VS code.

Ryan Florence:
Years ago, when Michael and I first started React training, he was teasing me about using Vim. He was like, "Why? Why do you use it?" I was like, "Oh, I'll just say this, I haven't thought about my editor in years."

Joel Hooks:
Yeah, that's nice.

Ryan Florence:
"I just never think about it anymore." He was like, "Oh." Because his impression was like, "Well, Vim means you're always goofing around with your editor," because that's how most people are in Vim. It's like, "I'm always tweaking it and doing all this stuff." But, that same thing happened and then he ended up... We both use Vim a lot. He's still in Vim, he hasn't made the switch over to VS code, and I hope he doesn't because, it gives me hope that I'll go back. He can just figure out all the configs.

Ryan Florence:
So what happened was same thing, I started using TypeScript and I was trying to configure VS code for TypeScript development, and getting all my hints and all that stuff. My fans were spinning like crazy, I don't know if I set it up wrong or what I did wrong, but it just wasn't working. So, I'm looking around at plugins, and it's just Vim is like an old developer thing. All the new tricks people... It's not as actively developed or that kind of stuff. So I was like, "I'll just quit going against the grain here, and I'll just grab VS code and see how it goes."

Joel Hooks:
So ultimately, you had to start thinking about your development platform again, your environment, and you're like, "Well, I could stop thinking about this and do the actual work that I want to do in a style." It's almost a style preference in some ways I think.

Ryan Florence:
Yeah. It's like, "Okay, screwing up Vim, I've got eight problems. In VS code, now I've got two that I didn't like before, and so I'm going to make that trade off." There's stuff I hate about VS code, absolutely despise, but it's not in my way as much as trying to configure Vim. But, I think Michael's got a really solid Vim set up now for TypeScript, and so now that he's done the work, I can just-

Joel Hooks:
Yeah, that's the way to do it. Just offload that problem onto somebody else, deal with the hassle for a little while and then come back once it's a solved problem. Which feels like a metaphor for TypeScript to me, in general, personally.

Ryan Florence:
Yeah. There's a job I want to do, and when my tools are in the way, I go try to find one that's not as in the way. I'm not an editor developer. That's not what I'm interested in.

Joel Hooks:
You don't have a personal identity wrapped up in your editing environment.

Ryan Florence:
Not even close.

Joel Hooks:
I feel the same. I was a big WebStorm IntelliJ fan forever, and then I was just like, "You know what? I'm just going to go." In matters of style, I swim with the current. That's just how it is in terms of my development life. Which speaking of, speaking of swimming with the current, maybe the tide, the tsunami, which is React, and it's dominance of the landscape in terms of web development and front end in particular, why is React so popular, and why does it keep its place? Is that just a tipping point? Is it hype? Is it people just herd mentality? What's going on with React?

Ryan Florence:
We saw a herd mentality before React, right?

Joel Hooks:
Yeah, for sure.

Ryan Florence:
It was Prototype over to jQuery, and then jQuery to Backbone. Then after Backbone, there was this big proliferation where, you got Ember and Angular, and there was all this competition between these big ones. Then React hit, and it just won the war. Now it's here, is it seven years?

Joel Hooks:
Yeah. 2013 was... It's almost eight years.

Ryan Florence:
Oh my gosh. Yeah. Why so popular? I think it just changed the whole idea of front end development. This is what we've been saying for years about it, is it changed it from this idea of mutation of like, "I've got this DOM and I'm going to go manipulate it when the user clicks a button," to a more functional approach where you just think, "Okay, what data do I have? Then, what should I render based on that data?" That's the same model that we had before JavaScript got really popular too. If you made a PHP website or a Rails website, before you did a bunch of front-end stuff, it was just, "Go to your database, get a bunch of information, kick out some HTML." That was it. Then someone posts a form, then the form goes through another route on your page, and the browser's got its own little spinning indicator thing. You make a mutation in your database, you redirect to a new page, go to your database and ask it, "Hey, what information should I render here?" Then you render again.

Ryan Florence:
So. it brought that web 1.0 model of, something happened, mutate data, and then render based on that data. Mutates the wrong word there. It just changed the data. You didn't have to mutate it in place. It just brought that web 1.0 model to JavaScript.

Ryan Florence:
Then, the second thing is composition. That, you can make functions on the backend in PHP or whatever, like here's the function to kick out a certain form. But now in React, you can use these components to wrap up both how this thing looks and how it behaves. So, that's really powerful. Now we have hooks, which is an even lower level bit of composition as well, so now not only can we compose these bits of UI with visual effects or visual, whatever, product, and then the behavior that it's got, but now we've got these hooks where we can even compose all those behaviors together as well. So, I think that's what it is, a functional data-driven approach, instead of thinking about time and mutating things over time and then composition.

Joel Hooks:
I feel like you're right. It does go back and is a throwback to the earlier web, but with a lot of that, to use a term from the past, rich internet application flavor that we saw with flash. At that time of the churn, the great churn, where Angular and React, and all this comes about, is right at the same time that flash was just absolutely scuttled. That's where I came from, I was a flash developer. So, there's just this complete empty spot where we no longer have this rich environment, and we need to do it in the web.

Ryan Florence:
Flash was that same model too. You got all your frames. You're like, "On this frame, what does it look like? Okay. On this frame, what does it look like?" Then, you could click a button and switch frames. So, React brought that same model.

Joel Hooks:
You mentioned composition, and component composition and something that I feel like it takes people a while to fully understand what it is, and how to use it, and why it's important. It feels like one of those things that's simple, but also incredibly complex, and the ceiling of understanding is quite high. How do you explain component composition in a nutshell, when you introduce it to people?

Ryan Florence:
I actually haven't taught one of our workshops in like a year.

Joel Hooks:
It's been a while, huh?

Ryan Florence:
Or longer.

Joel Hooks:
Getting rusty.

Ryan Florence:
Yeah, I am. If I remember, we just showed them a button, and then wrapped up a couple of prompts inside of it like, "This has a special button. You can add special styles to it and copy it anywhere you want." Then start talking about just wrapping up other behavior with a hook in there, or some state. I'm rusty on the teaching the React fundamentals.

Joel Hooks:
Just to throw a plug to your business partner, I think my favorite, my personal favorite current explanation online is one of Michael Jackson's, and I'll link to it in the notes, but he has a 15 minute video where he's like, "Hey, look y'all, we really need to talk about component composition," and then proceeds just to show some really good examples.

Ryan Florence:
With children, yeah. He had the little children-

Joel Hooks:
Yeah, yeah. He's bringing in children and Sean is like, "Look, here's what you need to do. It's 15 minutes long, it's no BS." It's just him, not edited, just thrown on YouTube. Honestly, it was like, "Well, wait. Okay." You get a nice click in your head. It was probably my favorite personal explanation of-

Ryan Florence:
Yeah, that's a good one.

Joel Hooks:
I know you you can read for days on this particular topic and work for years trying to get good at it, but that one was a click for me.

Ryan Florence:
Yeah. The big part of it is that nesting, in that you can say like, "Hey, here's what's inside of this thing. I don't care about what's inside of this component. I've got something else that's going to wrap it or whatever." When I think about component composition to now, I immediately go way deep on it with Reach UI type of stuff, rather than like, "Hey, let's talk about components composition as an intro thing." I'm like, "I forgot how to do that." I lived down in Reach UI for so long that now I'm like, "Oh well, you've got to worry about if they give you a ref, you've got to share that ref."

Joel Hooks:
Like the shareable library level of-

Ryan Florence:
Yeah, exactly.

Joel Hooks:
... What does that mean if I'm going to distribute it to thousands, tens of thousands of people to use.

Ryan Florence:
Yeah. I'm making a button, I'm making a menu button for a little menu dropdown, and it's really just a button. So, if you pass me in on click, I need to call that and check if event default prevented was called or prevent default was called, and I'm down in the deep weeds, which I always joke about teaching is, you can really only teach to people who are one level below where you're at. If people haven't thought about this shared library stuff like in Reach UI, I can't teach a beginner React to anymore, like a beginner React developer. I'm too far away from that, and I just-

Joel Hooks:
Well, you lose the beginner's mind.

Ryan Florence:
Yeah.

Joel Hooks:
It's very, very, very difficult to get back, if it's even possible to truly get it back. You can fake it, I feel like, and shift your mind a bit. But, if you observe people when they're first learning, you can get to that glimmer of the truly beginner mind. But once you move past, it's hard to ever-

Ryan Florence:
Yeah. That's why a lot of people are like, "Oh, how do I get in teaching? I shouldn't speak at this conference, because I'm not that good at stuff." It's like, "No, no, no, no, no. The thing that you just learned, the thing that you just barely learned how to do, you are the best teacher for that. Someone who learned that three years ago, they're not a good teacher for that because it's just obvious to them now." It feels obvious, yeah.

Joel Hooks:
We've struggled with that a lot just because we get people, "Oh, that's already been taught or somebody has already said that." To me it's like, "You've got to forget that Kent C. Dodds has literally written every article that could be written for React, and just write your own articles. Don't search and see if somebody else has already done this. Just speak your truth and your experience, and that story is interesting and something that is useful to people."

Ryan Florence:
Yeah, because everyone comes at things with a different amount of experience, and a different context, and a different thing that was confusing to them. That's why I loved when Michael and I were doing workshops together is, someone asked me a question and I'm just like, "I don't even know what you're asking me." Then Michael's like, "Oh," and then he gives an answer and I'm like, "What? I had no idea that was what the question was."

Joel Hooks:
Yeah. So, if we had had Michael here when I asked the other question, about how do you teach component composition, we could rift, right?

Ryan Florence:
Oh yeah, totally.

Joel Hooks:
[inaudible 00:22:27]. You mentioned Reach UI, and honestly I'll admit it, I'm a huge fan, a fan of your work and your contributions. Reach UI is one of my... I send people to it constantly, because I ask people, "Why did you subscribe to it again?" They're like, "I want to learn React." I'm like, "Look, if you really want to learn React, what you need to do is go look at Reach UI and open that source code and really dig into that, because I don't think-

Ryan Florence:
Study it.

Joel Hooks:
... "I can't think of a better example of React components." I would also say, if you're going to build those same components, just use Reach UI, because you've done this really fantastic, wonderful thing with this library. I'm wondering, what was the design philosophy and why did you attempt this project with Reach UI? Maybe, what is Reach UI, for folks that aren't familiar?

Ryan Florence:
Reach UI is an incomplete, we never got to finish it because of COVID, we had to lay everybody off, but Reach UI was our attempt at a shared composable React UI library. It's focuses on the ARIA best practices document, so menu buttons, list boxes, combo boxes, tabs, a progress bar, tool tips, dialogues, all those kinds of things. We wanted to build it in a way where typically, the way people build these things is, they wrap up their styles into it. It's like, "Oh, this is our component library. This is our design system." So, it's got all this styling stuff in it too, and it ends up being a whole lot more about style than behavior.

Ryan Florence:
Then the other problem is, and this is what I always called the curse of React, this was really my motivation for building Reach UI in the first place, was the curse of React, which is, man I've been in Remix land so long that I'm forgetting these other things. But the curse of React is that, React makes building a UI so simple that you end up doing it wrong, because you don't rely on a third party thing. Before React, when we just had jQuery, it was way too hard to do your self, and so you'd use a third party library.

Ryan Florence:
So what would happen is, the third-party library, they've already been through all of the screen reader issues and the head pointer issues and the keyboard issues and the mouse issues and the mobile issues, all those things. So, they have made this thing accessible. Most people didn't grab jQuery auto-complete for the accessibility. They grabbed it because it was just too hard to do on their own. So, React crossed this line for us, where now anyone can build an auto-complete, even a super beginner in React. It's an input, and on change, and a set state. That's it. As you're typing, change some state, and then you're going to filter a list and show it, and maybe you make a fetch to get that list. But, it's so easy that you never reach for a third-party library. So, now you're missing all of the accessibility from what we used to get.

Ryan Florence:
So, that's what I called the curse of React, is that made it so easy that you didn't use a better implementation of what you're doing. That was my biggest motivation was to say, "Hey, we need an accessible base." The second motivation was, as I guess it was fulfilling its purpose like you said, if you really want to learn React composition, go look at the Reach UI source code. I meant it as not just use Reach UI, but also learn from it. Maybe your component library is already too big and has too many other assumptions to use Reach UI, so please go and look at that source code and see what we did for accessibility and for composition, and copy that stuff over into your code. So, I mean it as a reference as well as a library.

Joel Hooks:
I think one of the things that was striking to me, while you were developing it, like the initial phases of the project, because you were in public, you were on Twitter and you were talking about it, and you were going through all the menu buttons you could find, and going through all the different browsers, and using all the different aspects of it, while having-

Ryan Florence:
And the native menu buttons.

Joel Hooks:
Yeah, every place you could find to figure out how they function, and what people expect out of them at the end of the day, and how that relates to the actual spec that's written in terms of how these things should function on the web, and then try to the best of your ability to codify that in a library. That doesn't have any concern with style, which is why these things, there's no real lock-in to it. It's just like, "Hey, do you want to skip a bunch of hard work and have this done for you in a very reasonable way? Here you go, just use it."

Ryan Florence:
Yeah. Another big goal was not just have a big proper API like, "Oh, there's behavior? Add a prop. You need this? Add a prop, add a prop, add a prop, add a prop." There was no, "Let's use components that look the way HTML works." When you build a table in HTML, there's not a rows option that you give an array and then let the table spit out a thing for you. It's got these building blocks, these primitives to actually put together a table however you need it. So, that was another big goal is to show like, "Look a lot of the nice React components out there just take 1,000 props. Split it up, give these things a better primitive, and then you don't have to worry about async behavior. It's the same as anything else."

Joel Hooks:
Yeah, it's really nice. I was wondering, so React router is the de facto, and that was yours and Michael's big splash into open source and the React community. I'm wondering just project-wise, has there been a big difference from your experience as a developer between Reach UI and React router?

Ryan Florence:
I think I'm more interested in Reach UI, so that was more fun. React router was more of a necessity. It was like, "Okay, I used to use Ember, they had this great router. Now I'm in React, how the heck do I put an app together?" We didn't really the stuff that's out there, so Michael and I were like, "Let's try to build a router." So, that one was less out of interest and more just out of need.

Joel Hooks:
Absolute necessity. Yeah, because it didn't exist and we had to have it.

Ryan Florence:
Yeah. I've never really liked how it's wrapped up in everything about your app. You switch pages, how do I load data? It's like people expected React router to do that for you. "Oh, I want to animate the transition between these. How come React router doesn't have a primitive for animating these things? I'm server rendering, how does that work? I'm code splitting, how does that work? I'm doing all of these things at once. How do I do all this stuff with React router?" It was like, "Oh my gosh, I don't... Now I'm using Redux, and so I actually don't want you to own the state. I want Redux to own the state." It was like anything we tried to do was screwing up something else. I just never liked how it just-

Joel Hooks:
I read the internet commentary from version three to version four. I personally just did the upgrade and thanked you, if not publicly, in my heart for your hard work. But, the fallout from like, "Hey, we're going to change this because we think it needs to be done in a better way," it's just-

Ryan Florence:
We just backed out. We're like, "We're just a bunch of components that match the URL. You figure out the rest."

Joel Hooks:
Which was a good move, I think. A good move for the project and for how we develop apps, right?

Ryan Florence:
Yeah.

Joel Hooks:
And probably your personal happiness too, on some levels. What's been the biggest challenge that maybe was a surprise to you when you got into open source development as your big thing. I guess it's your job in a lot of ways.

Ryan Florence:
Yeah, it really has been. The question is, what's the big surprise?

Joel Hooks:
Yeah. Was there a surprise challenge or what was the biggest challenge that took you by surprise?

Ryan Florence:
I think one of the biggest challenges is doing it or letting other people contribute.

Joel Hooks:
Yeah. That can be hard, right? Having other people contribute between you and Michael sitting down, or even just like yourself sitting down to do something.

Ryan Florence:
Yeah. Sometimes it's even like, me or Michael will think like, "Oh no, I'm the one that really wants to do this one, and I'm the one who needs to do it," as well. So, it's even hard between the two of us. But, if you've never been involved or started an open source project that literally has millions of users, I don't know if you can quite understand it, but you probably could.

Joel Hooks:
I don't, actually.

Ryan Florence:
There's this idea that, well, it's open source, and so if you don't have time to do it, just have someone else to do it. I get that kind of feedback on Twitter all the time, like, "Hey, why don't you just have someone else do this?" It's like, "That also takes my time," you know?

Joel Hooks:
Yeah.

Ryan Florence:
You're essentially saying, "Hey, instead of being," like if you think in your job terms, "Instead of being an individual contributor to this, why don't you become the project manager?" Which both of those are full-time jobs, so it's like, "I can either skip the project management and just write the code if I had the time, but not writing the code and then being the project manager, I still don't have the time to be the project manager." So, that's been hard. But fortunately, especially Tim Dorr, Tim Dorr has been amazing. We always get credit, Michael and I, for React router, but Tim is React router.

Joel Hooks:
So, he picked up the mantle and contributed. I would assume that that's the case for a lot of the original creators of a project. There's a lot of expectations, but it's growing a business, and in some ways, open source software is a business without the financial upside, the direct financial upside. I know that you've benefited personally from the notoriety and the experience involved with that, but nobody's paying you for React router Reach UI, right?

Ryan Florence:
Yeah. So, we've generally done the development of new versions and new features and stuff, but Tim has done the hard part of just managing the project, bringing in PRs, fixing bugs, writing release notes. He's just been absolutely incredible, and I've never given him enough credit for that. I don't think I ever could.

Joel Hooks:
The day-to-day too, that's huge. Probably, I don't know, it's probably the unsung hero of a lot of these kinds of projects, especially of that scale.

Ryan Florence:
Yeah.

Joel Hooks:
Where somebody just comes in and just does that work, and gets it done, gets it done well. Thanks, Tim. So, that brings me to the question, we always talk about getting paid and making a living. I know training is a good job, if you can find it and you can keep that rolling. I've made a living at that for years myself. But, you don't get paid for Reach UI, and you don't get compensated for your work on React router. So this last year, and probably before that, I don't know when you all first started talking about this, you and Michael set out and created something called Remix run. I'm wondering what does Remix, and why did you start this project?

Ryan Florence:
Remix is a web framework built on React router and React. Our tagline is, "Build better websites." I've been personally super disappointed with what all of us have been building with React. There's a lot of great sites out there, and particularly React router, we got out of the game of like, "Okay, how do you reload your data? How do you do this transition?" We're just like, "Look, we're going to match a URL, and then we're going to render a component based on it. Everything else is up to you." We've got these just like Webpack, and we've got these huge bloated websites.

Ryan Florence:
I'll tell a quick story. I was at a workshop, and one of the attendees came up to me after the workshop, because we always would hang out for an hour, sometimes longer, and let people just ask very specific questions about the code that they're working on. She opened up this code and it was so hard for me to follow. It was using Redux saga and Redux, and all this stuff. At the end of the day, the only thing that happened was, there were three requests, three fetches, and then just the page was rendered. That was it. There was no interaction, there was nothing interesting. The code was crazy, and it was like a 200 kilobyte bundle. It was nuts.

Ryan Florence:
I think React is really special, but we've jumped the shark, and no one knows, not no one, sorry. A lot of people and bootcamps are kicking out people, and this is none of their fault, bootcamp grads are some of my favorite developers ever, but they don't know that a form has an action attribute, and that when the user submits it, it will just make a normal request with the browser over to that page. They don't even know that. They think that you have to do an on submit handler in JavaScript for a form to work.

Ryan Florence:
So, that's one of the big motivations is like, React is awesome, but let's not forget how the web works. If you're on 404 page, that should not send a 200 status code, because the SEO is going to get screwed up. You should have meta-tags. There's just all these fundamental things. The development experience should be to me, like web 1.0. I've got a form, I've got a link, you click it, the browser goes there, and then we can add a bunch of cool stuff like they say, progressive enhancement. Remix is really just web 1.0, and then progressively enhance it with React and React router.

Joel Hooks:
I think it goes back in some ways to the phrase we were talking about earlier, it worked so well, I quit doing it.

Ryan Florence:
Yeah, yeah.

Joel Hooks:
That's why that stood out to me anyway, when I read it the first time. I was like, "Wow, it feels like Remix is a little bit of an embodiment of that philosophy." It worked so well that we stopped even teaching it to people that are new to the industry, is another aspect of that as well. I can see why that happens. A bootcamp< you're in there eight weeks, we've got to stuff-

Ryan Florence:
They should be pragmatic. They should be like, "What are people doing at these companies that are going to go work at," and that's-

Joel Hooks:
Yeah, how do you get a job tomorrow, is ultimately the goal. You don't get to spend time to deeply understand HTTP status codes at the level you need to, to be an expert. You're talking about a much longer program. It's just hard. Then, how do you get people into that? I think it's interesting from what you described, and this goes back to Reach as well is that, not only have you built an interesting project that you can build things with, but there's some educational value in there as well, where people are able to get in this and use the tool, use React and use the wonderful primitives that React has provided us, but then also learn more about how the web works, and more about how modern architecture and distribution, and HTTP caching and all that fun stuff works.

Ryan Florence:
Totally. There are times where we're like, "Okay, should we put a default in here or should we make them learn what a 303 is?" Like using Remix, it's going to be half a framework that helps you, but then also half docs that are just like, "Here's how the web works, so just [crosstalk 00:38:22]."

Joel Hooks:
I think you said that some people have commented that they spend more time on NBN than they do on the Remix docs, and that's significant as well, I think.

Ryan Florence:
Yeah, yeah. Really, a big part of it is the web fetch API. They basically, and this is the genius of Michael when we started developing this, he's like, "I think we should build it on this as our fundamental request response cycle." It's been awesome. But, we're even working on features for link pre-loading and we're just using link preload tags, but they're useless without a framework, because you need to know your bundles hashed asset names, and Remix knows that. We're working on a form component for mutation, so you write the code web 1.0 style, and we're going to use React router and Remix to make it fast, that you don't have to go back to the server for the whole document. Then, you can add on your errors and everything else.

Ryan Florence:
You can do everything you want to do in a really fancy form, but you never have to make a fetch yourself or keep track of your pending states or anything like that, or even serialize the form. We serialize the form for you, and give you a hook that's called use pending form. It's like, the user just submit a form, we serialize that based on the names and values of your inputs, and now you can use a hook to get that and throw a pending state up with the data that was in the form. But everything we do is, how does this work with a lowercase form, and how does it work with an uppercase form? Is it the native form or is it the Remix form? It needs to work no matter which one you use. Uppercase link or lowercase HREF, those links need to work the same, whether it's a full document request or it's a fetch. So, the whole thing is built on web 1.0 style of development, but then you can dress it up with all the cool stuff in React.

Joel Hooks:
One of my cheeky sayings is, a code normal, just code normal. Then, that could mean so many different things to different people. Usually, that means code and the style of the team and organization and project that you're currently on, that's what I mean by that. But, I think it's interesting if you can take that to the broader ecosystem and describe what that means. I don't know, based on the standards and just the way that the web works, and the idea of use the platform, which I think is a little bit of a tainted phrase in a lot of ways, but bringing that to the React world, so we are closer to the platform.

Ryan Florence:
Yeah. The problem with use the platform was, it just sounded like use web components and polymer, which none of us want. But yeah, I think we're going to appropriate use the platform for Remix one of these days.

Joel Hooks:
Yeah, I like it. Was there a type of application that you had in mind when you were thinking that this is the perfect use case for Remix?

Ryan Florence:
Really, I wanted it to work for any website. That's why it's built on the fundamentals of the web. You should be able to do that. I don't know that there's a perfect one. There's definitely the types that don't make... Well, we've got plans for offline mode and stuff like that to it. That's the thing is, since we're picking these really core, fundamental pieces of the web as our fundamental pieces, it's going to allow us to do anything. But, the way I think about Remix as far as market fit is, if someone wants to make a website and they're not a programmer, they're probably going to go grab WordPress or Squarespace or something like that, right?

Joel Hooks:
Yeah.

Ryan Florence:
Remix, I would love that to be the choice for everybody else. If you're a web developer at all and you need to make a website, Remix should be a good fit.

Joel Hooks:
Is it something where, I suppose... Because there's this all in sometimes, like when you pick a framework or a meta-framework, or however you want to say it, but you're like, "Now this is a Remix app." Is it something that I can adopt incrementally as a developer? Can I bring it in and add it in and start sprinkling it in and grow it like, I don't want to say virus, but grow it like a virus inside of an existing application? Or, do I need to have the foresight to say, "Okay, we're going to use Remix, and this is what it is for our project starting today."

Ryan Florence:
Yeah. One of the most appealing things to me about React was that, it could sneak into an existing stack. I had a boss once, who was the reason that I quit my job, but he had one jewel for me of wisdom. We were in the middle of trying to decide, we had started using Ember, and then React showed up, and we were goofing around with React, and it solved a lot of our problems, and I was talking to him about it. He said, "I've been in software a long time." He was a Novell guy, Microsoft, so he'd been in software for a long time, since I was a baby. He said, "The technology that sticks and wins, is the kind that can be incrementally adopted and fit into your existing stack, because nobody wants to rewrite."

Ryan Florence:
So, we've designed Remix that way too. We want, if you've got a website, you should be able to sneak Remix in for just two pages, one page. At the end of the day, all that Remix is, after you run Remix build, is there's two artifacts. There's a server build, which is used to just handle one HTP route, so it's just a request handler, that's it. So, if you're in an express app, it's app.git, and then put in whichever route you want Remix to handle. Then, there's the browser build, so you've just got to get that in your static assets somewhere, so that Remix can go.

Ryan Florence:
Then from there, you can just keep on adding pages over to Remix if you want. So, easy to incrementally adopt, easy to ditch when you want to quit paying us, because we didn't live up to your expectations, which we will.

Joel Hooks:
I have no doubt. Has there been pushback about the commercial aspect for what everybody feels they expect to be free?

Ryan Florence:
Yeah, yeah, it does seem like it should be free. I understand that. We'd love it to be free eventually, but we didn't get quite to reason like that. We really started Remix, aside from the technology reasons, but our business, our training business just got decimated by COVID. We ran live events. If you can't put 10 people in a room, we don't even have a business. So, we really wanted to build something that wasn't so directly related to our specific time, and something that was COVID proof, I guess. Now I lost my train of thought. What were you're asking me?

Joel Hooks:
Just, was there a lot of pushback or were people shocked in terms of just the notion, the audacity, the gall of Ryan and Michael to ask for money for a React Meta-framework?

Ryan Florence:
Yeah. That's the thing. It's like, "Hey, we want to write this code. We think it's going to be super valuable, and so we think we should be able to money for it." That's as simple as it needs to be. As far as have we gotten... So, that's the motivation, is, we can build a business that we don't need to be able to put 10 people in a room for. We've gotten some pushback, but I've got enough Twitter followers that if I say anything, somebody's going to not like it.

Joel Hooks:
Even if it's a 0.1%, it's going to be an annoying rattle off to the side, right?

Ryan Florence:
Yeah, it seems like a lot. Yeah. Then, it feels like a lot of people are feeling this way, but it's really like, "No, no, no, you've got a lot of followers, and so you're going to get that stuff." There is that, but I don't care. It's fine. If you go to GitHub, React router's GitHub page says that there're 1.6 million repos that depend on React router. That's our open source thing. That's the free thing. Then, if we can just sell a sliver of a percent of those 1.6 million people, we don't even need 1% of them. If we can just convince this tiny bit of React router users like, "Hey, we can help you build a better website with React router and Remix," then we've got a healthy business that we can run for the rest of our careers.

Joel Hooks:
I know you respect the hard work of others, and I'm not asking you to roast anybody's work in this case, but this year, we've talked about this before, and I'm excited and still excited about Remix and this project and what you all do. I love the ethos, and it feels like it's very in line with Reach UI, and just fundamentally ethically and technologically just a really exciting project. But pragmatically, I had to choose Next.js because it exists and it was just there when we started. We started in May and we could, but down the road, I'm of the mindset these days that, every few years, we're going to end up rewriting it, and if it's React, it doesn't really matter. Switching meta-frameworks should be relatively painless in theory. But right now, why would somebody choose Remix over Next? Which I think those are the two-

Ryan Florence:
Yeah, yeah.

Joel Hooks:
If I was lining things up, if I was to choose a meta-framework right now, I would have those two side by side. That would be my biggest considerations, I think.

Ryan Florence:
Yeah. Right now, today, November 15th, 16th, you should not pick Remix, you should pick Next, absolutely. We're not done. You go to our buy page, and it's very clear like, "Hey, this isn't even a beta. This is the supporter preview." So, there isn't a buy-

Joel Hooks:
You're chasing people off actively on the buy page.

Ryan Florence:
Yeah, yeah. We aren't ready for a flood of feedback either. We're trying to control that. So today, Next is the obvious choice. The only reason today to buy Remix is, you just want to see it exists. You want to support me and Michael financially, for us to be able to get this thing over the finish line. That's why we call it a supporter preview. That's what we call all the people who are using it right now, our supporters. We're so grateful for them, because without them, we wouldn't be able to do this. We've got a little bit of money in the bank, not nearly what we're used to, but we have enough to keep going. But when it's done, it'll never be done, done, but when we're at-

Joel Hooks:
When you stop actively chasing people away.

Ryan Florence:
Yeah, exactly. I think it'll be pretty clear what the differences are. There are little technical things that we do differently that I think are better, that I could talk about, like your whole build manifest in Next shows up in the console, which compressed is 30, 40 kilobytes, and I'm not okay with that. I don't think that adding more routes to your app should make any one page bigger than it needs to be. But, that's something that they're going to listen to this podcast and they're like, "Oh yeah, we should stop doing that, and then they make a ticket and then they'll do it." So, I shouldn't have even said it. I should have waited when we launched. So, we've got little technical things like that, that we do differently.

Ryan Florence:
But, you'll have a little bit more control over pre-loading. Next will automatically preload the JavaScript for any links that you have on the page. Once again, I don't like automatically putting that much weight in the footprint of any single page of my app. So, Remix it doesn't fetch that stuff until you actually click a link. Then, we've got APIs as well to let you control and be like, "Actually, you know what? That's an important link, so that's one that I do want you to preload. I want you to preload the JavaScript. Actually, you know what? I also want you to preload the CSS for it, and I also want you to preload the data." So, all three of those resources matter to render that page, and Remix gives you the control to pick all or one or two of those resources, with a really declarative API. So, you get to control the footprint of any one page. But again, that's stuff that next can-

Joel Hooks:
I honestly feel like control is a big theme there. This is, if I have a gripe, I personally avoided Next for a long time. I recognize that technological achievement that they've made, and it's a really good kit.

Ryan Florence:
It's great.

Joel Hooks:
But, I avoided it because they make so many decisions for you, and if you don't tow the company line, and I say tow because, it is a lead magnet for the platform, where you I assume, don't have a lot of intentions to run a platform, maybe. I don't know your ambitions, but-

Ryan Florence:
Yeah. That's a difference too. So, there's the technical things that right now, I think we have some optimizations that are better than theirs, but they've absolutely got optimizations probably that are better than ours right now too. So, that's not a super thing. I think the philosophical differences and the business differences are probably more relevant. In Next, you have a get server-side props, right?

Joel Hooks:
Mm-hmm (affirmative).

Ryan Florence:
You can actually post to our API that's like that. So, we've got this form component that when you use the form component, we're not going to call that code on the server to get data, we're going to send the data from your form. So this whole, once again, the web 1.0 idea is, this form component is a part of Remix and it knows about your server, then, your server data endpoints know about the form. So, if you want to do a mutation, you do it through a form like in web 1.0. So, I think it'll just get a lot more obvious when we get to our beta launch, and it'll be like, "Okay, they're just not the same framework."

Joel Hooks:
Just different. Fundamentally, philosophically there's a lot of differences in the way-

Ryan Florence:
Yeah, on how... Just imagine you're creating a new project or you're building a to-do list or whatever, you can look at the code of both and be like, "Oh, I get it." So, Next very much is like, "Hey, use these API routes and then try to statically compile everything else." Anything that's dynamic generally use for my API routes, everything else we want to statically compile. We say, "No, no, no, no, no, you don't need to statically compile all this. Let's do this the old school way."

Ryan Florence:
Then, you can see the code. We've got these hooks to say, "Here's the pending form, here's the pending location, and you can put the spinner up. Oh, your server came back with errors, don't validate it in the client, validate on your server. The errors came in..." So, just look at a workflow like that, of filling out a form, getting some errors back, and then rendering those errors. When you stick them side by side, you'll see that there's a philosophical difference between the two approaches, where ours relies on the server a whole lot more, and theirs is more about mixing static and dynamic with their API routes, which there's use cases for both.

Joel Hooks:
Sure.

Ryan Florence:
But, I think it'll get a little more obvious. Then the other thing is, business side, you're locked into Remix to some extent but not a deployment platform. Vercel is going to be... Here's the thing that everyone needs to know is, me and Guillermo have known each other for over a decade, and we are great friends. I've been talking to him about Remix on Vercel. If you want to ship a Remix app to Vercel when we're done, you won't have to do anything. You'll just type Vercel, and it will know this is a Remix app, and it will know exactly how to deploy it to Vercel. So, our incentives are aligned really well with what that team over there are building next. So, I'm glad that you were sensitive with this question, because we're not out to get anybody. I think Next-

Joel Hooks:
I've heard him, I heard Guillermo recently say that there's a reason that his company is not called Next Cloud.

Ryan Florence:
Yeah.

Joel Hooks:
There's a reason that they did not choose that, and it's financial for them, and they're venture backed, millions and millions of dollars, and you all are bootstrapped and pulling it up with your savings from your training business. So, there's a lot of differences in that. But, I appreciate the effort to try to do something as an independent, and build something where you're not trying to sell me a platform and a broader service, you're just trying to give me something that's very high quality, that is useful. I have so much respect for that, and just that mindset, and I'd love to see it.

Ryan Florence:
Yeah, thanks. We're excited about it. We think it'll work. They're really similar, but I think it will get more obvious.

Joel Hooks:
Yeah. I'm looking forward to it, and I'm looking forward to it evolving. Ryan, thanks so much for hanging out with me and chatting with me this afternoon. I'll let you get back to Remix.

Ryan Florence:
Cool. Thanks, Joel.

Joel Hooks:
[inaudible 00:55:12].