7 ms·

I think the reason this article is wrong is this. The author says that React isn't the best in any singular category, and is solidly middle of the pack. But tha

by johnfn 4y ago

I think the reason this article is wrong is this. The author says that React isn't the best in any singular category, and is solidly middle of the pack. But that actually makes sense; being best at one thing (such as bundle size) means you're probably making some tradeoff against another thing (such as functionality). React isn't as fast as Svelte, but Svelte gets those gains by putting another compiler in your build pipeline, a tradeoff unacceptable to many. React isn't as thin as Preact (or whatever other small library there is), but that means that React has more functionality. React might not be as easy to learn as some other frameworks, but that's because, honestly, React chose the right abstractions to build, and those aren't always the easiest to understand. (Honestly, they aren't hard to understand either; it's a minor difference at most, but it is what it is.) And honestly, if you were to build a big matrix of frameworks graded across all these categories, I suspect you'd find that leaders in one category almost invariably tank in other categories, for the exact reason that you have to make significant cutbacks in order to beat the tradeoffs that React made.

josephg 4y ago
I'm not convinced. In programming language / library design, you can often "have your cake and eat it too" if you can find a better design. Better designs take years to invent and mature - jQuery came out in 2006. React came out in 2013 (7 years later) and I think it improved on jQuery in just about every way. But now its 2022. Its been 9 years since React came out. As far as I can tell, clever folks have improved on how react works in just about every way in turn. What deep tradeoffs are Solid or Svelte making in exchange for their speed? I can't spot any. As far as I can tell, React's virtual DOM diffing is pure overhead - so good riddance. Solid and Svelte use a different approach to deal with state (similar to React's hooks) that honestly I prefer anyway. Dealing with state in react is a mess. Where do the new frameworks lose to React on any technical metric? Svelte is designed to be compiled, but lets be honest - in 2022 almost everyone is compiling our JS anyway. Go ahead and build a matrix of frameworks if you want. The competition is fierce. Like jQuery before it, React hasn't aged well. I'd bet good money that react, like jQuery, doesn't come out on top.
- jack_pp 4y ago
  I feel React has similar problems as Python, it was here first and thus it has become too ingrained in the culture, too many things were built on top of it. It will take a long time before something comes along that will de-throne them and even then you'll still see a lot of demand for devs who know it because there is too many codebases that people don't want to re-write. I don't think you can say the same thing for jQuery because first of all you couldn't build the same things with it and if you tried you probably hated it enough that you would jump at the chance to re-write your project with something like React.
  - josephg 4y ago
    > it has become too ingrained in the culture, too many things were built on top of it. It will take a long time before something comes along that will de-throne them The reality is that nobody cares what you use to make your webpage or app. It might take a while to dethrone python and react, but who cares? Make software using whatever tools you want. There's lots of jobs, and these things are super easy to learn anyway. I'm convinced that half of the jobs listing React are using Svelte or Vue or something, but know they'll get more candidates applying if they hire for react and then just train the person in vue after they start.
    - joshmanders 4y ago
      > I'm convinced that half of the jobs listing React are using Svelte or Vue or something, but know they'll get more candidates applying if they hire for react and then just train the person in vue after they start. Easy to convince yourself of this, but in reality what is the benefit of having to sift through even more applications and waste time to go through the processes just to say "oh by the way we don't use React, we actually use Vue, hope that's ok" and think that the candidate, expecting to be hired to do React will just be like "yeah sure no problem, I actually mastered all the frameworks so it's fine that you lied about what you use." Fantasy land.
      - josephg 4y ago
onion2k 4y ago
React isn't as thin as Preact (or whatever other small library there is), but that means that React has more functionality. This is absolutely true but 99% of React sites don't need the extra functionality if they've already accepted stopping supporting old browsers. Everyone who uses React should be testing Preact to see if their app works. It could well be a very low effort way to knock a few tens of KB off your bundle size.
mort96 4y ago
> React isn't as fast as Svelte, but Svelte gets those gains by putting another compiler in your build pipeline, a tradeoff unacceptable to many. But everyone uses React with the JSX compiler? I mean it certainly is a strength of React that you _can_ use it as a plain old library, but it's not the common use case.
potamic 4y ago
Here's my hot take. I think the author is partly justified in the premise. React when it came out was really a breath of fresh air and solved a class of problems really well. Sure it had its rough edges, but you expect those to smoothen out over time. But what has happened is exactly the opposite, where it has become more unwieldy and confounding to use. If I look back at the journey of springframework in java as an example, it had a graceful evolution, becoming more refined with each version, and springboot finally hitting the sweet spot. I think the root of the problem with react is actually the community. The web community has not figured out how to maintain software. There is an unhealthy attraction towards new paradigms and tools and an unhealthy willingness to endure paper cuts. So many practices simply wouldn't fly in any other community. Skepticism towards new ideas and a stubbornness to resist change are very important attributes for any community. It ensures that when a change does happen it passes through a very strict filter ensuring only the best of ideas get through. Tools that are built will only be as good as the community. I believe React had a great opportunity to become something cherished, but the community had to take it to that direction.
- zero_shift 4y ago
  This is a contradiction in terms: > There is an unhealthy attraction towards new paradigms and tools and an unhealthy willingness to endure paper cuts. Web developers (who are often maligned on this site) are both too eager to move to better tools... But also, not eager enough > So many practices simply wouldn't fly in any other community. Skepticism towards new ideas and a stubbornness to resist change are very important attributes for any community. Yeah, and hooks had a lot of pushback at the time. The new useEffect semantics are getting pushback. These are exactly what you are asking for. What are you wanting us webdevs to... _do_, exactly? It seems anyone can come to Reddit or the orange site and rail against UI programmers all day. But if we sit down and explain the situation nobody is very interested to listen.
  - vosper 4y ago
    > It seems anyone can come to Reddit or the orange site and rail against UI programmers all day. But if we sit down and explain the situation nobody is very interested to listen. And when someone tries to make things better with a new take or tool they get shat on here with “hurr durr those JavaScript developers always jumping on the new framework of the week” HN, where sneering at web devs always gets upvotes and somehow never gets old
