Stop Using React: It’s time to let it go

Hello. Okay. My talk. Stop using React. It's time to let it go because it really is. So as John said, I'm Siobhan. I'm been a web designer developer for the past sixteen years, but even longer if you count my teenage years as well. I started learning to code in the early two thousands.

And during my time, I have seen a lot of changes in the way we develop websites. We've gone from building static server rendered websites with HTML and CSS and the tiniest bit of JavaScript to using JavaScript for the entirety of the website build with client rendered SPAs to realizing, hey, you know, that might not be such a great idea and moving back to server rendering sort of with Java's JavaScript frameworks like Next.

Js. But what's next? Which is what we are going to talk about today in certain web development circles. There's a few on the Fetiverse like Hakiderm and Front End Social. There's been a big push towards the rethinking the way that we build websites. They should be accessible and quick to load and work for everyone.

And the easiest way to do that is to go back to the way we once built websites maybe, but in, like, a more modern way. So before I begin, I wanted to give a few disclaimers about what what my talk is and what my talk isn't. I know my title was very clickbait, and this talk isn't going to be me ragging on React itself.

But because I think of it in a microphone, I'm just gonna say. And this is pretty much about all front end JavaScript framework frameworks in general, even though I have used them quite extensively. Men really be out here inventing entire JavaScript framework so they don't have to learn CSS and HTML. And I think that's the only reason they exist, honestly.

But now that's done, what this talk is, the main reason, that's not the main reason why we should stop using React, but it's valid. We need to rethink our use of all client side JavaScript frameworks in general. So today, we'll be exploring how the web worked before SPAs came onto the scene, what it looked like when SPAs were at their peak, and what the web looks like now, and what we should all be thinking about when we start to architect a new web project instead of just jumping into our favorite JavaScript framework. And this will be explored kind of through the lens of my own experiences throughout my career.

So when I first started building websites, I was barely writing any JavaScript. This was way back when in 2009 when I first started actually working. It was the era of the Internet when we were literally cutting up Photoshop files so we could make buttons with rounded corners because you couldn't do that yet. The entirety of my job was building out HTML templates and styling them with CSS. They would then be used with a back end written pretty much in PHP.

And I would maybe once in a while use some JavaScript but read its jQuery, to create a nice carousel slider, and that was about it. I think I was actually using Flash and ActionScript to create more interactivity for websites than I ever did JavaScript at this stage. But this is how we built websites, right, back then.

This is how web development worked. It's still actually how web development works, probably not the Flash side of things, but everything else, you can still do this. You can build templates in HTML and CSS. And they either be served to the browser directly or you can use them with a back end language like PHP to render content with them on the server and then serve them to the browser after they're already generated.

And the browser will render them and maybe you can do some fun interactions with JavaScript. The web landscape has never stopped you from doing this, but we all kinda stopped doing this. And when did that happen? In the early two thousand tens from my memory. This all changed with the release of SPA frameworks like Angular in 2010 and React in 2013.

I honestly think this is a direct result of the rise of iPhones around the same time, and thus there's a higher demand to make dynamic app like experiences on the mobile web. And this is also around the same time I remember that responsive web design was starting to make an appearance. And when s p a SPAs first came out, they were magic.

Right? I mean, in 2012, the devs and I at the agency I was working at decided to try out AngularJS, on a project for the first time and it was an absolute game changer. Like, what do you mean? I could make everything into a component and two way data binding. I could just, like, type something into a field and all the references on the DOM would just update it.

That's, like, absolutely insane. Because before that, right, if we wanted to do that, we had to write a lot of JavaScript or jQuery and do a lot of manual DOM manipulation and none of it was magic. I built many Cordova apps and web based games with this method actually. Before right before this point, my coworker had made his own JavaScript framework called Scafu to help us do this because it was such a faff. But the benefits were great.

Right? These experience benefits of SPAs were great because the user experience improved because everything was now dynamic and smooth without visible page refreshes. Development was easier because we could now develop with components and data handling was easier. And so I jumped very heavily onto the modern web dev train and went down that path, It was great.

