That's why I like using PicoCSS on small projects, it instantly adds style without much classes needed.
gherkinnn 3 hours ago [-]
I recently went down a similar path to build the FE of an app. It worked fine at first and I learned a whole lot about recent updates to CSS. And boy, has it come a long way. Cascade layers, nesting, and the :has selector tripple-handedly change how views can be written for the better.
It is a solid solution for blogs and apps with a distinct document feel, but for anything beyond that I found it too limiting and brittle. Back to components and Tailwind.
gherkinnn 26 minutes ago [-]
Looks like I threw myself in to a Tailwind flamewar. I should've known better.
TW+TSX is easily the most productive way for me to write UIs and has been for 5 years. Don't like it? Don't use it but please leave me alone.
h4ch1 1 hours ago [-]
I don't get this comment at all; you say CSS is too limiting but somehow Tailwind, which is just applying CSS using classes is liberating?
Tailwind actually complicates a lot more things, when you have to specify variants for example, there you go installing tw-variants, writing Javascript just so you can get different sorts of buttons.
This is fine for larger component libraries like shadcn-ui, but for simplicity, I'd pick up pure CSS for something like button .error; and button .secondary.
(yes I know you can just @apply whatever you want inside those blocks, but what's the benefit of tailwind then?)
robertlagrant 1 hours ago [-]
> you say CSS is too limiting but somehow Tailwind, which is just applying CSS using classes is liberating
If you read the article you'll see what they're talking about. It's not "CSS is too limiting" it's "CSS only applied to elements is too limiting".
lawn 1 hours ago [-]
I've never heard anyone complain that CSS is too limiting. If anything it's the opposite.
zwnow 2 hours ago [-]
If u like tailwind u might like DaisyUI (daisyui.com)
Tailwind can quickly escalate into very very long class name chains, daisyui cuts that down by a ton. Yea its yet another dependency but definitely worth a look. Phoenix adopted it as default too.
habibur 2 hours ago [-]
Right click -> view source.
Found "<span class=..." — What?
Read the page.
Footer : "I only got 99% of the way there. I use 11ty’s syntax highlighting plugin, which uses classes for styling."
progbits 2 hours ago [-]
I think that's fair. It's not semantic information (I mean in a way I guess it is, but you wouldn't want a screen reader to present it as such), so classes are fine there.
xandrius 49 minutes ago [-]
It says no class though.
Iv 3 hours ago [-]
Well, HTML was supposed to be a generic language to describe typical documents. Most websites don't need more than the default elements.
From an outside perspective, it is perplexing to see the constant back and forth webdevs do between making website more complex and rediscovering the simpler first principles
zwnow 2 hours ago [-]
I am sorry but its not the devs who want complexity. Users and Designers want a snappy interactive UI with lots of animations to get the "vibe" right. Devs are usually fine with websites looking like they are straight out of 2003 (considering all the language doc pages I've seen)
zelphirkalt 30 minutes ago [-]
That depends very much on the type of developer.
Personally, I would first try to get the semantic structure of HTML right for the content I want to display. Then I would look at what I can do in CSS to make it look nice, but without going full overboard. Stick to things that are now standard in browsers, and that are responsive and resize and float nicely. Perhaps, if necessary even something like the checkbox hack, but probably try to avoid it, since it is a hack. Then the site already looks sufficiently good usually. At no point in this comes JavaScript into play, because this is about visuals, and that should be handled by HTML and CSS. I will use JS, when I have something dynamically changing and/or interactive on a page, and I will try to make a noscript alternative, perhaps usable by the user simply reloading the page.
However, I have also seen a lot of frontend devs, who just throw JS framework at everything and since everything is JS anyway, they also do things that could be simple HTML and CSS using JS instead. The result are those pages, where one is greeted by a blank white page, when not running JS.
So there definitely are a lot of devs, mostly frontend devs, that do this kinda thing, and it often secures their job by introducing complexity under the guise of looking fancy.
Example from a previous job: Making buttons that have 2 corners cut off, but the main navigation bugs regarding responsiveness, that led to broken layout took 3 months to fix. Transferring a navigation from one project to another? 3 weeks.
8 minutes ago [-]
chamomeal 28 minutes ago [-]
The dark option is definitely the most readable but wow those other themes on this site are super nice looking!!
the_other 2 hours ago [-]
I like it. Nice effort. Plus I like the visual style a lot too.
I feel there's a mismatch between creating novel "semantic" elements, and then customising them in the markup, rather than the contextual approach (nesting, rich selectors). The mismatch is that the new elements still apply a "what" approach, but the attributes used for customisation apply a "how" approach and leave it in the mark-up. It's still like `<p class="red" />` rather than `main p { background-color: red; }`.
I get that there's a trade-off between purity and code that's nice to work with, and I think you've hit a very readable, appealing and creative balance.
CafeRacer 21 minutes ago [-]
Great job!
But, I'm sticking to tailiwnd :D
xandrius 48 minutes ago [-]
So even almost classless websites can be laggy websites.
chamomeal 30 minutes ago [-]
It was super snappy for me. The snappiness actually stood out. In us east
jrrv 50 minutes ago [-]
:%s/;/:
admissionsguy 2 hours ago [-]
I can only see ~half of each line on my phone and cannot scroll, so whatever they are doing, they are doing it badly.
paganel 2 hours ago [-]
Also, can't seem to be able to select text, for one reason or another.
defanor 2 minutes ago [-]
I can see whole lines and select the text in a desktop Firefox, but the fonts are messed up (thinned and otherwise tweaked) and colors are set to reduce the contrast, making it awful to read. As with most of the design-related articles, I had to use the reader mode to actually read it. But the content can be guessed from the title (with a hint that it is about CSS) anyway: they have simply removed CSS class selectors, replacing them with element selectors, adding combinator selectors, pseudo-class selectors, and so on.
dayvster 2 hours ago [-]
Hah that's a cool and creative exercise.
Love the writing style as well
iLoveOncall 3 hours ago [-]
> I removed a non-trivial amount of CSS (now about ~5KB of CSS over the wire for the entire site)
That's around 2% of the size of the single page of that article, it absolutely is a trivial amount, especially when it complexifies so much the maintenance or addition of the website.
OtherShrezzing 40 minutes ago [-]
In fairness, the page loads two enormous fonts. Lots of blogs just use system fonts, so the advice is generally useful if you're trying to reduce your own site size. The total payload without the fonts are around 12kb, so reducing the CSS to 5kb is a fairly big deal. Without the fonts, the entire site could be delivered in the first TCP packet.
Gabrys1 3 hours ago [-]
The 5KB is trivial. They don't mention how much was actually removed. Maybe 200KB? Who knows
drcongo 2 hours ago [-]
It has also vastly simplified the maintenance of the website.
lelandfe 53 minutes ago [-]
Now let's dig into why they are using `-block` and `-inline` CSS logical properties... I guess you never know when you might be adding a traditional Mongolian translation on one's personal website.
singularity2001 2 hours ago [-]
It also has no style
2 hours ago [-]
thiago_fm 3 hours ago [-]
I love the design of his blog -- the use of dots, link highlights etc.
It also brings back memory of 2000s internet, but merged into Today's design standards. I assume this was intentional.
It is a solid solution for blogs and apps with a distinct document feel, but for anything beyond that I found it too limiting and brittle. Back to components and Tailwind.
TW+TSX is easily the most productive way for me to write UIs and has been for 5 years. Don't like it? Don't use it but please leave me alone.
Tailwind actually complicates a lot more things, when you have to specify variants for example, there you go installing tw-variants, writing Javascript just so you can get different sorts of buttons.
This is fine for larger component libraries like shadcn-ui, but for simplicity, I'd pick up pure CSS for something like button .error; and button .secondary.
(yes I know you can just @apply whatever you want inside those blocks, but what's the benefit of tailwind then?)
If you read the article you'll see what they're talking about. It's not "CSS is too limiting" it's "CSS only applied to elements is too limiting".
Tailwind can quickly escalate into very very long class name chains, daisyui cuts that down by a ton. Yea its yet another dependency but definitely worth a look. Phoenix adopted it as default too.
Found "<span class=..." — What?
Read the page.
Footer : "I only got 99% of the way there. I use 11ty’s syntax highlighting plugin, which uses classes for styling."
From an outside perspective, it is perplexing to see the constant back and forth webdevs do between making website more complex and rediscovering the simpler first principles
Personally, I would first try to get the semantic structure of HTML right for the content I want to display. Then I would look at what I can do in CSS to make it look nice, but without going full overboard. Stick to things that are now standard in browsers, and that are responsive and resize and float nicely. Perhaps, if necessary even something like the checkbox hack, but probably try to avoid it, since it is a hack. Then the site already looks sufficiently good usually. At no point in this comes JavaScript into play, because this is about visuals, and that should be handled by HTML and CSS. I will use JS, when I have something dynamically changing and/or interactive on a page, and I will try to make a noscript alternative, perhaps usable by the user simply reloading the page.
However, I have also seen a lot of frontend devs, who just throw JS framework at everything and since everything is JS anyway, they also do things that could be simple HTML and CSS using JS instead. The result are those pages, where one is greeted by a blank white page, when not running JS.
So there definitely are a lot of devs, mostly frontend devs, that do this kinda thing, and it often secures their job by introducing complexity under the guise of looking fancy.
Example from a previous job: Making buttons that have 2 corners cut off, but the main navigation bugs regarding responsiveness, that led to broken layout took 3 months to fix. Transferring a navigation from one project to another? 3 weeks.
I feel there's a mismatch between creating novel "semantic" elements, and then customising them in the markup, rather than the contextual approach (nesting, rich selectors). The mismatch is that the new elements still apply a "what" approach, but the attributes used for customisation apply a "how" approach and leave it in the mark-up. It's still like `<p class="red" />` rather than `main p { background-color: red; }`.
I get that there's a trade-off between purity and code that's nice to work with, and I think you've hit a very readable, appealing and creative balance.
But, I'm sticking to tailiwnd :D
That's around 2% of the size of the single page of that article, it absolutely is a trivial amount, especially when it complexifies so much the maintenance or addition of the website.
It also brings back memory of 2000s internet, but merged into Today's design standards. I assume this was intentional.