Hacker News Reader

Comment by warpech | Hacker News Reader

Author of another library, Handsontable, here. We actually use <table>, but there are many things that are easier with <div>:

- With <div>, you have complete control over the positioning of the cells. With <table>, you delegate the layout to the browser engine. - <table> has lots of semantic meaning, which makes it slower to render than a <div>, because the browser engine needs to make a sense of it. - There are differences in how <table>s are rendered in various browsers. This is especially a problem with old browsers such as IE6. - It is trickier to implement things like floating headers, virtual scrolling with <table>

Still, Handsontable uses <table> because you can overcome these problems if you're motivated enough. The biggest benefit is that <table> gives you enhanced semantics, which are good for Accessibility, SEO or any other form of code processing.

View on HN

In addition to that, using <table> gives you out-of-the-box Excel file export because .xlsx files (which are basically zipped XML files) support HTML tables.

> <table> has lots of semantic meaning, which makes it slower to render than a <div>, because the browser engine needs to make a sense of it.

I have to ask: is this really slower overall? I didn't try to make an exact 1:1 comparison, but in my experience, all JS-powered table libraries I've seen start choking around a couple hundred elements. With HTML tables + minimal styling, I can dump 10k+ rows with no performance penalty.

<table> element is much more complex to process than a <div>. <table> is one of the few elements that actually have a dedicated "Processing model" section in the spec: https://www.w3.org/TR/html52/tabular-data.html#tabular-data-...

It is not neccessarily a bottleneck, as long as your datagrid library uses the browser's ability to render the table. But if you want a custom look and feel, such as overlapping cells, irregular shaped cells, animated cells, it's far better to do it based on <div>s instead of fighting the browser engine.

This is why you need to use a virtual DOM to prevent the DOM from being filled with elements that consume memory and slow it down

Don’t know why you are being downvoted- it’s a real technique to render only a subset of elements that fit on ~2 screen lengths and swap them out as the user scrolls for arbitrarily large tables. Just using virtual dom doesn’t magically solve this but it does make doing things like this parlor trick easier IMO.

And yet I can't shake the feeling that this is part of the problem, not the solution. I have never seen a site using vDOM that didn't feel slow. That includes everything using React that I've seen or made. It might be that the performance loss comes from excessive styling and unrelated superfluous JS, but I'd love to see some analysis on the performance overhead of just the vDOM.

vDOMs do carry a fairly significant performance overhead and they are not worth using where there is only a small amount of data to be handled (which is why it can be turned of in Tabulator if not needed) but on modern browsers it isnt really something you should be noticing.

But when you start dealing with large volumes of data they quickly become the only option.

Even a plain html table with say 10 columns will crash out /massively slow down a browser if you load in 100,000 rows of data.

Browsers simply aren't able to process that may elements being added to the DOM.

In the case of Tabulator you can handle many thousands of rows because it only adds the rows you can see to the DOM, removing/adding them as you scroll.

So yes this means there is more processing when you scroll but at the same time you aren't trying to move 100,000 od DOM elements at once which reduces the load on the browser when loading/scrolling.

Depending on the complexity of what you are dealing with there becomes a point where the trade off in processing/memory usage makes it worthwile

Do you check source on every page you see, or just the ones that feel slow?

> + minimal styling

I suspect that may be the primary reason, not JS. When you start juggling details that impact a cell, that in turn impacts all the rest of the table, so you can add up with an additive impact based on the number of cells. <divs> still have that, but actually fall under the well-optimized engine for rendering, well, divs (and other straightforward elements that only impact other elements via positioning, not by things like colspan and rowspan)

But this is speculation on my part. I can say that while I appreciate the semantic definition of table and use the tag appropriately in my own work, I never look forward to it because it's always more work than doing so with divs. There is a reason everyone was happy to leave table-based layout behind and it wasn't (just) a desire for semantic purity.

Tabulator uses aria tags to let screen readers and other accessibility tools know how the table is structured so it is still just as accessible as a normal table even with its increased complexity

Just want to say thanks for handsontable. Thanks. It is a great way for my users (scientists who live in Excel) to feel comfortable with the applications we make to help them discover new therapeutics more efficiently.

You're very welcome! I am happy to hear it is used to make the World a better place :)

Could use use <table> for the semantics but set display:block to get <div> style layout?

the problem is it isnt just the table element, it is the thead,tbody,td,th elements as well

Complex interactive tables need a great number of elements to make them run and these wont conform to the standards of using a table (you cant just put a div inside a tbody element) but that is exactly what you would need to to to get a table with a virtual DOM to work correctly.

There are a lot of different styling tweaks that would need to be overriden for each element, some of which arnt consistent across each browser.

Also people have a tendency to put styles on the generic table tab to style tables across the site. if Tabulator was to then be used on the page, it could have any number of unknown CSS properties set on it, so would essentially have to look at overriding all possible style properties.

where as no one generically styles divs or spans and they come with very little built in styling making them the ideal choice for a library that wants to keeps its functionality isolated from the rest of the site

Reply on news.ycombinator.com