This is what they're replacing react with: https://nuejs.org/docs/view.html
It's an untyped view layer kind of along the lines of early angular 2.0.
The model files are plain javascript.
So no typings anywhere. Which is fine, I guess this is targeting the vuejs crowd. Maybe their marketing should pivot a little bit in that direction, most react people now use TypeScript because first class types in your view layer are super useful
This is great. But I went for Svelte. Invested in Svelte and SvelteKit. Wrote a decent sized app (not toy example, pretty feature right, tens of forms and screens if you will) and later I looked back at React.
And I discovered that:
- React is not that hard if you understand the hooks.
- React is lightweight too. For my use case at least.
- React is boring technology at this point which is good.
- The ecosystem is huge. You cannot have React Query like library and that's just one example.
So I'm sticking to React for next few years especially when the React compiler is already being used inside Facebook and Instagram and released as public beta.Even React Native supports React compiler and I don't see this support going away rather getting better.
PS Edit: React compiler leaves not much for runes in Svelte or its compiled nature. I don't like Svelte much after runes because it feels like you're not writing Javascript rather a notation that looks like Javascript. Post React compiler, much of the hooks hell is not needed in complex scenarios.
I wish instead of this marketing article there were technical details, for example: what method of change tracking is used (proxies Vue-style or recomputing everything React-style).
Also I didn't understand the phrase about JS "overflowing stack" with 150 000 objects. I created a list of 150 000 objects with the following code:
var list = [];
for (var i = 0; i < 150000; i++) { list.push({ id: i, name: `Name ${i}`, weight: i * 100 }); }
According to profiler, this array (with objects) uses 14 Mb, where 2 Mb is array and the rest are objects and strings. Running list.find() without any indexes also doesn't overflow the stack. With indexes it would probably be lightning fast and won't need any WASM and complications.JS is not that slow. And if you do numeric computations (i.e. multiplication of numbers in large arrays) the code gets compiled and runs pretty fast.
Nue’s a web framework I’m building to slice through modern web dev bloat. When a Vite/ShadCN/Tailwind button is 40% heavier than a full-blown SPA, it’s time to do things differently. We’re retooling from the ground up—web standards first, no bloat. It’s for frontend architects, design engineers, and UX folks craving simpler, saner workflows. Still in progress, but the shift’s coming. Curious to hear your thoughts!
Most new frameworks start as the "lightweight" option to whatever more mature options exist at the time. This is no argument for adoption.
Please post again 10 years from now after you have added all the bloat your users request and handled all the edge cases you don't yet understand.
If you are still lighter than a react button...that will be news worthy.
Looking at the project:
- Why is the demo impressive https://mpa.nuejs.org/app/ I believe someone can do the same web-app in React with the same performance.
- I'd like to quickly see some code samples on the home page. I had to dig the documentation to find some code samples (https://nuejs.org/docs/view.html#clean-html-templating), is it inspired from Svelte ?
- How is new faster and lighter compared to other tech? Specifically, compared to raw HTML/js.
To convince me that Nue is a framework worse using, please show that Nue: 1. Is simpler than HTML+JS (or at least simpler than react): like https://alpinejs.dev/
2. Is easy to understand: maybe the markup and logic are close to HTML or something else I already know
3. Has a better DX with good build time and HMR: you nailed this one
4. The tech is better: low overhead? highly based on WASM? virtual DOM? Server islands?
5. Show me metrics: https://esbuild.github.io/ nailed this one
If the authors of this project mean to say that a button in react wouldn’t work without including the react library (which is why the button is supposed to be 73kb), it’s a weak point, because the react library would be reused by other parts of the app bundle at this point.
This is misleading to people and the promise is so shallow that it almost feels insulting.
I really like the approach but the demo [0] doesn’t really work on iOS Safari (although might be my outdated 16.7.8 version). Scrolling doesn’t work, the layout and buttons have weird line breaks, the native search button is embedded in the custom designed one, leading to 2 icons…
Are there any code examples? I've looked for a bit but haven't found any. That should IMO be the first thing on any blog post about new frameworks.
IMO talking about the “heaviness” of popular web frameworks is way too simplistic to be actually meaningful.
How light or heavy an app feels, in my experience, has very little to do with initial bundle size, and far more to do with how adeptly the developers have solved the distributed systems problems of their app.
Are images compressed and cached on a CDN? Is linked content pre-fetched? Does the app avoid unnecessary roundtrips to the server?
These are the questions that truly matter, IMHO. They’re also things that junior devs are likely to get wrong.
All that said, I agree that you tend to see far more sluggish websites written in React than in any other framework. But personally, I think that’s a consequence of React being popular, and attracting a larger proportion of devs who miss important details.
I share this opinion of Electron, BTW.
Yes, React is huge, but I also see it used for everything and everyone when it's really not the right tech-stack in many situations.
Just need a simple interaction free site? Use Astro.
Need some interaction? Use Svelte. Larger project? SvelteKit.
Need a more established solution? Use Vue.
Working in a huge team and need a highly opinionated framework with strict conventions? Use Angular.
More than 99% of websites would be sufficient with Astro though. And when just some interactivity is needed it is always possible to add Svelte / Vue / Solid / Alpine / HTMX on top of Astro.
> frontend architect, design engineer, and UX engineers
Damn should I update my resume again? I’ve used webmaster, web developer, full stack developer in the past. Can I use "internet creationist" to leap directly to the next call phrase?
More seriously, I’m lost when using a search bar in a job listing. Now I just type "JavaScript" but that miss the posts only mentioning the higher stack and/or typescript.
Its not big frameworks making the web big/slow. Its...
Yes, its absolutely the big fucking frameworks. In most cases it is the actual literal use of the frameworks, but even that isn't the real problem. The real problem is deeper. You can call it second order consequences.
Its developers that cannot optimize and cannot program without something like React. If you took React away would you suddenly not be able to do your job at all? That's horrible problem to have. The result is a bunch of toxic defensive posturing by people who suddenly appear not qualified to do the work.
If you cannot dig deeper you certainly cannot optimize deeper. That makes the assumption you are actually measuring things and optimizing things in the first place, which many developers aren't. Again, if a given developer lacks the capabilities to dive deeper they may also lack the capabilities to measure things, as is quite common.
I really like how Nue is shaping up! Having a clear MVC separation, leveraging modern web standards, semantic markup—all great things. Kudos!
Seeing the .dhtml extension certainly brings back memories... One thing I dislike is that the HTML is still parsed and converted into JS, which is then evaluated at runtime, correct? I realize that this is required to support templating and a nicer syntax for binding and such, but my ideal "framework" would support plain HTML files that are not converted to JS, but used very lightweight syntax (essentially custom data attributes, and `<template>` elements) to make the page dynamic. In fact, I'm experimenting with such a library right now[1]. This approach is likely more difficult to manage when building large web apps, but for simple UIs as used in browser extensions, it's fairly sufficient.
Frontend web development has been stuck in a pit of complexity for well over a decade now, and it's about time we go back to basics. There are new generations of frontend developers who only know this way of working, which is a shame. They're not really _web_ developers, but React, Vue, or whatever the popular framework is, developers. Web standards are far along now that there is very little additional glue and sugar needed to build modern web applications. React ushered in a new way of building UIs, but it also spawned dozens of copycats and frameworks that are downright developer-hostile beyond their shiny exterior. Not to mention the security nightmare of an incomprehensibly large dependency tree. Let's actively reject this madness.
> Using Rust and Event Sourcing for instant UX over 150,000 records — far past where JavaScript crashes with a stack overflow error.
Nit: while I fully support making the web more efficient and hope that Nue is successful in promoting that, I'm skeptical of the "crashing" JS claim here. You can do amazingly efficient things with TypedArrays, the forgotten middle child between JavaScript and WASM.
Having said that, this requires building a few clever data structures on top (I've gotten a lot of mileage out of "typed" dequeues, and (sparse) bitmaps myself), often emulating structs in a language unable to express them properly. So the resulting code is not exactly idiomatic JavaScript — which I presume is what they implied here. Plus in this case it probably still wouldn't be as fast as a well-written WASM implementation, since almost all of the work is likely spent searching with only a little bit of DOM manipulation at the end.
So I'm both agreeing and feeling like it slightly overgeneralizes. I guess my point is: yes, let's be critical of bloated web frameworks, but let's not equate React with JavaScript either.
Today it’s Nue. Tomorrow it’ll be Olde and we’ll complain about all the boilerplate or repetitive update logic we now have to write.
The animations makes it feel slow, the lack of any throttling/debouncing means that my input feels slow too.
If you just use an html button with simple styling the size is around 58kB (not the quoted 73kB, which is from other libs that they built with like ShadCN than just react), so its still impressively smaller than react.
That said, using Preact instead (a smaller and more modular react-style library) the file size is less than 5kB. Its almost a drop-in replacement for React too: https://preactjs.com/guide/v10/differences-to-react
If i make a similarly minimal app with Nue (the lib the article is about), export as production, and remove the favicon it seems to want to add automatically, the filesize is 28kB. I couldn't see a way to meaningfully reduce that in their docs, as its clearly exporting things that arent being used.
Its pretty disingenuous for them to compare an app to a single button, given their own single button implementation is massively overinflated too. It does appear to be a full app framework rather than just a view library though. So I'll definitely give it a whirl.
To the OP: From a lot of the comments here, including my own, comparing yourself in this way is only going to result in people calling you out on it. Its clear the lib has merit in its own right, but you aren't comparing like to like, and if the focus is on "button" apps, then you are still WAY behind some other libs in terms of export size.
I like the philosophy so much, I myself am working on a minimalist theory to explain human psychology and strongly against specialized therapy and bloated productivity systems. We have specialized rules for everything which I feel repeatative and we are not using the full potential of human mind.
Anyways, here are my initial observations on NueJS
1. In the age of AI we need to support it for broader adoption. One of the reasons people choose NextJs and Tailwind over other frameworks is that LLMs understand them well. We need some minified doc to pass onto LLM to make it understand the framework.
2. What do you think about the unstyled components like Radix UI? Accessibility issue are important for components like Model.
3. What do you think about server components? I like them personality as we don't need to pay for separate NodeJS server as a small team.
4. How much Rust is required to use it properly? It's not an easy language to learn as far I heard.
5. How do it compared to AlpineJS who also focuses on performance?
Looks interesting!
Regarding the code examples in the docs:
It would be great if the examples for models and views would be from the same example.
Currently, the view example is something about users and the model is something about customers?
The interesting part for me is not how the individual components of the architecture work but how they connect...
Very catchy landing page, like it. And I've read the documentation. Unfortunately not convincing me. I mean, writing larger web apps means nothing else then dealing with a lot of _state_, really a lot of asynchronous _state_. Clicks, notifications, mouse movement events, push messages, navigation changes and so on and on. Larger web apps are state monsters. That's why I choose a framework that is good a state management in the first place. React is one of those proven. Nue does not look trustworthy in regard to good state management tbh. For smaller apps that might not be a problem, but there I tend to use vanillajs anyway.
The FAQ (https://nuejs.org/docs/faq.html) describes pain points that seem pretty foreign to me, the exact thing I appreciate about React is that I can focus on the domain and the tech MOSTLY does fade into the background. It has been an improvement in that regard, to all the frontend MVC I've done before and the architectural pattern has been adopted for good reason by all the native platforms.
TBC in React and its offspring, you can still model business logic outside of components, we just learned that most UI development is better served by keeping UI and its state closer.
I can’t find a single example of what a Nue app looks like. All I can find is pretentious claims about how Tailwind sucks and other outlandish claims.
This framework is a good example of something I call, "there's plenty of room in the middle." (In analogy to Feynman's "plenty of room at the bottom" about nanotechnology.)
Much like how Cosmic Inflation in the early universe left the imprint of microwave background radiation written exponentially large across the sky, I believe the exponential expansion of computing during the era of Moore's law left whole sections of scale in software not-fully-explored.
Specifically, as "average app sizes" went from 1K - 10K - 100K - 1M - 10M - 100M+, you could imagine the 1K-10K got fully explored because the space wasn't that big to begin with, and the 1M - 10M range got, if not explored at least inhabited, but it could be that that middle range of "neat applications that weigh in ~100K+ but less than 1M" didn't get completely explored because we didn't spend enough time in that era of computing.
A similar thing may be playing out in AI scaling, where we went from tiny to medium to huge model sizes, but now some new participants are going back and doing neat things with medium sized models.
It sounds cool and all but the single button thing just irks me. The point of React is for making a system of components with potentially complex relationships between them/when they’re displayed, etc… Nobody is using React to put a single button on their website. It’d be nice if there was a more useful, practical “benchmark” that your entire marketing of the library is centered on.
Honestly, after playing around with your example and tweaking a JavaScript example, I feel that my plain JS example is faster than the one with WASM/Rust on Nue (possibly due to the animations). Please disable animations; I think they make your WASM example feel slower than it probably is.
Here is a 1 million rows table in JS with filtering, sorting, and pagination: https://htmlpreview.github.io/?https://gist.githubuserconten...
Nue seems to be in an odd space. It's an untyped framework, built on top of "web standards".
But if you wanted web standards + web component, Lit already fills that space. If you want untyped JS or little/no JS at all, there's HTMX. Or if you're just tired of React, and want something faster + simpler, there's Svelte/Solid.
I'm not sure what problem Nue is uniquely solving.
If I felt strongly about going lightweight I would (do) use plain js. I trust myself to know when I'm following basic principles of performance and when the line has been crossed warranting the use of a framework
Nue still continues to advertise with clickbait?
React is the most used frontend framework, but not a good reference as React is outdated, slow and big.
Take Solid, Svelte or Vue (with or without Vapor mode) as reference and the picture looks different. Additionally when using custom components instead of large UI libs based on HTML elements like <dialog> or the recently announced stylable <select> element you have a very powerful, small and simple stack.
Still, they catched my interest. A lot. I'll dive into the docs to learn more. Maybe I'll be convinced to change my go-to stack to Nue ... damn, I had so many happy weeks with Vue. Maybe till Vue Vapor is out.
So many people are obsessed with Web application size. But there are other important factors as well. First of all, the UI must be functional even it's slow and heavy. If it does the job then it's already a win. I don't actually care how long I'll wait while I'm downloading the JS bundles. I've been waiting 5-10 mins GTA to load back in 2008, waiting seconds is totally ok.
It would be nice if the standard JS library was more feature complete like Python. Then devs wouldn't have to bundle third party libraries.
Or perhaps the caching could be better. e.g. if your'e using Tailwind CSS version XXX, why does the browser have to reload it every single time?
Local persistent storage isn't exactly at premium these days even for "lightweight" mobile devices.
Developers can ship a tiny amount of HTML and zero to a tiny amount of JavaScript a zillion different ways. Shipping hundreds of kilobytes of JavaScript is a choice.
To choose one way at random: build a backend with good old express.js (version 5). Use preact-render-to-string and JSX on your server side. Write yourself a few lines of JavaScript to support rehydrating interactive islands where you have them. (Hand-rolling island rehydration isn’t hard and you don’t need a big toolchain to achieve this.) But mostly build your routes and your site like any old-school MPA.
To choose another: build your backend with Go and Templ and adopt fixi.js sparingly to replace sub-portions of your page when appropriate. Keep your route structure like any MPA. Write custom plain JavaScript for those bits of interactivity not well-captured by fixi, and wrap it in simple web components whose only purpose is to implement the connected and disconnected callbacks. (No need for shadow DOM, etc.)
Or yet another: build a preact SPA front-end, studiously avoiding preact/compat or anything that would depend on it. Use your favorite backend: maybe Django! Maybe build with actix-web!
Or yet another: Rails 8’s Turbo & Stimulus are quite delightful and slim.
Etc. etc.
(I mentioned preact several times but that’s easily replaced with another tiny framework like solid, svelte, etc.)
Based on work done by svelte and solid, I think it is possible to shave base react down to half its current size, but it appears nobody (inside or outside of Meta) is willing to take on this challenge.
Unfortunately, the tradeoffs are still in favor of react and will continue to be in favor of react for the foreseeable future.
Most importantly it is next to impossible to get developers to give up DX (and muscle memory) for smaller JS bundles.
I'm a novice, I chose to learn dart/flutter rather than deal with, and attempt to figure which, web framework to use.
If forced I would likely go with htmx.
Regards nue: do I need to know rust?
So is there a book that I could read that would allow me to write applications with just HTML/CSS some js and rust? I don't want Nue so much as I want "The art of writing lightweight, feature complete, responsive applications on the modern web."
Would love a pointer to THAT.
I think there is an issue with the implementation of search and filtering.
When I open https://mpa.nuejs.org/ and type "kind of rate limit" in the search box, I get 383 search results, and the URL updates to include the query: /app/search/?query=kind+of+rate+limit.
However, when I paste that URL directly into a new tab, I only see one result instead of 383.
I find the blurring/fade-in effect jarring. It makes it feel slower rather than faster. Feels like fade-in is used to hide the performance.
Please add a button or something to disable that effect.
I feel like some of react’s innovations should be built into browsers. Jquery got built in with document.queryselect.
Seems to be no support for TypeScript in the frontend? I mean, it is mentioned, but only together with Rust and Go for "computation engines".
No TypeScript = No deal with me.
I wrote my first Javascript application back in the spring of 2025, and I am not aware of anyone who is willing to pay me enough money to voluntarily write Javascript again in a project of meaningful size.
The tagline says a lot more about React than it does Nue, but I'm always interested in less bloat when it comes to front-end. I'll try this out, one small thing I don't like is in the demo there is a weird pulsating effect that actually modifies the layout when clicking, throwing me off a little.
This doesn’t square with most of my experience with React, especially if use it to generate static code hosted by nginx. I’ve found my personal site to always be wicked fast, even though it’s not that complex.
Interesting, on that page using Safari, clicking on the home/nue logo or most other links/buttons results in a null error :)
I would hope React buttons work when people click on them though.
In the meanwhile on the App/Play store some native apps like YouTube weight around half a GB... but only the web is bloated
If React is good enough to power Facebook, it's good enough for your <1k users app.
I see a lot of people angry at "Nue" in various ways, and I can't help but think these are people heavily relying on React and missing the overall issue. The issue is that these huge frameworks have made the web a horrible slow mess. I deal as DevOps/SRE daily with these services, and finding one that will do a first load under 10s is close to impossible. When a simple home page dashboard or a notes page takes more than 10s to load on a 10G connection peered within 5ms of the host, and 95% of this is spent in JS, that's when you know the typical current webapp has reached a massive state of bloat only supported by fast browser engine, and people not having expectations.
I'm not hopefully Nue would revolutionize this since there are plethora of Web SaaS companies just wanting to use "common" frameworks... but I can at least root for them.