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.
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.
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.
Say what you want about Flash, but most of us cared a lot about usability - small details like keyboard navigation (escape key closing modals, arrow keys for navigating galleries, automatic focus on input fields on login pages, manually crafting tab order to ensure you cycle through relevant parts, etc.).
All these things seem to have been lost to time.
On top of that, I'm really frustrated by the fact that the community, in general, constantly tries to teach me how to code in ECMAScript—something I've been doing for 25 years now.
Just a tiny example: throughout 15 years of programming in ActionScript, I can count on one hand the number of times I intentionally had to use "===". Today using a simple comparison ("==") is treated as cardinal sin.
Not to mention that we've done full circle with stuff like React reinventing MXML, TS reinventing AS3, asmjs. Anyone remembers redtamarin? NodeJS but with AS? :)
> Utility frameworks like Tailwind are not design systems - they're just inline styles with better ergonomics. True design systems express visual harmony through mathematical relationships.
Yes, Tailwind is inline styling with much better ergonomics. Why is that not enough?
Yes, you may not end up with a coherent, harmonious design governed by mathematical relationships, but that's not an argument that the resulting product is not perfectly fine, nor is it an argument that your productivity is higher if you spend a bunch of time to learn how to define "visual harmony through mathematical relationships" as expressed in CSS, then go through the process of designing such a system that's suitable for your app before you even start building your components. The fact that you are typically developing your UI in concert with other features of your program is exactly why front-loading this design system effort probably results in wasted work as you rapidly iterate and evolve both. I think this is why Tailwind has become so popular, because it requires almost no front-loaded effort, and so iteration is rapid.
If you're not already persuaded by puritanical aesthetics around this stuff, then justifying this sort of front-loaded effort will probably be difficult. If it does turn out to be difficult, that probably means this approach will have a smaller niche than perhaps you're hoping for. Best of luck!
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.
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.
I think the docs [0] are a good way of evaluating the article's high horse claims, and as far as I looked around, I'm not seeing anything new nor interesting. The author seems to be more or less just reimplementing Vue from scratch. This makes the whole condescending tone funny, if not sad.
> 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?
You appeal to simplicity a lot, which is great! Contemporary frontend is way too complex. But a lot of what you're saying comes off as too black and white and rejects some of the learnings of the past decade.
Some examples:
- Inlining CSS is usually faster, but there are caveats to this. [1]
- You say, "the fastest page load is one that requires just a single request". This makes it sound like we should be avoiding the platform (the browser). Browsers can efficiently parallelize multiple requests. We shouldn't have the 200+ requests that many sites make, absolutely. But a rejection of requests entirely is not a goal. If you have a few interactive components that rarely change, having a few chunks that also rarely change means better caching too.
Point being there's no substitute to engineering and experimenting with what actually makes your site perform best for your users.
I love these claims — 30x smaller than Next! Y% faster than Next! (And then a roadmap making it clear it's not even close to feature-complete.) Something makes me think as the features mount, that bundle will get a little bigger, maybe get a little slower.
> 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)]
Give me Tailwind standardised utility classes over having to search through the codebase to find what a dev 6 years ago called a CSS class.
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 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.
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.
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.
The FAQ [1] doesn't mention compatibility. How am I supposed to ship a site with this when APIs it depends on, like popover [2], are only supported by the very latest browser versions?
I think the "frontend engineering problem" they are talking about is actually the "React engineering problem". All the examples seem to be entirely about react and only react.
I'm pretty happy with modern angular for big apps with big teams working on it, and just vanilla JavaScript for smaller simple things.
I've tried lit etc al for components but honestly beyond the pure atomics (buttons etc) there is very little that ever gets reused between projects
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 :)
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.
> 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.
I read it and was happy. But then I dived deeper and it is the same as all the other frameworks.
Why is this not using Webcomponents mixed with markdown? Why not JS template literals? Why do I need bun?
And not to mention the strange naming convention: htm for Client html for Server- wtf?
What I want is Astro with just web standards like Webcomponents
> 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.
I resonate with much of what you've written in here. In particular, the cultural costs. I work on a "frontend platform" team at a mid-sized company and spend most of my day trying to get the React/Next ecosystem to play nice for our engineers. If I rearchitected it from scratch, it would not use Next, but I digress.
Some critiques:
1. As others have mentioned, lots of abstract in here, not so much data. That's a hard sell to engineers. You're going to get a lot of theory responses, which maybe is what you want at this stage, but it might help to make that clearer if so.
To avoid this, you might consider refocusing the narrative. I have personally found that while appealing to Developer Experience (DX) is the fad, debating DX is an uphill battle. IMO we should appeal to something more concrete: User Experience. The discussion has to start and end with users. DX is part of it, but often over-represented. If I can sit down with someone and show them X technology is failing our users because Y fundamental flaw, the conversation is no longer on frameworkism. It's instead on how you solve problems for your users effectively. See Alex Russell's discussions on this, as divisive as they might be [1].
2. The why is clear. The what and how are not. Clarify what you're doing that is different. For example, Astro is also standards-based. Astro also approaches the problem from progressive enhancement and fundamentals over frameworkism. It seems like your focus is on separation of concerns and design principles? While I disagree on the dogmatic approach re: separation (I personally like components and composition), it would help to highlight your diff.
* I mention Astro, but this is true of other newer approaches, e.g. 11ty, Qwik, Enhance.
3. In another comment you claim that [in Nue] 90% of your codebase becomes CSS. I get that this is coming from the reduction of JS to do what HTML and CSS should, but it feels... disingenuous? At scale, no frontend or fullstack engineer I work with is spending even close to the majority of their time on CSS, regardless of stack. The focus IME is on building features, parsing/integrating data, and everything tangential to the feature (architecture review, testing, docs, etc).
Just some thoughts! I'd be interested in hearing more in the future.
@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 />
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.
A standards-first web framework
(nuejs.org)165 points by tipiirai 16 January 2025 | 195 comments
Comments
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 wanted to give it a try, but I need to install bun, a new js runtime, okay fine, why not. Javascript needs more runtimes after all.
Then I need to install `nuekit`.. globally.. Okay...
Now I need to run an obscure command 'nue; which I didn't know I installed. `nue create simple-blog`
Then it tells me to follow the tutorial docs, great. But I need to start writing YAML.. Losing patience now.
My relief comes when I see :
> Nue is not currently tested or developed under Windows, so use it at your own risk.
Well I guess as a Windows user I can't have a 'Standards First Web Framework'.
Think I'll stick to what actually works instead.
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
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've been doing "web dev" since 1999.
Say what you want about Flash, but most of us cared a lot about usability - small details like keyboard navigation (escape key closing modals, arrow keys for navigating galleries, automatic focus on input fields on login pages, manually crafting tab order to ensure you cycle through relevant parts, etc.). All these things seem to have been lost to time.
On top of that, I'm really frustrated by the fact that the community, in general, constantly tries to teach me how to code in ECMAScript—something I've been doing for 25 years now. Just a tiny example: throughout 15 years of programming in ActionScript, I can count on one hand the number of times I intentionally had to use "===". Today using a simple comparison ("==") is treated as cardinal sin.
Not to mention that we've done full circle with stuff like React reinventing MXML, TS reinventing AS3, asmjs. Anyone remembers redtamarin? NodeJS but with AS? :)
It's easy to be grumpy about all these things.
> Utility frameworks like Tailwind are not design systems - they're just inline styles with better ergonomics. True design systems express visual harmony through mathematical relationships.
Yes, Tailwind is inline styling with much better ergonomics. Why is that not enough?
Yes, you may not end up with a coherent, harmonious design governed by mathematical relationships, but that's not an argument that the resulting product is not perfectly fine, nor is it an argument that your productivity is higher if you spend a bunch of time to learn how to define "visual harmony through mathematical relationships" as expressed in CSS, then go through the process of designing such a system that's suitable for your app before you even start building your components. The fact that you are typically developing your UI in concert with other features of your program is exactly why front-loading this design system effort probably results in wasted work as you rapidly iterate and evolve both. I think this is why Tailwind has become so popular, because it requires almost no front-loaded effort, and so iteration is rapid.
If you're not already persuaded by puritanical aesthetics around this stuff, then justifying this sort of front-loaded effort will probably be difficult. If it does turn out to be difficult, that probably means this approach will have a smaller niche than perhaps you're hoping for. Best of luck!
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.
Happy to hear your feedback.
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.
[0] https://nuejs.org/docs/
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".
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?
<a :for="src, i in images" class="{ current: i == index }" @click="index = i"></a>
You appeal to simplicity a lot, which is great! Contemporary frontend is way too complex. But a lot of what you're saying comes off as too black and white and rejects some of the learnings of the past decade.
Some examples:
- Inlining CSS is usually faster, but there are caveats to this. [1]
- You say, "the fastest page load is one that requires just a single request". This makes it sound like we should be avoiding the platform (the browser). Browsers can efficiently parallelize multiple requests. We shouldn't have the 200+ requests that many sites make, absolutely. But a rejection of requests entirely is not a goal. If you have a few interactive components that rarely change, having a few chunks that also rarely change means better caching too.
Point being there's no substitute to engineering and experimenting with what actually makes your site perform best for your users.
[1] https://www.slideshare.net/slideshow/performance-now-24-perf...
* related video to above slides: https://www.youtube.com/watch?v=j5E_U_hu7g0
Give me Tailwind standardised utility classes over having to search through the codebase to find what a dev 6 years ago called a CSS class.
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?
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.
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.
[1]: https://nuejs.org/docs/faq.html
[2]: https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
I'm pretty happy with modern angular for big apps with big teams working on it, and just vanilla JavaScript for smaller simple things.
I've tried lit etc al for components but honestly beyond the pure atomics (buttons etc) there is very little that ever gets reused between projects
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.
> 1. Install Bun
Odd requirement to have. I guess they're trying to be consistent in breaking with the old paradigms.
What I want is Astro with just web standards like Webcomponents
This is Tailwind nonsense—not JavaScript.
Some critiques:
1. As others have mentioned, lots of abstract in here, not so much data. That's a hard sell to engineers. You're going to get a lot of theory responses, which maybe is what you want at this stage, but it might help to make that clearer if so.
To avoid this, you might consider refocusing the narrative. I have personally found that while appealing to Developer Experience (DX) is the fad, debating DX is an uphill battle. IMO we should appeal to something more concrete: User Experience. The discussion has to start and end with users. DX is part of it, but often over-represented. If I can sit down with someone and show them X technology is failing our users because Y fundamental flaw, the conversation is no longer on frameworkism. It's instead on how you solve problems for your users effectively. See Alex Russell's discussions on this, as divisive as they might be [1].
2. The why is clear. The what and how are not. Clarify what you're doing that is different. For example, Astro is also standards-based. Astro also approaches the problem from progressive enhancement and fundamentals over frameworkism. It seems like your focus is on separation of concerns and design principles? While I disagree on the dogmatic approach re: separation (I personally like components and composition), it would help to highlight your diff.
* I mention Astro, but this is true of other newer approaches, e.g. 11ty, Qwik, Enhance.
3. In another comment you claim that [in Nue] 90% of your codebase becomes CSS. I get that this is coming from the reduction of JS to do what HTML and CSS should, but it feels... disingenuous? At scale, no frontend or fullstack engineer I work with is spending even close to the majority of their time on CSS, regardless of stack. The focus IME is on building features, parsing/integrating data, and everything tangential to the feature (architecture review, testing, docs, etc).
Just some thoughts! I'd be interested in hearing more in the future.
[1] https://infrequently.org/2024/11/if-not-react-then-what/
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.