Your React App Doesn't Need All That JavaScript

What if I told you you were using way too much JavaScript in your React applications? Hi, my name is Jemima. I'm a product engineer at CASE. I'm a Google Developer Expert at Microsoft MVP and a Certified Professional in Accessibility Core Competencies. Basically, what that means is I really like exploring the web and sharing the things that I've learned with other people. And one thing I have that constantly comes up in React, at least for me, is that it just keeps feeling a lot more complicated than it needs to be.

So how much JavaScript do you actually think a dark mode toggle needs? I mean, like a toggle that's just switching between light and dark mode. You're updating two colors and you're clicking a button, that's it, right? In React, it's a lot more code than you feel is necessary, or at least I feel is necessary. So let's break down what's happening here, right?

First, we have our states. If you're using React, you're going to have to work with states. If you're switching between basically anything, that's fine. That state, we're all used to And then we need persistence. So you want to store the user's preferences, right? So like next time they visit the page, they can see what they selected previous time. That's also great. We care about user experience. Amazing stuff. And then we need global architecture. If you're working with React, you need like something that's going to pass the same theme down to every single component and across multiple pages, right? So you need a context and you need your provider and you need everything that's handling your global stack management.

And then because it's React, let's throw in some optimization, because why not, right? Because that means that we're making sure we're using memo. Why do we need to use memo to toggle the theme? It's either or. But that's the React way of doing things, right? To me, this feels way more complicated than it needs to be. I remember the first time I tried to build a theme switcher in React. And after having to download the state management library, I was like, this doesn't feel right. I think I'm doing something wrong. But all the articles were like, you're doing something right. But this is a very complicated method of doing things. And what is the issue that we face when we use something that's complicated to handle a very simple task? State propagation, right? So first, we are handling every single time the page is updated. Every time we change that state, that state needs to then be passed down to corresponding components. So that means every single time you click that toggle button, any other component that needs that theme is going to get updated too. This leads us to have lots of rerenders on our page. Because React operates on a virtual DOM, every time we make any change, it needs to basically update all the components that require that change. So we're causing rerenders. And then we also have the hydration flickers. This is when your page first loads. And let's say because you haven't necessarily kicked in your React yet, you're going to see a, let's say the user has saved dark mode, you're going to see a flash of light mode first and then dark mode is going to kick in. So to me, this feels like a lot for doing something so simple. It's kind of like, imagine having Optimus Prime and you're using him to flick a light switch in your house. It's like you have this giant overengineered, overpowered platform and you're using it to handle something super basic.

Well, what if I told you there was an easier way to do that? Thanks to modern web features and development, we no longer have to rely on overcomplicated React architecture to handle simple components. This is a simple CSS implementation that handles dark theme mode using just one checkbox. So let's break down what's happening here. First, we have our semantic checkbox in CSS and we're giving this a theme toggle. And then we have the has to the selector. This is what is doing all the work. Has to the selector is something that lets us style parent elements based on child elements. So basically what we're saying in this code is, if the theme toggle check box is checked, give the roots a new value of background black or text whites. This is what we're using to handle toggling the dark mode. In case of handling user preferences, we can also use the prefers color scheme.

So this means that if the user already has something on their system that says, oh, just set everything to dark mode. Like, you know when you're on your phone and, well, my phone has this automatic thing where like by 8 p.m. or something, it toggles to dark mode automatically. What that means is for every website they're using, it's also going to toggle to dark mode automatically. So you don't even need to worry yourself with storing user preferences because you are using the default one that comes with the user system. But if you do want to still handle user preferences, this is where JavaScript comes in. So now you can say, okay, I still want to save user preferences. Let me just get the local storage using JavaScript.

We have somehow managed to take React from being something that was, when React was first invented, Facebook wanted to use it for like super dynamic things. It's like, oh, I need to make sure users are seeing changes like immediately. I need to make sure things are being updated. If I'm getting data from the server or if a user is calling like any interaction that requires back and forth responses, I want to make sure that thing is being done really quickly. But now we keep using React for simple things like, oh, I want to toggle an accordion or I want to switch to light mode. I think we need to go back to where we were when we first started with web development, which was using JavaScript for functionality and using HTML and CSS for content and display and animation.

