| ▲ | tshaddox 19 hours ago |
| This is mostly just a complaint about how good React is. It's so good that it's difficult for the technical benefits of alternatives to outweigh the social benefits of choosing React. Note that this is neither a major compliment to React's technical merits nor a criticism of React's competitors. In fact, I don't even disagree with the author on some of his claims, such as: > React is no longer winning by technical merit. Today it is winning by default. > That reflex creates a self-perpetuating cycle where network effects, rather than technical fit, decide architecture. I agree! But teams are still largely choosing the better option, because the benefits of React are indeed outweighing the benefits of choosing an alternative. What the author is missing is simply that the technical benefits of an alternative are small except in narrow use cases. And I suspect most competent teams do in fact identify if they're in those narrow use cases and correctly choose an alternative. |
|
| ▲ | _heimdall 14 hours ago | parent | next [-] |
| I have been a part of quite a few tech stack decisions at various companies and startups. I have literally never heard an argument made for react that included merits of the framework itself. The decision was always based on a combination for familiarity, ability to hire for eng roles, and the ecosystem. |
| |
| ▲ | zarzavat 6 hours ago | parent | next [-] | | > I have literally never heard an argument made for react that included merits of the framework itself. That doesn't mean that those merits don't exist. Most of the new React competitors are just reinventions of HTML templating done client-side. React has been dominant for so long that there's a whole generation of frontend devs who don't remember why it was invented in the first place. Writing loops in HTML? We tried that, it sucks! It's telling that the "new" frameworks have no ideas other than to revert to ideas that were tried in the past. React is so modern it makes its replacements feel dated. | |
| ▲ | Xenoamorphous 8 hours ago | parent | prev | next [-] | | > I have been a part of quite a few tech stack decisions at various companies and startups. I have literally never heard an argument made for react that included merits of the framework itself. The decision was always based on a combination for familiarity, ability to hire for eng roles, and the ecosystem. Couple of thoughts regarding this: * A competing alternative would have to have really big benefits from a technical standpoint to outweigh the React advantages that you mentioned. * When exploring alternatives IMO the burden of proving that something is better lies within the person/people that want to go with an alternative option. React is the de facto standard these days so it shouldn't be a matter of "why React" but "why not React". | |
| ▲ | noodletheworld 11 hours ago | parent | prev | next [-] | | Then why dont you pick jquery? Its easy and well known, even now. The answer I see is that react is technically good enough. Using boring technology doesnt mean using the technically most advanced thing. It means picking something safe and stable. | | |
| ▲ | _heimdall 9 hours ago | parent | next [-] | | Why would you need jquery today? What can it do that native browser APIs can't? | | |
| ▲ | noodletheworld 8 hours ago | parent | next [-] | | Jquery is the old default for web apps from before people decided they wanted react. What can it do that others cant? Literally nothing. That didnt and does not stop it from being used for connivence sake. The point is: if its not about the technical quality; why are we not still using it now? | | |
| ▲ | zelphirkalt 3 hours ago | parent [-] | | If that is the point, then I feel it is made out of technical mediocrity, rather than excellence. A good team should be able to adapt the technology that best fits the task, and companies should be able to hire for it. Or stay mediocre otherwise. The hiring issue is home made. If companies started hiring for engineering skills, rather than familiarity with existing tech stack, it would change quickly. Experienced engineers are able to learn new languages and frameworks on the job. Of course, if hiring is too petty to give engineers a month of getting familiar with the product and expect readiness from the get go, then they will continue to miss out on talent. |
| |
| ▲ | mexicocitinluez 4 hours ago | parent | prev [-] | | Jquery didn't provide anything that you couldn't already do with native browser APIs, it was a wrapper around those APIs. |
| |
| ▲ | MisterSandman 10 hours ago | parent | prev | next [-] | | React is significantly more easier to hire for than JQuery is, especially in this market. Especially if you’re looking for more junior roles. As a new grad, I would’ve picked a react job over a JQuery job even if the JQuery one paid me 10k more. | |
| ▲ | isqueiros 7 hours ago | parent | prev [-] | | maintaining a large jquery/native js codebase vs a react one is not even in the same ballpark. even when not being opinionated react foundationally has more structure for complex code. |
| |
| ▲ | kamaal 13 hours ago | parent | prev [-] | | Im not sure how this is a negative merit for React. Besides if you are a small company, or a start up, your job is to get things done. Not to embark on a global technology crusade to push your favourite tech. By and large the best thing about react is the overall ecosystem, libraries, talent and ubiquitousness. And thats a good thing. | | |
| ▲ | _heimdall 13 hours ago | parent | next [-] | | It isn't necessarily a bad thing, but it doesn't align with the idea of how good react is or the technical merits of it. I also am not saying teams I have been on that picked react made the wrong choice. That's all in context and as you said startups are often in the "get things done" mentality where tech debt won't matter if you can't survive long enough for it to matter. | | |
| ▲ | tcoff91 12 hours ago | parent [-] | | It’s good enough that the ecosystem outweighs the superiority of something like SolidJS. React has React Native as part of its ecosystem. That’s a massive advantage. react-strict-dom is going to be a game changer for the development of universal apps. | | |
| ▲ | _heimdall 12 hours ago | parent [-] | | We're talking about two different topics here. I agree, the ecosystem around react is huge and there are reasons a team would pick react. Ecosystem isn't an indicator of the technical merits of react itself though, and that's what I was originally responding to here. |
|
| |
| ▲ | fireflash38 3 hours ago | parent | prev [-] | | That's a thought terminating cliche. You aren't arguing on merits. You're arguing on everything else. Why aren't we all still using C? Or B? Why isn't every website on good old PHP? Things change because people want better or different. Saying "people already use it" is not an argument for something. |
|
|
|
| ▲ | gitaarik 8 hours ago | parent | prev | next [-] |
| I think it's a bit of both. React introduced component based programming, wich was great. This was copied by many frameworks. But React held the first position because of it's strong base, and because it was just very nice and good in general for a long time in the first years of React, 12 years ago. But React has kept hold to the virtual DOM and JSX for over those 12 years. While other frameworks have created more innovative rendering mechanisms, resulting in faster rendering times with simpler code. So for the seasoned FE developer, they know there is better out there, but 9/10 jobs ask for React. And people don't seem to be interested in trying out some technology that is actually easier to use and results in a better end product. Because they are not familiar with the name, and they don't know anybody that made money with that, so better safe than sorry. So, React has been great, but by now it's a bit of a pain in the ass sometimes. |
|
| ▲ | iammrpayments 13 hours ago | parent | prev | next [-] |
| You’re assuming webdevs are rational creatures which in my experience is far from truth, since they easily fall for human biases traps such as “social proof” and “authority”. |
| |
| ▲ | rapsey 9 hours ago | parent [-] | | Pretty much every social group falls prey to these biases. It has no correlation to the education or intelligence level of the group. When there is a well known saying "science progresses one funeral at a time" you know it is unavoidable. |
|
|
| ▲ | sergiotapia 14 hours ago | parent | prev | next [-] |
| Never heard, "man react is great!" It's always, "we can hire more easily". Unfortunately |
| |
| ▲ | nicce 9 hours ago | parent [-] | | > "we can hire more easily". Is this the synonym for cheaper workforce? You always get decent people if you pay enough. | | |
| ▲ | sergiotapia 2 hours ago | parent [-] | | I don't think so. I mean, if your code is Javascript you have 1000 applicants. If your code is Nim, you have maybe 10? That's how the beancounters think about it based on conversations I've had. So to please the beancounters you need to sell a technical decision so that it's technical merits massively outweigh those 1000 candidates. |
|
|
|
| ▲ | j45 19 hours ago | parent | prev [-] |
| React is great at solving complex problems. Not all problems are complex to begin with, and having a complex tool as default otherwise adds complexity to the project and also inflexibility to iterate quickly. This is in addition to having to maintain a relatively brittle ecosystem from past feature as well as future features but that can be true for more than one area of JavaScript or other technologies. Looking for the next curve to emerge out of the current generation of web app building. |
| |
| ▲ | wk_end 18 hours ago | parent | next [-] | | I think (at least part of) the reason why React has been so successful is that is scales so well: it's actually a relatively simple tool that works well for small problems. Pair it with a Vite template or something and you can be up-and-running in minutes. But it continues working pretty well as your app gets bigger, too. But where React fails is actually in more complex scenarios. Prop drilling becomes tedious or intractable, so now we have all these different ways to manage state (Context, Redux, MobX, Recoil, Zustand, Jotai...). Your re-rendering gets slow, so now you need to start sprinkling React.memo() all over the place and adding reselect (or re-reselect!) queries and restructuring or denormalizing your store data, but then it turns out some of your props are objects that are regenerating each render cycle, so you need to memoize those too, and you end up on a wild goose chase there. Or your engineers were sloppy and accidentally put some side-effects into your components, so you've got subtle bugs you're not sure how to fix. And there's a lot of complexity or even unanswered questions around things like robustly fetching data your component needs, and maybe React Router answers them but then you end up down a whole other rabbit hole, especially when a new version of React Router comes out and breaks everything. | | |
| ▲ | solarkraft 17 hours ago | parent | next [-] | | The amazing thing about React to me is that millions of dollars keep flowing into improving its DX further. They have spent a lot of time building React Compiler (https://react.dev/learn/react-compiler/introduction) which does all the memoization for you! This severely lightens the performance concerns. | | |
| ▲ | paulhebert 17 hours ago | parent [-] | | Sure, but Svelte and Vue have had these compilation features built-in for ages without all that money flowing in. The react team resisted these features because they went against their “it’s just a library” philosophy. They’re only copying them now because of how obviously useful they are in the other frameworks. useEffect, useMemo, useCallback etc. add a ton of complexity and make it easy to write buggy code. I used to work at an agency so I’ve done projects with React/Svelte/Vue/Lit/Stencil/Angular/etc. I found the React projects had lots more performance issues, confusing bugs, etc. than Vue or Svelte. I agree with the article. React is popular because it was groundbreaking and now is the default, but it’s far from the best | | |
| ▲ | j45 8 hours ago | parent [-] | | Vue and Svelte both feel like down stream evolutions in their own respective ways (and likely overlapping). |
|
| |
| ▲ | branko_d 11 hours ago | parent | prev | next [-] | | I think React can be approached a little like JavaScript at this point: just use the good parts! In my case that means using it as a rendering library and component composer, but not for managing state or side-effects. | | |
| ▲ | stack_framer 11 hours ago | parent | next [-] | | This is exactly how I feel. I gave hooks a real, exclusive try for two years after they were introduced (2018-2020). I didn't like them—at all—so I went back to only using React as a UI library. I'm lucky enough now to work at a place where nobody else likes hooks either. | | | |
| ▲ | j45 8 hours ago | parent | prev [-] | | Agreed. Like too much javascript, keeping in mind what it takes to get something running vs keeping it running is a consideration. There are some fantastic rendering tools in React like Remotion. |
| |
| ▲ | boredtofears 11 hours ago | parent | prev [-] | | I had problems with prop drilling on early projects but since Context has been around it hasn't been an issue. Never bothered with all these state management libraries, any time someone on my team has tried to sell me on it they've never made a strong case for it over simple proper react state management. useEffect took a little getting used to - it becomes much less problematic when you learn which scenarios to use it in (fewer than you initially think). I've had to use React.memo() at times, but it's usually done in a simple optimization pass not unlike something I'd do in a backend framework. The only time I am even aware of these problems is when I stick my head into the javascript frontend framework "scene" where everyone acts like each one of these are dealbreakers and they happen constantly all the time. Life is actually pretty easy as a React dev, it's a well polished and at this point battle tested framework. I wish the other tools in my dev stack were as easy to deal with. |
| |
| ▲ | throwaway-0001 19 hours ago | parent | prev | next [-] | | And the moment you need to increase complexity in your app, you need to add back react. | | |
| ▲ | mickael-kerjean 15 hours ago | parent | next [-] | | I'm a counter example of your claim. Migrating away from React did made the complexity of my app a lot more manageable and unlocked new business opportunities that would have been impossible with React without following the JIRA route of making the software worse for 99% of users because 1% of those needed something. The project in question is Filestash (https://github.com/mickael-kerjean/filestash), what made me switch are those 2 reasons: - Performance ceiling. Past the point where you have used all the react specific optimisation tricks (useMemo, etc...), React just gets in the way, once you start to optimise things to reduce the memory footprint, optimise for 60FPS, dig into heap snapshots and allocation traces, your life starts to become miserable where you need a complete understanding of not only your app but also the inner working of React, and the intersection of both React with your app. At that point, you either accept the ceiling or rewrite everything to vanilla JS and have complete control over every piece of the code you are shipping to the client - Extensibility. I am now shipping plugins which patch frontend on the fly without any build step. In practice, after a plugin author packaged their plugin (as a zip file containing a manifest), the patches are applied in real time by the server without a prior frontend build system (open up the demo instance with the network tab open to see this working from: https://demo.filestash.app/). This powers themes with icons swaps, new behaviors (e.g. a "recall" button for files in Glacier), and other things plugin authors come up with that that makes the app far more customizable and opened for new niches without falling onto the JIRA trap | | | |
| ▲ | j45 19 hours ago | parent | prev [-] | | Maybe, maybe not. It's not the only sponge, unless it's the only sponge I know. |
| |
| ▲ | FpUser 14 hours ago | parent | prev | next [-] | | >"React is great at solving complex problems." The only thing it is great for is creating complex problems out of simple things. | | |
| ▲ | j45 8 hours ago | parent [-] | | Haha. I won't disagree with that - I have seen it used well and not well as well. Or people asking for "quick tweaks" not understanding that may not be a possibility depending on the programming that may have gone wild too soon. |
| |
| ▲ | sfn42 18 hours ago | parent | prev [-] | | React is totally fine for solving simple problems. I'd classify pretty much all frontend web development I do as simple. It's pretty much just boring internal websites, I definitely don't need react for them. Could have made the same thing with any other frontend framework, could have made it server-side rendered. React is totally fine for that. The backend is generally more exciting than the frontend. React is totally fine. The main problem I see is that most other developers are really ass at their jobs and just overcomplicate everything. I've seen very simple apps have a super complex React codebase, and due to the complexity they're always full of bugs. It's much more rare that I see an elegantly simple React app, or any other app for that matter. Everyone just always overcomplicates everything. Using React doesn't in any way require you to make it complex. You can make React apps dead simple. And if you are comfortable working with react you'll already know all the solutions to all the problems which makes your job extremely easy. You can breeze through and make the entire simple app in a few days if you know what you're doing. Or you can pick up some new fancy tool, hey let's try Svelte. And now instead of a few days we're gonna spend a few weeks and end up with a codebase that reflects our Svelte experience. And hey look it's time to onboard a new team member - hey guy, we have these three apps - this one's made with Angular because one dimwit wanted to learn that, here's a Svelte app we made last year and lastly here's a HTMX app we made when that was hot. Good luck learning 3 new technologies you'll probably never use again! |
|