Is React a Rails Competitor Yet with Michael Chan

Episode Description

Michael Chan discusses why React isn't yet a full-stack replacement, the struggles of learning modern front-end development, and the promise of ES modules.

Episode Summary

Michael Chan joins the FSJam Podcast to reflect on his React Podcast Discord community and the evolving landscape of full-stack JavaScript development. The conversation centers on a theme from his year-old discussion with Adam Wathan: React still isn't a complete replacement for traditional frameworks like Rails or Laravel because it leaves developers stranded when it comes to databases, infrastructure, and back-end integration. The hosts explore how tools like Prisma, GraphQL, and Redwood are beginning to close that gap by bundling disparate pieces together, while acknowledging the confusion that comes with so many layers of abstraction. A significant portion of the discussion focuses on the difficulty of learning React today—navigating hooks versus classes, TypeScript typing inconsistencies, and outdated documentation—leading to a broader observation that front-end development has become overwhelmingly complex compared to server-side frameworks. The episode wraps with Michael's enthusiasm for ES modules and how modern bundlers and browser support are finally making JavaScript's module system something developers can feel good about, marking a welcome departure from the painful days of RequireJS and AMD.

Chapters

00:00:00 - Introductions and the React Podcast Discord

The episode opens with introductions between the hosts and guest Michael Chan, who explains the origin of his React Podcast Discord community. It started when a listener named Mighty Joe Warren reached out wanting a space to connect with other learners, and it grew organically from there with members of the React Dallas meetup and podcast guests joining in.

Michael describes the community as a judgment-free zone where members explore technologies outside their daily work, including mob programming sessions on tools like Eleventy. Anthony highlights how the community filled a real need during a time when local meetups weren't possible, and the conversation touches on whether Michael is pivoting away from React—a charge he firmly denies while explaining his belief in building transferable, framework-agnostic critical thinking skills.

00:05:37 - Learning React from Source Maps and the "React Is Not a Rails Competitor" Origin

Christopher shares an unconventional learning technique: reading the source maps of production React applications to see how other teams solved specific problems. Michael finds this fascinating and compares it to the early days of learning HTML by viewing page source. The conversation then shifts to the origin of Michael's episode with Adam Wathan, "React Is Not a Rails Competitor," which began with a provocative tweet about Create React App only getting you halfway to a real application.

Michael explains how Create React App leaves developers at a cliff's edge—comfortable with front-end tooling but lost when it comes to databases, deployment, and infrastructure decisions. He contrasts this with Rails and Laravel, where finishing a tutorial means you've built and deployed a complete application. The gap, he argues, is real but shrinking thanks to serverless becoming more approachable and frameworks starting to bundle these concerns together.

00:13:25 - Databases, Prisma, GraphQL, and the Bundling of Full-Stack Tools

The discussion turns to how tools like Redwood are bundling front-end and back-end concerns, with Michael referencing Tom Preston-Werner's concept of bundling and unbundling. He praises Redwood's integration of Prisma as an ORM equivalent but notes the confusion that persists around databases, especially with hype-driven terminology around edge-ready and real-time solutions.

Christopher introduces the idea that every app is essentially a CMS, and Michael agrees, citing the observation that every SaaS product maps to one of the core Microsoft Office applications. The hosts discuss Airtable as a low-code tool and how Prisma relates to GraphQL, with Christopher and Anthony clarifying that Prisma handles relational databases while GraphQL serves as the broader integration layer for connecting multiple services and APIs.

00:20:26 - The Complexity Crisis in Front-End Development

Michael reflects on the growing confusion in the JavaScript ecosystem, where layers of abstraction—React, TypeScript, UI libraries, GraphQL, Prisma—stack on top of each other and make it increasingly difficult for developers to understand what each tool actually does. He contrasts this with the clean request-response boundary of server-side frameworks and expresses sympathy for developers drowning in competing priorities around performance, offline support, and type safety.

The conversation zeroes in on React's documentation problem: the homepage still shows class components, hooks are taught in courses but not reflected in official docs, and educators are left telling students to ignore parts of the official resources. Michael empathizes with the React core team while acknowledging that the mismatch between teaching materials and production codebases creates a painful learning experience, especially for newcomers expected to know both paradigms on the job.

00:28:19 - TypeScript Frustrations and the Challenge of Front-End Education

Christopher and Michael bond over the contested nature of TypeScript conventions in React, from typing children to the types-versus-interfaces debate. Michael admits he's used TypeScript for years but limits himself to typing props, finding that sufficient for his needs. The discussion broadens into why front-end tutorials struggle to be useful—Michael references the idea that development gets harder the closer you get to the user because domain-specific decisions multiply.

He argues that the industry hasn't figured out how to effectively teach front-end development because abstract component examples don't translate into real application building skills. The comparison to server-side frameworks is stark: Rails scaffolds give you end-to-end functionality out of the box, while React tutorials leave you with isolated components and no path to a finished product. Michael suggests the best approach might be repetitive practice—building hundreds of components—but acknowledges that's an exhausting and unpopular method.

