PurePerformance - Building High Performing Apps on React with Cassidy Williams

Episode Date: June 8, 2020

Cassidy (@cassidoo) has been building but also educating developers on how to build apps on React, JavaScript, JAMStack and many other technologies over the past years. We got her on our podcast where she gave us insights into React Hooks, how WPO (Web Performance Optimization) plays out in the React world, why it is important to think about state from the start and that its important to always have your end user in mind before even writing your first line of JavaScript.In the podcast she references additional resources which here are the links for: The performance benefits of Variable Fonts, Mandy Michael (@Mandy_Kerr), Isabela Moreira (@isabelacmor) and A/B Testing with React (YouTube).https://twitter.com/cassidoohttps://reactjs.org/https://jamstack.org/https://uxdesign.cc/the-performance-benefits-of-variable-fonts-79af8c4ff56chttps://twitter.com/Mandy_Kerrhttps://twitter.com/isabelacmorhttps://www.youtube.com/watch?v=xpfR0rRfcNk

It's time for Pure Performance! Get your stopwatches ready, it's time for Pure Performance with Andy Grab welcome to another episode of Pure Performance. My name is Brian Wilson and as always, I hope, because last time he made me scared he would suddenly spontaneously combust or something. But last I checked, Andy Grabner is with me, my co-host Andy. Did you spontaneously combust or are you there? No, I'm actually here. If I would have spontaneously combusted, then I would have probably just materialized again just in time for this podcast. So everything is good here.

Awesome. Well, we've got another episode, right? Obviously, that's why we're here talking. We're here and we don't have it. We're just here to chat to our dear listeners. So, yeah, we have a new guest we've had a several repeat guests recently this is another new guest so first time on the show and uh we're gonna be talking about some going into some topics we haven't really broached yet so i'm pretty excited about that would you would you like to go ahead and introduce our guests or do you have some some sort of banter you'd like to

well i'm not sure if it's a banter but it's first of all really glad to see that over the last three years we expanded the um the variety of topics that we've been covering right remember when we started with 101 on load testing and then continuous performance and now we've been touching everything uh around devops sre feature flagging progressive delivery, cultural changes and everything. And today we got a special guest. And it's really funny when you look at her Twitter page,

the first thing that comes up is a 14 second video that has 870,000 views. And it's titled with, when tech people ask me to describe my job and it's really with when tech people ask me to describe my job and it's really hilarious to watch it so i can just encourage everyone to go online and check out cassidy williams check out her twitter feed and the video and i know this is a podcast so we won't be able to use visuals now to kind of replay what's what's what's in that video. But I can ask Cassidy. Let's hear from Cassidy.

Hello, everybody. My name is Cassidy Williams. It's good to be here today. Hey. So, Cassidy, what's your job when people ask you? Give us an overview. Well, that's a good question. I am a coder, a conduit. Hold on.

I don't define logic. Logic defines me. That's basically what happens in that video there. So as for what my job title is now, I'm currently in between roles, actually. So what I've been doing for the past several months, almost a year, is I've been teaching with React training. And we had a team where we would go do public and private workshops to teach people how to write React better and JavaScript better for their applications. And unfortunately, because of the virus, the company had to let all staff go, which is a shame. But luckily, I did a bunch of interviewing and I'm going to be joining Netlify as a developer experience engineer,

which I'm really excited about. So, Cassidy, I think it's a new topic, at least that we want to dive into a little bit here, even though we, in the past, you know, I told you that we have a lot of listeners in the performance space. They're interested in backend performance monitoring,-end performance monitoring, front-end performance monitoring, real user monitoring.

And now you are teaching people how to use React, and I'm sure there's a lot of things around in that ecosystem, to build the next generation of applications that will power businesses to make money, obviously, or help people in education or whatever these apps are doing. Can you fill us in a little bit on kind of the landscape? So when you talk about React, what are you teaching? What are the frameworks out there? What are the things people need to know? Sure, absolutely. And I'm glad that you said when you teach people React and what are the frameworks? Because first of all, I think a very common misconception is that React is a framework.

React is a library and not a framework. And so it adds a lot of nice flavors to your JavaScript and gives you some really awesome capabilities. But it doesn't provide any structure for your applications at all. And so it doesn't give you a folder structure. It doesn't tell you how to do certain things. It doesn't set up like routing, for example, by default. And so there are a lot of cool frameworks around React. For example, there's like Next.js and Gatsby.

