We keep reinventing CSS, but styling was never the problem
denodell.com
denodell.com
Someone’s never used Windows before Vista. Remember how themeable XP was across all apps?
We had standard OS controls, that’s why all that worked. The web has… extreme customization per website.
1. is dark mode
2. primary background color
3. primary forground (text) color
4. primary accent color
5. secondary accent color
6. warning accent color
7. danger accent color
Even material or fluent are similar enough that applications using either tools with the above values for an overall theme would be easy enough to apply throughout an application.
Most GUI suffers from the NIH sydrome. Instead of using system components (and systems values and colors), every designer are pushing for adhoc widgets with fixed values.
Nobody can decide on standards because everyone is greedy. Microsoft has, like, a dozen GUI platforms and they're all Windows-only. Apple doesn't even use an off the shelf rendering API. And android is... Well, android.
Sure, I would like to use the OS provided controls. And then maybe after that we can all hold hands and sing Kumbaya.
I think it's because UI design is very much something that can't really be "solved" in the traditional sense, so a lot of us use our own opinions when we inevitably find a corner case that isn't working exactly the way we want.
Greed is maybe not the right word, but maybe it's more like ideological greed. Like everyone wants things their way 100%. They won't settle for 99%!
Like okay, with Apple and vulkan and metal, is vulkan the best API? No. Is it the most performant? No.
But it's pretty fucking good. Its 95% of the way there. But for greedy apple, that's not good enough. So they say "fuck you, heres metal, good luck developers!"
And now people only make Mac apps if there's a gun to their head and they really need that tiny slice of market share.
Its the same thing with Qt versus bespoke UIs in ImGUI or whatever. Qt is really, really good. Its not perfect.
But we're really gonna burn it all down and start over for like... a 1% improvement in code architecture or something? Really? We're chopping off both our legs so that our pinky finger hurts slightly less?
Sigh. Okay. Such is the way of developers, I guess.
Most standard toolkits provide escape hatches to have your custom components. I think most designers wants their view imposed to the users instead of following the platform constraints. Like instead of the standard play/pause button every player have, they want their own custom ones. Instead of using the standard tree widget, they want to create another that is the same, but behaves a bit differently. And then they say GTK is not good, let's go with HTML in Electron.
The only reason the original post think that "used to be a solved problem" was because we used to have a standard for guis: win32. But obviously people wanted more powerful/flexible UIs and more importantly, cross platform guis so it eventually died off.
A lot of design innovation came because the web is extremely flexible while at the same time being extremely non-standardized.
<select multiple
Also, don't forget that if you want to submit the values with something else than a GET wirh URL params or a POST with formdata mimetype for the body, you'll need JS anyway.
You can use it as backing for some JS component though (visually hidden), this is often done to have components work accessibly and with maximum interoperability. And to get functionality and tests right without implementing complex ARIA standards perfectly and running into constant issues with vanilla form submits (see above) or focus states and a11y.
the distinction i make is that a document is static, an application is dynamic. that menu needs to be regenerated every time a new document is added. if i include the menu in each document then every time i add a new document, i have to edit every other document to update the menu.
that has implications, including the timestamp when that document was last changed. therefore the distinction matters. i do not want to have to touch every document in order to update a menu. the menu should be distinct and be changeable without touching existing documents.
current html standards do not allow that because they do not support include. and http does not support directories. that's one advantage gopher had over http.
i can include the menu with javascript, or i could use xslt. but either way, the menu is an application, and it's not part of the document.
no being able to make this distinction is what forced me to build dynamic websites already in the early 90s. back then we didn't even have javascript, we only had serverside includes and eventually servers that could generate whole pages dynamically. it is in part what led me to a search for better webservers than the ones ncsa and cern were offering. but that's another story.
except that the browser does not provide enough interface for navigation. only back/forward, and clicking on links.
compare that to an email client or really any other application. hackernews is a messaging application.
a linked CSS file somehow makes the page an application
no, to keep with the analogy, the CSS part IS the application.
XSLT is exactly how current HTML standards allow static client-side includes
well, kind of. you need a lot of code to describe a simple template: https://news.ycombinator.com/item?id=44398626 [1]
and that still doesn't work for cases where you want multiple document in one view though.
it is at least a step in the right direction. it allows me to keep the document separate and free of navigation artifacts (the linked example is not ideal in that case, but it can be done).
but the same is achived if i build an SPA with javascript. the browser first loads the SPA application, and then the application loads the documents to be displayed. that allows me to keep the documents as original on the server. and unlike xslt this also works for multiple documents in the same view.
[1]: for those reading that thread to the end, the chromium issue turns out to be limited to the fedora build of chromium, nightly builds from the chromium website and chrome work.
And that is all that needed. If you want to provide a common structure for navigation, usually a menu, it should be sent as part of the page. Which means the document and the navigation needs to be composed server side (either on the fly, or generated once). Then you can enhance the page client side (which is rarely needed).
Most SPAs are reinventing the browser features (history, routing, navigation state, submitting forms, showing request's responses). When you really needs a full fledged application, those don't really matter (Figma, music players, document viewers,..).
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.
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.
Practically every one of these uses components, internal state, and design systems to make the site highly interactive, just about every "web app" falls into this category.
Fill out an email form, hit submit. Fill out my tax form, hit submit. Fill out a ticket form, hit submit. It's prettied up CRUD, but it's CRUD.
There's no high levels of interactivity, nor any sort of need for client side state in any of them.
Like go over 20 jira tickets to update the names or adjust different properties on different ticket.
Now read again "different properties on different issues".
Like you are not going to bulk edit task requirements or set title for 20 tasks to the same thing.
Better examples would be things like Google Maps, Lucidchart, Google Docs, Photoshop, Zoom, any 3D rendering. These applications can only work with components and internal state.
99% of web "apps" don't need the complexity.
It's not that complex or fancy compared to what can be found in b2c, but it's not just a crud where users are directly tasked to update values in fields either. And yes, it could have been a crud, but I believe our users would have been worse off.
Accessibility issue is a good point, but the accessible way doesn’t need to be the only way.
That's pre-javascript workflow. You can have your DnD without making your app an SPA. And why not have the DnD and the more complete change form?
My point was giving an example of an app that's a bit more featured than just some forms in a CRUD interface, not that you can only do that with a SPA.
> And why not have the DnD and the more complete change form?
It was, in fact, what we did.
There are plenty of JS frameworks and some have a more ergonomic dev experience than others, but what is an undeniable fact is that most users prefer SPAs for highly interactive apps. There is a ton of research into user retention that proves this. Google aren't building SPAs because they like Angular.
Obviously, yes.
> I haven't seen anything like that. 99.9% of applications I interact with are just simple CRUD apps.
Irrelevant. Being CRUD is completely orthogonal to whether the WebApps are interactive or not.
Look at Gmail. You can hand wave over it and claim it's a CRUD app. However, no one in their right mind would try to deny the app is a "highly interactive, component-based, state-driven, design-system-heavy applications".
Also, it's silly to pretend that SPA-type apps are only justified if you check each box in the buzzword bingo card. One of the primary selling points of designing SPA or non-static lage, SPA-like WebApps is performance. Meaning, you are able to put together a highly performant web page if you do not require full page reloads each time anyone clicks on something, if you can easily implement optimistic logic in components, and if you can update only a subset of components when you receive a response from a request.
I recommend discovering the concept of perceived performance and afterwards you read through common patterns and strategies to optimize perceived performance. After you do that, go through a though experiment where you start off with an old timey dynamic HTML/server-side rendered WebApp and consider the challenge of achieving the same type of improvements in user experience, or even doing the same tricks. You'll quickly arrive at the same conclusions at the whole world around you already arrived at.
It's literally basic web 2.0 junk from the early 2000s, the UI has barely changed since it launched.
That's perfectly fine. If you can't see it, you can't see it. You need to know what to look for to see it, though. If you're oblivious to web development then every page is just a page.
> You receive like an email a minute?
Irrelevant. The range of operations that Gmail supports and falls within the lazy classification of CRUD operations goed way beyond sending and receiving emails. For example, see gmail's support for tagging, email classification, multiple types of inboxes, etc.
> It's literally basic web 2.0 junk from the early 2000s (...)
Tell me you're completely clueless about web development and WebApps in general without actually saying it. Just keep in mind that you also have the option of not commenting on things you're oblivious about.
Petty sniping is not welcome.
Of course, there are webs which are developed with the worst practices and bloated to oblivion. But even the best websites with the greatest UI/UX and perceived performance will have at least some complexity to it to give that experience to the end user. UX and simplicity done right is really a craft that mixes creativity, human psychology and technical skill.
A linear form with help messages is better than any gimmicky design one can think of.
It's possible to make a web 1.0 HTML email client but GMail is much much better. It's the difference between 1998 MapQuest and Google Maps.
No one in their right mind who does a lot of emailing would use it compared to the normal one besides for ideological reasons.
A dresser can be hand crafted from solid oak and built to last centuries, or it can be flat-pack barely better than cardboard with fake plastic oak veneer.
You can make a fully functional SPA with less than 1mb of payload, or you can create the hot garbage that is Jack In The Box's menu website, that delivers 48mb of insanely bloated JS garbage. And I only harp on them because it's the single worst SPA example I've seen to date.
For that matter, I think with some nice tooling HTMX can be a pretty great experience for most in-between usage.
When people say CRUD App, I assume they mean web page + sprinkle of JavaScripts.
The vast majority of web apps out there could be implemented as REST systems (in the real, Fielding, HATEOAS sense, not the JSON-over-HTTP sense).
There are a few out there which need to be web apps, but those are relatively rare.
The point is you need the logic on the server since you can't trust the client, but you can make the client "dumb" with just super generic ability to show data and submit forms, and then you don't need to write your application logic a second time in the client. The server sends it instructions for the generic renderer to perform.
The painful reality is that this is true, but only at work.
There is so much that you use written in web technologies that are no CRUD. Some of that is Electron apps like VS Code and some of it is applications packaged in docker containers. Almost all of this non-work and non-CRUD stuff is open source. If you aren't writing code outside of work, where its only CRUD, your perspective of the universe is about 2mm wide. That is where the Dunning-Kruger starts to set in and why all this shit gets reinvented every couple of years. Its easy to think that: 1) you are awesome and 2) the world is painful when your perspective of the universe is only 2mm wide.
For everybody else, these things that most developers complain about really aren't painful enough to warrant any call to action because there are other things that bring substantially greater pain.
It’s a Dropbox-like file manager that instead of owning your data integrates with your existing storage, authentication, and authorization systems. Under the hood, there’s a lot going on, very recently I added plugins to handle various kind of file types that are not typically handled by browser, we're talking > 100 kind of file types handled entirely in the browser for niches like astronomy, data engineering, GIS, 3D models, dev and even embroidery patterns
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.
In a couple of years people will wonder why anyone would use something like Tailwind.
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.
So give that point was completely bunk, you changed it to something about the total number of internet connected devices. I have absolutely no clue why that is relevant, and you haven't explained why it is either.
What a world we live on.
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.
The moment we do that; we can theoretically implement any GUI framework we like, rendering to a <canvas> tag, without the current (serious) downsides. I’m looking forward towards more exploration of that direction. Then, we can mostly be free of HTML, CSS, and JavaScript defining how apps can be built. Those three tools that have long outlived their original intentions and have gone into complete duct-tape territory.
AI however, might actually solve this sooner than we realize. Apple already uses AI to copy-paste text from images. I’m sure there’s plenty of R&D going on right now on using AI to describe what is on screen. In theory, maybe we can legitimately AI our way out of needing accessibility concessions, and off we go. Build your website in Flutter; or in MAUI; or in some DIY port of SwiftUI; whatever you want.
On the upside, most people don’t build their own frameworks. Implement it right in Flutter, MAUI, etc. in such a scenario, and almost nobody will be harmed.
Also, for anyone who just says this is Java and Flash all over again - we’ve had plenty of technologies come full circle. WASM might be the one that gets us to full “web as app engine.” It already basically is, just badly.
Silverlight, Applets, Flash, all have WebAssembly runtimes now.
This is somewhat like the leap Figma has made. They were able to build their own walled-garden, offer value in it, and not have to worry about SEO. Most of the web is not in that position.
I'd imagine we'd be better off with more such fragmentation, though?
The internet was built to allow fragmentation, of protocols, of tech, of connections. It is just that, of course, most sites must flow to where the easy $ are. Let's just hope that enough good sites can escape the pull of easy $.
We might reach the point of saying, screw it, it hardly matters anymore. The web has been conquered by LOB apps, Paywalls, and Walled Gardens; and there’s no real way to fix that, but there is a way to fix the tech we are using.
If anything, if we fully embrace “web as app engine,” we can fix some of these issues ahead of time. Maybe we have a standard entry point for crawlers (or users) requesting the raw text of a document. It’s better than being stuck in this awful in-between which we are right now.
Like separating the text and widgets rendering engines, and placement engines with "stick" orientations.
I think some things work better when they’ve evolved from simplicity to complexity, and application hosts seem to be one of them.
I don't think it's so much a question complexity than a question of using the "right tool for the job". Web technologies were never designed for that, never engineered to be extensible. Web apps is a hack, it's terrible, and that's all because of politics.
We stopped using these for a variety of reasons: they were difficult to make secure or cross-platform, GMail made building apps in JavaScript fashionable, and the iPhone (which explicitly would not support ActiveX/Java/Flash).
If Tim Berners-Lee had made the web for apps and not documents, history would have been no different. Somebody besides Tim would have made a remote document system and we'd all be using that instead of something called the web.
My experience has been increased cognitive load when I come back to tailwind styles after a long time, when compared to dealing with handwritten CSS selectors and classes
Tailwind is only useful if you have some kind of templating system where you can define components. And in this case, it’s very easy to scope your css.
When you say "handwritten CSS selectors and classes," what you really mean is learning a unique codebase with high levels of abstraction that map on to the DOM in a structured way that cannot be automatically inferred. It has to be learned by looking at both the CSS (often buried in many component files) and how the components are implemented in the DOM. In large projects, this is far from trivial.
And I think that's the key. When people say "handwritten" CSS is either, what they mean is that their small project, with no other contributors, is easier to manage.
When picking up a Tailwind project, what's to learn again? You might forget some of the class names, but if you already know the CSS properties, you're 80% there. With your IDE's completion, you're 90%. And crucially, no context switching whatsoever.
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.
Look, it's strictly pragmatic approach, i end up creating utility classes anyway and i'm really glad someone did this for me.
Maintaining Tailwind (or a mix of Tailwind and CSS) is routine, just like it should be.
And i'm talking about web app development, markup is cluttered anyway (tsx or whatnot), semantic effort is already put in components and such. So yeah, saving some cognitive load works and helps in case of Tailwind.
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
in fairness to css, I think my team would struggle with most technologies they weren’t ready to learn.
https://developer.mozilla.org/en-US/docs/Web/CSS/Nesting_sel...
Browser support is here: https://caniuse.com/?search=nesting
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.
This results in only two modern browser engines available: chromium (by google), and FF (mostly sponsored by google). Very sad state.