4 ms·

>I miss proper custom desktop apps with horrible looking cluttered interfaces. Soo productive compared to any web based interface for almost all tasks. You mea

>I miss proper custom desktop apps with horrible looking cluttered interfaces. Soo productive compared to any web based interface for almost all tasks. You mean where everything runs on the UI thread? Gotta pass on that. :)

donatj 10y ago
In my experiences being forced to use various SPAs from various venders, more often than not async just means I need to behave single threaded rather than the app lest I wish to trigger race conditions that desync the local model and I end up having to hard refresh.
wcummings 10y ago
But (most) browser apps are single threaded and you can block the UI if you do anything intensive on the client-side.
- fbender 10y ago
  There quite a few ways around that with async APIs and WebWorkers, even ServiceWorkers now. A lot of devs just don't use them properly. Edit: Did you mean the browser itself could freeze? That's a thing of the past with Firefox being the last browser to separate the content and chrome process. So the web page may freeze, the browser window itself shouldn't.
  - wcummings 10y ago
    Those are relatively new features, and aren't used a whole lot.
    - fbender 10y ago
      WebWorkers are not a new "feature". The last browser to support it was (on desktop) IE in v10 (4 years ago) and on mobile Android 4.4 (3 years ago). Though that doesn't really matter since you can polyfill it, which obviously does not give you multithreading in those older browsers but it still forces you to think async. Regarding other APIs, a great number has been available since many years, and any newly introduced API since at least 5 years is either non-blocking or async.
alkonaut 10y ago
Not necessarily - although that's usually fine. I prefer a non responsive UI when waiting for io/db, to a poorly implemented background execution where you aren't sure anything is actually happening.
- FLUX-YOU 10y ago
  > I prefer a non responsive UI when waiting for io/db, to a poorly implemented background execution where you aren't sure anything is actually happening. You can't be sure anything is happening on a locked desktop app either though, so at least you can close it gracefully if it's doing that on another thread IME customers close stuff if Windows shows "Not Responding" but not if you just have a fake progress bar.
0xfeba 10y ago
Heh, the MS Windows file/folder permissions tab comes to mind when you mention that. Been single-threaded for 20+ years now. Clicking on the Add... button always freezes the UI while it communicates with the domain controller or whatever it does. http://imgur.com/a/YbGbU http://imgur.com/a/YbGbU
- compuguy 10y ago
  True, that's why I enable running explorer as a secondary process, so the desktop doesn't completely freeze.

donatj 10y ago

In my experiences being forced to use various SPAs from various venders, more often than not async just means I need to behave single threaded rather than the app lest I wish to trigger race conditions that desync the local model and I end up having to hard refresh.

wcummings 10y ago

But (most) browser apps are single threaded and you can block the UI if you do anything intensive on the client-side.

fbender 10y ago
There quite a few ways around that with async APIs and WebWorkers, even ServiceWorkers now. A lot of devs just don't use them properly. Edit: Did you mean the browser itself could freeze? That's a thing of the past with Firefox being the last browser to separate the content and chrome process. So the web page may freeze, the browser window itself shouldn't.
- wcummings 10y ago
  Those are relatively new features, and aren't used a whole lot.
  - fbender 10y ago
    WebWorkers are not a new "feature". The last browser to support it was (on desktop) IE in v10 (4 years ago) and on mobile Android 4.4 (3 years ago). Though that doesn't really matter since you can polyfill it, which obviously does not give you multithreading in those older browsers but it still forces you to think async. Regarding other APIs, a great number has been available since many years, and any newly introduced API since at least 5 years is either non-blocking or async.

alkonaut 10y ago

Not necessarily - although that's usually fine. I prefer a non responsive UI when waiting for io/db, to a poorly implemented background execution where you aren't sure anything is actually happening.

FLUX-YOU 10y ago
> I prefer a non responsive UI when waiting for io/db, to a poorly implemented background execution where you aren't sure anything is actually happening. You can't be sure anything is happening on a locked desktop app either though, so at least you can close it gracefully if it's doing that on another thread IME customers close stuff if Windows shows "Not Responding" but not if you just have a fake progress bar.

0xfeba 10y ago

Heh, the MS Windows file/folder permissions tab comes to mind when you mention that. Been single-threaded for 20+ years now. Clicking on the Add... button always freezes the UI while it communicates with the domain controller or whatever it does. http://imgur.com/a/YbGbU http://imgur.com/a/YbGbU

compuguy 10y ago
True, that's why I enable running explorer as a secondary process, so the desktop doesn't completely freeze.