00:34:17 - ES Modules, the Death of RequireJS, and Closing Thoughts

Anthony asks Michael about his upcoming talk on ECMAScript modules, and Michael expresses genuine excitement about the state of ES modules in JavaScript. He praises both static and dynamic imports, named and default exports, and how modern editors leverage these features for better developer experience. He also pushes back against the one-component-per-file ESLint rule, arguing it limits the expressiveness that modules enable.

The hosts share nostalgic war stories about RequireJS and AMD modules, recalling the pain of manually wiring up jQuery plugins and Bootstrap dependencies. Michael contrasts that era with tools like esbuild and Snowpack that treat ES modules as first-class citizens, celebrating how much faster and more capable the build tooling has become. The episode closes with Michael sharing his contact information and his flat, single-directory file structure philosophy—every module in one folder with a mix of named and default exports.

Transcript

00:00:00 - Christopher Burns

Nice to meet you, Michael.

00:00:01 - Michael Chan

Nice to meet you as well, Christopher.

00:00:13 - Anthony Campolo

All right. Welcome back to FSJam Podcast. Today we have Michael Chan. Hello, Michael.

00:00:20 - Michael Chan

Hey. What's up? Happy to be here.

00:00:22 - Anthony Campolo

Super excited to have you here. We've gotten to know each other really well over these last, I would say, maybe six months or so through the React Podcast Discord. And before we get into the episode here, why don't you talk a little bit about what the React Podcast Discord is?

00:00:38 - Michael Chan

React Podcast Discord. It's so funny. It started with Mighty Joe Warren, and he just hit me up on Twitter and he's like, hey dude, I love the podcast, but where's the community at? I want to meet people and learn together and whatnot. I was like, there's none of that. It's just me in my office talking with folks and then kind of blasting it to the universe. He's like, let's get this thing going.

I had a Discord channel and I was like, okay, you're gonna be the first one. It's just going to be you and me here for a while. He's like, no, no, no, no. Then he brought so many of his friends from the React Dallas meetup. I started inviting people just kind of in episodes, and it grew to be this really fun, little warm community of people who just wanted to learn together. And I've been taking a little bit of a break from React Podcast right now just to kind of get my bearings and identify what the future should look like for the show.

00:01:27 - Michael Chan

It's been really fun to just hang out with people. We've been learning a ton about technologies that people are interested in, like Eleventy. We've done mob jobs on Eleventy where we just jump in together and we're like, hey, we want to build this feature. How do we do it? Nobody knows. We'll figure it out together. It's just been a ton of fun stuff like that. And you've been a part of that. You've given some really great talks on Storybook and Redwood, and I love being a part of a community of learners that is not judgy about each other's work, but really open to just learning from each other, experimenting, being wrong, changing direction, knowing that it's all part of the process.

So that's a mouthful, but it's just a community of people who like to keep sharp, learn stuff that's not directly in their daily wheelhouse, and hang out with people during this time where we don't get to hang out with people very much.

00:02:16 - Anthony Campolo

Yeah, I think it was really timely because a lot of people are in this situation where they needed some sort of connection and we couldn't really have local meetups anymore. So I felt that there was a real strong need for it. A lot of it has just kind of popped up here. And yeah, I've gotten to meet a lot of really cool people. Ben Myers is a good friend that I've made, and he's going to be on the show.

It's really cool, especially because, as you say, you're kind of getting away from the React Podcast, but you've built this other community and it's in its place, which I think is probably even more valuable than just doing this kind of one-to-many broadcast. How do you kind of think about how you are positioned now? Because, as you say, this isn't really a React thing anymore. You're working on Eleventy and all this other stuff.

00:03:10 - Anthony Campolo

So do you feel like you're kind of pivoting away from identifying with React?

00:03:14 - Michael Chan

Oh, man. Just coming out the gates with the hard questions right there.

00:03:17 - Anthony Campolo

Yeah. We go deep here.

00:03:18 - Michael Chan

Yeah. Not going to let me off the hook. I love React. I think it's amazing. I think that there's still so much juice in React. And I really do think that in the event that Concurrent Mode and all that it represents ever gets shipped, it's going to be a real game changer for the way that we build applications. And I don't mean that in a judgy way, like, hey, why isn't it shipped yet? Because it's a really freaking hard problem. And I know that the React Core team wants to get it right.

There is a tension there, right? And I think a lot of people are kind of defecting from React because it feels like we're lost in the weeds. I don't know, we can talk about that. That's a big topic if we want to talk about that. But I am in no way defecting from React. I think that it is still today just the most impressive front end framework, and it enables me to do work that I just couldn't five years ago, and I am in no way stepping away from that.

00:04:13 - Michael Chan

But I think on the community side of things, I didn't want to just have a React community. That's not something I was really interested in starting. There's plenty of React communities that have been together since day one, and I think one of my goals, just as a person before I started the React Podcast, was to make sure that I was a capable developer outside of a single framework. I've seen a few at this point. I did a lot of PHP, I did a lot of Rails, did some JavaScript. I've used so many CSS frameworks I can't even tell you at this point, innumerable CSS frameworks.

