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
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.
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’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.
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.
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.
You can always have different files for different things but without @layers you'll bump into specificity issues. You also have to arrange your imports correctly or you spend countless hours on "why is this style being applied and not that one?". It's what makes modular CSS (with cascade) actually possible.
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.
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.
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.
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!)
It's because Chrome has taken over interop. Just like they do with any other useful initiative like OpenUI [1].
It feels like Interop was created to curb Chrome's bulldozing various processes with their own internal APIs and development, and to show that there's more to the web than yet another shitty Javascript API. So a lot of Interop is decidedly everything else. See e.g. Interop 2022: https://hacks.mozilla.org/2022/03/interop-2022/
Of course Chrome bulldozed this effort as well
[1] https://open-ui.org/ Started by Microsoft, of all people. Now almost completely taken over by Chrome of course.
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.
Functions might sound scary, but in reality they're used already in CSS processors like SASS/SCSS - and then they actually reduce complexity of the code.
The example with linear-gradient is probably the best use case for them.
He even cites the reasons for that over engineering in the post you've linked?
Also, even before reading the comments, I was pleasantly surprised that everything on that page worked and nothing bothered me. There is a good amount of attention to detail (switching of the rounding on codeblocks when switching to light mode for example, avoiding a weird corner on mobile). Nothing moves around on load etc. I know this is a low bar, but it's gotten pretty rare, even for pages linked on here.
I'm trying to say that his 100k lines might actually be spent on attention to detail and aren't just slop.
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.
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, although fast.
Yeah, people like to talk about how cultish Rust programmers are, but C programmers are so much worse. Just a couple days ago I had one trying to explain to me that all other languages are worse because you don't understand what the machine is doing under the hood. Completely ignoring it doesn't matter because I have a computer from 2023, not 1986.
> Just a couple days ago I had one trying to explain to me that all other languages are worse because you don't understand what the machine is doing under the hood.
Point out to these people that compilers rewrite your code quite significantly so the choice of language matters a lot less than the choice of debugger, profiler, etc.
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.
What's reactivity in this context? How quickly a website responds? My personal experience is that fast backends with server side rendered HTML and a bit of dynamic sections are in practice MUCH faster than SPAs, 20 years after using Gmail for the first time. Gmail then was fast, 95% of modern SPAs are slow.
Reactivity is updating the DOM whenever the underlying data is updated. That's one of the most basic reason for existence of all js frameworks. There's TC39 Signals proposal to bring that natively, but for now as said above the choice is either use a framework or recreate one. It's surprisingly easy nowadays using Proxy.
> Reactivity is updating the DOM whenever the underlying data is updated. That's one of the most basic reason for existence of all js frameworks.
Most web apps and websites do not have that much state variables (even though it may be a lot of data). So while React may offer a small dev speed boost, it’s consumed by the need to build stuff and a whole deploy pipeline to nurse.
Libraries like HTMX and Alpine can take care of most the boilerplate for old style imperative patterns. And backend frameworks like Rails, Phoenix, Laravel donhave their own implementation for data updates.
It’s always been easy to reactively update the DOM. I was doing that in vanilla JS before HTML5 had been formalised.
What the frameworks do is take this concept one step further to create a SPA (single page application) but I honestly think they’re an antipattern that needs to die.
The problems are ownership and provenance mainly, and that all DOM access is slow and requires syncing code internally.
Anyone can write code that tweaks nodes or uses templating, but doing it in a consistent way on a project with hundreds of thousands linea of code is challenging, especially if you also need performance and everyone's least favourite child: accessibility.
Sure you don't get some of this with frameworks, but they help a lot.
Well yeah, obviously frameworks are intended to provide a standard interface for projects that scale. But you’re describing a different problem to the one originally argued.
"State management" is a fancy way to say "your Javascript stores data in variables in some way, which are updated as and when needed".
"Reactivity" means "when those variables change, some generic code already exists to update the DOM instantly". As opposed to writing specific pieces of code to make those changes directly.
Unfortunately, with React, "updating the DOM automatically" generally means: you update the data; React recreates the entire DOM as a new copy in memory; React runs a diff checker to find out what changed from the real DOM; React makes each individual change in the real DOM. With React (or other virtual-DOM-centered alternatives) being used for the smallest of web projects, so many small sites do all that work when the procedure ought to be as simple as: you update the data; you update the DOM directly.
It comes down to inexperienced devs not being able to consider which tool is best for the job at hand, and just hammering nails into every web project in the same way.
I mean all you have to do is change the framework to a better one. Vue with Vapor mode, Svelte, Solid or Preact. These don't have a VDOM at all or use a super fast minimal one.
Signals are basically as fast as writing event handlers yourself but way less fragile and verbose. React is just shaping everyone's impression of all JS frameworks because it's very popular and very slow.
No, it's not, despite what other comments here say. Of course it's possible but you end up recreating React or another library along the way. JS is getting native signals sometime in the future but for now pure JS is not sufficient for a full, complex app.
> you end up recreating React or another library along the way
That's always the trotted-out response, most often recited by people who've read someone else saying it but not had the experience to form an opinion for themselves.
You absolutely don't end up recreating a massive, bloated, slow framework that tries to be as generic as possible to try to be everything to everyone. What you end up creating is a relatively tiny, fast, piece of code that is specific to that site's needs. The difference in size, speed and simplicity tends to be absolutely enormous.
Wrong on both counts. I've worked in companies with vanilla JS only and made parts of those frameworks they ended up building. It is absolutely not "relatively tiny, fast, piece of code that is specific to that site's needs" and once we switched to React we actually saw improvements in many parts of the sites' loading speeds. Next you're gonna No True Scotsman me by telling me the company was just bad but I've seen enough examples at other companies to see that using React or a similar framework is simply the right move.
The joke is that those who react have no idea and those who don't have no idea either. I never use react so I'm going to have to go with: Those other companies are also just bad. (joking) If everyone can work with/without it should be fine? As long as you don't try to do both.
For a large ERP-like back-office where leadership didn't want to use an existing reactive framework, I definitely ended up recreating built on top of jQuery ( at the start of the project IE still needed to be supported ).
Once you start adding dynamic forms for managing multiple items of different kinds, dashboards, error states, i18n, etc, you either end up with a homegrown framework, or with a lot of spaghetti.
Hate to tell you this, bit 99% of apps built with React are rebuilding what has already come before. Namely, taking some information from a database and displaying it on a screen, and taking some input from a computer and putting it in a database.
Almost every web application being built today, framework or no framework, is a variation of a theme. We have no issue recreating those ad nauseum, but we draw the line at recreating a framework?
There are JS libs (like Reactive Mastro [1]) that go well with writing otherwise vanilla HTML/CSS/JS, and there are libs (like React) where you're quickly sinking into a mud of abstractions and have to fight the reactivity runtime when you try to write vanilla JS.
That is an odd caveat to throw on the end. Sure, to avoid frameworks you have to know what you are doing. Is that really such an outrageous expectation?
If people knew what they were doing jQuery, Angular and React would not have existed in the first place. With devs moving companies every two years or so, being able to hit the ground running was very important and you couldn't afford to spend weeks or months learning the idiosyncrasies of your new codebase especially when it came to state management. That's the main problem frameworks and libraries were solving.
> you couldn't afford to spend weeks or months learning the idiosyncrasies of your new codebase especially when it came to state management. That's the main problem frameworks and libraries were solving.
Not really. Frameworks are usually created to avoid boilerplate and provide some nice scaffolding to support you while you’re coding the business layer. And a lot of them do smooth over accidental complexity, even though the architecture is generic and may hinder you in the future.
But the learning curve still exist, as most of what you interact with is custome codes, modules and components.
That's not quite right. jQuery was exactly the right tool for those of us who knew what we were doing. Browser inconsistencies in the early days were practically insurmountable without jQuery to provide a consistent API surface.
> is that really true for reactivity and state management?
No. Use a framework if you want those things. Everything around reactivity, state management, and components have been badly fumbled by the web platform and the various front-end frameworks are far more ergonomic.
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.
I don’t disagree with you and I lurve frameworks. Yes, I love react. It is so awesome.
But it is SO nice to not have any build step. All of my new projects start as a single babashka script now. You got html templating, throw in a stylesheet. Slap a datastar script tag in there for everything else. It’s just easy peasy.
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.
> 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.
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 ;)
If that means having an "HTML+CSS framework" that I could easily swap out for a "Typst framework" and publish my blog using Typst, then sign me up!
Meanwhile, there's Typst bundles [1], still experimental, that implement the same idea backwards: convergint a Typst project into a set of output files (which can be HTML).
They were too slow, people are all tailwind native now and don't know a thing about CSS. I keep seing "full stack devs" complaining about "bleed out" issue, aka C in CSS, cascading
Agreed. I think part of why it's hard to convey is that a lot of people formed their idea of CSS back when flexbox was new. These days an accordion is a few <details>, and a reading progress bar is a fixed div with animation-timeline: scroll(). You don't need JS for either.
Flexbox is still fairly new! Hmm, maybe I'm just old.
While a lot of devs love to use brand-new stuff that's only just been added to some browsers, some of us are not willing when we know it won't work for (almost) all users. The scroll() function is too new for use in production, IMO (but good to know it exists, to revisit after a while). If I have to code something else anyway, or copy-and-paste a polyfill, then why not just use a more robust option in the first place.
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.
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 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.
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.
Imagine a world where we have better technology and someone looks 20 years back at an old codebase. Everybody would have a hard time to understand anything. Everything of the old web tech would look overly complex und laughable overengineered. Nobody would probably be able to understand how a piece of CSS influences a part of a web page or how all the abstractions work in the code base and why they are there in the first place.
Modern web is a mess. I wish it wasn't, but it is.
This is a monkey's paw situation, because instead of the web people are increasingly getting pushed into native apps. I'll take the janky web languages over native apps any day of the week.
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.
Then there are issues with screen readers and how they interact with tables. Tables convey that they are tables, so screen readers treat them as such. Sometimes this means reading headings in between cells to help orient the user, and sometimes it means they'll add numbers for orientation. A bit of detail here: https://dequeuniversity.com/rules/axe/4.1/layout-table
If there are any mistakes in the markup, then it can completely throw off the layout in the accessibility tree without having any visual indication that something is wrong. Perhaps most importantly, tables are very rigid and inflexible, so if trying to do anything more dynamic or out of the boxy flow it usually means messy hacks.
If you're really careful you can sometimes get away with it, provided your site is extremely rigid in layout, but it generally ends in an inaccessible mess that is inaccessible in ways that people don't even bother to document nowadays. Just use flex and/or grid if you're targeting modern browsers. Much easier to author and much better for users.
I wanted subgrid a few years back. Imagine you need to show 3-4 pricing cards next to each other. It can't be a table, the cards have padding, an outline, shadow, etc. Inside they have rows of features. But some of the items aren't just a single line of text, they wrap around, and you need to have the heights of those inner rows align between the cards. It's not possible without a subgrid or some custom JS code.
Apparently, one of the very first proposals for a CSS enhancement was to use Cassowary-esque constraints for layout[1,2].
Think Apple's AutoLayout and similar, but in CSS. I don't recall why it went nowhere (though I do remember the reasons were more political than technical), but imagine CSS without all of the float/flexbox/grid/subgrid/etc crap, but just: `#table-a[width] == #table-b[width];` and so on.
And no need for hacks involving deep `<div>` trees just to get the HTML to cooperate with CSS --- it breaks the whole "HTML is for content, CSS is for styling" premise anyway, when HTML needs to adapt structurally to CSS.
The proposal even had `@import` and `@media` (the latter named `@precondition`) all the way in 1999!
There were some attempts at revivals (e.g. [3]), but they kind of went nowhere. Personally, I'm strongly considering using it for my own (non-web-related) UI library. CSS' base syntax is okayish (the way you define classes, reference elements, etc), and the basic rules like colors or text-related things have warts, but are ultimately okay --- but anything to do with layout is an absolute mess.
> 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
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".
255 comments
[ 0.76 ms ] story [ 23.3 ms ] threadAnchor 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.
Nesting and @layers make maintaining CSS drastically easier than it once was as well.
You can always have different files for different things but without @layers you'll bump into specificity issues. You also have to arrange your imports correctly or you spend countless hours on "why is this style being applied and not that one?". It's what makes modular CSS (with cascade) actually possible.
I sometimes wish that CSS were reduced to the "good parts" and made simpler through it, but I realize that it's infeasible.
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.
It feels like Interop was created to curb Chrome's bulldozing various processes with their own internal APIs and development, and to show that there's more to the web than yet another shitty Javascript API. So a lot of Interop is decidedly everything else. See e.g. Interop 2022: https://hacks.mozilla.org/2022/03/interop-2022/
Of course Chrome bulldozed this effort as well
[1] https://open-ui.org/ Started by Microsoft, of all people. Now almost completely taken over by Chrome of course.
Especially functions.
Make 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.
The example with linear-gradient is probably the best use case for them.
Also, even before reading the comments, I was pleasantly surprised that everything on that page worked and nothing bothered me. There is a good amount of attention to detail (switching of the rounding on codeblocks when switching to light mode for example, avoiding a weird corner on mobile). Nothing moves around on load etc. I know this is a low bar, but it's gotten pretty rare, even for pages linked on here.
I'm trying to say that his 100k lines might actually be spent on attention to detail and aren't just slop.
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."
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, although fast.
I honestly didn't know people like this still existed, with such strong viewpoints on C.
Point out to these people that compilers rewrite your code quite significantly so the choice of language matters a lot less than the choice of debugger, profiler, etc.
GP asked about reactivity. And that still requires some frameworking, either prebuilt or a lightweight self-written one.
Whenever state is updated, the listeners are all called with the updated state and can update the UI and what not based on the new state.
I haven't profiled this and compared it to frameworks, but feels adequate for the relatively simple UIs I've done.
Most web apps and websites do not have that much state variables (even though it may be a lot of data). So while React may offer a small dev speed boost, it’s consumed by the need to build stuff and a whole deploy pipeline to nurse.
Libraries like HTMX and Alpine can take care of most the boilerplate for old style imperative patterns. And backend frameworks like Rails, Phoenix, Laravel donhave their own implementation for data updates.
What the frameworks do is take this concept one step further to create a SPA (single page application) but I honestly think they’re an antipattern that needs to die.
Anyone can write code that tweaks nodes or uses templating, but doing it in a consistent way on a project with hundreds of thousands linea of code is challenging, especially if you also need performance and everyone's least favourite child: accessibility.
Sure you don't get some of this with frameworks, but they help a lot.
"Reactivity" means "when those variables change, some generic code already exists to update the DOM instantly". As opposed to writing specific pieces of code to make those changes directly.
Unfortunately, with React, "updating the DOM automatically" generally means: you update the data; React recreates the entire DOM as a new copy in memory; React runs a diff checker to find out what changed from the real DOM; React makes each individual change in the real DOM. With React (or other virtual-DOM-centered alternatives) being used for the smallest of web projects, so many small sites do all that work when the procedure ought to be as simple as: you update the data; you update the DOM directly.
It comes down to inexperienced devs not being able to consider which tool is best for the job at hand, and just hammering nails into every web project in the same way.
Signals are basically as fast as writing event handlers yourself but way less fragile and verbose. React is just shaping everyone's impression of all JS frameworks because it's very popular and very slow.
But it has no utility
Compute is fine and nearly free
These are just art projects
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.
That's always the trotted-out response, most often recited by people who've read someone else saying it but not had the experience to form an opinion for themselves.
You absolutely don't end up recreating a massive, bloated, slow framework that tries to be as generic as possible to try to be everything to everyone. What you end up creating is a relatively tiny, fast, piece of code that is specific to that site's needs. The difference in size, speed and simplicity tends to be absolutely enormous.
Once you start adding dynamic forms for managing multiple items of different kinds, dashboards, error states, i18n, etc, you either end up with a homegrown framework, or with a lot of spaghetti.
Almost every web application being built today, framework or no framework, is a variation of a theme. We have no issue recreating those ad nauseum, but we draw the line at recreating a framework?
[1]: https://mastrojs.github.io/reactive/
That is an odd caveat to throw on the end. Sure, to avoid frameworks you have to know what you are doing. Is that really such an outrageous expectation?
Not really. Frameworks are usually created to avoid boilerplate and provide some nice scaffolding to support you while you’re coding the business layer. And a lot of them do smooth over accidental complexity, even though the architecture is generic and may hinder you in the future.
But the learning curve still exist, as most of what you interact with is custome codes, modules and components.
No. Use a framework if you want those things. Everything around reactivity, state management, and components have been badly fumbled by the web platform and the various front-end frameworks are far more ergonomic.
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...
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.
Of course you can still write plain CSS.
But it is SO nice to not have any build step. All of my new projects start as a single babashka script now. You got html templating, throw in a stylesheet. Slap a datastar script tag in there for everything else. It’s just easy peasy.
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?
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 ;)
Meanwhile, there's Typst bundles [1], still experimental, that implement the same idea backwards: convergint a Typst project into a set of output files (which can be HTML).
[1] https://typst.app/docs/reference/bundle/
But there is probably a world where what you’re describing is possible with WASM and Canvas. Would need to solve for accessibility though.
dont need to import libraries anymore, can just build my own.
https://nerdy.dev/cascading-secret-sauce
What exactly has gotten good?
CSS is the only area that is seeing improvement, and frameworks ... use the same CSS, so no idea what you're talking about.
Most everything outside of CSS has been and continues to be shit.
(Full disclosure, I wrote a book on this, so I'm not exactly neutral: https://theosoti.com/you-dont-need-js/)
While a lot of devs love to use brand-new stuff that's only just been added to some browsers, some of us are not willing when we know it won't work for (almost) all users. The scroll() function is too new for use in production, IMO (but good to know it exists, to revisit after a while). If I have to code something else anyway, or copy-and-paste a polyfill, then why not just use a more robust option in the first place.
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.
remove inheritance and cascade from css and then we'll talk. but for now ill stick to tailwind.
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.
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.
I always thought that everything from Sass was pretty much ported over by now.
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.
Modern web is a mess. I wish it wasn't, but it is.
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.
Plus making a webapp with accessibility in mind, and I'd like to be aware of footguns.
Linear layout issues come to mind first: https://www.w3.org/WAI/WCAG22/Techniques/failures/F49
Then there are issues with screen readers and how they interact with tables. Tables convey that they are tables, so screen readers treat them as such. Sometimes this means reading headings in between cells to help orient the user, and sometimes it means they'll add numbers for orientation. A bit of detail here: https://dequeuniversity.com/rules/axe/4.1/layout-table
If there are any mistakes in the markup, then it can completely throw off the layout in the accessibility tree without having any visual indication that something is wrong. Perhaps most importantly, tables are very rigid and inflexible, so if trying to do anything more dynamic or out of the boxy flow it usually means messy hacks.
If you're really careful you can sometimes get away with it, provided your site is extremely rigid in layout, but it generally ends in an inaccessible mess that is inaccessible in ways that people don't even bother to document nowadays. Just use flex and/or grid if you're targeting modern browsers. Much easier to author and much better for users.
Think Apple's AutoLayout and similar, but in CSS. I don't recall why it went nowhere (though I do remember the reasons were more political than technical), but imagine CSS without all of the float/flexbox/grid/subgrid/etc crap, but just: `#table-a[width] == #table-b[width];` and so on. And no need for hacks involving deep `<div>` trees just to get the HTML to cooperate with CSS --- it breaks the whole "HTML is for content, CSS is for styling" premise anyway, when HTML needs to adapt structurally to CSS.
The proposal even had `@import` and `@media` (the latter named `@precondition`) all the way in 1999!
There were some attempts at revivals (e.g. [3]), but they kind of went nowhere. Personally, I'm strongly considering using it for my own (non-web-related) UI library. CSS' base syntax is okayish (the way you define classes, reference elements, etc), and the basic rules like colors or text-related things have warts, but are ultimately okay --- but anything to do with layout is an absolute mess.
[1]: https://web.archive.org/web/20140911231410/http://www.cs.was... [2]: https://web.archive.org/web/20140911231410/http://gridstyles... [3]: https://web.archive.org/web/20140907130017/http://gridstyles...
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.