And I don't know, there's older ones like Jekyll. There's a bunch of different things that you can use with React to make it cool and a little bit more structured if you prefer that. But as for what I actually teach, in a typical workshop, I teach React hooks. Now, if you haven't used React before, but you might have seen medium articles about this, I'll explain what they are. So before React version 16 and middle of last year, I'd say like March in 2019 was when they came out. You pretty much wrote class-based components for React. And so you would have like a component class that is named, I don't know, button. And then you would have a function inside of button or a method,

really, because it's a part of a class that would render button, and then you would have lifecycle methods. So before the component mounts on the page, do you want to run functionality? Go for it. Right after the component mounts on the page, do you want to run anything? Go for it, that sort of thing. And so it was much more structured. And then with React 16, the concept of functional components started to appear where instead of it being a class where it's kind of like a persistent object that is updated with these lifecycle methods, it's just a function that is recalled over time. And it allowed you to kind of have just a stateless component. If you wanted to just pass in, uh, props or parameters to your, uh, to your functional component, um, it would render on the page and, and that would be all well and good.

And, and people would use them, but they were just like, eh, I don't really understand why I would do this. Um, and then hooks came out. And so what hooks do is it basically replaces the entire life cycle structure of a given class-based component and puts it into one small function in a functional React component. And so pretty much everything you can do with, again, in class components, component will mount, component did mount, component should update, functions will mount component did mount component should update. Functions like those can all be done with one function called use effect in functional components. And it reduces your code size a ton. I actually did a giant rewrite of a side project

recently where I replaced React and Redux with just React hooks and functional components. And I think I got rid of over a thousand lines of code and it was just a small side project for me. And so imagine what you could do with a much larger system. And so that's mostly what we've been teaching and what we taught at React Training and what I teach kind of outside of work as well, because just that reduction of code size and bundle and everything is enormous. And the functionality is the same, if not better. And it's a lot more future-proof as well for different updates. One question before you go on, just so I, because React is all kind of new to me and stuff, but I mean, I've heard it a million times. I've just never

interacted with it too much. This is browser side code, right? Right. So when you're talking about the reduction in all that lines of code, that's also a reduction in the payload and how much has to be transferred over the wire and process. Okay, no. All right, cool. That's incredible. And that's where I was framing it in my head in terms of thinking even, we always look

at a performance angle of things that just transfer sizes know, transfer size is, you know, great enough, you know, that's pretty awesome. Yeah, no, it's, it's, it's awesome. Genuinely there, there was a talk by, uh, Ryan Florence, who, uh, used to, uh, he, he ran react training. Um, and the, his like clickbaity thing was hooks will reduce 99% of your React code. And everyone was like, whatever. And then you saw him refactor a bunch of stuff and you're like, oh my gosh, he's right. It's really amazing what you can do with it. And so for those who are listening who don't really understand kind of how React works under the hood. What happens when a component is put on the page is, let's just say you have an element that it could be anything,

a button, a dashboard, something. It generates an element and renders it to the DOM. And so the DOM, the document object model, it basically says, okay, we're creating this element in step one. We're putting this element on the page in step two in the DOM. And then whenever that component updates, whether it's a state change or a props change or something, it does a diff on the old element and the new element. And then it commits that diff to the DOM. And so it's kind of like a git diff where it doesn't pay attention to how the entire file changed. It just pays attention to which aspects of the component have changed. Um, and, and those are the things that update. And so the, that concept is called the virtual DOM. It doesn't need a full, uh, it doesn't need

a full repaint of the, of the browser page. When you, browser page when you have a state change or something change on the page. It only repaints the element that changed the text node or whatever. And so because those are kind of the four steps where, again, creates an element, renders the element, diffs the element, commits the diff. There are a lot of different performance things that you can do at each step. Like when that element is created in step one, you could say, okay, what things does this element need? There's a lot of props that you can pass in to an element from like the color to, I don't know, is a user authenticated and things like that. And sometimes that results in unnecessary calculations. And so there are different ways to kind of organize your client side code. So that way you don't have to do those calculations every single time. And then when you actually render things to the page, luckily that, because that's what React does,

that's pretty fast and you don't have as much control over that aspect of like these four steps. But the comparison, the diff, and then committing that diff to the DOM, there's some hooks called like use callback and use memo and just a memo function for memoization that can basically make your components render that much faster, which there's really no, as you guys probably know, there's no mega silver bullet for this