I think that I want places that focus on principles, make sure that people can make that leap when they have to between this job and the other job or this technology and the other technology because they invested in critical thinking skills that really transcend framework and allow you to be able to do anything.

00:05:11 - Michael Chan

Again, at this point, it's not even just about what I want. I think it really represents the people that are there in shaping it with the technologies that they find interesting. And every day I'm learning something new, which is great for me. I love that that's my happy place. I don't know if that answered the question, but I'm not going away from React. I have always wanted to be in a community that facilitates critical thinking and broader technology understanding.

00:05:37 - Christopher Burns

One of my favorite ways currently to learn React, as someone who already knows it, is something that I think is a little bit controversial: going on to websites that are built in React and reading their, is it stack traces or is it maps?

00:05:55 - Michael Chan

Okay.

00:05:56 - Christopher Burns

Yeah, because obviously the JS code gets bundled down through Babel, but then you can still see their JSX and stuff and how their app is structured. It gives you a really good insight into how they actually built their React app.

00:06:12 - Michael Chan

Interesting. What have been the most fascinating apps that you've spun up, I guess, in that way?

00:06:19 - Christopher Burns

Sometimes it's like, I have this problem and I've seen that these also have it. Then you go on to their source code and you see that they've left the source maps open, and you're like, oh, that's how they fix that.

00:06:30 - Michael Chan

That is super cool. That's a great idea.

00:06:32 - Christopher Burns

You could say it's like thieving work, thieving code off of closed source products. As long as you don't do it to Facebook, it's probably okay.

00:06:41 - Michael Chan

Well, I mean, if they don't know how to obscure their source maps, then I guess shame on them. That's a really good idea. I mean, I've not done that with React, but that is such a great way to work. I remember doing that voraciously when I was learning HTML and CSS, and I guess when JavaScript was still in the state that you could kind of web inspect the source. So yeah, I think that's a great way to do that if they're not blocking the source maps.

00:07:07 - Christopher Burns

But the thing is, I don't even know what source maps are for. Does anyone know what that's for?

00:07:12 - Michael Chan

I think they're intended as a debugging tool. Everything gets bundled down, and then the browser kind of gets the compressed version of it. Then you can link back to the source version of it.

00:07:23 - Christopher Burns

The source map. Yeah.

00:07:25 - Michael Chan

Yeah. An example that I have actually used, I haven't really done a lot of it with JavaScript, is with Sass files, where the source is completely different from the output CSS. It allows you to jump back to the line that the actual source is on. But yeah, that's great. I might have to steal that and just be like, this is cool. What's Twitter doing with this?

00:07:48 - Christopher Burns

To be fair, I've tried it on a lot of smaller companies, but I don't know if you could do it on Twitter, maybe.

00:07:54 - Michael Chan

They're probably big enough that they have somebody dedicated to just making sure that source maps don't accidentally go out into the world.

00:08:00 - Christopher Burns

Exactly. Because it would be a pretty big security problem for a social network.

00:08:06 - Anthony Campolo

All right. So you have joined us here today at the Jam podcast to talk about a podcast that you did. Now, it's almost been exactly a year now. I kind of wanted to get you on as the year anniversary. That ended up working out really well for this podcast you did with Adam Wathan called React Is Not a Rails Competitor. If people have been listening to this show for a while, they've probably heard me mention this before. Even Dom mentioned this on his episode, and I've referenced it on other podcasts I've gone on as well, because it really was pivotal for me in terms of orienting myself in this larger world of web development and just understanding my place in it.

I had come at it from this really strong front end perspective, and there was this whole other world of people who were coming at it from a completely different perspective. So first, how did that conversation initiate originally? Because you guys both host your own podcast and you did kind of a crossover thing.

00:09:09 - Anthony Campolo

So how did that come about?

00:09:11 - Michael Chan

That's a funny story. I don't even remember exactly what the tweet was, but I tweeted something about...

00:09:17 - Anthony Campolo

Oh, it was about how Create React App is a great way to spin up a front end or something like that, you know?

00:09:23 - Michael Chan

Yeah, that's right. Create React App is a great way to make half of an application, something like that. I don't know. Every once in a while, on Saturdays, what happens is I've bottled up all my frustration for the week, and then on Saturday I'll wake up and I'll have some really salacious, hot take that gets me in trouble. Then, I don't know, it's probably something super subversive mentally going on that I'm trying to disengage from my weekend, so I'll say something stupid on Twitter.

But yes, that was the hot take. Adam has a really great eye for a story. I've always admired that about him and his show Full Stack Radio, because it seems like he's always on top of whatever upcoming trend or conversation will be. So he invited me onto the show, and I'm a fan. I invited him onto my show as well.

00:10:11 - Michael Chan

