Why I don't miss React: a story about using the platform

&gt; But the web platform isn&#x27;t perfect, and I suspect most React developers have come across a situation where you’d love to be able to just tweak how your component is being rendered.<p>Honestly, I haven&#x27;t. The only potential caveat I can think of is when you have some non-reactive legacy code you want to embed inside a React component... but even then React&#x27;s escape hatches are more than sufficient.<p>If you&#x27;re really worrying about when your component renders or re-renders it&#x27;s probably because there are other issues with your app.

If all you need is a couple of basic forms and some basic interaction, you can do it all with vanilla JS but let&#x27;s not kid ourselves. This will not allow you to build very rich apps without implementing a significant chunk of the frameworks you dislike so much. In fact, I would even say that if this is not a core part of your product, you are simply wasting time and resources. There is a huge amount of man-hours poured into making these frameworks work correctly under any condition.

&gt; Was this slightly more work than using a library from npm?<p>&gt; I&#x27;d definitely recommend using a library for this, and we settled on lit-html <i>(link to library from npm)</i><p>This article is mostly about switching from React to Lit. You can use modern web APIs (like FormData) <i>with</i> React, FormData&#x27;s not a replacement for state management.<p>You can use Web Components <i>with</i> React, the way Fluent UI does (<a href="https:&#x2F;&#x2F;docs.microsoft.com&#x2F;en-us&#x2F;fluent-ui&#x2F;web-components&#x2F;integrations&#x2F;react" rel="nofollow">https:&#x2F;&#x2F;docs.microsoft.com&#x2F;en-us&#x2F;fluent-ui&#x2F;web-components&#x2F;in...</a>).<p>In this single case they replaced a couple validation functions with attributes. Good to move that direction but if that&#x27;s all you use React for then yeah, you might not miss it much.

The section about trusting dependencies, the scenario where they go away, version churn etc doesn&#x27;t resonate with me in regards to react.<p>I don&#x27;t know any project in JS-land that is more serious about semver, backwards compatibility and reliable upgrades than react. If facebook dropped the project tomorrow, Vercel alone could probably continue to maintain it well.

Both React and Lit&#x27;s approach (that requires schedulers and user uncontrolled updates) are completely unnecessary for most if not all of the applications currently using React and I bet nobody even knows why they exist.<p>Facebook made React like this because of these requirements: they wanted their chat application that requires various real time small updates to multiple parts of the page to run quickly where a wipe and rerender approach is too slow, while being declarative because their constantly rotating staff had trouble writing it imperatively.<p>To meet this requirement you need:<p>a constantly revolving staff that are of varying degrees of competence and can&#x27;t write non-buggy imperative code in the few situations you can&#x27;t just wipe and re-render<p>a situation in your application where wipe and re-render is too slow, AND the situation is too complex to hand-write the individual updates manually<p>The other decision React made that was wrong was the need for JSX. They decided on JSX because they made a mistake many people make when just using the pure JavaScript API for creating components - they tried to make it nested like html using a fluent&#x2F;chained call approach. As it turns out, trying to keep the nested HTML structure is not necessary for readability.<p>My library is github.com&#x2F;thebinarysearchtree&#x2F;artwork<p>After using it, it makes React look like SOAP vs JSON. It has less code, runs as fast as you can get, and everything is in your control because it is just web components with some functions to handle the repetitive parts.

The author makes some fair points but I also think part of it is learning. It sounds like they had finished learning React and the ecosystem and all that was left was finding React bugs, and occasionally identifying ways to work around React&#x27;s way of doing things. While they are still at a stage of learning Web APIs which means exciting discoveries.

It seems that the author switched from Facebook&#x27;s React to [his employer] Google&#x27;s [Lit](lit.dev), and subsequently wrote a blog post in praise of <i>the hand that feeds</i>.<p>&gt; Replacing lit-html would be an undertaking but much less so than replacing React: it’s used in our codebase purely for having our components (re)-render HTML.<p>That&#x27;s high praise. I might take a second look at Lit and style it facilitates.

I&#x27;m moving towards vanilla JavaScript for my platform, and one of the things that I&#x27;ve discovered is that if you have a reactive data source then you don&#x27;t need a lot of framework. Granted, I&#x27;m taking advantage that the core platform is much more stable than a decade ago.

Article makes a variety of already well understood points, but only briefly touches on the most interesting one (from my perspective): durability.<p>If the thing you&#x27;re integrating is an evolving, improving moving target, and it&#x27;s coming out of a team of only a handful of people, double any visible costs associated with your application for the sucker who must build it in 2 years time to add some new feature. It is possible to build a strong and easy to communicate case for avoiding frameworks using long term maintenance costs as the basis.<p>jQuery was actually pretty good at this, it only had one big flag day that I can remember. In that sense, jQuery was much closer to what <i>you get for free</i> working directly against the platform interfaces. Deprecation cycles are much, much longer, and burden of proof much higher for new features in the browser than pretty much any third party framework.<p>Somewhere here on the thread there was slander directed at Closure Library &#x2F; Compiler. In this context, that is so totally tone-deaf, Closure Compiler&#x2F;Library projects from 2010 still build with little to no changes today (based on local experience). I can&#x27;t say the same for any alternative I have used in the past decade.

