Matt Arbesfeld:
Welcome to PodRocket. My name is Matt Arbesfeld, I'm the co-founder and CEO here at LogRocket. And I'm joined today with a very special guest, Michael Jackson, who's a principal engineer and Remix team lead at Shopify and the former CEO and co-founder at Remix. Welcome to the pod, excited to have you on.

Michael Jackson:
Thanks for inviting me, Matt. It's good to be back.

Matt Arbesfeld:
Awesome. For those who didn't hear the first episode where you covered Remix, maybe you could give a quick overview of what Remix is, what it adds on top of React Router, and just give folks the lay of the land.

Michael Jackson:
Remix is a project that was started by me and Ryan Florence two years ago right in the middle of COVID. We were looking for a way to build full-stack apps with React Router. React Router is a project that has been around for a long time a lot of people have used it for years now for doing routing and react. Remix is sort of more generally a compiler and a server backend for React Router apps. So it takes care of the server rendering piece, obviously. We support multiple server run times, not just Node. So we also support Cloudflare Workers, and Deno, and Bun, and a couple of others.
And then on the front end, Remix is basically ... You can think of it as a browser emulation layer. So Remix takes care of, in a single-page app, doing things like, obviously, the routing. What do we show on the page? How do we fetch the data? When do we fetch the data? How do we do data mutations? How does that invalidate the data? When do we need to re-fetch data? How do we load styles? How do we manage transitions between pages? Things like that. The focus really, really is on the front end, the focus is on progressive enhancement. We believe that almost to a fault. Your entire Remix app works before any JavaScript loads on the page. And then JavaScript really is just used to enhance the user experience.

Matt Arbesfeld:
I would love to maybe even take a step before Remix. And I remember using React Router, maybe it was version one, and just was incredible how quickly you could build an app just by one giant react component with a bunch of different routes in there. Maybe you could take us through the origins of that and how you ended up getting started building React Router. And then we could fast forward to where we are today.

Michael Jackson:
Absolutely. My co-founder, Ryan Florence, he was hacking around with React and I was at the same time, and we just synced up on Twitter one day oddly enough. And he was like "Oh, I've been using React I built this little router." I was like "Oh, I've been using React too and thinking about the same space, let's see what you've got." And so we just started working on it together. Golly, that was 2014, so that was the year after React came out and not a lot of people were really invested in React at that point. It seems so weird to say it now 10 years later, but in 2013 when React first came out it was poorly received, at least among a lot of the web bloggers and things that were popular at that time.
The JSX was very unfamiliar to a lot of folks and so it just didn't go over well with a lot of people. In particular, one of the guys that I really followed and admired on Twitter, I remember him sort of poking fun at div onClick. Before that time, we had done a lot of jQuery, everybody, obviously, had, and event delegation was definitely the way to do things, right? Don't put the onClick on your div put the onClick on the parent div or at the root element, and use event delegation, and then you capture your onClick. And React had this very sort of explicit way of just saying div onClick. And I remember him sort of poking fun at that and just poking fun at sort of other things about React probably not realizing that React was actually able to do the event delegation behind the scenes for you. The JSX was really just a declarative way to sort of express your intent without specifying the way that it was actually going to be implemented.
So anyway. For whatever reason React wasn't received very well but we started exploring it. I had actually hired Ryan to help me out with a project. I was working on a Y Combinator startup back in 2013, we were building a chat app. I had gotten a little bit of funding and so I was trying to build a Slack thing and so we were building it in Ember. We eventually sort of ran out of money, and I had hired Ryan to help me just sort of stand up this Ember app because he had built this thing called Ember Tools. Anyway. We ran out of money and I was looking around after that startup died, and looking around and just wondering why it had taken me so long to build what I wanted to build and why I felt like I was not happy with the result. That was what drove me to React.
It wasn't that I was smarter than everybody else at the time, I definitely wasn't, I was just like "Well, I've used the current tools and I didn't really enjoy it that much, what else you got?" And so that's why I started looking at React. So React Router, obviously, came along after that. A lot of people were using React Router and sort of building their apps in React, and the router was an important part of that. We've been building that ever since 2014 and just sort of evolving it over the years. It was actually really, really awesome, I think, preparation to build Remix.
In 2015, we formed this consulting company, which we still have today, by the way, React Training. You can find us at reacttraining.com. We basically do consulting for people who are using React. Ryan and I for years, we traveled all around the United States, all around the world, to different companies. We went to Google, and we went to Airbnb, and we went to Pinterest, and we went to Viasat, and lots of companies, and we would train them on how to use React. We would see their React code bases, we would see React router in production at all of these places. It blew my mind when I realized that netflix.com ... I don't know if it still is but at one point it was built using React Router. That's an app that I use, that my family uses. It was pretty cool to see them using the tech that we had built.
We got to see it in production and we got to hear from these people about the challenges that they were facing. How do you SSR react at scale? How do you code split at scale? What does that look like? How do you really cool, fancy page transitions like you're doing on netflix.com, transitioning to pages of video and stuff like that? So we had conversations with lots and lots and lots of different people all around the industry about real production apps that they were building with React and React Router. And I feel like that was really, really great preparation for what we ended up doing with Remix.