Yeah. The conversation just kind of was like, why isn't it there yet? If I was an entrepreneur building an application and a team up today, would I still reach for something like Rails or Laravel or some type of traditional web 2.0 framework? You know, it's crazy that it's only been a year. I feel like it's been longer than that. I thought you were going to say two years or a year and a half or something.

I think that what we've seen in the last year, and I'm sure we'll get to this, has filled in so many of the gaps. I think that serverless is really finally becoming approachable for a lot of people. That's been a seven-year or more journey. A lot of those things really weren't ready yet. And doing education, I know that one of the biggest questions that people have is like, okay, I think that I understand everything about React, except now I have this Create React App and I don't know what to do next.

00:11:18 - Michael Chan

Do I connect it to Firebase? What is a database? Do I need a real-time database? What's a relational database? NoSQL? How do I connect it to a NoSQL database? Create React App just shuttles you up this cliff, right? You're at the highest point of front end web technology and then it just leaves you right at the precipice over this wide expanse of ocean. And you're like, do I jump off or just turn back around and learn the front end stack from scratch again? So I don't know, that's a tirade. I'm sure we could move on from that. But yeah, I think that's kind of the idea of like, hey, we've only gotten halfway there so far.

That, I think, is a frustrating experience for a lot of people who want to take what they've learned and actually transition that into a product versus education. Rails and Laravel are significantly different. By the time you finish a book, you've built an application and deployed it to the world, and there's fewer questions about like, okay, well, is AWS the best infrastructure? Or should I learn Azure? It's just like, hey, it's a Postgres database. You can put it wherever you want. But we put it on Heroku because it's easy and free. It's a Postgres database that you manage. We have not gotten there yet. Not yet. It's not that it's impossible, but we haven't really gotten there yet.

00:12:39 - Anthony Campolo

Yeah. That's awesome. And it's great to hear you try and make the pitch because you have no idea how many times I told that exact same thing on my own podcast, trying to explain what this whole thing is and why it's important. I'm really glad you hit on all the database stuff because that's usually one of the first things we talk about. There's this whole world of databases that is super consequential to your app and that Create React App, as you say, has absolutely no opinions about.

By giving you a lot of those opinions around the database, that gets you a huge chunk of the way there, but you can make opinions about the database that doesn't necessarily lock you in. Also, it's about making an opinionated choice, but still one that you can opt out of, or swap out, or that kind of thing.

00:13:25 - Michael Chan

I had an episode of React Podcast with Tom Preston-Werner, who you're great friends with. He used terms that I've not actually heard before, but I was familiar with the concept, the idea of bundling and unbundling. He was using that to describe Redwood. They're bundling these disparate pieces of front end architecture and infrastructure together to be able to make applications.

I think that that is great, and actually more so because they're integrating the Prisma side of it, which is roughly equivalent to an ORM from Rails. So all of these things are starting to come together. There is still that very confusing piece left of what the database actually is under the hood. And that is such a hard thing because there's so much hype about new wave databases, being edge-ready, and a bunch of killer terms that I'm sure make all these companies a ton of money in their VC pitch decks, but are so confusing to people like us who just want to make something.

00:14:22 - Michael Chan

So that part of it is still a little bit frustrating, but I feel like Redwood has done, as far as I can tell, the best job so far of making these things feel like a cohesive framework.

00:14:32 - Christopher Burns

One of the things that I always wonder and I bring it up a lot: the concept of everything is just a CMS. To a certain extent, any type of database work you do, you're just a fancy CMS at the end of the day. How many React applications could you bundle down to? It's a CMS for X.

00:14:54 - Michael Chan

All of them, right? At the end of the day you have an Excel spreadsheet and a cute UI on top of it. That is web development. I'd be hard-pressed to find a productive example of anything that we do that isn't effectively just a cute front for an Excel document. There was a tweet going around maybe a couple years ago, the notion of every SaaS being one of the four primary Microsoft Office products, and knowing which one you are is pretty key to focusing on your market.

00:15:30 - Anthony Campolo

Word, PowerPoint, Excel, and Outlook. Would that be the fourth one?

00:15:34 - Michael Chan

Yeah, probably. Yeah, I think so. There may be more, but that's the idea. Word, PowerPoint, and Excel being pretty much the key ones, but yeah, Outlook too. You look at Superhuman, there's a huge market for email clients, right, which is Outlook, and products like Basecamp and whatnot, or fancy Word. Anything that ever shows a list of things or people is Excel. And it's nuts.

00:15:59 - Anthony Campolo

There are people who actually make websites now with Airtable. They take Airtable and then they use that as a headless CMS. And to Chris's point, then just import the cells and make that your HTML or whatever. I don't know how they actually do it, how they do the ETL. I suppose you could do it a bunch of ways.

00:16:19 - Michael Chan

I have done that and it's amazing. It's great. Every year for my partner's birthday, I create for her a website, and I let people kind of leave nice notes, send in a picture that's on their phone of her, whatever. And I always try to do it in a technology that I'm uncomfortable with or unfamiliar with as a way of learning. It's a fun kind of annual or semiannual project.