is how you make something perfectly performant, But there's a lot of options, luckily, with React apps. So the quick question, when I started in my career with Diamond Trace, it was like 12 years ago, and before that, I also did performance with a performance testing tool. But kind of when web applications started and kind of when they became more, let's say, dynamic, we had folks like Steve Souders, I'm sure the name rings a bell, right? Who talked a lot about

web performance optimization and how we can optimize images, optimize the way we load things on the page. Are these things still relevant these rules that steve and others have set out back in the days or are they obsolete or are they are there other rules because now these frameworks or these libraries are taking care of things like this that you are that you for instance you know things get loaded in the proper way, that they're not blocking things that should be blocked, that you as a developer, if you're working with your development tools, you cannot make a mistake, let's say, upload an uncompressed image where you get automatically the options that the images have the right resolution.

From that perspective, from a web performance optimization perspective, is there something new or is it still the same as it used to be or is it completely obsolete? A lot of that is still the same, actually. Like uploading big images, like you said, you probably shouldn't do that. What's interesting for, I was actually just reading an article on this yesterday.

What's kind of changing right now for loading different files on the page that aren't necessarily code is fonts there's a lot happening in the font space right now and people are saying oh well if you do this via importing in your css then it is not performant but if you import it in the html side it is and so why is that and what has been particularly interesting to me is the introduction of variable fonts where the, how you can optimize performance for it and how they actually are performance. Some people, when they hear it and they're just like, well, if it's variable and you can pass in all these different things that sounds like a giant font file um but there's there's a lot of really good practices around that and so i would say that those kinds of those kinds of older practices they're still relevant today there's just newer things that you have to apply them to you know you know it's interesting you mentioned the fonts i was just

working with uh you know a possible customer of, and I started analyzing their front-end performance. And besides the fact that there were probably at least 100 resources that were being downloaded between images, fonts, JavaScripts, and everything, about 10 of them were fonts. And some of those were taking almost a second full round trip to download and all. And I'm like, what's going on with these fonts? And I'm starting to think back to the old rules about, shouldn't they just be using web fonts? And in my head, I don't really stay too much on top of the state of WPO and what the best practices are, because I'm not developing front-end web pages. But in my mind, I'm like, if you're doing all these fonts, you're kind of breaking the rule of just not using the standard web fonts.

So it's really interesting to hear that there is actually a major breakthrough on using fonts so that you can use them. You can make your pages look really, really nice without quite the heaviness of downloading 10 different fonts at a second a piece. Yeah. And that's what's cool about the variable fonts is instead of downloading like 10 different fonts at a second a piece. Right. You know? Yeah. And that's, that's, that's what's cool about the variable fonts is instead of downloading like 10 different fonts, you could download like two and you'll still get pretty much all of the fonts that you need and all the typography that you need on, on a given page because of what capabilities these,

these fonts have. And so, yeah, it's a, it's a really cool technology. I honestly have been wanting to dig into it a lot more and and hey i'm working from home now so i might as well because we all have yeah we have all the time in the world now right

sure definitely not more busy than usual but yeah no it's uh that's definitely something that is on my to-do list of things to just read more about, because I think it's so interesting, the capabilities that those provide. Yeah. So Cassidy, for those folks that are, you know, just here about React, or they heard about it before, but now listen to this podcast, are there any, I don't know, do's and don'ts or best practices, bad practices? Is there anything out there where you say, before you write your first React app for an enterprise, for somebody where the app actually goes live later on,

please make sure to understand these five things or read these five blog posts or read this book. Right, yeah. So I would say the biggest thing that a lot of people mess up is just really where your state lives in your application. And there's so many different things that you can do with state. And back in 2015, 2016, Redux came into the picture. And a lot of people are just like, ah, if I want to build a modern React application, I need to use React and Redux came into the picture and a lot of people are just like, ah, if I want to build a modern React application, I need to use React and Redux. You don't have to anymore. I want to preface with that. But what Redux did is it implemented the architecture

Flux. And if you don't know the Flux architecture you can look it up. I don't want to get into that now because that'll take up all of our time. But basically it implemented the Flux architecture with reducers to show how you can update a global state in your react application. And though I think Redux,

