Originally published at: https://www.sitepoint.com/javascript-web-workers/
In 2019, the web ecosystem has evolved to the point where the browser is an execution environment for applications built on JavaScript. This is reflected in the speed with which the industry comes up with new frameworks, paradigms, module loaders and bundlers, dependency managers, build tools, and package managers year after year.
When JavaScript was conceived in the early days of the internet, the direction of web development was not clear. Due to the constant, rapid change in the industry and ecosystem, the need for backward-compatibility with browsers and web standards, the evolution of JavaScript became a constant stream of patches, hacks and afterthoughts.
Today's mobile devices normally come with 8+ CPU cores, or 12+ GPU cores. Desktop and server CPUs have up to 16 cores, 32 threads, or more.
In this environment, having a dominant programming or scripting environment that is single-threaded is a bottleneck.
JavaScript Is Single-threaded
This means that by design, JavaScript engines — originally browsers — have one main thread of execution, and, to put it simply, process or function B cannot be executed until process or function A is finished. A web page's UI is unresponsive to any other JavaScript processing while it is occupied with executing something — this is known as DOM blocking.
Shouldn’t you be using event listeners rather than inline JS?
Hi, gandalf, yes, in a real-life project that would probably be the better approach.
The purpose here was to give a quick-and-dirty introduction to web workers.
Thanks for article!
Just want to say that the problem with quick and dirty introduction is that less experienced programmers may adopt this approach and use it in production.
I think they would appreciate the slightly longer article if they could learn it the right way from the beginning.
But looking past that, nice article 
2 Likes
Well, technically there is absolutely nothing wrong with inline trigger, just as there is technically nothing wrong with inline style attribute on a html element / tag. It is a matter of code maintainability, and judging particular situation on its own merits, not grammar fascism.
I am currently mentoring two beginners for my team - what I want them is to learn to think - to be able to discern when is what important. Not to enforce theoretical rules.
Personally - I have given up a wonderful and aesthetically beautiful framework like RoR, half way while I was choosing which direction to take. Reason? Insistence on Test-Driven-Development puritanism simply drained my enthousiasm. And looking back - not sorry.
Now I’m working with Django and Phoenix.
Years later I read this post by DHH and wished someone had told me that earlier.
I now manage projects as dev lead and mentor beginners, I have experience with bad and plain ugly code - but also the opposite - and I have no intention to extinguish the living soul out of them by enforcing every standard and every best practice every single time.
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.
