A standards-first web framework

I help maintain Lit[1], which I consider a very standards-first non-framework.

With Lit you can build full apps with standard and plain JS, CSS, and HTML; standard web components; and no build tools.

I don't immediately see how this is any more standards-first, especially when it mentions Markdown, tooling, and a CLI. I don't actually really see what exactly this even is from this landing page. It would help to show something up front.

[1]: https://lit.dev

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.

> But the issue is that Lit still approaches web development through the lens of components

Why is this a problem? Reuse is incredibly important for building almost anything on the web, and it's been with us since long before the web platform supported it natively, e.g. with CGI scripts that used Perl functions, to output repeated HTML "components", or PHP, web frameworks, etc.

If you don't have some method of reuse in the platform or framework, developers either have to copy-and-paste (and deal with so many difficulties of updating and maintaining consistency that it's not a realistic option), or push reuse to a non-standard layer of the system like server templating.

Server templating is fine, but it doesn't actually get rid of the implicit concept of components that'll be in the page or app, it just disaggregates it among to non-colocated parts of the system.

The issue is the coupling of HTML and CSS into your JavaScript code, which is a step away from the standards first development model.

Can you explain how it's not standards first?

Web components can be written in standard JS modules, loaded by or inlined into standard HTML, instantiated by standard custom element tags, rendered with the help of standard <template> elements, and styled with standard CSS.

If you don't use the web platform's native facilities for re-use, then you do have to use some non-web-standard system, like a server framework. Is there some way you see that that's more standard than the web?

In Nue you're literally writing standard HTML, CSS and JavaScript.

Your Markdown- based content generates semantic HTML. Your styling is pure CSS with modern features like nesting and container queries. JavaScript remains vanilla JavaScript.

React and similar frameworks introduce non-standard abstractions like JSX and proprietary component models that deviate from web standards. They couple structure, styling and behavior into JavaScript components.

With Nue your codebase becomes primarily CSS-based, with clean separation between content, styling and behavior. You're working directly with CSS rather than through framework abstractions. Hopefully this FAQ answers most of your questions:

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

> Your Markdown- based content generates semantic HTML HTML is far more expressive in semantics, so using markdown to get html means you will never be able to get most semantic things you actually wanted.

React couples the structure, styling into js components only if you make it so. You can just write style.css, import it and refer to it is classname as `className="my_custom_class"`.

And there is no clean separation of concern when it comes to html, css and js. You can force to separate them, but that would be a separation of technologies, not concerns - they are too intertwined to be separated. And the example of island on the tutorials proves that: ``` <form @name="contact-me" @submit.prevent="submit" autocomplete="on"> ```

There is no way to create a standard-first framework without introducing some form of DSL. This doesnt look like html, this doesnt look like js, and it is def not primarily css based anything.

___ The project is nice, using new features like starting style, view transition - instead of js based solutions is cool. There are a lot of experimental features, like popover api. The browser support is low and those things are not production-ready for everyone (maybe for some).

The approach is good, the site is good, the docs are good, but I dont like the distinction from competitors. Like I can use all those features in react/vue/astro/qwik. What makes you unique? Being able to apply web standard solutions? How about something along the lines - we create better primitives so you can create you website faster/easier?

I think this actually reveals the key misunderstanding. In a properly designed system, most of your codebase becomes CSS - often 90% or more when it comes to content-heavy websites written in Nue. The JavaScript handling pure functionality, HTML expressing semantic structure, and CSS doing the heavy lifting of systematic design and relationships.

This isn't separating technologies - it's letting each part focus on its core concern. HTML focuses on content structure and meaning. JavaScript handles true interactivity. And CSS becomes the primary engine for both design and sophisticated functionality through modern features like container queries, custom properties, and view transitions.

This natural separation produces systems that are both more powerful and dramatically smaller than JavaScript monoliths. The sophistication comes from systematic relationships, not artificial coupling.

> most of your codebase becomes CSS

I dont understand how you're making this claim with a straight face. You're either willfully ignorant, or pretending to be too abstract.

If your understanding on web-development is someone tweaking css values, I think you have a hug gap in your understanding.

You've drank the Apple/Linear/Dieter Ram kool-aid a bit too much, and you think throwing "less is more", "strip it down to the bare minimum" is all emblematic of that.

Good design is about making the complex simple. Not making the simple simple.

The straight face is rooted to numbers:

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

And the example is a blog. I think a lot of us would agree that React is a bad choice for a blog. But React is also used in a million other applications that need a lot more dynamism than a blog does. The idea that 90% of an app like that would be CSS makes no sense.