[Gigachad]

Tables like you mention, have infinite complexity and requirements. If all you need is the most basic grid, the built in <table> element is fine.

But what happens when you need inline editing, filters, searches, live updating data from a server, keyboard shortcuts, etc.

A single standard element will never handle everyone's use cases. The parent comment is seeing new wheels being designed for a high speed train and wondering why they are reinventing the wheel when wheels have existed forever.

[robbiejs]

Exactly, many different JS table/data grid/spreadsheet products out there, but there's not a single one that can "do it all". There's different categories, broadly:

1. A read-only table for presentation purposes, with pagination and sorting options. (DataTables)

2. A read-only data grid that supports high-frequency updates/redraws, for things like Stock or Bitcoin trading. (Ag-grid?)

3. A data grid to edit JSON/Javascript data, with user-friendly spreadsheet-like controls. (DataGridXL)

4. A spreadsheet-product, with features like formulas, merged cells, HTML (images) in cells, pivot tables, etc. (Handsontable?)

Source: https://www.datagridxl.com/compare.

[vaughan]

I have never used a data grid control that didn't end up with me having to dig deep into the code to add something custom that I needed, and just hit brick wall after brick wall. Especially React-based ones.

We don't need big libraries, we need to mix smaller libraries together that each do one thing well.

Like starting with a tutorial of how to build a data grid from scratch with suggestions of utilities to add along the way. Most people would avoid this because they see a library that does most of what they want and get a FOMO...but if they could only see the hours they will lose trying to customize it, they would have preferred to start from scratch. This has been such a constant experience for me with almost every framework/library in tech.

[dmitriid]

> The parent comment is seeing new wheels being designed for a high speed train and wondering why they are reinventing the wheel when wheels have existed forever.

Nope. The parent is seeing reinvention of basic UI capabilities such as a basic table and virtualized scrolling and wondering why they are not available natively

[johangavle]

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

[dgb23]

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.

[johangavle]

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

[Gigachad]

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

[robbiejs]

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

[johangavle]

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

[madeofpalk]

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.

[dmitriid]

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.

[robbiejs]

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.

[vaughan]

> But what happens when you need

My experience is that a lot of these features are more easily implemented than the time taken to handle the edge cases of using existing libraries, getting them to work with your UI framework (React/Angular), and getting them to work with your data service layer.