it really introduced a lot of cool ideas. Luckily you don't need it now because with react hooks, they introduced what's called the context API and the user reducer hook, which basically is 99% of Redux with a lot less code and setup and working with things. But there's still some gotchas that pretty much everybody with Redux fell into that you don't have to fall into with context and reducers. So what happened with these Redux applications was they basically made pretty much all state global. I've seen this so many times on so many teams where they basically made all of their state global. And yes, only certain components could update certain aspects of state,

but otherwise it kind of just lived on top of everything. And that was not great because in particular, I talked about how there's the four steps of React where you render something and you create something, render something, diff it, and then commit the diff to the DOM. It would do that diffing part every single time way too many times because you were updating state at the top level, which means it had to check on every single component in your application to see if it touches that piece of state. So it resulted in a lot of unnecessary re-renders in your application,

which can just slow things down, especially if there's more complex calculations happening in your application, which can just slow things down, especially if there's a more complex calculations happening in your different components. And so it's, you can do that with, with React hooks and context, but you shouldn't. And what you can do is you can still set up some kind of global store. And I do think that it's valid for some things to be more global, like, for example, authentication, maybe locale or something. But you don't have to put everything in that top level. You can make kind of sub levels of state that need to live in certain aspects of your application. You can call APIs in one component and then lift state to another component. I think this kind of can get hairy,

and so you need to kind of think about your architecture of how you want to structure your React applications. But I think where state lives is really the, that's kind of the biggest gotcha that I've seen with React applications when people just are like, ah, everything can be global, or I'll just make this state touch five different components. It should be fine, even if the components don't necessarily need it as much. Like, yes, it's fine. But again, you can have unnecessary re-renders and

unnecessary calculations that don't need to be made. And so the, yeah, yeah that's that's the biggest gotcha i've seen across so many teams cool how about um i mean this is also a world where we're also brian and i live more so than on the front end when it comes to calling the back end when it comes to making rest calls to different services in the back are there any i, I remember the days when backend developers were using frameworks to access the database, like a Hibernate, where it was a great framework to like an ER mapper and entity relationship mapper. But if you didn't use it correctly, you ended up with a lot of duplicated calls, a lot of round trips to the backend database to retrieve a certain set of data. And then it got a lot of bad, I think there was a lot of bad publicity about it.

And people are saying, well, it's not a good framework, but it was actually not the framework. It was just, it was so generic that it allowed you to do so many things. But if you didn't know how to use it correctly, you ended up with a big mess. Is there something similar in React, the way you interact and the way you fetch data from services, from backend services, from third-party services? Is there any best practices or are there any bad things you have seen people do? Yeah, and so there's so many things that we could talk about here. One thing that I have been really enjoying working

with is Apollo and GraphQL. And GraphQL, as you guys probably know, but for those who don't, it's basically a new way to query for your data. Rather, instead of using REST to kind of make API calls or something to your backend, you can use GraphQL to get that kind of make API calls or something to, to your backend, you can, um, you can use GraphQL to get that kind of data. And so, um, with Apollo, for example, they, they have Apollo server and Apollo client. What you could do is you can say in a given react component, for example, I'm in the react world. So I'll talk about that. Um, I could say, okay, well, in this component, I only need the avatar and I don't know if the user is pro or not. But then in this component, I need this data, this data, this data. And there's so many different things that you can query.

What's really awesome about using something like Apollo Client to query this data is that you can query just for what you need. So it really empowers the front end to do that, but you can kind of bundle these queries together so you can get the data that you need and then put it in a local cache. So that way the front end doesn't need to make unnecessary queries and it can do somes too, where it'll make a query after a certain point or on a certain re-render. And if the data that it sees is different, then it'll make updates. But if it's the same,

then it'll reduce any accidental re-renders or changes or something on the page. So there's some really awesome things that way. And there's also an architecture some really awesome things that way. And there's also an architecture that has been used a lot. I honestly, I I've used this architecture a lot just in my life, but now there's an actual name for it and it's called the jam stack. And jam stack it's the jam is JavaScript APIs and markup. And the concept of it is there's all kinds of different frameworks and you could do it with Vanilla.js or you could do it with Next.js

or Gatsby or Hugo or Jekyll or something. But what it does is you can generate your websites at deploy time. And so it will render a static website that has dynamic content. And so you can have a touch of both server-side rendering and have the benefits of client-side rendering, but it minimizes the time for rendering the page the first time because it has pre-built files over a CDN or some other service. And so it's not something that's built with some kind of server-side CMS, and it's not just a single-page application that only lives on the client side,