And I actually I didn't see a problem with it until very fairly recently. So if they are magic, why am I telling you to stop using them? We'll go through a few reasons. Firstly, know I said I wasn't gonna react rag on React, but, this is the last time. We need to stop calling it modern.

It's been ten years at this point. But more importantly, it's legacy technology. It was written, for a world that was dominated by I e six, and it shows with how it's structured. For example, its synthetic event system was designed to combat the browser inconsistencies at the time. No other modern framework has equivalents to these kind of things because they don't exist anymore.

Internet Explorer is not supported. Not even Microsoft supports it. So if you're using React, you're using a framework that is bloated with stuff you don't even need. But mostly, my main reason is code running on the browser. It is a bad idea to entrust the browser to run an entire app's worth of code.

Code that runs on the back end is controlled by you. You control the server. You can control how it's performing. Is it slow? Cool. Give it some more RAM. I don't know. You control it. Do whatever you want. Code that runs on the front end is completely out of your control. It is the Wild West. As soon as that code leaves your server and hits a user's browser or device, you have no control over it.

The performance of that is left up to the performance of your, user's device. And why does this matter? Because HTML, CSS, images, and fonts can all be parsed and run on low end devices at near wire speeds, so it's very quick. But JavaScript on the other hand is at least three times more expensive than this. But that's totally fine, you say, because CPUs are fast enough because everyone has a decent iPhone and sure, lots of people are, and a lot more also on the latest Android.

But I can guarantee you there's someone out there accessing it on an iPhone phone and a low end Android and a Samsung TV, Internet browser, and their Android fridge. And, yes, I have worked on a project where we where we received a bug report from a fridge, an Android fridge, so it does happen. But, yeah, this isn't right.

Premium devices like iPhones are mostly absent in a lot of markets worldwide due to the global wealth economy. The Australian market is sitting at about 60% market share towards iPhones and top end iPhones. This diagram here is taken from Alex Russell's blog about the performance inequality gap, which is a fantastic read.

If you haven't read any of his blogs, please go and read it. And so this graph here shows the market share of devices in the Latin America region. There are over 600,000,000 people here, and iPhones make up less than 6% of the market share. And this is similar in markets like India, which is sitting around 5%, and we have China, which is only about 20%.

Instead, these regions are opting for lower end Android devices. And because we don't control these devices, the specs of these devices define what we can build. This next graph here taken from the same place, as the last slide shows the single course scores for the fastest iPhone, fastest Android, and the lower end devices. And it shows, very well the growing performance gap between the latest iPhone and the rest of the market.

If we as developers are only building for the devices that we ourselves are running, we will never see a problem with the way we are building JavaScript heavy websites. I honestly have a theory that a lot of developers haven't yet been humbled by having to make an SPA Cordova app run well on an iPhone five in low power mode.

It's an experience, but I urge you all to go out and buy a low end Android and a low end laptop as you build and test your websites on them. Don't just test them on your beefed up MacBook Pro and your latest iPhones most because most of the world is not experiencing it the same as you are.

Okay. So should I stop using SPAs altogether then? Maybe. It depends on the sites you're building. Here's a flowchart taken again from, Alex Russell's blog. It shows the questions you should be asking before you launch head on into building a new project. Basically, if you're building mostly static content driven websites like a blog or a shop or a marketing website or a dashboard, then no.

They're much faster alternatives. But if you're building something with a long dwell time and lots of data updates like a game, then, like, maybe it's the right choice. Maybe. Not a yes. Just a maybe. Cool. So what should I use then? There are actually so many modern alternatives for what we can use.

But before you even jump in, you need to stop and think who your users are because what you're intending to build is for your users at the end of the day. They matter more than what you prefer to build it in. And overall, they're not going to even notice or care what the thing is built in as long as it works and it loads and it's quick. So some good questions to ask beforehand are how are my users accessing this website?

What devices are they using? Is it mostly mobile? Can I get the data to show this? Where are my users located in the world? Are they in Australia with, you know, fast Internet connections? Do I know what if they are in Australia, cool. I know they're probably 60% iPhone, but if they're not, then I need to go and find that out.

