5 ms·

> The dom is really, really fast, no, it is barely tolerable. Web apps in 2021 have trouble reaching the UI performance (latency) of early 2000 desktop softwar

> The dom is really, really fast, no, it is barely tolerable. Web apps in 2021 have trouble reaching the UI performance (latency) of early 2000 desktop software.

deleted 5y ago
[deleted]
Red_Leaves_Flyy 5y ago
Is that the fault of the web apps programmers (or their library/design choices!) or the engine?
- shadowgovt 5y ago
  A little bit of both. The DOM enforces a specific model of presentation focused on a structural, hierarchical, declarative description with layout including an automated vertical bias. Great if I want to layout something "document-shaped," a colossally bad match to the problem domain if I just want to draw a pentagon and animate it around the screen. The libraries exist to mitigate the huge problem-domain gap between the DOM model and other models.
minusf 5y ago
quite a blanket statement both for web and desktop apps... some are fast some are slow on both platforms, no?
- jcelerier 5y ago
  the immense majority of my experience on the web is slow, and on the non-web is fast, it's definitely not 50/50. I wouldn't be able to give you the name of a slow desktop app I use actually.
  - altcognito 5y ago
    It’s never about the UI, it’s what it’s trying to do before it renders. Oracle on the desktop? Slow. Heck, grep is “slow” by this definition. The web renders quite quick if you serve the content quickly. Even when the possibility of fast is there, companies like Apple and Microsoft overlay things with animations because it is “too jarring”
- altcognito 5y ago
  It’s a blanket statement because the time to render a standards based user interface is very small. Once we bring in the latency of the internet, (or on the desktop side, database or any other networked resource) all bets are off. It makes sense for Google to make this change. Why should I care anyway? Its not like anybody has cared about open document formats in this space anyway. This never was and never will be an open platform. I find it frustrating because this is just another nail in the coffin for open documents.
Jaygles 5y ago
Looking at the DOM in isolation, its pretty quick. The primary reason web apps are slow is because the business logic is typically un-optimized. I've encountered a web app that persisted its state by stringifying it and putting it into localStorage with every UI change. The resulting string was ~5MB and took 200-300ms each time (freezing the UI) on my tablet. I've encountered an app that used an in-house built chart library using jquery and D3. For each chart rendered it created a 50MB array of x-axis labels that wasn't cleaned up when the chart was destroyed. The reasons for why these inefficiencies exist is another topic. But there's nothing stopping someone from creating a complex web application that's performant.
- sgslo 5y ago
  Engineers will figure out how to make mistakes like this whether its in the browser or in a native app
  - zo1 5y ago
    Perhaps - but then the question just becomes "which one of those makes it easier for such mistakes to occur".
- MaxBarraclough 5y ago
  > The primary reason web apps are slow is because the business logic is typically un-optimized. This crops up a lot, shifting the blame from the web technologies to the developers who target those technologies, but where are the exceptions? What's the best example of a large, complex, efficient and responsive web-based application? It's easy to give examples of tragically inefficient and unresponsive web-based applications (Teams, Slack), but no one ever seems able to give a counterexample. Pinboard and Hacker News are fast and efficient precisely because they make minimal 'application-like' use of the web platform. Visual Studio Code is generally pretty responsive, but if I understand correctly there's little question that it uses vastly more computational resources than if it had been built using a 'conventional' (non-web-based) GUI toolkit.
  - sethhochberg 5y ago
est31 5y ago
It depends on what you do with it. HN is extremely fast.
- chalcolithic 5y ago
  (Un)folding a 100+ comment subtree is kind of slow, don't you think?
  - est31 5y ago
    I don't have any large such subtree at hand, but visiting large 200+ comment threads is really fast.
  - kazoomonger 5y ago
    Out of curiosity, I just tested a 100-comment thread on my phone with Firefox. Folding it was instantaneous, unfolding it took ~4 seconds. That makes me wonder what takes so long, given that the initial page load didn't take anywhere near that long.
  - zo1 5y ago
    Tried it with a sub-tree of ~240 comments just now. Less than a second on Firefox. Perfectly usable and acceptable in my opinion. To me there are probably hundreds of more annoying or slower things currently out there on the web that frustrate me.
    - jcelerier 5y ago
      "Less than a second" is definitely not an acceptable metric for any kind of UI latency. It should be at most a frame FFS, and that means 8 milliseconds on today's screens.
  - maple3142 5y ago
    Same experience on my Android phone. I just tried to unfold 75 comment, it has a noticeable latency in both chrome and firefox.

