Hacker News Reader

Comment by johangavle | Hacker News Reader

I have wondered about this countless times... a game can render hundreds of thousands of polygons per frame but DOM cant handle more than a few thousands of elements without lagging. JavaScript has come a long way, wish the rest of it would catch up. If we as devs can virtualize it, surely browser vendors could too

View on HN

You’re hinting at something interesting there. As someone who‘s in web professionally but has been programming games as a hobby, I have only naive insight into the latter.

But from that superficial understanding I assume it has to do with control:

In a game you control the rendering/layout logic more specifically. Not every element has to follow all the rules, they need to follow certain rules, scoped to their use case.

With CSS we only have high level control _and_ a predefined data structure that may or may not make sense for specific cases (DOM tree), so each rendering node has to respect _all_ the features, plus _all_ these dependencies are propagated across the whole tree, whether it makes sense or not for a given use case.

If we had more generic, less abstract control, we would not have the same problems. Maybe there is merit in exposing more control to web developers.

Just guessing here but perhaps they are adhering to some spec about how DOM should work and behave that is as old as the web itself :) HTML standards, JS standards, CSS standards all move forward, perhaps we need a DOM 2.0. Or a new browser that rethinks how it handles DOM to shake things up

Google docs decided to just turn the page in to a big <canvas> and render everything manually.

Yeah they sure have the resources available to pull such things off. But for the rest of us I dont think it is a way forward at the moment. You really start from scratch and how do you fix accessibility and such. Must have required huge effort on their part

That works because Google Docs is a full-screen app. You can't really use Canvas-rendered tables inside a regular web page: it doesn't scale, for one.

I have made a super fast spreadsheet-like component called DataGridXL, based on DOM, not canvas. A performant One Million Cells demo can be found here: https://www.datagridxl.com/demos/one-million-cells

There's a difference between the two, right? The browser is not just "rendering polygons" - it's actually laying them out. Position of one affects another.

Have thousands of physics entities in a game interacting with each other and see how it goes. That's why we see things like "millions of falling ducks" as an impressive demo or benchmark for 3D programs/engines.

See, when you're talking about rendering, you're saying millions. And even then you're talking about millions of elements in a physical simulation, all interacting with each other etc.

The browser struggles to display even a few hundred elements. You can't even animate something efficiently if that touches even the smallest part of a layout.

So yes. There's a difference between the two. The browser at the core is a system for rendering a page of text and a few images. It's unbelievably inefficient for almost literally everything else.

You can change thousands of DOM nodes in an eye-blink, but not while scrolling. It's too much for the DOM to repaint/redraw itself and keep 60fps scrolling.

I have managed to create the fastest Javascript Data Grid out there by not working with indivual <td> or <div> nodes for cells, but by using a neat CSS style: this only needs one dom node per COLUMN, not per cell.

The downside is that the product does not support multi-line rows.

Here's a performant demo of One Million Cells: https://www.datagridxl.com/demos/one-million-cells.

Reply on news.ycombinator.com