Comment by olifolkerd | Hacker News Reader

Comment by olifolkerd | Hacker News Reader

Parent Full thread

Let me preface my answer by saying im the chap that built Tabulator

This is because the <table> element introduces a lot of design constraints.

There is a lot of inhernt styling that would have to be overridden if a table element was to be used. it could also mess with the standard behaviour of other table elements that have been generically styled.

Importantly when you start building interactive complex tables there are 100's of different types of elements needed to make the table function correctly that a standard HTML element simple isn't designed to handle, event making the header and the body scroll separately requirements more elements that a standard table can handle and it would invalid HTML to use the tags inside the table that would be needed to achieve it.

Especially when you move into the world of the virtual DOM a standard table element simply wont cut it

With the inclusion of aria tags there are no accessibility issues as screen readers treat them just as any other tables.

For others; your last point is the most important. Semantic HTML gets you pretty far but there will always be an unhandled case. This is a fine use case of ARIA as long as it’s met with sincere concern for accessibility testing.

Appreciate the details. I've done some minor JS-based table controls while using <table>, but I wasn't dealing with thousands of rows so didn't need the virtual DOM. Sounds like that's the biggest obstacle. Nice work on the project!

For the nested markup and styling it sounds like a perfect fit for creating a web component no?

The virtual DOM, while very impressive, isn't necessary as well. Really depends on what problem you are solving there and what level of support you need for browsers. What problem are you solving? Many entries? Minimal cell mutation control?

For Tabulator the virtual DOM is essential. if you try and load 10,000 rows into a table either the browser will slow down and become almost unusable or crash entirely.

For large data sets it makes the table work regardless of the number of rows

What if you just chunk your DOM writes into small batches, and then put them into a queue, which is then consumed within a requestAnimationFrame() handler? A bit of indirection, but not nearly as much as a complete virtual DOM. (I assume this would result in the table "slowly" populating, but the browser and the page should both remain responsive.)

You can can do this but for large data sets it would take ages and doesnt over come the main issue.

Lets say we are working with 10,000 rows

Yes loading that many elements into the DOM is slow and your approach would stop it blocking, however what it dosnt do is stop the sheer number of elements from overloading the DOM.

Most browsers simply cant handle that many elements in the DOM, if you try and scroll a div containing that may elements at best it will be sluggish and at worst it will simply crash the browser. on devices without much memory it is very likely that the whole DOM will freeze up and make the site unusable.

By adding and deleting the elements as they become visible/hidden it keeps the number of elements in the DOM to a minimum, while improving load time and adding only a bit of extra processing to the scroll event, which modern browsers can handle with ease. giving all round the best solution

Ah, I didn't realize that "culling" of non-viewport-visible divs happened within your vDOM implementation. I agree that that would need to happen either way. If the "culling" process was a separate layer, though, it could also be implemented on top of the DOM-queuing process I mentioned.

I did this myself when writing a chat client's infinite history scrollback. Chat messages that aren't on the screen still have a pure-data "event" representation of them loaded, but their DOM representation (virtual or otherwise) is entirely discarded. Rather than the physical DOM nodes for chat-message divs having fixed positions such that they're able to disappear without affecting their peers' layout, I instead just have the chat messages stacked as regular block elements under reflow, with two fixed-size "scroll pad" divs just above and below the viewport "consuming" and "releasing" the vertical height that had been taken up by message divs as they're added and removed. You can have millions of rows "loaded" (in the sense of parsed data sitting in JS memory) for instant access, with not much browser memory usage at all.

Though, even that memory usage was too much (this chat client is supposed to run beside memory-intensive apps like games), so as well, in my setup, nodes that are far enough off the screen can have their parsed "event" representation discarded, and replaced with a single URL representing the serialized "history chunk" that those events came from. When the scroll distance comes close to them, the chunks are reloaded by re-requesting and re-parsing the chunk (which, helpfully, is usually still in the browser cache.)

Reply on news.ycombinator.com