7 ms·

"People want to have powerful apps in their browser" There is something rotten in that statement. No, you absolutely don't have to use such power in the browse

"People want to have powerful apps in their browser" There is something rotten in that statement. No, you absolutely don't have to use such power in the browser. There is a reason we have a thing called an operating system.

skitter 3y ago
With browsers being operating systems that do sandboxing by default. If I know I want to run an app, I prefer a native version, but browsers are superior for trying things out.
devmor 3y ago
If every system has a web browser that handles WASM and program develop paradigms shift to primarily utilize it, then programs by default are cross-platform and memory sandboxed. Sounds a lot better than today.
- horsawlarway 3y ago
  I mean - to be fair, you have this already today. It's just limited to html/js/css as the tooling. Which is actually a-ok for the vast majority of use-cases. Honestly, I really don't want companies to be making GUIs using WASM/WebGPU. Html/css/js solve that domain fairly well already, and the "canvas-only" wasm implementations I've seen so far are pretty damn monstrous. Outside of being a completely opaque box to me, the user, they're also usually not terribly performant, break all sorts of expected behavior, and have cross platform issues. I'm interested in seeing if webGPU enables more ML possibilities on the web, especially ML that's running client side and not over the wire. But really - that's about it. GUI tasks seem like a bad pick for this. They're literally several steps backwards from where we are right now, and they completely remove the ability to inspect the running application as the user. And that last point is a really, really big deal. Personally, I like a web that supports things like 3rd party integrations, ad-blockers, user-agent css styling, etc. I don't want a fucking canvas riddled with ads that I cannot interact with.
  - danShumway 3y ago
    This is my one fear with GPU stuff. I'm using Canvas when I build games on the web, and that's about it. And even there I'm regularly trying to think "isn't there some way I could represent this application state as a tree?" There are a few places where this doesn't make sense, but if we're honest most application state even for native apps really ought to be represented in the form of an interactive document. I want people to be able to build more powerful stuff on the web, but I don't want them to start looking at the DOM as if it's just some inconvenient quirk of the platform rather than a really seriously integral part of the web's success as a platform. Yes, it's often inconvenient to build fancy effects on top of the DOM, yes you have to worry about updates and performance -- because your entire application state is not supposed to be in the DOM 100% of the time; the DOM should be treated as a render target presenting the application state and controls that are relevant to the user right now. The DOM forces you to represent your current app's interface as a pure-text XML tree;that is the common denominator for all of your users no matter what device or features or settings they have enabled. Targeting that common denominator is good practice because in most (not all but most) cases if you can't sit down and write out your app's current interface as presented to the user on a sheet of paper by hand as an XML tree, probably something in your interface has gone wrong or gotten too complicated and you ought to be rethinking the UX anyway.
    - beebeepka 3y ago
      But bypassing DOM is the main point when you have to draw and animate a lot of stuff quickly. I say let the browsers use these low level API for speeding up DOM and CSS. But also allow people to bypass this layer. Back in the day I migrated (more like recreated) a web RTS from DOM to canvas and getting rid of all that HTML and CSS was a massive relief. Deleted so much markup, styles and js all while improving performance massively.
      - danShumway 3y ago
        I'm using WebGL for game development right now (and am somewhat looking forward to WebGPU) -- I'm not saying everything needs to be in the DOM. Just most things. It shouldn't really be the default for application frameworks to target Canvas (and multiple frameworks do treat it like the default rendering target). Like I said: > There are a few places where this doesn't make sense, but if we're honest most application state even for native apps really ought to be represented in the form of an interactive document. An RTS may be an exception to that because for most RTS games you can't sit down and describe what's going on in the game in a clear way using a pure-text tree or interactive document. But "exception" is the important word there. Most web apps aren't games, most web apps shouldn't be laying out complicated 2D/3D graphical scenes.
- timw4mail 3y ago
  Just makes the browser the level that has to be up to date, which determines what hardware is still usable. If Chromebooks are anything to go by, this will just end up making more hardware unusable for new software.
KeplerBoy 3y ago
Telling people that the thing they want is stupid, won't stop them from wanting it.
- wiz21c 3y ago
  Alas. Three times alas...
