3 ms·

On the topic of tables and JavaScript and using vanilla HTML: Lately I’ve felt especially frustrated that I’m wasting so much time dealing with performance for

On the topic of tables and JavaScript and using vanilla HTML: Lately I’ve felt especially frustrated that I’m wasting so much time dealing with performance for data tables, a concept that has been so thoroughly solved for decades in desktop applications. Feels like there should be a vanilla html option for a table that: - supports massive collections (“virtual tables”) - sortable, filterable by header - overflowable cells - user resizable column widths - user show/hide columns - freeze columns/rows - performance! - no strong opinions on style I struggle to find one solid option that fits all of that. Usually I have to make a sacrifice and then wrestle with the library of choice for that missing feature.

yashasolutions 2y ago
Have you tried Tanstack, they have a headless solution that is pretty neat. Also work with vanilla.
- _heimdall 2y ago
  I've found it way easier to keep table logic on the server since that's almost certainly where the data lives. Any filtering, sorting, pagination, etc in the client should just trigger an AJAX call PR similar (HTMX works great here) to request an updated table and swap in the new markup. Tanstack table, and really any table library running in the browser, is extremely heavy and complex to manage and maintain. You either end up with a copy of your entire dataset living in the browser memory or any changes to the view still requests to the server, getting back JSON instead of HTML. That JSON has to be parsed, merged with the current state, and run through client-side rendering logic to update the DOM to end up with the HTML that could have been rendered on the server directly from the original data source.
  - Waterluvian 2y ago
    This feels like the complete opposite in terms of performance. Plus it fails to cover any case where we’re just not reporting database records. Eg. Client-side data generation and analysis.
    - _heimdall 2y ago
      Performance is a whole other ball of wax. A comparison can be done, but you have to set context first with regards to the size and shape of the data set, network conditions, filtering/sorting features, etc. You'd really want to factor in database bandwidth limitations at that point, as any fully client-side table library will need to load all the data first. My primary point was on the simplicity of the stack and ease of maintaining. I would expect a performance gain in most cases as well, though there are definitely cases where client-side would perform better.
- 7sigma 2y ago
  I love tansack but even better is inertiajs, no need for an API. You get the benefits of spa without paying the tax of writing api
nicoburns 2y ago
IMO "virtual rendering" in general is one of the biggest weaknesses of the web platform. I would love to see a general-purpose solution to this.
- cxr 2y ago
  The general purpose solution is for the browsers themselves to implement the equivalent of virtualization and table sorting features and for authors and publishers to stay out of it and stick to sending the right bytes, making sure everything is marked up correctly. A Web developer is never going to be able to ship a JS blob that makes tables work the way his or her users want them to, only the way that he or she thinks works well (if that). So just put a table on the page and add links to educate people about which browsers and/or add-ons make viewing tables a good experience. If you have some compulsion to be involved in this any further, then write your own add-on and link to that.
another-dave 2y ago
To me, I think this is where HTML standards went off the rails. Rather than working on, say, the vibration API, give us built in web components that are stylable but also accessible by default. In 2024, half of the things in Bootstrap or Tailwind UI should be obsolete. Where's our OOTB carousel, date picker, rich drop-down with icon/subtext, form elements supporting AJAX state, modal windows? etc etc. All of these things should be as foolproof as an unordered list for devs to implement & the quality of websites in terms of performance & accessibility would be lifted massively
- robertoandred 2y ago
  We’ve had date pickers and modals, and scroll snapping gets you halfway to carousels.
