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

Perhaps this is pedantic but for someone who seems principled about strictly using standards, markdown itself has no real standard - you'll find wildly different implementations all over the place.

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

Lit is amazing. But I don't like template strings for HTML. The IDE doesn't understand it automatically, and lit jsx had a bunch of issues last time I tried to use it.

In my view, JSX will be the true legacy of React. Applications are code. Many frameworks (such as htmx) extend HTML to bring a bit of programmability into it; but I felt they were just framework-specific, non-standard rules to learn. JSX is more standardized, and isn't as framework dependent.

Shameless plug: Magic Loop [1], a Lit alternative (that nobody knows about) which uses WebJSX [2] underneath.

[1]: https://github.com/webjsx/magic-loop

[2]: https://www.webjsx.org

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.

Not pedantic at all. Markdown is not a web standard, but it enables standards first development by keeping things separate. Nue's Markdown implementation is also very different, much closer to MDX.

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

I think the true legacy of React will be normalizing tight coupling, especially when combined with Tailwind. An entire generation of developers learned to bundle everything into JavaScript - content, styling, behavior, and state all living in the same files. Nue aims to reverse this mindset by showing how proper separation enables more sophisticated systems, particularly once our design systems arrive and you can see the difference. Now it's just words.

Lit and React are quite different, there is no JSX and lit-html is greatly integrated with web standards. I like your approach but if much, your platform makes less use of web standards than Lit, not more.

The straight face is rooted to numbers:

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

Cool, webjsx might be exactly what I was looking for. A simple thing that lets me map state to the DOM to make reactivity easier.

> React will be normalizing tight coupling, especially when combined with Tailwind.

You're skipping the history of why it came to be.

When I started writing HTML, you needed excellently structured CSS because there were no components. So you needed .sidebar, .topbar, .button.ok etc. This was extremely hard to get right. We cannot see the future, and we cannot know what an application will become - figuring out a globally scoped css hierarchy was difficult even for very experienced developers.

Post 2010 (with frameworks like Backbone.js and Angular), people started splitting apps into components. This meant that the smallest unit of reusable design could be a component, instead of CSS classes and JS functions. Adoption of self-contained styling in components increased gradually after Bootstrap brought in utility classes, CSS-in-JS picked up, and Tailwind made it easier.

It made total sense of course, because the component is what you want to re-use. To address your point directly, tight coupling within a component is ok - maybe even a good thing. We did not get there without trying other ideas, we tried them for twenty years.

BEM naming conventions in CSS and splitting HTML into components at the back end template level existed long before JS frameworks and single page applications.

I'd say the big mind-shifts with React were the virtual DOM replacing things like progressive enhancement, and later with Next and server side components, the commingling of back-end and front-end, which is mostly a complicated solution to the problem already created by moving away from progressive enhancement.

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.

We're in a thread talking about "standards first" things, and JSX just isn't a standard part of the web platform, nor is it in anyway standard within the ecosystem of JSX.

JSX has no semantics, only syntax. What a JSX expression means changes depending on the transform you use and the framework you use with it. Some JSX transforms produce values, some produce side-effects. Values produced with JSX under different transforms have different types and are not compatible with each other.

Maybe one day some form of JSX will be standardized, but until then tagged template literals work great with no tools and their behavior is fully determined by the template tag that you use, not an external transform. They're also more expressive than JSX (In Lit we support explicit attribute, property and event bindings rather than overload a single namespace for all 3).

Support for syntax highlighting, type-checking, and intellisense are available to IDEs via plugins and LSPs.

I just want to do a drive by comment to compliment you and the rest of the Lit team on Lit. I love how using a TS compiler is optional, I'm impressed by how fast and pragmatic lit-html is, and how easy it is to understand how it can be fast (vs, say, React's virtual DOM). Lit has a Redis-like quality of simplicity to it, like good Italian food and very much unlike eg React or Vue. I could study the architecture for an hour and feel like I completely grokked how it worked and why.

I can't say I completely love the OO aspect of it (notably the amount of boilerplate it requires to define props), and personally I think Lit would've been more powerful if it were optional for LitElements to be Web Components (having a million nested shadow DOMs by default is, well.. let's say it makes some common pragmatisms like global CSS overrides needlessly hard. also a single global namespace for tag names gets messy fast, and so on). But given the goals you set yourself, Lit is absolutely amazing. Small, fast, easy. Hats off!

Fwiw there's a great VS Code extension for lit-html which (for me) fully solves the IDE support issue. https://marketplace.visualstudio.com/items?itemName=runem.li...

Obviously that doesn't solve it for other IDEs, but back when TS and JSX and ES6 were new they had bad IDE support too.

Magic Loop looks very similar to Crank (that nobody knows about either). Was it an inspiration?

> Nue's Markdown implementation > MDX

The problem with Markdown is there is no standard.

I had this 2017 project called Sailboat [1], which was almost the same thing but for React. I am aware of Crank though, and it's quite nice.

[1]: https://medium.com/@jeswin/sailboat-a-modern-router-for-reac...

This comment is representative of something like a mass psychogenic illness prevalent in the hacker news community.

Which could be roughly summarized as: an absurd and distorted perception of application development for the web, the goals people in that domain are trying to achieve and the history of how we got here.

The real true legacy of react will be bringing functional reactive programming to the masses. Packaging it in a way that a common junior dev could build an intuition around.

Would it make a difference if the example is a single-page application?

Thanks so much for the kind words! It means a lot :)

I was thinking of stencil, but lit is also an option, when I read the title. Meanwhile the creator of nue is apparently working on a static site generator based on markdown?

I don't really know what any given tagged template literal is going to do with its content either. It can also produce a value or run side-effects. The only difference is that the parser now has to be inside the browser, and that has a runtime cost instead.

> In Lit we support explicit attribute, property and event bindings rather than overload a single namespace for all 3

I'd like to know more about this. I don't know what that even means.

Yes. An actual application where 99% of the content is UGC, not big blocks of texts baked into the app, and there's lots of interactive elements.