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

191–200 of 223 posts

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

#191

Post by capableweb »

reilly3000 wrote: post #133
anonygler wrote: post #123

That jscontroller= stuff in the DOM is Google’s internal framework called Wiz. Easily one of the worst things I’ve used in my career. It’s like a hyper engineered Backbone.js. Working with it is so tedious that passionate web developers who might fix these perf issues burn out and leave. What’s left are promo-seeking impact farmers who don’t really care about these sorts of things.

Meanwhile daily users of Google web apps on Chrome are prone to slowdowns and crashes all. the. time. When I worked at an ad network and lived in DFP/Ad Manager I had to reboot my Mac twice a day to keep the site even usable. Impact indeed…

The Google-Web is even worse on Firefox. My i7-7700K + RTX 2080ti can barely handle rendering some (small/medium) spreadsheets in Google Sheets anymore. It used to work fine, but seems every month the performance of Google properties on Firefox are getting worse and worse. Even YouTube seems to have a artificial delay in starting the videos if you're using Firefox.

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

#192

Post by lucideer »

dmitriid wrote: post #188
lucideer wrote: post #169

Earlier quoted context omitted.

This isn't in the slightest bit true. Many UI frameworks provide performant list elements, they are not performant in all cases. Recreating the functionality of those list elements on the web is not the hard problem here: optimising them for your specific application is.

> This isn't in the slightest but true. It is. I personally used a virtual list with custom rendering in Delphi in early 2000s. It is, for all intents and purposes, a solved problem. That is, solved everywhere else. > Many UI frameworks provide performant list elements, they are not performant in all cases Yes. On the web. > Recreating the functionality of those list elements on the web is not the hard problem here I…

> It is. I personally used a virtual list

I've used virtual lists (outside the web). They often work well. They sometimes don't. I'm not refuting that they exist, I'm just refuting absolutist statements about their generalised perfection.

>> they are not performant in all cases

> Yes. On the web.

They are often very performant on the web (creating your own virtual list implementation is straightforward). They are often not performant in non-web environments. There is no major fundamental difference between web and non-web in this regard: it's just rendering content to a screen.

> asking for element sizes causes the browser to recalculate the layout

This isn't really the case as stated.

It's true if the layout has changed since last size read, as layout changes will trigger a layout flush, requiring recalc (which are done lazily). For Chrome, this is unfortunately a global flush, but for e.g. Firefox it's on a "frame" basis (an internal frame object, not HTML element). Recalc of dims, either eager or lazy, will be necessary for any drawing system (you're just looking at whether the request for a component size is an internal implementation detail or an application API).

> you can't batch-render anything

Not sure what this means? Why can't you batch-render on the web?

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

#193

Post by bryanrasmussen »

chrismorgan wrote: post #92
wildrhythms wrote: post #63

Earlier quoted context omitted.

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…

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

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

#194

Post by el_oni »

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…

This might be a dumb question but, isn't this something that could be implimented using CSS grid? Not being able to use semantic elements does suck though

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

#195

Post by dmitriid »

lucideer wrote: post #192
dmitriid wrote: post #188

Earlier quoted context omitted.

> This isn't in the slightest but true. It is. I personally used a virtual list with custom rendering in Delphi in early 2000s. It is, for all intents and purposes, a solved problem. That is, solved everywhere else. > Many UI frameworks provide performant list elements, they are not performant in all cases Yes. On the web. > Recreating the functionality of those list elements on the web is not the hard problem here I…

> It is. I personally used a virtual list I've used virtual lists (outside the web). They often work well. They sometimes don't. I'm not refuting that they exist, I'm just refuting absolutist statements about their generalised perfection. >> they are not performant in all cases > Yes. On the web. They are often very performant on the web (creating your own virtual list implementation is straightforward). They are oft…

> It's true if the layout has changed since last size read

For elements that don't yet exist in screen and want to be "custom-rendered" this will be a change in size.

And while there's no element, you can't pre-calculate its size because there are no useful browser APIs for that. And you can't effectively control layout behaviour in the browser when you dump an element into it. And...

> > you can't batch-render anything

> Not sure what this means? Why can't you batch-render on the web?

There is no good way of telling a browser "pause rendering on this particular set of elements" and then "render these particular elements in one go". Any change you do to an element is immediately passed to the renderer.

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

#196

Post by dmitriid »

madeofpalk wrote: post #189
johangavle wrote: post #149

Earlier quoted context omitted.

I have wondered about this countless times... a game can render hundreds of thousands of polygons per frame but DOM cant handle more than a few thousands of elements without lagging. JavaScript has come a long way, wish the rest of it would catch up. If we as devs can virtualize it, surely browser vendors could too

There's a difference between the two, right? The browser is not just "rendering polygons" - it's actually laying them out. Position of one affects another. Have thousands of physics entities in a game interacting with each other and see how it goes. That's why we see things like "millions of falling ducks" as an impressive demo or benchmark for 3D programs/engines.

See, when you're talking about rendering, you're saying millions. And even then you're talking about millions of elements in a physical simulation, all interacting with each other etc.

The browser struggles to display even a few hundred elements. You can't even animate something efficiently if that touches even the smallest part of a layout.

So yes. There's a difference between the two. The browser at the core is a system for rendering a page of text and a few images. It's unbelievably inefficient for almost literally everything else.

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

#198

Post by robbiejs »

simion314 wrote: post #145
wildrhythms wrote: post #63

Earlier quoted context omitted.

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…

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

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

#199

Post by robbiejs »

Gigachad wrote: post #163
johangavle wrote: post #161

Earlier quoted context omitted.

Just guessing here but perhaps they are adhering to some spec about how DOM should work and behave that is as old as the web itself :) HTML standards, JS standards, CSS standards all move forward, perhaps we need a DOM 2.0. Or a new browser that rethinks how it handles DOM to shake things up

Google docs decided to just turn the page in to a big and render everything manually.

That works because Google Docs is a full-screen app. You can't really use Canvas-rendered tables inside a regular web page: it doesn't scale, for one.

I have made a super fast spreadsheet-like component called DataGridXL, based on DOM, not canvas. A performant One Million Cells demo can be found here: https://www.datagridxl.com/demos/one-million-cells

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

#200

Post by robbiejs »

johangavle wrote: post #149
dmitriid wrote: post #139

Earlier quoted context omitted.

> The parent comment is seeing new wheels being designed for a high speed train and wondering why they are reinventing the wheel when wheels have existed forever. Nope. The parent is seeing reinvention of basic UI capabilities such as a basic table and virtualized scrolling and wondering why they are not available natively

I have wondered about this countless times... a game can render hundreds of thousands of polygons per frame but DOM cant handle more than a few thousands of elements without lagging. JavaScript has come a long way, wish the rest of it would catch up. If we as devs can virtualize it, surely browser vendors could too

You can change thousands of DOM nodes in an eye-blink, but not while scrolling. It's too much for the DOM to repaint/redraw itself and keep 60fps scrolling.

I have managed to create the fastest Javascript Data Grid out there by not working with indivual or nodes for cells, but by using a neat CSS style: this only needs one dom node per COLUMN, not per cell.

The downside is that the product does not support multi-line rows.

Here's a performant demo of One Million Cells: https://www.datagridxl.com/demos/one-million-cells.

Post reply on HN