Morten Barklund: 0:00

While react is great on its own. It's it's it doesn't actually get you that far, you need to, uh, use the ecosystem that exists around react to.

Fernando Doglio: 0:31

You're listening to episode number 13 of 20 minute JavaScript where we discuss everything JavaScript related. This episode is hosted by OpenReplay, an open-source session replay suite for developers. Stop guessing your production issues, and checkout openreplay.com I'm Fernando Doglio, your host and podcasting Jedi, maybe? For the next 20 or so minutes. And today we're going to be talking about scaling react applications, whatever that means with a very special guest. Morten Barklund he's a web developer and author of "React Quickly". So Morten welcome. Thank you for being here and please introduce yourself.

Morten Barklund: 1:05

Hi Fernando. I hope you're doing well. Um, so I am a Morten I am a Danish web developer currently located in the us. Uh, I work as a freelance web developer. And I work a fully remote at an agency called X team, which is a pretty large collection of, uh, of developers from, from throughout the world. I think it's, uh, just over 700 people working for that company right now. I'm currently working, uh, for on a Google funded project, which is an open source application written, uh, fully in react. So that's a pretty great expense.

Fernando Doglio: 1:42

Alright, interesting. And, um, I think it's pretty on point. We will all going to be talking about today because we're going to be discussing, uh, scaling real complications and what that actually means for a team, for the project and, and, uh, for, uh, for everything essentially. Cause, um, uh, in particular I'm not a big front end guy. I've done some front end but mostly backend. Uh, so the concept of scaling the front end to me is, uh, a bit strange let's put it that way. So I wanna, um, uh, I'm sure. And I'm sure a lot of people also feel that way. Uh, so I wanna make sure that. We covered that. And we explain what you mean when you say, uh, when you are talking about scaling application. So would you please, uh, explain what you mean by, uh, when you, when you think about, or when you plan on scaling our react application?

Morten Barklund: 2:36

Uh, yes. So, uh, when you come from a backend, uh, framework scaling is, is a different beast. It's often about handling many users at the same time and. And having a large database, things like that, but that is not, of course not what we're talking about here. We're talking about, this is probably about scaling software architecture in general. So what happens when, when you grow it from, uh, from five files to 500 files and from one developer to ten to a hundred developers. Um, and what happens when you, when you are expanding your small hobby project into a business, when, when should you change your, uh, your, uh, ideas and your patterns that you're using in your application? And they can also just when you're prototyping things out, or you might have just a small section of your application that starts out with a very few components and it might evolve at some point and you can't just keep uh, adding on to the same thing. At some point you need to fundamentally change what you're building. You need to make sure that it scales. But there are also other concerns which includes, um, just general architecture flow of data. You can also be just a resource usage. You might have an app, a component of video display component, for instance, that works great on its own. But when you include it into a large website, it suddenly starts hugging resources or, uh, things are, are starting to be choppy because it takes up too much, uh, too much stuff that the rest of the application needs.

Fernando Doglio: 4:12

Okay. Interesting. And before getting to the details, so that in the context of react in particular, do you think that there is a limit to how much that it can scale following what you're saying about architectural patterns essentially? Is there a limit to, I don't know the number of files that are developers the size of the team or the team working on it, or are there patterns that allow you to scale indefinitely within the realm of reality?

Morten Barklund: 4:38

If you're using just react and nothing but like pure react. Yes. Then there's definitely a limit because it's, it's great for smaller projects. But when you scale, uh, to, to larger projects, you need to use a lot more external libraries and tools to make sure that your whole application at your whole workflow works a lot better. Th this goes for anything from the actual website performance, but also, uh, how, how the team works. You need to have a testing in place. You need to have a lot, a lot more external tools in place. So while react is great on its own, it's, it's it doesn't actually get you that far. You need to use the ecosystem that exists around react to, to fully, uh, to fully use it in large applications.

Fernando Doglio: 5:22

All right. But we're talking about like a bundler and so on or are we talking about like, uh, Uh, something on top of react itself.

Morten Barklund: 5:30

So for, for, for the website is specifically, uh, it's uh, there are some great, uh, react frameworks that make it a lot easier to work with at scale things like next or remix that are, uh, that are great tools for, uh, for working with it, uh, as a website. But of course, if you're building a web application, it's a slightly different, uh, beast, but, um, for websites, yeah, definitely. There are some, some frameworks built on top of react that you probably want to use.

