A standards-first web framework

Lit has indeed done important work in standards-first development through web components.

But the issue is that Lit still approaches web development through the lens of components. While these components may be "standard" web components that encourages developers to keep bundling markup, styles, and behavior together rather than maintaining proper separation of concerns.

Nue takes a different approach by removing all the unnecessary layers between the developer and web standards. Where Next.js forces content into JavaScript components and requires complex build pipelines, Nue provides a more direct development experience built directly on HTML (layout), Markdown (content), vanilla CSS, and vanilla JavaScript.

With Nue HMR completes in milliseconds rather than seconds. The HMR spans css, content, data, and HTML-based server and client-compnents. CSS updates instantly through the native cascade instead of rebuilding components. The entire development feedback loop stays under 100ms, maintaining perfect flow while preserving document state.

Most importantly, this sort of standards-first architecture enables true systematic design trough vanilla CSS. Instead of coupling design decisions to components through utility classes or CSS-in-JS, with Nue you can build design systems directly with CSS variables, calc() and other modern goodies.

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

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.

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

What's your reasoning behind the choice of markdown?

To quote yourself -

> What began as elegant HTML, CSS, and JavaScript has devolved into build systems demanding hundreds of dependencies just to render a page

If HTML is so elegant, why isnt nuejs not using it?

---

On the similar line, if you're so much for web standards, why are you recommending the use of Bun which breaks so much of standards in the name of speed?

I've also been developing web apps since the days of jQuery and Flash. I think there are some interesting kernels here (in particular, emphasizing how much browsers have evolved), but the post brings up older architectures as better (MVC, separating CSS from HTML) without providing arguments for why those were better at addressing current pain points.

Personally, I hated MVC in frontend code. It works ok for backend apps (though I prefer service-oriented architectures more), but it tended to creating arbitrary separations that provided little value on the frontend.

Similarly, I think the separation of CSS and HTML was an illusion 90% of the time. The CSS is always coupled with the html, and having it spread across multiple files just made design updates more error prone. That provided all of the problems with separation of concerns with none of the benefits. You want to be able to update things like fonts, colors, spacing, etc site-wide in either 1) components (which works great with coupling html & css inside of component files) or 2) logical areas (which works great with css themes and variables). Neither of those are due to the separation of HTML and CSS.

I think there are a couple of interesting ideas here, but I'd need to see clearer arguments about why these patterns were actually better on the frontend (and when they fail) to be convinced in this direction.

Repeating this here for emphasis:

>>the web platform itself has evolved to eliminate the need for most framework abstractions.

It is 100% true that modern frontend javascript development is hard. You take your eye off the ball for 6 months, and you lose what's going on. I can understand why casual folks find it difficult to get started.

For instance, a year back everybody was using pnpm. But now you use pnpm thru corepack.

----

I can understand why people yearn for simpler days, but the reality is frontend developement is super-duper nice, even with all the warts. Anyone who is romanticizing the "good old days of jQuery" is being non-serious or has not lived through the pains of that.

---

You cant write a spotify.com or a amazon.com with jQuery and have 100s of engineers collaborate and maintain.

And neither can you with nuejs.

I can answer these questions very clearly once the design systems are released. Now they are just listed with plain text to give you an idea what's coming.

This is about the gap between Figma and React/Tailwind/CSS-in-JS, which is wider than Figma -> CSS

Flutter fundamentally misunderstands web standards and separation of concerns. It imposes a custom rendering engine and widget system on top of the web platform, creating another layer of abstraction rather than leveraging native browser capabilities.

The web already has a powerful "canvas for any screen" - it's called HTML and CSS. Modern features like container queries, CSS grid, and view transitions provide sophisticated responsive capabilities without fighting against web standards.

Flutter's approach is precisely what we need to move away from - trying to solve web development challenges by building on top of the platform rather than understanding its inherent strengths. True standards-first development means embracing HTML's semantic structure, CSS's systematic design capabilities, and JavaScript's proper role in progressive enhancement.

Creating better interfaces doesn't require new abstractions. It requires deeper understanding of web standards and systematic design principles.

Jony Ive specifically has said he looks up to Dieter Rams and his philosophy

Nuejs uses markdown, which is not web. You cant claim to be standards-first, yet use something that is 100% non web-standard.

That is before we talk about their use of 'bun', which is famously my-way-or-highway engine.

I'm glad that you brought up Astro. This is Astro but crappier. It even has "islands", something that Astro has made super-duper popular.

To their credit, Astro authors are humble to tell you that Astro is not a good fit for all usecases, and focuses sharply on blogs, static content with little interactivity.

"standards-first"

"bun"

Choose one.