Hacker News Reader

Comment by altcognito | Hacker News Reader

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.

View on HN

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

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.

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

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.

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.

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.

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.

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

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.

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)

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

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.

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

I disagree, I prefer to Google something and have it instantly in my browser instead of having to find and install yet another app, then uninstall it when I'm done with it. Especially for stuff I only use once/rarely.

Also, I might be using the latest iPhone, an old Android, Windows or Linux, or hell maybe my TV browser, and it's most likely going to work. The app wouldn't exist on at least half those platforms.

There certainly are issues with webapps, but well done it can a really good UX.

You're right that the web scores extremely well on portability and on having zero installation hassle. The points about efficiency still stand though. To put that another way: the web's upsides are real, and so are its downsides.

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

Reply on news.ycombinator.com