Fernando Doglio: 5:57

All right. Have you tried already a remix? Uh, everyone seems to be talking about it. What, what, what are your thoughts on it?

Morten Barklund: 6:04

Uh, I I'm a big fan of it. It, it does, it, it is an opinionated framework, so that will probably, uh, uh, rub some people the wrong way, because. They might have different opinions than what this framework does. Right. That's but that's how it is with a opinionated frameworks. But if you, if you like what they're doing, then it's definitely a really, really good tool. It's it? It, it allows you to use react on a, on a different level, in a different mindset. So you're not thinking about. Uh, the, the website in the same way, you're thinking about your routes in a different way. You're thinking about data load in a different way. Uh, but yes, I have used it and I will actually also be using it in the book. So there will be some projects in remix.

Fernando Doglio: 6:48

Awesome. All right. Okay. Going back to the topic. So you, you mentioned something interesting. You said that even if you have a scaling, uh, application in general architecture that allows you to grow. You might still have, uh, or include individual components that may screw everything up. How is that possible and what kind of problems have you encountered and what can people do to avoid those, those issues?

Morten Barklund: 7:15

So, one of the, one of the biggest issues when you are, when you're creating a react application at scale is minimizing re renders because. React components. They rerender for a number of reasons. And if you don't fully understand those reasons, you might have components that rerender when they don't have to. And that's, that's not a big problem if you just have five or 10 components, but when you have 500 components, it's a big problem. If a hundred of them, they rerender all the time for no good reason. So minimizing rerenders does is one of the most important things when you're building larger react application. And react is pretty good at it. Pretty good at informing you about how things are working. There's also a lot of secret magic going on behind the scenes. So it, it can be a bit tricky to figure out exactly what happens, where, and for what reason.

Fernando Doglio: 8:06

All right. And do you think that using something like Next or Remix makes the job easier, uh, in that regard or since. It works as an extra layer of abstraction. If you will, on top of react, would it make it even harder to figure those, you know, uh, those tricks out and, and try to solve those rerenders?

Morten Barklund: 8:28

Uh, yes and no. So for one thing, uh, uh, server-side render it does not really, uh, change how your component rerender. So it, it, so. Understanding component rerenders is kind of independent of the framework, but it does add the complexity that it will also render a one time on the server. And you need to make sure that the server render is identical to the front end first-time render. So that adds some complexity because of rehydration. Uh, so, so you need to make sure that it rehydrates properly or at least that you are making sure that it renders empty the first time. If it, if you can't render it on the server, the first time.

Fernando Doglio: 9:09

All right. Uh, okay. So going back to browser, what are kind of the, usual gotchas that, that you, as a front end developer, want to look out for when you're creating a, uh, or writing your component, uh, that you want to make sure that, you know, you're not constantly rerendering, like you mentioned.

Morten Barklund: 9:28

So that's, that's a. I think that's like the main thing you have to learn as a react developer. So there are no, there are no quick takeaways, uh, for this because that's kind of your whole job that is really there components that render only when they have to render. And that's kind of what you spend your next, uh, many years learning how to do. Thinking about, uh, thinking about memoization is of course a big part of it, but also just creating the correct component architecture in the first place, thinking about data flow, thinking about events and callbacks and async programming, and there's a lot of components that go into it. It's, it's, it's kind of your main job is to, to, to render the right things at the right time.

Fernando Doglio: 10:13

Okay. All right. Fair enough. And at a project, at a project level, what are some of the problems that you've seen preventing projects from scaling? I'm assuming it has to do with the project's internal structure and the architecture, but kind of, um, What are, if let's look at it the other way, instead of looking at the pitfalls, let's look at, let's look at it. Uh, the, uh, the good practice, what are some of the good practices that you will recommend or even implement in your own projects? If you know that, uh, what you're building needs will need to scale up to a big team, or even to a bigger project, uh, with many, many components.

Morten Barklund: 10:58

