Great guide that introduces people to a overcomplicated, redundant feature-creep.
People want to have powerful apps in their browser, so there's clearly a need to have access to compute shaders from JS and WASM.
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.
Sounds a lot better than 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.
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.
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.
> 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.
If Chromebooks are anything to go by, this will just end up making more hardware unusable for new software.
(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 ;)
A bit like some emacs jokes go and say the operating system is just their bootstrapper for emacs.
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.
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
Agreed, but I would argue that the only reason why it's possible to have a single URL to download and run the software is because there's decent sandboxing.
Linux does have some decent security utilities, but it's only recently that they're starting to show up in non-developer contexts for everyday apps (basically Wayland, Flatpak, Bubblewrap, all of which have experienced pushback from the community) -- and while I fully approve of that effort, it's not anywhere close to the level of security yet that the web offers.
I would say that if you would feel comfortable with a native app installation workflow that worked exactly the same as the modern web's app delivery mechanism (ie, you can click on a link and a native app that has never been pre-vetted or moderated is installed and launches on your computer without any confirmation and without taking you to a store page), then... that's halfway decent sandboxing. The first bar to clear is "do I feel comfortable running arbitrary untrusted code that has never been validated by anyone?"
The second couple of followup tests that the web itself struggles with is stuff like "is this spying on me, is this fingerprinting my computer, how easy is it for this thing to phish me?" To me, that would be when we start to move pass halfway decent sandboxing to "good" sandboxing. I'm not sure the web deserves that label.
But I don't know of any native platforms that pass even that first bar where I would feel comfortable running malicious code on the system. I mean, sure, you can set up VMs and Firejail and I could if I wanted to set up a Linux system that had good sandboxing -- but none of that stuff is accessible to your average user; it's security for the very few people who know how to set up that security. Meanwhile, the web is security for every single person with a web browser on every single one of their devices.
Arguably mobile phones have started getting closer, but Apple is still claiming that the reason they can't open up their app store is because it would be insecure, so if we take them at face value they don't believe that their sandboxing is good enough to allow for untrusted code execution. And I'm hoping that eventually the combination of Wayland and Flatpak turns into decent universal sandboxing on Linux for every app the user is running on every distro, but we've still got a long way to go.
> Additionally, HTML + CSS + JS have proven to be the most popular UI platforms
This is certainly part of it, but... people write JS that don't like JS. I don't think it's a good enough explanation on its own.
But just opinion me, I don't have strong opinions about that.