Matt Arbesfeld:
That makes sense. So Remix was really meant to solve all those problems you had learned over the years. Or, sort of the layer on top of React Router to solve a lot of the common patterns that you saw different companies approaching.

Michael Jackson:
Absolutely. Like I said, when we started the company in 2020, we looked around and we were hoping to find a framework that embraced progressive enhancement like I already said, that was ready to run at the edge, that used React Router, they had gotten the concept of nested routing, and we just didn't find it. So we decided that we would just go and build one ourselves because we can't be the only ones who want these things. And that's how Remix was born. And then a year later, a year into it, we actually raised money for it and we hired a team. And then a year after that, last year, Shopify approached us, they were building Hydrogen at the time. They saw a lot of good things happening with Remix, they wanted to build Hydrogen on top of Remix, and so it made sense for us to team up. So we ended up selling the company to Shopify.

Matt Arbesfeld:
Back in 2013, 2014 I was at a company called Meteor that was also in the front-end space frameworks.

Michael Jackson:
Oh, no way, you were at Meteor. That's cool.

Matt Arbesfeld:
I remember sort of we were like "Oh, should we use Reacts, React Router?" And we ended up going with a different framework which I think was the wrong choice. We built Blaze its own-

Michael Jackson:
Oh, okay.

Matt Arbesfeld:
Framework. And I think one of the challenges in front end ... I wonder how much this played into a decision to join Shopify is it's challenging to really build a business around frameworks and to capture the value from building it. Did you have a plan for monetizing Remix? Did that play into your thought process behind joining a bigger company? Or was it sort of more of just a really good fit with Shopify? How did you think through that decision?

Michael Jackson:
Well, I mean I think a little bit of both honestly. I think the fit really is a great at Shopify. They've been really excellent stewards of open-source projects for a long, long time. If you do things in Ruby you're probably familiar with a lot of the major, major contributions they've made in Ruby on the Rails space over the years. Really big-level stuff. Swapping out the whole just-in-time front end for the Ruby was a major piece of work that just landed in the most recent stable release of Ruby. But anyway. We knew that there were good open-source stewards. We knew that Shopify was interested in solving this problem because they were working on Hydrogen, the problem of how do we build great front-end apps in sort of this modern wave of frameworks that's coming out. They threw their hat into the ring and they were participating in that, and so they were trying to figure it out and hacking on the same problem space that we were.
At one point, the Hydrogen was actually built on top of React Router, right, so they were very, very much ... There was a ton of overlap. So we thought okay, we're working on the same problem, we believe in open source, we've been open source since day one, Shopify believes in open source, Shopify's great stewards of open source. It was a great, great fit there. Also, the thing that you alluded to is yeah it is tricky to figure out how to build a business, right? I think whenever you're creating value I think there's a business to be built. Whether it's a service business where you just sign contracts with customers and say, "Hey, we'll support this thing or we'll do training on this thing." I had already been in a service business with the React Training business so I wasn't super interested in building another ... I call it a consulting business, right, because you get paid for the time that you work. I was more interested in building a product business.
So we were headed in the direction of building out hosting services for Remix that you could use to host your Remix app. And there was a lot of stuff there. There was everything from the CDN layer, how do we host assets and images, and things like that to how do we host the actual app. And the more we started heading in that direction and sort of developing in that direction, the more I felt a little out of alignment with our users. Eventually what I was going to have to do is I was going to have to ask our users to come and host their stuff with us. I think that's fine if you want to do that. There are companies out there today that are asking that of their user base.
It's like I said, we had a lot of real-world experience with people who are deploying React Router apps all around the world and on all sorts of different infrastructure. On Google Cloud, and AWS, and Cloudflare, and everywhere else. It's been my experience that the most successful technologies are those that integrate well into your existing stack, that don't try and replace it. Every once in a while you take a look around your organization and you say, "This just isn't working we need a rewrite." And in that case, good luck because they're very difficult to pull off, and lots of times what you end up with is just different bugs. You fixed some bugs but now you have different ones. What we wanted to do was we wanted to fit into people's existing stack instead of force them to rewrite or replace it.
And so part of the premise of Remix is it'll run anywhere. We'll run on Google Cloud, we'll run on AWS, we'll run on Cloudflare, we'll run on Fastly, on Deno, on Bun, whatever backend you have, whatever contracts you have in place with your service providers. If you've got a contract with Microsoft Azure and that's where your company deploys stuff, we don't want that to prevent you from using Remix. We don't want to have to ask you, "Hey, come and host your stuff on Remix instead of wherever you're already hosting and what you're already familiar with." That was a core philosophy of ours is we wanted to fit into your existing stack. So there was a little bit of an incompatibility or a little bit of a misalignment I guess you could say there where I really just ... I don't want to have to ask people to switch to some hosting service that I was building.