> The dom is really, really fast, no, it is barely tolerable. Web apps in 2021 have trouble reaching the UI performance (latency) of early 2000 desktop software.

deleted 5y ago

[deleted]

Red_Leaves_Flyy 5y ago

Is that the fault of the web apps programmers (or their library/design choices!) or the engine?

shadowgovt 5y ago
A little bit of both. The DOM enforces a specific model of presentation focused on a structural, hierarchical, declarative description with layout including an automated vertical bias. Great if I want to layout something "document-shaped," a colossally bad match to the problem domain if I just want to draw a pentagon and animate it around the screen. The libraries exist to mitigate the huge problem-domain gap between the DOM model and other models.

minusf 5y ago

quite a blanket statement both for web and desktop apps... some are fast some are slow on both platforms, no?

jcelerier 5y ago
the immense majority of my experience on the web is slow, and on the non-web is fast, it's definitely not 50/50. I wouldn't be able to give you the name of a slow desktop app I use actually.
- altcognito 5y ago
  It’s never about the UI, it’s what it’s trying to do before it renders. Oracle on the desktop? Slow. Heck, grep is “slow” by this definition. The web renders quite quick if you serve the content quickly. Even when the possibility of fast is there, companies like Apple and Microsoft overlay things with animations because it is “too jarring”
altcognito 5y ago
It’s a blanket statement because the time to render a standards based user interface is very small. Once we bring in the latency of the internet, (or on the desktop side, database or any other networked resource) all bets are off. It makes sense for Google to make this change. Why should I care anyway? Its not like anybody has cared about open document formats in this space anyway. This never was and never will be an open platform. I find it frustrating because this is just another nail in the coffin for open documents.

Jaygles 5y ago

Looking at the DOM in isolation, its pretty quick. The primary reason web apps are slow is because the business logic is typically un-optimized. I've encountered a web app that persisted its state by stringifying it and putting it into localStorage with every UI change. The resulting string was ~5MB and took 200-300ms each time (freezing the UI) on my tablet. I've encountered an app that used an in-house built chart library using jquery and D3. For each chart rendered it created a 50MB array of x-axis labels that wasn't cleaned up when the chart was destroyed. The reasons for why these inefficiencies exist is another topic. But there's nothing stopping someone from creating a complex web application that's performant.

sgslo 5y ago
Engineers will figure out how to make mistakes like this whether its in the browser or in a native app
- zo1 5y ago
  Perhaps - but then the question just becomes "which one of those makes it easier for such mistakes to occur".
MaxBarraclough 5y ago
> The primary reason web apps are slow is because the business logic is typically un-optimized. This crops up a lot, shifting the blame from the web technologies to the developers who target those technologies, but where are the exceptions? What's the best example of a large, complex, efficient and responsive web-based application? It's easy to give examples of tragically inefficient and unresponsive web-based applications (Teams, Slack), but no one ever seems able to give a counterexample. Pinboard and Hacker News are fast and efficient precisely because they make minimal 'application-like' use of the web platform. Visual Studio Code is generally pretty responsive, but if I understand correctly there's little question that it uses vastly more computational resources than if it had been built using a 'conventional' (non-web-based) GUI toolkit.
- sethhochberg 5y ago

est31 5y ago

It depends on what you do with it. HN is extremely fast.

chalcolithic 5y ago
(Un)folding a 100+ comment subtree is kind of slow, don't you think?
- est31 5y ago
  I don't have any large such subtree at hand, but visiting large 200+ comment threads is really fast.
- kazoomonger 5y ago
  Out of curiosity, I just tested a 100-comment thread on my phone with Firefox. Folding it was instantaneous, unfolding it took ~4 seconds. That makes me wonder what takes so long, given that the initial page load didn't take anywhere near that long.
- zo1 5y ago
  Tried it with a sub-tree of ~240 comments just now. Less than a second on Firefox. Perfectly usable and acceptable in my opinion. To me there are probably hundreds of more annoying or slower things currently out there on the web that frustrate me.
  - jcelerier 5y ago
    "Less than a second" is definitely not an acceptable metric for any kind of UI latency. It should be at most a frame FFS, and that means 8 milliseconds on today's screens.
- maple3142 5y ago
  Same experience on my Android phone. I just tried to unfold 75 comment, it has a noticeable latency in both chrome and firefox.