and it's not a server-side app that's like a Django page that is pushed up and you navigate to a different page every single time, a new HTML page every time you navigate around. It's a combination of the two where you generate a website on the server, but you still have the client-side benefits of pulling in dynamic content and everything. And so that's kind of the trendy architecture that is really picking up a lot of speed. And there's a lot of companies that are completely based on that now. And actually, I mentioned that I'm going to Netlify in my new role and pretty much that's what they do. And so I'm kind of excited because I can work on something that I actually use.

But it results in a really great developer experience because you can have these pre-rendered sites that are enhanced with JavaScript and services that are available with APIs without making unnecessary requests to databases and stuff. And if you architect your apps out in a smart way, you can kind of cache the data you need and have less re-renders and also just less page load as you're navigating around an application

and changing things around an application. And so it's not, it's not a single page, all powerful client side app, but, but a combination of the other technologies. Very cool. Can I jump in here for a second? I wanted to ask a question regarding this, right? Sounds like there's a lot of different ways to approach, you know, creating the front end and what we, what Andy and I have seen in a lot of our other conversations and i'm sure you've seen some of this as well is you have all these different options for the back end you have serverless you have kubernetes you have docker swarm you have standard virtualization and anytime something new comes out ever you know some some people make the mistake of saying well we're developing something

new so we must put it to microservices in the cloud and use kubernetes because that's what we do that's what they're supposed to do right but the strong advice that we hear over and over and we've seen proven out is always pick the technology that fits what you're trying to do what is it that you want to create and then find the set of the back-end setup that's going to best suit that. When you talk about these new components, was it just Jam or Jam? Jamstack is the name of the architecture. Jamstack. Yeah. When you talk about this, we talk about single-page apps,

talk about the CMS side. When looking at the Jamstack particularly, is there a type of webpage or type of content being delivered that that's more suitable for? Because I'm starting imagining basically front-end developers say, hey, I want to do Jamstack because that's the new coolest one to do, but it might not be appropriate for it might have

the same kind of issues that people see with the back-end, just picking the newest hottest, but it's not necessarily the best fit. Is there that kind of best fit situation for front-end development? And if so, where would Jamstack fit in best? What kind of sites would that be best for?

Yeah, and so the difference there, because I agree with you, and I've been on so many teams where they jump on the latest technology and sometimes it's a mistake and sometimes it's great, but it's a toss-up. What I like particularly about this architecture is that it's framework agnostic.

You can choose whatever frameworks and whatever technology is the latest thing that you want to build, and it will generally fall under this concept of JavaScript, APIs, and markup. It doesn't need to include all attributes of it. And so it's not like mean stack where it's like Mongo Express, Angular Node, I think that's what that stands for. The Mern stack where it's same thing, but with React instead of Angular. There's so many different names of stacks of these sorts of things that are specific to a particular framework. This is more of an architecture, a style of writing things where it is specifically aimed at better performance and scaling and security and developer experience and stuff. But it's, you can use whatever you want to write it. It's just the concept of how you organize your applications so that both the front end and the back end are empowered to be performant on their own and work together in a good way.

And so if I'm being honest, I can't think of a specific example where it wouldn't fit. But that's mostly because it's such a generic style of writing applications rather than specific to a given framework. Right. So it sounds like it's more of here's a style that you can use. You're still going to be responsible for utilizing it properly, but it's going to if you learn it and you know how to use it, you're going to reap some benefits. Exactly. Like be discerning with how you render things and what you put on the page and when you load certain content. But it has a lot of benefits if you put on the page and when you load certain content. But it has a lot of benefits if you do it the right way. Great.

One quick comment, then a question. I actually remember when you brought up Jamstack years ago, when I used to live in Boston for a couple of years. And I remember I was actually at the inaugural meetup of the Jamstack group. And yeah, and I think it was at least three years ago. First time I heard it back then. And thanks for reminding me about all about this great, you know, Jamstack. I want to switch, not switch topics, but I want to go into different, slightly different direction. So a big topic that comes up more and more these days with us is everything around progressive delivery.