Starting with our theme switcher, as we established previously, handling a theme switcher in React requires a lot of state management and updating. So this is what a theme switcher in React looks like. It's pretty standard stuff. You just click the button, it switches to light mode or switches to dark mode. Now, if we wanted to handle the same thing in HTML and CSS using that code I showed you earlier, this is exactly what's happening here. It's the same thing, but it's not having any of the rendering effects that React does. I also have a little renderer here. So you can see what the React updates look like. So every single time we update this theme switcher, it's calling a new render for each single card that uses that theme mode. So anytime this is updated, it's updated here. But you notice that with the CSS, it's only called on page load and it's not called any other time.

I also have a little renderer here. So you can see what the React updates looks like. So every single time we update this theme switcher, it's calling a new render for each single card that uses that theme mode. So anytime this is updated, it's updated here. But you notice that with the CSS, it's only called on page load and it's not called any other time.

This is because it doesn't use the same virtual DOM model that React does. So everything that's handled in CSS is updated purely through the CSS GPU renderer. It's not requiring any new updates or any working with JavaScript. Let's also take a look at the code in production so we can see what's going on here. If I switch to my code.

So this is our React code. Like we said, we have all our use effects and we have all our use states here. We have our context, yada, yada, yada. And then this is our CSS code. We don't use any other functionality here. The only thing that's handling the work here is this check box for theme switcher. And then if we go to our styling for theme switcher, you notice that we have our has theme here. And all that's doing is saying, okay, if the check, if the theme switcher is checked, then apply this background and apply this color and all of that. So that's pretty much it.

So that's pretty much it. That was, that is probably one of the simplest implementations of a theme switcher that I have built since using React. And that really great thing about the CSS theme switcher is that because React is technically a single page application, it means you don't even need to update it across the app. So for example, I'm using the same CSS implementation here for my global dark mode management. And you'll notice when I switched to the other page, the accordion page and back to the theme switcher, I don't need to make any changes here. So if I inspect this in the global dev tools, you see that it's just the theme switcher here, which is the check box that I'm using. And then when that's updated, this root value here gets all the updates. So this is all that's being changed. And once I switch back and forth, because React is a single page application, this is technically the only, this is technically the only div that's actually being rendered on page. I don't need to update it at all.

That's a really cool implementation of using the CSS Has pseudo selector to handle anything that requires parent styling. And the great part about this thing is that number one, it is baseline supported. So you can use this in production right away. And number two, it can apply to anything where you have previously needed to use CSS, previously needed to use JavaScript to target a parent selector. So for example, here as well, I'm also using the Has pseudo selector to say, oh, if this Has popover is open, then move this page by the padding of this spacing. So anything that you might think of, oh, let me reach for JavaScript because I need to target like I need to target this parent element here, try using Has instead.

And then the second implementation we'll be looking at is a accordion. So an accordion is a simple component. You click a button, it displays contents. You click the button again, it closes the contents, fairly standard stuff. Now this is what the Java React accordion would look like. So let's take a look at that code first. It's here. So it's not that complicated to be fair. We just have like a toggle button. And then if the toggle is done, we just set it to the active item and then that's all we're toggling the accordion here. But regardless of whether it's complicated or not, do we need it to be done in React? Probably not. So let's take a look at what is going on behind the hood here. So we can reload our renderer again. And that thing we can also have here is the performance time to show you like how much time this thing actually takes to load.

So every time this thing is called, we have the user waiting for the content and waiting for the renderer to be done. And actually, this is for example, when it comes to things like slow internet, we can't always assume that everyone is using 5G, right? People that use slow internet, whenever you're putting things like content in JavaScript, it means that because the way a page loads, you get your HTML first thing, you get your CSS, and then you get your JavaScript. So that means that if anybody's trying to use your page, they have to wait for all of the JavaScript to be loaded on this page before they can then toggle this accordion. That is kind of a performance issue because you don't want to be preventing users from being able to see content on the page.

Also, if I download the page and let's say sometimes my internet glitches out in the middle of things. So it only downloads like the HTML and all the styling is broken and there's no JavaScript at all. If that happens to a user, it means that whatever is inside this accordion, they're not going to see it at all. But we have the HTML version of an accordion, which has the exact same functionality where it toggles all the code, it toggles all the displays, but you don't have any of the JavaScript requirements.

