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, 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.
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 <table> 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 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.
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.
It’s definitely active, just today I was listening to Dave Rupert talking about a versatile element for tabs widgets (and other things) that’s really making good progress.
Isn't that just the charter which lists their goals? Should their organizational goals change massively in a single year? The charter of most NGOs basically stays static for their entire lifetime.
I think they're referring to the date, April 1 is "April Fool's Day" in many countries. Some companies put out joke press releases on April 1 that are not intended to be taken seriously.
Oh wow. Thanks for pointing this out. I had no idea this was happening. I've wanted it for forever, but I thought browser vendors had always shut down talk with "just don't style native controls" dogma. Good to see it changing to reflect the reality that everyone does it anyway.
In an fortunate twist for the unfortunate circumstances, the fact that there's fewer browser rendering engines today means that it's easier to get "all" browsers at the table and agree with a singular direction for things like these: there's simply fewer of them.
For what it’s worth, I’ve had pretty good luck styling checkboxes and radio buttons (e.g. with appearance: none), however I’ve had pretty though luck styling selects. My best shots at custom selects have involved multiple backgrounds, css masks with linear gradients, etc. As for the options list, I’ve never even tried.
HTML and CSS is one standard, two if you squint. The problem is a hundred nonstandard ways to do it, and this is going to be the first standardization of this for the web. I don't think that comic is relevant.
And when you reimplement <select>, 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 simply unimplementable.
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.
Not only that, but reimplementations tend to have bugs. I cannot remember a single time I used YouTube's comment text field without some bug in the last 5 years. It always breaks in some way, usually when line breaks get involved. Right now when I press Return twice the cursor will only move down one line. It's been like that for at least 6 months. Now and then they replace the bug with a different one, but it never really works correctly.
>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.
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 <select> 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.
> 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?
The weird thing is that some things are hilariously complicated in web, but simple in native, and vice versa.
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.
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.
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 <table> 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)
Just be careful of the accessibility doing this. You need to apply the correct role attributes at every level so it is understood by assistive technology to be a table.
Screen readers give special treatment to tables to help users understand what is being presented. They also offer special commands to help navigating in a row or columnar fashion.
You lose this all of this if you use non semantic elements. I believe semantics can even be lost if you change the css display property of an actual <table> element. Make sure to test whatever you do!
Virtualized scrolling for performance reasons also adds another layer of complexity regarding accessibility. Since not all rows of the table/DataGrid are available in DOM
You might need table-layout:fixed and could also help to set a column width using colgroup col elements. I think that's what I'm doing on my little table component in this page:https://i5ik.github.io/_____/7guis/
I know it's not great for performance, but to get a sticky header and flexible column widths you can render two tables and contain one of them to show only the header which you can then wrap into a <div>, position absolutely to cover the top of the table and give position: sticky.
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 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.
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 ?
Yeah, I've been in the same situation. I do think drag&drop has a place in tables, but definitely not like some (including our) designers want it to work. Luckily my boss was at least somewhat understanding and (after some convincing) let me implement drag&drop using an "insert line" (idk what to call it) instead of moving the element around for real.
- 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
> 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
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.
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
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 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.
Tables like you mention, have infinite complexity and requirements. If all you need is the most basic grid, the built in <table> 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 why they are reinventing the wheel when wheels have existed forever.
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?)
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.
> 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’re hinting at something interesting there. As someone who‘s in web professionally but has been programming games as a hobby, I have only naive insight into the latter.
But from that superficial understanding I assume it has to do with control:
In a game you control the rendering/layout logic more specifically. Not every element has to follow all the rules, they need to follow certain rules, scoped to their use case.
With CSS we only have high level control _and_ a predefined data structure that may or may not make sense for specific cases (DOM tree), so each rendering node has to respect _all_ the features, plus _all_ these dependencies are propagated across the whole tree, whether it makes sense or not for a given use case.
If we had more generic, less abstract control, we would not have the same problems. Maybe there is merit in exposing more control to web developers.
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
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
Yeah they sure have the resources available to pull such things off. But for the rest of us I dont think it is a way forward at the moment. You really start from scratch and how do you fix accessibility and such. Must have required huge effort on their part
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.
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 <td> or <div> 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.
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.
> There should just be one way to do a scrolling list, implemented natively and left alone.
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.
I think that's part of it. I also think that, as far as interactive components, virtually nothing on the web has had a shelf life of longer than 3-5 years. Ever.
The lone exception are the base HTML components. I think the last actual change to those was making textarea resizable, and that's kind of a browser override to the spec as much as anything else. Essentially nothing has actually changed in form and UI elements.
That tells me:
1. The web is too obsessed with novelty to ever settle on one thing on their own.
2. The best group to actually establish such a thing is likely W3C, which means it will take 15 years and we'll have thrown two away as poorly considered before it's said and done. And it won't matter unless the changes would eliminate something as obnoxious as Flash.
That is still entirely possible. The web works very well, but it's still a combination of HTML, CSS and Javascript. The one word I can think of that describes the state of the overall design is "asinine".
I went to check this out, seems they're only focusing on React and beyond that, a maintainer mentions they're looking for funding. Doesn't sound too promising...
A lot of this has morphed into the unfortunately named FAST framework, which focuses on web components rather than react. However, they have both Microsoft fluent and unstyled flavors, in case you just want to style things yourself and not look microsofty
this is simply because a single implemention doesn't and won't meet all needs. many times you need a simple component that just renders properly, but some people need a11n, others need a bunch of i18n which opens up another can of worms. and did I mention all of these need to integrate with whatever cluster fuck of a system they wrote? and different UX designs / coding designs.
>building a good component library is in itself a pretty daunting task.
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.
> There should just be one way to do a scrolling list, implemented natively and left alone.
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.
Maybe webdevelopers should stop trying to make everything look different from its defaults. It used to be that you could reliably predict what clicking the mouse in a region of the screen would do. It wasn't progress, when webdevelopers threw that out...
It's not always only about custom theming. There is a ton of functionality that is simply lacking in web standards. If you want default behavior, feel free to use an unstyled or minimally styled <table> element. But it's not going to have any live searching or filtering, the ability to handle enormous numbers of rows and columns (as can be done with virtualization in JavaScript), draggable rows and columns, resizable columns, etc. Sure, it's fair to say "too bad, I don't care about those features anyway" or "too bad, no one gets to use those features on the web until web standards and browsers decide to implement them," but I don't think that's a useful attitude.
Define "those things," and then tell me what "those things" would be defined at before, say, live search came along. Because however you would have defined search boxes would not have allowed for the development of live search.
Iteration is what brings us progress that we enjoy, while also bringing with it the headache of reinventing the wheel over and over again. Both go hand in hand.
This seems to be a constant meme repeated in every single thread which dares to mention modern web development.
I don't know if it's because the HN community is dominated by backend developers who think UIs are pointless and should be generated by code, but it's really annoying.
No, we shouldn't be stuck in a rigid framework of shitty premade components with zero customizability.
Modern web interfaces can be designed to be user friendly, performant, and good looking.
Try marketing a web app which looks like a Java applet from 2003 and let's see how many users you get. As much as so many developers hate to admit it, things looking modern, polished and well designed is important.
> Modern web interfaces can be designed to be user friendly, performant, and good looking.
Right. Name three examples that are all this, and still considered "good UX" by webdev standards.
> Try marketing a web app
Herein lies the real issue. And it predates the web. I recall a piece of documentation of Windows around 3.11 era, where the developers already threw their hands up in the air over realizing that, no matter how good, powerful, integrated and interoperable components they design, they can't insist on people using them, because marketers gonna market and suits will want their apps to be unique and branded and shite.
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.
They look so awesome... wait... neither of them has a working demo at the top of the front page. There is no need to try to talk me into loving something - it wont work. Just show me as many working demos as it takes and show me code. Clearly I'm not the audience. Happy it works for you tho :)
I’m not trying to trick you into liking something and I wasn’t intending to provide demos. They require creating an account because they are serious productivity tools, not cute demos.
Maybe browser vendors should provide defaults that don't suck. The whole existence of Twitter Bootstrap is testament to the fact that browser makers were asleep at the wheel.
Platforms exist to support applications, not the other way around. Applications weren't born wanting to reimplement the native controls, they did it because the native controls are not only uglier but also less usable and hopelessly inconsistent between different platforms.
I understand what you're getting at, but that ship has long since sailed. It's also important to note that changing the look of elements doesn't necessarily mean making their functionality indecipherable. Bad design will always be possible, restrictions to try and stop it are pointless.
For the record...the issues you mention were initiated by former print designers, turned wannabe web designers.
No one should underestimate the percentage of "web designers" who don't know the difference between a span and a div, or the damage that level of ignorance is doing.
FFS, I still see PSDs (which is a silly format for web design) - already approved by clients - with small (read: difficult to read) font sizes, in a color that's low contrast with the background color (read: even more difficult to read).
Don't blame the developers some of this do push back. Unfortunately, "the creatives" too often have more juice.
> Don't blame the developers some of this do push back. Unfortunately, "the creatives" too often have more juice.
It's so bizarre how developers are simultaneously considered 1. powerful in the job market, highly in-demand, with companies competing for talent, and 2. totally powerless to push back against dark patterns, privacy invasions, and poor product or design choices.
I mean has anyone even tried saying "You know what, I'm not going to implement that. I'm a professional, too, and in my judgment it's [ridiculous | unethical | poorly thought out | whatever]. We need to negotiate it down to something better."
Not going after you in particular, but I see this "developer power" dichotomy all the time on HN and it's kind of hard to understand.
There is an implicit assumption here that developers have a better understanding of these issues than the rest of the people involved. My experience is that many developers are clueless about UX in general.
Source: I'm a developer, and I work with other developers. On my team I'm the only person who has studied UX design, which resulted in me getting considerable praise for the quality and useability of my user interfaces. At the same time, I have seen my colleagues design interfaces by literally adding controls to a window in the order they implemented the features, starting in the top-left, and moving slowly down the page in a row by row fashion. Well, that's also a strategy...
The real problem is that most designers just like drawing pretty pictures, and are clueless about UX as well. Pushing that to developers is one option, but it's really a separate skillset.
I don't specifically want to include origin in this discussion, but I have never experienced this myself. And I think it might have to do with my (Dutch) culture, or that I am freelance and my clients trust me to do the right thing.
When one of my clients think of something which doesn't work for whatever reason they want me to say no to them. And it doesn't hurt our professional relationship, I will explain them why it is a dumb idea (not in those words of course :-)) and we figure something out that does work properly. They appreciate me being direct and selling them no and they request it themselves.
So while I can understand your comment and I think that it is fair in plenty of situations, it isn't always.
1 and 2 are one in the same. The revolving door feeds itself.
It's not like the recruiter and/or hiring company are going to tell you up front "Yeah, the design team is clueless." True story: you only find that out after the fact. Pushing back is possible, and it does happen, trust me ;) But it either happens too late, management is clueless, or both.
So you update your CV in search of green pastures. That in turn creates an opening. Management won't admit it's them. The narrative is: we need better talent and that means paying more.
I feel like such arguments are rarely made in good faith due to mostly elitist attitudes but I'll give it a try.
It's one thing to push against dark patterns, and completely another to constantly fight your design teams. Do you honestly think the developer is making all these design decisions? Lol
entertainment media will always develop the ability to arbitrarily control every part of the media presentation, and the web has developed into an entertainment medium. This is why load time is so important, people will wait long times for something they need to do, but will not wait to be entertained.
I’m not sure this is different than any other medium.
Examples that come immediately to mind: academic journals, vending machines, car dashboards, magazines, credit cards, TV remotes, washing machines, etc.
You should see what you can do with <summary> and <details> these days, no more do your native browser elements have to look like complete dog to receive free native device controls
I can't believe these elements slipped under my radar for so long - I have a site with no Javascript (outside of Google Analytics anyway) and <summary> and <details> have helped me keep it that way.
There are just a few too many forces at play, the quest for dynamic easy to start rules (css) and immense flexibility while never having to dig into lower layers causes that. Wait another 10 years, and even then..
While I agree with the sentiment of this comment (there are so many aspects of modern web development that are layers of abstracted complexity to re-invent wheels long-since optimised). However...
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.
This was solved, you render the visible items, and a few extra items before and after, then when the user scrolls you never render new items widgets but recycle the existing ones and refresh their state to match. It is super efficient and was solved in many toolkits, I am sure it is done in Flex4.
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.
It has of course been "solved" many times in many toolkits, that wasn't my point.
My point was that each solution is a compromise, and none can ever be one-size-fits-all optimal.
Rendering "a few" items before and after is a heuristic requiring bounds which will produce variable performance impact depending on the content of your list items. It also doesn't account for scroll jumps at all.
Refreshing state is only more efficient than creating/destroying items in some systems and its performance characteristics are again highly dependent on the content of each list item in your application.
This not true, it was solved correctly before and nobody would force you to use an AdvancedDataGrid instead of a table or 100+nested divs.
>Refreshing state is only more efficient than creating/destroying items in some systems and its performance characteristics are again highly dependent on the content of each list item in your application.
YEs it depends but 99% of cases you refresh the string for some Label/Text components and some img src , since you do it with native code it will be much faster then creating new DOM elements or changing a DOM element attribute. Plus hacked-up widgets that are not native are forced to listen to tons of events and run non-native code to detect if they should or not run and what to do when to run.
TLDR the problem was solved, we need good enough widgets like in good toolkits and we can still give people the option to create their own "improved" version with their cool library if they want.
Scrolling lists is the first thing that comes to mind when I see someone proclaiming that PWAs will run the world soon, and everything will be based on web tech.
iPhone SDK has this from the very beginning. With data sources, delegates, reused cells, etc. It's even easier with SwiftUI (with swipe actions and what not). Yet people are willing to break even simple scroll on the web. Why?
> 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.
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
It is exactly, and it's a hard problem to generalise.
My point is that rendering a list widget is more complex than other widgets because it's as complex as general full-page rendering / scene rendering
> This isn't fundamentally oppositional — it's the most basic...
It can be both.
View culling is essentially the complexity I'm talking about. View culling is a heuristic, it produces different impacts depending on many variables within the view, as well as the parameters of your cull.
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.
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
It is a very hard problem on the web because you don't have any APIs to do this properly: asking for element sizes causes the browser to recalculate the layout, you can't batch-render anything, and a million other things that are readily available, once again, literally everywhere else.
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?
> 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.
> 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.
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.
I’ve been “burned” many times by using standard off the shelf solutions to problems. Not because they didn’t work or had security issues but because they didn’t do precisely what a stakeholder expected, down to the pixel. No amount of me saying “nobody will notice if our app works the same as everyone else’s” worked.
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?
TIL: Chrome DevTools Layers tab, accessible by going to to the three-dot menu > More Tools > Layers, which allows you to see things rendered outside of the browser viewing area (among many other things I'm sure).
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.
I really should look into virtualized rendering; turns out I've got some really long lists that are mostly hidden (overflow: hidden I think) that shouldn't be rendered.
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 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.
Assuming you're arguing in good faith, managing complexity of large applications requires "something". What something is takes many different shapes, some of them trade performance for complexity management.
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.
Doesn't sound like you tested it on a mediocre mobile phone, sounds more like a laptop/desktop.
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...
I wonder if pushing 40k rows to mobile is such a bad idea. Phones have tons of space now. HD video streaming pulls tons of data. I guess mediocre mobiles complicate matters.
Usually there are other factors making it implausible. Such as not compressing/compacting the data on the server, and not being able to limit large blob data columns, unable to control the parsing of data, and lack of normalized relational caching on the client.
Usually it’s a collection of backend and frontend frameworks that complicate all this.
I’m feeling more and more we need thick efficient clients.
I'd have thought background tab would be written to it's domain-partitioned bit of the cache before being unloaded. I'm very surprised you lose the current state. To be honest, that sounds like a bug.
I had similar fears when implementing a large table with some data visualization during one of my first forays into web development. I had noticed how slow things with 100 elements were let alone 1000. When I wrote my code that handled much more than that, I was surprised how responsive it was. How does a company with thousands of employees manage to make something that runs more poorly than something I wrote in an afternoon?
I'm not sure what you are asking. You can of course build a trivial use-case with a native feature and have it perform as one would expect from a native HTML element.
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...
Did you read the article and the comment I was replying to? Both basically rendered 40k element HTML <table>s. Difference is, the Google UI lags because it is hampered by browser painting/layout computations taking forever, despite the <table>s in discussion having near-identical complexity, so one can conclude the Google UI bug is more-or-less a bad interaction between the UI's CSS and the browser rendering engine.
So, pray tell, how does parent comment decrying UI developers for supposedly not just rendering HTML tables make any sense in light of this context? It is just sass from someone who likes to rail against UI development, there is no insight
I think this is actually a little subtle: if you don’t have fixed-width columns then changing the visibility (or more strictly the display property) of rows can require column widths to be recalculated which is often pretty slow. It’s easy to say that obviously you should just set fixed widths but it is pretty hard to decide what they should be in practice if you want the page to still work when someone resizes their window.
It's easy to underestimate how fast a plain vanilla HTML table can be. It gets a lot more heavy if you start doing things like sorting, column resizing, filtering, and of course it depends on what you have inside of them.
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.
Presumably, almost all of the rows are tagged with "display:none" then? From the timings I did in the past, rendering tables with thousands of rows and a many columns can take whole seconds.
Table rendering/updates used to be all or nothing, so loading big sets meant waiting for the entire thing. Not sure if that is still the case in all browsers
They just all need to have the latest shiny thing, spurred on by the idea that a huge amount of abstraction is a good thing.
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.
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)
Its not real. What good is virtual table if I cant search for contents of last row, "2000;1", after loading the page :( Still, this gives me an idea. Dump contents of my table as text under virtual one so search will at least scroll down to appropriate offsets.
Version 2 (december) will have a very fast search feature. But you're right: CTRL+F does not work, as it is virtual. I don't really understand your idea, can you elaborate?
did your test consist of other things found on a site such as the one with the Google data grid or did you just slap a table on an empty page? Is the table fixed height? What are the scroll settings?
Hi! Frontend dev here. What we are doing is covering several other industry standard use cases.
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.
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.
Unfortunately, as is often the case when one learns of a new CSS property or a Web API, the browser support is just not there yet. Safari, for example, doesn't support this at all: https://caniuse.com/mdn-css_properties_contain
Writing good browser based software is about delivering the best possible experience for all users regardless of their browser choice. That doesn't mean withholding beneficial features just because they're not available everywhere. It means writing software to take advantage of every possible benefit that improves the user experience, and detecting browser support where necessary to provide fallbacks and polyfills if you need them.
In this case it's just a performance hint, so Safari users would have the same experience they do now. Everyone else would benefit.
This is how you end up with "the performance sucks if you don't use chrome" complaints though. I imagine Google makes use of optimizations only possible in Chrome quite often making their applications provide sub par experiences on other browsers.
This is how you end up with "the performance sucks if you don't use chrome" complaints though.
Not it isn't. You get that by only testing in Chrome, and not putting the work in for other browser users. If you test in other browsers and the performance sucks then you should work to make it as good as possible in those other browsers as well.
Aiming for the same experience everywhere is how you don't use things like the 'contain' hint because it's not available in Safari, and then everyone gets a slower website because of it.
Don't undermine every user's experience just because one browser is lagging behind.
In my opinion, good applications perform predictably across different browsers, which means they rely on highly available features across all browsers... meaning they don't use things specific to a single browser/device....
What you're arguing for here is what Google did - they didn't implement 'contain', so everyone got the equivalent of the Safari browser experience. If Google had done what I'm suggesting here then users who are on Chrome, Firefox, Edge, etc would have a much better experience. Safari users wouldn't see any difference. Why would you make the user experience for many people worse than it could just because they don't use Safari?
Everyone should get the best possible experience for their chosen browser, even if that means users get different experiences.
> "they didn't implement 'contain', so everyone got the equivalent of the Safari browser experience."
Not sure that the Google developers knew that feature existed. Most people in this comment thread were unaware of this feature too, seems reasonable that the Google developers might not have been aware either.
> "Everyone should get the best possible experience for their chosen browser, even if that means users get different experiences."
I like that quote. Good websites do give the best experience a device can handle, rather than cater to what the worst devices are capable of.
I don't think this matter much? It's just a performance optimization, Safari can remain slow while all modern browsers benefit. Unknown CSS values should be ignored so there should be no impact on actual usability.
Seems to me like it's excellent for daily use despite the lack of compatibility of outdated browsers.
It matters because it causes a new stacking context. Z-index only affects elements within the same stacking context, so you then can get weird behaviour that one floating tooltip overlaps something in Firefox/Chrome but doesn't in Safari because Safari doesn't create the stacking context.
Browser support aside, it seems very counterintuitive. https://developer.mozilla.org/en-US/docs/Web/CSS/contain suggests that it can cause pages to render differently, which is very strange, considering that the description implies that it only effects when the browser repaints/re-processes region, and not what the result is.
"When" can definitely affect the end result if the page elements are arranged such that they break the rules implied by the contain logic.
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.
Browsers give no control over when areas are repainted. If you change a bit of CSS or DOM, it will be repainted in the next frame. There is no way to say 'dont paint this yet'.
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'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
With a disclaimer for me being employed at Bryntum (and the main author of the Grid component), I still think the chances of getting long term support are better with a paid component from a specialized vendor. Wether you buy Bryntum Grid or AG Grid, there are agreements and such plus the fact that the products are the livelihood of the devs behind them. For the really large vendors though, I guess some of their widgets are to "plug holes" and the mileage may vary...
The article still doesn't answer how scrolling a page can cause layout change. Layout change occurs when elements are added or removed from DOM or when they change their size. I assume there is some Javascript that updates styles on scroll event.
> Layout change occurs when elements are added or removed from DOM or when they change their size
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).
I'd be willing to bet money that Google has hooked the onScroll event and is computing their own top left offset for the interior panel instead of just letting native scroll logic take care of it.
Dunno. I have a large plain (onscroll is not listened to) table in Chrome, and it does constant re-layouts during scrolling. It looks like Chrome does some optimization where it only paints portion of the table and when you scroll, it will paint the new portion only when you scroll just slow enough (and does re-layout whenever this happens, I guess). Otherwise you see just white space. It causes huge CPU load too.
Firefox does not do this, and has smooth scrolling as a result with little CPU load.
I expected a soft-sell somewhere in this article, and the depth of knowledge had me say “respect. I’ll check out this sell”, but I did not expect $2040/yr for the JS table library!
I seem to recall reading somewhere that 'content-visibility' has a performance penalty, because the browser effectively sticks intersection observers on the elements marked with content-visibility:auto; so that setting content-visibility:auto on, say, thousands of table rows delays page render. But now I can't find where I saw that.
That makes sense. Ideally in that scenario you don't set it at table row level, rather at a higher container level. In this case a container wrapping things far down the page. Your markup structure of course has to support this.
Shameless plug: we had a really hard time finding an accessible data grid that matches the specs, so we built one recently (in React) for our design system. It’s very minimal but completely composable. For example we don’t have virtualized rows or frozen columns but that’s something that can be added on later; we focused on a foundationally accessible data grid to start:
https://paste.twilio.design/components/data-grid
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
That seems like a bizarre reason not to use it, given that it's strictly a performance optimisation, and browsers will simply ignore CSS rules they don't understand.
I imagine that it could cause accusations from Apple that Google is trying to take their customers out of the ecosystem, putting a nice cash flow at risk.
It's a bad argument because if someone else makes a better product then they deserve to get more users. Nothing's stopping Apple from implementing those optimizations into Safari. That's the whole reason we have competition. If the government is going to make it so that improving your product makes you liable to lawsuits then no one would ever improve anything.
It's not the government dictating the lawsuits, I was referencing the deal between Apple and Google to have Google as the default search engine on Safari.
It causes a new stacking context which has significant impact on how everything is rendered and things like Z-index behave. This can cause head-scratching issues and differences which aren't obvious at first sight.
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 already worked properly.
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.
>The full page contains 38,000+ (!) elements, which is not how you build a fast web app! The obvious thing to do here would be to change to using a data grid with virtualized rendering
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).
What makes this even more ironic, is that for a period of time, Chrome was one of the only browsers to support the contain property. I've been using this property for years to speed up my applications, it does have quirks (especially using strict), but reading up on the different modes it can offer huge performance gains for large apps.
Svelte has solved performance, and made writing butter smooth, lightning fast web apps 10x easier with 10x less code. Blows my mind that more companies haven’t adopted it considering devs fall in love with the unmatched DX, and users get highly optimized apps shipped to them at a faster rate thanks to the boost in dev speed.
Congratulations on your cool project. You mentioned it 8 times in this thread alone. While I wouldn't call your comments spam (they do refer to their individual parents, though), stumbling over the same link so many times while reading one thread does leave a certain weird taste.
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