And progressive delivery is this kind of term, and I think it kind of encapsulates your blue-green deployments, your canary deployments, your feature flagging. is on this do you also see more and more organizations going down that route and and using these deployment options to start experimenting more and and if that's the case how do you in your world when you teach when you code you know leverage progressive delivery and which flavors are there yeah so so this is this is a world that I have, I've like dipped my toe in, but there's so much that I probably can't even name all the different options out there, but I've done things like, like AB testing and, and figuring, figuring out you know, which things should be loaded for which users and, and having, yeah,

different environments for different locales or different stages of development and stuff. And it's a whole world where myself, what I've really been enjoying, and I promise I'm not just trying to advertise where I'm working for, but there are companies like Netlify, like Zite, like a bunch of different groups where they're based around, for example, like Jamstack and a bunch of other site, I should say frameworks for site generation and stacks and stuff where they set up a lot of these kinds of environments for you. And it's really nice.

And so they'll handle the continuous deployment. They'll handle what kind of environment you want to deploy to. And so you can just say, okay, well, I want this repo on this branch to be pointed at, staging to be pointed at, this testing branch to be pointed at, this domain domain and that sort of thing. And, and, uh, it's a lot of reduction of, uh, kind of dealing with ops and, and, uh, AWS and that sort of thing. And so, um, I think there are a lot of strides happening, uh, in that field of, of setting up different environments and different, different experiences for different users as you, as you kind of figure out, okay, this is what this user wants. This is what this user wants. There's some great talks out

there that I recommend. There's a developer named Isabella Morera, where she has given some awesome talks specifically around A-B testing in JavaScript and React and how to do that without messing with your users too much and giving them a new experience every time they refresh the page because you don't want that to happen, but also to set up analytics around it. But yeah, this could be a rabbit hole that you really dive into because there's so many options out there right now. Mm hmm. So when you when you design a new app,

do you early on get engaged with your end users to really figure out what should be the user journeys, what should be the flow? How does this work? I know this is I mean, it's kind of like going or doing the A-B testing canary deployment of feature flagging and trying it out in the live system with the right people, but actually taking all the way to step back to the beginning. When you design a system, are you teaching these folks that you obviously want to sit together with your end users and trying to understand what problem they want to solve and how to navigate through the system? And then maybe do some early prototyping or what's what's the approach yeah and so this isn't something that i necessarily teach but it's something that i do um for myself i i'm very

much a pen and paper person before i before i start typing anything and so i'll actually draw out screens of what i'm thinking the app should do, where I think it should go. And then, yeah, I immediately try getting feedback right away where it sometimes is dumb where I have to take a picture of my notebook after I've drawn something out. But then from there, I can then use a wireframing tool and be just like, okay, how about this? And then share it with a few people and then just kind of expand it more and more and more until I have a good design going more until I have a good design going until I have a good architecture going. And then that's when I start actually thinking about my code. And I've kind of altered how I write things from there over time where just how I structure

out my folders, what frameworks and stuff that I use. But yeah, I think it's absolutely important to show things to your users first and kind of get their opinions on things. And even if it's just a very small subset of your users, even if it's for just a side project, I was making something recently for kickboxing where even though I'm not really much of a kickboxer myself, I was listening to some friends talk about how there's no good timers for kickboxing. And so I drew out, okay, here's what, what you might need if you wanted to do some kind of routine. What do you think? What do you think? And iterated a bit with them. And having that communication with someone who might use your application, who might find it useful, I think is absolutely key to actually doing a good

job at it. And if you aren't able to physically be there, um, doing something like AB testing or something, uh, it, it gives you a lot of really good data. Um, there's, there's sites like, I don't know, mix panel and looker and, and a bunch of other, data um aggregators and stuff where you can see okay generally users click on this and not this um and and so you can do that at the later end too if you just want to build and do it but i think it's absolutely worth doing a lot of that work up front purely to save time and energy and and uh also to make sure that you are producing a good experience what we've i mean what we see with our folks that we work with with our customers uh is we have a capability in our product in dynatrace that we call session replay so when we monitor your applications

from a front-end perspective we are are able to monitor user experience by, it seems doing similar things to what you explained earlier with React. So we captured a DOM and then we captured DOM changes and we basically sent it back to our backend monitoring system. So you can actually visually replay

how individual users were navigating through your website. And that's especially useful for obviously multiple cases when you have people complain and you can look them up and say, oh, I know why you complain because you are using an old browser that doesn't render things correctly or something like that. But you can also use it for A-B testing and then you can visually replay and see how A versus B navigated. And then you may figure out that people just don't find this little button

