A standards-first web framework

Lots of big claims, including bashing React and this seems to be a framework to build static sites, like blog posts with little to no reactivity?

Also, kinda silly to "appeal to authority" by invoking Dieter Rams. I understand that the author was inspired by Rams work, but this is akin to saying "My new framework is Iron Maiden" because I happen to really like maiden.

(replying to self)

I just checked out the demo site, and now I'm question their design choices as well.

https://simple-blog.nuejs.org/

Nue claims to be minimalist and an outright rejection of everything that is bloated. And yet, this simple page has an obnoxious blur. I get that it kinda looks nice on first load, but click around - the blur happens on each navigation.

This screams form over function if anything.

(replying to self)

I looked at the code, and I'm finding it very hard to take them seriously.

https://github.com/nuejs/nue/blob/4ed9b628f9f307f19bd6dd4d09...

This almost feels like someone taking on a challenge to create a toy framework themselves.

--

While we're at it, since the author wanted to poo-poo tailwind. Com'on https://github.com/nuejs/nue/blob/4ed9b628f9f307f19bd6dd4d09...

Yeah, I was expecting something bigger and more explicit when he went after tailwind. Instead, the author just re-hashed older design patterns (MVC and semantic html decorations from css) without providing context add to when and why you would prefer the older patterns over newer ones. I've been building since the jQuery days, and I totally agree that there are a lot of challenges that people tend to forget from that time. Decoupling html from css just didn't provide much value, but it did create a lot of bike shedding.

I really like how htmx has handled explaining their architectural trade offs. They're very clear about the kind of problem they're solving, how they're solving it, and when/why their solution is better.

This post just has "get off my lawn" vibes without a ton of substance

Agreed - I read the whole thing and I'm not sure what this even is. I guess an SSG and with a design system? If so, all the React bashing comes off like "airplanes are too complicated these days, check out this bicycle".

Edit: after checking the code samples, this looks a lot like svelte (pre-runes). So, single file components with templating with reactivity. I didn't get that at all from TFA..

I like the blur, actually. Well, not that much - it's too much blur.

But I definitely don't like that on top of the blur effect there are scaling animations for each element. I shouldn't be saying this as I'm guilty myself of doing silly things for page transitions in my portfolio, but am working on that.

Nue is currently mostly just for static sites, but as the article states the development is building towards single-page applications too, keeping the idea of separation of concerns at core.

For reactivity, Nue's client-side library provides the same capabilities as React (components, loops, state updates) in just 2.5kb through HTML-based syntax. But crucially, this interactivity is added to semantic content rather than replacing it.

The critique of React is best explained in this document:

https://nuejs.org/docs/

Coupling content, styling and behavior into JavaScript components can easily turn into hard-to-read code that compounds over time. Nue proves you can build more sophisticated interfaces through web standards while keeping codebases lean and maintainable.

This blog is for introducing people to Nue's development model rather than a guide to minimalistic design. See

https://nuejs.org/docs/tutorial.html

The _why_ is extensively documented. See:

https://nuejs.org/docs/

Also FAQ:

https://nuejs.org/docs/faq.html

It's a nice change to see extremely clean html when viewing source though I must admit

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.

Check out the Development Philosophy section on our contribution guidelines to understand the difference on Nue's coding style:

https://github.com/nuejs/nue/blob/master/CONTRIBUTING.md#dev...

NOTE: the document was just updated to match this concern

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.

I think this Iron Maiden argument is best explained on the article, specifically on the section about the design engineering problem.

You should clarify that you just updated that doc, based on the discussion here.

It is kinda disingenuous to say "Check out the doc .." which gives the impression that all of the gaps people have identified in this thread was by design all along.

You're right - I should have been upfront about the documentation update. However, the point about "Less is More" being a fundamental coding philosophy was an important addition that better articulates how this principle shapes the entire framework. Next time, I'll be explicit. Thanks.

Tipiirai, thank you very much for patiently replying all these comments. Tailwind is a terrible abstraction, nobody should be shamed for saying that and the people not used to modern CSS or the ones that can't organize code, well, they should be the ones explaining themselves.

> When you embrace CSS as your primary architecture, you're not just writing styles - you're building a design system.

And

> 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.

