[lxe]

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.

Grumble grumble

[wildrhythms]

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.

[dfabulich]

What you need is Open UI. The browser vendors are working on it.

https://open-ui.org/

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

[bla3]

https://open-ui.org/charter

> Most recent revision: April 1, 2020

That doesn't inspire confidence...

[brigandish]

Well, it only took 25 years to get some real control over vertical alignment via grid, maybe selects will not be horrible by… 2029? I live in hope.

[extra88]

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.

[true_religion]

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.

[skolsuper]

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.

[nextaccountic]

https://github.com/openui/open-ui last commit 10 hours ago

[dimal]

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.

[necovek]

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.

[runarberg]

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.

[wdb]

Confusing naming as there already exists https://openui5.org Open-source sibling of SAPUI5

[saagarjha]

> The browser vendors are working on it.

How's progress?

[arthurcolle]

Mandatory standards xkcd

[Dylan16807]

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.

[TOMDM]

For todays lucky 10,000 https://xkcd.com/927/

For todays lucky 10,000 concerning the lucky 10,000 https://xkcd.com/1053/

[chrismorgan]

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.

<select> makes a very bad primitive.

[alpaca128]

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.

[bryanrasmussen]

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

[chrismorgan]

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.

[KronisLV]

> 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?

[iforgotpassword]

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.

[danielvaughn]

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

[wildrhythms]

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.

[robbiejs]

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.

[fiddlerwoaroof]

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)

[danielvaughn]

We used to use tables to style things that should be grids, now we use grids to style what should be tables. Back to square one :)

[robbiejs]

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)

[WickyNilliams]

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!

[johangavle]

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

[graderjs]

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/

[tenaciousDaniel]

That's why I included "flexible column widths" since it's definitely doable if you use a fixed layout table.

[methyl]

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.

[madeofpalk]

For sticky headers you can literally just put `position: sticky` on the thead now!

https://codepen.io/chriscoyier/pen/WNpJewq

[simion314]

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.

[robbiejs]

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

[simion314]

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 ?

[franga2000]

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

[craftinator]

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

[el_oni]

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

[madeofpalk]

Why is drag and drop an unreasonable expectation to have for a table where that makes sense?

[vaughan]

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.

[Gigachad]

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.

[robbiejs]

Exactly, many different JS table/data grid/spreadsheet products out there, but there's not a single one that can "do it all". There's different categories, broadly:

1. A read-only table for presentation purposes, with pagination and sorting options. (DataTables)

2. A read-only data grid that supports high-frequency updates/redraws, for things like Stock or Bitcoin trading. (Ag-grid?)

3. A data grid to edit JSON/Javascript data, with user-friendly spreadsheet-like controls. (DataGridXL)

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

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

[vaughan]

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.

[dmitriid]

> 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

[johangavle]

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

[dgb23]

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.

[johangavle]

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

[madeofpalk]

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.

[dmitriid]

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.

[robbiejs]

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.

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

[vaughan]

> But what happens when you need

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

[chrisco255]

https://react-table.tanstack.com/

React Table is very good, in that it manages the table layout and rendering but allows you to fully customize the look of it.

[arendtio]

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

[thrashh]

I think it’s a funding issue.

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.

[da_chicken]

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

[irrational]

I was going to suggest Google, except... they really don't, do they? They want everyone to use their own tools/sites/etc.

Hmm, maybe Mozilla? But they've been firing all of their staff and cutting way back, so they won't do it.

Microsoft? Save reasoning as Google.

So... yeah, there probably is nobody that has the incentive to do this.

[jitl]

Microsoft is building a web component framework: https://developer.microsoft.com/en-us/fluentui#/get-started/...

[PKop]

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

https://github.com/OfficeDev/office-ui-fabric-core/issues/12...

[oldmanhorton]

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

[gowld]

> A lot of desktop GUI toolkits were funded by the people who created the platform themselves

Not Linux (GTK, QT).

And not Java Swing

[secondaryacct]

How much do you pay ? Because Syncfusion or Sencha have well funded well working stuff.

[jatone]

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.

[simion314]

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

[lxe]

Right? Mozilla's XUL had the right idea a the time. I wonder if similar things exist for the modern age?

[jaywalk]

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

[agent327]

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

[tshaddox]

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.

[nitrogen]

So do all those things once, in the browser, and then every table can have them. That's maximally useful.

[pwinnski]

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.

[tshaddox]

I’m not sure what you mean though. Just don’t allow anyone to develop their own table component after the first one was developed?

[5560675260]

Standards and browsers are already so bloated, that it's virtually impossible to create a new implementation.

[enlyth]

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.

[TeMPOraL]

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

[tshaddox]

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.

[dmitriid]

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

[6510]

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

[lmm]

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.

[jaywalk]

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.

[chiefalchemist]

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.

[ryandrake]

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

[agent327]

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.

[geraldwhen]

That’s a great way to not get raised or promoted. The text will be grey on grey. We will intentionally break accessibility because reasons.

I’m not paid to care. Caring actually causes problems.

[WildGreenLeave]

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.

[chiefalchemist]

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.

And so on.

[beebeepka]

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

[chiefalchemist]

All these BAD design decision ;)

[6510]

developers are powerful in the job market, highly in-demand, with companies competing for talent.

But you get to pick one and then you are married and she makes all the decisions.

[bryanrasmussen]

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.

[r3trohack3r]

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.

[sabellito]

What do you mean "look different from its defaults" in regards to scrolling lists of things?

I'm not sure what you meant with the second and third phrases, do they relate to the first point?

[xboxnolifes]

Unless browser defaults happen to be the optimal expected behavior for the majority of users, sites will always have an edge by changing them.

[nawgz]

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

[jamesfinlayson]

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.

[toastal]

Now remove the Google Analytics too

[nawgz]

You avoid JavaScript, except the worst usage of it? Very bizarre choice...

[LudwigNagasena]

Look at Qt and its styles.

[agumonkey]

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

[lucideer]

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.

[simion314]

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.

[lucideer]

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.

[simion314]

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.

[rimliu]

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?

[setr]

> 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

[lucideer]

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.

[dmitriid]

> These are fundamentally oppositional requirements

That have been solved literally everywhere except the web.

[lucideer]

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.

[dmitriid]

> 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

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.

[lucideer]

> 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?

[dmitriid]

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

[zz865]

If only web front ends worked as well as Visual Basic in 1996.

[starik36]

1991

[madrox]

If you think that’s bad, let me talk to you about backend development and the reinvention of CRUD over the same time period…

[taneq]

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

[sergiotapia]

If you don't invent new ways to render a list how else will you be able to give a talk and get 500 twitter likes?

[lxe]

You're right... I'm undermining my own job security here.

[tester34]

Same things happen on native apps.

Let it be Winforms or WPF.

[pojzon]

Its not only in web development but software development as a whole.

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.

[notreallyserio]

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.