Live from Remix Conf!

Hey, everybody. Welcome!

Welcome to JS Party! This is a live recording.

And at a real party too, in person.

A legit party.

Yes. An after-party, in fact, for the Remix Conference.

Wooh!

Super-exciting.

Yeah, it’s really exciting. I’m here with Ali, I’m Divya, and we are also here with Kent C. Dodds!

Hello! Happy to be here.

Yeah. Kent organized Remix Conf, and also is part of the Remix community. Do you wanna talk more about Remix Conf?

[04:05] Yeah, I would love to talk more about Remix Conf. Thank you so much for coming and being here at the conference. Remix is a web framework; we talked at length about it a couple episodes ago, so you can go back, and we’ll link to that… But yeah, so it’s a web framework for building awesome websites, and when I joined the team back in November, I thought we just should do a conference. It was one of the first things that I did, was start that up. We’d just barely open sourced, but I knew that we had a good community going already with the closed source thing, and so I figured we could probably get 300 to 350 people in Salt Lake if I had the right team to organize the conference and put things together. So I got the right team, and we’ve got the same group, it’s Zero Slope Events, the same group that does React Rally; they’ve done a couple ReactConf, NGConf… Yeah, a bunch of tech conferences. They’re amazing. We’re in the same venues React Rally has been in the past, and we’ve got 330(ish) people at the conference.

That’s awesome. That’s actually a really impressive turnaround on a conference, too. I feel like these things take forever to plan, so six months or so is pretty impressive.

I feel actually pretty proud of that accomplishment.

Pat yourself on the back for that. That’s you. [laughs]

What made you guys wanna have a conference in the first place, considering it’s a project, and you’re building the community? What was the impetus for that?

Yeah, so actually, I was thinking about a Remix conference before I even joined Remix. I was like, “Boy, it sure would be cool to have a Remix conference.” I’d been using Remix before I joined for over a year, and I just loved it. I didn’t wanna talk about anything else… So when I joined the team - this was after they’d gotten funded, and we just said – one of our primary goals was adoption. And Remix is basically an evolution of React Router, so we already have really good adoption. Basically, 7 in 10 React apps are using React Router, so there’s a lot. But we want also to just highlight what the community is doing with the server aspect of what React Router is, which is now Remix.

So I think the idea was we wanted to get people together so that we could help them inspire each other to know what cool things that you can do with Remix. And then also, to share some of the things that we’ve been working on, and that was Michael Jackson’s keynote, which was just like “Here’s a bunch of things that we’re working on… And now I’m done, let’s hand it off to the community.” But yeah, this is definitely not like a money-maker for us or anything. We’re just trying to highlight the community.

That’s awesome. And I wanna shout you out for doing a lot of unique things for this conference too, of having us go out into the city and get lunch in groups today; I thought that was really unique, I’ve never seen that at a conference before… And then having this event tonight, and the Hack and Hang last night… So lots of really cool events. I also really liked the single track and the speakers room [unintelligible 00:07:04.15]

Oh, thank you. Yeah, we borrowed a lot of ideas, and some of these ideas were my own… I’ve been to a lot of conferences, and a lot of things that I like, and there’s things I don’t like about conferences… You’ll notice, we do have music, but you will still be able to hear other people talk when you’re at this after-party. At lots of conferences it’s just like blaring music and you have to yell at each other.

So eating out in the city - that one I borrowed from React Rally… And we also gave our speakers some spending money in the city… Because when you go to speak, you don’t wanna leave with less money than you came. That’s kind of annoying.

For sure.

That’s the whole idea, is like I can go for free. That also I borrowed from React Rally. But one thing that was an original idea that I’m really proud of is we also had back-up speakers. That’s not original, but we recorded the backup speakers’ talk last night, and they’ll be put onto the YouTube channel like usual.

That’s so cool.

I’ve been a back-up speaker before, and you’re in this weird place where you’re like “I hope that somebody gets sick, but I actually don’t…” [laughter]

No Covid. [laughter]

[08:09] Yeah, absolutely not. So yeah, that was one thing that I’m excited that it will be able to be heard. They’ve put a lot of work and effort into preparing those talks. I also put the Twitter avatars on the badgers.

That’s also smart. So people can recognize you.

Yeah, exactly.

Yeah… Unless your Twitter picture is like ten years before your current, which I think many of us are guilty of doing…

Yeah, for sure.

We’ve definitely changed in the last two years of not going to conferences…

Absolutely.

At least I have.

I was thinking the same. And plus if you love drawing too, like their profile pictures.

Yeah. So it was super-fun. And after the conference day, now I have a lot of ideas of cool things that we’ll do next year.

That’s awesome. And it keeps going tomorrow, too. Y’all are doing the hangout day.

Yeah, yeah. Originally, I wanted to take everybody to Lagoon, it’s this theme park and you go on rollercoasters and stuff… But they’re only open on weekends in May, so…

Oh, okay… [laughs]

I’m somehow unsurprised that you wanted to take people to an amusement park… [laughs] Not surprised at all…

That’s my jam, that’s what I do for fun. It’s logistically challenging to do stuff like that.

Sure, yeah.

But it was like “But I still want people to feel like they can go out and do something fun”, so I just came up with this idea to think of a ton of fun things that people could do and that they would do with each other if they just had the inspiration to do that… So we’ve got - I don’t know, probably a list of 20 things and places people can go… And we had one person run a marathon actually on Saturday, like a half-marathon…

Woow…!

And we have a bunch of people playing pickleball, and disc golf… And I actually went on a one-wheel ride with a bunch of folks today, which was sweet… And yeah, tomorrow people are gonna be going out and doing fun stuff.

So really, this is 100% – like I said, we’re not making any money off of this. In my mind, if we end up with more money at the end of all this, then that’s a failure in my mind, because we could use that money to do something cool for the conference. So it’s 100% a huge thank you to the sponsors, because this wouldn’t have been possible without them. We just wanna get the community together and have the conversations that you have at an in-person conference.

Cool.

That’s awesome. Should we talk to some of the speakers?

Yeah, let’s get some speakers up. I’m gonna leave now, thanks everybody… I’m gonna hand this over to some speakers, so thank you for having me.

Yeah, for sure.

For sure, for sure. Thanks for having us.

Hello, Henri.

We have lift-off! [laughter]

Welcome!

Bonsoir! I’ve gotta say good evening to both of you. I haven’t seen either of you in like - well, years.

Yeah, exactly.

It’s been years, yeah.

I think we’ve met for the first time in Amsterdam, before all of this craziness happened…

I feel it was JSConf EU.

Yeah, or the Mozilla Conference.

Berlin, yeah.

VSource

Oh, you are correct. I think it was VSource maybe. I thought it was JSConf EU.

Same thing. Same week.

Either way. I’m happy to see both of you guys. Ladies. Pardon me. So it’s been a hot minute… And actually, when I found out this was happening, I’m like “Oh my god, I totally remember this”, because I think I attended one, and I can’t remember where it was, but it was a lot of fun then, too.

