Hacker News Reader

Comment by jcelerier | Hacker News Reader

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

View on HN

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.

Engineers will figure out how to make mistakes like this whether its in the browser or in a native app

Perhaps - but then the question just becomes "which one of those makes it easier for such mistakes to occur".

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

Figma is one of my favorite examples of something which is a nontrivial webapp that avoid feeling like a webapp a lot of the time, even when running in a browser instead of their Electron wrapper.

But their technical leadership contains some of the (arguably) most accomplished folks working in the Javascript world these days, they might be an outlier in this area.

How is it on resource-usage though?

Another example: Google Docs seems ok on responsiveness, but not on efficiency (especially memory).

It’s easy to forget that Figma is a webapp, until you leave it running in the background and your $2000 computer grinds to a halt.

Figma is built in Web-Assembly (compiled from C++) [1] and Canvas, basically sidestepping the vast majority of the web stack. That's why it's fast.

[1]: https://www.figma.com/blog/webassembly-cut-figmas-load-time-...

This exchange is absolutely hilarious to me. We've got people complaining about Google doing something while praising Figma for not being so foolish or evil and extolling them as being exceptionally clever. Except oops, turns out Figma is doing the same thing that is believed to be foolish or evil.

It turns out HN is prone to the same sort of knee jerk reactions as most every other "social news" site (even if to a lesser degree). Who would've thought?!

Neat, I had no idea it wasn't a normal old DOM application. Certainly does add a lot of validation to Google's approach here.

> But there's nothing stopping someone from creating a complex web application that's performant.

Google--the folks who make V8--seem to disagree with you here. If they find canvas rendering to be more performant, then I'm going to believe them absent more information.

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

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.

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

(Un)folding a 100+ comment subtree is kind of slow, don't you think?

I don't have any large such subtree at hand, but visiting large 200+ comment threads is really fast.

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.

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.

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

Same experience on my Android phone. I just tried to unfold 75 comment, it has a noticeable latency in both chrome and firefox.

Same here, just this comment's tree starts to have some perceptible latency on my one+ 8 pro (which should be pretty powerful. In contrast I have some Qt apps where unfolding trees with tens of thousands of nodes is instant.

quite a blanket statement both for web and desktop apps...

some are fast some are slow on both platforms, no?

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.

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”

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.

Reply on news.ycombinator.com