EDIT: the nested selector popped up without me noticing; removing my comment because I was working from faulty information (and clearly was missing from the blog post)
> Fast-forward a couple of decades and we’re building highly interactive, component-based, state-driven, design-system-heavy applications
Are we actually, in fact, if we're being honest?
I haven't seen anything like that. 99.9% of applications I interact with are just a series of simple CRUD operations. Sometimes they add unnecessary complexity and flashiness and of course there are some games and such, but when it comes to actual business apps they all just boil down to updating text records in a database at a human pace.
I am genuinely interested to hear examples of these "highly interactive" web apps others are building I keep hearing about but never seeing.
All the cognitive load you save is immediately burdened by scanning 60-100 CSS classes in a 200-300 line length HTML element. And this repeated over and over and over in a ginormous number of lines. Giving you a massive migraine.
Turns out HTML size also increase by 7-20x in tailwind CSS.
Tailwind CSS is "write-only" code. Maintaining a site developed by someone else who has gone full-blown worship of the Tailwind Dao is a nightmare.
The solution is already here, and it's totally fine: Use utility classes just for layout (margin, padding, etc); use scoped styles for your components; use a small set of globally available classes for styling native elements (buttons, etc) -- and you're good!
Vue and others have had scoped styles for a long time. Now @scope is spec'd with improving browser support. All this pain in TFA is from people flailing with all of the many bad options that pervade the React ecosystem.
Here we go. Let's spin the wheel of front-end framework fortune once again. The article correctly identifies that CSS isn't the problem, but just giving up on elegance is premature.
IME, CSS is actually _just fine_ and would do as well as anything else at the job. The real problems arise from:
- People just not being aware of the affordances of modern CSS (like nested selectors, variables, fancy grid layout stuff, etc.). Of course CSS is going is suck if you insist on living with CSS3 like it's 1998.
- Inherent domain contradictions. "I want isolated styling!" "I want consistent theming!" and like the dog in the "no take, only throw!" meme, "I don't want interfaces. I want my styling to be isolated except when I don't want it to be!"
CSS is actually pretty elegant. We should be using declarative, composable configuration (e.g. CUE) in other domains too.
It's a vendor-lock problem that's being solved (by google) by all that complexity. Effectively, it's too expensive to maintain core browser (approx. $1B/year for chromium) engine because of all that css and other standards published (and adopted by some developers) every month.
Beyond the fact that almost all web "apps" are actually honest documents, let's not forget that operating systems 20 years ago were more "highly interactive, component-based, state-driven, design-system-heavy applications" and still globally (across all applications at once) themeable. So it seems to me that the problem is that modern UI in fact has lost the concept of modular components. e.g. every time someone comes out with light/dark mode as a feature, I can't help but feel like it's an insider joke that's been running so long that the new kids think it's serious. Every single application used to have a more powerful version of that by default. There were GUIs for users that were simple enough to find and use that my 90 year old grandma had customized the theme on her windows 98 machine.
"Beyond the fact that almost all web "apps" are actually honest documents, ..."
The www is a document publishing scheme
The documents can contain links ("URLs") pointing to files of any type, text or binary
The documents can contain hyperlinks to each other
Option #1: Publish HTML with visible hyperlink to source code, the www user chooses whether or not to download the code, compile it and run it on their computer
Option #2: Publish HTML with hidden link to executable code, presume that the www user is using a program that contains an interpreter for the code, downloads it to temporary storage and runs it automatically without any www user interaction
Option #2 exposes www users to endless surveillance and monotonous annoyances
It is amusing to watch so-called "technical" people try control this default behaviour in popular browsers, the automatic running of other peoples' Javascripts
Their "solution" is to write their own Javascripts, e.g., "browser extensions"
Whoever maintains the browser software can limit or disable this "solution" at any time for any reason;
Currently companies engaged in online surveillance-based, programmatic, targeted advertising are the browser maintainers
But that nonsense only applies to Option #2
Option #1 is still in heavy usage
Although the number of www users aware of it may be relatively small
For myself as a document consumer, the www still functions well as a document publishing scheme
> Every single application used to have a more powerful version of that by default
Kinda. Having tried to use various dark themes before in that era of theming, it was always a mess of broken applications, since you could easily get a dark-against-dark or a light-against-light contrast if one part of the UI picked up the theme but another part did not. If careful use of the theme colors is not enforced or tested, then themes will tend to be broken in enough cases to not make them worthwhile.
(I'm very pro themeing and customisation, but it's a lot of effort that everyone needs to be on board with to make it work, it's not enough to just make the tools available, you need to actively push them into use, and I think very few people have found that worthwhile: there's just about enough utility to dark modes for enough people for some developers to consider it worthwhile, but I think the longer tail becomes very unpalatable in terms of cost/benefit tradeoff)
This would be less of a problem now that dark/light mode has become a mainstream thing. Both normal users and developers often switch between light and dark, so bugs would be found quickly and solved with high priority.
The reason theming back in the day was often broken is because it was very niche. That one sysadmin using Linux with a satanic theme complaining about some dark-on-dark text won't even get a reply, but a customer's executive running macOS using its built-in automatic dark/light switcher complaining will be the top priority.
It's a shame the implementation went to a boolen dark/light instead of exposing a bunch of semantic color variables like old toolkits used to do, but we can "thank" designers for that one.
> let's not forget that operating systems 20 years ago were more "highly interactive, component-based, state-driven, design-system-heavy applications" and still globally (across all applications at once) themeable. So it seems to me that the problem is that modern UI in fact has lost the concept of modular components. e.g. every time someone comes out with light/dark mode as a feature, I can't help but feel like it's an insider joke that's been running so long that the new kids think it's serious
?
It would be possible to have this, by building all apps on the web platform exclusively from native input elements.
For forms. With no fancy things like combo boxes or multi selects!
Window interface, menu bar: using native controls there is ofc a power that web apps don't have.
Regarding the rest, I think you are painting the past with rose-colored glasses.
Yes, UI kits for native applications are more powerful than the web platform in many regards.
But the Windows applications I remember often were a mix of native controls and custom (of course, unthemable) elements.
Many applications even went out of their way to avoid native controls. E.g. SAP, Winamp, and loads of other programs I don't remember now.
Reinventing UI controls is not exclusive to the web platform and "the new kids" have no OS UI framework to build on. They have the web platform.
I too remember the styling options in Windows pre Windows 7.
I loved to play with the ones in Win98.
Most of them would have unpredictable effects on most desktop applications, because of the unpredictable mix of native controls and custom GUI.
If you want to improve web apps, why not argue for better native HTML interactive elements? E.g. menu, multi-select, date-picker...
What I agree with is that handling zoom, font size, color schemes should never be eschewed or ignored.
Oddly enough, in my work history, the Venn diagram of the people who argued for "just make it look like the design, nobody zooms" and the people being smug at web UI was very large. Smug at CSS too, the next moment cheering for obscure and inaccessible, bug-ridden "CSS-only" solutions that the one person who can write CSS proposed as a joke, because a styled toggle switch "shouldn't require JS" (I somewhat agree with this, although the programming language is unimportant).
Rant over... nostalgia is a nice thing.
But web apps are not Windows applications or GTK applications or macOS applications, and these all habe never been as perfect as you make them out.
Sure, large, data-driven applications with good developers for native UI did many things better than many web applications do.
But that's not because web app programmers are too stupid to just do the same thing. That's a tired trope.
Sure, web development has a low barrier to entry. Ranting about it has an even lower one though.
> React, Vue, Svelte. They all put components at the core. Scoped logic. Scoped templates. Scoped state. Then we hand them a stylesheet that’s global, cascading, and inherited by default.
I don't know about react and vue, but svelte has a style tag that's scoped to the component.
Ah dangit. I was expecting a deeper conclusion. Then I checked on GPTZero and turns out the article is very likely to be AI-made. The header, too (you can tell). I'm not sure I should be taking advice from an LLM...
CSS is kudzu, growing wild and untameable. The complexity has long since reached the point that implementing a new browser engine would be nearly impossible. The fact that the maintainers don't even any sort of releases, shows just how out of control it is.
The problem is not reinventing CSS, rather misusing a platform designed for interactive documents as application platform.
We should have left the Web be Web, and use native applications with Internet protocols for applications, like it has always been until the rise of Java applets, ActiveX and Flash.
Then HTML5 came to be, and we have yet to sort out all the mess, but hey should not complain too much, it pays most of the bills.
Maybe it's the author's style but this whole thing feels almost stereotypically written by an LLM. Bullet point overuse, "The real question" "Here’s the uncomfortable truth" "this isn't just X it's a Y"
On the other hand, top LLMs are better at CSS than just about everyone so it's a top percentile expert opinion at least lmao.
Unpopular opinion: we should treat the web sites less like apps and more like documents with forms. I'm so tired of devs trying to recreate the browser inside of the browser and all the bugs that comes with it
24 comments
[ 2.4 ms ] story [ 59.6 ms ] threadin fairness to css, I think my team would struggle with most technologies they weren’t ready to learn.
Are we actually, in fact, if we're being honest?
I haven't seen anything like that. 99.9% of applications I interact with are just a series of simple CRUD operations. Sometimes they add unnecessary complexity and flashiness and of course there are some games and such, but when it comes to actual business apps they all just boil down to updating text records in a database at a human pace.
I am genuinely interested to hear examples of these "highly interactive" web apps others are building I keep hearing about but never seeing.
What a world we live on.
Turns out HTML size also increase by 7-20x in tailwind CSS.
Tailwind CSS is "write-only" code. Maintaining a site developed by someone else who has gone full-blown worship of the Tailwind Dao is a nightmare.
Vue and others have had scoped styles for a long time. Now @scope is spec'd with improving browser support. All this pain in TFA is from people flailing with all of the many bad options that pervade the React ecosystem.
IME, CSS is actually _just fine_ and would do as well as anything else at the job. The real problems arise from:
- People just not being aware of the affordances of modern CSS (like nested selectors, variables, fancy grid layout stuff, etc.). Of course CSS is going is suck if you insist on living with CSS3 like it's 1998.
- Inherent domain contradictions. "I want isolated styling!" "I want consistent theming!" and like the dog in the "no take, only throw!" meme, "I don't want interfaces. I want my styling to be isolated except when I don't want it to be!"
CSS is actually pretty elegant. We should be using declarative, composable configuration (e.g. CUE) in other domains too.
The www is a document publishing scheme
The documents can contain links ("URLs") pointing to files of any type, text or binary
The documents can contain hyperlinks to each other
Option #1: Publish HTML with visible hyperlink to source code, the www user chooses whether or not to download the code, compile it and run it on their computer
Option #2: Publish HTML with hidden link to executable code, presume that the www user is using a program that contains an interpreter for the code, downloads it to temporary storage and runs it automatically without any www user interaction
Option #2 exposes www users to endless surveillance and monotonous annoyances
It is amusing to watch so-called "technical" people try control this default behaviour in popular browsers, the automatic running of other peoples' Javascripts
Their "solution" is to write their own Javascripts, e.g., "browser extensions"
Whoever maintains the browser software can limit or disable this "solution" at any time for any reason;
Currently companies engaged in online surveillance-based, programmatic, targeted advertising are the browser maintainers
But that nonsense only applies to Option #2
Option #1 is still in heavy usage
Although the number of www users aware of it may be relatively small
For myself as a document consumer, the www still functions well as a document publishing scheme
Kinda. Having tried to use various dark themes before in that era of theming, it was always a mess of broken applications, since you could easily get a dark-against-dark or a light-against-light contrast if one part of the UI picked up the theme but another part did not. If careful use of the theme colors is not enforced or tested, then themes will tend to be broken in enough cases to not make them worthwhile.
(I'm very pro themeing and customisation, but it's a lot of effort that everyone needs to be on board with to make it work, it's not enough to just make the tools available, you need to actively push them into use, and I think very few people have found that worthwhile: there's just about enough utility to dark modes for enough people for some developers to consider it worthwhile, but I think the longer tail becomes very unpalatable in terms of cost/benefit tradeoff)
The reason theming back in the day was often broken is because it was very niche. That one sysadmin using Linux with a satanic theme complaining about some dark-on-dark text won't even get a reply, but a customer's executive running macOS using its built-in automatic dark/light switcher complaining will be the top priority.
It's a shame the implementation went to a boolen dark/light instead of exposing a bunch of semantic color variables like old toolkits used to do, but we can "thank" designers for that one.
?
It would be possible to have this, by building all apps on the web platform exclusively from native input elements.
For forms. With no fancy things like combo boxes or multi selects!
Window interface, menu bar: using native controls there is ofc a power that web apps don't have.
Regarding the rest, I think you are painting the past with rose-colored glasses.
Yes, UI kits for native applications are more powerful than the web platform in many regards.
But the Windows applications I remember often were a mix of native controls and custom (of course, unthemable) elements.
Many applications even went out of their way to avoid native controls. E.g. SAP, Winamp, and loads of other programs I don't remember now.
Reinventing UI controls is not exclusive to the web platform and "the new kids" have no OS UI framework to build on. They have the web platform.
I too remember the styling options in Windows pre Windows 7.
I loved to play with the ones in Win98.
Most of them would have unpredictable effects on most desktop applications, because of the unpredictable mix of native controls and custom GUI.
If you want to improve web apps, why not argue for better native HTML interactive elements? E.g. menu, multi-select, date-picker...
What I agree with is that handling zoom, font size, color schemes should never be eschewed or ignored.
Oddly enough, in my work history, the Venn diagram of the people who argued for "just make it look like the design, nobody zooms" and the people being smug at web UI was very large. Smug at CSS too, the next moment cheering for obscure and inaccessible, bug-ridden "CSS-only" solutions that the one person who can write CSS proposed as a joke, because a styled toggle switch "shouldn't require JS" (I somewhat agree with this, although the programming language is unimportant).
Rant over... nostalgia is a nice thing.
But web apps are not Windows applications or GTK applications or macOS applications, and these all habe never been as perfect as you make them out.
Sure, large, data-driven applications with good developers for native UI did many things better than many web applications do.
But that's not because web app programmers are too stupid to just do the same thing. That's a tired trope.
Sure, web development has a low barrier to entry. Ranting about it has an even lower one though.
I don't know about react and vue, but svelte has a style tag that's scoped to the component.
There are people building new browser engines
We should have left the Web be Web, and use native applications with Internet protocols for applications, like it has always been until the rise of Java applets, ActiveX and Flash.
Then HTML5 came to be, and we have yet to sort out all the mess, but hey should not complain too much, it pays most of the bills.
On the other hand, top LLMs are better at CSS than just about everyone so it's a top percentile expert opinion at least lmao.