So, first of all, a react project is like any other software or development projects. So things that would make any project fail would of course also make a react project fail. So you need, you need a proper architecture, you need good management, you need, uh, a good workflow, et cetera, all those things, but for, for front-end and JavaScript, uh, projects in particular, I think things like coding standards are important because. It's much more loose. People would do things in many more different ways, and there can be a stupid discussions, but I can speak from personal experience and say that my life became so much easier when I embraced a tool like prettier, which does code formatting for the entire team in the exact same way. And I never have to worry about whether this thing goes on a new line or not. It's just made everyone's life so much easier. You just eliminate a lot of the, uh, a lot of the conversation, a lot of the, uh, the friction between team members. Another important part is that automated testing. It's, it's, it's really important, uh, that you include this on different levels. So, uh, I, I prefer to have unit tests for the more hardcore calculations. If you have a state reducers, or if you have a components that. That does some pretty complicated logic. It's really good to have unit tests for those. And if you have UI libraries is really nice to have visual tests for those, you can have some kind of a, of a screenshot testing or tool like storybook, where you can do a visual testing of libraries, which is a nice thing to have. And then you just integration, test everything else. So you know that your components, they work together in the correct way. And if someone changes something. Then it'll it'll fail the correct, uh, correct things.

Fernando Doglio: 12:48

All right. And, uh, well, you mentioned prettier there, but do you have any other preferred tools regarding automated testing, integration testing that you would usually pick for your own projects?

Morten Barklund: 13:00

I think that depends on personal experience. I have tools that I would go for, but that's because I know them and they're probably just as good as as many other tools. Um, but the whole, uh, the whole, uh, Testing library, a suite of tools where we have react testing library. This is a really nice suite that I personally prefer for, for integration testing, but there could be other tools for, uh, for other parts of an application.

Fernando Doglio: 13:28

Alright, perfect. Um, say that you're, you're building an MVP. Um, Uh, pretty tight schedule MVP that, you know, you're going to have to grow eventually and refactor into something bigger. Do you have suggestions for teams like that? Or going through that process, the, to like, look ahead of what's coming. So without losing a lot of time, you know, created a big architecture for something that right now doesn't need it. But that it'll eventually need to grow. So like key actions or key patterns, if you will, to pave the way into something bigger, do you have kind of those kinds of suggestions?

Morten Barklund: 14:09

So 4, 4, 4 compose for most components, I would say that. It's a good idea too, to not overthink them. And I, I personally, uh, ascribe a lot to the principle of YAGNI which is you ain't gonna need it. So don't, don't build something that you don't know for sure that you are going to need. So for visual components, I would just stick to exactly what I need right now and not prematurely. Try to optimize. But for the overall architecture, there definitely ideas you can start bringing in first and foremost would be things like data flow and the API structure. So, if you know that you're going to have a global state start thinking about how you would handle that state throughout your project and think about how, how the, uh, the different parts of the project would be, uh, communicating with each other. I think that you can, you can scale that out from the start, even though it'll be trivial and there'll be very trivial connections between different parts. It's, it's a good idea to just start fleshing them out and schedule and organizing them in different, in different sections.

Fernando Doglio: 15:12

All right. Interesting. And regarding the state in particular, what would be either the tool or, uh, let's, let's call it the, uh, the way you would structure that so that, you know, it'll grow. Would you like stay within the, the use context or, you know, hook or would you go into a third-party library? And if you will, which one would it be? Would it be like a Redux, or Redux Toolkit or would you go to something, something more lightweight? What would be your pick there?

Morten Barklund: 15:44

So I'm a big, uh, big fan of, uh, of context and, and use context in general. And I would always use that. Uh, there's actually a, a tiny library called use context selector. Uh, which adds to the use context everything that Redux toolkit does. So it, so it, so all of the optimizations that you get with Redux, you can get with this tiny library and you can build everything with context and just use context selector. And you're pretty much there. Uh, but, uh, It's also starting to, uh, or it has been for, for quite awhile that many, um, data libraries, the data fetching libraries comes with built-in state.. So it has a built-in state and will automatically update its own state. So if you're loading a list of things and then later you're up, you're updating one of them, the, the, the library you're using will update its internal structure. Cause it, it knows the structure of your data. So it can, it can update internally. So you can. It'll update the list before the server responds. And then when the server response it'll pre it'll refill, in that information, the server might have changed some variable somewhere or filled in some extra properties. So, so, uh, so tools like Apollo for a graphQL has that and then React query, which is a popular tool for, for classic rest. APIs also has a similar cashing of your, uh, of your data,