that you put there and you thought everybody's finding it. So I think that's a technology that we have seen being used more and more now for exactly that purpose, to get feedback from the end users, how they are navigating through a system of where they're struggling, where they're losing time, and also where they may be dropping off. And I think that's also great feedback.

But I agree with you. You should start as early as possible before you put it live into a big test audience. But at least it's good that we know there are tools out there. And you mentioned a couple. We have it as well to get real insights into your real user behavior. Yeah, those kinds of tools are necessary, I think, especially as you want to build more just user-focused applications. Yeah.

Hey, one more topic that I would like to cover is mobile. So maybe you just naturally assumed, you know, when you build apps that it doesn't matter where they run, desktop or mobile. But in your world, how does this look like? Do developers need to develop, and especially now with React and Jamstack, do you have to take care of specific things

not only from a design perspective, but also from the libraries that you use and what you do to be optimized for a desktop browsers versus a mobile browser? Yeah. So this is where CSS comes into play and stuff. And there's actually a conversation I really like to talk about when I'm teaching.

And it's about media queries, where CSS media queries, they're great. I still use them for if a page is a certain width, you change how the page looks or it doesn't have to be a width. If it's on a certain type of browser or certain things, the CSS media queries can detect that sort of thing, which is great. But let's just say you have a big set of content on your page and you have a sidebar that queries data from an API or something. And when the page is on your phone, the sidebar isn't there because the screen is too small. If you just use media queries to take that kind of sidebar away, that kind of thing away, you're still making unnecessary API calls and data fetching without even seeing what it's

fetching on the page. And so that's where something like use effect, that hook that I mentioned that replaces the lifecycle, it does a lot more than that. And there's a lot of really cool things. And what you can do is you can basically make a function that runs in sync with any state variable, anything that you want to run on the page. And so I just love this aspect of React. I think it's the coolest thing where I could keep track of the window width. And then if the window width is below a certain size,

we just won't render a certain component on the page and it's done on the JavaScript side. And I know that there are things that are hidden with CSS or moved off to the side or something that aren't necessarily beneficial for mobile users. And then I've also seen some people who will do something like they will just load an entirely different site for a mobile user. I personally don't like that approach, but it's totally viable where they'll say, oh, well, this site is loaded if it's a mobile user and it does a little redirect and then it doesn't load certain fonts as a result. And it loads a much just smaller bundle size and everything.

And so that's an option too. I feel like it's a good way to do it, but it's not necessary if you write things in a good way for a more responsive application. But there's options, I guess, and that's kind of the defining feature of front-end development. There's almost too many options with how you want to put something together. Very cool.

Hey, Cassidy, are there any other topics that you want to make sure people know about the work that you're doing about React, about Jamstack that we haven't covered yet? I do want to mention very quickly the concept of memoization. And when people hear it, they're always just like, what was that word? Because it kind of sounds like memorization in a baby voice. But what memoization does is it's a way to reduce the number of calculations that happen on a page. But it basically compares values in a calculation. And so let's just say I had some function that's like calculate big number. And every single time my component renders,

I have to run calculate big number to get that value. And if you look at like your performance tab in your browser, that big value could be a spike every single time you render your page. What you could do is you can wrap that kind of function, that calculate big number, inside of a hook called use memo. And what it does is it'll look at a dependency array that says, okay, which things do I have to pay attention to? If the values in that dependency array haven't changed, then it won't rerun those calculations. And so you can make sure that you're not running unnecessary calculations on repeat just because it's something that needs to be done. And there's also just a memo function too that you can wrap your entire component in. And it'll say, okay, well, if the props haven't

changed in this component, if the state hasn't changed this component, we don't need to re-render anything. And we can just do that. And that also works and it can reduce that number of re-renders. I think those are great and people should know how to use memoization. That being said, I mentioned before, there's really not a silver bullet for making things particularly performant. I keep bringing up those four steps where you create an element, you render it to the DOM, you do a diff, and then you commit the diff to the DOM. When you do that diff where it compares the two different states, and then it commits that diff to the DOM, that's pretty dang fast. Because again, that's what React does. When you memoize something, that can speed up the committing

to the diff of the DOM, the committing that diff to the DOM, because it says, okay, well, less things have to be changed on the page. Less things have to be calculated. Great. But it does add another diff to that set of steps that have to happen. And so there are pros and cons. I'd say be discerning on that front,

