7 ms·

What happened to React? It's on the wrong end of almost all of those micro benchmarks. I know micro benchmarks don't tell the whole story, but when you consis

What happened to React? It's on the wrong end of almost all of those micro benchmarks. I know micro benchmarks don't tell the whole story, but when you consistently wind up on the slow end it's not a good look.

foota 7y ago
I'm also curious, in particular why is the swap rows benchmark so much slower?
- leeoniya 7y ago
  because React's stance is that it's a rare enough case in their experience, so they don't spend time optimizing for it. that metric is slower in general because libs with simple reconciliation strategies will tend to do work for every row between the two swapped ones (2,998).
  - ilrwbwrkhv 7y ago
    So what's the benefit of more complex ones like react's?
    - pier25 7y ago
      Popularity. The ecosystem is bigger and there are more devs available.
    - ng12 7y ago
      By choosing React I'm optimizing for my time. I'll always add a framework that adds a tiny performance overhead if it means I can develop and maintain features easier. That said -- performance characteristics like this are rarely interesting to me. The vast majority of "performance issues" I've encountered have to do with high-level architecture and/or network issues. I've never given up on a framework because it couldn't swap two DOM nodes fast enough.
      - foota 7y ago
        I was surprised by the delay though, 500 ms for swapping nodes?
leeoniya 7y ago
> What happened to React? react has always been approx where it is now. but there are a lot more faster libs in the table.
- topspin 7y ago
  > react has always been approx where it is now Didn't know that. What I thought I knew is based on years of breathless claims about React's great performance. This is eye opening. Even Angular 8 does better in these benchmarks.
  - ng12 7y ago
    I think the breathless claims of performance are because for what React is doing -- storing the entire application tree using virtual DOM and seamlessly rendering updates -- it is really impressive. The fact that it is has similar performance as some much more naive frameworks is pretty amazing. In practice all of these frameworks are fast enough that you wouldn't notice unless you were doing something really crazy.
    - topspin 7y ago
      Yes, it's an admirable design. I've used it. I know. And no, nothing I've done with it has been intolerably slow. Although now I'm starting to wonder about some responsiveness issues I've experienced... I also wonder if batteries care about elegance. Not really they don't. If one makes the highly likely assumption that these micro benchmarks are a measure of efficiency then it's actually difficult to do worse than React regarding battery life, heat, etc. Very interesting.
    - pier25 7y ago
      Bundle size and start time are much more important metrics IMO unless you have a high perf use case. Like you said, most of these are fast enough for the majority of uses cases.
    - Jasper_ 7y ago
      Then why are all the React-based web apps I use so slow?
igammarays 7y ago
React was a mistake of the last decade. React itself is a great academic idea (i.e. pure functions, composability), but the whole React-Redux boilerplate mess (I dare not call it an "ecosystem" because that word implies harmony of some sort) is the the result of an entire generation of code monkeys and job seekers who didn't design their technology stack with any real engineering consideration, but rather on the basis of tool popularity, feeding a vicious cycle of "lean startup" companies spending a glut of VC money looking for the fastest way to hire more React code monkeys because they think "that is how you do engineering".
- randall 7y ago
  Not to interrupt a good rant against tech (in this era... very brave, btw) but you should look at react with the context api. I think everyone who’s used it is glad it removed redux’s boilerplate insanity. There’s even some other frameworks (the name escapes me now) that are like boilerplateless redux if ppl like that style of event driven state updates.
  - acemarke 7y ago
    Hi, I'm a Redux maintainer. Please check out our new official Redux Toolkit package. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once: https://redux-toolkit.js.org https://redux-toolkit.js.org Also, note that we have a new "Style Guide" docs page which specifically recommends patterns that we feel will lead to simpler code, like the "ducks" structure for single-file Redux logic: https://redux.js.org/style-guide/style-guide https://redux.js.org/style-guide/style-guide Finally, we're currently working on a major rewrite of the Redux core docs, with the goals of updating them for today's target audience and teaching easier-to-use patterns: https://github.com/reduxjs/redux/issues/3592 https://github.com/reduxjs/redux/issues/3592 (and by "we" I basically mean "me", since I'm not getting a lot of help with this effort so far.) I'll also point out that while Context is a great tool for making data available to a nested subtree of components, it has major limitations in terms of processing frequent updates. We tried to use it internally in React-Redux v6, and it just wasn't sufficiently fast enough, which is why we had to rewrite the internals again in v7 to use direct subscriptions instead. So, very useful, but not a replacement for Redux.

