How I made Google’s data grid scroll faster with a line of CSS • Hacker News Board

Re: How I made Google’s data grid scroll faster with a line of CSS

#221

Post by tshaddox » Sat, Oct 30, 2021, 8:21 PM UTC

dmitriid wrote: post #157

tshaddox wrote: post #53

Earlier quoted context omitted.

I like https://airtable.com/ , https://linear.app/ , and https://height.app/ . They are all pushing the limits of interactive web apps, not always entirely successfully, but the overall product experience is mostly smooth and polished. I wouldn't really be able to say what it means to be "considered good UX by webdev standards," but I develop for the web and I like these three.

> they are all pushing the limits of interactive web apps I wonder if you realise that "pushing the limits of interactive web apps" has about as much functionality as Norton Commander/DOS Navigator from the 1990s? It's a damning fact for the web platform that what is "pushing the limits of interactive web apps" is literally nothing more than tables and lists.

I absolutely realize that! And indeed, that’s the whole point: to have web apps with the rich interactivity, responsiveness and performance, accessibility, etc. of good native apps. We’re really not there yet, but we’re making progress.

Re: How I made Google’s data grid scroll faster with a line of CSS

#222

Post by vaughan » Tue, Nov 02, 2021, 12:52 PM UTC

robbiejs wrote: post #204

Gigachad wrote: post #137

Earlier quoted context omitted.

Tables like you mention, have infinite complexity and requirements. If all you need is the most basic grid, the built in element is fine. But what happens when you need inline editing, filters, searches, live updating data from a server, keyboard shortcuts, etc. A single standard element will never handle everyone's use cases. The parent comment is seeing new wheels being designed for a high speed train and wondering…

Exactly, many different JS table/data grid/spreadsheet products out there, but there's not a single one that can "do it all". There's different categories, broadly: 1. A read-only table for presentation purposes, with pagination and sorting options. (DataTables) 2. A read-only data grid that supports high-frequency updates/redraws, for things like Stock or Bitcoin trading. (Ag-grid?) 3. A data grid to edit JSON/Javas…

I have never used a data grid control that didn't end up with me having to dig deep into the code to add something custom that I needed, and just hit brick wall after brick wall. Especially React-based ones.

We don't need big libraries, we need to mix smaller libraries together that each do one thing well.

Like starting with a tutorial of how to build a data grid from scratch with suggestions of utilities to add along the way. Most people would avoid this because they see a library that does most of what they want and get a FOMO...but if they could only see the hours they will lose trying to customize it, they would have preferred to start from scratch. This has been such a constant experience for me with almost every framework/library in tech.

Re: How I made Google’s data grid scroll faster with a line of CSS

#223

Post by vaughan » Tue, Nov 02, 2021, 12:54 PM UTC

Gigachad wrote: post #137

vaughan wrote: post #59

Earlier quoted context omitted.

There is not one set of static requirements for lists. New UX paradigms are being invented all the time, which actually make things more usable. E.g. Think about Airtable vs Google Sheets. Also consider data sources and data binding. Do you bind a cell, a row, the entire table? How do you handle real-time updates or infinite scrolling. How is styling done? It always feels like we should just standardize the current t…

Tables like you mention, have infinite complexity and requirements. If all you need is the most basic grid, the built in element is fine. But what happens when you need inline editing, filters, searches, live updating data from a server, keyboard shortcuts, etc. A single standard element will never handle everyone's use cases. The parent comment is seeing new wheels being designed for a high speed train and wondering…

> But what happens when you need

My experience is that a lot of these features are more easily implemented than the time taken to handle the edge cases of using existing libraries, getting them to work with your UI framework (React/Angular), and getting them to work with your data service layer.