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 Progress on the web is rate-limited by Apple. If you want that to change (i.e., by Apple facing enough competition that it is forced to staff WebKit above starvation levels), supporting @owa is the most effective thing you can do.
@slightlyoff @syntaxseed I’d also add that it also takes developers to contributing back to standards. It’s not a black box. GitHub was feeding back to Web Standards from the beginning. Exactly what is lacking, and what platform-compatible prototypes are out there—were what browsers asked of my old team the most. GH JS built polyfills, sent patches, demoed how 50 lines of code can be reduced to a one liner if an API was exposed. Things got implemented. The web got better.
@syntaxseed @slightlyoff I would argue JavaScript is vastly different than 15 years ago. Sure all the old stuff still works, but 15 years ago people pretty much used jQuery for everything outside of large orgs like Google.

@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.
@Crell @syntaxseed @slightlyoff This thread is getting a bit all over the place, but I feel like you're definitely missing the point of what Tailwind is trying to do.