This last time I did it in Airtable. I was going to use something else, but Airtable is so good. You set up your database, you put your fields in there, and then you literally just click a button and it's like, I want a form for this that represents this data. And I want a list view, like a list and show view. So people can see the list, click in something, and then see that thing.

00:17:04 - Michael Chan

So I just literally pushed two buttons on Airtable and the thing was done for me. I shared a link. People could write stuff in, put images in. It's wild. It's super fun stuff. They're on the low-code movement for sure.

00:17:19 - Christopher Burns

I remember it must have been a year ago now, when everybody was talking in Gatsby about how to use an Excel sheet as your CMS. So, Google "Excel sheet as your CMS." It's just getting to a point where everything is just a CMS, and that's what I really like about Prisma. It just makes databases like a CMS. I never have to worry about SQL or anything like that. Prisma is the way to go.

00:17:50 - Michael Chan

It is interesting. So with Prisma, does that become your integration layer between... So I've not actually used Prisma save for the tutorial in Redwood. Does that become kind of your integration layer between multiple services? So if you wanted to connect your Google Sheets, but then also you have data from an Airtable and all that kind of stuff, if you wanted to query all of that in one place, you would do that with Prisma?

00:18:15 - Christopher Burns

Not necessarily at all, really. It's more just to your database.

00:18:20 - Michael Chan

Okay. Got it.

00:18:21 - Christopher Burns

You have a Postgres database. You have a model. Prisma 2 is going to give you a functional way to basically pull and push data to your database. Prisma 1 was through GraphQL. Sad, dead hero. Prisma 2 doesn't use it. It's more programmatic. I think that's the right word. But the next move in the industry is GraphQL. GraphQL is not fully there, and I'm sure Anthony knows how much GraphQL has still got to grow.

00:18:56 - Anthony Campolo

GraphQL is, to me, just like this is where all the interesting stuff is happening. But this doesn't really have anything to do with the database, I don't think. It doesn't, because it gives you a way to talk to your database. But like you were saying, Chris, Prisma doesn't do Airtable. Prisma only does relational databases. So if you want to mediate between all these other services, that's where GraphQL is actually super interesting. And that's why I think even though Prisma was once doing GraphQL stuff, Redwood has now taken on GraphQL stuff themselves. And so they're going to become a more swappable piece than I think Prisma will be, but it's kind of going to depend on how all these things develop over the years.

00:19:38 - Christopher Burns

And there are two models to GraphQL that I think is very much in the industry right now. There's the Gatsby model, where you just put in all the API sources you want through plugins like an Airtable plugin or a Contentful plugin. Or there's the more managed solution of GraphQL. For example, in my company we talk to Stripe through a custom GraphQL interface. We talk to Prisma through a custom GraphQL interface. Then it's almost bleeding edge technology where you can turn any REST client into a GraphQL client. You can even turn a SOAP API into GraphQL. With GraphQL Mesh, it's pretty crazy.

00:20:26 - Michael Chan

That is really the magic of GraphQL, right? I was confusing it earlier with what Prisma is designed for, and I think that's maybe part of the problem in this full stack, can we replace these full stack frameworks with React yet? I think part of the problem still is that confusion, where these pieces are becoming so nuanced that it's like, I don't even know what they do anymore. From Prisma 1, the separation of GraphQL and kind of Prisma 2, what does that mean for me? Why do I care? I just want data. And now I have two layers of abstraction between me and my database. At what point do I just burn it all down and just do SQL queries from React server components and that's it?

00:21:13 - Christopher Burns

I've been doing React for like four or five years now, but I'm still like, what's concurrent mode? Give me a use case for concurrent mode. People have that turned on right now. What do they do with it? Just don't know. Just never got to that point yet. But that's the thing about React. You can skim the surface so fast and get up and going. But then to learn all the hooks and how to use all the hooks properly in the right contexts, that's going to take you years.

00:21:42 - Michael Chan

It's challenging, right? Because I think front end frameworks have not really adapted from the early marketing pitches. All of the front end framework front pages, look at Rails, look at Laravel, look at the front end pages of all of these things, they are communicating the value of what you're going to get by using the framework at a high degree of abstraction.

Look at React. Look at Angular. Look at Ember. The front page is them showing you the three easiest possible components that you could possibly build in a front end framework ever. Things that you could have done in jQuery and maybe four more lines of code. They have not evolved past that point seven years ago where they were all just pitching on, ours is the easiest framework to set up. I think that's bullshit. In the past seven years, we should have moved away from that to, hey, building applications is hard. This is going to help you in these high-level ways, and you're going to have to read the docs to figure out how to do it.

00:22:38 - Michael Chan

Oh, man. Now I'm in it. So this is where I get in trouble time.

00:22:48 - Anthony Campolo

Read the docs is one of my favorite rants of all time.

00:22:53 - Christopher Burns

Wait, I've just got a side thing to say. You say the React website is like, here's how to do it, easy. They're still using React components and classes on their home page.