flohofwoe 3y ago
The post is actually about using WebGPU as native library in native applications (outside the browser or Electron). (but apart from that there seems to be a growing schism between people who see the browser as a document viewer, and others who see it as an application platform, I'm definitely in the platform camp ;)
dragonelite 3y ago
Yet they all though it to be worth the engineering time to deliver this utility. While i agree with you i know a lot of people that find interaction via a browser more natural than a desktop application. A bit like some emacs jokes go and say the operating system is just their bootstrapper for emacs.
notjustanymike 3y ago
Heaven forbid a doctor be able to share a link of a 3D visualization for a procedure so patients have a better understanding of the decisions they have to make. That'd be way too convenient!
danShumway 3y ago
I'd be more sympathetic to this statement if any of the modern operating systems had halfway decent sandboxing. Insert inevitable reference to "the Birth and Death of Javascript" but native platforms should be copying the web more in general. The DOM is just structured CLI output, with all of the advantages that CLIs have. Seriously, as a user nearly every native app on my machine ought to (in a better world) be rendering its interface to a structured text format that I can inspect and modify on the fly and pipe into other applications or dynamically restyle as I see fit. Because of that structure, most web-apps can be extended arbitrarily with user extensions. The sandboxing on the web is... okay it's not great, but it's better than what anybody else is doing. The delivery platform for apps is better specifically because the sandboxing is better, which allows me to try out apps quickly without giving them a lot of unnecessary access to my computer. People are building apps in the browser because browsers offer capabilities that native operating systems don't offer. The few platforms where browser dominance doesn't hold true (iOS, Android) largely maintain native dominance by severely limiting what web browsers can do. That's the wrong way to move forward; offer a native experience that's as good as the web and people won't need to build apps on the web. Even just good application sandboxing alone would be a good start, and yet whenever something like Flatpak tries to make progress in that direction, people are constantly complaining about it and explaining that sandboxing is the wrong way to approach app security. It's not really surprising then that people look at that discussion and take away from it that maybe the desktop isn't a good fit for their app. ---- My only critique of the webGPU direction is people bypassing the DOM, which... is usually the result of native developers and native frameworks trying to bring native development patterns to the web instead of rallying behind the idea of user-inspectable pure-text interfaces in the DOM. In that regard, and very specifically in that regard, I do kind of agree that the web is becoming too much like a native operating system. In the sense that it is repeating the same exact mistakes that native operating systems made. But in regards to people just generally building apps in browsers... good. Honestly, progressive web apps are a safer, more user-respecting way to deliver functionality than native OSes are.
- shortrounddev 3y ago
  > if any of the modern operating systems had halfway decent sandboxing What qualifies as "halfway decent"? For servers, Linux seems to have a good set of utilities (taken advantage of by docker). Windows doesn't seem to have as good system calls (like chroot, for example), but UWP apps seem to be decent enough for a sandboxed app. What would be a good example of sandboxing for you? Personally I think that websites are the most popular way to distribute applications because it only requires a single link or URL to download the software and have it run immediately as required. No other cross-platform computing VM (JVM, CLR) can boast about that kind of ease of distribution. Additionally, HTML + CSS + JS have proven to be the most popular UI platforms. XAML just doesn't come close to the flexibility provided by these tools, and non-declarative UI is just out of the question for the majority of people designing websites in HTML, who are not software engineers
deleted 3y ago
[deleted]

skitter 3y ago

With browsers being operating systems that do sandboxing by default. If I know I want to run an app, I prefer a native version, but browsers are superior for trying things out.

devmor 3y ago

If every system has a web browser that handles WASM and program develop paradigms shift to primarily utilize it, then programs by default are cross-platform and memory sandboxed. Sounds a lot better than today.

horsawlarway 3y ago
I mean - to be fair, you have this already today. It's just limited to html/js/css as the tooling. Which is actually a-ok for the vast majority of use-cases. Honestly, I really don't want companies to be making GUIs using WASM/WebGPU. Html/css/js solve that domain fairly well already, and the "canvas-only" wasm implementations I've seen so far are pretty damn monstrous. Outside of being a completely opaque box to me, the user, they're also usually not terribly performant, break all sorts of expected behavior, and have cross platform issues. I'm interested in seeing if webGPU enables more ML possibilities on the web, especially ML that's running client side and not over the wire. But really - that's about it. GUI tasks seem like a bad pick for this. They're literally several steps backwards from where we are right now, and they completely remove the ability to inspect the running application as the user. And that last point is a really, really big deal. Personally, I like a web that supports things like 3rd party integrations, ad-blockers, user-agent css styling, etc. I don't want a fucking canvas riddled with ads that I cannot interact with.
- danShumway 3y ago
  This is my one fear with GPU stuff. I'm using Canvas when I build games on the web, and that's about it. And even there I'm regularly trying to think "isn't there some way I could represent this application state as a tree?" There are a few places where this doesn't make sense, but if we're honest most application state even for native apps really ought to be represented in the form of an interactive document. I want people to be able to build more powerful stuff on the web, but I don't want them to start looking at the DOM as if it's just some inconvenient quirk of the platform rather than a really seriously integral part of the web's success as a platform. Yes, it's often inconvenient to build fancy effects on top of the DOM, yes you have to worry about updates and performance -- because your entire application state is not supposed to be in the DOM 100% of the time; the DOM should be treated as a render target presenting the application state and controls that are relevant to the user right now. The DOM forces you to represent your current app's interface as a pure-text XML tree;that is the common denominator for all of your users no matter what device or features or settings they have enabled. Targeting that common denominator is good practice because in most (not all but most) cases if you can't sit down and write out your app's current interface as presented to the user on a sheet of paper by hand as an XML tree, probably something in your interface has gone wrong or gotten too complicated and you ought to be rethinking the UX anyway.
  - beebeepka 3y ago
    But bypassing DOM is the main point when you have to draw and animate a lot of stuff quickly. I say let the browsers use these low level API for speeding up DOM and CSS. But also allow people to bypass this layer. Back in the day I migrated (more like recreated) a web RTS from DOM to canvas and getting rid of all that HTML and CSS was a massive relief. Deleted so much markup, styles and js all while improving performance massively.
    - danShumway 3y ago
      I'm using WebGL for game development right now (and am somewhat looking forward to WebGPU) -- I'm not saying everything needs to be in the DOM. Just most things. It shouldn't really be the default for application frameworks to target Canvas (and multiple frameworks do treat it like the default rendering target). Like I said: > There are a few places where this doesn't make sense, but if we're honest most application state even for native apps really ought to be represented in the form of an interactive document. An RTS may be an exception to that because for most RTS games you can't sit down and describe what's going on in the game in a clear way using a pure-text tree or interactive document. But "exception" is the important word there. Most web apps aren't games, most web apps shouldn't be laying out complicated 2D/3D graphical scenes.
timw4mail 3y ago
Just makes the browser the level that has to be up to date, which determines what hardware is still usable. If Chromebooks are anything to go by, this will just end up making more hardware unusable for new software.

KeplerBoy 3y ago

Telling people that the thing they want is stupid, won't stop them from wanting it.

wiz21c 3y ago
Alas. Three times alas...

flohofwoe 3y ago

The post is actually about using WebGPU as native library in native applications (outside the browser or Electron). (but apart from that there seems to be a growing schism between people who see the browser as a document viewer, and others who see it as an application platform, I'm definitely in the platform camp ;)

dragonelite 3y ago

Yet they all though it to be worth the engineering time to deliver this utility. While i agree with you i know a lot of people that find interaction via a browser more natural than a desktop application. A bit like some emacs jokes go and say the operating system is just their bootstrapper for emacs.

notjustanymike 3y ago

Heaven forbid a doctor be able to share a link of a 3D visualization for a procedure so patients have a better understanding of the decisions they have to make. That'd be way too convenient!

danShumway 3y ago

I'd be more sympathetic to this statement if any of the modern operating systems had halfway decent sandboxing. Insert inevitable reference to "the Birth and Death of Javascript" but native platforms should be copying the web more in general. The DOM is just structured CLI output, with all of the advantages that CLIs have. Seriously, as a user nearly every native app on my machine ought to (in a better world) be rendering its interface to a structured text format that I can inspect and modify on the fly and pipe into other applications or dynamically restyle as I see fit. Because of that structure, most web-apps can be extended arbitrarily with user extensions. The sandboxing on the web is... okay it's not great, but it's better than what anybody else is doing. The delivery platform for apps is better specifically because the sandboxing is better, which allows me to try out apps quickly without giving them a lot of unnecessary access to my computer. People are building apps in the browser because browsers offer capabilities that native operating systems don't offer. The few platforms where browser dominance doesn't hold true (iOS, Android) largely maintain native dominance by severely limiting what web browsers can do. That's the wrong way to move forward; offer a native experience that's as good as the web and people won't need to build apps on the web. Even just good application sandboxing alone would be a good start, and yet whenever something like Flatpak tries to make progress in that direction, people are constantly complaining about it and explaining that sandboxing is the wrong way to approach app security. It's not really surprising then that people look at that discussion and take away from it that maybe the desktop isn't a good fit for their app. ---- My only critique of the webGPU direction is people bypassing the DOM, which... is usually the result of native developers and native frameworks trying to bring native development patterns to the web instead of rallying behind the idea of user-inspectable pure-text interfaces in the DOM. In that regard, and very specifically in that regard, I do kind of agree that the web is becoming too much like a native operating system. In the sense that it is repeating the same exact mistakes that native operating systems made. But in regards to people just generally building apps in browsers... good. Honestly, progressive web apps are a safer, more user-respecting way to deliver functionality than native OSes are.

shortrounddev 3y ago
> if any of the modern operating systems had halfway decent sandboxing What qualifies as "halfway decent"? For servers, Linux seems to have a good set of utilities (taken advantage of by docker). Windows doesn't seem to have as good system calls (like chroot, for example), but UWP apps seem to be decent enough for a sandboxed app. What would be a good example of sandboxing for you? Personally I think that websites are the most popular way to distribute applications because it only requires a single link or URL to download the software and have it run immediately as required. No other cross-platform computing VM (JVM, CLR) can boast about that kind of ease of distribution. Additionally, HTML + CSS + JS have proven to be the most popular UI platforms. XAML just doesn't come close to the flexibility provided by these tools, and non-declarative UI is just out of the question for the majority of people designing websites in HTML, who are not software engineers

deleted 3y ago

[deleted]