It feels like React is getting a bit of a kicking recently

It feels like React is getting a bit of a kicking recently, which I’m not 100% against, but I can’t stress enough how ingrained React is. It’s what happens when a framework or library is the hot topic for over a decade!

I’ve just been reading “Removing React is just weakness leaving your codebase”. I don’t really agree with some of the sentiment in the article, but I like how the author has referenced concerns about what happens if a big framework player like Vercel goes away. That’s an important and concerning reality. I’m not 100% convinced React is always a weakness though, especially when you apply a bit more nuance.

Vercel are behind Next.js, which is arguably the most popular React framework out there. I guess it feels important to me that they don’t go away because Netlify’s recent fall from grace has had a tangible impact not just on the web community, but also our clients — some of which are now embarking on re-platforming projects, including moving to Next.js. Netlify has just not been good enough for big projects in our experience.

It is always a concern that technology’s survival depends on VC-funded companies, but that’s a topic for another day entirely. One thing that this definitely does though, is create a fragile basis for the web.

Libraries and frameworks can be very useful in complex projects permalink

This is especially in the case of projects that require a lot of complicated state management. This is something that is very difficult and messy, both with web components and native JavaScript. Currently, anyway.

A dream of mine is native reactive state — both global and local — in web components that doesn’t require DOM selection and manipulation. That is something I do very much like about React and Vue. The problem is, you get good state-management with frameworks, but also massive bundles of JavaScript on the client-side as a symptom of that. It becomes a developer experience beating user experience situation. Not great.

I see a lot of weird and wonderful stuff working in client services. In the 15+ years I’ve been doing client stuff — with brief stints in product teams — I’ve never once seen the same project setup. Of course I’ve seen simple websites, over-engineered with React-based codebases, but I’ve also seen the inverse: very complicated systems, stitched together with an SSG, Nunjucks and web components that frankly, are a nightmare to maintain and improve. The incorrect decision has probably been made at the start of these projects and expensive technical debt has also likely been cashed in.

If you want my two cents: React ain’t going anywhere for a long time. I don’t use big tech companies as the barometer for that opinion because big tech companies make up a tiny percentage of the overall industry. They’re just louder than everyone else.

The main reason I think React is going nowhere is because — even though it is very much a minority player in the industry — there are still thousands, if not millions of codebases that are heavily React-based.

Do I like this reality? Not especially, no, but I’ve sort of gotten over it now. I don’t like the fact that libraries like React are so heavily used, but over the years, I’ve grown more empathetic about the decision by teams to use them. The web platform doesn’t currently give us all the tools we might need, but I’m hopeful it will in the longer term. I also get that people can’t wait for that and need to get moving, so libraries service their needs better than the web platform currently does.

It looks like React is going to be releasing a v19 of their framework. Just today I spotted that they are going to be supporting custom elements — AKA web components, which has been requested for 6+ years at this point. It’ll be interesting to see how that works because I think that could be a decent setup: React to do all the complicated state stuff and web components to do the rendering of stuff. It’ll make moving away from React a hell of a lot easier in my opinion. Great for design systems too.

What should you use on your project then? permalink

I honestly couldn’t answer that. Once upon a time I would have tweeted that React should not be used under any circumstances, but at the time, I’d only seen really grim, over-complicated codebases powering very simple contexts. The culture of React discourse was extremely toxic too (still is sometimes) and I didn’t want to support that in any capacity. A few more years down the line though, I’ve seen lots of very complicated projects, underpowered with a valiant attempt to not use frameworks of any kind.

It’s all about trade-offs in the real world. What capabilities do you have in-house? What are the performance needs of your project? Are you on a hard deadline? Do you want to attract a certain type of developer, with a certain skill-set to your team in the long term? Who are you going to exclude by choosing FrameworkX or FrameworkY? Do you oppose a framework’s funding source? What damage does a technology cause for your users?

Lots of questions that should be asked rather than “FrameworkX is hot at the moment: let’s use that”.

All I would say is finding the lowest-tech solution and leaning into browser capabilities as much as possible is a good way to build something resilient and reliable. Also avoiding doing as much client-side rendering (and re-rendering) as possible usually makes things better for everyone too. I like how Astro does that with Islands, for example. I also understand that’s not possible in some projects.

Every project is different and every team has their own problems they need to address. My overall advice is spend a lot more time planning and strategising as you are already doing and always think “what’s the worst thing that can happen?” along with “who are we going to harm with this decision?”. It works pretty damn well for us. Planning is much deeper than breaking projects up into Trello tickets at the end of the day.

Most importantly, don’t base your project decisions on what some dude thinks on Twitter, Mastodon or their blog. That very much includes my opinion too because I don’t understand your project unless you bring me in to help you. Only you and your team do and it’s those opinions and expertise that really matter. Effective communication is the real cheat code.