fanboy44 4y ago
> React isn't as fast as Svelte Svelte is so much more than just faster.. It's reactive to the core!, you don't need redux stores or whatsoever, no react-hooks with all it's unacceptable traps and edge cases, no CRA where a simple eject shows the mess it actually is.. I can go on and on. Sorry but IMAO React is totally deprecated, it had its time, but there are much better solutions now. Just take a few days to dive into Svelte (or even better svelte-kit) and I doubt you'll ever want to go back to the ever mounting complexity React has become. I've been programming professionally in React from 2014. In the first years it was great compared to Angular, but today I cannot think of any reason to start a new project in React.
- wildrhythms 4y ago
  How does Svelte solve the reactive state problem that Redux is trying to solve?
- andsoitis 4y ago
  > Just take a few days to dive into Svelte (or even better svelte-kit) Svelte has now been around for, what, 4 or 5 years (according to Wikipedia)? How bad are the breaking changes to larger apps that are built with it? When I google "svelte breaking changes", I get results such as https://svelte.dev/blog/whats-new-in-svelte-september-2022 https://svelte.dev/blog/whats-new-in-svelte-september-2022 Foundational churn that cause deep and broad downstream impact can really slow down a team. Generally, backwards and forwards compatibility is a plus in my view and a tradeoff against it is worth being intentional about.
- joshmanders 4y ago
  > no CRA where a simple eject shows the mess it actually is Have you looked at the svelte compiler? It's not as small and easy to reason about as you want to think it is.
mcv 4y ago
I don't see why another compiler would be unacceptable to anyone; all fromt-end frameworks have a compilation step. React needs to compile jsx files, Vue its .vue files.
twhitmore 4y ago
The right abstractions? React's functional components are a monument to concept over practicality, and the overall ecosystem is a hot mess. Populating initial state should not be a difficult special case. Handling state changes should not be a choice of esoteric extras. These are just basic requirements of any reasonable application. React got quite a bit right, and it seemed cool at the start, but at a certain point the enthusiasm for "concept" diverged from actual requirements.

by johnfn 4y ago

josephg 4y ago

I'm not convinced. In programming language / library design, you can often "have your cake and eat it too" if you can find a better design. Better designs take years to invent and mature - jQuery came out in 2006. React came out in 2013 (7 years later) and I think it improved on jQuery in just about every way. But now its 2022. Its been 9 years since React came out. As far as I can tell, clever folks have improved on how react works in just about every way in turn. What deep tradeoffs are Solid or Svelte making in exchange for their speed? I can't spot any. As far as I can tell, React's virtual DOM diffing is pure overhead - so good riddance. Solid and Svelte use a different approach to deal with state (similar to React's hooks) that honestly I prefer anyway. Dealing with state in react is a mess. Where do the new frameworks lose to React on any technical metric? Svelte is designed to be compiled, but lets be honest - in 2022 almost everyone is compiling our JS anyway. Go ahead and build a matrix of frameworks if you want. The competition is fierce. Like jQuery before it, React hasn't aged well. I'd bet good money that react, like jQuery, doesn't come out on top.

jack_pp 4y ago
I feel React has similar problems as Python, it was here first and thus it has become too ingrained in the culture, too many things were built on top of it. It will take a long time before something comes along that will de-throne them and even then you'll still see a lot of demand for devs who know it because there is too many codebases that people don't want to re-write. I don't think you can say the same thing for jQuery because first of all you couldn't build the same things with it and if you tried you probably hated it enough that you would jump at the chance to re-write your project with something like React.
- josephg 4y ago
  > it has become too ingrained in the culture, too many things were built on top of it. It will take a long time before something comes along that will de-throne them The reality is that nobody cares what you use to make your webpage or app. It might take a while to dethrone python and react, but who cares? Make software using whatever tools you want. There's lots of jobs, and these things are super easy to learn anyway. I'm convinced that half of the jobs listing React are using Svelte or Vue or something, but know they'll get more candidates applying if they hire for react and then just train the person in vue after they start.
  - joshmanders 4y ago
    > I'm convinced that half of the jobs listing React are using Svelte or Vue or something, but know they'll get more candidates applying if they hire for react and then just train the person in vue after they start. Easy to convince yourself of this, but in reality what is the benefit of having to sift through even more applications and waste time to go through the processes just to say "oh by the way we don't use React, we actually use Vue, hope that's ok" and think that the candidate, expecting to be hired to do React will just be like "yeah sure no problem, I actually mastered all the frameworks so it's fine that you lied about what you use." Fantasy land.
    - josephg 4y ago

