3 ms·

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 c

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.

BjoernKW 8y ago
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.
twanvl 8y ago
Could use use <table> for the semantics but set display:block to get <div> style layout?
- olifolkerd 8y ago
  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
olifolkerd 8y ago
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
TeMPOraL 8y ago
> <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.
- olifolkerd 8y ago
  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
  - mattnewton 8y ago
    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.
    - TeMPOraL 8y ago
      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.
      - lazyasciiart 8y ago
        Do you check source on every page you see, or just the ones that feel slow?
      - olifolkerd 8y ago
        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
itodd 8y ago
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.
- warpech 8y ago
  You're very welcome! I am happy to hear it is used to make the World a better place :)

BjoernKW 8y ago

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.

twanvl 8y ago

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

olifolkerd 8y ago
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

olifolkerd 8y ago

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

TeMPOraL 8y ago

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

olifolkerd 8y ago
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
- mattnewton 8y ago
  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.
  - TeMPOraL 8y ago
    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.
    - lazyasciiart 8y ago
      Do you check source on every page you see, or just the ones that feel slow?
    - olifolkerd 8y ago
      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

itodd 8y ago

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.

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