Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

medium.com

Post reply on HN
Print view View original

201–210 of 223 posts

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

#201

Post by robbiejs »

wildrhythms wrote: post #68
danielvaughn wrote: post #65

Earlier quoted context omitted.

Every time I’m given a table mockup, it’s flexible column widths with a sticky header. It’s damn near impossible even with JavaScript.

100% agree. Also consider that tables, uniquely, size to their content. So a cell's width is actually the width of the widest cell in its column; the cell height is the height of the tallest cell in its row. It's a problem with so much hidden complexity, and people who come up with these beautiful table designs genuinely do not understand the hidden challenges of implementing it.

Exactly, non-fixed row heights / column widths are a performance nightmare. I have managed to create a super fast Javascript Data Grid. There are many performance tricks, but the first thing I decided was to give each column a fixed with and each row a fixed height. Here's a One Million Cells demo that shows its performance: https://www.datagridxl.com/demos/one-million-cells.

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

#202

Post by simion314 »

robbiejs wrote: post #198
simion314 wrote: post #145

Earlier quoted context omitted.

That is my exact same experience. In good tookits you have good native components, good Dropdown, GridView,DataView even AdvancedDataView , I could put in a native tookit 1 million items in such a widget and have no more performance hit then 20 items where with web the best practice is to implement pagination. Imagine a CSV editor implemented in web with the "native" components, you will have to paginate the CSV file…

You can have a super fast CSV editor online, in fact I made one: https://www.editcsvonline.com/ . It's based on my product DataGridXL, which, I believe, is the fastest Data Grid out there. Editing cell values with EditCSVOnline is faster than it is in Google Sheets :-)

I did not say it is impossible, but it is not a simpel thing like on a toolkit where you would

1 add a DataGrid widget

2 connect a data provider

3 setup special rendering functions for some columns (only if needed)

4 define sorting functions if needed

And that is all, you get performance, sorting, column resizing, re-ordering for free, you can focus on the business logic and not on creating a DataGrid widget from scratch and fixing bugs for years until you get to 20% of the performance and features of similar desktop native one.

TLDR , web needs widgets like desktop toolkits for people that want to focus on bussiness logic, for the rest they can use more simple things they create themselves or npm install or buy some more cool widgets.

With current web tech we spend to much time on re-creating functionality(not styling), have often you see borken menus or dropdowns on websites? Wouldn't a native dropdown that could be styles or a native menu widget that could be styles would make things much better ?

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

#203

Post by robbiejs »

fiddlerwoaroof wrote: post #97
danielvaughn wrote: post #65

Earlier quoted context omitted.

Every time I’m given a table mockup, it’s flexible column widths with a sticky header. It’s damn near impossible even with JavaScript.

You can do this all in CSS, if you’re willing to restyle all the table elements to use grid. I demoed this at my last job, and it worked pretty well. (This has its own trade offs)

I'm sure grid was faster than table, However, for real performance benefits, forget about and forget about grid: you need absolutely positioned DOM nodes, and CSS transform/translate for animations. You'll end up with a Data Grid that renders faster than Google Sheets: https://www.datagridxl.com/demos/one-million-cells. (Dislaimer: I am the maker)

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

#204

Post by robbiejs »

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…

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/Javascript data, with user-friendly spreadsheet-like controls. (DataGridXL)

4. A spreadsheet-product, with features like formulas, merged cells, HTML (images) in cells, pivot tables, etc. (Handsontable?)

Source: https://www.datagridxl.com/compare.

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

#205

Post by robbiejs »

rasz wrote: post #162
eska wrote: post #10

I’m not a frontend dev so I just stick to vanilla html and js. I created a simple table with 40k rows, slapped an input box above it, and had some vanilla js set CSS visibility on all rows depending on whether they matched. This would update live as I was typing (10ms trigger delay). No optimizations. So what are frontend devs doing that they break all of this so badly? Are they just trying to be too smart, I wonder?

>table with 40k rows Oh I have one with 6K rows, 300ms to insert into a page if I try to measure, but in reality browser freezes for 3 seconds (1.8s style, 900ms layout, 300ms update tree). Freezing goes away with position: absolute, but it still takes 3 seconds to show up after .appendChild. I tried replacing Table with Flex divs, even worse speed.

If your table is simple (values, no markup), try DataGridXL: here's a One Million Cells Demo that loads in an eyeblink: https://www.datagridxl.com/demos/one-million-cells. (Disclaimer: I am the maker)

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

#206

Post by KronisLV »

wildrhythms wrote: post #63
lxe wrote: post #3

I've been doing web development for 20 years now. I don't know if it's strictly endemic to web or frontend, but I feel like we're solving the same problems over and over again, using the same low levels of abstraction. There's no reason for lists to scroll slowly after so many years of scrolling lists. There should just be one way to do a scrolling list, implemented natively and left alone. Yet, in web development, t…

