4 ms·

Websites do the same thing as 15 years ago? Not true, websites can now exceed desktop apps. Was their figma 15 years ago? 20 times more complex - this comes wi

Websites do the same thing as 15 years ago? Not true, websites can now exceed desktop apps. Was their figma 15 years ago? 20 times more complex - this comes with doing more. 15 years ago there was no CI/CD. Write CSS - don’t have to given Sass, components, and bootstrap. Performance is worse - look at v8 benchmarks, look at webgl and Wasm. The browser itself can run much faster today, and people are doing more with it. JS barebones - just one package. https://github.com/stdlib-js/stdlib https://github.com/stdlib-js/stdlib. - and the node ecosystem is a feature not a bug. Look elsewhere - every other UI framework we’ve tried before has been worse in terms of compatibility, functionality, flexibility, and available prebuilt tooling.

lapinot 3y ago
Nothing you say is wrong per se. But what GP is saying i believe is that most website should not need these features to provide value to users. And indeed most website useful to me are still mildly interactive documents. The problem is that web browsers, standards, ecosystems inflated to cater these few webapps needing advanced control over the machine. In a sense web is just the new java: a new environment said to be "cross-plateform" where it is in fact just a new plateform that got its vm ubiquitous. The web-as-vm has nothing wrong, but it has eaten the web-as-interactive-documents. And now to have a lightweight web experience not focused on webapps i am stuck with the heavyweight runtimes with even more stuff on top just to disable features, lock down invasive websites that grabbed the newly available features to implement invasive anti-features, etc.
speed_spread 3y ago
In the late 90's we had native apps with UIs more complex than Figma that ran fine with 1/100 the CPU, RAM and storage we have now. The online rush buried a whole class of development tools that has to be painfully reinvented over the next 20 years and are still bogged down by the incidental complexity of using the web as an application platform.
- ptx 3y ago
  One example of this, I think, is that modern UIs are seemingly no longer able to display large lists. The native win32 API had virtualized list views 27 years ago, since Windows 95 OSR2 [1][2]. [1] https://learn.microsoft.com/en-us/windows/win32/controls/list-view-controls-overview https://learn.microsoft.com/en-us/windows/win32/controls/lis... [2] https://www.geoffchappell.com/studies/windows/shell/comctl32/history/ https://www.geoffchappell.com/studies/windows/shell/comctl32...
- aranchelk 3y ago
  IIRC they were: * Often Windows-only. * Infrequently updated, with bugs bad enough to crash the app, sometimes the system * Dependent on the user to install new versions * Able to access everything on your computer * Non-collaborative * Dependent on you for data backups These are non-trivial things. Now that I’m thinking about it, I still don’t have convenient sandboxing of desktop apps.
  - speed_spread 3y ago
    We have online package managers, garbage collected languages, containers, unit testing, memory protection, remote backups, cross platform UI toolkits - None of the issues you mention required having to serve everything through a browser window set in motion by a subpar language written over a weekend with cosmetic considerations as first design principle. BTW you can have easy app sandboxing today using flatpak, works like a charm on Fedora.
    - ptx 3y ago
      Is the Flatpak sandboxing actually secure, though? Or does it work like a charm because most of the security enforcement is disabled in practice? Allegedly [1] a lot of popular packages use "--filesystem=host", which completely defeats the security of sandbox by granting access to the user's home directory (i.e, allows arbitrary code execution through modification of configuration files). I think I would rather trust the browser's sandbox, where sandboxing has been in place from the start and applications are designed for it. [1] https://flatkill.org/2020/ https://flatkill.org/2020/
      - speed_spread 3y ago
        It's true many flatpaks are still leaky to match usability expectations. We don't know how to devise proper information partitioning schemes or aren't willing to accept the ones we come up with it. Ultimately it comes down to who you trust the most. Do you trust your cloud provider to not look at your data and sell you off or do you prefer trusting your local application to not fuck around where it shouldn't?
  - 3y ago

lapinot 3y ago

Nothing you say is wrong per se. But what GP is saying i believe is that most website should not need these features to provide value to users. And indeed most website useful to me are still mildly interactive documents. The problem is that web browsers, standards, ecosystems inflated to cater these few webapps needing advanced control over the machine. In a sense web is just the new java: a new environment said to be "cross-plateform" where it is in fact just a new plateform that got its vm ubiquitous. The web-as-vm has nothing wrong, but it has eaten the web-as-interactive-documents. And now to have a lightweight web experience not focused on webapps i am stuck with the heavyweight runtimes with even more stuff on top just to disable features, lock down invasive websites that grabbed the newly available features to implement invasive anti-features, etc.

speed_spread 3y ago

In the late 90's we had native apps with UIs more complex than Figma that ran fine with 1/100 the CPU, RAM and storage we have now. The online rush buried a whole class of development tools that has to be painfully reinvented over the next 20 years and are still bogged down by the incidental complexity of using the web as an application platform.

ptx 3y ago
One example of this, I think, is that modern UIs are seemingly no longer able to display large lists. The native win32 API had virtualized list views 27 years ago, since Windows 95 OSR2 [1][2]. [1] https://learn.microsoft.com/en-us/windows/win32/controls/list-view-controls-overview https://learn.microsoft.com/en-us/windows/win32/controls/lis... [2] https://www.geoffchappell.com/studies/windows/shell/comctl32/history/ https://www.geoffchappell.com/studies/windows/shell/comctl32...
aranchelk 3y ago
IIRC they were: * Often Windows-only. * Infrequently updated, with bugs bad enough to crash the app, sometimes the system * Dependent on the user to install new versions * Able to access everything on your computer * Non-collaborative * Dependent on you for data backups These are non-trivial things. Now that I’m thinking about it, I still don’t have convenient sandboxing of desktop apps.
- speed_spread 3y ago
  We have online package managers, garbage collected languages, containers, unit testing, memory protection, remote backups, cross platform UI toolkits - None of the issues you mention required having to serve everything through a browser window set in motion by a subpar language written over a weekend with cosmetic considerations as first design principle. BTW you can have easy app sandboxing today using flatpak, works like a charm on Fedora.
  - ptx 3y ago
    Is the Flatpak sandboxing actually secure, though? Or does it work like a charm because most of the security enforcement is disabled in practice? Allegedly [1] a lot of popular packages use "--filesystem=host", which completely defeats the security of sandbox by granting access to the user's home directory (i.e, allows arbitrary code execution through modification of configuration files). I think I would rather trust the browser's sandbox, where sandboxing has been in place from the start and applications are designed for it. [1] https://flatkill.org/2020/ https://flatkill.org/2020/
    - speed_spread 3y ago
      It's true many flatpaks are still leaky to match usability expectations. We don't know how to devise proper information partitioning schemes or aren't willing to accept the ones we come up with it. Ultimately it comes down to who you trust the most. Do you trust your cloud provider to not look at your data and sell you off or do you prefer trusting your local application to not fuck around where it shouldn't?
- 3y ago