What kind of networks will they be accessing my site from? Is it mostly four g or five g, or are they, like, on a wired Internet connection? How can I find out how fast it is at their location? And then what value am I even providing with this service? Is is there any point to me even building this website?

And just how long will the sessions be? And then next, what type of site are you building? If you're building an informational site like marketing sites and blogs, they will generally have short session times. And when they are attached to a CMS, they mostly usually are, their data models are stored on the server, which means they are the perfect candidate for not being a client side app because they don't need any client side data abstraction or updates.

But cool. What about something more complicated like an ecommerce website? Surely that can be an SPA because, you know, there's data updated on the front end. Ecommerce sites have been running server side for over twenty years now. There's very little, if any, shared between the screens. All of that is server generated. Again, they're perfect candidates for not being an SPA.

But if you're making a game or a cool futuristic web experience, like, okay, maybe go for it. Progressive enhancement. Progressive enhancement is basically the earliest web dev approach where all of the essential content and functionality are prioritized first, ensuring a usable and therefore accessible experience for all users.

Then additional features and enhancements are layered on top for those with modern browsers and fast internet connections. Basically, when you're building websites, you should be focusing on building a solid foundation of core functionality with HTML itself. HTML is fault tolerant by design. The browser will ignore any markup it doesn't understand.

Any markup that is broken. It will just ignore it and continue to pause the rest of the page. That means older browsers are very likely to be able to load the HTML for your website even if there are bugs in it. Or if you are using features that are only exist on one browsers, older browsers will still support this.

Ideally, a user should be able to navigate through your entire website using only HTML. So if CSS doesn't load and JavaScript doesn't load, ideally, your website should still be working. Next, you would add your CSS, which is also pretty fault tolerant. It means, you know, if one of, your declarations it doesn't understand or is newer, it will just ignore it and continue rendering the rest of the CSS and it will work.

Again, you should avoid CSS in JS because if your JavaScript doesn't load, then your CSS won't either, and that's bad. And then you would add on improvements with JavaScript for the users that can access them. And the JavaScript layer is the one that is not fault tolerant. So if your JavaScript errors out, your entire site won't work.

So it's not a good idea to build your entire website with JavaScript. But overall, the core takeaway here is that your web your website should work if the users have JavaScript turned off on the browser. I found that the UK government website on progressive enhancement is one of the best sources for why we should be using this approach and avoiding all client side JavaScript frame frameworks.

Look it up. They have an entire design system that you can pull down and play with. It's built just using h, HTML and the Nunjucks templating language. But okay. I hear you. We all wanna use frameworks. I do too. Writing HTML, CSS, and JavaScript can be a bit of a chore, But I do want to counterpoint that and say I recently built a vanilla TypeScript app with Vite, and it was very fun and very refreshing to go back to the basics.

And if you haven't done it in a while, you should try it out because it's it's very fun. But frameworks can really help with code structure and page structure. And, thankfully, there are a heap of static site generation, and templating solutions, and you can use them as is or you can use them with markdown or or you can hook them up to external CMSs and they're great.

The big one here I've listed so we've got Astro, Levante, Jackal, and WordPress. The big one I'm gonna try and sell you on is Astro. I've been using it for a lot of my projects recently and it's great. It's just vanilla HTML and CSS and JavaScript, but you can build with the components and it has routing and it's all, server generated.

And it also supports UI frameworks like React with the form of islands. So if you can't give up your React components, you can pop them into Astro and it will load them separately from the rest of the website. Eleventy is much the same and then we've got Jekyll templating language. And I know a lot of people hate WordPress and I have been on that train before, but honestly most of the client side apps and the Next.

Js apps that I've seen being built would honestly be better off being built in WordPress. There are a lot of ways to build very clean and custom and non clunky websites with it. And sometimes it is just honestly probably the best solution for what you're building. In summary, please think about your users. Try and make fast, accessible, progressively enhanced websites, and, stop defaulting to JavaScript when HTML will do just fine.

Thank you.