Really enjoyed this article. Web components seem promising, I played around with them a bit but I found it difficult dealing with global styling (ie, how do I make my component have the same colour scheme as everything else?).<p>Probably worth looking into again.<p>I also concur with the author about lit-html. It does one thing and does it really well, easy to understand, and no transpiling needed. Can&#x27;t recommend it enough for generating dynamic html client side.

Tried Lit and StencilJS.<p>They are both forcing the usage of custom events to dispatch functions and share data between components. It&#x27;s horribly unergonomic. Using the DOM with event bubbling and capturing feels really bad.<p>Orchestrating rendering is a mess.<p>The Shadow DOM and templates don&#x27;t really solve any issues that aren&#x27;t already solved with things like CSS modules for style scoping and even using element cloning is faster than templating.<p>The only thing they have going for it is that they&#x27;re a nice way to share 3rd party components as an alternative to iframes or JS library API which targets a DOM node with a parameter.<p>And you can use any small framework like Preact, Svelte or SolidJS and wrap it with a web component.

The rendering part resonate with me. I&#x27;ve tried in some side projects SolidJS framework and I really enjoy that the rendering of each component occurs once! Easier to not fall into some traps that React has.

This reminds me of those posts like &quot;Flask is better than Django&quot;. Sure, if you want to reinvent 90% of what&#x27;s given to you for free with the bigger framework.

It’s bizarre to see the author waxing poetic about the small size of lit-html when it’s actually no smaller than Preact.

I admit I don&#x27;t really understand the web components&#x2F;cusotm elements &quot;story&quot;. (I&#x27;m not even totally sure the right terminology, or what OP is talking about specifically).<p>Are these now useable on any contemporary browser? Or do you use some kind of polyfill? Anyone have a good from-zero tutorial for the approach OP is talking about?

I wish I didn’t say this but I just hate using React now. What was once simple is becoming more and more complex and I wish I had just stuck to a more batteries included framework like Angular&#x2F;Vue&#x2F;Svelte but the time has passed now. I’m just glad I don’t have to work on Frontend anymore.

I use plain JS, couple of libs and web components for business front ends. Works like a charm. Never needed React. It was created by FB to solve FB problems. Being small company this React approach to me it is just plain overhead.

In my projects I use cycle.js&#x2F;snabbdom and I&#x27;m already following many suggestion of the article (es. form data). My next goal would be to discard snabbdom (and virtualdom) and use custom elements. For that I&#x27;m evaluating a library like <a href="https:&#x2F;&#x2F;github.com&#x2F;WebReflection&#x2F;uhtml" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;WebReflection&#x2F;uhtml</a> and all it&#x27;s ecosystem of utility

Everything on the web &quot;uses the platform&quot;. There&#x27;s no other way to get content into the browser.<p>Web Components are just a part of that platform, and very badly designed at that. A lot of the platform around them now exists only to patch holes in them (like form participation) and to solve the problems they introduced.<p>And since they are now a part of the platform, they poison everything like upcoming CSS scoping which instead of being a straightforward thing now has to account for all the web component insanity.<p><i>Edit</i>. There also so many thing wrong in the article that argh.<p>&quot;We don&#x27;t need React and dependencies&quot;... and then talks about lit-html which is a small framework with custom syntax and constraints on how you can use tagged literals.<p>&quot;Easily replaceable dependencies&quot;... and again talks about lit-html which is a fully incompatible replacement for Polymer. I wonder how folks that used polymer (Youtube) feel about &quot;easy replacements&quot;.<p>&quot;Can&#x27;t control rendering with React&quot; and talks about Web Components which literally give you no control over when a component can be rendered, don&#x27;t have lazy loading, cannot subclass SVG or embed partial SVG etc.<p>And so on and so on...

Come on over rovers: <a href="https:&#x2F;&#x2F;github.com&#x2F;cheatcode&#x2F;joystick" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;cheatcode&#x2F;joystick</a>.<p>I promise you&#x27;ll love it if you&#x27;re switching from React (pure HTML, CSS, and JavaScript w&#x2F; minimal abstraction). And it&#x27;s full-stack so no more stitching together frankenstacks. Good ol&#x27; isomorphic JS for devs who value their time&#x2F;productivity.

Few things that annoy me about react are mostly minor personal missed details like stale state in websockets, sometimes asynchronous state updates&#x2F;wrong order; things you expect to work in a certain way but don&#x27;t. Then it&#x27;s like &quot;you should use a [use]Reducer for that&quot;. Generally I like react&#x2F;my go to. Just sometimes it does things not intuitive to me.

