Hacker News Reader

Comment by hahn-kev | Hacker News Reader

I think part of the problem is that there is no other thread (outside of service workers), so that's why it's hard. In C# I would just fire up another thread to do the work and I don't have to worry about blocking the UI until I want to notify the UI from that thread. But I can't fire up a separate thread in JS so everything is done on the UI thread

View on HN

I don't think it's the problem.

I think that it's a combination of two things:

1. many webdevs just have no clue what a thread is, because generally, they don't need it, so it isn't taught;

2. most of the documentation you can find online was written by people (and now ChatGPT) who don't understand async, sprinkle the word randomly and tweak things until they seem to work.

As a consequence, webdevs learn that async is magic. Which is a shame, because the underlying model is almost simple (the fact that we have both micro-tasks and tasks complicates things a bit).

> many webdevs just have no clue what a thread is, because generally, they don't need it, so it isn't taught

JavaScript doesn't have threads.

This is not meaningfully true in 2024

*2025 (although still true of 2024 and several preceding years, heh)

Parent commenter helped implement async in JS, they know what they are talking about. JS has threads locked behind semantics. Web workers run on separate threads. I do a lot of heavy parallel processing that never blocks the UI with them all the time.

I stand corrected.

It looks like web workers is the way for JavaScript to do multi-threading.

Async has always been enough for what I need to do in the front end, as most of my long running processes are just calling a back end.

Edit to add: for context, I am a full stack developer and know what threads are... I just never have needed them in the browser.

Web workers are great for local compute and isolation. Unfortunately it's a hassle managing sane pooling because different platforms have different worker limits.

On the other hand, the isolation guarantees are strong. There aren't really any footguns. Messaging is straightforward, works with a lot of data types and supports channels for inter-worker communication.

When your answer is "the problem is the developers", your answer is always wrong.

Both your points, 1 + 2, are variations on that.

The right answer is the problem is the language design.

My points are "the problem is it isn't taught" and "the problem is the documentation available", so I'm not sure how you read "the problem is the developers".

The browser as a runtime is the epitome of worse-is-better.

Outside of workers, of which service workers are one type.

You can create a new thread via. `new Worker` but using a worker requires a separate file, and lots of serialisation code as you communicate via `postMessage`. TC39 module expressions helps but not a lot of movement recently. https://github.com/tc39/proposal-module-expressions?tab=read...

There's some progress on that proposal, just happening elsewhere. https://github.com/tc39/proposal-esm-phase-imports defines machinery for importing a ModuleSource object which you can instantiate as a Worker, and once that's done module expressions would just be syntax which evaluates to a ModuleSource rather than needing a separate import.

> But I can't fire up a separate thread in JS so everything is done on the UI thread

Yea targeting the web is nuts if you have other options!

Reply on news.ycombinator.com