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, there's always a new and different way to do a thing, with either new, or pretty much the same ways for things to be broken.
Grumble grumble
Select elements are the bane of my existence. Impossible to style. I am constantly re-implementing a <select> because it has to look a certain way. Just terrible.
> The purpose of Open UI to the web platform is to allow web developers to style and extend built-in web UI controls, such as <select> dropdowns, checkboxes, radio buttons, and date/color pickers.
> To do that, we'll need to fully specify the component parts, states, and behaviors of the built-in controls, as well as necessary accessibility requirements, and provide test suites to ensure compatibility. We'll also implement polyfills for our extensible web UI controls.
I would say: if it’s just about the style of the <select>, stubbornly refuse to reimplement it, just do what you can on it with CSS and try no further. If you’re needing different functional behaviour (e.g. adding right-aligned text on each option, or making it intelligently filterable by typing—e.g. an airport picker making “CHC” match “Christchurch”), then yeah, you’ve got to reimplement <select> even though it’ll necessarily be a smidgeon worse in some ways.
<select> makes a very bad primitive.
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?
What you described is very easy in eg Qt. You have a bunch of classes representing the table and the contained data, a rendering class etc. that you can extend and override methods easily. Relatively easy, maximum control.
OTOH some years ago (still Qt4 times iirc) I was supposed to add a messaging function to an app that should look like mobile messaging, with those speech bubbles. It was a freaking nightmare to get this past a proof of concept that wouldn't have weird glitches and performance issues if you tried to break it. After two weeks of iterations we just embedded a QWebView and got it working better than ever before within two days, although we felt pretty stupid and defeated for basically pulling in a browser just for that.
Imagine a CSV editor implemented in web with the "native" components, you will have to paginate the CSV file after each 20 rows.
In good toolkits you just drop the native widget and customize it, and if some idiot will say that native is not customizable then let me tell you that you have no idea what you are talking about, you could customize as much as you want, even paint the pixels one by one if needed and still get performance when you have a table with 1 million of customized widgets.
- drag start: opacity: .5 the dragged row - drag move: if hovering over a row, apply border-bottom or border-top depending on which half the cursor is closer to - drag end: move the row to the hovered row, opacity: 1
EDIT: or maybe it was outline instead of border, or even a hard inset box-shadow... Whichever one of those ended up wasting the least time re-calculating layout in testing
I think this is generally a symptom of current leadership practices, where the people making decisions about technical direction are not people who understand how their product functions. This generally isn't top leadership, but the upper and mid level management, who feel they need to "make their mark" on the product to get promoted.
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 thing because we cannot see what will come next.
That said, there still does not feel like a good data grid for React, and trying to build one makes it feel like React is just getting in the way.
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 why they are reinventing the wheel when wheels have existed forever.
React Table is very good, in that it manages the table layout and rendering but allows you to fully customize the look of it.
Maybe this one implementation should not be implemented natively? (otherwise you would need a new implementation for every platform)
However, I agree with you, that in the web development we are missing a mature component library. Everybody seems to build his own library when he needs one. In addition, the libraries to connect components to applications (react, vue, etc.) have their own component formats and logic, so that building components that can be used with different libraries is difficult. Furthermore, building a good component library is in itself a pretty daunting task.
A lot of desktop GUI toolkits were funded by the people who created the platform themselves so they had every incentive to make it both flexible and consistent.
When I look for a web component, the few component libraries that cover several different components are often extremely incomplete. Often they’re just side projects of a company or even an individual. No one is putting in the money to create something fleshed out.
On the other hand, when I look for just a specific component (like a drop down or autocomplete textbox), there are sometimes very complete but because they are a single component, it has its own usage and styling conventions that are going to be completely different from some other component in my app.
No one has the funding incentive of building a complete component toolkit for the web.
Google could do a deal with Qt or Apache/Adobe Flex and use their APIs or even copy paste their code, this projects have years of experience and bug fixing, their components are advanced and super easy to use. Using Flex4 is at least 1000x faster then web native.
I can't even imagine how that would work without turning into something like <select> that can only be minimally styled and has to be (usually poorly) re-implemented to get it to look the way you want it to.
scrolling lists are, once one gets to thinking about them in depth, a lot more tricky to implement than they are to use. In fact I can't actually think of a better example of something that seems at first glance simple, but upon closer inspection is riddled with challenges.
It basically comes down to the simple question of: how do I render as little as possible at a time, but also render everything/anything in the list "immediately" or as fast as possible. These are fundamentally oppositional requirements, and no solution, whether arrived at after 20 or 50 years, will ever not be a compromise of some sort between them.
An example from Flex4 is the DataGrid and AdvancedDataGrid. You get a basic component for simple use cases and a very advanced one if you need stuff like resizable columns, re-ordering columns, sort-able columns.
IMO you don't have experienced with this powerfull tookits, your imagination is lacking and you think that shit that existed for so many years is impossible to do. Nah, it can be done but Google and Mozilla are focusing on JS and failling to implement even the most basic customization stuff for native components , they are probably not even aware that things can be done better because their heads are to deep into the web ass and not seen any good Desktop or mobile toolkit in their lives.
Isn’t that the constraint of basically any rendering system?
The html page itself — I want to only render what’s on screen, but still scroll down quickly
video games — I want to render only what’s in sight, but still turn quickly and render appropriately
Windows — I want to render the visible parts of opened apps, but still switch apps quickly
Etc
This isn’t fundamentally oppositional — it’s the most basic rendering optimization you’d apply (basically view culling), before getting into anything fancy
That have been solved literally everywhere except the web.
We've been solving the same problems over and over again ever since someone had the bright idea of putting a display on a computer.
Let it be Winforms or WPF.
Very smart ppl very easly fall for “not invented here” way of thinking and pretty much solve the problems that were solved already like hundred times.
It’s hard to fight that, seems to be our nature. But this is something that probably diffrentiates “great” devs from “just” devs.
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?
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 native inputs with custom inputs that better match our branding guidelines.
I'd love to make sure these new custom inputs we cranked out last sprint work well for screenreaders and mobile devices, but we had another marketing lead join the company and now the branding guidelines are changing again.
I'd love to just focus on some HTML and CSS, maybe improve some of the touch support for mobile users, but now the release engineering team wants to have a meeting about micro-frontends?
I'd love to get past the existential crisis I had during that micro-frontends meeting and start working on the UI again, but first I have to debug all these failing Docker containers that's required to run our backend.
Really not sure where I'm going with this comment I'm going to stop now.
Having said that, it just looks like you're arguing about something you don't know much about, while at the same time trying to put down people who have been doing this for a while.
However, regarding your question: For one thing, many pages are being build for mobile devices first nowadays. So you would not simply push 40k rows but use some kind lazy loading which is a lot harder to build and can easily degrade the desktop experience.
Furthermore, people often use libraries to get rid off the browser differences and if you use too many of them, use them inappropriately or just a few that are not optimized for performance you can easily ruin the performance. In addition, the whole npm ecosystem makes it very easy to load and combine libraries. Often you need only a few functions but if your tree-shaking doesn't work correctly you end up with a lot of code that has to be loaded even if it will never be used.
So frontend development is a messy place and it is easy to fuck up the performance. Even though that should be no excuse for any frontend dev to write crappy code...
However, it's not like the UI guys in the article didn't do that and implemented some crazy shit poorly. They just slapped a table on the page, incidentally with 38k elements - sounds a lot like what you did actually, and it lagged the page due to browser painting/layout issues.
Now, finally: how exactly is what you did not just the same as this, except they were actually making a usable front-end so the addition of CSS broke the browser rendering engine? Because it sure doesn't sound like you would know what to do in the situation the article discusses...
One perf issue I ran into on an older application I'm maintaining was that on render, a callback would iterate over ALL cells to add a drag handle to them, so that a user could change the column width anywhere. That quickly ran a few hundreds of thousands of times.
Abstraction is great, our modern world wouldn't exist without them, but it's a website.
Let's put our tinfoil hats on, and use this to discover that managers promote inefficient development to force higher management to put more funding into projects. It's clear now, the bloated hobby websites are just from that idea spreading.
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.
I mean, yes. Sometimes, to some degree, you can get away with something like that, but most of the time real clients have complex requirements.
EDIT: Removed most of the substance of my comment. If my astoundingly fragile downvoters can't be arsed to discuss anything of substance, I don't find bringing said substance to the table worth it. Yay community.
In this case it's just a performance hint, so Safari users would have the same experience they do now. Everyone else would benefit.
Seems to me like it's excellent for daily use despite the lack of compatibility of outdated browsers.
For example, the `paint` rule implies that child elements have their renderable pixels completely within the containing parent. If the containing parent is moved off screen, computation of whether any of its children need to be painted is skipped. That will cause the child to vanish if it extends outside the parent.
The thing the contain property does is ensure that a particular Dom change won't affect pixels outside the element involved, which means the browser won't need to do any extra repainting.
I don't think this is recommended to use internally at Google because it's not supported on Safari.
I'd pay that in a heartbeat if it had the API and UI that fits in with the rest of my software. Better an upfront price in dollars for a component that I know will be well-supported by a company than a "free" component that will likely be abandoned or mismanaged by one bored developer
I mean.. you're just at risk of the company going under, or getting bored and randomly deprecating something because they don't care about it.
Your risk level wouldn't really change all that much.
Layout change happens even as you as much as glance at a web page. See e.g. https://csstriggers.com Also things like getting the size or offset of an element would cause a layout recalculation (I don't know if it's still the case).
Firefox does not do this, and has smooth scrolling as a result with little CPU load.
Sometimes some optimizations just don't work out.
If you have something that "unmounts" things as they scroll off the screen ("virtualized rendering" as the article calls it, a common feature for data grids), this is great tool for verifying that behavior.
https://developer.mozilla.org/en-US/docs/Web/CSS/content-vis...
Whereas "contain" prevents recalculations, "content-visibility" doesn't render applicable elements at all until needed.
The contain CSS property allows an author to indicate that an element and its contents are, as much as possible, independent of the rest of the document tree. This allows the browser to recalculate layout, style, paint, size, or any combination of them for a limited area of the DOM and not the entire page, leading to obvious performance benefits.
I wonder how much of this is browser specific because isn't this is all about implementation?
(Disclaimer: I am the maker of the product)
https://news.ycombinator.com/item?id=29024792
https://news.ycombinator.com/item?id=29024825
https://news.ycombinator.com/item?id=29024709
https://news.ycombinator.com/item?id=29024850
https://news.ycombinator.com/item?id=29024739
I hope that other data grid libraries can mimic some of this to improve web accessibility. These components can be really tedious to interact with today
more than 20 years ago we worked on a browser and had tests with tens of thousands table rows. That was fun. The 40K elements today should be absolutely no issue ... until of course :
> the entire page is laid out when you scroll the grid.
and that is the root issue here. For the smooth scroll it should be scrolling over already laid out page (or at least laid out well ahead part of the page).
Google Search Console is just unusable for browsing large data sets due to this issue.
