[auggierose]

Good layout is simple. But can it be flexibly done without a good sense for abstraction and math? No. I mean, just look at the hot shit that is Tailwind, that's what people come up with while fighting abstraction.

CSS was a mess, but together with React is now the best language for building GUIs. You can build up any abstraction you want in React, even

    <FullScreen><Center>Hello World!</Center></FullScreen> 

In fact, that's what I did over the weekend for my Electron desktop application, writing my own little library of components, including tabs and treeviews, using only CSS and React and no third-party libraries apart from that.

You already have been proven wrong. You are just not ready to accept the proof.

[troupo]

> CSS was a mess, but together with React is now the best language for building GUIs.

People should stop saying this lie. To di so, they should try and look outside of the web for even a nanosecond.

Even Turbo Pascal from 1990s is a better language for describing UIs.

The "best language for building UIs" chokes on less than 1000 elements on a static page: https://pbs.twimg.com/media/GF__tHjXgAAZGUA?format=jpg&name=...

Compare that to an actual UI: https://cdm.link/app/uploads/2023/11/CleanShot-2023-11-15-at...

[danShumway]

So, a couple of issues:

A) Out of curiosity, is that "actual" UI screenreader accessible and does it work on mobile devices? Does it work with touchscreens? Can I scale the text? Maybe it does, I don't recognize the program off the top of my head. But I don't assume that by default.

And very often this is just the same argument over and over again. "Check out how cool the thing is that I can build when I assume that you'll be using a widescreen desktop monitor with a mouse and keyboard in the full screen." I mean, great, that's very cool, but I'm glad the the web doesn't allow you to make those assumptions. It's a better platform for forcing you to care about more stuff.

B) You can absolutely get more than 1000 elements on a static page, it's not that big a deal unless you're doing something weird. Of course, if you are putting 1000 elements on a page, you might take a step back and ask yourself why you're doing that because giant pages with thousands and thousands of nested elements are hell for screenreaders. You want to update a thousand pieces of the DOM at the same time. Well, OK, let's ask for a second whether that's actually good interface design. I would argue maybe it's not?

I make this point a lot on HN, but if you can't describe your interface using pure text, you don't have an accessible interface, period. And to rephrase point A, you're correct that if you don't worry about that, you can make very complicated interfaces that are extremely performant, and wow am I glad the web forces you to worry about that.

C) People have a fundamental misunderstanding of what the DOM is and how it should be used, in part influenced by treating the DOM as a markup tool rather than as a render target -- but suffice to say, there is nothing about the interface you're showing me that makes me think it's not doable on the web. Some of these visual components you might jump out and use canvas for -- that's not violating the spirit of the web, the DOM is your user interface, and a bunch of nested DOM elements that simulate a slider using div soup is not more accessible or semantic or maintainable than an actual native browser slider with accessible controls that you throw a canvas element in front of.

The thing that would be hard about building this interface on the web is I would have to care about what happens if the font size changes, and I would have to care about what happens if the user opens the app on a phone, and I would need to care about tab controls and turning this interface into an actual hierarchy, and I would have to think about touch screens, and I would need to have higher standards for my interface design than just "how many elements can I fit on a screen at the same time?".

And again, I am grateful every single day that the web forces designers to think about that stuff.

[troupo]

Your question stem from a few assumptions that you consider inviolable, so I'll go through them one by one

- that all software has to work on mobile

This is a fallacy. Not all software has to work on mobile. More over, mobile-first approach is exactly the wrong approach for a lot of software.

No, the software in question will not work mobile. Because it's a screenshot of Ableton Live, a professional DAW specifically made for desktop and for manipulation with mouse and keyboard.

It doesn't mean that the web is somehow superior here because "it can work on mobile, too". Not for complex UIs, for the exact same reason: screen sizes and interactions on mobile are completely different from desktop screen sizes and interactions. The simpler the UI and interaction, the better it works across desktop and mobile. See, e.g. the stripped-down versions shipped with SwiftUI/Catalyst.

- that complex dynamic UIs like the one in the screenshot can actually be done in DOM, no problem

No, they can't. And you immediately list several reasons: "because giant pages with thousands and thousands of nested elements are hell for screenreaders" and "You want to update a thousand pieces of the DOM at the same time. Well, OK, let's ask for a second whether that's actually good interface design. I would argue maybe it's not?" and "Some of these visual components you might jump out and use canvas for "