but those are some things worth looking up and knowing as you're optimizing performance in a given react application very cool um yeah we want to also make sure in the proceedings of this podcast right on the website that we add a couple of links obviously we'll link you on your twitter profile so people can see the video that you posted in January, but also making sure that we add a couple of links to React and to ChampStack and whatever

you want people to follow up on. We'll ask you later on for a couple of links to write the write-up. Absolutely. I'll get some links for Mandy Michael on variable fonts and Bella over on A-B testing as well. That'd be great.

Perfect. All right. All right, Andy, is there time for a summary? I'll make it short. So, Kassidy, typically I'll try to summarize what I have learned in the last 45 minutes. But I'll keep it short. I think for me, it was great to learn about React.

Just as Brian said, we are familiar with React. I had no clue about the changes it went through, and it seems React hooks is really the way to go. And especially around reduction of code size, making it cleaner, and therefore reduction of code size means less potential bugs in code. And also, as Brian pointed out in the beginning, less code means less size.

Less size means less things that need to be transferred. It was also great to hear that WPO, so the Web Performance Optimizations, most of them are still relevant. And thanks for pointing us out to the fonts. So we'll definitely make sure to add that link. And I think I took a couple of notes on practices.

So you talked about one big thing that people need to understand from the beginning is where state live. So there's different options, but also it's a big impact depending on where you put it and yeah i think it sounds like we need to have more of these sessions on technologies and frameworks that we haven't touched upon in the last couple of years since we've been doing this podcast because there's so much fascinating content out there and in the end we're all contributing to the the world that is building the next generation of apps and they should run soft and smooth, and they should be also awesome looking and functional. So thank you for that.

Yeah, thank you so much for having me. It was fun talking about all of this. It's fun to geek out about stuff you use. Exactly. Yeah. I just also want to point out that one thing that I was thinking about more and more as the discussion occurred today was I think historically there's been a bias of the back-end development being the more hardcore, serious stuff, and the front-end is more about design and look and feel. But obviously, you know, that has changed a ton over time. The amount of technology and the amount of development and code going into the front end is tremendous these days.

And it's even more visible. You know, if you make a mistake on the front end, you can't hide it, you know, so it's even more critical. So I'm hoping this helps to dispel some of that and really break some of that down

and really give credence and strength to the front end development side because it is such a critical, critical aspect. And it's, you know, I'm very, very novice. I never really developed, designed any or coded any front-end stuff, but I've done some analysis. So I've learned a little bit more of how some of these things operate than maybe say, you know, my typical colleague, but I would still consider myself an extreme beginner. And just hearing all this stuff going on today, I'm like, wow, it's even more complicated

than the tiny little bit of the universe that I know. It's like the Hubble telescope has been discovered in the meantime, and that universe has expanded way beyond things I can even comprehend. So hats off to everyone who's doing this work because it's nonstop, it's constant, and it's very, very, very visible. You can't hide behind any of it. So tip of the hat, whatever you want to say to that.

So thanks for sharing all this with us, Cassidy. I think just in tech in general, there's a lot of gatekeeping where you're just like, well, you're not a real developer or this isn't as hard as what I do. That happens everywhere. And so I think anything to reduce that kind of talk is necessary because especially as things have gotten more complex in every end of the stack, it's all in the name of performance. It's all in the name of doing things better. Um, but yeah, you, you have to kind of nip that kind of conversation in the bud because things are tough out there for, uh, but in a good way that there's, there's really cool things that are being worked on and developed. And, and yeah, I think I, I really like

working on the front end because I do like making things look good and stuff. But also, I have a CS degree and I really like the theoretical aspect of coding things and state machines and optimizing that kind of stuff and reducing runtime in applications. And so, I'm really enjoying the advances that front-end development has made over the past few years. And yeah, every end of the stack is hard. And so kind of reducing, yeah, that kind of talk saying that something might be much easier than others.

There's no need for that. Exactly, exactly. Awesome. All right, well, thank you very much for being on. If anyone has any questions, comments, you can tweet us at pure underscore DT. Cassidy, your Twitter handle is? It's Cassidoo, C-A-S-S-I-D-O-O. Awesome. All right. So follow her and then you can watch that great little video she has in the beginning of your page. And thanks for listening, everyone. We'll talk to you all soon.

Thank you. Bye.