back
22 comments
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 of web workers, but about counterintuitive behavior discovered in their own app when attempting to apply web workers to solve a then-misunderstood problem.

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].

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?
This blog post has nothing to do with workers and everything with “just don’t use React with hooks”
It’s even simpler than that I’m afraid. It’s “we found a bug in our glue code with another library and we found it by debugging after overengineering.” It doesn’t implicate any of the technologies they use, just an oversight in their prior root cause analysis process.
Or don't use GraphQL subscriptions / Apollo for GraphQL.
The lesson is to understand how reactivity works with the tech stack your project is built with.

This is a problem with react, and it's middlewares where things become a convoluted mess if there isn't at least one person that's experienced with what's actually happening and is attentive to avoid pitfalls with potential side-effects.

The lesson is that, two objects aren’t equal even if their content is.

This is what to, the issue boils down, and such incorrect React’s usage should be clear to junior-level developers.

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

> 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.

The big surprise to me is neither PR included any tests to prevent regressions.
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.

I feel like I've been told that many things in rust (and swift) require switching from pointers to indices which seems like suddenly you do miss the fact that something has a pointer
Interesting article, bad title.

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?

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.
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.

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.

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.
Well that's just you. Some of us got the gist of it a bit earlier. No shame in being a slow learner though.
Hello It's Marco one of the developers. You're right, web workers absolutely have a spot in apps. That's actually why I thought to use them in the first place! In this case it turns out it wasn't necessary though. Sorry for the click bait title but I hope you could at least enjoy the article.
Lol what? Plenty of senior devs, leads and managers deal in absolutes.