5 ms·

The dom is really, really fast, we have spent decades refining the process and there is deep tooling to support it built right into the browser. What a bunch of

The dom is really, really fast, we have spent decades refining the process and there is deep tooling to support it built right into the browser. What a bunch of nonsense.

jcelerier 5y ago
> 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.
moshmosh 5y ago
React (not just React, but they "meme"'d it) sold everyone on the DOM being slow. What they actually meant was that if you add & remove 5,000 elements one at a time in a loop, it's slow. If you don't do that it's plenty fast and all of React's tricks to "make it fast" are just overhead that are bloating and slowing down your "app". (FWIW, I actually kind of like writing React, if I must do front-end JS, so I'm not hating on it just for hating's sake)
- MaxBarraclough 5y ago
  > What they actually meant was that if you add & remove 5,000 elements one at a time in a loop, it's slow. Ok, but it's not trivial to build complex web-based applications that don't do exactly that. This is why there are so many frameworks out there that take care of that problem for you. React isn't the only one. Angular, Vue, and Svelte also handle this for the developer, using various different approaches. It's not just a gimmick. If the web standards themselves were up to the task, there'd be far less need for frameworks.
  - moshmosh 5y ago
    I would agree that companies have mostly settled on paying 20% as much for development, at the cost of 5-10x the memory footprint and 5-10x the input latency in the finished program. I think the web tends to get hit the hardest by that because if a company is targeting the web for an "app" in the first place, they've already chosen cost savings over performance and UX, so they'll be prone to make even more trade-offs for the same reason within the web platform.
    - ctvo 5y ago
      > I think the web tends to get hit the hardest by that because if a company is targeting the web for an "app" in the first place, they've already chosen cost savings over performance and UX Or it could be they're choosing a ubiquitous, open, cross platform distribution model for their app?
    - Leherenn 5y ago
refulgentis 5y ago
I must be missing something, its a "bunch of nonsense" whenever someone claims they're better off rendering to canvas for performance?
umanwizard 5y ago
I have never used a web or electron app that felt subjectively as “snappy” as equivalent desktop apps.
dmitriid 5y ago
The DOM is abysmally slow for everything except one use case: displaying a simple text page with a couple of images. The core of the web is designed to display that on a 1990s computer in a single rendering pass. Everything bolted on top adds layers of complexity and indirection resulting in a laughably slow and inefficient system. The web can't even reliably animate an item in a list for laughing out loud.
dang 5y ago
Please don't call names in HN comments. Your post would be fine (well, a little unsubstantive and flamebaity, but nothing too serious) without the swipe at the end. If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful. We're trying for a bit higher quality of discussion here, if possible. We detached this subthread from https://news.ycombinator.com/item?id=27130438 https://news.ycombinator.com/item?id=27130438.
- altcognito 5y ago
  I’ll review and I respect that youre trying to keep it civil. My swipe was more at the argument, but this could be better, sorry.
deleted 5y ago
[deleted]

The dom is really, really fast, we have spent decades refining the process and there is deep tooling to support it built right into the browser. What a bunch of nonsense.

jcelerier 5y ago

> 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.

moshmosh 5y ago

React (not just React, but they "meme"'d it) sold everyone on the DOM being slow. What they actually meant was that if you add & remove 5,000 elements one at a time in a loop, it's slow. If you don't do that it's plenty fast and all of React's tricks to "make it fast" are just overhead that are bloating and slowing down your "app". (FWIW, I actually kind of like writing React, if I must do front-end JS, so I'm not hating on it just for hating's sake)

MaxBarraclough 5y ago
> What they actually meant was that if you add & remove 5,000 elements one at a time in a loop, it's slow. Ok, but it's not trivial to build complex web-based applications that don't do exactly that. This is why there are so many frameworks out there that take care of that problem for you. React isn't the only one. Angular, Vue, and Svelte also handle this for the developer, using various different approaches. It's not just a gimmick. If the web standards themselves were up to the task, there'd be far less need for frameworks.
- moshmosh 5y ago
  I would agree that companies have mostly settled on paying 20% as much for development, at the cost of 5-10x the memory footprint and 5-10x the input latency in the finished program. I think the web tends to get hit the hardest by that because if a company is targeting the web for an "app" in the first place, they've already chosen cost savings over performance and UX, so they'll be prone to make even more trade-offs for the same reason within the web platform.
  - ctvo 5y ago
    > I think the web tends to get hit the hardest by that because if a company is targeting the web for an "app" in the first place, they've already chosen cost savings over performance and UX Or it could be they're choosing a ubiquitous, open, cross platform distribution model for their app?
  - Leherenn 5y ago

refulgentis 5y ago

I must be missing something, its a "bunch of nonsense" whenever someone claims they're better off rendering to canvas for performance?

umanwizard 5y ago

I have never used a web or electron app that felt subjectively as “snappy” as equivalent desktop apps.

dmitriid 5y ago

The DOM is abysmally slow for everything except one use case: displaying a simple text page with a couple of images. The core of the web is designed to display that on a 1990s computer in a single rendering pass. Everything bolted on top adds layers of complexity and indirection resulting in a laughably slow and inefficient system. The web can't even reliably animate an item in a list for laughing out loud.

dang 5y ago

Please don't call names in HN comments. Your post would be fine (well, a little unsubstantive and flamebaity, but nothing too serious) without the swipe at the end. If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful. We're trying for a bit higher quality of discussion here, if possible. We detached this subthread from https://news.ycombinator.com/item?id=27130438 https://news.ycombinator.com/item?id=27130438.

altcognito 5y ago
I’ll review and I respect that youre trying to keep it civil. My swipe was more at the argument, but this could be better, sorry.

deleted 5y ago

[deleted]