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:
@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.
@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
@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. 🙂
> Not until the JS baked directly into the browser stops sucking so badly.
I've heard this before, and while I don't disagree, the goal post for "good js" always seems to be moving.
Granted it's been ages since I wrote front end, one big issue we had was cross browser compatible. It seems that's mostly a moot point. Yet the sentiment remains.
I very rarely like frameworks. I find they are to focused and ridged. They only work when my problem is exactly their problem.
I think "good js" in the browser will always be a moving target.
I think it will be the responsibility of frameworks (or fingers crossed small libs) to do the exploratory work.
@slightlyoff I don't see React adoption reducing at all. I keep noticing so much next.js usage in the job market (SMEs), which is surprising to me even within React ecosystem (I thought esbuild or Vite setup would be top usage).
It's marketing! FB/Meta/Vercel marketing keeps winning, and developers love packaged solutions (which actually is way way over what they need and keeps upgrading major versions every 5 days).
Tremendous article, as always. Thanks for all you do.
"Graciously accept the resignations of PMs who decide managing products is not in their wheelhouse."
I can understand the devs, tech leads etc who are part of frameworkism. But what role do these sorts of PMs even currently play, given that, in some sense, their role should be framework-agnostic...?
Do I just not have a proper conception of what a PM does? Or did the mass layoffs get the wrong folks...?
gotcha - the issue is not that the PMs are explicitly frameworkists themselves, but that they're not actually managing/holding to account the frameworkists.
(Which, I suppose, makes them frameworkists...)
Thanks!
@slightlyoff The link here for MPA view transitions is wrong (its the same as the one just above it)
@slightlyoff Also, the link to the Harry Frankfurt - On Bullshit essay seems to be dead. Here's one that hopefully will live longer
@slightlyoff Great comprehensive work!
I know some companies, which are highly invested in React and SPA architecture for quiet well-taken for that web applications, but then for another simpler almost content -only web pages they again use the same stack because of the already developed React-based UI kit.
So, it's another portion of logic behind such decisions.
@slightlyoff also not sure that provide alternatives for React Native as Cordova and another web-based solutions is performance wise. Especially in the light of migration of React Native to the new interop-based architecture. Yep, it has JS bloat overhead, but still on top of native components.
But it is only true if we develop React components deligently, otherwise your mobile application with all your native components will strive because of JS side and drain battery enormously.
@maphew @dotstdy And it doesn't even work! I sit with *so many* teams that are beached on the shores of unshippability because their "move fast" stacks only provided a one-time burst of acceleration, rather than sustainable gains in velocity and momentum.
Adding the time folks have to spend remediating these made-up problems to the cost side of the equation makes these "move fast" systems look like what they are: irresponsibily marketed tools for experts in the hands of n00bs.
@slightlyoff This prompted me to think a bit more of how bundlers play a role in the bad perf outcomes of frontend projects, and my conclusion is that they currently are like power tools without appropriate safety features:
https://hachyderm.io/@fvsch/113583490410827935
(also cross-posted on bluesky: https://bsky.app/profile/fvsch.com/post/3lcd7taxvh22i)
Spicy opinion: JS bundler authors have messed up big time by growing the ability to add JS code to websites without providing similarly powerful tools to control how, why and by how much you add code (let alone to help you drive numbers down). Great power with no responsibility.
@joshavanier Remember: the important thing isn't the framework, it's the chance switching gives you to rethink architecture and values.
Bonne chance!
Could you explain “epistemic closure” cuz I can’t find a signified to that sign.
Alex Russell
Sherri W (SyntaxSeed)
Mu-An
Bryan Haskin
Larry Garfield
Miron 🇪🇺
Aleš Roubíček
Brammm
Ukiah Danger Smith
Joeri Sebrechts
Luc Heinrich
Florens Verschelde
Munawwar Firoz
nickchomey
Matthew
Rimu
Rouven Malecki
Aleksandr Shoronov
Josh Simmons
Seth Larson
matt wilkie
Alyssa Coghlan
OliverUv
Daniel Barlow
mathew
Almad
PuercoPop
Mike Mathew
bmac
Ben
It's a me, Mauro
Patrick Johanneson 🚀 🇨🇦
joſh
Steven G. Harms