I’ll be honest, a lot of the stuff announced went completely over my head, but the jewel amongst all of that was the increased support for web components and custom elements.

React has long been a criticised for their their low performance on the Custom Elements Everywhere benchmark, but the additions in version 19 Beta might drastically change that. Before, React was getting a paltry 67% score, in comparison to the vast majority of React’s competitors getting over 90%. That’s all change with React 19 Beta though, boasting a 100% score. Impressive stuff.

I’m always leaning towards the platform and especially so with custom elements. You might remember how deep I got into them and native web component stuff in general, in 2018, after Monica Dinculescu delivered an astounding talk at Google I/O ’18. Since then I’ve used them a lot and in some cases for client work, their capabilities have been really stretched. One stumbling block there was that managing state in a densely custom element powered front-end was really tough and got messy rather quickly. One thing React is very good at though, is managing state.

Look, it’s no surprise that by nature of working in client services, we see a lot of different types of codebases at the studio. React features quite a lot, but so do all different types of technology combinations. Every client is often — and should be — running their own race at the end of the day.

There are some projects on our radar though that I think would really benefit from the efficient state management of React enhancing an already well populated collection of web components. The above mentioned project would definitely benefit from that.

On the other hand though, integrating React as a state management later is a hell of an undertaking in terms of major surgery on a platform. One of the scariest parts is that admittedly, a lot of these components do a lot more than what they should be: rendering an output and sometimes, sending data back. They would need extensive refactoring which immediately puts us in major feature territory.

At that point, does it not make sense to rearchitect components in JSX? Maybe, but what you don’t get with JSX is interoperability because unlike custom elements, JSX isn’t a web standard. The investment in using custom elements seems quite cheap with the knowledge that React will probably fall out of favour, which up until recently, based on the slow speed of progress — amusingly which is often a critique of web standards by framework enthusiasts — seemed sooner rather than later. Sure, platforms like Astro and libraries like preact use JSX, but I think we can all agree, it’s synonymous with React.

I also really like JSX to be honest. It’s a good developer experience and makes writing stateful components a breeze. Although I find templating frustrating with “raw” web components and template literals, there are lots of great solutions out there that make that sort of stuff easier, then compile to proper custom elements. It becomes easy to forgo minimal developer experience gains for the greater good.

Saying that, a tool that allowed you to author JSX and stuff like hooks that then compiled to maintainable web components — should a framework like React fall out of favour — might well be a huge success.

It’s going to be interesting keeping an eye on the custom element world with upcoming complete support in React, that’s for sure.

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

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?

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.

You can completely disable the client-side Javascript bundles with this little snippet:

export const config = {
  unstable_runtimeJS: false
};

This is an experimental/beta feature, it seems, but I can vouch for how effective it is because every single page on this site is powered by Next JS and has 0kb of client-side React code!

Here’s an entire page component with this snippet in context, that you can use as a template for pages that you want client-side JavaScript to be disabled on:

export const config = {
  unstable_runtimeJS: false
};

export default function MyLightweightPage({message}) {
  return (
    <article>
      <p>{message}</p>
    </article>
  );
}

export async function getStaticProps() {
  return {
    props: {
      message: 'Hello, world'
    }
  };
}