I’ve written earlier in the year about how React was getting a bit of a kicking and a contributing factor to that was a seemingly excruciatingly slow pace of progress. That has potentially been remedied by the recently announced React 19 Beta.
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.
