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.
I nowadays build sites (personal websites and projects) that are much more responsive than most things I see online or on a job, just using modern CSS, a little thinking about how I structure my stylesheets, trying to use semantic HTML and not making a div soup. It works pretty well, if used correctly and given the due attention.
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.
True, though it is also true that achieving good responsiveness was not as easy in the past, say 10 or more years ago, without flex box and grid and without calc and clamp and such.
I nowadays use flex, calc, clamp, min, max, scoped variables, and even display table sometimes these days and it just works so well. Eliminates almost all hacks.
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.
OTH all the complexity ends up baked into the browser where it will be frozen forever (even the shitty/overengineered ideas, like WebAudio). At least frameworks can be discarded and replaced when something better comes along.
IMHO even HTML+CSS should be completely implemented outside the browser in the 'framework layer', but I guess that's not a very popular opinion among the more 'conservative' web devs ;)
> 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.
I did like you asked. The first search result on google is a question on stack overflow. And the first comment provides an example that looks very much like flexible divs, side by side, between two and four based on the width of the container.
My rule of thumbs is: Use flexbox unless it truly is a grid or repeating rows + "I wonder if a flexbox can be used ... ah yes it can."
Flexbox is just made for responsive layouts. It is very good.
"flexible divs side by side" sounds like something which can be generated in many ways, From display: inline-block, over float:left, col-columns, flex layout, to a grid based layout. Can what you desire be created in, for example, https://grid.layoutit.com/?
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
Wow even more fancy border styles! Infinite complexity for useless eyecandy. Date pickers are still barely working, last time i needed to build a touch (gloves, industrial setting) optimized interface with date picker, time picker, and numeric up/down style input fields it needed custom components and js...
But who needs these, when we can have bezel and whatnot...
Who needs ways to reliably trigger the display of the touch keyboard, to be notified if it is displayed and to move the input field in view so it is not obscured by the keyboard?
This is why the web is a terrible platform compared to Windows Forms for getting stuff done. Because those making the standards only work on creating gimmicks.
Good to see Josh writing, especially after his courses have taken such a hit. He is excellent. As an electrical engineer and also now CS grad and someone who has purchased his courses wanting to be able to work across the entire stack.. yet have also thought "thank god I don't really have to learn css" now (yes, due to increasing model performance).
On that note I may know just enough to be dangerous thanks to Josh (casting spells: e.g. shouldn't we group those in their own container and then within that container shouldn't that be a flex box?). I guess I'm here to say humans are full of contradictions.
I know this post isn't about vibecoding frontends, BUT...
Many of my coworkers and friends are rejoicing that they don't have to write frontends anymore. I actually think that frontends are the last thing that should be vibecoded. It's the part that faces the user. It's what helps the user form their first impression of your product. If your landing page looks like it was made in 30 seconds by Claude, they'll assume the rest of your product was too. Use AI assistance on the parts of your codebase where only raw functionality matters (eg, the backend), and put real human effort and care into the frontend that reflects the effort put into the rest of the system.
Shocking take: you shouldn't really vibecode any part of a serious application!
Definitely use coding agents to write code, but carefully and thoughtfully review any important backend or heavily user-facing components of the software you're developing.
everyone is rejoicing the other part of the stack can be vibecoded.
a backend developer would tell you the backend is much more important to focus on, performance, security, data integrity etc. not losing or exposing customer data is a lot more important than what it looks like.
truth is, it's all still important, preferably no one is vibe coding any part of a serious product.
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 agree. And I don't even use layers yet. I keep specificity roughly in mind and narrow my selectors using nesting properly to only affect what I want the rules to style. Do I make mistakes? Sure, but they are easy to fix. Make selectors specific enough and think about whether the rule you are writing is something general or just something for this one component on the page, and it is eeeeasy to not make a mess these days.
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.
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.
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!
> 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
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!)
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.
I built a web app with Claude Code without reading the code it wrote. I only asked for things like "add outer margins to the menu and header, with a transparent blurred background," and it came out the way I imagined.
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.
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.
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.
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.
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.
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.
Thankfully, now that our machine God is here, we don't need to bother ourselves with learning new CSS features. Just feed the article to the machine as part of the spec and it will handle everything.
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.
dont need to import libraries anymore, can just build my own.
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."
GP asked about reactivity. And that still requires some frameworking, either prebuilt or a lightweight self-written one.
Really knowing what you're doing is the implicit part of the right-hand side of the bell-curve meme :-)
I nowadays use flex, calc, clamp, min, max, scoped variables, and even display table sometimes these days and it just works so well. Eliminates almost all hacks.
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.
IMHO even HTML+CSS should be completely implemented outside the browser in the 'framework layer', but I guess that's not a very popular opinion among the more 'conservative' web devs ;)
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.
I did like you asked. The first search result on google is a question on stack overflow. And the first comment provides an example that looks very much like flexible divs, side by side, between two and four based on the width of the container.
https://stackoverflow.com/questions/60615826/two-divs-side-b...
What didn't you like about the solution in that comment?
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.
But who needs these, when we can have bezel and whatnot...
Who needs ways to reliably trigger the display of the touch keyboard, to be notified if it is displayed and to move the input field in view so it is not obscured by the keyboard?
This is why the web is a terrible platform compared to Windows Forms for getting stuff done. Because those making the standards only work on creating gimmicks.
On that note I may know just enough to be dangerous thanks to Josh (casting spells: e.g. shouldn't we group those in their own container and then within that container shouldn't that be a flex box?). I guess I'm here to say humans are full of contradictions.
Many of my coworkers and friends are rejoicing that they don't have to write frontends anymore. I actually think that frontends are the last thing that should be vibecoded. It's the part that faces the user. It's what helps the user form their first impression of your product. If your landing page looks like it was made in 30 seconds by Claude, they'll assume the rest of your product was too. Use AI assistance on the parts of your codebase where only raw functionality matters (eg, the backend), and put real human effort and care into the frontend that reflects the effort put into the rest of the system.
Definitely use coding agents to write code, but carefully and thoughtfully review any important backend or heavily user-facing components of the software you're developing.
Same for the README on a GitHub project. Alas, plenty of those are now just voluminous AI spew.
a backend developer would tell you the backend is much more important to focus on, performance, security, data integrity etc. not losing or exposing customer data is a lot more important than what it looks like.
truth is, it's all still important, preferably no one is vibe coding any part of a serious product.
doesnt mean you tell it: make it look nice.
i find it is great if you want to apply your creativity and ideas.
how to add borders, gradients, animations, positioning, etc.
its a great time for everyone to build things, just how they want/imagine them.
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.
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.
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/
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
Such an uninsightful comment.
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.
CSS has warts, true, but you are not forced to use them. Modern CSS can be brief and clean.
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.
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.
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.
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.
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.
> The Anchor Positioning API allows us to anchor one element to another.
Hello CSS, Welcome to 1996 Delphi :-/
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.
Just call it like it was: Chrome. It was Chrome that didn't move. We can all see the graph :P
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.