Matt Arbesfeld:
If you make it so easy to host everywhere then not really a reason to host where ... On your guys' servers and then it creates weird incentives there in the model.

Michael Jackson:
And the big goal, right, is we want people to build better websites. I want to eliminate loading spinners online. I really want people to dig into the platform, and build really cool stuff, and change the web. And it's hard to do that if I have to have this ask of "Oh, come and deploy it with me."

Matt Arbesfeld:
Turning to Hydrogen and Remix, how do those two interact? Is Hydrogen a E-commerce specific layer on top of Remix or is it ... Will it become one thing? What's sort of the future there in how you see those fitting together?

Michael Jackson:
So we're working on Hydrogen v2 right now. I'm not specifically working on it but we communicate with that team a lot that's working on Hydrogen. The plan is that Hydrogen v2 is going to be a layer on top of Remix. You'll build Remix apps and Remix will take care of all of the server-side rendering. We'll give you the links, and the forms, and progressive enhancement, and all of the hooks that you need to build cool web apps. And then Hydrogen will be the Shopify-specific parts, right? I need to communicate with the Shopify API and need these queries, and that kind of thing is how it looks like it's shaking out. Hydrogen v2 is still a work in progress so not 100% clear exactly what's going to be available there but that's the way it looks right now.

Matt Arbesfeld:
As you think about the enhancements to Remix next year, will there be changes that best correlate to what Hydrogen needs, or do you think agnostically to Hydrogen? Or maybe there's not even a choice there. I guess how do you balance requests that might be specific to E-commerce versus ones that ... If I'm a B2B app developer or enterprise tools I might have different needs.

Michael Jackson:
Understood. I think the pairing is going to be really, really good. The needs of building a good E-commerce site ... First of all, it's fairly common, a lot of the web is E-commerce, a lot of the most profitable properties on the web are E-commerce so it's good to make Remix good for building E-commerce. But I think the things that we are going ... Or the things that they are going to help us with, or the requests that they are going to make of us are just going to help Remix be better for everybody.
I'll give you an example. We have some experience with SEO on our team. Obviously, everybody's who's building for the web does, right? And usually it boils down to put good meta tags on, put the right headers on the page, and things like that. But it turns out when you get really, really deep into SEO, there are some more things that you can do and there are some sort of more ergonomic ways to do things. Because they've been doing it for a long time, and so they can help us understand oh, what if you had an API that was more like this to help out?
Another thing that affects a lot of E-commerce sites, and a lot of sites in general, is third-party scripts. They just take forever to load and they slow down the whole experience. I mean, this is something that we, obviously, need to optimize for Shopify sites but it's going to ... If Remix has tools to help you optimize that, it's just going to help everybody who's building any site with a third-party script on it, right, no matter what the site is. So the way I see it playing out is really, really favorably for Remix users regardless of what they're building, right? We're going to get this sort of pressure from Shopify that's going to make Remix better, but Remix is not going to be Shopify-specific, right? Remix is definitely going to be sort of a general-purpose web framework that's just going to get better from that pressure.

