We went down a similar path (using Hotwire, non the less!) and got to many of the same conclusions. It is impressive to see what CSS does and how many of the headaches are gone and :has is very powerful.
Alas, after several months we tore it all out and went back to React+Tailwind.
We still use native HTML popovers and :has selectors and other things we've have learned.
But writing UIs across three files (template, stimulus controllers, css) is such a tremendous bore. Concepts that belong together are spread out and I needed to be diligent with placing attributes and classes and remember to remove them all when removing functionality again. Obviously no compile-time checks, just magic strings and runtime errors. The Hotwire docs were also surprisingly hard to work with. All in all a lot of friction.
This just was not worth it.
inb4 rage, it is possible to use React for the UI alone and pass in fully formed view models, use form submissions and links.
I'm curious about this. I'm not a frontend engineer but enjoy tinkering on simple frontend UIs for my hobby projects, and I've found Tailwind nice for creating encapsulated components more easily. It's funny that it skips the entire cascading part of Cascading Style Sheets though. Are there major downsides besides that?
> It's funny that it skips the entire cascading part of Cascading Style Sheets though. Are there major downsides besides that?
I think cascading is a bad default. It's useful, but only sometimes, and often causes headaches like unintended coupling and confusion about why rules are being overridden. The utility class approach (like Tailwind) makes a lot of issues like this go away. I don't see a good reason why the traditional approach is worth the extra pain or discipline.
CSS can be laser-like specific if you want it to. Want to only affect that thing? Use ids, inline styles or learn how to write proper selectors.
I am by no means a CSS expert, but 90% of CSS issues I heard complaints about boiled down to the complainers not having spent the time necessary to learn the basics. And the other 10% were solved by :has()
That being said, most other styling solutions I had used (e.g. in GUI libraries) will quickly make you wish you had CSS.
> CSS can be laser-like specific if you want it to. Want to only affect that thing? Use ids, inline styles or learn how to write proper selectors.
You've still go all the normal CSS problems like having to debug complex selectors, jumping between files to debug styling, having to name lots of things you're only going to use once, verbose media queries, verbose styling attributes, and not knowing when it's safe to delete styling because you don't know where it's shared.
And for what benefits? To say we're writing CSS "the right way", when it was designed for styling traditional documents and not for complex UIs?
This also strikes me as a "if everyone learned to do it properly, there wouldn't be a problem" statement. It's ignoring the reality that nobody can agree on the proper way to write CSS, and writing discipled CSS is fatiguing and time consuming. And even if you could get everyone to adopt the same approach, the above issues are still a big deal.
It's a real failing when a language or methodology requires you to invent your own complex discipline to tame it (e.g. C and C++), and get everyone on the team to follow this. At some stage, it's better to scrap everything and try again with what was learned to avoid the mess.
> 90% of CSS issues I heard complaints about boiled down to the complainers not having spent the time necessary to learn the basics. And the other 10% were solved by :has()
I really don't agree, I understand traditional CSS and how to use complex selectors and it's just not a good approach except mostly for styling traditional Markdown-like documents and adding your own utility classes. If laser-like specific selectors is something I want more of the time, I want this as the default and for it to be easy.
Tailwind is a very thin layer above CSS and you can't use it properly without knowing CSS. Coupled with the way you reuse styles in Tailwind by using templates (instead of sharing via classes), it solves most of the problems with CSS in a simple way that people find simple to follow.
Tailwind's major downside is it isn't the "traditional" way (which nobody can agree on anyway for complex UI styling), so Tailwind gets attacked for being the wrong way without its benefits and tradeoffs being examined properly.
Jumping between the files? The cascading part means you can always add in a file after and overwrite it. I don't see how this would get better without the cascading part.
My point isn't that CSS is perfect. My point is that someone has yet to show me a better styling language that isn't purely hypothetical. I am happy to learn new languages if there are clear benefits.
I mean having to jump between the HTML and multiple CSS files (which often you have to track down by using the browser inspector) to make edits to while styling things. When HTML and styling are tightly coupled anyway and almost always edited together, it just slow everything down for no good reason vs co-locating them together via utility classes.
> The cascading part means you can always add in a file after and overwrite it. I don't see how this would get better without the cascading part.
If you mean overwriting styles set somewhere else, this is what makes CSS confusing and hard to refactor. Cascading is just best avoided whenever you can.
> I am happy to learn new languages if there are clear benefits.
I can recommend looking at Tailwind. Make sure to use it with some kind of templating language e.g. so a "button" component goes in a template file, as that's the way you reuse styling (vs copy/paste) which critics seem to miss. It makes styling much simpler and quicker (everything is co-located, no need to write selectors, no need to make up class names, very concise syntax especially for mobile), especially if you're doing complex responsive designs.
I am editing my CSS files predominantly in the browsers inspector this has the benefit showing you what it looks like directly, potentially even with mobile preview.
I also don't need to hunt down CSS files because I rarely ever got more than 5 css files in projects I authored myself usually more like three: style.css for general stuff, fonts.css for fonts and multiple foo.css for page/section-specific stuff that isn't needed elsewhere thus only one of those is ever loaded.
For most "theming"-like stuff I make extensive use of css variables I want all my things to look like the button? Well just add the same styling with the variables in place.
As for the divide between HTML and CSS: to me HTML is 99% semantic. That means I describe the information as it should be described and the rest is done in CSS. Nowadays I rarely ever feel the need to create useless divs or go back and edit the HTML to fix styling issues thanks to grid layouts.
It wasn't always that way, but thst was to a degree the point of the linked article as well.
> As for the divide between HTML and CSS: to me HTML is 99% semantic. That means I describe the information as it should be described and the rest is done in CSS.
How do you visually group and align elements in designs like this one by only using semantic elements? I agree there's a few things in there that could be ol/ul/li tags but there's a lot of divs that are just flex containers or flex items. I don't see what useful semantics they could all have when they're mostly for cosmetic reasons.
Yeah think it’s best to push html css js to the limit & avoid frameworks unless obviously needed. They’re just such a rabbit hole of complexity fragility and lately supply chain risk
I like the idea of using vanilla CSS for my personal website but, not being a designer, making something that looks good from nothing is difficult. I've looked at some templates to get started with but they are generally a mess of a million classes I don't need
> Using characters as the unit of measure ensures that we get the right behavior no matter which device you’re using and in a number of other scenarios such as multitasking on iPad or even if you simply enlarge the font size past a certain point.
We went down a similar path (using Hotwire, non the less!) and got to many of the same conclusions. It is impressive to see what CSS does and how many of the headaches are gone and :has is very powerful.
Alas, after several months we tore it all out and went back to React+Tailwind.
We still use native HTML popovers and :has selectors and other things we've have learned.
But writing UIs across three files (template, stimulus controllers, css) is such a tremendous bore. Concepts that belong together are spread out and I needed to be diligent with placing attributes and classes and remember to remove them all when removing functionality again. Obviously no compile-time checks, just magic strings and runtime errors. The Hotwire docs were also surprisingly hard to work with. All in all a lot of friction.
This just was not worth it.
inb4 rage, it is possible to use React for the UI alone and pass in fully formed view models, use form submissions and links.
>let me be clear: there is nothing wrong with Tailwind
But there is.
I'm curious about this. I'm not a frontend engineer but enjoy tinkering on simple frontend UIs for my hobby projects, and I've found Tailwind nice for creating encapsulated components more easily. It's funny that it skips the entire cascading part of Cascading Style Sheets though. Are there major downsides besides that?
> It's funny that it skips the entire cascading part of Cascading Style Sheets though. Are there major downsides besides that?
I think cascading is a bad default. It's useful, but only sometimes, and often causes headaches like unintended coupling and confusion about why rules are being overridden. The utility class approach (like Tailwind) makes a lot of issues like this go away. I don't see a good reason why the traditional approach is worth the extra pain or discipline.
CSS can be laser-like specific if you want it to. Want to only affect that thing? Use ids, inline styles or learn how to write proper selectors.
I am by no means a CSS expert, but 90% of CSS issues I heard complaints about boiled down to the complainers not having spent the time necessary to learn the basics. And the other 10% were solved by :has()
That being said, most other styling solutions I had used (e.g. in GUI libraries) will quickly make you wish you had CSS.
> CSS can be laser-like specific if you want it to. Want to only affect that thing? Use ids, inline styles or learn how to write proper selectors.
You've still go all the normal CSS problems like having to debug complex selectors, jumping between files to debug styling, having to name lots of things you're only going to use once, verbose media queries, verbose styling attributes, and not knowing when it's safe to delete styling because you don't know where it's shared.
And for what benefits? To say we're writing CSS "the right way", when it was designed for styling traditional documents and not for complex UIs?
This also strikes me as a "if everyone learned to do it properly, there wouldn't be a problem" statement. It's ignoring the reality that nobody can agree on the proper way to write CSS, and writing discipled CSS is fatiguing and time consuming. And even if you could get everyone to adopt the same approach, the above issues are still a big deal.
It's a real failing when a language or methodology requires you to invent your own complex discipline to tame it (e.g. C and C++), and get everyone on the team to follow this. At some stage, it's better to scrap everything and try again with what was learned to avoid the mess.
> 90% of CSS issues I heard complaints about boiled down to the complainers not having spent the time necessary to learn the basics. And the other 10% were solved by :has()
I really don't agree, I understand traditional CSS and how to use complex selectors and it's just not a good approach except mostly for styling traditional Markdown-like documents and adding your own utility classes. If laser-like specific selectors is something I want more of the time, I want this as the default and for it to be easy.
Tailwind is a very thin layer above CSS and you can't use it properly without knowing CSS. Coupled with the way you reuse styles in Tailwind by using templates (instead of sharing via classes), it solves most of the problems with CSS in a simple way that people find simple to follow.
Tailwind's major downside is it isn't the "traditional" way (which nobody can agree on anyway for complex UI styling), so Tailwind gets attacked for being the wrong way without its benefits and tradeoffs being examined properly.
Jumping between the files? The cascading part means you can always add in a file after and overwrite it. I don't see how this would get better without the cascading part.
My point isn't that CSS is perfect. My point is that someone has yet to show me a better styling language that isn't purely hypothetical. I am happy to learn new languages if there are clear benefits.
> Jumping between the files?
I mean having to jump between the HTML and multiple CSS files (which often you have to track down by using the browser inspector) to make edits to while styling things. When HTML and styling are tightly coupled anyway and almost always edited together, it just slow everything down for no good reason vs co-locating them together via utility classes.
> The cascading part means you can always add in a file after and overwrite it. I don't see how this would get better without the cascading part.
If you mean overwriting styles set somewhere else, this is what makes CSS confusing and hard to refactor. Cascading is just best avoided whenever you can.
> I am happy to learn new languages if there are clear benefits.
I can recommend looking at Tailwind. Make sure to use it with some kind of templating language e.g. so a "button" component goes in a template file, as that's the way you reuse styling (vs copy/paste) which critics seem to miss. It makes styling much simpler and quicker (everything is co-located, no need to write selectors, no need to make up class names, very concise syntax especially for mobile), especially if you're doing complex responsive designs.
I am editing my CSS files predominantly in the browsers inspector this has the benefit showing you what it looks like directly, potentially even with mobile preview.
I also don't need to hunt down CSS files because I rarely ever got more than 5 css files in projects I authored myself usually more like three: style.css for general stuff, fonts.css for fonts and multiple foo.css for page/section-specific stuff that isn't needed elsewhere thus only one of those is ever loaded.
For most "theming"-like stuff I make extensive use of css variables I want all my things to look like the button? Well just add the same styling with the variables in place.
As for the divide between HTML and CSS: to me HTML is 99% semantic. That means I describe the information as it should be described and the rest is done in CSS. Nowadays I rarely ever feel the need to create useless divs or go back and edit the HTML to fix styling issues thanks to grid layouts.
It wasn't always that way, but thst was to a degree the point of the linked article as well.
> As for the divide between HTML and CSS: to me HTML is 99% semantic. That means I describe the information as it should be described and the rest is done in CSS.
How? Check the code of this first hero header:
https://tailwindcss.com/plus/ui-blocks/marketing/sections/he...
How do you visually group and align elements in designs like this one by only using semantic elements? I agree there's a few things in there that could be ol/ul/li tags but there's a lot of divs that are just flex containers or flex items. I don't see what useful semantics they could all have when they're mostly for cosmetic reasons.
Yes.
The cascade model is a bad design.
Yeah think it’s best to push html css js to the limit & avoid frameworks unless obviously needed. They’re just such a rabbit hole of complexity fragility and lately supply chain risk
I mostly agree. I prefer vanilla CSS to frameworks but I find a lot of value in CSS modules.
In particular I use:
1. The `composes` feature to do something like base classes.
2. The import feature to get something like namespacing.
Given the recent advancements in CSS, I won’t be surprised if they eventually build something like `composes` into the base language.
The namespacing seems more like an artifact of how you package your website and how you stay organized within your package system (I use webpack).
I like the idea of using vanilla CSS for my personal website but, not being a designer, making something that looks good from nothing is difficult. I've looked at some templates to get started with but they are generally a mess of a million classes I don't need
I used to be like this, until I realized Tailwind makes me faster.
In the context of determining responsive layout:
> Using characters as the unit of measure ensures that we get the right behavior no matter which device you’re using and in a number of other scenarios such as multitasking on iPad or even if you simply enlarge the font size past a certain point.
Nice idea! I haven't seen this before.