Yeah, that’s awesome.

I think live podcasts are kind of cool.

Yeah, and a lot has changed for you. You’re at RealWebPageTest now, and doing stuff there…

Hey, merci… Yeah, you know, having fun, just –

Tell us more about that.

Yeah, introduce yourself, for everybody who’s listening. We know you, but…

Oh, okay. So hello, bonsoir, all the listeners out there. My name is Henri, and I’m mostly known as @HenriHelvetica on Twitter. That Netscape avatar that you thought you saw - you did see. And I’m here at Remix Conf in Salt Lake City… And I spoke earlier today and I talked about performance, but specifically with regards to a company I work for, which is WebPageTest by Catchpoint… And where we live and breathe performance, user experience, and in part, developer experience now as well. So yeah, it’s a pile of fun.

Yeah, it was cool to see you walk through that process of using RealWebPageTest, and the different parts of it that people might not be using… Because I think there are parts of WebPageTest that I’m like “Let me just run it through and see what the LCP is”, and that’s all I care about, and that’s it, and then I close it.

Yeah, and I totally understand that. That’s just natural. We’ve grown accustomed to with whatever product we use; it does something well that we like, and we just kind of dive in and use it for that and just get out. But considering sort of like the environment that has been created of late, where performance is really being discussed more prominently, I think there needs to be some discussion about the features that are available to them, that they might not know about, and specifically, what they do.

And the biggest picture - I’d say bigger, but I think the biggest picture overall is what I’ve talked about, which is performance literacy. I think that – I’m not saying it’s not there, but generally, I think it could improve… And that’s going to be sort of like my mandate this year, for sure, my campaign. It’s just to show people, having them understand what’s going on, why they need to particularly pay attention to one part, or understand what it means.

Definitely. I think especially in the frameworks space… The CSS, HTML, JavaScript developers have always really talked about performance a lot, and those conferences always bring it up in a lot of their talks… But today was really unique at React Remix Conference to be speaking about performance in almost all of the talks. I thought that was really cool and different compared to a lot of other conferences.

Yeah. It felt very Perf Now, you know?

Yeah. [laughs]

Yeah, exactly.

[15:37] You know, I have to say this… When I first found out that this conference was happening, it was immediately on my radar, because I felt Remix was buzzing. And I also felt that they had been so adamant in indicating to people, letting them know that they were pretty performant in using our tool, so I just could not miss that… But a) I was happy I came, and b) I remember maybe like three days out I was looking at the actual speaker line-up and their abstracts, and I couldn’t believe the amount of performance conversations that were taking place… And I come from a moment in time where it was myself and that was it. And to have ongoing talks about like a little performance here, and there, and your LCP is going improve…

Divya, you might remember in 2019, during my keynote, I said at Performance Now in Amsterdam “Lighthouse is largely responsible for what’s going on in terms of people chatting about it. And now you add Lighthouse, Core Web Vitals and there’s like a huge tent of people who are pretty interested… And that’s why I think - you know, when I joined WebPageTest, it was like the best time on Earth to be into performance right now. There are so many people who want more information.

Yeah. Lighthouse is such an entry point for so many people, but still so many people don’t even know about that… I talk about it in some of my talks about SEO, and writing blog posts that are good… Just like, “Hey, also send your blog through a Lighthouse test, because it will affect your Google ranking”, and people are like, “Oh, I’d never heard about this before.”

Yeah. You know, it’s interesting, because Lighthouse - if I remember correctly, Lighthouse really started as like a PWA tool, and then they added performance, SEO, best practices, accessibility, and the PWA is still there. And now it basically has been transformed, co-opted as a performance tool. No one cares about anything else. It’s like, “What’s your Lighthouse score?”

Lighthouse score, yeah. And post it on Twitter.

And they’re not like “Oh, here’s my SEO score.” Like, “SEO? What’s that? What’s your performance score, bro?” So it has become synonymous to performance, which is really interesting, because that’s where the people chose to take it. And now it’s like, “Okay–” So today was about like “Okay, let me show you the details about these scores and these times that you see”, and there’s a lot more to it.

So I had a great time today, to open the post-keynote talk… Which - again, I didn’t know till about 48 hours before…

Oh, wow.

So – well, is Kent still here? I was actually supposed to be a pre-recorded talk.

Oh, got it. Got it.

And then I got the call, they’re like “You’ve been super-sized.” [laughter]

You’ve been promoted.

Yeah, you’ve been promoted. And then I got the top slot, and I was like “Alright, let’s go have some fun.”

That’s awesome.

So how are things with you two? Everything’s love? Work good?

Yeah, for sure, for sure. Having lots of fun building stuff, talking to people… What else could you ask for, right?

I guess so.

Yeah. I mean, it’s interesting, because I’m interested in the work that you do, and Tim, and the team that you are working with is wonderful at RealWebPageTest. And it’s interesting at least looking at the trajectory that I’ve been moving towards… So I did a lot of frontend, and now I’m pretty much full-stack towards the end of the stack, not the front… And I’m actually curious if from your experience and working on RealWebPageTest what the trends look like, as people start talking more about server-side rendered apps… You see Next.js bringing up their things, and Remix is doing – I guess they call themselves center stack… I guess full stack… But I’m wondering if you see that in the trends, or at least in the data that you guys are collecting.

That’s a very interesting question, and you may get an even more interesting answer.

That’s what I’m looking for. [laughs]

The one thing that I realized is that having sort of run the JAMstack Toronto Meetup, and being exposed there, everything that’s going on with what you discussed is still such a small part of the web. It’s obviously very new, very well-discussed in our little bubble… But you break out of that and it’s like “This is not the main discussion.”

Yeah, people are still building websites, and…

WordPress, yeah.

Yeah, though this is not the main discussion, you know what I mean?

Yeah, true.

So I’ll be frank - I’m really spending a lot of time watching what’s happening on the WordPress site, because some of you may or may not know, last fall they officially announced a core performance team…

[20:25] Oh, that’s cool.

…so my ears were like “Okay…” So I’ve been following them closely. I think I told this to someone earlier today - Douglas Crockford once said, how’s the quote go again? Basically, the frontend is like a disaster. That’s where your problems will keep coming up, day in and day out. I’m not saying that with all that’s happening on the modern development side that we shouldn’t keep an eye on that, but just - it’s still such a small pie. There’s so many bigger problems to take on, and they’re more of in a classic frontend/backend split.

That’s fair. What are you most excited about working on at RealWebPageTest now? Is there a new feature that you’re working on, or what’s new, what’s upcoming?

I mean, can I ask my lawyer first?

[laughs] Read your NDA…

Yeah, did you sign an NDA?

Okay, apparently nothing’s happening…

Okay, yeah…