Matt Arbesfeld:
It reminds me a lot of how React was within Facebook. And you'd see the occasional React feature that would seem very Facebook-specific, but the fact that you knew React was being deployed at such scale gave you confidence that this was solving problems at scale, many components. I think it could be very interesting to see how the Shopify scale helps Remix really develop.

Michael Jackson:
Absolutely. A very similar thing. I remember seeing a few weird things in the React codebase but they were mostly just, I think, implementation things that came from the build system, for example, that they used at Facebook, it was called Haste. And there was some Haste stuff in the React codebase but it was more stuff that you would need if you were actually working on the React codebase itself not if you were using React as a developer.

Matt Arbesfeld:
With the initial thought behind Remix helping power Hydrogen, is there thoughts of having Remix be used in other places in Shopify like sort of the click to create stuff builder or other parts that ... Or sort of the initial plan just to have it power Hydrogen?

Michael Jackson:
One of the cool things about the acquisition, the way that it happened, is the CEO Toby was very involved. He's a really cool guy. He's an engineer at heart, he used to be on Rails Core. He's a builder, and he builds stuff with Remix and he enjoyed it, building stuff with Remix. When you have that support at the highest levels of the company, it turns out it's a really positive thing. The shopify.com team right now, for example, is rewriting shopify.com with Remix so it's going to be on our main flagship website. And then there are lots of other teams at Shopify who are building things with Remix, and I think it's coming from the top down just saying, "Hey, maybe you guys should look at using Remix because it's actually a lot of fun and I think it can actually help out here and solve the problem." It initially started with Hydrogen with our sort of developer offering, but I think it's going to be very widespread at Shopify this year with lots of different teams using it.

Matt Arbesfeld:
Many of our listeners are fun developers, they have a day job, but they're maybe interested in creating open-source projects. You had React Router that led to your training company and then Remix that led to this acquisition. What sort of advice would you give to someone looking to create open-source projects and get into this ecosystem? How did you sort of approach the problem of what to build, and how to build, and how to approach starting a company in the space?

Michael Jackson:
Maybe one of the main pieces of advice that I would give is just to not be afraid to go against the grain. It's funny because you see trends in other things. You say, "Oh, food is trendy, or clothing is trendy." Development is also very trendy. For a long time it was like "Oh, everything should be static." And what was it? The Jamstack, right, was the trendy thing. And it's fine if you want to build stuff that way that's fine, I'm not here to talk bad about the Jamstack. Even though it was probably 90% of the developers that I knew were talking about, we didn't build that way. We said, "No, no, we think server rendering is actually really cool. We think HTTP caching is really cool, and running at the edge is really cool, and it can get you the same benefits as what the Jamstack is after and so we're going to go in that direction."
I mean, I think I went a little bit further back than you wanted me to. How I first came to React in the first place where I was talking about it was not popular but it was just this thing that I felt like I was willing to try because I had totally used something else and just wasn't satisfied with it. Even though it was a great community and a great framework at the time, I thought "There's got to be something else out there. There's got to be something else that's out there for me." And I think that's how you can find things that maybe other people have overlooked. It turns out when we started developing Remix, we tapped into this community that was like "Oh my gosh, thank you. Thank you so much for building this because we were starting to go crazy over here thinking that the whole front-end developer landscape is marching off and it completely ignoring progressive enhancement. Thank you so much for building Remix because we believe in progressive enhancement and now we have a tool that we can use that promotes this front and center."
Chances are if you think it's important you trust your own experience. If you think it's important there are going to be other people out there too who think that that's important. And so I think you just got to find your tribe. I've personally had to hone in on who my tribe is and what the people are who are sort of building the things the way that I believe in building things. And I've unfollowed a whole bunch of people on Twitter and followed a bunch of new ones. Just figuring that out. Finding my tribe I guess is the way to describe it. Another way you could say it is my customers or my users, right, the people that I am building for.

Matt Arbesfeld:
I appreciate the first principles thinking and not just following the herd and what the noise is about but what actually solving as developers what problems are affecting us. It makes a lot of sense.

