[HN Gopher] Web workers are not the answer
       ___________________________________________________________________
        
       Web workers are not the answer
        
       Author : 0xedb
       Score  : 28 points
       Date   : 2022-10-17 20:35 UTC (2 hours ago)
        
 (HTM) web link (dagster.io)
 (TXT) w3m dump (dagster.io)
        
       | candiddevmike wrote:
       | Only a junior developer deals in absolutes. Web workers are
       | sometimes the answer, and if you can work within their
       | constraints, will free up your main thread and speed up your SPA
       | or rendering.
        
         | coinbasetwwa wrote:
         | Lol what? Plenty of senior devs, leads and managers deal in
         | absolutes.
        
         | m00x wrote:
         | Both authors have 8+ years of experience, so it does strike me
         | as a controversial take for clicks & views.
         | 
         | Web workers definitely have their place to be useful. I think
         | we can just take it as "Web workers weren't the right solution
         | for this".
         | 
         | Still an interesting read.
        
           | soylentgraham wrote:
           | I am appalled at the code I wrote when I was 8 years into the
           | proffesion.
           | 
           | I would also be wary of any code I wrote after 16 years
           | (though some I do... the very pure no dependency stuff!)
           | 
           | In 2 years that'll be 3x8 years and I hope to pass the
           | audition.
        
             | whateveracct wrote:
             | This is funny to me in a way. When I look at my very first
             | few non-trivial Haskell projects, I still like the code.
             | Are there ways to improve it? Things I've learned? Sure.
             | But the code is still perfectly good and fine. Maybe things
             | are just different outside the Turing Tarpit.
        
       | duderific wrote:
       | > simply moved our use of useSubscription() into a component that
       | simply returned null. That way, the extraneous renders that were
       | being triggered by useSubscription() would be extremely cheap
       | because the component had virtually no re-render cost.
       | 
       | It seems like maybe the API provider (Apollo) should provide a
       | way to avoid the extraneous renders. Maybe this is unavoidable
       | due to the React hooks architecture.
        
       | NaughtyShiba wrote:
       | Nice read, thanks for that!
       | 
       | However, I would say it doesn't emphasise issue, from React's
       | perspective, enough.
       | 
       | Languages like C++ or Rust, where pointer/reference definitions
       | are required, has an advantage that you won't miss the fact that
       | something has pointer.
       | 
       | Worthy mention - `additionalProperties` property of `react-
       | hooks/exhaustive-deps` ESLint rule, allows to define hooks which
       | requires referential stability for dependencies. Personally, I've
       | yet to use it.
        
       | azangru wrote:
       | The blog post is littered with React code (plus Apollo). Which
       | part of the problem was specific to the workers - and how can
       | this lesson be generalized to any FE framework, or no framework
       | at all?
        
         | tobyhinloopen wrote:
         | This blog post has nothing to do with workers and everything
         | with "just don't use React with hooks"
        
       | sangeeth96 wrote:
       | I wonder if the team ever tried the React DevTools Profiler or
       | something like why-did-you-render[0] to debug and find the root
       | cause, before going the counter/manual method?
       | 
       | [0]: https://github.com/welldone-software/why-did-you-render
        
       | [deleted]
        
       ___________________________________________________________________
       (page generated 2022-10-17 23:01 UTC)