3 ms·
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 SPA
by 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 agoPWAs are the native applications of ChromeOS, WebOS, KaiOS, and by the looks of it, many mobile applications.
- MaxBarraclough 6y agoI'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 agoIt 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.