I think React is great. In Some instances of useEffect can seem inscrutable. I believe svelte is a great counter to a lot of the ceremony in React and I see it as the most compelling “framework” available. I sorta miss JSX with it but it’s not that important after a while. I find all the tech and rhetoric that comes from Google Dev Rel people (excluding a few gems) to be either pretty damn good but evangelized distastefully or just straight up incoherent. I find everything thing with web components and shadow dom and all that abhorrent. Yeah it’s the “platform” but the APIs are super complex, convoluted and filled with caveats all to not use a framework. I also believe the narrative that big JS bundles are ruining the web is a diversion. Google, and more specifically, monetization and advertising is ruining the web directly. Large JS bundles are secondary. Advertising and ad revenue ruined the web before the much aligned SPA.

The problem with Web Components is it&#x27;s slower than React or other vDOM implementations. Also everything is a string. To re-render, you have to manipulate the innerHTML--usually replacing the string every update. To pass a prop to a component in a modular way, you have to pass a string attribute (e.g. something like &lt;my-component my-attribute=&quot;[1,2,3]&quot;&#x2F;&gt;). Even though v8 is extremely fast at string operations, it&#x27;s just not a good practice and doesn&#x27;t scale.<p>W3C standardized Web Components before React existed and took off, unfortunately. I expect the next standard to just be React itself (or a barebones version that the library can build on top of), patent licenses permitting. I&#x27;m pretty sure as a C++ precompile, it would be unstoppable and end the debate for good.

There&#x27;s pointers here to interesting new things which I&#x27;ll have to learn more about.<p>One of the core values for React for me is simply code structure - organising things into a hierarchy of elements seems to make sense - I found that hard to replicate when I once tried to build a vanilla js application.

I&#x27;ve really enjoyed using HTMX + Flask rendering HTML. It seems very ergonomic.

Few of the comments seem to focus on Lit, the &quot;anti-framework,&quot; which is a very valid alternative.<p>In Lit, there are *no* pre-built components. No boxes or buttons or controls or routing. None. You make what you need.<p>Sounds daunting but, as the author points out, it frees you from cruft. You make only what you need. YOU design the API and syntax. And you add&#x2F;remove whatever you want, whenever.<p>It would be hard for me to go back to canned components after Lit! Try the interactive tutorial:<p><a href="https:&#x2F;&#x2F;lit.dev&#x2F;tutorial&#x2F;" rel="nofollow">https:&#x2F;&#x2F;lit.dev&#x2F;tutorial&#x2F;</a>

&gt; In our case, we still felt this decision was justified because we don&#x27;t have to recreate a scheduler with all the complexity of React&#x27;s; we can build a small, self-contained implementation that only implements what we need.<p>I wish there were more details about this. Implementing a small scheduler seems like a monumental task and I&#x27;d love to learn more about how to implement a base-case.

Whenever I see a few internal apps made with React&#x2F;Vue, they would miss super basic features such as highlight-able text or canonical permalinks.<p>It got me thinking, why these frameworks make simple things difficult?<p>Note that I am a backend&#x2F;infra engineer (but I am able to build complex web app using jQuery back in the old days.) so I may be missing something here.

It&#x27;s so strange to me how not using a framework is so often displayed as the &quot;simple&quot; solution. Not using a framework basically means using global, mutable state. This is maybe ok if all you need is one or two dropdowns. But anything further it isnt the way.

Aren&#x27;t web components more of an addition to frameworks like Bootstrap than a React replacement?

Same here. I&#x27;ve been slowly getting rid of old React components on both SaaSHub &amp; LibHunt. It&#x27;s much easier to go forward and maintain your code when there&#x27;s less JS complexity. For the curious ones - these are both Ruby on Rails based projects.

I have known about web components for some time but this article and the linked mdn guide have whet my appetite to maybe give it a try. Perhaps for my next bespoke small web app I can try my hand at web components rendered server side.

Server side rendering ftw

All comments is about developer experience. What about user experience? I find many framework adding a lot of data, loading times, etc. for little gain for the user.

lit-html is great although at $DAYJOB we ran into some issues with missing linting on them.<p>We now use a JSX renderer that emits plain HTML strings.<p>You get all the ergonomics, the IDE assistance of checking for typos in your attributes, ensuring your closing tags line up, and webpack can flatten it back to plain HTML at compile-time for no run-time __jsx &#x2F; React.createElement() calls.

Why lit-html over something like pug?

My ad for web components: btw I used to use react

React works well for simple, non-interactive components. Complex, interactive components are going to have state. Stateful components don&#x27;t work so well in React. If you want to update props in a stateful component, the recommendation is to replace the component entirely by changing its key. At the point all of the benefits of React (preservation of selection, caret position, scroll position etc.) vanish. You might as well use vanilla js instead of React.<p>What does using Vanilla JS look like? Here&#x27;s an example: <a href="https:&#x2F;&#x2F;github.com&#x2F;wisercoder&#x2F;eureka" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;wisercoder&#x2F;eureka</a> It uses two tiny 500-line libs. It uses TSX files, just like React. It has components, just like React. It doesn&#x27;t have incremental screen update, but neither does React, if your components are interactive and stateful.