You know, I will say this… I get back to the literacy idea, because that means it’s like having workshops; that means it’s like presenting, that means it’s being able to have conversations with people about performance where they can speak from a more learned place. And so this education that needs to take place, and that’s going to take place this year, I think is a lot of fun. It’s almost like the early days, say, of JAMstack. You’re like, “Oh, this is kind of interesting”, and then watching it sort of like snowball into what it is now… And the whole idea - again, I know people argued about the name, and yadda-yadda-yadda… I started to call it just the modern stack. What is going on? It’s modern development. Let’s go.

I’m excited about that, I’m excited about helping people unlock, when they’re looking at data and metrics, to be like “Oh, I know what’s going on here.”

Yeah, I guess that makes sense, because as long as we’re building for the web, regardless of what framework, stack, technology, whatever, the browser is gonna render it and performance is gonna come into play either way.

And you’re just gonna wait for the results, and that’s it.

Yeah. That’s great. And the literacy will always – there’s always a need there.

Yeah. Like any web development, there’s literacy that needs to be achieved for people to be able to speak in that confidence, where it’s like “Oh, here’s what’s going on there etc.”

I have to give a shout-out to my team, everyone at WPT, as we call it - Tim, Scott, Jeff, JQ, Jeena, Mikayla, William…

All the other people. The entire Catchpoint team…

Yeah, and I mean –

[unintelligible 00:23:09.21]

Catchpoint and WebPageTest is like this, but we’re trying to do great work, and hopefully people could come along and be part of it.

Yeah.

That’s awesome.

Exciting.

Hopefully I’ll be on your podcast soon.

Oh yeah, we’d love to have you at some point. That’d be great.

Yeah, that would be really cool. We should do a whole episode.

Something a bit more formal… I’ve been having some backchannel talks, but… We could continue that afterwards.

Yeah, we’ll keep talking

I’ve got some paperwork we could sign…

Perfect.

So let’s go. Thanks for having me.

Yeah, thanks for joining.

Thanks for talking with us.

By all means, man. Ladies, thank you. Who’s up next?

I think –

Oh, there we go. Storyblok’s in the building, let’s go!

Arisa, welcome!

Yeah, thank you. Do you wanna introduce yourself? I know you gave the Storyblok talk, so… Yeah, can you speak more to that as well?

Sure, sure. My name is Arisa, and I’m originally from Japan, but living in Germany. Storyblok is a headless CMS, and I work in there as a developer relations engineer. Not just on the headless CMS… What makes it unique is that we have the real-time visual editor, so whenever you make content changes, you can take a look at it and see in one screen.

[24:37] We’re based on the atomic design methodology; it means that you can reuse the components, as many as you want, and you can nest these reusable components in any levels. So you can only, for example, define only the necessary components that you need, and you don’t need to duplicate unnecessary [unintelligible 00:24:57.25] components.

So that’s what we have… And here for today’s talk I was showing that, let’s say, choices of choosing the technologies; I was showing as one of the examples that imagine that if you are for example in your everyday life, when you face something non-user-friendly interface, then maybe in the end you will be able to get something you wanted to have, but the journey until you will be able to get the things you wanted to have, or the things you wanted to achieve - it’s not going to be nice. Same thing could be transferred or would be applied in the tech world.

I was showing how resilient, fast, very smooth and organized experience you can get from, let’s say, Storyblok and Remix. Because on the fly, Remix already provides a very nice way to dynamically handle the routes. Let’s say anyone who doesn’t have the developer experience - they can easily create nested routes dynamically, from let’s say the dashboard and the visual editor… And developers can focus on their own work, and stuff like that. So that’s something what I was giving a talk today.

Oh, cool. So that means with the way you’re using or Storyblok works with Remix is - can you speak more to that? It’s just the routing layer and how the components get loaded?

Yeah, sure, sure. So the thing is, once you define components from the Storyblok side by giving a name of the component and by giving the levels of the components, how you want to nest, and the next step you can do at the Remix side is that - well, you can, first of all, define the component to be dynamically rendered. To do that, we provide JSON files for the draft version and the published version.

Of, for draft AND published, they’re separate JSON files.

Yeah, yeah.

Okay.

So if you wanna see, for example, a cleaner version of the draft JSON, you can just take a look at the published version… Because for the draft version we have additional property to show all these components are editable… But you don’t need to see that in the published component.

I see, yeah. Okay. Because it’s a post. So if someone were publishing like a blog or something - I mean, with Storyblok that’s what you’re doing, right?

Got it. It’s a CMS, yeah.

Yeah, exactly. So what you can take a look at from this draft JSON is that you’re gonna see all the components are in an array object. So you’re gonna see that if you want to dynamically return these components, you’re gonna actually use the map to render automatically.

Sorry, can you say that again?

Oh, sorry - you can actually map these array objects, so that you don’t have to worry about to manually create for example let’s say the component files, and you don’t need to worry about to create the logic to manually render these components. You can just call one API that is provided from our SDK.

[28:11] In Remix’s case you can just use our React SDK. So you can call one of the APIs that is fully equipped to handle all the dynamic component rendering part, so conditionally, it will decide - like, if the dynamic components are there, then it’s gonna return. But if not, then maybe you can put some nice error handling to show “Hey, the name of the component doesn’t exist”, stuff like that. And you don’t have to worry about to build this kind of workflow by yourself. You can just call this API and you just call this API as a JSX component, and everything is all set. You don’t need to worry about what kind of components the users are going to define, let’s say inside of another component. Everything is already set in there.

Okay.

How have you been enjoying the conference and working with Remix?

Oh, I am really enjoying it a lot, and I need to insist that these is one of the best conferences I’ve ever attended… I mean, this is my third time joining an in-person conference…

Oh, wow. Nice!

Yeah.

Oh, ever?

Ever, yes.

Oh, wow! Cool! That’s awesome.

Yeah… Because I started to speak in conferences after the pandemic… So I attended more online conferences as speakers, so as attendees. So this is my third time. But it’s really one of the special ones, because – I mean, I feel that I know a lot of… Not just the speakers, but even the attendees. I got a chance to be able to talk to them, so I feel like I know more of let’s say the folks joining here closely, as well as – yeah, I was able to do some fun activities. For example, I was going to the dinner, and there was Kent, he was asking “Do you wanna do one-wheel?” and I’m like “Yes, I really wanna do that.”

The one-wheel has been really popular…

I’m terrified though… Like, absolutely not. [laughter] I’m impressed by your bravery.

[laughs] Yeah, so I’m really enjoying the conference itself. I mean, the talk also went really smooth. The reason I’m saying that is – well, Michael from the Remix team knows, because we attended another conference together in Amsterdam, and the funny thing is during my talk there was a fire alert going on… And for some reason, the monitors on the stage - it really hated my laptop to connect it, so I had anything that I could get to be stressed out. So compared to that, RemixConf went really smooth. I simply really enjoyed it.

That’s rough. Anything is smooth compared to that, but… It’s been an awesome event. Cool, cool, cool. Well, thank you so much for joining us.