onion2k 4y ago

React isn't as thin as Preact (or whatever other small library there is), but that means that React has more functionality. This is absolutely true but 99% of React sites don't need the extra functionality if they've already accepted stopping supporting old browsers. Everyone who uses React should be testing Preact to see if their app works. It could well be a very low effort way to knock a few tens of KB off your bundle size.

mort96 4y ago

> React isn't as fast as Svelte, but Svelte gets those gains by putting another compiler in your build pipeline, a tradeoff unacceptable to many. But everyone uses React with the JSX compiler? I mean it certainly is a strength of React that you _can_ use it as a plain old library, but it's not the common use case.

potamic 4y ago

Here's my hot take. I think the author is partly justified in the premise. React when it came out was really a breath of fresh air and solved a class of problems really well. Sure it had its rough edges, but you expect those to smoothen out over time. But what has happened is exactly the opposite, where it has become more unwieldy and confounding to use. If I look back at the journey of springframework in java as an example, it had a graceful evolution, becoming more refined with each version, and springboot finally hitting the sweet spot. I think the root of the problem with react is actually the community. The web community has not figured out how to maintain software. There is an unhealthy attraction towards new paradigms and tools and an unhealthy willingness to endure paper cuts. So many practices simply wouldn't fly in any other community. Skepticism towards new ideas and a stubbornness to resist change are very important attributes for any community. It ensures that when a change does happen it passes through a very strict filter ensuring only the best of ideas get through. Tools that are built will only be as good as the community. I believe React had a great opportunity to become something cherished, but the community had to take it to that direction.

zero_shift 4y ago
This is a contradiction in terms: > There is an unhealthy attraction towards new paradigms and tools and an unhealthy willingness to endure paper cuts. Web developers (who are often maligned on this site) are both too eager to move to better tools... But also, not eager enough > So many practices simply wouldn't fly in any other community. Skepticism towards new ideas and a stubbornness to resist change are very important attributes for any community. Yeah, and hooks had a lot of pushback at the time. The new useEffect semantics are getting pushback. These are exactly what you are asking for. What are you wanting us webdevs to... _do_, exactly? It seems anyone can come to Reddit or the orange site and rail against UI programmers all day. But if we sit down and explain the situation nobody is very interested to listen.
- vosper 4y ago
  > It seems anyone can come to Reddit or the orange site and rail against UI programmers all day. But if we sit down and explain the situation nobody is very interested to listen. And when someone tries to make things better with a new take or tool they get shat on here with “hurr durr those JavaScript developers always jumping on the new framework of the week” HN, where sneering at web devs always gets upvotes and somehow never gets old

fanboy44 4y ago

> React isn't as fast as Svelte Svelte is so much more than just faster.. It's reactive to the core!, you don't need redux stores or whatsoever, no react-hooks with all it's unacceptable traps and edge cases, no CRA where a simple eject shows the mess it actually is.. I can go on and on. Sorry but IMAO React is totally deprecated, it had its time, but there are much better solutions now. Just take a few days to dive into Svelte (or even better svelte-kit) and I doubt you'll ever want to go back to the ever mounting complexity React has become. I've been programming professionally in React from 2014. In the first years it was great compared to Angular, but today I cannot think of any reason to start a new project in React.

wildrhythms 4y ago
How does Svelte solve the reactive state problem that Redux is trying to solve?
andsoitis 4y ago
> Just take a few days to dive into Svelte (or even better svelte-kit) Svelte has now been around for, what, 4 or 5 years (according to Wikipedia)? How bad are the breaking changes to larger apps that are built with it? When I google "svelte breaking changes", I get results such as https://svelte.dev/blog/whats-new-in-svelte-september-2022 https://svelte.dev/blog/whats-new-in-svelte-september-2022 Foundational churn that cause deep and broad downstream impact can really slow down a team. Generally, backwards and forwards compatibility is a plus in my view and a tradeoff against it is worth being intentional about.
joshmanders 4y ago
> no CRA where a simple eject shows the mess it actually is Have you looked at the svelte compiler? It's not as small and easy to reason about as you want to think it is.

mcv 4y ago

I don't see why another compiler would be unacceptable to anyone; all fromt-end frameworks have a compilation step. React needs to compile jsx files, Vue its .vue files.

twhitmore 4y ago

The right abstractions? React's functional components are a monument to concept over practicality, and the overall ecosystem is a hot mess. Populating initial state should not be a difficult special case. Handling state changes should not be a choice of esoteric extras. These are just basic requirements of any reasonable application. React got quite a bit right, and it seemed cool at the start, but at a certain point the enthusiasm for "concept" diverged from actual requirements.