So let's take a look at how this is being done in HTML. This is the only feature that we need to make an accordion in HTML. So we have our details element here and our summary element here. And these are the two things that are responsible for toggling this accordion here. Let's take a look at the dev tools to see what's actually going on underneath the hood. So this is our details accordion. Once we click it, you notice that the details updates to open or to closed. One thing that's also really cool about details accordion is if we go into this JavaScript here, you notice that we have like our ARIA expanded and our ARIA controls and everything. And while this is updated, this is stuff that we had to manually code.

So when it comes to accessibility, if you are not keeping accessibility at the forefront of your development process, it's very easy to forget things like this. So if somebody was using a screen reader, for example, it'd be very easy for you to forget to actually update this accordion to say ARIA expanded, which means that if I was on a screen reader, I would have no idea what was actually happening with this accordion. If it was not grouped, if it did not have ARIA controls, I would have no idea what was actually going on behind the scenes.

The best thing about details is that it has all of this inbuilt by default. So you see, if I click here, I have my ARIA expanded and ARIA controls panel set here. And if I go to details, let's read this one. If I go to details, you notice that it also has the focusable, expanded and focused values here. So that is basically how that's updated. When you start using semantic HTML, it means that you are getting a lot of inbuilt browser benefits without having to manually code any of this yourself. So it saves you a lot of time in the long run.

Details also has another feature that if you wanted an exclusive accordion, so an exclusive accordion is just when you click one accordion, the other one closes. Details also lets you do that without any extra code. All you need to do is add a name attribute. So you notice that here, I now have a name attribute added to my accordion. So I'm using the name FAQ. And if I click that, you notice that it toggles by itself. This is another great example of things that are inbuilt that the browser can handle by itself that we do not need to use custom code or outsource to an external library.

So I think details is a good example of why people don't necessarily use these custom features, because details came out like 10 years ago. It's not a new feature, but a lot of people haven't heard of it. And that's because the first time it came up, people were like, oh, this is really cool. When can I use this? And they're like, oh, sorry, it's not supported across all browsers. And by the time it actually became supported across all browsers, people have kind of lost interest because they're like, oh, we're just going to use this JavaScript library now.

So I think it's a really good example of a reminder that we should always be keeping up with the latest things on the web. I think especially in this age of AI, you'll notice that when you tell an agent to build something, it's going to default to the most popular pattern. So if I tell my agent to build a JavaScript accordion, odds are it's going to be, if I tell my agent to build an accordion on a web page with no specification, odds are it's going to be the JavaScript accordion. Regardless of the fact that, oh, details is a much simpler and easier alternative, it's going to default to what has been popular.

So I think that's why it's really important that we keep up with the latest changes to web development to ensure that we're kind of keeping ahead of the agents and like letting them know what we actually want them to do. So yeah, that's it for details. Let's move on to a modal. Now a modal is a very common thing where people will reach for a library before they even try to build on themselves. Because with a modal, it's not just like making things pop and appear on the screen. You also need to do things like implementing backdrops.

So that's when if I click outside the modal, I want it to close. I need to make sure I'm implementing the focus trap. So if I've clicked into the modal, is the focus being trapped in that modal? Can the user get focus trapped anywhere else on the page? I need to make sure I'm implementing keyboard functionality. So that's exit to close. I need to make sure I have like a scroll lock on the modal. The page should not be able to scroll if the modal is open.

So the fact is, there's a lot that goes into building a modal that people may not necessarily want to handle, which is why they reach for a library. But the great thing is now we have a tool that gives us the exact same features of that modal only using one attribute. Let's take a look at how this modal works. It's the exact same feature. We have the open and animation. We have the click to close. We have the focus states within the modal. We have the closing when you click outside.

In terms of focus trapping, we don't have it doesn't have like an imbued version of that, but you can easily create your own once you have this set up. When it comes to HTML modal, all we need is this one attribute here. Popover is an attribute that lets you create modals whenever you want. Once you click the popover, the top layer appears on the page. This top layer is an imbued functionality for popover, handling z-index styling and modal placement automatically. All z-index or focus management is handled natively in popover.

So let's take a look at what is being done in this popover modal here. You notice that once I click the popover, this thing that's called top layer appears on the page. Top layer is an imbued functionality for popover. That means that you don't have to worry about z-index styling or where you're placing your modal on the page because popover automatically handles that for you. Anytime the modal is placed on the page, popover creates a top layer. That means the modal will always appear on top of everything.