Yeah, this was really – I mean, I’ve only used Storyblok as is, but never with Remix, so this was actually really interesting, and your talk was very informative… So thank you.

Yeah, thank you so much.

Thank you, too.

Wow, this mic looks like it’s been beat up. I’m kind of scared of the previous people that were talking here… [laughter]

I think that was the result of a mic drop, potentially, I would imagine…

Yeah, an actual mic drop, yeah.

A literal one.

Yeah. So this is – let’s speed test. Yeah, okay.

Yeah. So if you want to – I don’t wanna say, the A/V people may kill me for letting you mic drop… So maybe don’t do that.

Yeah, probably a bad idea.

Definitely. Well, thank you for having me.

[32:06] Yeah, of course, thanks for being on.

I think this is the first time I’ve met both of you, so it’s a pleasure to be here.

Yeah, you too.

Yes, really nice to meet you, too. Do you want to introduce yourself to the listeners as well, and maybe give the cliff notes version of your talk from today, too?

Okay, well it all started when I was born… [laughter] The cliff notes version of me - my name is Anthony Frehner. That’s a really tough last name, so that’s how you say it… I’ve been working at Shopify for only about six months or so.

Oh, wow. Okay.

But at Shopify I have the privilege of working with a group of really intelligent, smart people, working on a brand new framework called Hydrogen. Kind of the whole thing behind Hydrogen was just making headless e-commerce for Shopify better. And along with big bets on React Server Components and things like that, my task lately has been to kind of take that value that these intelligent people have worked on for making headless e-commerce better for Hydrogen, pull it out and make it better for everyone now. The goal is to make it great for anyone, whether you’re using Vercel, or Remix, or whoever.

When you say that, you mean make it agnostic? Framework-agnostic.

Yeah.

Okay.

Yeah, React framework-agnostic.

Okay, cool.

And we have tentative grand plans for maybe even going outside of React, and stuff, but we’ve gotta take small steps before we can take those big ones.

React’s a pretty safe bet. [unintelligible 00:33:31.08]

Yeah. It’s a good place to start, it feels like.

Yeah, for sure. That’s awesome. That’s really cool to hear about. The headless e-commerce space is so big right now. I have a good friend. Kelly Vaughn, who’s very involved in the Shopify space, so I get to hear about it from her a lot.

Oh, sweet.

It’s really cool. Tell us about how Hydrogen works with Remix. Do you use it as your routing layer, or how does it work?

No, the goal for this package that we’ve been working on is essentially components… It’s going to be called Hydrogen UI, so it is a separate package than Hydrogen itself… But yeah, so it’s components, and it’s hooks, and kind of the things that I showed in the talk as well, that are helpful for GraphQL queries, and things like that. And maybe there’s some stuff in there that’s useful for anything, like that GraphQL helper function that I showed, that was like “Hey, you’re not using these fields in your GraphQL query. Maybe you should remove them, and make your query more optimized.” Stuff like that. It has the potential for just being used anywhere that you’re querying GraphQL.

So again, there’s lots of big plans, but we’re still kind of pushing to try and get our first release out, and then once that is done, now we can take a breath, and then take a look at the wider ecosystem and say “How can we make things better for everybody.”

Yeah. I love how that’s become such a strategy within the web dev space, of having some open source or free project that just helps everybody, and then - you know, you still have a company behind it, but you have this product completely detached from it… Next.js and Vercel, for example. I think that’s really cool.

Yeah, it’s interesting to see, like you say, the open sourceness of everything, and everything going open… The other part - I’m fairly new to Shopify, so I don’t wanna toe the line too much, or whatever you wanna call that… But there’s a big emphasis at Shopify of “This isn’t a zero-sum game.” In other words, we don’t have to make it so we are the winner and everyone else is a loser. We want to make it so everybody wins, if we can. And obviously, if we can do well in the process, that’s great, and we can all have jobs, and stuff… But the goal is to really just help out the broader ecosystem and help everybody, and kind of see some of that – not only in this work that we’re doing in Hydrogen UI, but also just in React itself, with React Server Components and things like that… Providing feedback and trying to make that proposal better.

You’ve talked a bit about making it React-agnostic… So what are the plans so far? You have it working with Remix, you have it working with, I guess, vanilla React, and Next.js I think, too?

[36:16] So the package itself isn’t released yet, so that’s the fun part; this is all – it almost feels like an Apple keynote of like “Hey, this is where we want to be in maybe six months, or less time”, but this has like a future-looking type feel to it. But the goal is to make it so it works in Remix.

And I alluded to in my talk as well - we’d really do want these tight integrations with other frameworks to make sure that we’re doing it right for you. In fact, last week we noticed that Netlify, for example, had built a Hydrogen adapter for their new Netlify edge computing that’s built on Deno, and stuff like that… We noticed that we had broken something in their adapter through one of our releases, and hadn’t really paid attention… So we fixed it, but then we also worked with Netlify to say “Hey, we’re now going to do preview deploys on every commit, so we can check out Hydrogen on Netlify, and make sure it’s working there”, and stuff like that. So yeah, there’s the goal to just make it work everywhere eventually.

So is there actually – are you working with different deployment platforms to make sure that Hydrogen works on them? Because there’s obviously intricacies to how that works. So what’s that process like?

Yeah, it’s been interesting… And again, most credit goes – it hasn’t been me; I’ve just been sitting in the background. Most credit goes to the intelligent team that I’m a part of.

But yeah, we’ve worked very closely with Cloudflare specifically, to make sure things work there… And having Slack channels where we can talk and collaborate and make sure things are working well… Shopify itself is actually working on its own deployment platform…

Oh, really?!

Yeah.

Interesting.

So that’s another place where we’ve been working with our own internal team to be like “Okay, well is this working there?” and having preview deploys…

Super-interesting. Remind me to talk to you about AWS. [laughs]

Okay, yeah.

Cool. What are you excited to work on, since you’ve just started on Hydrogen? What’s the thing that most excites you about that project?

The most exciting thing about Hydrogen for me is I really enjoy working on developer tooling and making just developers’ lives better… So I really like working on things like – right now, currently, we have Vite as our bundler, and doing all that stuff… And we have a super-intelligent person [unintelligible 00:38:40.28] that has all that integration, and I’m just absorbing all of that knowledge, trying to absorb all that knowledge from these people and learning how to make Vite to make Hydrogen run better, and stuff like that.

So I really enjoy developer tooling, and standard spec… That’s more outside of Hydrogen, but yeah - working on standards… It’s kind of weird, but I actually really enjoy that stuff, too. And I’ve only done a tiny bit of it, but when I do it, it’s super-satisfying. I’m kind of weird that way.

That’s awesome.

There’s something really awesome about building developer tools as a developer yourself, and being able to work on something that’s for your persona. It sounds like you get to do that at your job.

