“React isn't great at anything except being popular.”
When the rubber hits the road, React is good. There’s a hundred thousand tiny little facets of its design that all contribute its effectiveness in getting functional (as in operationally successful) results. I’m no React fanatic. I hate the bundle sizes, the weird quirks with hooks, the footguns with performance, etc etc. But it works, and the results speak for themselves. I recently hacked for two weeks on React, Node and React Native to produce a CRUD app for Chrome and Android. It’s no FAANG app, being hosted locally for the site that needed, no localisation, ugly code, barely optimized… but it works! It has served its purpose well with minimal bugs for months, saving potentially thousands of hours of tedious labour. With React, I can prototype and get results fast. I’ve tried Vue, Angular, Vanilla, Blaze/Meteor, EmberJS, and even tried my own custom framework based on MobX. None were as good for getting results. For a bunch of little reasons, React is just… really effective.
The sentence immediately after the one you quoted was: "Don’t get me wrong: React is good". So dismissing the article on the grounds that 'React is good' doesn't get you very far.
In my opinion React is "great" at a lot of anything, besides being popular. The original author makes the point that other frameworks are greater, and I don't agree with the unqualified nature of that judgement.
React is really effective. And that makes it "great" in my book.
They are almost literally the exact same API. Prior to the “automatic JSX transform”, they were basically identical. That’s how both libraries support JSX, which isn’t always exactly a mapping to h but is almost totally in both React and Vue (and Preact, and even in Solid if you ignore recommendations to use its custom JSX transform). The API you’re criticizing is specifically good because it enables what you prefer in React.
What do you mean by a component that takes an arbitrary node to render?
Do you mean a component that renders out to a node?
Or a component that takes in a node external to the component so it can render to that external node (as opposed to or in conjunction with a node inside the component)?
If the first, isn't this just the job of the component's <template> or jsx?
> Duplicate vnodes doesnt work, so you HAVE to use some function to generate it instead?
Yes. Mutable vnodes is a huge mistake that I've done long time ago when I've tried to figure out how to write efficient diffing algorithm (2014-2015), and a lot of libraries copied that terrible idea without deep understanding why I've done it in the first place.
That... doesn't make sense. The user isn't complaining that React is bad, just that your app is bad. And your app is bad because you handled history incorrectly, which has nothing to do with your choice of UI framework.
You know what else works? HTML <form>. And I guarantee you 100 percent the <form> is miles ahead of your React "app" in internationalization, accessibility, performance and portability.
I’ve built many real world web forms. React (or similar) is the only way to keep them sane.
Interdependencies between fields. Toggling visibility, dynamically changing drop downs based on previous values.
They almost always require local and remote validation. Sometimes long running validation that needs to be triggered early so it’s done by “submit time”. If it’s not done the submit needs to wait.
Any and all invalidation based on changing previous fields. Adding explainability. Submission preview. Mixing multi-media with regular text values. Complex error messaging that sometimes requires interactivity (e.g. uploading images may have errors for image quality and it’s nice to have the ability to crop or re-center an image from the error message).
If you think my requirements are over and above, maybe, but if you care about user experience it’s critical.
If you think the forms I’m building are “overly complicated” and “rare”, I disagree. Almost all of the above even apply to one of the simplest/very common usecase: “What is your address?”. eg handling global addresses with ergonomic drop downs, postal code validation, previewing the address and asking for user input for normalizing the address, etc. Similarly very common use cases for forms, contact information with phone number and/or email validation.
Using web forms is basically impossible or at best user hostile in 2022.
No, because as a user your React "app" fails to serve my basic needs. Web forms work. (I don't care that they're ugly or don't fit your corporate style.) I also don't care that they made your life difficult as a programmer. Sorry.
P.S. I've done my share of frontend programming too, so I feel your pain. Kind of. But sacrificing user experience for developer experience is not the way of the future.
> that they made your life difficult as a programmer. Sorry.
> But sacrificing user experience for developer experience is not the way
I think you misunderstand my last comment. It’s not “difficult to maintain ergonomic web forms”, it’s roughly impossible. I know that sounds facetious but it’s true. There are too many under-experienced developers or developers who don’t “want to learn” or respect front end development. As such what should be simple is almost always broken.
Three years ago I joined a team, their “relatively simple” (16ish fields) web form took 3+ seconds to load. I got them to add React (ie increase page weight) and lazy migrate to components over 3 months. We dropped time to interactive to 500ms (including the server latency), improvements got made in weeks rather than the previously scoped months reducing time on task for our users, developers were happier and users reported better feedback.
This isn’t the first time I’ve personally improved a “simple web form” with React, and I know of many such success stories. You can disagree with me. You can argue they were bad developers. You can argue you would never have fallen into those traps. You might be right. But my description above is very much the reality of a very many “simple web forms” and definitely true for all complex web forms. Using a framework is just the better default.
> No, because as a user your React "app" fails to serve my basic needs.
Could you elaborate? Is it the “JavaScript required” issue? Increased page weight? Something else?
Using the Web Platform and using React are not opposites, you can do both. See: Remix as a framework that bakes in these ideas, but using the platform is easily achievable yourself too.
Making this distinction between HTML <form>s and React shows a clear misunderstanding of the programming model that React provides. It targets the platform in a native way. This is how React DOM, React Native, and libraries like Ink[1] work.
Maybe, but I've never (as in not even once) seen a React "app" that didn't try to re-implement the web platform and didn't fail on many user-facing metrics.
“React isn't great at anything except being popular.”
When the rubber hits the road, React is good. There’s a hundred thousand tiny little facets of its design that all contribute its effectiveness in getting functional (as in operationally successful) results. I’m no React fanatic. I hate the bundle sizes, the weird quirks with hooks, the footguns with performance, etc etc. But it works, and the results speak for themselves. I recently hacked for two weeks on React, Node and React Native to produce a CRUD app for Chrome and Android. It’s no FAANG app, being hosted locally for the site that needed, no localisation, ugly code, barely optimized… but it works! It has served its purpose well with minimal bugs for months, saving potentially thousands of hours of tedious labour. With React, I can prototype and get results fast. I’ve tried Vue, Angular, Vanilla, Blaze/Meteor, EmberJS, and even tried my own custom framework based on MobX. None were as good for getting results. For a bunch of little reasons, React is just… really effective.