00:23:06 - Michael Chan

Yeah, it's true. It's true.

00:23:07 - Christopher Burns

On the React home page is React classes. Who uses classes these days?

00:23:13 - Michael Chan

Yeah, it's why, and I don't want to discount the incredible work that's going on behind the scenes because I know that they've been doing so much user research and testing into docs 2.0. However, this is where front end is super weird and confusing for people. Am I supposed to use hooks or am I supposed to use classes?

This has been kind of a refrain from educators for a really long time, of I'm teaching only hooks because I feel like that's what we're supposed to be doing. But then everybody goes to the docs and it's like, wait, the front page of the docs says that I'm supposed to do this other thing. Don't believe the docs, I guess, except for when you're supposed to actually learn something and then go to the docs, but only go to this subset of the docs. And again, there's some amazing stuff happening. However, I think it's kind of a bad time right now if you want to be a front end developer.

00:24:02 - Anthony Campolo

I love this. I live this in my bootcamps. So what you're saying, I can testify to the truth of it to a very, very strong degree. We learned hooks first. Our first exposure to React, day one, was useState. So it's going to be your mental model going into it. And I think that's great. I think that is the right choice because the React community seems to have collectively decided that hooks is the way to go, and I think you agree with that as well.

But the problem then becomes, okay, you learn that, then they're like, by the way, here's this entirely different way to do it. And this is actually going to be the vast majority of the legacy code you're going to work with. And now you have to understand, as you're learning it, how these two things relate to each other in highly subtle and non-obvious ways. And then instead of having this hook thing that you're just kind of confused but can work with, you have these two things and you don't understand anything.

00:24:58 - Michael Chan

I waffle a little bit because I don't want to... Also, I've said a number of curse words at this point. Is that fine in this show? Should I stop?

00:25:07 - Anthony Campolo

Yeah, no. You're good. You can swear. I'll probably edit them out. But I like the passion, so feel free to let them fly.

00:25:13 - Michael Chan

Okay. I can get 90% of the passion without the swearing. I feel like I straddle this line a lot where I am such a huge super fan of everybody on the React Core team. The work they're doing is groundbreaking. It has been groundbreaking since day one, and I am just in love with what they're doing, the way that they're doing it, and the way that they're managing it. I'm so impressed by it daily.

But at the same time, React exceeded all of our expectations for adoption, and I have a huge amount of compassion for how freaking difficult it is for a new React developer to get anything done. I think that React, as it stands today, is a very difficult framework to learn because of exactly what you said. Yeah, you go through a course and you learn hooks, but you're going to join an app, a percentage of the code base is not going to be in hooks, and you're going to have to learn all of those boundaries. You're going to have to learn classes just to handle those use cases for things that you don't even understand the boundaries of why it's done in a class and not a hook anyway.

00:26:22 - Michael Chan

And it sounds like, okay, well, that's part of a progressive journey of being a React developer, but it's really not. If you're pitching yourself as a React developer, you're expected to know these things. It's very difficult. I have a lot of empathy for people trying to figure it out now because you really have to know all of the APIs in order to have a job writing React.

00:26:41 - Christopher Burns

The crossover is so strong. For example, we move from classes to what are they, functional components? Or are they anonymous functions that, in TypeScript, return React elements? I don't know. Even Kent C. Dodds, the legend, wrote a blog post on how to write a React component in TypeScript in the last two weeks. And this is 2021.

00:27:10 - Michael Chan

And it was deeply contested to read the thread. Everyone was like, that's not how I should do it. Nobody agrees. It's a big challenge. And yeah, like you said, the API differences. React isn't built with TypeScript. Those types aren't maintained by React. They're maintained on DefinitelyTyped, and so a lot of the language is legacy language. For a while it was like SFC was the type for components, and now React has, I think, moved the language, at least on the docs, to be component is a function, and then class component is the class version of the component with that legacy API. But yeah, you add TypeScript onto there and it's like the mess is even worse.

00:27:50 - Christopher Burns

Now please someone tell me the correct type for child. I don't know.

00:27:57 - Michael Chan

Does anybody, with the exception of React, which I jumped on early... I am a late adopter and I've used TypeScript for probably four years now in production code, but I literally only use it to type props. I needed something to do that job for me and that's it. I just have interfaces that type the props and that's been great for me.

00:28:19 - Christopher Burns

But let's not get started on TypeScript. Why write types when it's obviously interfaces? I don't know, all these things are highly contested, but I think my favorite experience is when you go, I'm going to learn testing. Oh, one plus one equals two. That's your first test, and now do everything yourself.

00:28:40 - Michael Chan

That's the same thing with React. Here's a greeting component. It's like, okay. It's tough, right? Because I'm sure that you experienced this doing the Redwood docs, Anthony. Actually, I'm going to lead this with something that I don't even know if I've actually said this. David Heinemeier Hansson of Rails and Basecamp fame, there was an interview I listened to right around the Node.js and io.js split. He was saying that he does not envy the responsibility that everyone has in trying to bring those things back together.