Yeah, a little bit. It’s super-fun, and like I said, I get to learn from these super-intelligent people… And when I have time, I go out and look at these new proposals that are happening, and try to provide feedback where I can, and things like that…

Working on – the current one I’m excited about now is like this new app history or a navigation API for the web to kind of replace history.pushState( ).

Oh, interesting.

There’s a lot of working going on there. And again, I’m not doing much there, but I’m just sitting there kind of in the background, watching and learning, and maybe once every month or so being like “Hey, what about this?” type thing.

That’s super-interesting.

Did you work on e-commerce prior to Shopify itself, or e-commerce dev tooling itself?

[40:09] So unintentionally I have worked – you know, doing a lot of e-commerce throughout my job history… But it was never intentional. It was just - that’s what I always happened to be working on. My first job was working for a local company here and making their website, and migrating it from Magento to Shopify, which at the time I had no idea I was gonna be working for them. And then another company I worked for, local, building a custom platform to integrate all these different e-commerce things into a dashboard, so you can see how well your products are selling, and stuff like that. So it’s kind of been like an accidental “Hey, I kind of understand e-commerce, I guess, but…”

Yeah, it’s interesting, because developer tools itself is a niche in and of itself, in all of development, and then e-commerce dev tools is a niche within that niche, because it’s very specific; the problems that people have in e-commerce, when they build e-commerce sites, are very different than if they were building another type of website, right?

Yeah, totally. And that’s one of the reasons for me Remix really stood out - e-commerce is so focused on performance, so focused on how well is your website running in time to first byte, and SEO stuff… And Remix just seems like a great fit for that. Hopefully, Hydrogen is, too.

Awesome. Well, thank you so much for chatting with us. It was awesome to meet you.

Thank you very much.

Yeah, thanks.

How’s it going?

Good! I guess I’ve never met you guys, so I’ll introduce myself to you…

Yeah, that would be awesome.

My name is Emily Kauffman. I was one of the backup speakers from yesterday…

Oh, cool.

Okay…

So they kind of cornered me over there and was like “Hey, there’s a podcast going on.”

Perfect. Welcome.

Yeah, welcome. Why don’t you tell us a little bit about yourself and then also what your talk was about?

Sure. So my name’s Emily, I’m from Pittsburgh, Pennsylvania. I work for a company called Harvey, which is a grocery delivery service, where all of the food comes from local farms and producers. We’ve spent the last two years doing performance, and that kind of led us to Remix in the past couple of months… So that’s basically what I’ve been doing, is writing our site in Remix, and it’s been awesome. It’s been a lot of fun.

That’s so cool. It’s really cool to hear about a company using Remix in production too, because it’s pretty new as far as these dev tools go… I would love to hear about your experience there, and what the challenges were, but also the really high points as well.

So we’re not quite to production yet…

Not quite to production. Okay, sorry.

It’s a big Symfony application, so over the last year we’ve been slowly moving it to React. We have it in React now, so we have been doing comparisons of our existing React site into what it would look like in Remix… And the high points have just been – I guess you guys were talking about Lighthouse scores… Ours was a 32 without Remix. Using the same components, it was a 97.

Wow… That’s huge!

Wow! Okay.

So that kind of stuff has been really exciting for me, just seeing those changes… And that was not that many weeks of work to get it to that point.

Had you used another framework prior to Remix? What was the reason for reaching for it in the first place?

I mean, part of it was I did it on a weekend, because I wanted something to play with… And I was like, “Oh, I bet this would be pretty cool.” And I shared it to my boss, and he was like “Wow… Yeah, we should try to keep working on this and just see…” Because performance has always kind of been an issue with our application. Because it used to be a small – if you’re familiar with like a CSA…

Oh, yeah, yeah, yeah.

…Community Support Agriculture, where you get like a box from a farm… And two years ago, before the pandemic, we had like 40 products that you could get… Because everyone wanted grocery delivery service, we grew to like 500 products in the most short amount of time, and it kind of crashed our page… So that was one of the reasons we were looking for something to help with that performance.

[44:17] Can you speak more to the stack, or what it was like before you moved to Remix itself, and what that migration was like? I mean, you haven’t pushed to production, but I’m just curious what that stack process was like.

So they were all Twig templates originally. We kind of set up a React single-page application, and it was kind of like intertwined with the Symfony application. And then as part of our performance stuff we were doing, we kind of split out our admin code versus our member code… So I’m just focusing on member right now, but I’ve built a components library, so I was able to pull out a bunch of – you know, like the buttons, and all of that stuff. That made it a lot easier to move over…

Yeah, for sure.

…because I just basically set up all these new routes that matched what we had…

You already had the component library.

I already had the components, yeah. I mean, I wanted to do that anyway, for fun, but this was like a good way to justify it, and it’ll make it take a lot less time if we can just have a lot of that. But yeah, it’s been fun.

So I guess it didn’t take any convincing, really, for the team to move to it.

No… So I don’t exactly know the story, but I guess my COO hired Ryan at one point in the past, and…

Okay.

Oh, wow.

…so I was working on trying to figure out how to convince everyone that we should move to Remix, and my COO posts in our Slack channel like “Hey, have you guys heard about Remix? I think we should use it” and I was like “Actually… I can talk to you about that.”

Were you using React Router before?

Yes.

Okay. So I guess then it’s sort of related.

Yeah. So we were on an older version of React Router, and since they just released that upgrade path, I’ve started working on that…

Oh, cool.

…so maybe I’ll just switch some of it to Remix and [unintelligible 00:45:55.12]

Yeah, I think it definitely helps if you have the infrastructure in place, or you’re already using React Router, because then it sort of integrates really nicely with Remix… Instead of if you weren’t using, and then you move to – I’m actually curious about that migration strategy. I’ll have to find someone who has done that, and see…

Our member site is a single-page application, our admin is not. We’re not using React Router there. So that is something I’m trying to figure out.

Okay. So that one is using Remix also, or will be.

It’s not using Remix yet, but I think it will, eventually. I’m trying to figure out if we need to do a rewrite of just everything to get it, because a lot of it is just Twig templates, and PHP [unintelligible 00:46:34.01]

Rad. Nice.

I think [unintelligible 00:46:40.13] called people who write PHP dinosaurs earlier, so that’s me, I guess… [laughter]

Yeah. I was like, “Um, there are people who write PHP.” The Laravel community is huge, by the way, and there are people who still write Laravel, and they’re a very interesting, awesome community, so… I don’t know; I’d take issue with that comment, personally…

Yeah, that’s fine…

Awesome. Well, thanks so much for chatting with us it was really cool to hear your story.

Yeah, it’s nice to meet you guys.

Thank you.

Nice to meet you.

My name is Aaron Saunders. I was one of the backup speakers also. I did not get promoted, but I still did my speech last night. I’ve found out about Remix through just evaluation of software.

Okay.

