4 ms·

I just wanna note it's crazy that things confusing people a decade ago are still confusing people now. How fucking hard can the concept of a ui thread be?

hahn-kev 2y ago
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
- PittleyDunkin 2y ago
  > 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!
- chii 2y ago
  The browser as a runtime is the epitome of worse-is-better.
  - PittleyDunkin 2y ago
    [flagged]
- rafram 2y ago
  Outside of workers, of which service workers are one type.
- Yoric 2y ago
  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).
  - bsuvc 2y ago
    > 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.
    - Retr0id 2y ago
      This is not meaningfully true in 2024
      - Retr0id 2y ago
        *2025 (although still true of 2024 and several preceding years, heh)
    - soulofmischief 2y ago
      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.
      - bsuvc 2y ago
        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.
        soulofmischief 2y ago
        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.
- bfgeek 2y ago
  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=readme-ov-file#problem-space https://github.com/tc39/proposal-module-expressions?tab=read...
  - bakkoting 2y ago
    There's some progress on that proposal, just happening elsewhere. https://github.com/tc39/proposal-esm-phase-imports 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.
deleted 2y ago
[deleted]
WJW 2y ago
I don't think that is weird at all. Nobody is born knowing about UI threads and junior devs today are not significantly different in knowledge from junior devs a decade ago. It's not surprising that things which were confusing in 2015 are still confusing now.
- santoshalper 2y ago
  That's what I love about these junior devs, man. I get more experienced, but they stay noobs. All right, all right, all right.
Ma8ee 2y ago
I read somewhere that about 50% of all developers have less than 5 years of experience. That fact explains quite a lot.
- greggyb 2y ago
  I’ve come across that as well, but in presentations. I think it is either Alan Kay or Bob Martin who likes to use the statistic. I recall it being framed in terms of the growth of tech/programming as a profession: it’s doubled every 5 years; the fact that 50% of developers have less than 5 years of experience. This is simply exponential growth stated in two different ways. I do a lot of work on a platform that has doubled in user base yearly since its inception, for about a decade (though I think we are at an inflection point now or soon), and it is wild to have “experts” be those with 2 or 3 years of experience. Having used the platform for 11 years, now it is crazy to believe I have more experience than 99.9% of the field.
normie3000 2y ago
> things confusing people a decade ago I was being confused by blocked UI threads TWO decades ago (AWT or Swing or something), so I'm confused that it was confusing you one decade ago.
moregrist 2y ago
To be fair, blocking the UI thread is still a common issue in desktop app programming, where it’s been a well-known thing for at least 1-2 decades longer. You either have to split linear execution (hard although async can make this easier in languages like Python) or go multithreaded with its own difficulties. But IME what typically happens, at least in desktop apps, is that doing a little work in the UI thread is fine until it isn’t, and the “not fine” moment can be months or years away from when the code is written. The bug reports are often vague and rare enough that it takes a while to see the pattern (eg: “it froze and then I killed the program”). And after enough of these problems, someone with experience puts a framework and some rules in place that move tasks off the UI thread. Which works until they creep back in.
schwartzworld 2y ago
Hopefully it’s not the same people getting confused.

hahn-kev 2y ago

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

PittleyDunkin 2y ago
> 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!
chii 2y ago
The browser as a runtime is the epitome of worse-is-better.
- PittleyDunkin 2y ago
  [flagged]
rafram 2y ago
Outside of workers, of which service workers are one type.
Yoric 2y ago
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).
- bsuvc 2y ago
  > 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.
  - Retr0id 2y ago
    This is not meaningfully true in 2024
    - Retr0id 2y ago
      *2025 (although still true of 2024 and several preceding years, heh)
  - soulofmischief 2y ago
    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.
    - bsuvc 2y ago
      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.
      - soulofmischief 2y ago
        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.
bfgeek 2y ago
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=readme-ov-file#problem-space https://github.com/tc39/proposal-module-expressions?tab=read...
- bakkoting 2y ago
  There's some progress on that proposal, just happening elsewhere. https://github.com/tc39/proposal-esm-phase-imports 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.

deleted 2y ago

[deleted]

WJW 2y ago

I don't think that is weird at all. Nobody is born knowing about UI threads and junior devs today are not significantly different in knowledge from junior devs a decade ago. It's not surprising that things which were confusing in 2015 are still confusing now.

santoshalper 2y ago
That's what I love about these junior devs, man. I get more experienced, but they stay noobs. All right, all right, all right.

Ma8ee 2y ago

I read somewhere that about 50% of all developers have less than 5 years of experience. That fact explains quite a lot.

greggyb 2y ago
I’ve come across that as well, but in presentations. I think it is either Alan Kay or Bob Martin who likes to use the statistic. I recall it being framed in terms of the growth of tech/programming as a profession: it’s doubled every 5 years; the fact that 50% of developers have less than 5 years of experience. This is simply exponential growth stated in two different ways. I do a lot of work on a platform that has doubled in user base yearly since its inception, for about a decade (though I think we are at an inflection point now or soon), and it is wild to have “experts” be those with 2 or 3 years of experience. Having used the platform for 11 years, now it is crazy to believe I have more experience than 99.9% of the field.

normie3000 2y ago

> things confusing people a decade ago I was being confused by blocked UI threads TWO decades ago (AWT or Swing or something), so I'm confused that it was confusing you one decade ago.

moregrist 2y ago

To be fair, blocking the UI thread is still a common issue in desktop app programming, where it’s been a well-known thing for at least 1-2 decades longer. You either have to split linear execution (hard although async can make this easier in languages like Python) or go multithreaded with its own difficulties. But IME what typically happens, at least in desktop apps, is that doing a little work in the UI thread is fine until it isn’t, and the “not fine” moment can be months or years away from when the code is written. The bug reports are often vague and rare enough that it takes a while to see the pattern (eg: “it froze and then I killed the program”). And after enough of these problems, someone with experience puts a framework and some rules in place that move tasks off the UI thread. Which works until they creep back in.

schwartzworld 2y ago

Hopefully it’s not the same people getting confused.