I've never been able to find this interview, so I think it might be part of a fever dream and I'm just attributing it to DHH. But he also said something that I did not put together: the closer you get to the user, the harder development becomes, because so much of it is the domain that your product is solving for the customer.

00:29:35 - Michael Chan

We talked earlier about like what? Everything's basically one of the Word products. But how does it differentiate? It's that user experience, how you get from point A to point B, the subset of customers that you've decided to service, their specific paths of doing a task. And the closer you get to the user, the more decisions you have to make as a developer and have to live by. You spin up a new Rails app and it's like they put the lists in tables. The notion of front end and React is just hilarious. It literally looks like an Excel spreadsheet when you Rails new. I just remember that really sticking with me, that the closer you get to the user, the more difficult these decisions become.

I think we experience that pain in how difficult it is to write a useful front end tutorial, because we have to tell people things in the abstract, like, oh, you can build a component like this, as opposed to, you can add a new record for a user end to end with this.

00:30:31 - Michael Chan

It's a totally different way of communicating to people. I think that as an industry, we just haven't evolved yet to how to communicate to people effectively in that way. I don't even know what it looks like because, at the end of the day, people don't like strength training. I think the best way to probably learn front end development is to build 100 components and wake up and, before you start your day, start with some challenge like, okay, how would I build this component? Do it and be like, okay, cool. That's one more thing that I know how to do. That's exhausting. We don't take that approach.

00:31:04 - Anthony Campolo

Yeah, I agree that as you get closer and closer to the users, it gets harder and harder because you're increasing the space of potential edge cases as well, and differences of not only experience and knowledge, but even access to equipment and tech and all this sort of stuff. And as you get further and further out, you have to, at a certain point, make decisions for the largest possible use case and just say, I can't cover every possible use case. You can never do it. So it becomes a kind of mindset shift in that respect.

00:31:42 - Michael Chan

Yeah. And Christopher, like what you were talking about, the layers of integration, right? You have React and then you have TypeScript on top of that. The API that TypeScript provides to type the React components, which isn't bundled together, has different language, which you have to interpret as a developer. You have, I don't know, maybe you use some off-the-shelf UI library and you use some off-the-shelf React querying system. Then that hits GraphQL, but that GraphQL is building queries through Prisma. The graphs of technologies that you have to be aware of is becoming so huge.

We haven't even talked about the complexity of offline mode and web workers and all of these things just don't exist for that server-side CMS. You're going to send a request, the server is going to do some stuff, and it's going to send a response back. That boundary is so freaking clean.

00:32:31 - Michael Chan

It's just delightful, right? And yeah, you can't do stuff offline, but you gained simplicity for it. Right now it just feels like we're kind of in the muck because everyone is telling front end developers this is the most important thing. Speed is the most important thing. Rendering performance is the most important thing. Layout thrashing is the most important thing. First contentful paint, offline, web workers, use types, make everything better for your users. It's like there's a crowd of people just behind you every time.

You're just trying to put someone's middle name inside of a form field. It just seems like there's a crowd of people yelling at you. It's a tough space to be.

00:33:12 - Christopher Burns

I still feel like I've low-level PTSD from when your web worker just decides to stop rendering the website completely and you're like, why are you doing that? And he's like, I don't know. You deleted the content that I'm trying to render. The thing is, you're like, oh yeah, web workers. They're like this futuristic thing. But even, I think it was on Front End Happy Hour, someone who works at Netflix trying to wrangle the service worker at Netflix is like, your worst fear is just like your service worker just blocking out 20% of the users forever, because that's how browsers work.

00:33:55 - Michael Chan

Yeah, I mean, it's really scary. And I always like to say to lean on the browsers as much as you can. But the more you do that, you have these edge cases where it's like now the browser subtly changed and you can't update something for a good chunk of your users for some indiscernible reason, and you're not really sure how to do it. That's a bad day at work, a really bad day.

00:34:17 - Anthony Campolo

One topic I'd like to get your take on before we close out here is ESM, ECMAScript modules. I know you're going to be giving a talk about this soon, so you've been doing a little bit of research on these. So I'd be curious to get your kind of high level views on why these are important and what they're going to kind of change in the JavaScript world.

00:34:39 - Michael Chan

I'm a huge fan of the way ES modules, JavaScript modules, whatever we want to call them, the way that they work. Huge, huge, huge fan. I'm grateful to everyone who is involved in making those what they are. JavaScript is not an easy language to create new features in, and dang, I feel like ES modules are just fire. I love them. I haven't used modules in many other languages, so I'm just going to say that my experience has mostly been in Ruby.

I think the thing that I really like about ES modules, they feel very browser-y, right? You have the static imports, but you also have the dynamic imports, the named and default exports. There are a lot of features that you can utilize there for some really nice expressiveness in code. I think a lot of times we underutilize a lot of those features. I think it's getting better.

