4 ms·

The web is absolutely more than good enough for the vast majority of apps. I was playing Quake Live in the browser on a thermally throttled dual core laptop 15

The web is absolutely more than good enough for the vast majority of apps. I was playing Quake Live in the browser on a thermally throttled dual core laptop 15 years ago, but the hive mind here at HN will have you believe that the generic social media apps that dominate the charts all need to be "close to the metal": https://apps.apple.com/us/charts/iphone/top-free-apps/36 https://apps.apple.com/us/charts/iphone/top-free-apps/36

troupo 2y ago
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 2y ago
  > 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 2y ago
    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 2y ago
      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 https://news.ycombinator.com/item?id=20387298 [2] https://hn.algolia.com/?q=zoom+vulnerability https://hn.algolia.com/?q=zoom+vulnerability [3] https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEve...
      - lukeschlather 2y ago
        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.
- redwall_hp 2y ago
  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 2y ago
    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_difference https://en.wikipedia.org/wiki/Distinction_without_a_differen...

troupo 2y ago

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 2y ago
> 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 2y ago
  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 2y ago
    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 https://news.ycombinator.com/item?id=20387298 [2] https://hn.algolia.com/?q=zoom+vulnerability https://hn.algolia.com/?q=zoom+vulnerability [3] https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEve...
    - lukeschlather 2y ago
      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.
redwall_hp 2y ago
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 2y ago
  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_difference https://en.wikipedia.org/wiki/Distinction_without_a_differen...