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.
If the rest of you weren’t so stupid, our industry wouldn’t have a problem
This attitude is why we’re all still stuck writing C++ in 2026. Nobody wants to admit that they’re not hardcore enough to write in poorly designed languages so we never make the effort to improve the situation. We all seem to agree that Zig is an upgrade over C. There’s nothing inherently modern about Zig that we couldn’t have written back in 1995 - we just didn’t because nobody wanted to admit that C is frustrating and clunky, albeit fast.
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 ;)
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
> 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.
"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/?
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.
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 optimized interface (gloves, industrial setting) 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 platform-native 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.
I'd love to see this level of customization come to date and datetime-local popups, finding a meaningful path that preserves compatibility with the design languages of various platforms. If and when that happens, it will be because of the work of standardization working groups like Open UI and Interop.
> Because those making the standards only work on creating gimmicks.
Totally agree, but afaik we are a very small minority. My tinfoil hat theory is that all of this is intentional to keep monopolies and making it impossible to compete in the browser space
And I believe the OP is right. Keep people busy working with changes that don’t move the needle, each of the three large platforms wants to lock in the serious use cases into their native apps.
"Functions in CSS" - Bah! That's all we need to make CSS even more convoluted - make it compete with Javascript now ... All these feature creep is just to make sure nobody else can create another browser engine.
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.
I warmed up to CSS this year. Before that it was this cryptic thing with seemingly infinite change-try cycles. What happened was that I discovered some of the new features, and was able to greatly simplify and beautify my CSS. I might end up liking it.
It has this maddening amount of features though, and as it needs to be backwards compatible, this amount can only grow going forward. But if you look at a well chosen subset of the whole thing, it actually is a quite nice language.
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.
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.
Here's another prediction in the ocean of them we're swimming in right now: websites won't matter. When you have a general interface that can present data however you wish, being restricted by the whims of designers will seem prehistoric.
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
I think your definition is off. Js was never for "code". The code itself is just a means to a goal. That certain things better can be achieved without js is good.
Better analogy would be "Microwave ovens were never for injecting electromagnetic waves into food. The electromagnetic waves were just a means to heat the food".
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!
I do not think functions in CSS are the original sin. Why we don’t have them, was a valid question in the 90ies already.
And you cannot emulate functions by using a preprocessor in all use cases.
But what bothers me is the governance model of CSS, the increasing complexity that leads ultimately to more framework usage, not to thoughtful engineering of accessible front ends.
Very soon CSS will be Turing complete and we can have a JavaScript-free C64 emulator. Yay.
We need basically control structures and full access to user input to achieve that.
And we can only hope the vendors get the sandboxing right this time, otherwise we will get a entire new class of CSS based browser exploits.
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.
CSS was born out of the idea that content and presentation should be separate with the former controlled by the author and the latter by the consumer.
Most of CSS's design was informed by that idea. That styling is in separate files in the first place and then all the complicated cascading stuff that is even in the name of the thing.
I've always been fond of that idea and still am but there is no denial that it utterly and completely failed and now we live in a world where all these things are just cargo cult. Sometimes I think it'd be best to finish what Tailwind started and be consequential about it which would mean going back to presential HTML alltogether.
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 hold the opinion that adding anything to CSS is a bad idea. It's already complete, you can do almost everything you'd want in it, and if you can't there's always javascript. Updating CSS forces people to update their browsers and we get that never-ending chase of compatibility. It's just breaking stuff for a little benefit
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.
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.
so funny to start the article with "Interop that all compilers unite to implement together" and then proceed to show features available only in one browser
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.
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.
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.
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 :-)
Yes. We could do those before React and other crap too.
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.
This attitude is why we’re all still stuck writing C++ in 2026. Nobody wants to admit that they’re not hardcore enough to write in poorly designed languages so we never make the effort to improve the situation. We all seem to agree that Zig is an upgrade over C. There’s nothing inherently modern about Zig that we couldn’t have written back in 1995 - we just didn’t because nobody wanted to admit that C is frustrating and clunky, albeit fast.
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 ;)
dont need to import libraries anymore, can just build my own.
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.
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?
But who needs these, when we can have bezel and whatnot...
Who needs ways to reliably trigger the display of the touch platform-native 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.
I'd love to see this level of customization come to date and datetime-local popups, finding a meaningful path that preserves compatibility with the design languages of various platforms. If and when that happens, it will be because of the work of standardization working groups like Open UI and Interop.
Totally agree, but afaik we are a very small minority. My tinfoil hat theory is that all of this is intentional to keep monopolies and making it impossible to compete in the browser space
What does one (CSS tech) even have to do with the other (competition in the 'browser space')?
And I believe the OP is right. Keep people busy working with changes that don’t move the needle, each of the three large platforms wants to lock in the serious use cases into their native apps.
Rage bait, don't engage
It has this maddening amount of features though, and as it needs to be backwards compatible, this amount can only grow going forward. But if you look at a well chosen subset of the whole thing, it actually is a quite nice language.
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.
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.
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.
Same for the README on a GitHub project. Alas, plenty of those are now just voluminous AI spew.
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.
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
“Code” is not a concern like semantic vs style.
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/
And you cannot emulate functions by using a preprocessor in all use cases.
But what bothers me is the governance model of CSS, the increasing complexity that leads ultimately to more framework usage, not to thoughtful engineering of accessible front ends.
Very soon CSS will be Turing complete and we can have a JavaScript-free C64 emulator. Yay.
We need basically control structures and full access to user input to achieve that.
And we can only hope the vendors get the sandboxing right this time, otherwise we will get a entire new class of CSS based browser exploits.
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.
Most of CSS's design was informed by that idea. That styling is in separate files in the first place and then all the complicated cascading stuff that is even in the name of the thing.
I've always been fond of that idea and still am but there is no denial that it utterly and completely failed and now we live in a world where all these things are just cargo cult. Sometimes I think it'd be best to finish what Tailwind started and be consequential about it which would mean going back to presential HTML alltogether.
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.
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.
Google said they weren't smart enough to implement it, or pay anyone to fix the one they forked a decade ago.
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.
Such an uninsightful comment.
> The Anchor Positioning API allows us to anchor one element to another.
Hello CSS, Welcome to 1996 Delphi :-/
I always thought that everything from Sass was pretty much ported over by now.
Just call it like it was: Chrome. It was Chrome that didn't move. We can all see the graph :P
Broad support for new CSS features is GOOD.
Making BASIC SITE FUNCTIONALITY depend upon new CSS features is bad.
remove inheritance and cascade from css and then we'll talk. but for now ill stick to tailwind.
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.