But I think that especially in React, I think there's this one ESLint rule that I've always raged against, the one component per file, which I think is just absolutely harmful because there's so many reasons to put multiple components in a single file. I mean, especially when you think about context in React. I don't even know how you would make a useful context module without having multiple exports from that module. But anyway, I digress. I think that there's a lot of features there that can be used to make your code more discernible, have it communicate better, especially with editors like VS Code, which use the TypeScript engine under the hood and kind of understand all of these relationships.

Yes, module bundlers are getting better at tree shaking. Every six months it seems like there's huge advancements in bundling speed, tree shaking. The browsers are getting better, faster support for them. I'm just really excited. I think it's been a really long time coming. And the API is really good. The fact that we're seeing bundlers that are starting to get a little bit more out of the way and really using ES modules as first-class citizens instead of one of the many ways that you can bundle modules is exciting to see.

00:36:45 - Michael Chan

I think it'll be really cool to start just using them in the browser. There are still warts, but seeing all the work that's happening, that esbuild is just wild to see, like how much faster that is than all of our traditional build steps in the past that have gotten kind of unruly and disappointing. I guess that's a long way to say that I'm kind of excited about all of it. Seeing that be realized in the browser and seeing the browser become a more capable platform that we can target directly is awesome.

00:37:15 - Christopher Burns

Did you ever use RequireJS? That brings me some bad times. Downloading people's jQuery files, putting them into RequireJS. And then just as I'm thinking about that, like that was really bad. You now have the future where you could just import a URL into things like Snowpack. How have times changed?

00:37:42 - Michael Chan

Yeah. It's really amazing. Are you talking about your pain in require? I remember very specifically just spending weeks of my life with that target logo. Is that what the logo was? There was a target and it was just looming over me. I just could not get out from under the weight of this target. I was trying to read these APIs and understand what the hell I was trying to do. I knew that there were way smarter people than me, that this was easy for. But I am very grateful that I don't have projects that use that anymore because it was very difficult as a newcomer to front end JavaScript to understand.

00:38:19 - Christopher Burns

It was especially when you're using PHP. So using a bit of PHP, bit of RequireJS, to get your Popper and I don't know what else. Like Bootstrap, Popper.

00:38:32 - Michael Chan

That's true. Yeah. Bootstrap JavaScript. Yeah, yeah, yeah.

00:38:35 - Christopher Burns

Yeah. Leaflet for maps before Google Maps was pretty good. I can't remember many more off the top of my head. Oh, definitely a carousel. For one, you can't forget the carousels.

00:38:47 - Michael Chan

Had to have carousel. Yeah. Slick slider. Yeah. No, I was just always, just put it on the window. It's fine. It's gonna be fine. Live to fight another day.

00:38:57 - Christopher Burns

And now we're on the other side. AMD. Is it AMD? Modules are a thing of the past?

00:39:03 - Michael Chan

Yeah, that was like a module protocol that RequireJS used right before CommonJS.

00:39:10 - Anthony Campolo

AMD was asynchronous modules. Something like that. So it was kind of split between, there was the browser ones and there was kind of the nerdy ones. So AMD was the browser one. I think that's the one that kind of has ended up mostly morphing into, I think, what we have now. I could be wrong about that, but I think that was kind of the story. These are all things we can include in the show notes for people who want to go down these rabbit holes.

We're all about out of time here. So thank you so much, Michael, for being here. I've really enjoyed getting to know you through the Discord that we've been on, and I've really enjoyed getting to present there and getting to meet all the people there. So thanks for putting it together, and I look forward to continuing to participate and contribute.

00:39:51 - Michael Chan

Yeah. Me too, me too.

00:39:53 - Christopher Burns

I guess the final question, the rhetorical question to end the episode, would be, how do you lay out your file structure in React?

00:40:04 - Michael Chan

I have a modules directory, and I put every single module in there. They all have a mix of named and default exports. I don't use any globals in there, and it's flat. It's just a big ass directory of modules. I don't care if they're just JavaScript or React or whatever. And just in that directory, boom.

00:40:39 - Anthony Campolo

Could you also include your contact info so people can get in touch with you?

00:40:44 - Michael Chan

Oh, yeah. I am Chan-tastic most places. My last name, Chan-tastic. And yeah, so I'm on Twitter. I mean, I have an Instagram account, but it's just silly one-line drawings of things that my kids say. But then on YouTube, I've been doing some stuff. So YouTube, C Chan-tastic. If you want to join our Discord, it's events. I know it's kind of like a long URL. And then yeah, I'm continuing to develop courses, as you mentioned, Anthony. I'm doing a course on ES modules right now at Lunch Dev. Yeah, that's kind of me on the internet right now.

00:41:23 - Christopher Burns

Thank you for your time.

00:41:24 - Anthony Campolo

Thanks a lot. Catch you guys next time.

00:41:26 - Michael Chan

Thanks, guys.

00:41:58 - Anthony Campolo

Oh, man, I love it. I love when people get on here and rant.

00:42:02 - Michael Chan

I really hope that this doesn't get me in trouble, but let it be.