All this translates to: no, you can't make the same interface in DOM.

1. Complex dynamic interactive UIs are a hell for screenreaders regardless of technology. And there are no good solutions there.

2. Updating tens of thousands of elements is not an issue even for mobile. Games routinely update tens to hundreds of thousands of elements in a matter of milliseconds. If it's a problem for DOM, it's an indictment of DOM.

Updating even hundreds of elements is quite an ordeal for the browser. Professional software will easily update hundreds (or indeed thousands) of elements in its UI at any point without breaking a sweat. If that seems challenging to you, that's the problem of the technology you use and defend, not of the UI.

3. If you need to "jump out to canvas" to implement certain stuff, then you failed both your claim about screenreaders (canvas is 100% inaccessible) and your claim about "doable in DOM" (you wouldn't have to jump out to canvas).

Just like Figma you'd have to jump out for a lot of stuff and possibly "implement a browser inside a browser" (Figma's own words: https://www.figma.com/blog/building-a-professional-design-to...)

There's a gazillion reasons why recreating that UI in DOM is extremely difficult: browser will likely choke on that many elements, you have very little control over positioning and layout, any interactivity is likely to choke the browser due to multiple DOM updates and constant layout re-calculations etc. etc. etc.

> and I would need to have higher standards for my interface design than just "how many elements can I fit on a screen at the same time?".

No, no you wouldn't. If that was true in the general case, we would actually have actual correct beautiful performant useable useful UIs on the web. The matter of fact is that this is not the case, and web UIs are universally bad, underperforming, breaking all possible interaction modes etc.

And no. That Ableton Live UI isn't "cram as many controls as you can into UI".

> And again, I am grateful every single day that the web forces designers to think about that stuff.

This is such a bold lie.

[danShumway]

> This is a fallacy. Not all software has to work on mobile. More over, mobile-first approach is exactly the wrong approach for a lot of software.

Okay, sure, the web would be better if it wasn't cross platform. My bad, I didn't realize that it was actually a bad thing that I can check my bank account balance from Android Firefox. /s

Come on, seriously?

I don't know if it's actually worth going through this over and over again when you are literally just re-summing up my point. That all of this, "oh interface design would be so much better" talk very often boils down to:

"I shouldn't have to worry about real-world design constraints."

I am once again, so so happy that the web doesn't give you that option. Just wait until you find out that in most industries there are literal laws around considering stuff like accessibility. In most industries you don't get to act like people saying "should blind users be able to enjoy the thing" is some kind of moral slight against your artistic integrity.

But, to very quickly go over this:

----

> 1. Complex dynamic interactive UIs are a hell for screenreaders regardless of technology. And there are no good solutions there.

As it turns out, the answer is no, these professional awesome UIs that are so great don't worry about accessibility, I was correct: https://forum.ableton.com/viewtopic.php?t=230533

And once again, the critique becomes, "but accessibility is hard when I approach UIs this way, so I just shouldn't have to think about it."

And that's why we have HTML; because software UI developers don't think about a dang thing if they're not forced to. I cannot believe someone is going to try and argue that the web is worse because it works with screen readers and adblockers and extensions and all of the amazing stuff we can do because interfaces are at their core based on text and markup.

> 2. Updating tens of thousands of elements is not an issue even for mobile. Games routinely update tens to hundreds of thousands of elements in a matter of milliseconds. If it's a problem for DOM, it's an indictment of DOM.

Games are not a shining example of flexible UIs and they shouldn't be your target for most application UIs. The reason why updating tens of thousands of elements at the same time is problematic is because signaling those updates becomes a problem for users with low vision.

Nevertheless, the web has escape hatches for this in the form of Canvas/WebGL. Of course, it's harder to use them, because they shouldn't be the default thing you reach for.

> 3. If you need to "jump out to canvas" to implement certain stuff, then you failed both your claim about screenreaders (canvas is 100% inaccessible) and your claim about "doable in DOM" (you wouldn't have to jump out to canvas).

No, if you put a canvas in front of a native slider, that is 100% accessible, there is zero issue there. People don't understand how the DOM works. You can have canvas elements in your design. The only thing that actually gets in the way of accessibility is not having the slider. But there's not a requirement that your slider be made of 40 div elements, you can use the built-in browser primitives. The screenshot you provided of Ableton doesn't have 10 thousand actual logical elements in it to update.

It's got like a couple of dozen separate controls here, maybe if you want to be real generous a couple hundred: but they're just designed using some kind of skewmorphic crud that makes them seem more complicated than they actually are. But it's literally just not a problem for a couple of grid elements in there to be canvases, I'm not saying that you have to use divs for every single element in this UI.

Of course it also wouldn't be a problem for the design of some of these controls to be simpler and more visually consistent and to use common UI paradigms instead of mimicking guitar dials, but whatever, music production is obsessed with simulating physical dials in software for whatever reason. This is why I have to run a compatibility suite to get midi plugins working between Linux and Windows, because every plugin has to be quirky and ship with an entire graphics library.

Heaven forbid that we use buttons, that would get in the way of my moral duty to make my interface look like a piano. /s

One of the reasons why working with text during interface design makes you a better designer over time is because you start to group controls more and you start to think more about controls like they're logical units rather than just as collections of pixels on the screen.

> No, no you wouldn't. If that was true in the general case, we would actually have actual correct beautiful performant useable useful UIs on the web.

People need to heck off with this. We do have good UIs on the web. Better UIs than on native in multiple cases. Your standard for what is a good UI dismisses everything that is good about web UIs, but if you actually want to talk about responsive design that works in the real world and not just for a hypothetical happy-path mouse-controlled desktop, then the web often produces better UI results than native platforms.

And the web produces this result that literally no other platform can claim even though it is far more developer-accessible than most of these other platforms that people champion. I'm so tired of pretending that because somebody laid out a UI in Photoshop and they couldn't get pixel-perfect results on the web that somehow the web has failed. It hasn't. The web gets non-programmers to produce better, more accessible UIs than these professionals on the desktop that can't be asked to give a single heck about anyone who's not a prototypical customer using a standardized setup.

> This is such a bold lie.

You're right, I'm lying I'm not actually grateful for the web, you saw through my deception! /s What are you talking about?

[taeric]

Where was I proven wrong? Does that example compile down to something that isn't several dozen nested divs using react?

As stated in my post, happy to be proven wrong if that is the case. I am fairly far removed from a lot of this nowadays, and it would not be the first time that the world moved on without my noticing rapidly. (My favorite example of this is just how good battery technology has gotten. A decade ago, a battery powered lawn mower was a laughable idea. )

[danShumway]

Does it matter if it does compile down to that?

A lot of abstractions are complicated under the hood -- the high-level graphics formats that are used in engines are under the hood doing a ton of complicated tradeoffs and tricks to try and get the same sprites to render on Metal, Vulkan, OpenGL, and DirectX.

I tend to avoid over-abstraction when I can, but I still have to ask -- it a problem that those abstractions are complicated under the hood if they work for the developers that use them? Pipewire is pretty complicated under the hood to maintain compatibility with multiple setups; does that mean we can't have a universal audio interface for Linux and every device should be programming separately for ALSA and PulseAudio?

[taeric]

Fair that I don't think "what it compiles to" should be near as important as I was holding it.

CSS, though, did have a goal at the start to be a lot more approachable than what we have, though. User stylesheets were a huge selling point in early pitches that I recall. That is flat not possible with how we have things nowadays.

And I also think it would be fair to lay a lot of the blame on just how many divs so many designs explode things into.

[danShumway]

I mean... I do agree with this:

> And I also think it would be fair to lay a lot of the blame on just how many divs so many designs explode things into.

That could be a longer conversation but what I try to get across to designers is that the DOM is your interface, the DOM is not the tool you use to build your interface, the DOM should be a user-facing representation of application state, and incidentally you can also represent that visually.

So agreed, I hate it when I open dev tools and I just some completely incomprehensible mountain of divs.

That being said:

> That is flat not possible with how we have things nowadays.

I do this. I maintain custom stylesheets for websites I visit, it's very possible. It's one of the things I love about the web, I love that I can have website-specific stylesheets in Firefox without even installing an addon. I've set up hacks when I was trying to use the browser less to do grayscale effects across websites I didn't want to visit. It was a tiny amount of code and it mostly just worked, and I really couldn't do something equivalent with other platforms.

And OK, sure, maybe that's just me and it's unfair for me to say it's easy. I work with CSS a lot, I am generally proficient at it. So that's maybe a bad standard for me to have -- what about the people who don't want to work with CSS a ton until they understand it?

Well... do they use uBlock Origin? There are a host of browser extensions that modify stylesheets on the fly to do complicated things that help make the web better. uBlock Origin would be a lot worse without CSS. And there's an on-ramp for that kind of thing too, HN has honestly a pretty bad user-interface as far as the DOM is concerned. But I have a number of one-line filters in uBlock that are basically just CSS rules that help make the website better.

It's not perfect and it should be better, but I'm left looking at the alternatives again -- no other platform gives me as much control over 3rd-party user interfaces as the web. And for the most part it just works, websites like Facebook are the exception and very often, particularly for indie websites, I can open up the DOM and mess with things and fix problems.

It's a problem that it's not more accessible and I am not shaming anyone who struggles with it, but I don't think it's impossible. It's a normal thing for me to do. Maybe I'm biased on that, but I think it's very feasible for especially programmers to learn to override 3rd-party interfaces on the web.

My main critique of the web is that there should be more abstractions for non-programmers and UI designers to work with that doesn't require them to drop into a programming language when overriding things. Reader Mode for Firefox is a step in the right direction, although it could be a lot better. The browser controls for font sizes are good. There's a lot further that browsers could go to improve that situation.

[taeric]

Totally fair that my statement is too strong there. I'm not going for a legal offensive here. :D

[auggierose]

> Where was I proven wrong? Does that example compile down to something that isn't several dozen nested divs using react?

Why do you care about what it compiles down to? What does that have to do with anything?

As I said, your proof is here, it's just that you refuse to accept it.

[taeric]

As I said in the other response, I think it is fair to say I shouldn't care about what it compiles down to. That complaint is largely in pursuit of user stylesheets, where you basically do have to know the structure of the things in order to be able to adjust stuff.

I'm still skeptical, but largely on the difficulties I see frontend teams having. And despite the other poster saying they have great success with pages working on all of their devices, I daily have pages that don't. And I don't exactly visit a ton of pages. With some of these from large companies like Amazon and Google, I find it hard to believe that this is truly a solved problem. (Visiting smaller shop websites is basically guaranteed to not work on both my phone and on my monitor. Such that I don't think it is just a "big company" problem.)

[auggierose]

Basically, at least everybody using Tailwind is doing it wrong, because they are throwing out their biggest weapon: abstraction. So that could account for the failure in the real world you see. I think there are many users of Tailwind out there.

I am also not a big fan of many of the React libraries I am seeing out there. In case of my desktop app, I am more comfortable rolling everything on my own on top of browser APIs + React.

[taeric]

That resonates with my view, well enough. Most of my complaint with CSS is not the idea of having a style sheet. I'd more complain at how so many people try to get the natural flow of the document to rube goldberg into the layout that they want. That and the "unrooted" nature of most styles. It can be powerful, but usually is just a mistake.

[danShumway]

So, I'll make a concession here -- I definitely don't think CSS is perfect, and two things that are not great about it is that I'm not convinced specificity is all that good and the focus on using native elements for style names is a big trap.

When I switched to using BEM, CSS immediately became like 3x easier, especially on large projects. And there's no downside to style overrides or user customization or maintainability, there's no 3rd-party library to install, it doesn't require me to write a single line of Javascript. All I've done is change how I name classes. For users, BEM-style CSS is easier to do user overrides on through custom stylesheets than the traditional CSS that uses semantic naming.

And I do think that's a big weakness of CSS and we might have set a bunch of people up for failure by teaching everyone that the "proper" way to use CSS is to write

  main section p {
    color: red;
  }

Nah, that is asking for trouble, you will end up with soup and you will have a terrible time trying to figure out what styles are applying to what elements. Instead, use

  .Article__Paragraph {
    color: red;
  }

and all of a sudden you won't hate refactoring as much and doing style debugging in the browser will be way nicer, and when you open up your dev tools you'll see component names instead of div soup, and you'll be able to instantly grep for the code you need to change for every single style alteration you make.

Not that BEM is the only way to do that kind of thing, it's just the version I tend to evangelize most commonly. But the big thing is, use stylesheets, definitely, but don't do a bunch of nested rules that are targeting native DOM elements. We shouldn't be teaching people to do that.