I've come to understand what's happening in frontend's decade-long failure to deliver decent user experiences as a sort of epistemic closure. I'm calling it "frameworkism", and the epicenter is now React.

Here's a lot of words on why we should all reject it, and what the post-React world should look like:

https://infrequently.org/2024/11/if-not-react-then-what/

If Not React, Then What?

Frameworkism is now the dominant creed of today's frontend discourse, and it's bullshit. We owe it to ourselves and to our users to reject dogma and embrace engineering as a discipline that strives to serve users first and foremost.

Alex Russell

@slightlyoff I've being doing this for so long (#webdev). I have an inkling that everytime this conversation comes up and the person doing the "front end frameworks are killing us" cautioning - can't or won't actually recommend an alternative - it's because it will never be possible.

Not until the JS baked directly into the browser stops sucking so badly.

It's bandaids on top of wounds on top of bandaids.

#Javascript

@slightlyoff Until we can write *real*, performant frameworks in Native-JS or in Typescript directly in the browser that have better DOM integration.... we will never escape this.

Userland keeps patching the problem with the next bandaid (frameworks, transpilers, livewire, HTMX, etc).... when only the browsers and the creaking, sluggish, joke of JS browser standards can actually fix it.

Browser tech jumped the shark so many years ago I don't know what the damn hold up is.

@slightlyoff They should take the approach #PHP has taken over the last decade - rapid release of modernizing updates, eventually leaving the old behind.

Honestly I'm shocked with browsers being essentially down to a single monopoly now... why JS is still *almost* the same as it was 15 years ago! 🤦‍♀️

Just fix it #Chromium.... ffs.

@syntaxseed @slightlyoff Browsers have done that with #CSS. I'd argue all CSS frameworks are obsolete now with how far CSS had come. But people still reach for tailwind or whatever, despite it being built for a CSS that doesn't exist anymore.

For JS, same problem but it's React. For #PHP, it's #Laravel.

Once a critical mass of people use something, it's almost impossible to get them to migrate to something better, because the network effect costs are too high.

And here we are.

@Crell @syntaxseed @slightlyoff

You should check out Vanilla Extract to see what a good CSS build system can offer you. Think of it like a superset over regular CSS that gives you more confidence in your CSS because of the type system.

Building on that foundation they offer many variations on how to structure your CSS code.

- Sprinkles: atomic css classes
- Recipes: easy configuration of styles based on component props

https://vanilla-extract.style/

vanilla-extract — Zero-runtime Stylesheets-in-TypeScript.

Zero-runtime Stylesheets-in-TypeScript.

vanilla-extract

@hmiron @syntaxseed @slightlyoff That offers nothing I want, as I don't use TypeScript.

I don't want a CSS superset. CSS is now good enough that it doesn't need a superset. The only pre-processing that has any value anymore is whitespace stripping for better compression, and I'm not even convinced that's worth it these days. 🙂

@Crell @hmiron @syntaxseed @slightlyoff There is one good post-processing, and it is un-nesting of CSS selectors. They break the experience on relatively new browsers in most possibly not so progressive enhancement scenarios.