Fernando Doglio: 17:11

Cool all right. Interesting. And now how is this? Let's put it this way covered in your book in react quickly. And, and tell us a little bit about your book.

Morten Barklund: 17:22

So react quickly. Second edition is a 600 plus page book. That has two parts. The first part is react fundamentals. So it goes over. Some of the react API, the most important parts of the API, but definitely not everything that would have taken another 300 pages, I guess, if we should cover everything in detail. Um, so that's, that's for understanding react itself. But the second part, the last 300 pages is about the react ecosystem and all of the external libraries that we're using. So we are covering prettier, we're covering, uh, testing libraries. We're covering. Uh, data loading library. So at both Apollo and react query, we're also covering remix and the next and all that kind of library. So, so we're talking about all of those different things as well, because you can't really use react for anything but tiny hobby projects, if you don't understand the ecosystem. Nice. All right. So everything we've been talking, essentially, about is covered in the book, even that and more of course. Yes, definitely.

Fernando Doglio: 18:24

Of course. Interesting. All right. Uh, and we're going to have a discount code for our listeners on the show notes for your book. So, uh, make sure you check it out. So before we end this quick interview, um, I'm going to ask you three questions that we ask all guests. Right? First one is what is the best advice you ever received?

Morten Barklund: 18:45

That is definitely learning to learn and. In software in general, but in front end in particular over the last many years, learning to learn is super important. So when someone comes with a new project or a new tool or new library, it's very important to quickly being able to assess, uh, what it does, what it replaces, where it fits into your stack, and if it's useful or not to, to your current needs.

Fernando Doglio: 19:13

Absolutely. I a hundred percent, actually 150% agree with that. I, I, that's an advice I always give to new new developers. I mean the whole ecosystem is always changing. So if you, if you learn to pick things up quickly, you'll be, you'll be in advantage. So definitely. Uh, so number two, what is the most exciting project you worked on?

Morten Barklund: 19:35

That is fortunately my current project, for sure. I've been working on this, uh, open source react application, uh, for the last two and a half years now. And it's been a great experience. Um, so, uh, the scary thing about it is that it is a WordPress plugin.. It sounds, that sounds pretty horrible, but I have not touched PHP at all. First of all. And secondly, uh, w we're building is a pure react application that is just happens to be a WordPress plugin because that's where most developers are. So it's a, it's a visual editor is kind of like Google slides where you can, uh, where you can create pages with different items on it. But it's for creating web stories. So stories kind of like Instagram stories or Facebook messenger stories, but for the open web.

Fernando Doglio: 20:27

Nice. And why did you use WordPress as a headless CMS?

Morten Barklund: 20:31

Uh, it, it, it, the whole project is a plugin for WordPress developers. So it's, so it's meant for, for publishers to install on websites. So, so we're creating the plugin and, uh, have, uh, thousands of websites using this plugin.

Fernando Doglio: 20:47

Nice. All right. Final question. Uh, what is one thing you wish you knew before you got started coding?

Morten Barklund: 20:54

So I learned programming in, uh, in the university at, uh, and. What I learned, I have never used 90% of it after I finished. I thought right. I had no idea which 10% I would be using. So kind of had to pay attention all the way through. And I've, I've been surprised by which parts I ended up actually using and referring back to later. So that, that can really come as a surprise. Interesting. So you're saying, uh, you wish you knew the 10% to pay attention to, to just pay. Uh, yes, but I also think that that's part of the journey. So it would have kind of been a cheat if I knew that. Yeah, absolutely. All right. Uh, that's all the time we have, uh, for today. Thank you very much Morten for coming in and discussing Scaling React Applications. Please tell our audience where they can find you and where your online, uh, definitely follow me on Twitter at, uh, @barklund and, uh, and I can, uh, link to other things. Yep. All right.

Fernando Doglio: 22:02

We'll have the links in the show notes anyway. All right. Again, thank you for coming. It's been a pleasure, a real interesting topic, and I hope that, uh, people get the book and pick up on, on it even more. All right.