4 ms·

JS is not single threaded in the way you indicate. JS parsers, compilers, and even some garbage collectors are threaded. IO (arguably the most common case for

by hajile 6y ago

JS is not single threaded in the way you indicate. JS parsers, compilers, and even some garbage collectors are threaded. IO (arguably the most common case for threads) is threaded behind the scenes. Web Workers allow using multiple cores/processes for typical parallel programming. Message passing exists as do shared memory and even atomics (note: node, firefox, and chromium-based browsers all have it available after Spectre/meltdown mitigations were added, but it's still disabled in Safari). What JS really needs is a CSP or Actor model on top to abstract away threads/OS processes/cores/hardware and let the VM handle them seamlessly like in Erlang/BEAM.

MaxBarraclough 6y ago
> What JS really needs is a CSP or Actor model on top to abstract away threads/OS processes/cores/hardware What kind of website would benefit from this?
- pjmlp 6y ago
  SPA and PWAs.
  - MaxBarraclough 6y ago
    Is the point here concurrency or parallelism? If it's concurrency, is it something that could be done in a library? As for parallelism, I don't think many SPAs and PWAs really need to be able to make full use of multicore for acceptable performance, do they? If you're writing heavyweight number-crunching code, that belongs either server-side or in a native application.
    - pjmlp 6y ago
      PWAs are the native applications of ChromeOS, WebOS, KaiOS, and by the looks of it, many mobile applications.
      - MaxBarraclough 6y ago
        I'm not convinced it's the right move for the web to try to accommodate the development of every conceivable kind of GUI application. This doesn't change when someone makes a computer whose only GUI toolkit is a web browser. If you try to port Red Dead Redemption 2 to JavaScript, you're going to have a bad time. That's not the fault of the web, it's just not an appropriate choice of platform. Like I said in another comment in this thread, the downsides of the web as a platform wouldn't go away by improving its support for parallelism or for concurrency. Web-based UIs would still seem clunky and half-baked compared to native apps, and they'd still use far more computational resources than native apps.
        pjmlp 6y ago
        It will get ported to WebGL/GPU with WebAssembly, it is still Web. I also do prefer native, yet as mentioned, web browsers or web widgets as GUI toolkits are a fact and aren't going away. Specially if everyone keeps pushing packaged ChromeOS apps, aka Electron.

by hajile 6y ago

MaxBarraclough 6y ago

> What JS really needs is a CSP or Actor model on top to abstract away threads/OS processes/cores/hardware What kind of website would benefit from this?

pjmlp 6y ago
SPA and PWAs.
- MaxBarraclough 6y ago
  Is the point here concurrency or parallelism? If it's concurrency, is it something that could be done in a library? As for parallelism, I don't think many SPAs and PWAs really need to be able to make full use of multicore for acceptable performance, do they? If you're writing heavyweight number-crunching code, that belongs either server-side or in a native application.
  - pjmlp 6y ago
    PWAs are the native applications of ChromeOS, WebOS, KaiOS, and by the looks of it, many mobile applications.
    - MaxBarraclough 6y ago
      I'm not convinced it's the right move for the web to try to accommodate the development of every conceivable kind of GUI application. This doesn't change when someone makes a computer whose only GUI toolkit is a web browser. If you try to port Red Dead Redemption 2 to JavaScript, you're going to have a bad time. That's not the fault of the web, it's just not an appropriate choice of platform. Like I said in another comment in this thread, the downsides of the web as a platform wouldn't go away by improving its support for parallelism or for concurrency. Web-based UIs would still seem clunky and half-baked compared to native apps, and they'd still use far more computational resources than native apps.
      - pjmlp 6y ago
        It will get ported to WebGL/GPU with WebAssembly, it is still Web. I also do prefer native, yet as mentioned, web browsers or web widgets as GUI toolkits are a fact and aren't going away. Specially if everyone keeps pushing packaged ChromeOS apps, aka Electron.