This is also really great because if you have multiple popovers, if you have nested popovers, it just creates the top layer in accordance to how it was created. You have top layer 1, top layer 2, top layer 3. You don't have to worry about any z-index or focus management because all of that is handled natively in popover. If we take a look at what our popover looks like here, you see that it has a popover and then it has a top layer 1. Once the popover is closed, it's set to hidden and it disappears from the page as you want.

I think popover is a really cool tool that doesn't get used a lot. It's one of the super useful HTML tools we have these days. I'm also using the popover here for this sidebar. You can use popover for a number of implementations, whether you want to build a tooltip, a sidebar, a menu dropdown, a modal, basically anything that you think needs to appear on the page without handling the appearance yourself. Popover is a great option for that. Let's start with popover. Then we have scroll animations, which I'm very excited about due to the challenges faced in setting up intersection observer or monitoring scroll states when writing React components.

So let's start with popover. And then we have scroll animations. This is one that I'm very excited for because I think scroll animations have been the bane of my existence since I've been writing React's components. Every time I have to set up like intersection observer or start monitoring scroll states, it's just, it's a lot. So let's take a look at how the scroll animation works in React. And we can see our render counters here. See everything that's happening.

So if you have your performance here, you should be rendering. All right. So yeah, this is going to have paint flashing. So I really should give a trigger warning for if you are prone to photo-sensitive epilepsy. But yeah, with our paint flashing here, we can see every single time this, and then also we can also see the frame rendering stats. So we can see how often it's calling the GPU. So this is how often a scroll renderer calls, like takes up your memory and has to re-render on the page.

Now let's see that same feature in CSS. You notice that with the CSS, it's not making any updates to the actual page rendering, and it's not using any memory either. So this is a really, really good performative example of how we can use CSS to save so much more memory in our code. But also another thing with scroll rendering is let's say you have a busy main thread, right? Let's say your page is doing a lot of things. This is what happens to your scroll rendering when you start having a lot of things going on in your main thread. As you can see, the scrolling becomes very janky and like very not smooth.

But also another thing with scroll rendering is let's say you have a busy main thread, right? Let's say your page is doing a lot of things. And even though you have the scroll animation on it, you also have, you're running multiple things in the background. This is what happens to your scroll rendering when you start having a lot of things going on in your main thread. As you can see, the scrolling becomes very janky and like very not smooth. This is because since it's all React and it's all JavaScript, they are all running on the same single thread. So every single time you call that scroll animation, if your main thread is busy, it needs to wait for whatever is happening on the main thread to be done before it can call the scroll animation. And that's going to look a lot less smooth than you want.

But with CSS, because it's only handled by CSS, regardless of whatever else is going on in JavaScript space, the CSS is always going to be smooth. It's always going to be fast. So let's take a look at the code that we're using for our CSS here. Okay. So when it comes to our CSS scroll, the main thing that handles that scrolling animation is our animation view timeline here. Here we have it behind our supports. Basically what we're saying is if whatever browser we're using supports animation timeline, then apply this animation timeline. We're setting it to view and we're giving it a range of entries to cover 30%. So basically what this means is start the animation once the item has entered the scrolling container and then stop the animation once the item has covered 30% of the scrolling container.

So this is a really, really good example of how we can use CSS to create more animation. Timeline is a really good example of how we can use CSS to create faster implementations of things that we're previously doing in JavaScript. A really good thing about animation timeline as well is because we are putting it behind supports, a lot of these features are already backwards compatible, meaning that if your browser doesn't support animation timeline, you're just going to see the items without any animation of them. It's not going to be hidden and it's not going to prevent users from being able to access the information. So this is something that's very great when it comes to using the semantic way of building things.

So this is something that's very great when it comes to using the semantic way of building things. Even if the feature itself doesn't work, the content and the information is still passed across. So yeah, that's that for animation view timeline. Let's move on to carousel.

Now this one I'm really excited for because the next two I'm going to show, these are fairly new features, so they're not going to be baseline supported yet. But they are really good examples of how fast the web platform is changing and they are good examples of how new things are being built every day. This is a React carousel. This could be a standard carousel library. This could be your standard carousel implementation, however you want to do it. This is the same carousel using just CSS.