I run a software development firm in Washington DC, and we are always trying to find the cheapest, most effective way to build solutions for clients. And I saw the posts, and so I started playing with it for a weekend, and then I have a YouTube channel, so I did a couple of videos on it…

That’s awesome.

[47:54] Then when – I think Kent mentioned that they were gonna do the conference, he said “Hey, you should go for a talk.” So I did. I threw my hat in the ring. I didn’t make the final cut, but I was just happy to be here. I haven’t spoken at a conference in almost 15 years now.

Oh, wow, that’s awesome.

And it’s one of the things that when I talk to kids and other folks getting into tech, I always say “You’ve gotta put yourself out there.”

Yeah, definitely.

So I figured I need to eat my own dogfood and put myself out there, so…

Yeah. Well, a YouTube channel errs as well

Yeah, but a YouTube channel - you can sit at home, and if you don’t like something, you cut it, and you can edit it, so it’s a lot different than standing up in front of a bunch of people, talking.

It’s still a lot of work…

It is definitely a lot of work, but I enjoy it, because my whole passion thing is about getting more folks into tech, specifically black and brown folks into tech.

That’s awesome. Tell us about your talk. What did you speak about?

So my talk was about [unintelligible 00:48:43.22] and nested routes in Remix. It was something that even when I was trying to learn it, reading through documentation, I’ve found it a little bit challenging to understand… My big thing on my YouTube channel is to take topics or technology that - I don’t wanna offend anyone, but normal people don’t normally run into, and kind of expose it to them, but explain it too in a way that they’ll at least get excited enough to try it. So that’s kind of what I did.

That’s really cool.

Can you speak to the pain points that you had when you were learning Remix? What was that like?

It wasn’t that much of a pain point for me, but I think - no offense to anyone; I think a lot of the assumption when you read this stuff is that you know a lot of technology.

Yeah, yeah.

There’s almost kind of this closed group of “Are you smart enough to understand this technology? And if you’re not, step to the side.”

Yeah. I think in general – because I think it’s just like to what level, or how deep do you get when you explain something. Do you go all the way to fundamentals, or do you just assume it’s –

I try to assume that you – so I do stuff on React and I do stuff on Vue. So I assume that you know what React is, and I assume you know what Vue is. And then I just try to break it down to simpler concepts. I also like to give a lot of references to other things for people to look at, to try to just build upon the concepts. But it’s really about just breaking down that kind of initial fear that people have of trying something new in technology.

And that’s a great sign that you know something really well too, because if you can explain something complex to a beginner, there’s on better way of showing that you really understand a thing that’s challenging. It’s hard.

Right. I taught at the college level for a little while, and so one of the – I like people to ask questions, because then through the questions you get the feedback and you get better at explaining things.

Yeah. You find out the common pain points that other people are having.

Yes, common pain points that other people will have. Exactly.

Yeah.

So since you’re a teacher, or someone who’s naturally inclined towards educating or documenting and talking about your process - so from your experience, since yo had comments around how the docs for Remix works, where do you think that line is when you have to explain concepts? Especially because Remix introduces some newer ways of rendering – it’s like route-based rendering, which is pretty atypical for frameworks, right? So where do you think the explanation needs to go? Not specific to Remix, but in general, if you were to –

I think it’s almost unlearning some of the other stuff that you’ve learned, and getting back to the basics, which is one of the things that I liked about Remix. They take away a lot of the complexity of things, but a lot of those things are things that when you’ve read other articles and saw the things you had to learn - you’re getting a specific mindset.

Yeah. I think it’s always funny when they bring up that a lot of new developers have used event.preventdefault() on every form that they’ve ever done. I think that’s so funny it’s like I’m an older developer now but it’s probably true for a lot of people.

Yes, because you see it in all the demos and all that code, it’s always like “Well, remember, you have to do event.preventdefault(), always.”

Yeah, always. But you don’t, actually.

[51:52] You don’t. A lot of it just doesn’t matter anymore. But you know, overall I’ve had a great experience, like I said. It’s been years since I spoke at a conference, it’s been since before Covid since I’ve actually been at a conference… So this is a great kind of first step back in, and then I’m also just excited, grateful for the opportunity to talk… Because honestly, pre-Covid I decided that I was gonna start getting back out and speaking at conferences, and trying to – that’s when I really got into promoting my YouTube channel, and stuff like that.

That’s awesome. Well, thank you so much for chatting with us.

Thank you.

Yeah, thank you.

This was great to meet you, and we’ll definitely shout out your YouTube channel in the show notes.

Hello…

I don’t think you need an introduction, but…

Long-time follower, first-time caller…

Wait, have you never been on the podcast?

No. I can’t remember. I think I might have been…

We have to have you on then…

Because I think we had –

…JS Party, but it…

We had an episode on React Router, I think, at one point… I think you were on it…

Yeah… This sounds familiar. Maybe it was like a couple years ago.

Probably.

Yeah.

But welcome, regardless.

Cool, it’s good to be back.

Potentially, yeah.

Maybe.

We’ll have to look it up, and link the episode if there was one.

But thank you for having me regardless.

For sure. Thanks for joining us.

Yeah, excellent. Yeah, happy to be here.

It’s been an awesome event, and your keynote this morning was really great as well. You gave a really great introduction into the history of Remix, and the thought behind it, and then also where it is now… I think that was a really great story for people. Do you wanna give us the short lightning talk version of that now?

The short version of it? Sure.

Yeah, yeah.

Thank you, by the way, for the compliments. The short version of the story is - we’ve been developing React Router for a long, long time… And I think Ryan and I were always kind of hoping that somebody would just sort of like pick it up and run with it, and take it to the next level… Because we saw so much potential for everything, everything that we’re doing now with Remix - code-splitting by route, and data loading by route, and loading and unloading styles by route, and all of this stuff that you can do with React Router but nobody was actually doing anything with it. And it wasn’t for lack of trying either; I had tried to convince various people to use it, and it just wasn’t catching on. I tried to convince the RedwoodJS team to use it, I tried to convince the Next people to use it…

[56:03] Actually, the top issue on the next issue tracker for a number of years was “Use React Router!” Because I think the React community actually really liked it. But it just never happened. At one point I was talking to them about possibly doing some consulting… Anyway, it never happened… So when Covid hit and our training business kind of took a big hit, we were just kind of like “Well, I guess if nobody else is gonna do it, I guess we should just do it. And along the way we’re gonna do all this other good stuff too, which is stuff that we really believe in. We’re gonna do progressive enhancement, and we’re gonna make sure that it’s backend-agnostic, and it runs in lots of different places…” Just a lot of different sort of opinions that we’ve had, that we just wanted to put in there as well.

Awesome, awesome.

Yeah, since you mentioned the Next thing, I actually wanna – considering the announcement that came out yesterday around what Next is doing… I saw some comments around whether or not there was some inspiration taken from React Router or not. Do you wanna speak to that, and how that influences what you guys are doing?

