Comment by mind-blight
Comment by mind-blight a day ago
I appreciate the links. I think this quote from the FAQ captures the disconnect for me:
``` This isn't about rejecting modern development - it's about recognizing that browsers now offer sophisticated capabilities that eliminate the need for most framework abstractions. ```
The problem I have is that I agree with the initial premise, but I disagree with the conclusion. Framework architectures mostly solve different problems than modern web standards.
If you want to go after specifics like 1) just use browser forms and stop re implementing the wheel, 2) you probably don't need a massive state validation library, or 3) stop building CSS features in JS, then I'm 100% on board. But that's not a problem with CSS-in-JS, JSX + render library, components, or many of the other targets you go after.
Things like tailwind (for example) solve fundamentally different problems, and those have more to do with team standardization, avoiding bike shedding, and rapid prototyping. For styling in particular, I don't want to return to the days of crawling through thousands of lines of CSS - edited over years by multiple teams - to find all of the places where different styles impact the specific html component I'm looking at. That's tightly coupled code with loosely defined locations. JSX components just decay less quickly due to encapsulation.
I've also just never seen the separation of CSS and HTML actually provide practical value. It's always been "check out what's possible!" projects like CSS zen garden. Super cool, but that decoupling just doesn't do much in practice.
Like I said, I think there are some interesting ideas here, but I just don't think it's clear why this is a better approach for general web application development (which is the argument you appear to be making).
I'm super curious to see if you prove me wrong, so I'll definitely keep an eye out :). I just don't yet see how the proposed solution solves the identified problems without pulling in a bunch of pain points that were already solved a while ago.
I understand this concern deeply. For developers who've spent years mastering JavaScript patterns and component architectures, the idea of "returning to CSS" can feel like a step backward. They remember the pain points of global styles, specificity wars, and maintaining large CSS codebases.
But this perspective misses how fundamentally different modern CSS development has become. When you embrace CSS as your primary architecture, you're not just writing styles - you're building a design system. You can make typography following certain "musical" scales, colors maintaining precise OKLCH relationships, and spacing flowing from consistent ratios.
It's also about the simplicity in semantic HTML. Consider a real example: a typical React component library might need four different versions of text styling: Text, Description, DialogDescription, and AlertDescription. Each requires its own component definition, TypeScript interfaces, and style declarations. But in a CSS-driven system, this complexity vanishes. A single typographic scale handles all text needs through mathematical relationships.
This systematic approach leads to dramatically less code overall. Where JavaScript monoliths often grow to thousands of lines, a CSS-based system keeps in hundreds.
Nue is of course not for everyone. It's specifically designed for developers who see CSS as a creative medium - who get excited about the possibilities of container queries, custom properties, and calc() functions. For these developers, CSS isn't just a styling language - it's a powerful system for expressing design.