Author here: this is Nue's new, more natural direction. Our previous focus on design engineers and CSS design systems was accurate, but missed the most important point: the web platform itself has evolved to eliminate the need for most framework abstractions. What began as elegant HTML, CSS, and JavaScript has devolved into build systems demanding hundreds of dependencies just to render a page.
This is a long term, ambitious project to strip away these artificial layers and return web development to its core strengths. Instead of fighting web standards, we're taking them to their absolute peak.
Yep, I rewrote my OSS Dropbox like frontend for every file transfer protocol in vanilla JS [1], so far it's not only faster with smaller memory footprint, the app is faster to boot, lighter in size despite the optional build system, there is no framework code I don't know about running at the worst possible time and I can effectively run to the maximum of what a browser can do.
It's refreshing to be able to open the network tab and see the original files coming out [2] and the developer console showing the full structure of it untouched in the same way it's visible from github.
This has opened new doors that was previously closed with any kind of framework, the option to dynamically patch those js file at runtime to customise the interface for unique needs that make sense for someone but wouldn't make sense for 99% of everyone else. Now it's just a matter of submitting a small plugin patch that do it and tada, a happy customer while maintaining only a single codebase
> Do you think the code can be extended and maintained by someone other than you? How about a large team?
There's no track record of it but I believe it would be ok in the right team. The core idea was stolen from every other frameworks: "build your app as a tree of components". In the approach I went with, components are modular and expressed like this:
in practice, a working code loading another component would be:
```
import FooCompoment from "./component_foo.js";
export default function (render, props = {}) {
const $node = createElement(`
<div>
<div data-bind="component_foo"></div>
Name: ${props.name}
</div>
`);
// render the component with an animation
render(transition($node));
// render a child component
FooComponent(
createRender($node.querySelector(`[data-bind="component_foo"]`)),
{ ...props },
);
}
```
The syntax is arguably less nice than JSX but the upside is 0 running cost and the idea around decoupling components remain. A lot of people have argue that I just end up maintaining my own framework but the reality is what would be considered "framework code" fit under 200 lines of code ....
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.
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?
In Nue you're literally writing standard HTML, CSS and JavaScript when developing websites. Your Markdown- based content generates semantic HTML. Your styling is pure CSS with modern features like nesting and container queries. JavaScript remains vanilla JavaScript.
I'm not literally writing" standard HTML, I'm literally writing Markdown and the tool you've yet to fully realise is generating* HTML from the Markdown I'm literally writing.
The issue here is that the GP probably doesn't consider writing content to be related to developing the website.
Which is fair. It's one way of looking at it. Once, a really long time ago, I made a website (e-shop) where the content was written in an XML file, sliced and diced by XSLT via a little PHP script. My job was to write the (X)HTML for the layout and XSLT for data extraction - the content was something my client provided. If they provided the content in Markdown, I'd use markdown-to-html converter instead. Crucially, if I were provided with content in HTML, I'd also handle it (most likely not by directly pasting it into the page, though). I'm sure you can change the format in Nue trivially and write your posts in HTML if you want (right, @tipiirai?)
Not technically, but they sure don't have to make it easy. Getting an element reference is clearly not the optimized-for use case. The docs even warn against it.
> Refs are an escape hatch. Manually manipulating another component’s DOM nodes can make your code fragile.
Come on man. Be serious for a second. Have you ever even taken a look at the WebKit or Chromium codebase? Whatever it is that you're doing here is so far removed from "the metal" that I doubt you have ever shipped anything that actually needs a compiler if you're writing stuff like this.
Nice work. I've been following Nue for a while now. Stripping away (obsolete) abstractions in favour of what the web now can do natively is liberating.
But Nuejs claims to be standards-first. The entire premise of the framework is "All these other frameworks bring their own stuff, and have lost the plot on how beautiful HTML, CSS and JS can be", and then they turn around and use Markdown (not-standard), cli (not standard), bun (not standard).
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.
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.
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
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.
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".
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.
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.
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.
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..
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:
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.
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!
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.
This article is extremely well written and energizes me... Having a framework that allows separating the graphical work from the logic would be great. But I have trouble imagining this idea passing the brutal test of production -- except for showcase websites and blogs. I'm specifically thinking about apps (linear?)
But
I'm looking forward to seeing what comes next and hope to get more information when the templates arrive :)
You're not alone! The feedback form shows overwhelming relief from developers tired of complexity. Single-page applications will be the true test of the standards-first approach, as that's where the contrast with current practices becomes most stark.
I think this sounds exciting. As a backend eng (who prefers Htmx) and someone who totally struggles with css, reading your intro made me walk away feeling dumber than before. Again not expecting an ego boost or anything. Something that felt counter intuitive:
1. Lack of drawings hurt - I had no idea what zaha or rams meant. You had bold text which I thought were links but alas they were just bold text.
2. I actually appreciate math and still wasnt sure how I could use math in the new proposed framework (id kill for a constraint system that was similar to what iOS had).
3. +1 on the crazy level of complexity in today's frameworks (which is why I hate using nextjs etc) but perhaps some code samples (even if proof of concept would have helped) would have been helpful.
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.
I guess it doesn't take much to entertain frontend devs, but I'd lose my shit if I had to relearn a new shape for the wheel every 6 months. A Sisyphean existence: one must imagine the webshit happy.
And consider that amazon.com was launched in '95, so yeah, you don't need the latest JS framework to build an empire.
The truth is that 90% of tech is about chasing trends that the people who succeeded have set. It's not because the core ideas have merit or are successful. It's because Facebook did it, so we have to do it too (even though we operate at 1/10000th of the scale). No further reasoning needed, everything else is driven by the hype.
Don't believe me? Just look at the state of LLMs. They're solutions looking for problems and the entire world is eager to waste billions in the process of figuring out that LLMs are not good at factual reasoning.
> You cant write a spotify.com or a amazon.com with jQuery and have 100s of engineers collaborate and maintain.
True but you can write a Spotify or Amazon that ten developers maintain.
We have a huge problems with cargo culting what big tech monopolists use when small teams have fundamentally different needs and would be more productive with smaller tools with less overhead. Though of course the fancy stuff looks better on a resume so can't really blame the devs.
True - As a FE noob I am definitely not asking for the olden days. I do lament often CSS just does not feel intuitive for me and it could be just being used to iOS layouts or more old school layouts (think Swing, Android etc). What made it worse for me was the 18 generations of css philosophies (use classes, use css files, inline, dont inline, and repeat). I wasnt sure if Nue was promising this - but if I can go to one way of doing CSS that lasts more than 2-3 years Id be happy :). Same with frameworks. I can pickup iOS development after not having done it for almost 10 years. I just dont have this confidence with webdev. Heck I moved out of Nextjs to htmx (though I liked the ergonomics in the former and this is not an endorsement of htmx) was because an app I had left in maintenance mode for 6 months started breaking builds out of no where when I had to add a small feature.
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.
Hey sorry for the noob question. I wasnt actually sure what you meant by design systems - Is there actually a level of "understanding/expertise" one needs to have to just "get" it? For context even though I am not an FE eng, I have built apps and sites (using nextjs, tailwind, bootstrap, vanilla html, css, jquery, htmx - not all of them together). Again I am not an expert in CSS (i really suck at it) but il put together something that works.
> The gap between design and engineering has never been wider.
This seems like such a weird claim to make. This used to be "here's a JPEG, you may beg for the PSD". Not saying that there's no gap today but... never been wider..? Am I missing something about the typical Figma setup that makes it worse than a random JPEG export of one state of the UI?
I probably won't ever use this but the docs look really nice. Specifically: the header combines a blurry backdrop filter with something like `background: radial-gradient(transparent 1px, white 1px) center / 4px 4px` to make a background of transparent dots.
I like the attitude in general although it does come across a bit arrogant, the goal seems to be a noble one.
I can't really tell what it currently offers over Astro, it does seem to be a static site generator with a couple of nice tricks, I feel like Astro has perfected this.
I don't think it's any more "standards first" than Astro, or am I missing something?
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.
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.
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.
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:
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.
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.
> 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.
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.
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.
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.
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.
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.
> 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.
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.
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 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.
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!
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?
Well, you can be as firm as you like about the claim, it's still reads as if Dieter Rams worked for Apple.
Dieter Rams no doubt had significant influences and admiration for those who shaped his work and design philosophy, should we credit those people as being behind Apple also? How far should we go? Perhaps we need to point out da Vinci is also one of the men behind Apple's design philosophy.
Seems reasonable to suggest "the man behind" is generally understood to mean "the person directly responsible for".
Everybody who is so upset about the proliferation of so many heavily abstracted, complicated JS frameworks should probably recognize for a moment that we have a horrible backwards compatibility problem with HTML, CSS, and JS. None were ever designed with the idea that they could support apps like freaking Netflix for Smart TVs or React Native apps for virtual reality.
If you want a truly standards first UI development stack, try Flutter. It critically changed how I view UI development: 1 canvas for any screen. Truly a beautiful thing.
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.
So how do you write a mobile app with HTML and CSS? Or a TV app? Or a car app? Or a watch app? Or a VR app?
The “one simple standard” falls apart when you need multiple platforms.
And honestly the document and document styling model wouldn’t work very well for these platforms.
Everything from “center a div” to “pinterest style masonry grid” is 100x easier in flutter.
Also, flutter is not “another abstraction” on top of web. The widgets don’t map to DOM elements at all. It is a completely orthogonal approach. All of the other web frameworks are indeed abstractions, but flutter is not.
Just curious, have you used flutter before? My impression is that you would like it because there is actually less abstraction. A widget just represents a paintable object on a canvas without any more indirection than you give it.
Do you have any favorite Flutter projects I could click around? It’s an intriguing concept but I’ve been offput thus far by Google’s lack of adoption of its own framework.
Yea this is the same as GCP - Google doesn’t use their own public cloud offering. But that’s an organizational decision I don’t know anything about. Sonos app is a popular flutter app that made some news recently. Google earth as well. I think they have a showcase.
I want to address Markdown and it's role in standards first development.
While MD itself isn't a web standard, it's a strategic choice that reinforces standards-first development by generating pure, semantic HTML. This creates a natural separation between content structure and visual presentation.
Consider the impact on CSS development.
In React codebases, engineers spend 90% of their time writing JavaScript - managing state, coordinating effects, optimizing builds. Style sheets become an afterthought, buried under framework patterns and utility classes.
Nue flips this ratio: codebases become 90% CSS, focusing engineering effort on systematic design through web standards. By keeping content in Markdown and presentation in stylesheets, we maximize the power of native CSS features - from custom properties and container queries to mathematical relationships for typography and spacing.
This shows a lack of understanding of what a modern webapp is meant to be. Again, your framework is a attempt for static blogposts & other non-interactive/minimally intercative sites. Modern javascript developers build complex webapps, whether you like it or not.
You think stripe.com (webapp) engineers are spending 90% of the time tweaking css?
In content-heavy websites, yes. Single-page apps are a different game obviously. this is a real number when comparing Next.js blog starter to Nue's blog starter:
> In content-heavy websites, yes. Single-page apps are a different game obviously.
Content-heavy websites have (for me anyway) multiple acceptable solutions currently.
I want to see what your DSL looks like for SPAs.
To be clear, I am your target - developer who noped out of JS frameworks and want something better.
But, like I said, I already have multiple options for separation of concerns with content-heavy or mostly-static sites. What I don't have is a decent SPA framework that neatly does separation of concerns.
There are, of course, many different flavours of Markdown. Which do you use? The best thing to come out of Markdown is probably Djot, which is inspired by Markdown but just different enough to not really be considered a flavour of Markdown. The designer, John McFarlane, put a lot of thought into it, and designed it to be easy to parse.
> What began as HTML, CSS, and JavaScript has devolved into a complex build orchestration demanding hundreds of dependencies, even for a simple page.
I’m no react fan boy, but this is a total straw man. Vite and the like make builds dead ass easy. Also, to try to represent the days before react as some kind of utopia is total horseshit. I have been doing front end for just as long as the author (nearly 20 years) so I lived through that stuff. It was total chaos before. Just gobs of unmaintainable shit. No tests. No reusable code. Nothing. Does react have problems? Yes. Do people use it when they shouldn’t? Also yes. But the whole “it’s too complicated to get it to build” argument is tired.
In most cases, though, there will inevitably be some blurring between the layers, your back end will be coupled to the data model somewhat and the front end will then be coupled to that, both the design, layout and functionality, unless you attempt to build a library or a framework that's detached from a specific project/domain.
For example, even Vue lets you extract your layout into a separate component and then fill it in with slots https://vuejs.org/guide/components/slots.html but nobody ever does that because that'd take more time and they end up just having BasketComponent instead of BasketLayout and BasketComponent, same for not trying to detach the styles from specific components, nobody wants to do that.
React has it's problems, but for me one of the most appealing things is doing away with this magic attribute sprinkling that is a maintenance nightmare and just going all in on JSX.
> The core issue, however, is the inability to participate in the actual craft. Design decisions are buried in React components with cryptic expressions like flex items-center shadow-lg p-6 hover:bg-gray-50 dark:bg-gray-800 py-[calc(theme(spacing[2.5])-1px)]. This might make sense for JavaScript engineers, but it's an insult to systematic design.
@tipiirai your measured and patient responses in this thread are impressive to witness. It's bloody hard to not come back fists swinging when you're dealing with this level of resistance, regardless of why. <Chapeau />
It is interesting, but I really dislike the way it tries to bash every other tech in the blog post, on the homepage and in the docs itself. The tone is very confident, but it will put you open to a lot of scrutiny.
Instead it could really use a lot more explanation on how it works. If you make comparisons make sure they are fair. The image "JavaScript mixed together" and "Strict separation of concerns" is just comparing apples with oranges. Multiple times in the docs it compares a huge complicated JSX like component and replaces it with 3 lines of html and 3 lines of css. I don't believe that it does the same thing.
Some of the claims are strange. It praises standard HTML but apparently you have to use some custom Markdown syntax to write it. How does that add up? And on top of that it also introduces new syntax for loops and variables.
This could all work perfectly fine. But my suggestion would be to talk more about how it works and what are the advantages and less trying to bring down competitors. It could use less grand claims and focus more on what it really does.
> Multiple times in the docs it compares a huge complicated JSX like component and replaces it with 3 lines of html and 3 lines of css.
I've seen my fair share of React code, and the code he is displaying is definitely idiomatic React.
> It could use less grand claims and focus more on what it really does.
Agreed. While I appreciate that a rationale is needed for something like this, I think his presentation of the rationale was far too verbose compared to diving into some code.
Maybe I'm not the target - I would have preferred more code and less pontificating, because I 'noped right out of React and others. What I have as a replacement in standard JS, HTML and CSS is unsatisfying to me.
> the code he is displaying is definitely idiomatic React
It's really not. There's nothing, for example, stopping you from using <dialog> in React. It works perfectly fine and can integrate with any state or event manager if you want it to.
What he's doing is comparing brand-new web features that don't have good support yet with long-standing solutions that were needed years before those web features were a glimmer in anyone's eye.
You're missing the main point that OP is making: TFA's complaint with these patterns isn't that it's React, it's that it's not using the modern tooling. That is true, but could just as easily be an argument for updating old React code bases to take advantage of the new features. There's nothing inherently React about avoiding using them, it's usually done because of some combination of lack of knowledge of the changes and a need for various reasons to support old browsers. (Yes, a lot of real world use cases still require supporting versions of Safari older than 15.4 [0]).
It's not fair to take these legacy patterns, which are what made React and friends so much better than the other options that were available at the time, and compare them to features that were specifically built with the intention of making those patterns no longer necessary.
Once those new features are supported on most devices (which again, they aren't in many cases) I'm excited to see them incorporated into code bases written in any framework.
Yeah there is a lot of idealism in the project - problem is reality doesn’t care about your idea of separation of concerns and most likely your web applications will not benefit from it.
What I mean React and other frameworks went with mixing concerns because of reasons that were practical - for example realization that usually one dev implements HTML and JS code in one task, not like article comes up with designers and devs. In reality lots of designers don’t live in agile sprints and the same repositories as devs there is huge impedance mismatch.
Usually one does not design a page like website but reusable components that will have its own context and content.
Designer might focus on broad scope how stuff fits in a web app.
That pop-up to edit “task” has to behave the same on 20 different views.
Widget showing task details will probably be integrated also in some far removed place.
That is whole different game that this “standards focused framework” is not addressing and that game was addressed by whole bunch of frameworks that this article nags about.
The "separation of concerns" point is very overblown, IMO. It seems to have become a slogan repeated without considering what the goal is, and just completely dismissing components as another valid way of organizing code.
Components have won for a reason - for any given web-based UI component to work it needs to render HTML, to style that HTML, and logic for rendering and behavior. So HTML, CSS, and JS.
It only makes sense to colocate those things so that they're easier to build, understand, distribute, and use as a unit. Often times they're not even separable as the HTML depends on state and logic, etc.
And the weird thing is that any other UI platform has components that combine rendering, styles, and logic together and no-one bats an eye because it would be very odd and cumbersome to do it any other way, but on the web some people think components are bad. And they tend to provide no realistic mechanism for reuse except to use an external system.
> I don’t need a framework to make documents - I need framework to make web applications that is why components won so I agree.
I just realized how little "content" my app has. So Nue's focus on these psuedo-Markdown documents is extra worthless. If 99% of the content is coming from the database, what would even go in these docs?
It's the same at the big tech company I work at. Yes we have technical writers and UX and all that, but all the bits and bobbles of text are like 1-line long, so they go into some funky template with all the random strings and then some tooling picks them up and the translators use a custom UI to translate them. None of these folks are working directly in the codebase, nor do I think they should.
The "separation of concerns" is often misunderstood, and historically people were treating html, css and js like they were completely separate beings, which is of course a recipe for disaster [0].
However, what I'd like to see is separation between logic and presentation. In React world people used to call them dumb and smart components. Then you can use stuff like storybook to gauge your layout before applying "business logic" to the application. On top of that you have an easy way to test your "smart" components.
[0] like that time when I saw an org that decided to be "cloud agnostic" and people started pushing their own databases and http servers to AWS. :)
I think all of their criticism of the current web ecosystem is valid... And I'd rather have someone take a big swing than marginally improve the React ecosystem.
You could deploy HTMX on top of any static site generator and get literally the exact same experience? Your portrayal of any of this as 'novel' just comes across as naive. The technology already exists, I agree its underutilized, but this could have been an advocacy post instead of reinventing wheels that are already quite well made.
HTMX is more like "jQuery on steroids", but Nue is a frontend development framework with universal HMR support. Think Next.js but slimmer. Different tools for different needs.
You may have already added this in other locations, but it's worth flagging in each comment that you are the creator. I had a suspicion from your tone, but I had to check your bio to be sure.
And, while on the subject of tone: this is not a very effective way to receive constructive criticism. I had exactly the same reaction as OP, as did apparently a lot of upvoters. Communication is a two-way street, but when a significant number of people misunderstand you or can't find the information that you think you put out there, it would be worth listening to them to figure out what you could do to better communicate.
In the end, most people wouldn't even notice or care if they didn't fully appreciate your project— you are the one who is invested in people appreciating it, so it's up to you to take responsibility for the way in which it's communicated. It's not useful to blame other people for failing to understand your docs.
> "JavaScript mixed together" and "Strict separation of concerns" is just comparing apples with oranges
I feel this this comparison reveals how deeply framework thinking has shaped our understanding of web development and how thoroughly we've accepted JavaScript monoliths as normal.
Why have we normalized a world where marketing pages need a JavaScript monolith with mixed content? Why do we consider utility classes more "maintainable" than systematic design? Why must every solution flow through JavaScript when browsers provide these capabilities natively?
I have tremendous troubles explaining these things to engineers, who constantly turn the discussion into technical, low-level details instead of looking at the bigger picture. Any suggestions how I should approach this? Thanks in advance!
218 comments
[ 3.3 ms ] story [ 361 ms ] threadThis is a long term, ambitious project to strip away these artificial layers and return web development to its core strengths. Instead of fighting web standards, we're taking them to their absolute peak.
Happy to hear your feedback.
>>the web platform itself has evolved to eliminate the need for most framework abstractions.
It's refreshing to be able to open the network tab and see the original files coming out [2] and the developer console showing the full structure of it untouched in the same way it's visible from github.
This has opened new doors that was previously closed with any kind of framework, the option to dynamically patch those js file at runtime to customise the interface for unique needs that make sense for someone but wouldn't make sense for 99% of everyone else. Now it's just a matter of submitting a small plugin patch that do it and tada, a happy customer while maintaining only a single codebase
[1] https://github.com/mickael-kerjean/filestash
[2] https://demo.filestash.app/login?type=s3&access_key_id=Q3AM3...
When I look at the contributors, I see abysmal contribution from other people.
https://github.com/mickael-kerjean/filestash/graphs/contribu...
----
What works for one disciplined (and talented) developer such as you might not work at scale.
There's no track record of it but I believe it would be ok in the right team. The core idea was stolen from every other frameworks: "build your app as a tree of components". In the approach I went with, components are modular and expressed like this:
in practice, a working code loading another component would be: The syntax is arguably less nice than JSX but the upside is 0 running cost and the idea around decoupling components remain. A lot of people have argue that I just end up maintaining my own framework but the reality is what would be considered "framework code" fit under 200 lines of code ....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.
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?
which is totally non-standard. Super common, but non-standard. You compiled the markdown to html using a tool (another non-standard item)
You dont get to claim "standards-first" framework and then use non-standard technology and workflow.
Which is fair. It's one way of looking at it. Once, a really long time ago, I made a website (e-shop) where the content was written in an XML file, sliced and diced by XSLT via a little PHP script. My job was to write the (X)HTML for the layout and XSLT for data extraction - the content was something my client provided. If they provided the content in Markdown, I'd use markdown-to-html converter instead. Crucially, if I were provided with content in HTML, I'd also handle it (most likely not by directly pasting it into the page, though). I'm sure you can change the format in Nue trivially and write your posts in HTML if you want (right, @tipiirai?)
> Refs are an escape hatch. Manually manipulating another component’s DOM nodes can make your code fragile.
https://react.dev/learn/manipulating-the-dom-with-refs
Huh? `ls -l | grep '^d' | wc -l`
> 18
You need 18 dependencies to generate a page?
`touch index.html`
If you want to go back to elegant HTML, CSS, and JavaScript, it's right there. You don't need bun and whatever this is to use it.
The absolute peak of using web standards is to just open up either the either the W3C or WHATWG specifications. That's it.
> https://nuejs.org/vision/
> Closer to metal.
Come on man. Be serious for a second. Have you ever even taken a look at the WebKit or Chromium codebase? Whatever it is that you're doing here is so far removed from "the metal" that I doubt you have ever shipped anything that actually needs a compiler if you're writing stuff like this.
That is before we talk about their use of 'bun', which is famously my-way-or-highway engine.
But Nuejs claims to be standards-first. The entire premise of the framework is "All these other frameworks bring their own stuff, and have lost the plot on how beautiful HTML, CSS and JS can be", and then they turn around and use Markdown (not-standard), cli (not standard), bun (not standard).
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.
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.
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...
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
https://nuejs.org/docs/
Also FAQ:
https://nuejs.org/docs/faq.html
``` 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.
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.
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.
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".
Though, I'll say that I agree with OP that a lot of functionality already exists within HTML and browsers.
https://github.com/nuejs/nue/blob/master/CONTRIBUTING.md#dev...
NOTE: the document was just updated to match this concern
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.
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.
https://nuejs.org/docs/tutorial.html
1. https://developer.mozilla.org/en-US/docs/Web/API/View_Transi...
2. https://docs.astro.build/en/guides/view-transitions/#built-i...
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.
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..
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.
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!
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.
1. Lack of drawings hurt - I had no idea what zaha or rams meant. You had bold text which I thought were links but alas they were just bold text.
2. I actually appreciate math and still wasnt sure how I could use math in the new proposed framework (id kill for a constraint system that was similar to what iOS had).
3. +1 on the crazy level of complexity in today's frameworks (which is why I hate using nextjs etc) but perhaps some code samples (even if proof of concept would have helped) would have been helpful.
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.
And consider that amazon.com was launched in '95, so yeah, you don't need the latest JS framework to build an empire.
The truth is that 90% of tech is about chasing trends that the people who succeeded have set. It's not because the core ideas have merit or are successful. It's because Facebook did it, so we have to do it too (even though we operate at 1/10000th of the scale). No further reasoning needed, everything else is driven by the hype.
Don't believe me? Just look at the state of LLMs. They're solutions looking for problems and the entire world is eager to waste billions in the process of figuring out that LLMs are not good at factual reasoning.
True but you can write a Spotify or Amazon that ten developers maintain.
We have a huge problems with cargo culting what big tech monopolists use when small teams have fundamentally different needs and would be more productive with smaller tools with less overhead. Though of course the fancy stuff looks better on a resume so can't really blame the devs.
Honestly how many people are writing massive front-ends like these ?
I would argue the number of people using overkill framework for their needs is actually greatly increasing tech debt and slowing things down.
So back to design systems, googling it I found - https://designsystemsrepo.com/design-systems-recent.
At a high level this looks like a set of templates and themes (but I think you were alluding to something more than just this?)
This seems like such a weird claim to make. This used to be "here's a JPEG, you may beg for the PSD". Not saying that there's no gap today but... never been wider..? Am I missing something about the typical Figma setup that makes it worse than a random JPEG export of one state of the UI?
I can't really tell what it currently offers over Astro, it does seem to be a static site generator with a couple of nice tricks, I feel like Astro has perfected this.
I don't think it's any more "standards first" than Astro, or am I missing something?
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.
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
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.
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.
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?
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
The problem with Markdown is there is no standard.
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?
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.
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.
https://nuejs.org/docs/compare.html
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
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.
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.
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.
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.
> 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.
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.
[1]: https://medium.com/@jeswin/sailboat-a-modern-router-for-reac...
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!
Rams and his work at Braun may have inspired Apple's products via Jony Ives, but Rams never worked on an Apple product (as far as I'm aware).
It's a bit like claiming "Thomas Edison is the man behind Tesla's motor technology".
> Dieter Rams is the man behind Apple's design philosophy.
(no need for him to work there to impact Ive's stance on design)
You might try "Dieter Rams inspired Apple's design philosophy."
Dieter Rams no doubt had significant influences and admiration for those who shaped his work and design philosophy, should we credit those people as being behind Apple also? How far should we go? Perhaps we need to point out da Vinci is also one of the men behind Apple's design philosophy.
Seems reasonable to suggest "the man behind" is generally understood to mean "the person directly responsible for".
> 1. Install Bun
Odd requirement to have. I guess they're trying to be consistent in breaking with the old paradigms.
"bun"
Choose one.
[1] https://bun.sh/docs/runtime/web-apis
If you want a truly standards first UI development stack, try Flutter. It critically changed how I view UI development: 1 canvas for any screen. Truly a beautiful thing.
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.
The “one simple standard” falls apart when you need multiple platforms.
And honestly the document and document styling model wouldn’t work very well for these platforms.
Everything from “center a div” to “pinterest style masonry grid” is 100x easier in flutter.
Also, flutter is not “another abstraction” on top of web. The widgets don’t map to DOM elements at all. It is a completely orthogonal approach. All of the other web frameworks are indeed abstractions, but flutter is not.
Just curious, have you used flutter before? My impression is that you would like it because there is actually less abstraction. A widget just represents a paintable object on a canvas without any more indirection than you give it.
While MD itself isn't a web standard, it's a strategic choice that reinforces standards-first development by generating pure, semantic HTML. This creates a natural separation between content structure and visual presentation.
Consider the impact on CSS development.
In React codebases, engineers spend 90% of their time writing JavaScript - managing state, coordinating effects, optimizing builds. Style sheets become an afterthought, buried under framework patterns and utility classes.
Nue flips this ratio: codebases become 90% CSS, focusing engineering effort on systematic design through web standards. By keeping content in Markdown and presentation in stylesheets, we maximize the power of native CSS features - from custom properties and container queries to mathematical relationships for typography and spacing.
This shows a lack of understanding of what a modern webapp is meant to be. Again, your framework is a attempt for static blogposts & other non-interactive/minimally intercative sites. Modern javascript developers build complex webapps, whether you like it or not.
You think stripe.com (webapp) engineers are spending 90% of the time tweaking css?
https://nuejs.org/docs/compare.html
Your comparison is between 2 drastically different sites. https://next-blog-starter.vercel.app/ and https://simple-blog.nuejs.org/
Content-heavy websites have (for me anyway) multiple acceptable solutions currently.
I want to see what your DSL looks like for SPAs.
To be clear, I am your target - developer who noped out of JS frameworks and want something better.
But, like I said, I already have multiple options for separation of concerns with content-heavy or mostly-static sites. What I don't have is a decent SPA framework that neatly does separation of concerns.
I’m no react fan boy, but this is a total straw man. Vite and the like make builds dead ass easy. Also, to try to represent the days before react as some kind of utopia is total horseshit. I have been doing front end for just as long as the author (nearly 20 years) so I lived through that stuff. It was total chaos before. Just gobs of unmaintainable shit. No tests. No reusable code. Nothing. Does react have problems? Yes. Do people use it when they shouldn’t? Also yes. But the whole “it’s too complicated to get it to build” argument is tired.
Depends on how you build things.
https://primevue.org/theming/unstyled/
https://primevue.org/theming/styled/
In most cases, though, there will inevitably be some blurring between the layers, your back end will be coupled to the data model somewhat and the front end will then be coupled to that, both the design, layout and functionality, unless you attempt to build a library or a framework that's detached from a specific project/domain.
For example, even Vue lets you extract your layout into a separate component and then fill it in with slots https://vuejs.org/guide/components/slots.html but nobody ever does that because that'd take more time and they end up just having BasketComponent instead of BasketLayout and BasketComponent, same for not trying to detach the styles from specific components, nobody wants to do that.
Exactly! The more you put styling decisions into your components, the more you hardcode your visual design.
<a :for="src, i in images" class="{ current: i == index }" @click="index = i"></a>
Seconded.
I gotta be honest: while I actually am sold on the principles in the rationale, I'm not so crazy about what the implementation looks like.
This is Tailwind nonsense—not JavaScript.
Instead it could really use a lot more explanation on how it works. If you make comparisons make sure they are fair. The image "JavaScript mixed together" and "Strict separation of concerns" is just comparing apples with oranges. Multiple times in the docs it compares a huge complicated JSX like component and replaces it with 3 lines of html and 3 lines of css. I don't believe that it does the same thing.
Some of the claims are strange. It praises standard HTML but apparently you have to use some custom Markdown syntax to write it. How does that add up? And on top of that it also introduces new syntax for loops and variables.
This could all work perfectly fine. But my suggestion would be to talk more about how it works and what are the advantages and less trying to bring down competitors. It could use less grand claims and focus more on what it really does.
I've seen my fair share of React code, and the code he is displaying is definitely idiomatic React.
> It could use less grand claims and focus more on what it really does.
Agreed. While I appreciate that a rationale is needed for something like this, I think his presentation of the rationale was far too verbose compared to diving into some code.
Maybe I'm not the target - I would have preferred more code and less pontificating, because I 'noped right out of React and others. What I have as a replacement in standard JS, HTML and CSS is unsatisfying to me.
It's really not. There's nothing, for example, stopping you from using <dialog> in React. It works perfectly fine and can integrate with any state or event manager if you want it to.
What he's doing is comparing brand-new web features that don't have good support yet with long-standing solutions that were needed years before those web features were a glimmer in anyone's eye.
> It's really not.
Of the React projects I've seen (including a ton on github), none of them used the browsers dialog without a React wrapper.
A quick search on google for a React project using `<dialog>` found none. Similar for github.
If you have an example, I'd like to see a link, because I'm skeptical that React projects are using `<dialog>` without wrapping it in React.
const Modal = ({ isOpen, onRequestClose, ...rest }: ComponentProps<"dialog"> & { isOpen: boolean; onRequestClose: () => unknown; }) => {
};It's not fair to take these legacy patterns, which are what made React and friends so much better than the other options that were available at the time, and compare them to features that were specifically built with the intention of making those patterns no longer necessary.
Once those new features are supported on most devices (which again, they aren't in many cases) I'm excited to see them incorporated into code bases written in any framework.
[0] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...
Uhm I found some 37-odd thousand results
https://github.com/search?q=%2F%28%3F-i%29%3Cdialog%2F+%28pa...
Probably more out there but I kept the strict jsx/tsx extensions.
What I mean React and other frameworks went with mixing concerns because of reasons that were practical - for example realization that usually one dev implements HTML and JS code in one task, not like article comes up with designers and devs. In reality lots of designers don’t live in agile sprints and the same repositories as devs there is huge impedance mismatch.
Usually one does not design a page like website but reusable components that will have its own context and content.
Designer might focus on broad scope how stuff fits in a web app.
That pop-up to edit “task” has to behave the same on 20 different views.
Widget showing task details will probably be integrated also in some far removed place.
That is whole different game that this “standards focused framework” is not addressing and that game was addressed by whole bunch of frameworks that this article nags about.
Components have won for a reason - for any given web-based UI component to work it needs to render HTML, to style that HTML, and logic for rendering and behavior. So HTML, CSS, and JS.
It only makes sense to colocate those things so that they're easier to build, understand, distribute, and use as a unit. Often times they're not even separable as the HTML depends on state and logic, etc.
And the weird thing is that any other UI platform has components that combine rendering, styles, and logic together and no-one bats an eye because it would be very odd and cumbersome to do it any other way, but on the web some people think components are bad. And they tend to provide no realistic mechanism for reuse except to use an external system.
If you look at website as an application components are valid approach.
I don’t need a framework to make documents - I need framework to make web applications that is why components won so I agree.
I just realized how little "content" my app has. So Nue's focus on these psuedo-Markdown documents is extra worthless. If 99% of the content is coming from the database, what would even go in these docs?
It's the same at the big tech company I work at. Yes we have technical writers and UX and all that, but all the bits and bobbles of text are like 1-line long, so they go into some funky template with all the random strings and then some tooling picks them up and the translators use a custom UI to translate them. None of these folks are working directly in the codebase, nor do I think they should.
The "separation of concerns" is often misunderstood, and historically people were treating html, css and js like they were completely separate beings, which is of course a recipe for disaster [0].
However, what I'd like to see is separation between logic and presentation. In React world people used to call them dumb and smart components. Then you can use stuff like storybook to gauge your layout before applying "business logic" to the application. On top of that you have an easy way to test your "smart" components.
[0] like that time when I saw an org that decided to be "cloud agnostic" and people started pushing their own databases and http servers to AWS. :)
How Nue works is _extensively_ documented:
https://nuejs.org/docs/
Most of these questions are also addressed in the FAQ:
https://nuejs.org/docs/faq.html
THe Markdown claim is also explained multiple times on this discussion
You've done this gluing, sure, but surely at a cost to flexibility. You also didn't even glue, you just reimplemented the whole stack.
And, while on the subject of tone: this is not a very effective way to receive constructive criticism. I had exactly the same reaction as OP, as did apparently a lot of upvoters. Communication is a two-way street, but when a significant number of people misunderstand you or can't find the information that you think you put out there, it would be worth listening to them to figure out what you could do to better communicate.
In the end, most people wouldn't even notice or care if they didn't fully appreciate your project— you are the one who is invested in people appreciating it, so it's up to you to take responsibility for the way in which it's communicated. It's not useful to blame other people for failing to understand your docs.
I feel this this comparison reveals how deeply framework thinking has shaped our understanding of web development and how thoroughly we've accepted JavaScript monoliths as normal.
Why have we normalized a world where marketing pages need a JavaScript monolith with mixed content? Why do we consider utility classes more "maintainable" than systematic design? Why must every solution flow through JavaScript when browsers provide these capabilities natively?
I have tremendous troubles explaining these things to engineers, who constantly turn the discussion into technical, low-level details instead of looking at the bigger picture. Any suggestions how I should approach this? Thanks in advance!