I think they were very forthcoming about it… On Twitter, at least. Not in the RFC, unfortunately. But on Twitter Sebastian came out and said “Oh yeah, we took some inspiration from React Router”, which I think is pretty obvious to anybody who is kind of paying attention to this space.

Honestly, I wasn’t too miffed about it. The goal of Remix is not – we have said since day one, build better websites, sometimes with Remix. And I mean it. I really do mean it. So if we have a good idea, that is nested routing, which I really love, and the Next team is far enough along with their implementation that I don’t actually think it makes sense for them to use React Router at this point…

Sure, yeah.

…because the router is such an integral part of a framework…

Yeah.

I don’t think it would make any sense. They would have to have massive deprecations, and huge breaking changes for their whole user base, and it would be a huge pain… So if they wanna just sort of take one core idea, which is nested layouts, which has been a huge pain point in Next for a long time, and they wanna put that in the framework, I applaud them for it. I say “Yeah, go for it!”

I will say that we’ve been thinking about nested routing for a long, long time, and literally, everything we’re doing in Remix is coupled with nested routing. So the suspense that we’re doing, the data fetching that we’re doing, even our data mutations, even things like styling, the code-splitting - everything is coupled to the nested routing architecture, which… I don’t know if they have plans to go all the way down that rabbit hole, but it goes quite deep. But we’re satisfied with it, we’re satisfied with how well it’s worked out for us, and hopefully it works out well for them, too.

Yeah. I would say inspiration is the best form of flattery, so…

Yeah, absolutely.

So if they took some inspiration… I mean, it is an open source project, so technically it’s free for all, right?

Exactly. I’m not gonna get upset about somebody copying an idea from my MIT-licensed code. I do that all the time; I look at people’s code, and I’m like “That’s rad! I’m gonna do it like that.”

Yeah. And React Router is such a huge part of the React community as well. We all grew up using React Router, kind of, so…

Yeah. Cool.

So yeah, I’m sure it’s a huge inspiration.

Yeah. The Router really has been a – it’s been interesting to work on the router, because I think at first… We’d been through several iterations, and to be totally honest, we didn’t know what we were doing the first couple of times around. We were learning React, just like everybody else. I still remember when the very first person came along and said “Hey, I wanna do server-rendering with React Router.” And it was like, “What…?” We hadn’t even thought about that part yet. It was just kind of this little niche thing that – you know, Facebook wasn’t actually server-rendering with React Router; they had their whole XHP backend… So I didn’t – anyway.

[01:00:25.07] We had to evolve to support that, we had to figure that out… There were just silly bugs and things that we were doing early on… But it really has been a huge privilege to work on that project for so many years. I think we’ve really, really, finally hit it on the head with V6 though, I have to say.

That’s awesome.

We sat on V5 for like five years, because prior to that we had been kind of accused of “Oh, you’re moving too quickly, and I’m kind of getting exhausted with all the API change.” And so I was really, really shy to push another major version, until I was sure… Like “This time for sure!”

“This is it!”

“I got it right! This is it! No more!” I have to say, I’m really proud of V6. There’s a lot of stuff in V6 that we haven’t even really talked about that much… But I think it’s a good sign that people are just quietly shipping it and not having huge problems with it or huge issues with it… That’s always a great sign, because like “Oh, okay, that’s just working for everybody. That’s good.”

Yeah. There aren’t people yelling at you on Twitter about it.

Yeah, exactly. We have a really great story for upgrading from V5, which I think is huge. We care a lot about backwards-compatibility. One of the coolest features in V6 is all of your routes and your links are all relative, and it all works… So you can actually build tiny React Router apps. You can be on the ads team, and you could be on the messenger team, and somebody else could be on some completely different team. And you’re just working on the routes at /admin/whatever, and then you’re working on the routes at /messages/whatever, and you can stitch those apps together into a larger app.

So I think organizationally, that’s how lots of companies are split up - by product, by focus. And I think the router now is a lot more conducive to working in those larger organizations, which I think is pretty awesome. That was a specific design goal of V6, for example.

Yeah. I think it was Eric’s talk where he talked about the state machines piece…

Yeah.

One thing that at least for me has been coming up is just the persistence question in terms of when you use Remix and you want a persistence layer with it; you end up having – I think Eric’s demo used cookies…

He’s using the cookie, yeah.

I think some people might use IndexedDB maybe, potentially…

Yeah, yeah.

So with Remix, have you guys been thinking about that particular question as to like how people will be answering that data persistence question?

Yeah, a hundred percent. In the early days of Rails, when Rails first came out, I remember – the first time I used Rails, I could use MySQL or Postgres or SQLite. And SQLite was kind of the one that it shipped with, because that was pretty easy. They could just create a file, and that was fine. And then if you wanted to get serious, you’d get your Postgres database, and then you could connect to that. And I think now - we have seen such a proliferation of databases and data architectures…

It’s pretty hot now…

Obviously, you’ve got NoSQL, lots of people are just like “Oh, I’m just gonna use a key-value store”, maybe you’ve got an Elasticsearch database, maybe you’ve got a JSON API that you’re talking to… Firebase… There’s so many –

There’s also this resurgence of SQLite, where everyone wants to use SQLite now…

Yeah, it’s cool. You all at Fly are dealing as well with SQLite.

Yeah, exactly. We have Litestream, so SQLite, yeah.

[01:04:02.09] Kurt actually convinced me, too. I have like a version of UNPKG that one of these days when I’m going to get some free time I’m actually gonna ship it, I promise… But it’s all built with SQLite as a cache. Anyway, it’s really cool. But I love SQLite.

But the point I was trying to make is there are so many different options for data persistence, and I have no idea, honestly, what you need for your app. There are just so many different options. And so what we’re doing as of now, as of Remix V1 and for the foreseeable future is we just wanna give you the right touchpoints so that you can access your data really easily.

So all we care about is when are you loading the data, when are you actually running your queries, and then also if some of those backends are slow, how can you return a response to the user really quickly, without having to wait on them. So that’s the streaming work that we’re doing.

Yeah.

The pattern in Remix is kind of like called “backend for the frontend.” I don’t know if you’ve ever heard of that pattern before, but it actually works out really nicely. If you have your data in Postgres, or you have your data on GitHub in a JSON API or something that you’ve built - yeah, a GraphQL API, it doesn’t really matter… What we care about is that we can run all of the queries for all of your nested routes in parallel, and that we can go and generate the page. Now, again, like I was saying, if some of them are slow, that’s cool, too. We’ll very soon in Remix - in the next couple of weeks we’re gonna ship support for React 18 streaming. You’ll be able to stream down the pieces of the page that are already ready, and then just await the pieces that aren’t. But I think that’s right level of abstraction in a world where we literally have no clue how you’re storing your data… We’re just gonna help you decide – give you the right hook, essentially, to say “Okay, we’re ready for some data. You now take it from here.”

Yeah. So then Remix will basically be more like a framework, and then you kind of pick and choose what your deployment platform is, as well as your database as a service, whatever that may be…

