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

"They're smart enough to know they're not smart enough to build perfect abstractions, so they do a great job but leave escape hatches just in case"

that's why I prefer Solid instead of React. For client side stuff, Solid is sooo much better than React.

This is totally uncalled for. He's not attacking you. He's explaining a tradeoff, very reasonably.

> I would even say that if this is not a core part of your product, you are simply wasting time and resources.

I find especially interesting that this phrase can be used to defend both sides of the argument. If you are building a highly rich application, chances are that using a framework for that is the right choice, agreed.

But.

Not all the apps being build out there need to be Very Rich Apps. There's indeed a lot of space for only-slightly-rich-but-mostly-static apps, despite the recent HN article.

And for those, introducing a framework is ... precisely, a waste of time and resources.

This is a classic red-herring argument from developers who have not built anything complex with vanilla js. You can build rich interactions with or without a framework, you’re just making different trade-offs (conventions, learning curve, flexibility, tooling).

There is a much larger amount of man-hours put into browser APIs, and web components is one of them. I don’t see anything wrong or that warrants a “you’re wasting your time” warning in his argument. And note, he’s talking about the chrome dev tools everyone including the react team use daily, not “basic forms”.

The path is littered with the ghosts of frameworks past. Don't let the current efforts or trends convince you that we're done with this process. React will be a ghost one day.

In my experience, it hasn't seemed all that significant. These frameworks are absurdly general and cover a range of use cases and deployment methods that most people don't use. I just need the kitchen sink, not everything else.

So far, just using custom elements and a small wrapper around the <template> element, I've not been struggling to create the features I need or would otherwise miss.

I am currently working on an app at work that wants SPA functionality, but they won't let me use any of the frameworks. Tons of vanilla JS and Jquery. I am sure what I have written is probably considered a crime against humanity in some place.

Does it work? Yes. Is it an elegant and maintainable codebase? Not by my definition.

I've built my own framework once out of frustration, thinking typescript will make it easy... after a while I realized that I was just rebuilding chunks of existing frameworks and most likely not in the best way. Webtech is really messy to begin with, typescript didn't really save me. So I stopped. Sure it was nice to know how to build your own viewstack, navigation and state management and how to some newer html5 features, but it really was not the way to go. Vue js seems to be closest match to the way my mind works and built a very crippled version of it minus all the good tooling and plugins. I was also influenced by Knockout and Wpf/C#, so it had some similarities of what I used to do in those. I honestly do not like the way react works or the way it wants me to work, it feels extremely messy too (syntax and project structure)! I get the same feeling from react that I got from own crappy framework!

So anyone reading this, I encourage you to build your own frameworks, but think very carefully if you need it in production and can support it in the long term. Try to keep emotion/ego out of the decision.

I kind of feel that given the "simplicity" of a single class wrapping custom elements, everything is pretty boring.

Note: I cannot do better.

I'll freely admit I'm a backend guy and don't know much about JavaScript frameworks, but the author emphasizes they didn't use Lit, just lit-html, and for the same reasons they didn't use React.

Is lit-html really such a huge portion of Lit that you disagree with their own assessment of what they've done?

This is interesting -> this is the best thing in the world -> here’s how this could be better

The “use the platform” people have been making this case for web components for at least 5 years now. The reality is WC will take off when and if they are a better alternative and even then they’ll need to be paired with some sort of framework. They may even make their way into React one day.

The only thing that bugs me about these takes is React is using the platform. It works great in all major browsers, it’s not some extension like Flash. It’s the platform.

React is over 10 years old and is backwards compatible probably all the way back to its 0.x versions.

Web Components have already deprecated and removed v0 of Custom Elements, and deprecated HTML Imports. On framework/library side: Polymer 1 wasn't compatible with Polymer 2 IIRC, and then Polymer was scrapped and discontinued in favor of lit.

React is a surprisingly safe bet for durability.

One issue I have with lit is that it just forces you to turn everything into a web component instead of a carefully deliberated choice.

Honestly once you get used to it, it becomes second nature... For me at least.

