As someone who actively goes out of my way to stick to writing vanilla HTML/CSS/JS as much as possible, it's honestly hard to explain to people who only write within frameworks how good it's gotten. Use the proper tool for the job, of course, but it sparks joy!
I've done the same for years, and it feels a little bit like the IQ bell curve meme, where on the left and right it is like "vanilla HTML/CSS/JS are all you need."
This is an earnest question but is that really true for reactivity and state management? Of course with vanilla is all things are technically possible, but I feel like last I checked this wasn’t something well supported without really knowing what you’re doing.
1. The tools available in vanilla have improved a lot recently and 2. LLMs have made niche skills/knowledge more accessible. SPAs still have their place but the average CRUD app is now really well served by vanilla or lightweight libraries like HTMX.
On the other hand, the average CRUD app doesn’t care about the traffic and rendering overhead of a reactivity library such as Vue. Looking at the boilerplate code needed for basic reactivity that your sibling comment linked to in the Mozilla docs… no, thanks. Just eat the 16kb and have some decent ergonomics.
Definitely worth keeping up with as a framework user too.
Smaller bundles, often easier to use, less bug potential. Code's a liability and being able to occasionally rip a bunch out as a feature becomes baseline is always a joy.
Y'all know React and Vue frameworks still use HTML, CSS, and JS, right? We're using the same thing, with a thin layer of helpers around mounting components and managing their lifetimes...
As culi also touches on I think it depends on what is meant by frameworks. As someone who belives abstraction are horrible practice unless they serve a really good purpose though, I never bought the "this is easier" part of the big CSS frameworks. I fully accept that people who work on user facing web applications more than I do, which is rarely, had a much easier time using something like bootstrap/tailwind/whatever. I always found having to look up documentation on something wich was infinitely worse than the CSS documentation on developer.mozilla.org to be a a weird experience. I do fully accept that a lot of teams experiences would prove my personal opinions wrong on this.
On the flip-side I always found javascript frameworks to have a purpose. Though to be fair I don't think I've worked with user facing javascript without a framework since jquery came about. I guess you could call that a library, but still.
People who use css-as-an-object type of frameworks or tailwind don't really get to experience what writing CSS is like. styled-components or Linaria or Emotion do though ofc
Since I’m in before the negativity: I love CSS! For whatever reason, it’s always made sense to me. I have great respect for everyone with the tenacity to push on improvements that might take 5-10 years to be in common use, if at all.
We're pretty far past the 5-10 year timeframe now that browsers push updates so aggressively. It's pretty common to see features that were adopted just a year ago in common use
I’m part of the seeming minority that really enjoys working with CSS. And the way I use it today is so different than I did a few years back, e.g CSS modules, declaring a palette with variables then changing it for dark mode… it’s genuinely great to work with.
Working with modern CSS is such a joy, and increasingly as time goes on I'm replacing huge chunks of JS with CSS which is a little boon in itself. Honestly, my only complaint is how long I have to actually wait to use new features.
Nesting and @layers make maintaining CSS drastically easier than it once was as well.
I love working with CSS as well. It feels like the most optimized approach to me. However, it's really hard to use CSS as much once the project involves other engineers who don't have that level of interest in CSS.
light-dark() is even better for that :) I also enjoy CSS, using @scope and @layer a lot with the :has() selector, it’s just so different now and I think most people are unaware.
Worth keeping in mind that Josh's blog is absolutely over-engineered and I'm sure he'd admit that himself. He tried to keep parity with his rather complex course systems and his blog itself is a lot more than 'text on a page'.
offtopic here but what the heck, I am learning C from you right now! You finally made pointers click for me after failing to learn them a handful of times in the past. Legend!
The discussion here reminded me of one of my favorite demos, someone live coding Qt5 and QML on a first a generation Raspberry Pi, 1080p HDMI. Sort of a mashup of CSS and JavaScript for simple shaders. Fourteen years ago.
> If you’re familiar with JavaScript, this should feel pretty familiar. We define new functions with @function and specify the returned value with result.
It used to be that HTML was for content, CSS was for layout, and JS was for "code"
Now JS is for content and layout and code, HTML is for content and layout, and CSS if for layout and code
The new responsively-sized iframes standard is an exciting one for me not mentioned. It's finally a step beyond the original frames and framesets. It will let us design sites out of iframes as building blocks instead of needing to use web components. Websites made out of websites.
The future of HTML/CSS and hopefully JavaScript is, that it no longer used and replaced by a new technology stack.
Especially CSS is such a miss fitting technology for what it is used today, that web frameworks actively fight it, by trying to keep its scope to components.
When looked at web tech from a distance, it is cristal clear to me that we need something new.
Instead of all the abysmal complicated rules of CSS, we would probably be much better served by something like ElmUI (a modern advanced version of the idea) + some scripting for dynamic things.
A bit strange to me how Josh beings with heralding the browsers working together and then every mentioned feature is Chrome only. They're nice previews for a potential future I suppose!
The article is specifically about the “inter-op” program where the browsers work together on specific standards to bring to all browsers. (And we get to vote on the selection!)
Been waiting a long time for CSS inherit() . . . although I freely admit that (and CSS Functions) open a respectable-sized can of worms. Sort of like what transclusion and conditionals do for document markup.
Anchor Positioning would be sweet and doesn't feel like it's got so much baggage.
I am very much excited for the future of CSS. And I love that functions are a part of it.
I spent 3 months this year testing out a reporting system for large quantities of dynamic data.
My requirement was to generate pdf reports, but didn't want any reporting tools and installations. Especially something like Microsoft Excel, which the old system was based on.
After a lot of tests and proof-of-concept apps, I finally zeroed down to simple, pure, self contained html, that I am generating from a python script.
And it's glorious.
I am generating interactive charts when the html is viewed in the browser, and hiding all of them and only printing static svg images when in print mode, using css media print queries.
Because JavaScript requires… a lot. A virtual machine, script parsing, etc. Making that a requirement before you even display any content on the page would be a regression.
If CSS is Turing complete, that means it has a virtual machine with parsing and so forth. That means that difference between it and JavaScript is just syntax. (Same for any Turing complete language)
I can see that, but CSS already requires a lot, no? Especially as they keep adding new features to it.
To me it feels like "programming in YAML", the way a declarative language/format acquires more and more features until you're writing functions in an awkward syntax that was never designed for it.
Strongly agree. While I am a huge fan of the capabilities of native CSS and the fact that it keeps getting more capable as time passes, I have come to the conclusion that it is unfortunately a programming language trapped in an “obsolete stylesheet syntax” body, especially after the addition of calc(), variables, functions and multiple ways of conditional logic.
The worse part of working with CSS is that there is no standard static type checking tool (stylelint comes close though). A lot of programming errors should/could be caught at build time.
Sometimes wondering if a completely alternative syntax+tooling is possible that would leverage all the existing capabilities, while using a different language paradigm.
It requires a lot… but a lot less than JS. The awkward declarative nature of it is a side effect of wanting it to parseable at speed.
At an initial look I agree with you that the functions look very awkward. But I thought the same about CSS variables until I started using them and now I think they’re great so I’ll keep an open mind. I almost wonder if they would have been better off calling them “templates”, or something. “Functions” is going to make people think it’s just like JS.
Yeah OK, I see what you mean, I may change my mind once I start using them. And having worked on interpreters and compilers, I can understand the need to keep internals simple and fast - like everything must be parsable in one pass - so the surface ugliness of syntax isn't as important in the long term.
Perhaps I should also be sympathetic to the spec authors, since they're working under tight constraints of language design. Things might look a lot more elegant if HTML/CSS/JS were designed from scratch as a coherent whole.
For small-scale projects, I use a server-side helper for an HTML page to include only certain CSS, SVG, and JS on a page. Each JS file is tiny, progressive, vanilla JS; SVGs are predefined and generate an SVG sprite that I then consume; CSS pulls in a `base.css`, the page's CSS file, and any component ones pull in their own. It's hand-rolled per project (pre-AI being decent), but I'm proud of it, and it keeps every page tiny. HTTP/2 multiplexing is pretty good and downloads the files more or less in parallel.
a) they keep on making CSS more and more complex. You can reason in favour of it, of course, but it is undeniable that CSS becomes more and more complex - and complicated, too. Which leads us to b)
b) "CSS Subgrid is a good example. Subgrid is a super-powerful extension to CSS Grid which enables entirely new layouts."
Well ... I wanted two flexible divs side by side. It is possible, but there are like 5 different main strategies for this, grid is one of them.
Now via a "subgrid", they acknowledge that the existing ways SUCK. So they add yet-another-component here. This reminds us of:
People can hate it, but they work really almost flawlessly. I am not saying I use them for everything, but I totally changed my mind after I saw how flexbox and other things SUCK to no ends. So I now compare all of them to HTML tables. If they suck more than HTML tables, I discard them. This is my quality metric now. And a lot of this has to do with developers making these decisions, failing hard at DESIGN. What happened to simplicity? HTML tables are simple for the most part; they are kind of like a grid already.
this is like the webdev version of the c++ people who love talking about how great the modern version of their language is, ignoring the fact that all the bad stuff is still in there...
remove inheritance and cascade from css and then we'll talk. but for now ill stick to tailwind.
I've done the same for years, and it feels a little bit like the IQ bell curve meme, where on the left and right it is like "vanilla HTML/CSS/JS are all you need."
Smaller bundles, often easier to use, less bug potential. Code's a liability and being able to occasionally rip a bunch out as a feature becomes baseline is always a joy.
I find it is way too complicated with regards to flexbox, grid etc...
Just do a google search for flexible divs side by side. Start with two. Then switch to five. Tell me the solutions that work well.
Y'all know React and Vue frameworks still use HTML, CSS, and JS, right? We're using the same thing, with a thin layer of helpers around mounting components and managing their lifetimes...
On the flip-side I always found javascript frameworks to have a purpose. Though to be fair I don't think I've worked with user facing javascript without a framework since jquery came about. I guess you could call that a library, but still.
Nesting and @layers make maintaining CSS drastically easier than it once was as well.
I sometimes wish that CSS were reduced to the "good parts" and made simpler through it, but I realize that it's infeasible.
Especially functions.
Makes me think of a previous post from the author, who wrote 100k lines-of-code to power their blog.
https://www.joshwcomeau.com/blog/how-i-built-my-blog-v2/
https://youtu.be/0j-Wakm5B84?is=7dU_EvFyk_nQNwjO
It's like a peek into a CSS future from a different timeline. Something we could have had.
It used to be that HTML was for content, CSS was for layout, and JS was for "code"
Now JS is for content and layout and code, HTML is for content and layout, and CSS if for layout and code
Especially CSS is such a miss fitting technology for what it is used today, that web frameworks actively fight it, by trying to keep its scope to components.
When looked at web tech from a distance, it is cristal clear to me that we need something new.
Instead of all the abysmal complicated rules of CSS, we would probably be much better served by something like ElmUI (a modern advanced version of the idea) + some scripting for dynamic things.
If you want them now, you have to do sort of verbose and clunky calculations to get outer corner radius.
[Outer Radius = Inner Radius + Padding](https://www.reddit.com/r/Design/s/oal9fZclJS)
This seems like something standard enough to be a built-in feature.
Anchor Positioning would be sweet and doesn't feel like it's got so much baggage.
All browsers at least have partial support. I've been using it.
I spent 3 months this year testing out a reporting system for large quantities of dynamic data.
My requirement was to generate pdf reports, but didn't want any reporting tools and installations. Especially something like Microsoft Excel, which the old system was based on.
After a lot of tests and proof-of-concept apps, I finally zeroed down to simple, pure, self contained html, that I am generating from a python script.
And it's glorious.
I am generating interactive charts when the html is viewed in the browser, and hiding all of them and only printing static svg images when in print mode, using css media print queries.
And there is so much more.
The format is awesome for ingestion by ai models.
Google said they weren't smart enough to implement it, or pay anyone to fix the one they forked a decade ago.
To me it feels like "programming in YAML", the way a declarative language/format acquires more and more features until you're writing functions in an awkward syntax that was never designed for it.
The worse part of working with CSS is that there is no standard static type checking tool (stylelint comes close though). A lot of programming errors should/could be caught at build time.
Sometimes wondering if a completely alternative syntax+tooling is possible that would leverage all the existing capabilities, while using a different language paradigm.
At an initial look I agree with you that the functions look very awkward. But I thought the same about CSS variables until I started using them and now I think they’re great so I’ll keep an open mind. I almost wonder if they would have been better off calling them “templates”, or something. “Functions” is going to make people think it’s just like JS.
Perhaps I should also be sympathetic to the spec authors, since they're working under tight constraints of language design. Things might look a lot more elegant if HTML/CSS/JS were designed from scratch as a coherent whole.
I always thought that everything from Sass was pretty much ported over by now.
Broad support for new CSS features is GOOD.
Making BASIC SITE FUNCTIONALITY depend upon new CSS features is bad.
a) they keep on making CSS more and more complex. You can reason in favour of it, of course, but it is undeniable that CSS becomes more and more complex - and complicated, too. Which leads us to b)
b) "CSS Subgrid is a good example. Subgrid is a super-powerful extension to CSS Grid which enables entirely new layouts."
Well ... I wanted two flexible divs side by side. It is possible, but there are like 5 different main strategies for this, grid is one of them.
Now via a "subgrid", they acknowledge that the existing ways SUCK. So they add yet-another-component here. This reminds us of:
https://xkcd.com/927/
I started to go back to oldschool - HTML tables.
People can hate it, but they work really almost flawlessly. I am not saying I use them for everything, but I totally changed my mind after I saw how flexbox and other things SUCK to no ends. So I now compare all of them to HTML tables. If they suck more than HTML tables, I discard them. This is my quality metric now. And a lot of this has to do with developers making these decisions, failing hard at DESIGN. What happened to simplicity? HTML tables are simple for the most part; they are kind of like a grid already.
remove inheritance and cascade from css and then we'll talk. but for now ill stick to tailwind.