Yup.

And so essentially, whoever is using Remix will have to make those decisions separately?

Yeah, you were saying earlier - we call ourselves kind of center stack, and I think this really kind of gets to it… Because we’re not super-opinionated about where you host; we love Fly, we also love AWS, we love Google Cloud, people deploy on Vercel, Netlify… It’s totally cool. We’re kind of backend-agnostic, we’re database-agnostic… But what we do care about is the network tab, which is the thing that tends to come in between the backend and the frontend.

It’s like a communication middle layer.

Exactly, yeah. How and when are you loading your data, how and when are you doing mutations, how does that affect how you need to reload data, and bust the cache, things like that… A short-term goal of ours is also to be frontend-agnostic. We do not consider ourselves a React framework. We love React, and I think React makes a great set of trade-offs, personally, for everything I’ve used. I think it’s amazing. But I totally get it that some people don’t want that, or some people want a much smaller version, maybe they wanna use Preact, maybe they like Vue, or Solid, or something like that…

Svelte, yeah.

Svelte, or whatever. Yeah. So I really don’t care of what you wanna use for templating. You could even just say “I don’t wanna run any JavaScript on my site at all”, which we saw quite a few people do today. I thought it was kind of a fun, little theme; it was like a little bonus to everybody’s talk. They’re like “Oh, and by the way…”

Turn on JavaScript

Yeah, and it still worked, right? But yeah, so that’s I think why we call ourselves center stack, is because we fit right in that – that’s the part that we really care about, that we wanna provide some structure around what happens in between the front and the backend… And then pick whatever you want on either of those sides.

[01:08:04.11] Well, you gave a little bit of an answer to this in the last question, but kind of as our final question before we wrap up…

Sure.

…can you give us a little bit of a sneak peek at the vision, the roadmap for Remix at all?

Yeah, a hundred percent. So we’ve actually got quite a few things that we would like to build… I think it kind of depends a little bit kind of who you ask, but… So one of the things that I’m really interested is in seeing how many different places we can actually run Remix, and how many different use cases that we can serve.

Right now we actually serve the traditional SSR use case pretty well, and we can also do really well the very traditional full-page reload whenever I make a mutation or a request. Just leave scripts off the page, right?

One use case that I actually think would be really cool for us to be able to serve is what happens when – more of like a Create React App style app, right? We heard Jon Jensen today talking about like “Oh yeah, a bunch of folks at Netlefix –” Sorry… Netlefix… [laughter] Netflix… “A bunch of folks at Netflix–”

[unintelligible 01:09:12.15]

Yeah, they’re a Create React App, they ship that, and it’s just like a client-side thing, right? And that’s a totally legit way to build apps, right? I would love to have better support for that, I would love to have better support for so-called offline apps, or PWAs… If you look at the Remix server runtime, it’s actually pretty cool, because the whole thing is just built on web primitives, which we polyfill on Node, because Node obviously doesn’t have a lot of that. So we polyfill it on Node; a lot of that stuff is already present though in like Cloudflare Workers, it’s present in Deno, we heard from Ryan Dahl today… Guess where they’re also present - in the browser, in the service worker environment. What if you could run the Remix server in the browser? Right…? Right?!

Crazy, yeah.

Yeah, but you could keep the same programming model. This is the exact same programming model: request, response… Maybe your data store is IndexedDB, or maybe your data store is just some JSON API which you can absolutely hit from a service worker that’s running right there in the browser. So it’s just sort of moving – these server environments are kind of funny; you can run it on the origin, you can run it in the CDN now, with Cloudflare workers, or something like that, and you can also run it right there in the browser.

I thought it was actually kind of interesting… One of the big inspirations for the Remix backend was the fact that Cloudflare Workers actually used the service worker API, so it felt like you were coding a service worker, but it’s running on the CDN. But if you’re still using the same API, why not just bring it all the way to the client?

I have a good friend, James Long, who is building this app called Actual. He’s written a bunch of stuff. He wrote Prettier, he wrote this library called absurd-sql… It was rad, actually… It’s absurd, because – so browsers have this thing called IndexedDB… In all known implementations of IndexedDB, IndexedDB is built using SQLite… But SQLite was deemed not a good fit for browsers, because they needed more than one implementation in order to standardize something. So they said “We can’t standardize SQLite in browsers, so we’ll standardize IndexedDB instead.” All the browser vendors went out and built IndexedDB on top of SQLite, but what he really wanted was SQLite. So then he built the SQLite implementation on top of IndexedDB.

Very meta.

It’s sandwiched.

So he’s got SQLite talking to IndexedDB, which is…

It’s a SQLite sandwich.

…powered by SQLite. Exactly, it’s a SQLite sandwich. Anyway, he built this app; that was his persistence layer for a finance app that he was building called Actual. That’s why he called it Absurd, because it was a sandwich.

But I would love people to be able to build apps like that with Remix. That would be totally awesome, people who are doing that. So basically running it in more places, that’s definitely one of our goals. Like I was talking about, being frontend-agnostic - that’s definitely one of our goals.

[01:12:17.28] Another goal of ours is to – we really wanna pave the way for React Router apps to become Remix apps. React and React Router give you a lot of leeway. You can build an amazing experience with React. You can also build a really terrible experience with React. So what we wanna do is by building Remix, what we’re hoping is we’re kind of putting some of the bumpers on the bowling lane a little bit, to help you roll a strike with React. So what we wanna do is kind of pave the way for people who are using React Router to give them a compiler, give them a server runtime, be this kind of center-stack layer for them, to help them build really great apps with it.

So that’s all the stuff that we’re kind of focused on at the moment. And then there are a couple of odds and ends, like we really should have a better story around image optimization that’s, again, built on web standards. We’ve thought a lot about it, and we should take care of that… But I consider that stuff kind of like low-hanging fruit.

And then another big – just a really big thrust of ours is just education. This conference, the meetup groups, the documentation that we’re writing, Kent’s working on an Egghead course… Just all of the stuff that it takes to just help people build great apps… Because right now I feel like we’re – I kind of mentioned it in my talk; I feel like in some ways we’re still giving people a basketball and telling them to kind of do a slam dunk… But knowledge really is power. So the more our company can do to empower people, to give them the knowledge that they need to really take advantage of the tools that we’re building, the better. So that’s a huge focus of ours as well, education.

That’s awesome. I think the Egghead course is live. I got an email about it today.

Yeah, it’s live. We I think were tweeting about it earlier today…

Oh, and another one.

We’re gonna make another one.

Another one. You heard it here first, folks.

You know what - don’t ask me; just ask Kent what’s going on. He knows.

Amazing, amazing. Well, thank you so, so much. This has been an awesome conversation. I learned so much.

Yeah, thanks for having me.

And thanks to the conference for having us as well.

Yeah, this was great. Thank you.

It was definitely a great episode.

Cool.