Hacker News Reader

Comment by Waterluvian | Hacker News Reader

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.

View on HN

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

We’ve had date pickers and modals, and scroll snapping gets you halfway to carousels.

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

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

[2] https://chromestatus.com/feature/5112013093339136

[3] https://open-ui.org/components/carousel.research

Here:

    <input type=”date”>

Exactly my point — compare the feature set of this, vs the experience you'd expect from an airline or hotel booking site. Stuff like entering a date range or showing additional info inline is impossible (colour-coded availability or price details, say).

Then you get onto `type="datetime-local"` and there's just no input for times at all apart from typing manually in the input field.

Google make the browser & even they don't use `input type="date"` on Google Calender — the gap is too far between the desired look & feel/functionality vs what's possible so people end up reimplementing it, which is a complete waste of everyone's efforts.

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.

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.

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.

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

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.

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.

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.

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

Reply on news.ycombinator.com