I work in UX, I am constantly being given designs that don't work well with native/semantic elements- a great example is tables. As soon as the table needs some kind of animation, drag-drop behavior, anything like that, I can't use a anymore; or it becomes some frankenstein kafkaesque amalgamation that is impossible to maintain. Does the table really need an animation? (probably not) drag and drop? (probably not) But…

> But management and the people in charge of OK'ing these designs have a 'make-it-happen' attitude and nobody really cares about semantic, native feel when they've invested so much into a "design system" that is largely antithetical to that.

It feels like at some point you'll just have to start telling them that their ideas will result in technically bad solutions and be ready to look for a new job.

Clearly that's not a good idea for everyone, but if unions could form and fight back against unfair treatment of workers, why don't developers have similar organizations to fight against privacy breaches, unethical development or business practices, or even just unreasonable design demands that are not standards compliant or accessible?

To expand upon that: if doctors refuse to harm people, why do developers harm websites and other pieces of software so readily just because they're told to?

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

#207

Post by kevingadd »

pcwalton wrote: post #87
kevingadd wrote: post #7

Earlier quoted context omitted.

Even if they can't use contain, this is a self-inflicted problem - if you look at the screenshot, other elements + a drop shadow overlap the content list, which means it can't trivially be efficiently scrolled by a compositor, and it's quite reasonable for the browser to assume that it can affect layout. If it were a properly isolated box in the page without overlap with overflow turned on I bet this would have alrea…

I don't think this is a reasonable assumption for the browser at all. It's 2021; WebRender has proved that a better design is possible.

Sure, but are Chrome and Safari going to do a WebRender-style renderer anytime soon? WebRender is great but in practice it affects at most (generously) 20% of the web audience. Optimize for the browser you have, or maybe the browser coming next year, not the one your customers will have in 5 years.

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

#208

Post by mankz »

jackdh wrote: post #190
mankz wrote: post #150

Earlier quoted context omitted.

Not per year! The EUL license is USD 680/developer and is *perpetual* + support & upgrades are optional.

Also missing a few power features such as advanced pivoting and row grouping which is a shame.

Grouping of headers + rows supported. https://bryntum.com/examples/grid/grouping/

Pivot on the way, ETA Q1/Q2 2022

Would love to hear any additional features you feel should be present in a full fledged grid package.

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

#209

Post by chrismorgan »

bryanrasmussen wrote: post #193
chrismorgan wrote: post #92

Earlier quoted context omitted.

And when you reimplement , it won’t feel native because different platforms have different conventions (e.g. placement of dropdown, click-and-drag behaviour, whether focus is selection, keyboard shortcuts like Tab), and very few implementations try even half-baked user-agent sniffing to try to emulate the platform. And that’s just thinking about desktop platforms; on mobile platforms, the native dropdown behaviour is…

>and very few implementations try even half-baked user-agent sniffing to try to emulate the platform well, to be fair every tutorial on JS for the last 16+ years or so has said avoid user-agent sniffing but only detect capabilities, not to mention freezing of user agent string will make this point moot. Problem of course being that you cannot detect how the specific browser makes a select work with capability detecti…

Freezing the user-agent string won’t prevent sniffing, it’ll just possibly make sniffing of precise version numbers a bit more difficult (… because you’ll be abusing feature detection to achieve it); but for this sort of thing you’re mostly just caring about the platform at a coarse level, and maybe the browser (though I think Edge lost its distinctive style and behaviour in the Chromium migration, so that now all browsers on Windows work roughly the same). So UA freezing won’t cause any trouble at all for this sort of thing.

For various sorts of keyboard shortcuts, this style of platform detection has long been essential, so that you can use altKey/⌘ on Apple platforms and ctrlKey/Ctrl everywhere else. Ain’t never been no feature detection candidate for that.

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

#210

Post by theandrewbailey »

Scottopherson wrote: post #40
eska wrote: post #10

I’m not a frontend dev so I just stick to vanilla html and js. I created a simple table with 40k rows, slapped an input box above it, and had some vanilla js set CSS visibility on all rows depending on whether they matched. This would update live as I was typing (10ms trigger delay). No optimizations. So what are frontend devs doing that they break all of this so badly? Are they just trying to be too smart, I wonder?

Filtering a list is easy when all the data exists on the client and has no advanced filtering controls. I'd love to slap an input box above a table and call it done but the product owners and designers that fill my backlog have other ideas. I'd love to make sure this CSS visibility filtering worked well for screenreaders and other accessibility tools but that ticket was pushed down the backlog in favor of replacing n…

You're shaving yaks all the way down.
Post reply on HN