One piece of advice I would give is to not try to ram the hooks use-case into things. It becomes especially annoying when you're dealing with asynchronous values, where you need to deal with 'null' and friends. Sometimes some imperative code in useEffect is simpler to read and easier to maintain; it's fine to step out of the paradigm for some things.

Author also talks a lot about the issues with losing control of the component model when using preact

They can also maintain a “shadow DOM” with its own HTML subtree and CSS scope, so that you can make complex elements whose internal state is encapsulated from the rest of the DOM.

lit-html is completely different from web components and not meant to replace Polymer. lit-html is a library that just handles rendering and lit-element, which is meant to replace polymer uses lit-html as its renderer to make web coponents.

> To re-render, you have to manipulate the innerHTML--usually replacing the string every update

"Usually" is relative, I guess, but nothing's stopping you from using the imperative DOM APIs to update the component's contents; I daresay this would be the typical thing to do. These APIs will be just as performant as anything else out there. What you're really giving up, then, is the reactive programming model. Web Components are just a way of modularizing things; they have nothing to say about how you update the DOM (for better and worse).

You are right (I think) that there's no good way around converting attributes to and from strings, though the performance overhead there should be minuscule in most cases. The bigger problems with that are a) some data (like functions) can't be serialized at all, and b) it leaves a lot of room for passing invalid values

Is this actually how people pass props with Web Components? I've only used web components for a few years but I've always created a new instance of the class and I pass props using the constructor like:

`${new ExampleComponent(props)}`

Then in the constructor it's just this.state = {...this.state, ...props}

Boot up, runtime, micro benchmarks and at scale.

- `jobs` is an array of functions

- enqueue adds a job to `jobs` and starts running jobs if not running

- job running can be triggered by animation frames or setTimeout

So stuck with iframes which although I can hide to some extent, are terrible.

> It is not a call for everyone to immediately drop React and move to web components.

> It is not a blog post declaring React “dead”, or the wrong choice for every project.

> It is not a blog post declaring web components the best solution to all projects.

You might want to consider how well the phrase, "Haters gonna hate," applies to your comment.

Do you have any concrete examples for this? I'm not sure I agree: I've made plenty of stateful components in React and they are just fine. If anything, they're a lot cleaner than what I could do in plain JavaScript, thanks to the framework.

Further, could you expand on what you mean re: recommending changing the key? I have never heard the React team suggesting to do this, although maybe I missed something in the documentation :-)

I've only need the "change key to flush components" trick very few times, and most of those where rush fixes for bugs that had a better "doing it right" fix at a different level.

If you instead are talking about syncing props with state, there are ways to do this as well without changing the key, but this is considered an anti-pattern in the first place.

This sounds more like bashing react without even knowing it very well in the first place.

> React works well for simple, non-interactive components. Complex, interactive components are going to have state. Stateful components don't work so well in React

React components are designed with state in mind. When state changes, components passed that state in the form of props are re-rendered. Don't take my word for it though, from the first paragraph on the reactjs.org website; "React makes it painless to create interactive UIs. Design simple views for each state in your application, and React will efficiently update and render just the right components when your data changes."

> At the point all of the benefits of React (preservation of selection, caret position, scroll position etc.) vanish.

I have never heard these spouted as the benefits of React. The main fundamental philosophy of React is that only components that have state changing "react" to changes - in other words, the benefits of React are: no unnecessary re-rendering (hence the virtual DOM).

> If you want to update props in a stateful component, the recommendation is to replace the component entirely by changing its key

This part just threw me, if you are doing it this way - you are doing it wrong.

They work fine, though managing state outside of components via a state management library is common.

> If you want to update props in a stateful component, the recommendation is to replace the component entirely by changing its key.

Where do you find this recommendation? I’ve never seen anything like it, and keys are usually only used for repeating sets of elements, and you would generally only use a different key if something is not the same logical entity as the thing that previously had the key.

There might be some cases where you want to force a new rather than updated component by the kind of key manipulation you describe, but it's not the general case of prop updates for stateful components.

> It doesn't have incremental screen update, but neither does React, if your components are interactive and stateful.

React does have incremental updates for interactive, stateful components. You can deliberately negate it the way you’ve described, but you should not, generally.