foota 7y ago

I'm also curious, in particular why is the swap rows benchmark so much slower?

leeoniya 7y ago
because React's stance is that it's a rare enough case in their experience, so they don't spend time optimizing for it. that metric is slower in general because libs with simple reconciliation strategies will tend to do work for every row between the two swapped ones (2,998).
- ilrwbwrkhv 7y ago
  So what's the benefit of more complex ones like react's?
  - pier25 7y ago
    Popularity. The ecosystem is bigger and there are more devs available.
  - ng12 7y ago
    By choosing React I'm optimizing for my time. I'll always add a framework that adds a tiny performance overhead if it means I can develop and maintain features easier. That said -- performance characteristics like this are rarely interesting to me. The vast majority of "performance issues" I've encountered have to do with high-level architecture and/or network issues. I've never given up on a framework because it couldn't swap two DOM nodes fast enough.
    - foota 7y ago
      I was surprised by the delay though, 500 ms for swapping nodes?

leeoniya 7y ago

> What happened to React? react has always been approx where it is now. but there are a lot more faster libs in the table.

topspin 7y ago
> react has always been approx where it is now Didn't know that. What I thought I knew is based on years of breathless claims about React's great performance. This is eye opening. Even Angular 8 does better in these benchmarks.
- ng12 7y ago
  I think the breathless claims of performance are because for what React is doing -- storing the entire application tree using virtual DOM and seamlessly rendering updates -- it is really impressive. The fact that it is has similar performance as some much more naive frameworks is pretty amazing. In practice all of these frameworks are fast enough that you wouldn't notice unless you were doing something really crazy.
  - topspin 7y ago
    Yes, it's an admirable design. I've used it. I know. And no, nothing I've done with it has been intolerably slow. Although now I'm starting to wonder about some responsiveness issues I've experienced... I also wonder if batteries care about elegance. Not really they don't. If one makes the highly likely assumption that these micro benchmarks are a measure of efficiency then it's actually difficult to do worse than React regarding battery life, heat, etc. Very interesting.
  - pier25 7y ago
    Bundle size and start time are much more important metrics IMO unless you have a high perf use case. Like you said, most of these are fast enough for the majority of uses cases.
  - Jasper_ 7y ago
    Then why are all the React-based web apps I use so slow?

igammarays 7y ago

React was a mistake of the last decade. React itself is a great academic idea (i.e. pure functions, composability), but the whole React-Redux boilerplate mess (I dare not call it an "ecosystem" because that word implies harmony of some sort) is the the result of an entire generation of code monkeys and job seekers who didn't design their technology stack with any real engineering consideration, but rather on the basis of tool popularity, feeding a vicious cycle of "lean startup" companies spending a glut of VC money looking for the fastest way to hire more React code monkeys because they think "that is how you do engineering".

randall 7y ago
Not to interrupt a good rant against tech (in this era... very brave, btw) but you should look at react with the context api. I think everyone who’s used it is glad it removed redux’s boilerplate insanity. There’s even some other frameworks (the name escapes me now) that are like boilerplateless redux if ppl like that style of event driven state updates.
- acemarke 7y ago
  Hi, I'm a Redux maintainer. Please check out our new official Redux Toolkit package. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once: https://redux-toolkit.js.org https://redux-toolkit.js.org Also, note that we have a new "Style Guide" docs page which specifically recommends patterns that we feel will lead to simpler code, like the "ducks" structure for single-file Redux logic: https://redux.js.org/style-guide/style-guide https://redux.js.org/style-guide/style-guide Finally, we're currently working on a major rewrite of the Redux core docs, with the goals of updating them for today's target audience and teaching easier-to-use patterns: https://github.com/reduxjs/redux/issues/3592 https://github.com/reduxjs/redux/issues/3592 (and by "we" I basically mean "me", since I'm not getting a lot of help with this effort so far.) I'll also point out that while Context is a great tool for making data available to a nested subtree of components, it has major limitations in terms of processing frequent updates. We tried to use it internally in React-Redux v6, and it just wasn't sufficiently fast enough, which is why we had to rewrite the internals again in v7 to use direct subscriptions instead. So, very useful, but not a replacement for Redux.