Are both super interesting and make sense with a number of changes I've seen in the ecosystem. I respect CSS-focused developers (I'm not one, but I like to dabble) and appreciate a ton of innovation that's coming out of the designer-developers who try to push the boundaries of both the roles and the technology.

The disconnect that remains for me is that client/server state management and scope creep are the two main drivers of sprawling code bases in my experience. Having a bunch of 1-off styles in a component definitely made design updates a nightmare, but tailwind and/or just using CSS variables helped improve that. Using service-oriented architecture (including on the frontend to keep complex business logic out of components), GraphQL + fragments + urql/apollo, and/or Remix (or a similar framework) were all really big steps forward in trying to solve the thorny state management problem. They all come with their own tradeoffs, but that's where most of the complexity and sprawl comes from in my experience.

There's definite bloat from people re-inventing the wheel (forms are the most common one I encounter), but the explanation pages feel like Nue is a panacea. I only see how it improves specific areas rather than the whole architecture. I'll say, I really like how HTMX approached their education around this. Similarly, they're a "use the standards!" kind of library, but they have clear examples of what is solved, and what isn't solved. And their "isn't" includes cases where the current approach is better suited. That makes the scope a lot clearer, which I still feel like I'm missing from the Nue project

ETA:

It's also possible that I'm just not the target audience. Most of the projects I've built or lead have been either extremely event heavy (E.g. using Bluetooth sensors attached to limbs + timers to guide people step-by-step through exercises) or extremely data heavy (e.g. analytics and information collection based on dynamic ontologies). The data model and state management were always multiple orders of magnitude more complex than almost anything else.

Thank you, @meiraleal! The reception here is pretty brutal but expected, especially around CSS. Engineers consistently dismiss its power, no matter how it's presented. However, for those of us who work with design systems, the value is self-evident.

> I've also just never seen the separation of CSS and HTML actually provide practical value.

I would pay really good money to have a library of web components that implemented only the document structure using semantic HTML and the Javascript interactivity, and kept all the styling on a separate CSS file. Something like headless-ui, but without any of the utility classes.

Then we could move on from these template marketplaces (where each dev has to reimplement their own widgets for each different javascript framework), and we would have a simpler marketplace of "Web Component Themes".

Bashing react today is like bashing Java in ~2010.

There are some valid criticisms of react but a lot of them want to throw the baby out with the bathwater, much like with many other mature technologies.

I celebrate people who can produce something innovative in the web development world, but at least produce something before making these grand claims while bashing what came before. Those abstractions are there for good reasons!

And it hijacks my back button. It took two clicks to get back to HN. (Fennec/Android)

I believe the "obnoxious blur" is a common view transition API animation [1]. Astro uses similar as a default [2].

1. https://developer.mozilla.org/en-US/docs/Web/API/View_Transi...

2. https://docs.astro.build/en/guides/view-transitions/#built-i...

More like bashing Enterprise Java Beans?

The only similarity is that it is/was popular to bash both. The reasons for bashing and utility of each are vastly different.

Maybe the Spring ecosystem.

Astro uses a crossfade as the default view transition, as is described in the docs you linked, it doesn't use any blur.

I haven't seen `filter: blur` used for view transitions before, wouldn't personally call it obnoxious, but to each their own.

I think as long as prefers-reduced-motion is respected, its' fair game.

I stand corrected--didn't notice at first. I do prefer the crossfade, admittedly.

And a lot of that bashing comes from people who don't understand React or the ecosystem it's part of.

You should check out Radix UI (https://www.radix-ui.com/). Same idea as headless ui, but it doesn't assume that you will use Tailwind. I _think_ they add css classes to all of their components to allow you to choose any styling method you want, but I'm usually working with ShadCN (which is one level up and uses tailwind).

Though, I'll say that I agree with OP that a lot of functionality already exists within HTML and browsers.

Personally, I only started bashing it in earnest after reading most of its source code.

That feels more like bashing Redux or one of the state management libraries. That's where I've seen a lot of complexity sneak in.

Please dial back the attacks. This is not an interrogation scene in a crime drama.

But Radix UI is still based on React. Maybe someone could take a shot at porting them to "pure" Web Components.

Why? Because the code quality is bad? Or there's just so much code?

I submitted one PR to React like 10 years ago. The maintainers were quite pleasant to work with and it wasn't too hard to figure out what I needed to do.