4 ms·

The React premature optimization train is leaving platform 1, all aboard for how to save 30 CPU cycles in your super complicated single page web app! Memoizing

• fgerschau 7y ago
  Why write inefficient code when it's just as easy to do it right? I also wrote an article about this, if you can write efficient code without sacrificing readability I think it's worth the (small) effort. https://felixgerschau.com/premature-optimization-javascript https://felixgerschau.com/premature-optimization-javascript
  • Etheryte 7y ago
    Nothing you've brought up in the article is actually optimization though? "Use const" and "reuse code" aren't optimizations, they're simply programming. The submitted article is fairly similar in some sense. You address optimization but skip out on the most important step of optimizing - measuring what you need to optimize. Tacking memo, ref and key onto everything isn't free and if those parts of your application weren't the problem you're actually making it slower.
    • MaxBarraclough 7y ago
      It makes the claim that using const can improve performance. It doesn't properly substantiate this claim though, and it doesn't seem likely that it's true. It makes the same claim about code reuse, with the reasoning that code is more likely to be JIT compiled if it's a single hotspot rather than two, well, 'warm spots'. Again it doesn't properly back up this reasoning.
• londons_explore 7y ago
  > The React community is the absolute worst offender for premature optimization. They are also the worst for "no optimization it takes 5 seconds to load" pages.
• jsf01 7y ago
  So true. This reminds me of one of my favorite tidbits from another vdom framework’s documentation, in which using the equivalent of shouldComponentUpdate is generally considered to be an antipattern. Whereas in React, it seems idiomatic to just memoize and throw in shouldComponentUpdate wherever you can as much as you can. https://mithril.js.org/lifecycle-methods.html#avoid-premature-optimizations https://mithril.js.org/lifecycle-methods.html#avoid-prematur...
  • onion2k 7y ago
    From the mithril docs you linked to: "You should only use onbeforeupdate to skip diffing as a last resort. Avoid using it unless you have a noticeable performance issue." From the React docs (https://reactjs.org/docs/react-component.html#shouldcomponentupdate https://reactjs.org/docs/react-component.html#shouldcomponen...): "Use shouldComponentUpdate() to let React know if a component’s output is not affected by the current change in state or props. The default behavior is to re-render on every state change, and in the vast majority of cases you should rely on the default behavior. [...] This method only exists as a performance optimization." Both framework developers are telling users the same thing.
    • jsf01 7y ago
      That’s a good point. There’s something in the difference between the two communities then, where React’s tends to be encouraging of memoized components and shouldComponentUpdate while mithril’s tends to advise against those methods. The blog post behind this thread is a prime example.
      • dragonwriter 7y ago
        > There’s something in the difference between the two communities then, where React’s tends to be encouraging of memoized components and shouldComponentUpdate I haven't seen that. > The blog post behind this thread is a prime example. But it's...not at all an example of what you describe. The blog post explains how things work and how to optimize, it doesn't encourage optimizing without demonstrated need, and the "even better" optimization approach it suggests isn't using memoization or shouldComponentUpdate, but instead paying attention to the basic component structure.
• onion2k 7y ago
  Measure first, then optimize. This sounds like good advice, but from experience I've found that optimizing code by adding things like memoization after you've discovered it's too slow in the context of an app is a lot harder than than writing something that's efficient to start with, especially if a feature is mature and other parts of the code are resistant to change. There's a balance to strike between spending time writing optimal code and actually shipping, but if there are low-hanging fruit available and you choose not to take advantage of them you'll probably regret it.
• matthewmacleod 7y ago
  Premature optimisation is a problem, but I'd say in general it's a better approach to just start out by doing the fast thing. Memoising (or using PureComponent or whatever) is an absolutely minimal cost if you're using an appropriate architecture – my experience suggests that it's way easier to do that from the outset with everything—adding some exceptions where required—rather than trying to detangle a large SPA that uses mutable props everywhere later on. It's probably good advice to avoid lots of custom shouldComponentUpdate logic though. That's smelly.
  • davedx 7y ago
    > Premature optimisation is a problem, but I'd say in general it's a better approach to just start out by doing the fast thing This is contradictory
    • ragnese 7y ago
      The keyword is "premature". The whole silly meme of "premature optimization is the root of all evil" is a 100% useless statement. Of course, you shouldn't do it yet if it's premature- that's the definition of premature. But if it's almost the same amount of effort to write faster code from the get go- especially if you KNOW the code will be speed-sensitive, then you should absolutely try to do the fast thing over the slow thing. That seems obvious...
• quantummkv 7y ago
  This whole "don't do premature optimization" is one the worst creeds in software development, right below "just hack together a temporary MVP for now, we'll write a good one later" As someone who spent weeks trying to optimize a react native app, believe me, this is not going to go the way you think it is. It never will. Not without rewriting half of your app and earning the ire of your customers for being a slow hog along the way. > Memoizing a leaf component probably isn't worth doing It isn't when you only have 10 components. By the time you have a thousand of them in a big app, you will have a thousand small performance paper cuts in you application. And they will bleed your app while you can do nothing but watch.
  • davedx 7y ago
    What does your app do that you need to render a thousand on one screen? I'm genuinely curious
    • quantummkv 7y ago
      Not exactly a thousand. That was a bit of a hyperbole. But I have used hundreds of components in some apps. Most of them were big enterprise apps that had a lot of input fields for data entry. Given the was data entry works in React, especially with the general form practices, it was a nightmare when I first started and was a follower of the entire premature optimization gospel. For a more similar and public example, just have a look at how sluggish the jira webapp feels.
• Tade0 7y ago
  I see that oftentimes this stems from the lack of knowledge regarding how the system underneath (VDOM, DOM, JS VM, computer ) works. Case in point: why are (or were?) anonymous functions frowned upon in React props? Is it because of the penalty involved with creating a function on each render call? Of course not - my phone can do 19mln of those a second. It's because the VDOM sees a reference change, so it re-renders the component. Obviously if there's a performance penalty, it's because of the latter, but I heard the former before as an argument in a discussion.