Michael Jackson:
When you go back to first principles, I think that's how you're able to unlock new capabilities. And people are just like "Oh, wow, I didn't realize that dribbling is actually the most important part of basketball." Well, it is. When you go back to building web apps it's like "Oh, I didn't realize that HTTP and using browser standards was like ... I didn't realize how capable the browser is, it's actually really, really capable." There's a lot of stuff we've developed in the last five, six years that ... Anyway. Sorry, I could go on this for a long time.

Matt Arbesfeld:
What do you see as the next big problem to solve? Once that's solved is there web standards that will require a new approach? Or, what's next I guess that you think is a problem worth solving beyond Remix?

Michael Jackson:
I mean, I think we all have been playing around a lot with ChatGPT and looking at AI. I think there's a lot to be said about our industry changing as a whole, right? Writing code, yes, is important and I think will be for a very, very long time, or at least the ability to understand code and read it. There are some amazing developer productivity enhancements that are imminent I think with some of these tooling that's coming out right now. I saw a demo of ChatGPT that was basically finding exploits in your code base. The whole world of security auditing and software is going to change drastically which is huge, right, and it's, obviously, very important. It's going to change drastically when that stuff becomes more mainstream.
Getting into the space of writing for the web or building Remix apps, I would love to see more experimentation on that front. What is it like to code at a higher level? What is it like to just sort of describe or declare the app that I need to be built and then have high-quality helpers to sort of help me build it either right there in my editor as sort of plug-in for VS Code, or potentially I could say it in English and then the computer would help me write the code? And I'm speaking very handwavy about this because I honestly don't know a ton about it but the inkling is there. I have got this spidey sense where I'm like "Oh my gosh, this whole industry is about to totally change." I don't know if you felt that.

Matt Arbesfeld:
No. Especially with primitives like Remix under the hood, it feels like a lot could be done building on top of something like Remix to say take the E-commerce example. Show me a banner with six products that so and so and then it could generate code on top of Remix that does that. It feels like a not-so-distant future.

Michael Jackson:
Well, the machine could totally understand the framework that you're building with, right, and could look at ... And you can train it by looking at examples, apps, and blog posts, and documentation, and it's like "Oh, okay, I know how to build Remix apps let me help you out with that." And maybe have the Remix assistant, right, sitting there in your VS Code that's like "Hey, let me help you write your loader here. What a API are you talking to again? Oh, the GitHub API, I know that API. Here's the sort of function signature for the API call you need to make." It'd be really, really, really cool. I mean, TypeScript honestly is getting there, right, with the sort of IntelliSense stuff, but this could be even one level above that I think.

Matt Arbesfeld:
In a few years, robots will be writing all of our code. Instead of just Googling lots of articles, hopefully in our editors we can code even faster and more of enabling.

Michael Jackson:
I think the real power is augmenting, right? I think the real power of AI will be augmenting what humans have been sort of capable of, and helping us to achieve what we have been dreaming of. But oh gosh, who has the cycles to be able to produce that quantity of work or whatever? I think if you don't have good ideas, I think AI is not really going to help that much.

Matt Arbesfeld:
Oh, awesome. Well, really enjoyed the conversation. Thanks so much, Michael. Any last call-outs you'd like us to make on the pod or direct folks anywhere?

Michael Jackson:
If you're interested in learning more about Remix we've got our website at Remix.run. We've got a really active Discord community so hop in the Discord or hop on our GitHub. Our GitHub is Remix-run, you can find us there. You can find us on Twitter at Remix_run. We've also got a conference coming up in May, we're going to be in Salt Lake City, so if you're into hanging out with real people we'd love to see you there. You can learn more about that on our website as well.

Matt Arbesfeld:
Awesome. I hear in May you may be able to ski in Salt Lake so maybe some skiing.

Michael Jackson:
I think you should still have some skiing available. Last year I think we had some people do some mountain biking as well. We were organizing runs and stuff. Hopefully, we'll get a good group out. It was so fun last year. We just had so many cool people there. It was like I left just glowing from the conference it was just so, so fun.

Matt Arbesfeld:
Awesome. Well, thanks so much, Michael, it was a good chat.

Michael Jackson:
Thank you, Matt, take care.