As you can see, it's not calling any rendering at all. It's not using any JavaScript. It's just CSS. And we have our carousel buttons that allow us to scroll this carousel. We have our carousel pagination here that allows us to click through this carousel. And we also have a carousel scroll functionality. So I'm just using my arrows, like my keypad, to swipe through this carousel without any clicking. All of this is done using CSS. So let's break down what is happening here. Firstly, we're using the scroll snap type to move through this carousel. Scroll snaps type is a CSS selector that allows you, you see how when I move this a little, it snaps the next one? That is what scroll snaps type does. It just allows you to snap the next element in any scrolling container. And then we're using the scroll buttons.

Scroll buttons are new features that just came out, I think it was like last year, they were released, so they're still working on making a baseline. But scroll buttons are new features that we can use to control a scrollable container and tell it where we want it to move to. We also have the scroll marker. The scroll marker is what allows us to have the pagination, which means that when we click it, we're like, oh, the scroll marker is set to this value. So take us to that value instead. And then we have target current. So this is what we're using to highlight the colors here, say that, oh, if this is the current target, just highlight it here. So I think this is one of the very cool examples of how far we've come with CSS, because even though, yes, we're just using CSS for display and styling, it is still possible to use it for things that are very interactive, the things that previously required a lot of JavaScript, because the web is just constantly changing. And I, for one, think that's super neat. So, yes, you can also see the code for the carousel here. I didn't share that one because it is a lot, but I will be sharing the link to the repo at the end. So you can definitely go view everything there. But this is the code that we're using for the CSS carousel. And I think it's super fun. So be sure to check it out.

And then finally, we have customizable select. Customizable select is, I watched a talk recently by, I think, Jake Archibald, and he was talking about the history of customizable select. One of the things he mentioned was that I think when select was being, the idea for the select element was being built like 30 years ago, the first thing that the person that wanted to create select said was, oh, but I want to make sure that it's able to be styled. Like I want the user to be able to decide how they're going to style it. And 30 years later, we finally can do that. So yeah, I think that's a really interesting talk. You should definitely check that out. But what I'm really excited about this for is that it's one of those things that it seems so simple, that you're like, oh, why couldn't we just always have customizable select? Like what was the issue there? But then when you see the actual way that customizable select works, you realize that it has taken years of web innovation for us to actually be able to get to this point. So let's take a look at the customizable select here. The one we have in our React is doing all the basic stuff a select does. You click a drop down, it has options. You can click the options and it updates automatically. Fairly simple stuff. As we can see, it's always rendering every time we call it because that's what React does. And then we have the same thing with our CSS and HTML select.

And you notice that when we click it, it does all necessarily updating is supposed to do, but without any of the rendering. So how this is working is using a new feature called Appearance Based Select. And also, speaking back to what I mentioned before about these things having imbued fallback functionality, even if you click Appearance Based Select and let's say a user doesn't support it, they're just going to see the default select anyway. So this is a really good way of making sure that you are using the latest tools, but you're still able to have a fully functional website without needing any other external functionality. If you're not a fan of polyfills, you can just say, okay, for users that their browser doesn't support this, we're just going to show them the regular re-select. So what we have here is we have our select element with Appearance Based Select. We have our selected content, and this is what allows us to be able to show the items here.

And one thing you also notice is that with this one, we're actually able to show images and text, and we're able to style the text. We're able to have different background animations. We're able to put this icon here. These are things I previously couldn't do in Select. In Select, you could only have the options as they appear. But now with Appearance Based Select, you're basically able to style the native select elements the exact same way that you would a custom dropdown. So I think this is one of the really cool advancements that have come to the web platform recently. And I for one, I'm very excited to use it. And that is that on our demo.

So the purpose of this demo is basically to number one, show you that there are different ways of doing things compared to how you were doing them before. So for example, if you've previously been using an accordion library, you can uninstall that now because you have details and it's the exact same thing for a lot less code. Same thing with modals, same thing with theme switchers. These are all features that already exist in the browser. So you can just let the browser do the work. Because at the end of the day, I think that we should always adhere to the principle of least complexity when it comes to building things. React is really good at doing so many complicated things. It's really good at building really impressive websites, but we do not need an entire state management library just to switch between two colors. So when it comes to deciding what tool you're going to use, choose the most appropriate one for the job by choosing the least complex one for the job. All right, and I hope this helped.