- mcaruso 2y ago
  > Where's our OOTB carousel, date picker, rich drop-down with icon/subtext, form elements supporting AJAX state, modal windows? etc etc. You might want to take a look at what browsers have been working on lately, because a lot of what you're asking is either already here or actively developed. Some of it driven by the Open UI working group (https://open-ui.org https://open-ui.org). - Modal: see the <dialog> element, with its focus trapping out of the box, stylability through the top layer, entry and exit animations through @starting-style and the ability to transition discrete properties like `display`, etc. - Rich dropdown: browsers now support popovers, which allow you (without any JS) trigger a popover that overlays the screen in the top layer, and with automatic focus management. See also the work being done on stylable <select> elements, there's a great episode of Off The Main Thread that goes deep into all the work being done to make this happen [1]. - Carousel: see the recent work on stylable <details> elements [2], and in general the carousel project at Open UI. After <select>, the carousel is one of the main focus areas. [1] https://offthemainthread.tech/episode/stylable-select-element/ https://offthemainthread.tech/episode/stylable-select-elemen... [2] https://chromestatus.com/feature/5112013093339136 https://chromestatus.com/feature/5112013093339136 [3] https://open-ui.org/components/carousel.research https://open-ui.org/components/carousel.research
- cluckindan 2y ago
wruza 2y ago
This is where HTML/DOM differs from all other UI frameworks. Everything else has collections with custom datasets and scrolling windows. HTML does not, because it is winword derivative. From there it all went downhill and regular html developers didn’t even realize it. It’s not only about tables, but all lists, grids, trees, icon views, tiles, etc. No amount of frameworks and code that re-enables that can convince html to implement it.

yashasolutions 2y ago

Have you tried Tanstack, they have a headless solution that is pretty neat. Also work with vanilla.

_heimdall 2y ago
I've found it way easier to keep table logic on the server since that's almost certainly where the data lives. Any filtering, sorting, pagination, etc in the client should just trigger an AJAX call PR similar (HTMX works great here) to request an updated table and swap in the new markup. Tanstack table, and really any table library running in the browser, is extremely heavy and complex to manage and maintain. You either end up with a copy of your entire dataset living in the browser memory or any changes to the view still requests to the server, getting back JSON instead of HTML. That JSON has to be parsed, merged with the current state, and run through client-side rendering logic to update the DOM to end up with the HTML that could have been rendered on the server directly from the original data source.
- Waterluvian 2y ago
  This feels like the complete opposite in terms of performance. Plus it fails to cover any case where we’re just not reporting database records. Eg. Client-side data generation and analysis.
  - _heimdall 2y ago
    Performance is a whole other ball of wax. A comparison can be done, but you have to set context first with regards to the size and shape of the data set, network conditions, filtering/sorting features, etc. You'd really want to factor in database bandwidth limitations at that point, as any fully client-side table library will need to load all the data first. My primary point was on the simplicity of the stack and ease of maintaining. I would expect a performance gain in most cases as well, though there are definitely cases where client-side would perform better.
7sigma 2y ago
I love tansack but even better is inertiajs, no need for an API. You get the benefits of spa without paying the tax of writing api

nicoburns 2y ago

IMO "virtual rendering" in general is one of the biggest weaknesses of the web platform. I would love to see a general-purpose solution to this.

cxr 2y ago
The general purpose solution is for the browsers themselves to implement the equivalent of virtualization and table sorting features and for authors and publishers to stay out of it and stick to sending the right bytes, making sure everything is marked up correctly. A Web developer is never going to be able to ship a JS blob that makes tables work the way his or her users want them to, only the way that he or she thinks works well (if that). So just put a table on the page and add links to educate people about which browsers and/or add-ons make viewing tables a good experience. If you have some compulsion to be involved in this any further, then write your own add-on and link to that.

another-dave 2y ago

To me, I think this is where HTML standards went off the rails. Rather than working on, say, the vibration API, give us built in web components that are stylable but also accessible by default. In 2024, half of the things in Bootstrap or Tailwind UI should be obsolete. Where's our OOTB carousel, date picker, rich drop-down with icon/subtext, form elements supporting AJAX state, modal windows? etc etc. All of these things should be as foolproof as an unordered list for devs to implement & the quality of websites in terms of performance & accessibility would be lifted massively

robertoandred 2y ago
We’ve had date pickers and modals, and scroll snapping gets you halfway to carousels.
mcaruso 2y ago
> Where's our OOTB carousel, date picker, rich drop-down with icon/subtext, form elements supporting AJAX state, modal windows? etc etc. You might want to take a look at what browsers have been working on lately, because a lot of what you're asking is either already here or actively developed. Some of it driven by the Open UI working group (https://open-ui.org https://open-ui.org). - Modal: see the <dialog> element, with its focus trapping out of the box, stylability through the top layer, entry and exit animations through @starting-style and the ability to transition discrete properties like `display`, etc. - Rich dropdown: browsers now support popovers, which allow you (without any JS) trigger a popover that overlays the screen in the top layer, and with automatic focus management. See also the work being done on stylable <select> elements, there's a great episode of Off The Main Thread that goes deep into all the work being done to make this happen [1]. - Carousel: see the recent work on stylable <details> elements [2], and in general the carousel project at Open UI. After <select>, the carousel is one of the main focus areas. [1] https://offthemainthread.tech/episode/stylable-select-element/ https://offthemainthread.tech/episode/stylable-select-elemen... [2] https://chromestatus.com/feature/5112013093339136 https://chromestatus.com/feature/5112013093339136 [3] https://open-ui.org/components/carousel.research https://open-ui.org/components/carousel.research
cluckindan 2y ago

wruza 2y ago

This is where HTML/DOM differs from all other UI frameworks. Everything else has collections with custom datasets and scrolling windows. HTML does not, because it is winword derivative. From there it all went downhill and regular html developers didn’t even realize it. It’s not only about tables, but all lists, grids, trees, icon views, tiles, etc. No amount of frameworks and code that re-enables that can convince html to implement it.