Maybe it’s because my brain is tired, but I had to reread the article several times to understand that the takeaway isn’t about something counterintuitive about the behavior <i>of web workers</i>, but about counterintuitive behavior discovered in their own app when attempting to apply web workers to solve a then-misunderstood problem.<p>Definitely not a better title, but a clearer synopsis: web workers [were] not the [appropriate solution to the problem we set out to solve, in fact their constraints helped us discover an extant problem and address it. Nothing peculiar or otherwise about web workers was implicated].<p>It’s possible this realization has broader value: digging in to better understand a problem and finding the appropriate solution is different than you presupposed are important skills! But I do think the title and summary do it a disservice. And I’m wary of how that might mistakenly influence people to reflexively dismiss web workers for appropriate use cases.
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?
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?<p>[0]: <a href="https://github.com/welldone-software/why-did-you-render" rel="nofollow">https://github.com/welldone-software/why-did-you-render</a>
> 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.<p>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.
Nice read, thanks for that!<p>However, I would say it doesn’t emphasise issue, from React’s perspective, enough.<p>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.<p>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.
Interesting article, bad title.<p>Not that I don't appreciate the effort, but the more articles I see like this, it starts to make me wonder. In the future will I have to write a full report with infographics every time I debug or optimize something?<p>Imagine how much more productive engineers could be these days if they didn't have to do a presentation or book tour every time they solved a problem.
I see the title has been edited. The title at the time I’m noticing it, “counterintuitive web worker behavior” is even less representative of the article’s content than the original.
The title here is clickbait and what the article is really about is that fully understanding your problem before you start making changes to fix it leads to simpler and better fixes.
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.