[troupo]

Just because you played Quake doesn't mean the web is good for "vast majority of apps".

The web can barely display simple text and images without jank because that is inherent limitation of the DOM that you cannot escape (that, and the absolute dearth of useful controls and utilities in the browser).

You could of course build stuff with canvas/WebGPL/WebGPU, but then you have to reinvent the whole world from scratch because those are low-level (and in case of Canvas quite limited) APIs

[throwitaway1123]

> Just because you played Quake doesn't mean the web is good for "vast majority of apps"

It means that at least 15 years ago it was more than powerful enough for all of the 2D Candy Crush style games which make up the overwhelming majority of mobile gaming apps.

> The web can barely display simple text and images without jank because that is inherent limitation of the DOM that you cannot escape

I've seen you repeat this phrase over and over again like a mantra on HN, but without examples I can't really gauge the performance problems you've run in to. The overwhelming majority of jank on the web that I've experienced is due to advertising bloatware (an adblocker is indispensable), and occasionally bad engineering (e.g. someone forgot to make an event listener passive, or isn't debouncing an event) not some inherent limitation of the platform. What are some examples of popular apps that you think require the full brunt of a modern chip? Every M3 iPad review I've watched ends up saying essentially the same thing: "this chip is powerful, but besides Geekbench benchmarks we have nothing to use it for".

[lukeschlather]

One thing I can quantify directly: in Zoom's native Windows app I can reply to a question and share my screen essentially instantly. That is to say I can do like "you can see here" and I've shared my screen before I've finished speaking, in the Google Meet PWA I have to say "here let me show you..." and pause while I wait for the screen share UI to load, I find the button to share the correct screen, and go.

I don't think it's an exaggeration to say that Zoom saves me 5 minutes out of every 30 in meetings, in fact it might be conservative. And this isn't just a question of the chips (though native Zoom does make better use of it) but also display, audio input/output, even global keyboard shortcut handling.

[throwitaway1123]

After some of the CVEs linked to the Zoom desktop clients I wouldn't touch them with a ten foot pole [1][2], but I don't want to move the goalposts since we're talking about performance here. It's hard to tell whether or not the disparity is due to a Screen Capture API performance issue, or just bad engineering from the front end team at Google Meet, or even just bad UI design. Hiding features behind buttons and menus will always add a noticeable delay to an action, but that's just bad UI design, not a technical problem.

> but also display, audio input/output, even global keyboard shortcut handling.

I personally have never had a display or audio hiccup that I could attribute to a browser limitation. I don't even own a device with a display powerful enough to max out Youtube.com's 8K video resolution limit. I'm not sure why you've had issues with keyboard shortcuts. Keyboard events are well established and widely supported [3].

[1] https://news.ycombinator.com/item?id=20387298

[2] https://hn.algolia.com/?q=zoom+vulnerability

[3] https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEve...

[lukeschlather]

All I can tell you is that Google Meet is thoroughly inferior to native Zoom, and the browser-based Zoom is also inferior. If you don't use both apps professionally, you don't have a feel for what it means to rely on such features working for effective communication, you don't have a basis for comparison. It's hard to quantify the cost of security, and it's equally hard to quantify the cost of bad UX.

Definitely during the pandemic - good UX meant I got to feel more present with friends and family and that was well worth any security cost.

[throwitaway1123]

I've used Zoom professionally in the browser literally within the past week, and it ran smoothly. We can trade anecdotes here, but it won't be very productive.

What I can tell you is that I felt at ease using Zoom in the browser knowing that I wasn't opening my computer up to a remote code execution vulnerability. Your UX concerns are a bit nebulous, but I'd be willing to bet that the risk assessment departments at most organizations could quantify the cost of a hacker gaining access to one of their employee's computers. I also used Zoom during the pandemic but I wasn't doing a ton of screen sharing (I was more interested in seeing my friends and family members faces rather than their screens).

[lukeschlather]

Another thing is that the native Windows app can support 50 simultaneous video streams, which makes it possible to see more people. I was in dance parties during the pandemic with enough people that it meant that I could see 50 realtime streams of people dancing. It wasn't the same as being in a room with 50 other people dancing in sync, but it was better than only seeing 25 people at once. My problems aren't so much nebulous as too numerous to explain, I could go on for a while.

Of course a lot of this is Zoom vs. Google Meet, I'm sure a lot of the things I like about Zoom work fine in the browser - but not as well as with the simultaneous video streams limitation.

You can cost out security, but a lot of the things that I love about Zoom's native app are truly priceless - it means I can see and hear more of people I care about. Another thing is supporting dual monitors with different screens, it makes it very easy to rearrange and see more than one person I want to see at a glance. You can do it with multiple browsers and so on, but it's more fiddly and you spend more time fussing with the screens, which means less time actually paying attention to the people.

[troupo]

> Of course PWAs aren't popular on platforms that deliberately go out of their way

Strange how we went from "The web is absolutely more than good enough for the vast majority of apps" to "majority of mobile gaming apps."

> I've seen you repeat this phrase over and over again like a mantra on HN, but without examples

I mean, almost every single web "app" out there suffers from this. The DOM isn't built for highly dynamic interactive applications. It's a system to deliver static text and images.

> What are some examples of popular apps that you think require the full brunt of a modern chip?

Now you're pretending I said something I didn't.

However, it's funny how the amazing fast web sites that are more than enough for the majority of apps struggle with even the most basic tasks even on maxed out machines. I mean, Slack's app needs up to 20% of CPU even on an M* Mac (last I tried it was M1 Max IIRC) to render a few animated emojis.

It's a single example, but it's quite representative of the state of the Web.

[throwitaway1123]

> Of course PWAs aren't popular on platforms that deliberately go out of their way

You've got your signals crossed. That was another commenter who wrote that statement [1].

> Strange how we went from "The web is absolutely more than good enough for the vast majority of apps" to "majority of mobile gaming apps."

We didn't go from one thing to another. I addressed a subset of the app market: gaming apps. Just like your Slack example addressed a subset of the app market: chat apps.

> I mean, almost every single web "app" out there suffers from this. The DOM isn't built for highly dynamic interactive applications. It's a system to deliver static text and images.

This is not a technical argument, it's a philosophical one. The council of browser elders never convened to proclaim that web browsers are only meant to deliver "static text and images", that's just your philosophical viewpoint. In fact, Apple is currently pushing WebXR to support the new Vision Pro, so apparently they didn't get the memo about "static text and images" [2].

> Now you're pretending I said something I didn't.

You said that the web is not performant enough. CPU speed is a pretty big component of performance.

> I mean, Slack's app needs up to 20% of CPU even on an M* Mac (last I tried it was M1 Max IIRC) to render a few animated emojis.

Slack's desktop app or Slack's web app? If you're talking about the Electron app, well then yeah bundling Chrome is never going to win efficiency awards, but now you're pretending I said something that I didn't. I'm not defending Electron apps. Everytime I discuss the web on HN someone does a bait and switch and starts talking about Electron. Don't conflate Electron with the World Wide Web.

If we're talking about chat apps, then I've watched high definition streams on Kick, Twitch, and YouTube where the chat is streaming in over Websockets faster than I can read it. The human brain at that point becomes the actual performance bottleneck. But tell me more about how the web can only handle a few lines of text (by commenting on a website).

[1] https://news.ycombinator.com/item?id=40891602

[2] https://webkit.org/blog/15443/news-from-wwdc24-webkit-in-saf...

[redwall_hp]

Quake Live also required an NPAPI browser plugin. So it wasn't a web application any more than for delivery and loading the binaries it had download.

[throwitaway1123]

Plugins like Flash, Silverlight, and NPAPI were common at the time, but anything running in a web browser is still a web application. It feels like you're making a distinction without a difference [1]. Either way, the web can performantly do what Quake Live did back then without plugins today, and it can certainly handle the Flappy Bird and Angry Birds style apps that people are playing on mobile devices today. Just take a look at some of the Unity WebGL and threejs demos.

[1] https://en.wikipedia.org/wiki/Distinction_without_a_differen...