The Incredible Overcomplexity of the Shadcn Radio Button
Well, this is horrifying.
Frameworks without the framework: why didn’t we think of this sooner? • Svelte
Interesting ideas around front-end frameworks:
The common view is that frameworks make it easier to manage the complexity of your code: the framework abstracts away all the fussy implementation details with techniques like virtual DOM diffing. But that’s not really true. At best, frameworks move the complexity around, away from code that you had to write and into code you didn’t.
Instead, the reason that ideas like React are so wildly and deservedly successful is that they make it easier to manage the complexity of your concepts. Frameworks are primarily a tool for structuring your thoughts, not your code.
The proposed alternative here is to transpile from the idiom of the framework into vanilla JavaScript as part of the build process, which should result in better performance and interoperability.
Related links
The Main Thread Is Not Yours — Den Odell
Every millisecond you spend executing JavaScript is a millisecond the browser can’t spend responding to a click, updating a scroll position, or acknowledging that the user did just try to type something. When your code runs long, you’re not causing “jank” in some abstract technical sense; you’re ignoring someone who’s trying to talk to you.
This is a great way to think about client-side JavaScript!
Also:
Before your application code runs a single line, your framework has already spent some of the user’s main thread budget on initialization, hydration, and virtual DOM reconciliation.
NoLoJS: Reducing the JS Workload with HTML and CSS - Web Performance Calendar
You might not need (much) JavaScript for these common interface patterns.
While we all love the power and flexibility JS provides, we should also respect it, and our users, by limiting its use to only what it needs to do.
Yes! Client-side JavaScript should do what only client-side JavaScript can do.
CSS-in-JS: The Great Betrayal of Frontend Sanity - The New Stack
This is a spot-on analysis of how CSS-in-JS failed to deliver on any of its promises:
CSS-in-JS was born out of good intentions — modularity, predictability and componentization. But what we got was complexity disguised as progress.
The only frontend stack we should talk about
Explore the platform. Challenge yourself to discover what the modern web can do natively. Pure HTML, CSS, and a bit of vanilla JS…
Related posts
Providers
Web browsers provide you with great features for free. Why would you choose to use tools that stop you taking advantage of that?
Reasoning
In which I find a tagline for Web Day Out and a tagline for React.
Progressively enhancing maps
How I switched to high-resolution maps on The Session without degrading performance.
Responsibility
Fear of a third-party planet.
Switching costs
The enshittification of React …which was already pretty shitty for users.