One criterion the article omitted was portability: I haven't followed React Native for a few years but I imagine a lot of people want a framework that will allow them to share code between mobile apps and web apps.
“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.
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.
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.
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?
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.
I see React as today's PHP... same terrible community, similar issues and also extremely messy code, yet if you dabble with it, you'll find a job where people just don't know any better.
That's another good one. I feel like the crowd that used to code all that horror for Wordpress, Magento, Joomla, and other PHP CMSes, slowly moved to jQuery from backend coding, and then has transitioned to React full-time as things became more frontend-heavy. Still same freelancers from 3rd world countries and junior devs who just want to pay their bills and honestly don't even like computers that much. That's why there's so much terrible software today, not just websites. Back in the 90s and early 00s our industry was full of people who truly loved computers and wanted to make something good. Today you have to really be careful what tech stack you pick, that can make a difference between being surrounded by people who just blindly follow popular trends and real badasses who can make something great out of nothing.
I think the comparison with PHP is somewhat merited in that they're both practical technology communities with a "get stuff done" attitude. React is also often the entrypoint to programming these days (most bootcamps teach React) in a way that PHP used to be. I see this much more positively than you though. There's a lot of good code written in PHP these days. And it's great that programming is accessible to more people.
React is far better designed, though. Far fewer kludges. I like PHP, but it's not the same.
I think React is more like Kubernetes. Not the simplest way to do things, but standardised, various gotchas designed out, lots of ecosystem, and plenty of people who know how to use it.
Doesn't seem like it. It's still the top rated framework according to State of JS.
Also, what would be a better alternative, since you don't like it? Seems like it's yet another technology HN loves to hate, but every developer I know likes it.
It's not that I don't like it; I use it daily at work. It's just that I am seeing far too many people instinctively reaching for it when they need to build a frontend of any complexity, for any purpose. I was like that once myself, and I'm looking back to those days with embarrassment.
Personally, I like the movement back towards the web platform, browser standards, and web components. For many cases, these are more than enough.
The tide will only turn when a competitor arises who has a clear advantage over React. I've all of the major JS frameworks, and while they're all nice, none of them are a no-brainer as far as ditching React.
"JSX is a gotcha-riddled kludge to clumsily shoehorn HTML into a JavaScript function return. The only thing worse than using JSX with React is not using JSX with React."
- JSX is the best part of React. Without it i would not even work on it or even consider any other framework. Hence i consider Solid as the only viable better alternative.
I think people are starting to see the power of it when it's used in a functional manner (rather than early class-based components). A lot of alternate template libraries are only minorly different in syntax and use different styles of interop to handle the crossover. I think .svelte and .riot are fairly close, while still being somewhat html-like, rather than JS first.
That's kinda moving the goalposts. I agree that Solid is one of the more viable competitors to react for the combination of JSX + a VDOM-less model (this operates much like svelte), but my point was that it wasn't *Solely* Solid's use of JSX (there are many others adopting or trying to adopt JSX) that makes it viable.
> Vue is one of the most successful and well-funded open-source projects in history.
Don't be ridiculous. I will not believe such kind of hyperbole without concrete numbers. In 2021, the Linux foundation had a $177M revenue. Does Vue's funding compare in the slightest?
Is revenue really the defining factor of success for "open source"? Is higher revenue the indicator of "well funded"?
I think not. Open Source success would be indicated by adoption. And "well funded" indicated by sustainability of the project.
And in thos regards, Vue is both very popular and well funded. And among open source projects of current era, it is one of the most well known one akin to linux and git.
PS: Comparing a 6yr old project with 22yr old one is hardly fair. Not to mention that linux is quite big in scope
> JSX is a gotcha-riddled kludge to clumsily shoehorn HTML into a JavaScript function return.
Oh boy, now that’s some flame-bait. I don’t like JSX, and like the Author also prefer Vue over React, but I know a lot of people simply dislike other frameworks *because* they don’t have JSX (or, as is the case with Vue, it’s theoretically possible but no one uses it).
> I know a lot of people simply dislike other frameworks because they don’t have JSX (or, as is the case with Vue, it’s theoretically possible but no one uses it).
Count me in that camp. My take is that while JSX isn't perfect, it's less of a cludge (and much more flexible because it compiles down to JS) than the templating languages that other frameworks use. I'd love it if they'd add just a little bit more sugar to JSX though. Support for JS-style comments would be top of my list.
Mine doesn’t work very well in JSX blocks. Partly because I don’t think there is any way to insert a comment inside a JSX tag (to comment out an attribute).
The great part about JSX is some random new framework doesn't need a VS Code plugin to get syntax highlighting, and type checking Just Works.
I can accept a template language for a major framework where I can count on decent developer tooling, but it's a hard turn-off when evaluating niche frameworks.
Not necessarily - bunch of languages have adopted JSX with slightly or substantially different component semantics from React (for example Vue, Solid, Forgo, Crank).
A Crank component (which is an async generator) feels very different from a React component. Likewise for a Forgo component, which uses closures for state and doesn't have automatic rerenders. Solid doesn't have components in the traditional sense at all.
Although the syntax they use for representing HTML is the same, the rest of the framework can have arbitrary design.
Maybe I haven't tried hard enough, but it was a pain doing JSX/Typescript with mithril. All the TSX tooling expects a React API and if you use something else you get a ton of annoying type errors.
I used TSX with Cycle.js for a while and didn't experience too much trouble. Typescript has some simple compiler options to change how it generates JSX or JS and doesn't bundle any types out of the box for TSX: all of the React API types come from React's type library. Sometimes that was more of detriment than if there were base types in TSX because reimplementing mostly the same set of standard HTML elements and HTML-like attributes a third time in a different .d.ts file when switching VirtualDOM implementations was a chore. (It was fine, but it was a chore.)
If you are seeing errors that are React specific, most likely means you just need a subtle tweak in your tsconfig.json.
Definitely not. They’ve always been explicitly implementation-agnostic (literally specified as not having any semantics). An increasingly popular JSX transform (used by Solid) has very different semantics. JSX semantics are more like an s-expression than anything else. Code as data, you can do anything with it you like. I use it to make art and render that to meta links on my personal site. You can use it to render CLIs, or even JSON responses on a server.
Yep, I've recently used Vue instead of React and I hate the magical templating system. Slots, magical rules for variable scoping etc. The templating is IMO way worse than JSX.
I don't care for React one bit, but IMO JSX is the highlight of React. Everything else in React is pretty much just OK at best (and some not even that), and the development of React itself has been extremely slow with very relevant few features.
+1 As someone who never runs into problems with JSX, I have definitely wondered if the criticisms against JSX/React are from people trying to use it in ways that are explicitly counter to its core philosophy.
I think he undersells the virtue of being the “least likely to be regretted.” That is criterion number one for me if I’m trying to pick something that will be used for years into an uncertain future.
Every company I've worked for has some sort of shit show on their codebase. Using React was never a guarantee that your code was going to be great, the tool doesn't determine the outcome. You could have the best equipment and if your builders are trash the house is still going to be mediocre
Depending on the scale and goals, there are huge advantages to companies standardizing on one framework.
Nothing burns more than having to dedicate an additional quarter to a project because half the code you need to finish the task is sitting atop another API or, much worse, in a different language.
And when we're talking web apps, There's real material cost to the end user in using more frameworks than are strictly necessary. React is large, but it tends to be large with a spanning set of features that means you don't have to glom something else in alongside it.
I agree that it is advantageous for companies to standardize but often they don't. React + Vue in one app might be a bit crazy but React in the main app and Vue in an internal app, or some secondary app might be OK. Resume-driven development is a thing, as well as joy-driven development. Devs are gonna be devs! There is a mild conflict between what is good for a devs career and what will make the shareholders of that company the most money. It is almost like a super-polite tug of war over future potential dollars between the two. Mostly incentives align but sometimes not.
The fact that React is “good,” in the author’s own admission, combined with its raw popularity and staying power is why I would still choose it for any greenfield project.
What all these React spinoffs seem to be doing is unlearning the lessons encoded in the React architecture and replacing them with more magic by "helpfully" applying state changes immediately instead of in a controlled fashion. But this is going to create mixtures of old and new state, which creates subtle bugs down the line.
Discussions about VDOM also seem mostly pointless because it is clear to me most people's mental model of how React renders is flat out wrong. If you are redundantly touching the DOM, that means you haven't memoized your components, or you are needlessly making copies of the same state. All of these have far bigger performance implications. In fact, even without memo(...), React renders can halt early.
Quoting from the Use.GPU/Live docs, which is a true React extension with the same semantics:
"If a component renders the exact same JSX object as before, React will not re-render that child, even if the child is not memoized.
So there is a hidden semantic in React: when you construct a JSX expression anew, you are requesting that those children be re-rendered unless memoized. But if you reuse a JSX expression from before, you are implicitly giving permission to ignore any unchanged children."
This is crucial to understand when stacking context providers.
I don't get the sense that React derivatives have been used to build e.g. desktop-class apps. They mostly seem optimized for web sites.
While it is true that React does a lot of things at run-time instead of build time, this is necessary for building truly data driven apps. JSX is really Lisp quoting in disguise. If you can't recognize this, you should probably brush up on the fundamentals.
Agreed. Last year, for instance, I tried Svelte. I had a great time for a while, everything was fairly simple...but then I hit a specific scenario. I can't recall what it was, but it led to me digging as deep as I could into their docs to try and understand how Svelte was doing that whole $ thing. I nearly melted my brain trying to understand it.
That's not to say hooks are much better, but I find the overall mental model to be fairly simple to understand, and I don't often find myself bumping up against React's edges.
That's the thing about react, there basically are no edges or very very few edges left. There were edges in like 2018, but the team has made it relatively easy to do anything you want to do, while writing scalable and maintainable code.
Hooks are much better. The only problem with hooks is that people don't get them. But once you get them, every other approach looks like a complicated pile of shit.
I think the dev community does really poorly with these kinds of abstractions that are very simple but completely unintuitive.
I place a lot of the blame on the React team too. When hooks came out, their docs were absolutely terrible. They probably still are. They were full of shitty editorialising like "we created hooks because we found classes were too difficult for people to understand!", which made every dev I worked with feel insecure for not immediately knowing how to write super awesome clean code.
I'm a big fan of hooks, but I'm still not completely sold on them. I like code that reads in logical sequence, like you're telling a story. When you use `useEffect` to coordinate side effects from prop changes, it makes me feel like I'm reading a story written by Quentin Tarantino.
That being said, it's a relatively small complaint.
>I'm a big fan of hooks, but I'm still not completely sold on them. I like code that reads in logical sequence, like you're telling a story. When you use `useEffect` to coordinate side effects from prop changes, it makes me feel like I'm reading a story written by Quentin Tarantino.
I actually read this as a compliment considering Tarantino himself spoke in an interview about how his non-linear storytelling style comes from the way novels he'd read were written.
I believe you're referring to $ not being fired when another $ below it updates the variable the first $ subscribes to. This is an expected behavior. In Svelte the order of $ matters to prevent infinite loops.
In this example the second $ won't trigger the first $:
let a = 1;
let b = 1;
$: if (a > 0) { b += 1 }
$: if (b > 0) { a += 1 }
With React's useEffect one can easily falls into the trap of an infinite re-rendering:
let a = 1;
let b = 1;
useEffect(() => {
b += 1;
}, [a]);
useEffect(() => {
a += 1;
}, [b]);
Great framework are supposed to prevent this kind of loophole.
I haven't done much playing around with Svelte so don't have any business injecting myself into this subthread, but your explanation piqued my curiosity.
So basically, reactive blocks are only allowed to run once per tick; if a dependency changes after a block has run, too bad, the block won't run again. That is really shocking to me. (I won't say more due to my inexperience with Svelte...)
This is all triggering my memory, I had forgotten how it actually worked so couldn't explain the issue I was having. But it was related to this exact behavior. I found it so unintuitive and difficult to grasp that I literally abandoned the project and decided to build it from scratch in React.
It's a shame because it's an otherwise lovely framework.
Novice react developers reach for useEffect way too often, because they are still thinking in terms of state transitions instead of declarative states. I have spent a lot of time teaching people not to do that. They always end up very happy once they get it, because now they can build complex UIs and have a solid strategy for compartmentalization, which makes bug whack-a-mole go away.
It's not a fault in the framework, it's a fault in their understanding, where they don't know how to implement features in O(N) lines of code instead of O(N^2).
The hint is in the name: you're supposed to think in terms of formal functional Effects that mount and unmount independently and compose orthogonally.
The result will be a code base that remains maintainable even though you've kept on adding more nuanced features over months and months.
Also, your snippet doesn't cause an infinite loop at all because modifying local variables does not trigger a rerender. If you had written setA / setB, sure, it would... but I think this perfectly illustrates the explicit vs implicit distinction.
Great frameworks don't trap developers in local maxima.
I think what you are describing looks a lot like what the Svelte team is trying to achieve with the reactive assignments "$:"
A couple years ago, that feature used to work similar as useEffect, so I got used to use it for transitions, and now is biting my ass because the Svelte team are breaking my transition use-cases
I used to use "$" like useEffect, but now I don't know how to use it anymore
And Svelte still bites my intuitions when dealing with complex objects, most of the times I've manage solve it by separating the code into multiple components, but it's not clear why that happens
I think there’s a strong argument to be made here that the actual code in this scenario is flawed.
What Svelte is doing is simply covering up the flaws in your code by short circuiting an infinite loop scenario which has been coded into your app. This will have unexpected side effects, however.
That being said, I think useEffects is far too overloaded in React, and is currently used for completely orthogonal purposes.
At he very least it’s used for the following completely unrelated purposes.
1. Component setup and graceful dismantling.
2. Syncing with external state.
3. Running code specific to a certain prop being changed.
I think the React team would be highly justified if they created a separate hook for #3 at least. Maybe a usePropsChanged hook that is called when one of the props change, and provides an isChanged function that you can pass a prop to, to check if it’s actually changed (I’m sure someone can come up with a better design than I have in the process of writing this comment).
That would be a semantic which would actually allow you to avoid the code flaw that your code above includes, as opposed to brute force papering it over like Svelte appears to do.
Agreed. I think a lot of people forgot how much pain we went through with Knockout and Angular 1 and similar magic frameworks. We seem doomed to repeat it, in some ways.
I can promise that it doesn’t— nothing is as bad as $digest loop hell was lol. It has its own quirks and gotchas of course, all frameworks do, but it did learn from Angular 1. That said, I’m not up to date on Vue nowadays, I was using it on its first release because we’d been hurt so bad by Angular 1 at the time.
"this is necessary for building truly data driven apps".
So where should we try to draw the line at what is truly the kind of "app" that deserves this much JavaScript, versus a "glorified website" that management wants to see lots of interactivity/animations/etc.?
In my career, I've struggled far less with choosing a JavaScript framework for front-end interactivity, and far more with justifying how much JavaScript goes into Web experiences these days, without any concern for the end-user performance impact or other impacts that may not be as obvious, e.g. accessibility.
Write your code as components. The JS is nearby the corresponding HTML, and thus several teams can work on large web applications because it is so nicely componentized.
Applying state changes in a controlled fashion is just about the last quality I'd ascribe to a non-trivial React codebase. By the time you've finished with all the ceremony of memoizing everything just right so you get acceptable performance you're left with a brittle codebase full of surprises. Making one innocuous change can break all your memoizations. Or you're just as likely to find something failing to update because it's been over memoized. Manually managing all the dependency arrays for all this is very poor DX.
React deserves credit for bringing fresh thinking into the JS framework space but there's a tremendous amount of room for improvement.
So don’t memoize unless you need to. Most of the time, you don’t. This is a fairly classic case of overeager optimization. The state changes shouldn’t* particularly depend on memoizations anyway though as memoize should be mostly for view stuff (which should* be idempotent) rather than model stuff.
* = subjective and there are a few rare exceptions
If you want acceptable performance in a reasonably complex react app you absolutely have to memoize. The fact you think this isn’t the case suggests to me you haven’t worked on a big react app.
There’s a significant difference between having to memoize and having to memoize tons of stuff.
Generally you should only need to memoize a few things, and if you find that your app becomes brittle due to the amount of memoization you’re doing you probably are not handling state in the right way. If you’re using Redux that’s a common reason for this; don’t use Redux (is my advice). And yes, I’ve worked on several large enterprise React apps at successful startups.
It’s worth to note that this crucial to understand thing is only ever mentioned deep inside the API reference. If it’s this essential and never once mentioned even in the advanced section of the documentation, that’s on the project and not on the developer struggling with react. They are using it as advertised.
For context, the author has only been working professionally as a front end developer for about three years - so has no such memory of $digest or ko.computed() or other such miserable kludges.
Bingo. The great lesson that React learnt from Flex is that your Components should just be code. In Flex your fancy MXML components are 1 to 1 mappable to plain Actionscript.
Not templates, not an opaque resource bundle, not some whole other thing. Just code.
React is a mature project with a huuuge ecosystem of libraries and components. It is wery well tested. While not being particularly great at anything, its not worst at anything, either. I dont expect a competent dev to ever encounter performance issues with it.
Other frameworks have their own problems. Solid requires a custom babel compiler plugin. Some are new and lack components, placing a huge backlog to reimplement everything from scratch, just not worth it.
We need a framework that will not tie components and libs to itself, so they can be used with other frameworks or with plain ts as well.
> We need a framework that will not tie components and libs to itself, so they can be used with other frameworks or with plain ts as well.
That's why I wish web components would see greater adoption. Having worked through jQuery, Backbone, Sencha ExtJS, AngularJs, Angular 2 and React over the course of a 15 year career, It's frustrating when you can't switch frameworks because the cost to rewrite your existing components trumps the potential efficiencies of adopting a new set of design patterns and affordances.
"Good enough, let's spend time considering other things instead: React"
It may no longer be the best at anything anymore, but it's a polished well-rounder that will probably be fine for the typical web app. Less cognitive load when you just use it and follow the herd.
Are you putting react there because you consider it to have the largest learning curve? If not, I'd probably substitute Vue.
When I was first getting into reactive frontend frameworks it was part of a time-sensitive project, and we chose Vue because we could basically just write HTML and sprinkle in the reactivity. This was back in the Vue 2 days before they made everything functional, and I still think that older Vue API is the most self-explanatory for people who already know HTML and some vanilla JS.
React wouldn't be my pick for scalability. For large, complex and dynamic pages, its performance is significantly degraded by the virtual DOM. There are various workarounds to limit the size and frequency of virtual DOM renders, but they can only go so far, which is why we now have concurrent mode. Solid and Svelte are more scalable in that sense.
Learning curve: Hooks can be quite unintuitive for the React beginner. React's learning curve was far gentler when all components were classes and the lifecycle was simpler.
I dunno, I’ve been with React for 4 years now, and while I’ve seen a lot of funky stuff, hooks weren’t generally the issue (though I wouldn’t say never).
What's the point of this article? An attention getting headline followed by some bombastic claims followed by walking them back later in the next paragraph. It's like generating debate for the sake of debate.
I get the impression these things exist just to keep engagement numbers up
This article really undersells the value of a stable, popular API.
React keeps getting picked because it has an ecosystem. And that's the most valuable thing for medium to large scale enterprise jobs. Web developers are positively thirsty for abstractions that are powerful enough to get the job done without having to learn something new in 2 years.
In an industry of near perpetual churn for the apparent sake of churn, having something you can just cling to that does the job almost all of the time is great. You can focus on the actual problems you want to solve while someone else burns their time arguing whether you could solve them faster with Vue, hypothetically, in a spherical development environment where everybody on the team was already Vue experts.
And yet because they're still under one framework they inter-operate relatively smoothly.
Far more smoothly than if one were trying to change from React to another framework. All of my old class-based components still work under my React hook-and-function code.
I've had the opportunity to train junior developers on React, Vue, Svelte, Solid, and even Angular. And I've used Ember professionally.
The objective time-to-profficiency has made React (and Solid which is quite similar to React) the most obvious choice for us, and I'm one uncomfortable with consensus. Svelte doesn't quite have the staying power of React or Vue yet. Since it's a superset of JavaScript, it's harder to teach, and the component frameworks just aren't there yet. Vue is great, but Vue 3 took a step towards performance and a step away from intuitive readability IMO- it's probably better suited to a team with homogeneously high experience.
How is it similar when React lets you write non-incremental algorithms when you working with your state and with Solid you are forced to write incremental algorithms? Simple aggregate (GROUP BY) use cases that your average junior developer will be able to solve in 5 minutes with React will be a huge problem even for experienced Solid developers. The only similarity is that it is also using JSX syntax, but with completely different semantics.
Personal viewpoint alert: I deeply despise React, and have turned down job offers simply because they made that framework choice. Vue is so much more simple and concise, and its CSS markup in particular is just incredibly good. If anything, React gives you way too much rope to hang yourself and you end up with some mess like quoting CSS inside of some object to apply to another object
In my opinion CSS should not go anywhere near the component code. With bootstrap or something similar (even some dissimilar frameworks), much of the "extra styling" is achieved with utility classes. Not using utility classes and a consistent, thought-out CSS frameworks leads to great pain when scaling the codebase.
Bootstrap is a lot like React. You don't appreciate the "bloat" until you need it. Or worse, you recognize you reimplemented the wheel a dozen times without noticing and most of your "wheels" are polygons with a different number of edges.
The majority of my Vue SFC have no css/styling in them - using the utility classes of a general library (bootstrap/etc) is generally pretty good. There are times when you do need some override, or something custom local to a specific component. Scoped CSS in an SFC is very useful. I had to do some react a couple of years back and I was more than a bit surprised it wasn't supported. "Oh, you can use this plugin" but... the other 4 people on the team didn't use it, discouraged it, and saw nothing wrong at all with needing to coordinate style changes specific to one component in relatively disconnected style files. I got one "it's better this way" but I think he was meaning "this is what I already know".
In my opinion it is harder to get stuff like alignment right. The various utility classes in Bootstrap (and other framework) are a blessing because you can have things like "give me two times the usual margin to the right" without having to hardcode the margin value.
Using any specific CSS - scoped or unscoped - for a particular component is not a good sign. This might not always be avoidable.
Vue has a mechanism for that, but you can't really exchange it for something that fits your needs. It's going to be there, trying to please you with all the features the upstream developers thought you'd need and you have to program around those feature.
> Using any specific CSS - scoped or unscoped - for a particular component is not a good sign. This might not always be avoidable.
I don't generally disagree. Component-level CSS is something I don't do all that often, but when I do, in Vue, I'm glad I can keep it in the same file (generally scoped). For me, it's easier to spot the edge cases (oh, this is modified, and here's where it's being done).
Even at the component level, you can see use system-wide offsets. "give me two times the usual margin to the right" may be a general rule, but for componentX, something needs to be three timex the usual margin, so... you can still reference a system-defined margin variable, but have that 3x override where it's needed.
Again, not something I do often but, imo, the Vue SFC style scoping makes it easier/safer to do when needed.
If the premise is to be believed, the article is only making the problem worse...
Personally, I can't stand writing JavaScript and prefer to insulate myself against the moving target that is ECMAScript by writing declarative UIs in ClojureScript + Reagent, which uses React behind the scenes: https://reagent-project.github.io/
There is some interesting new stuff on the horizon like Hyperfiddle Photon, which compiles network I/O for you. As for me, an old dinosaur, I'm tired of learning new syntax. Clojure the language has not changed since its release. Lisp has been around since the 60s. It will be around in another 60 years. For me, it is the 100-year language. I'm sure it's not the end goal, but I am willing to bet it will be a Lisp-like.
It's popular to hate on React. I still like it, and much of the "dislikes" I hear come from not actually understanding React and using it in the "functional programming" way it was designed to be used in. Same with Redux.
Vite works with React.
And you can get the same performance as Vue.
I get thé author’s general point. But most of us are not trying to innovate on front end frameworks.
And a CTOs job is to make a better product. Not a playground for their experiments.
316 comments
[ 4.0 ms ] story [ 515 ms ] thread“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.
Sure good devs can learn any language/framework, but there is a learning curve and most write shitty code while unfamiliar with a framework.
Popularity is an important feature.
> “React isn't great at anything except being popular.”
So did you stop reading the rest of the article after you hit that sentence or what ?
React is really effective. And that makes it "great" in my book.
I’m arguing that they keep choosing it because it’s effective and markedly more effective than the other choices currently available.
As soon as you go any amount of complexity higher in your program two way databinding is pure poison.
Two-way databinding is the absolute very worst feature people took from Flex.
Specifically, imagine you a component that takes an arbitrary node to render. Just pass the node to the temple right?
Ha.
This api sucks -> https://vuejs.org/guide/extras/render-function.html
Compared to having “{node}” in react.
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?
If the second, isn't this what slots are for?
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.
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.
[1] https://github.com/vadimdemedes/ink
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.
> 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?
Except the back button doesn't work right.
I see React as today's PHP... same terrible community, similar issues and also extremely messy code, yet if you dabble with it, you'll find a job where people just don't know any better.
I see it as today's jQuery.
I think React is more like Kubernetes. Not the simplest way to do things, but standardised, various gotchas designed out, lots of ecosystem, and plenty of people who know how to use it.
Also, what would be a better alternative, since you don't like it? Seems like it's yet another technology HN loves to hate, but every developer I know likes it.
Personally, I like the movement back towards the web platform, browser standards, and web components. For many cases, these are more than enough.
That being said, solid is hardly the only one out there competing that can use JSX:
- https://github.com/vuejs/babel-plugin-jsx
- https://mithril.js.org/jsx.html
- https://preactjs.com/guide/v10/getting-started#setting-up-js...
I think people are starting to see the power of it when it's used in a functional manner (rather than early class-based components). A lot of alternate template libraries are only minorly different in syntax and use different styles of interop to handle the crossover. I think .svelte and .riot are fairly close, while still being somewhat html-like, rather than JS first.
Don't be ridiculous. I will not believe such kind of hyperbole without concrete numbers. In 2021, the Linux foundation had a $177M revenue. Does Vue's funding compare in the slightest?
I think not. Open Source success would be indicated by adoption. And "well funded" indicated by sustainability of the project.
And in thos regards, Vue is both very popular and well funded. And among open source projects of current era, it is one of the most well known one akin to linux and git.
PS: Comparing a 6yr old project with 22yr old one is hardly fair. Not to mention that linux is quite big in scope
Oh boy, now that’s some flame-bait. I don’t like JSX, and like the Author also prefer Vue over React, but I know a lot of people simply dislike other frameworks *because* they don’t have JSX (or, as is the case with Vue, it’s theoretically possible but no one uses it).
Count me in that camp. My take is that while JSX isn't perfect, it's less of a cludge (and much more flexible because it compiles down to JS) than the templating languages that other frameworks use. I'd love it if they'd add just a little bit more sugar to JSX though. Support for JS-style comments would be top of my list.
<Button
/>I can accept a template language for a major framework where I can count on decent developer tooling, but it's a hard turn-off when evaluating niche frameworks.
A Crank component (which is an async generator) feels very different from a React component. Likewise for a Forgo component, which uses closures for state and doesn't have automatic rerenders. Solid doesn't have components in the traditional sense at all.
Although the syntax they use for representing HTML is the same, the rest of the framework can have arbitrary design.
If you are seeing errors that are React specific, most likely means you just need a subtle tweak in your tsconfig.json.
I don't care for React one bit, but IMO JSX is the highlight of React. Everything else in React is pretty much just OK at best (and some not even that), and the development of React itself has been extremely slow with very relevant few features.
You're not supposed to write single components that span a thousand lines of code nesting pure javascript and JSX elements.
Even better if you can factor out any computation out of the JSX parts into selectors.
It is not like you need to only use one framework per company. There is a lot of melting-pot coding happening out there.
React was probably successful in part because it didn’t require a rewrite.
Nothing burns more than having to dedicate an additional quarter to a project because half the code you need to finish the task is sitting atop another API or, much worse, in a different language.
And when we're talking web apps, There's real material cost to the end user in using more frameworks than are strictly necessary. React is large, but it tends to be large with a spanning set of features that means you don't have to glom something else in alongside it.
What all these React spinoffs seem to be doing is unlearning the lessons encoded in the React architecture and replacing them with more magic by "helpfully" applying state changes immediately instead of in a controlled fashion. But this is going to create mixtures of old and new state, which creates subtle bugs down the line.
Discussions about VDOM also seem mostly pointless because it is clear to me most people's mental model of how React renders is flat out wrong. If you are redundantly touching the DOM, that means you haven't memoized your components, or you are needlessly making copies of the same state. All of these have far bigger performance implications. In fact, even without memo(...), React renders can halt early.
Quoting from the Use.GPU/Live docs, which is a true React extension with the same semantics:
"If a component renders the exact same JSX object as before, React will not re-render that child, even if the child is not memoized.
So there is a hidden semantic in React: when you construct a JSX expression anew, you are requesting that those children be re-rendered unless memoized. But if you reuse a JSX expression from before, you are implicitly giving permission to ignore any unchanged children."
This is crucial to understand when stacking context providers.
I don't get the sense that React derivatives have been used to build e.g. desktop-class apps. They mostly seem optimized for web sites.
While it is true that React does a lot of things at run-time instead of build time, this is necessary for building truly data driven apps. JSX is really Lisp quoting in disguise. If you can't recognize this, you should probably brush up on the fundamentals.
That's not to say hooks are much better, but I find the overall mental model to be fairly simple to understand, and I don't often find myself bumping up against React's edges.
I think the dev community does really poorly with these kinds of abstractions that are very simple but completely unintuitive.
I place a lot of the blame on the React team too. When hooks came out, their docs were absolutely terrible. They probably still are. They were full of shitty editorialising like "we created hooks because we found classes were too difficult for people to understand!", which made every dev I worked with feel insecure for not immediately knowing how to write super awesome clean code.
That being said, it's a relatively small complaint.
I actually read this as a compliment considering Tarantino himself spoke in an interview about how his non-linear storytelling style comes from the way novels he'd read were written.
No, some people actually get them and there are way much better alternatives[1].
1. http://intelligiblebabble.com/compose-from-first-principles/
In this example the second $ won't trigger the first $:
With React's useEffect one can easily falls into the trap of an infinite re-rendering: Great framework are supposed to prevent this kind of loophole.https://github.com/sveltejs/svelte/issues/6730
https://github.com/sveltejs/svelte/issues/6732
So basically, reactive blocks are only allowed to run once per tick; if a dependency changes after a block has run, too bad, the block won't run again. That is really shocking to me. (I won't say more due to my inexperience with Svelte...)
It's a shame because it's an otherwise lovely framework.
It's not a fault in the framework, it's a fault in their understanding, where they don't know how to implement features in O(N) lines of code instead of O(N^2).
The hint is in the name: you're supposed to think in terms of formal functional Effects that mount and unmount independently and compose orthogonally.
The result will be a code base that remains maintainable even though you've kept on adding more nuanced features over months and months.
Also, your snippet doesn't cause an infinite loop at all because modifying local variables does not trigger a rerender. If you had written setA / setB, sure, it would... but I think this perfectly illustrates the explicit vs implicit distinction.
Great frameworks don't trap developers in local maxima.
Do you have any links where I could read more about this? Or examples?
A couple years ago, that feature used to work similar as useEffect, so I got used to use it for transitions, and now is biting my ass because the Svelte team are breaking my transition use-cases
I used to use "$" like useEffect, but now I don't know how to use it anymore
And Svelte still bites my intuitions when dealing with complex objects, most of the times I've manage solve it by separating the code into multiple components, but it's not clear why that happens
What Svelte is doing is simply covering up the flaws in your code by short circuiting an infinite loop scenario which has been coded into your app. This will have unexpected side effects, however.
That being said, I think useEffects is far too overloaded in React, and is currently used for completely orthogonal purposes.
At he very least it’s used for the following completely unrelated purposes.
1. Component setup and graceful dismantling. 2. Syncing with external state. 3. Running code specific to a certain prop being changed.
I think the React team would be highly justified if they created a separate hook for #3 at least. Maybe a usePropsChanged hook that is called when one of the props change, and provides an isChanged function that you can pass a prop to, to check if it’s actually changed (I’m sure someone can come up with a better design than I have in the process of writing this comment).
That would be a semantic which would actually allow you to avoid the code flaw that your code above includes, as opposed to brute force papering it over like Svelte appears to do.
So where should we try to draw the line at what is truly the kind of "app" that deserves this much JavaScript, versus a "glorified website" that management wants to see lots of interactivity/animations/etc.?
In my career, I've struggled far less with choosing a JavaScript framework for front-end interactivity, and far more with justifying how much JavaScript goes into Web experiences these days, without any concern for the end-user performance impact or other impacts that may not be as obvious, e.g. accessibility.
Assuming you're asking more along the lines of "how does it work internally?", these are my usual recommendations:
- My own extensive post "A (Mostly) Complete Guide to React Rendering Behavior": https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-...
- Related, "When does React render your component?", which looks more at the source level checks: https://www.zhenghao.io/posts/react-rerender
- Dan Abramov's "A Complete Guide to useEffect" https://overreacted.io/a-complete-guide-to-useeffect/
- Shawn Swyx Wang's talk "Getting Closure on React Hooks" that builds a mini version of React hooks: https://www.swyx.io/hooks/
- Rodrigo Pomber's excellent "Didact: Build a Miniature React with Hooks": https://pomb.us/build-your-own-react
https://overreacted.io/react-as-a-ui-runtime/
React deserves credit for bringing fresh thinking into the JS framework space but there's a tremendous amount of room for improvement.
* = subjective and there are a few rare exceptions
Generally you should only need to memoize a few things, and if you find that your app becomes brittle due to the amount of memoization you’re doing you probably are not handling state in the right way. If you’re using Redux that’s a common reason for this; don’t use Redux (is my advice). And yes, I’ve worked on several large enterprise React apps at successful startups.
I think what OP was suggesting is that you don't have to memoize at every level of the tree / where it doesn't make sense.
Just write a function that returns an element.
Not templates, not an opaque resource bundle, not some whole other thing. Just code.
Other frameworks have their own problems. Solid requires a custom babel compiler plugin. Some are new and lack components, placing a huge backlog to reimplement everything from scratch, just not worth it.
We need a framework that will not tie components and libs to itself, so they can be used with other frameworks or with plain ts as well.
That's why I wish web components would see greater adoption. Having worked through jQuery, Backbone, Sencha ExtJS, AngularJs, Angular 2 and React over the course of a 15 year career, It's frustrating when you can't switch frameworks because the cost to rewrite your existing components trumps the potential efficiencies of adopting a new set of design patterns and affordances.
Don't all of them do though? Like @babel/preset-react for example
"Good enough, let's spend time considering other things instead: React"
It may no longer be the best at anything anymore, but it's a polished well-rounder that will probably be fine for the typical web app. Less cognitive load when you just use it and follow the herd.
When I was first getting into reactive frontend frameworks it was part of a time-sensitive project, and we chose Vue because we could basically just write HTML and sprinkle in the reactivity. This was back in the Vue 2 days before they made everything functional, and I still think that older Vue API is the most self-explanatory for people who already know HTML and some vanilla JS.
Learning curve: Hooks can be quite unintuitive for the React beginner. React's learning curve was far gentler when all components were classes and the lifecycle was simpler.
I get the impression these things exist just to keep engagement numbers up
React keeps getting picked because it has an ecosystem. And that's the most valuable thing for medium to large scale enterprise jobs. Web developers are positively thirsty for abstractions that are powerful enough to get the job done without having to learn something new in 2 years.
In an industry of near perpetual churn for the apparent sake of churn, having something you can just cling to that does the job almost all of the time is great. You can focus on the actual problems you want to solve while someone else burns their time arguing whether you could solve them faster with Vue, hypothetically, in a spherical development environment where everybody on the team was already Vue experts.
Far more smoothly than if one were trying to change from React to another framework. All of my old class-based components still work under my React hook-and-function code.
The objective time-to-profficiency has made React (and Solid which is quite similar to React) the most obvious choice for us, and I'm one uncomfortable with consensus. Svelte doesn't quite have the staying power of React or Vue yet. Since it's a superset of JavaScript, it's harder to teach, and the component frameworks just aren't there yet. Vue is great, but Vue 3 took a step towards performance and a step away from intuitive readability IMO- it's probably better suited to a team with homogeneously high experience.
How is it similar when React lets you write non-incremental algorithms when you working with your state and with Solid you are forced to write incremental algorithms? Simple aggregate (GROUP BY) use cases that your average junior developer will be able to solve in 5 minutes with React will be a huge problem even for experienced Solid developers. The only similarity is that it is also using JSX syntax, but with completely different semantics.
Bootstrap is a lot like React. You don't appreciate the "bloat" until you need it. Or worse, you recognize you reimplemented the wheel a dozen times without noticing and most of your "wheels" are polygons with a different number of edges.
Using any specific CSS - scoped or unscoped - for a particular component is not a good sign. This might not always be avoidable.
Vue has a mechanism for that, but you can't really exchange it for something that fits your needs. It's going to be there, trying to please you with all the features the upstream developers thought you'd need and you have to program around those feature.
I don't generally disagree. Component-level CSS is something I don't do all that often, but when I do, in Vue, I'm glad I can keep it in the same file (generally scoped). For me, it's easier to spot the edge cases (oh, this is modified, and here's where it's being done).
Even at the component level, you can see use system-wide offsets. "give me two times the usual margin to the right" may be a general rule, but for componentX, something needs to be three timex the usual margin, so... you can still reference a system-defined margin variable, but have that 3x override where it's needed.
Again, not something I do often but, imo, the Vue SFC style scoping makes it easier/safer to do when needed.
Personally, I can't stand writing JavaScript and prefer to insulate myself against the moving target that is ECMAScript by writing declarative UIs in ClojureScript + Reagent, which uses React behind the scenes: https://reagent-project.github.io/
There is some interesting new stuff on the horizon like Hyperfiddle Photon, which compiles network I/O for you. As for me, an old dinosaur, I'm tired of learning new syntax. Clojure the language has not changed since its release. Lisp has been around since the 60s. It will be around in another 60 years. For me, it is the 100-year language. I'm sure it's not the end goal, but I am willing to bet it will be a Lisp-like.