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.
I've created plenty of medium-sized projects with React/Vue clocking in at 200-300KB compressed (excluding image assets). You can still realistically use those on 2G — yes I've tried, not just in dev tools, but when I was actually rate limited to 2G.
> 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.
You can create that kind of garbage with any framework, or without framework. You can actually do worse with the traditional way of using third party dependencies wholesale (the jQuery way), you can be downloading 200KB for 1KB of actually used code.
Edit: Also, the comparison in the article is pretty stupid. A full view in React is not much larger than "a React button", it's upfront cost + marginal cost.
Author here: Fair point—React’s baseline isn’t a monster. ~60KB compressed for a barebones Vite/React setup, or even ~25KB with Vue. Medium projects at 200-300KB are definitely workable.
But here’s the point: a single React/ShadCN button, straight from their official docs, still outweighs Nue’s entire SPA demo. Add more widgets—tabs, modals, whatever—and that gap only widens. Nue is flipping the script. Web standards let us start lean and stay lean—smaller codebases, faster HMR, quicker builds. That’s the win: efficiency that scales without piling complexity.
So don't use ShadCN? It's so weird to put up this strawman app and then be like "see what's wrong with React"? Like showing two boards nailed together and being like "can you believe I needed all those power tools just to do this?"
> Add more widgets—tabs, modals, whatever—and that gap only widens
This is the benchmark I want to see. Two full-featured apps built with minimal prod dependencies. There's a pretty good chance that the various ShadCN modules share many of their dependencies so that importing more doesn't necessarily mean a linear increase in bundle size. It could be that once you build something full-featured, React projects come in smaller, or at least not big enough to invalidate the other upsides of choosing it.
But the OP did implement a fully featured app as the Nue comparison half of the benchmark. I have never used Nue and don't know if I ever would. I just think to be fair to the OP, even if incremental cost declines as you keep adding stuff in React, there's no way it is negative, which means the benchmark you asked for logically must have a similar result?
> Two full-featured apps built with minimal prod dependencies.
This isn't what you see in the real world. I'd rather see comparisons to real life (where 99.9% of web apps are bloated garbage) than nonsense synthetic benchmarks like that.
Does an ecosystem like that exist for Nue? If not, it’s the only fair comparison. The ShadCN button comes with styles and behavior that wasn’t implemented in the Nue demo.
An extra 100-200KB compressed is a ~100ms one time cost once in a while for the majority of my users, and ~1s for 95%+ of users. At that point I'm going to optimize for developer productivity (which includes breadth of ecosystem). I can be both productive and respectful to my users with these common frameworks.
Note that I'm very mindful of web performance, and I've been quite vocal on this site about some alarming trends like calling for the end of bundling (native esm) and roundtrips for everything (liveview and co., or at least the abuse of them). In my experience waterfalls and roundtrips are the number one thing hated by people on slow and/or unreliable networks; 100KB added to a flat bundle at load is almost nothing.
> An extra 100-200KB compressed is a ~100ms one time cost once in a while for the majority of my users, and ~1s for 95%+ of users. At that point I'm going to optimize for developer productivity
Is that 100ms on fiber? Cable? 5G? 4G?
Is that for the first button? Or each button? And what happens when you next need to manage dates as objects? Do you pull down dayjs or do you wrangle it yourself? What other libraries do you need to add? How's build speed? How much time to the linters take as they cascade through all that code? How are your Next.js (a pretty standard companion to react) version updates going? Keeping up with security alerts?
I'm biased against React because I manage a team trained in classic web design who now have to manage a giant React codebase and learn its special way of doing things, and it's a slog.
Agencies are going to keep building with React because they can get 90% of a project done in no time flat, and they don't have to deal with the infra challenges after they get their check. Small clients like us will continue to fall for it and slowly grind to a halt as the infrastructure pulls the team to a standstill.
Yeah, I don’t even know why people who are that clueless about frameworks are commenting; it takes less than an hour of learning of modern web development, from scratch, to shut down that notion. And other libraries to manage dates and stuff? Excuse me? How does that have anything to do with the rendering framework? Completely orthogonal choices.
And asking about basic math on download speed is golden. No idea how someone can “manage a team trained in classic web design” without that knowledge and then pretend to care about performance.
Eh, I'm clueless about this aspect of the framework (if you can call such a steaming pile of resume-driven-development such), and honestly I'm thankful for it.
Libraries like dayjs add complexity to the overall codebase and it's another piece of code you need to keep track of, update, and repair when its makers decide to go a different direction with it or some script kiddie decides to introduce a backdoor into it.
I think your larger concern shouldn't be about the "clueless people" who are commenting on this thread and rather the number of upvotes my comment got (especially compared to your rant). Clearly it struck a chord.
People are commenting and upvoting because the choices that went into building React leaves a lot of room for frameworks like Nue, Vue, hell even HTMX. Just because (it sounds like) you've staked your career on thinking React, the McDonalds of frameworks, is awesome doesn't change that.
No I’ve not staked my career on React, I’m not even primarily a front end guy and React is my least favorite framework among popular ones, but thank you for your concern. I was debunking one ridiculously wrong comment criticizing my least favorite framework with solid, reproducible statistics, but that’s apparently a rant compared to your very insightful questions like “100ms to download 100KB, is that fiber? Cable? 5G? 4G?”, then okay. You clearly struck a chord with a large number of people so out of touch that they believe a copy of React is required for each button, and pride themselves on such ignorance because it’s “resume-driven-development”, so congratulations.
(Another tip: Don’t bring votes into discussions, it’s both against site guidelines and laughable.)
> I'm biased against React because I manage a team trained in classic web design who now have to manage a giant React codebase and learn its special way of doing things, and it's a slog.
What special way is that? One of the big draws of React is its minimal api surface, and the ability to write standard JS alongside of your presentational HTML.
I am also curious what "classic web design" actually means, I have a theory, but I am curious all the same
I was speaking directly to the reactive framework itself (which is a smart way to get around some limitations), the div salad it pushes developers to sustain, and the fact that they felt they had to rewrite HTML such that instead of typing <h2> devs have to type something like <Heading.
HTML is a pretty simple markup language and abstracting from it doesn't seem to make any sense.
And I think your theory about what I mean by "classic web design" is probably right; keeping the JS separate from mark-up is one example of how I wish I could go back in time.
But I can't. So it's time to learn to manage people who want to go this direction.
Meta wrote React for Facebook mainly, and most other projects won't touch that scale. In my organization's case it's like we're water-skiing behind an aircraft carrier. It's the wrong tool for the job, and having three people manage 37k lines of code (excluding libraries) is tough.
Although payload can be indicative of page load speed, there are many good reasons Lighthouse scores are more complex than that. Specifically, at the start of this thread the criticism was that the js work in modern web apps is slow. I have thus far managed to avoid using react so I don't know the actual numbers, but I don't think the conversation should be reduced to payload size, even if it is obviously important. When I profile problematic pages, other than sites that don't properly scale their images, it is not usually network that bogs them down, it is the rendering.
Even focusing on Lighthouse score or similar for a basic app is totally missing the point of Nue as presented on the linked page. It about a framework designed for speed that can handle data at scale, that is easier to control and personalize, and easier to model and thus architect. And yes, of course, most any framework can be used for good work, but the relevant question here is which one promotes it the most from start to finish, and makes it the easiest to implement. Speaking only for myself, this focus is great to see.
How much is it React/Nue and how much is everything else?
HTML has evolved in the last 15 years to be a platform for applications. The early Bootstrap was a terrible Rube Goldberg machine because CSS didn't have civilized layout mechanisms such as grid and flexbox. Newer frameworks like Tailwind are more sensible, but still add 50k to your bundle, and if your app is complex and developed under deadlines you probably have components that use Tailwind and Bootstrap and emotion and styled-components and raw CSS and you still have to write some SCSS to get the styles just right in the end.
I've been investigating the accessibility of various <Modal> components and found that they all suck because they do complicated things with <Portal>(s) and various-aria-attributes. HTML has had a <dialog> component that properly hides the rest of the page since 2022 but barely anyone was using it.
If you stuck to using Tailwind or Bootstrap or raw CSS and used a minimal widget set you can make small applications with any framework. If you wrote raw CSS and made the most of the widgets that come in HTML5 (like the new stylable <select>) you can make tiny applications.
Tailwind, at least for the last couple major versions, only adds the classes you actually use (plus the resets). Baseline size of the resets is far below 50k.
Great point about the dialog element. I used it in a project recently for the first time... It was very nice to not involve a framework-heavy "portal" scheme, etc.
Since those class names are repeated, they will be gzipped to a very small size. And on top of that browsers/devices are much happier about HTML sizes than about JS sizes. See Performance Inequality Gap: https://infrequently.org/2024/01/performance-inequality-gap-...
I think Nue just puts you in the mindset of trying to keep the codebase as small and lightweight as possible. I wanted to rebuild my website with Nue and there was something telling me to avoid Motion, Tailwind CSS, etc. This philosophy can actually prove very helpful in the long term, however I feel that by using Nue you're really compromising on DX (development is much slower), although that might be because I'm not so familiar with creating websites without a framework. In any case, it's definitely worth a try.
Yes it is. It’s not size, it’s logic: Every time the component rerenders, the root loop is executed. Why? The root loop reassigns every useEffect, reruns every useState, every other hook (and useSearchParams is executed n times for n components that need it in the hierarchy) when only the HTML needs rerender.
(Yes the programmer can optimize/memoize, and yes “a hook’s execution time is very short” (but multiplied by every cell in the table, when needed)). Must be the fault of the programmer if the framework has a super-intensive concept at the root.)
this means the example wasn't made to be lightweight.
You'll need an apples to apples example to convince any detractor. Implement the same app using two different toolsets, document the process with each and then benchmark it
To be honest, I am very confused with this benchmark. It is misleading.
What is the actually size of the production build portion only for that button part? Because I think that the ShadCN button source code is not equal in size for the button that client downloads in production environment. Especially if you have SSR.
If you look at the demo, all of the payload comes from react and the tailwindcss classes that the shadcn button refers to.
It's dishonest to call this the payload of "one shadcn button" since it's basically all react/tailwindcss fixed cost and not literally a shadcn button.
But still, that's a decently broad demo to fit in a small payload, so the exaggeration kinda takes away from that.
The main thing I care about in client development is the state management solution since that's where most of the complexity comes from, and it's what makes or breaks an approach. In React, I use MobX which I see as the holy grail.
> It's dishonest to call this the payload of "one shadcn button" since it's basically all react/tailwindcss fixed cost and not literally a shadcn button.
Does the ShadCN button work without paying that cost?
Sure. If you just want the shadcn button by itself, it will generate this html: <button class="{tailwindcss classes}" />.
And it has a dependency on some common tailwindcss classes that will get injected into your bundle.
Most shadcn components depend on tailwindcss classes, and how the whole shtick works is that tailwindcss only includes in your bundle the classes that your components use across your app. Which is kind of a clever integration for a ui component 'package manager' for reducing bundle size.
But most importantly, consider that OP's demo has very minimal CSS because they aren't using a CSS framework, and that has nothing to do with their Nue framework. It's not like their Nue framework comes with an optimized answer to tailwindcss/shadcn; you have to bring your own solution.
So if you use tailwindcss/shadcn with React, you'd certainly use it with Nue.
What Nue should do instead is add libraries to either side necessary to reach parity with the other side. Nue has built-in routing, so it would be fair to add react-router-dom to the React side. And they wouldn't have 100 people calling them out for the dumb benchmark.
Seems like you should be correct. A shadcn button is just react, tailwind, and @radix/react-slot. But if you simply create a new shadcn Next.js template (i.e. pnpm dlx shadcn@latest init) and add a button, the "First Load JS" is ~100kB. Maybe you could blame that on Next.js bloat and we should also compare it to a Vite setup, but it's still surprising.
Yeah, but my point is that you download the runtime and core of React/Tailwind just once for the whole web page and those should be removed from the test, or at least there should be comparison which includes the both cases.
You only need couple images on your webpage and that runtime size becomes soon irrelevant.
So the question is, that how much overhead are React/Tailwind CSS adding beyond that initial runtime size? If I have 100 different buttons, is it suddenly 10 000 kilobytes? I think it is not. This is the most fundamental issue on all the modern web benchmarking results. They benchmark sites that are no reflecting reality in any sense.
These frameworks are designed for content-heavy websites and the performance means completely different thing. If every button adds so much overhead, of course that would be a big deal. But I think they are not adding that much overhead.
> Yeah, but my point is that you download the runtime and core of React/Tailwind just once for the whole web page and those should be removed from the test, or at least there should be comparison which includes the both cases.
You think a test that is comparing the size of apps that use various frameworks should exclude the frameworks from the test? Then what is even being tested?
Actual overhead when the site is used in reality? How much ovearhead are those 100 different buttons creating? What is the performance of state managing? What is the rendering performance in complex sites? How much size overhead are modular files adding? Is .jsx contributing more than raw HTML for page size? The library runtime bundle size is mostly meaningless, unless you want to provide static website with just text. And then you should not use any of these frameworks.
It really doesn't sound like ChatGPT’s default voice, though it is pretty good at taking on different voices so in a sense you could say that about almost anything. It does use em-dashes, which people have recently started way over-indexing on as a ChatGPT tell, but lots of posters on HN have been using em-dashes for longer than ChatGPT has existed.
It reads like pretty much every piece of tech marketing/evangelism in the last several decades. Which, sure, ChatGPT nails pretty well if you tell it to do that, but... I don't think that has high specificity as a ChatGPT tell.
I agree with everybody else: it smells like ChatGPT. And I thought this before reading this chain.
Actually, going through their entire profile, it makes it even more obvious:
> Author here. No need to update the resume yet—titles do keep shifting! React’s monolithic style has muddied the waters, making it tough to build clean business logic, prioritize performance, craft CSS design systems, or just focus on user experience. Nue’s here to unblock that—giving each role room to shine with leaner tools, not cramming everyone into the same heavy stack.
> Author here. React’s absolutely mature—no question there, with a skilled team behind it. But the button example highlights something off: a single component outweighing an entire app feels fundamentally broken. There’s clear room for fresh alternatives, especially now. You can see it here on HN—seasoned devs wrestling with React’s wild complexity. Nue’s a stab at fixing that.
Looks like they switch to ChatGPT-mode for most of their Nue replies.
I agree with you this is absolutely ChatGPT output. This should result in instant bans from HN in my opinion. I only come here to hear from human beings.
And yet, over the last year or two, people using ChatGPT to write their comments stand out like a sore thumb. The overall structure, the specific style of using em-dashes, semicolons, and colons...it's blindingly obvious.
Yep, I read through some of their comments -- it is strange. I would certainly like to see people improve their grammar, punctuation, and general consistency; but, let's face it, people rarely care to.
Call me paranoid (because, let's admit it, I am) but... after all, it's the Internet, and it's 2025! There's been enough controversy about the political power of speech over the past decade alone, that I can see people running their stuff through ChatGPT just to stay on the safe side and make things sound blandly "professional": just so they can avoid being taken the wrong way by a random reader who happens to strongly object to some particular aspect of their communication style.
(Goodness knows I've found myself on either side of all that at different times -- personally, I find it highly inauthentic to make noncommittal "positive" statements in lieu of plain observations. It's absolutely grating; while some other people seem to require it, and can be indeed quite self-contradictorily harsh about it.)
I can definitely see a major use case for LLMs there -- though I do find the implications quite terrifying. Call it political correctness, call it jamming stylometry, call it a day. Either way there's definitely some sort of power differential here that needs to be examined and I think the world is less prepared than ever to confront whatever its meaning turns out to be.
Which brings me to my other point:
>To be clear, I don't really care, I use ChatGPT all day every day, but just letting OP know it's often pretty obvious when you have it write for you.
Now this I don't quite understand. Pointing something out ("letting someone know") generally implies you want someone else to care about that something, even if you honestly don't. So, since you don't care -- why is it that you want others to? Honest question.
Isn’t using compressed numbers pretending that network bandwidth is the only cost of bloat?
All that JS, once decompressed, needs to be parsed and actually evaluated. That is where it hurts even people on gigabit connections.
I think frontend bloat has arrived at such an absurd level that it kind of makes me wish broadband and mobile speeds, and JS engine speeds, had paused their advancement for 15 years so that FE developers would have had to learn to write good code. Presently there is a whole generation of developers who built their whole careers in this era where you can get acceptably mediocre performance even with wildly inefficient code and an absurd amount of dependencies, most of them barely used on a given page. They’ve never been challenged to do any better, so i don’t really blame them.
before React took over, "SPAs" were written with jQuery and Bootstrap, and it was common to see a project with multiple copies of different versions of jQuery. Totally possible to bloat a website without a framework. just go old school!
Downloading =/= executing. Downloading 60 kb of compressed JavaScript isn't the problem, the problem is running that JavaScript, and all the resulting web calls that JavaScript will do, and all the resulting compute it will take to... I dunno, make the button round or whatever. Load time is no longer a solid metric for a good experience, that's very late 00's of anyone to say, the metric now is how long until the page is laid out, and the controls on it are responsive?
absolutely. page performance is the result of a hairball of initial asset loads, AJAX calls, ad-hoc roundtrips, telemetry bloat, ...
It's so convoluted, and very app specific. Core web vitals provide the right framework to think about what is relevant, but in reality your app likely requires dedicated instrumentation to capture these phases accurately.
It's gonna sound elitist but every one of these confident assertions on the part of, for the purposes of discussion I'm assuming are defensive React developers, reinforces that a sizable contingent of the aforementioned developer community has no grasp whatsoever on the fundamentals of programming.
Hate me if you will, but holy fuck. "Downloading this code takes WAY more time than running it" with NO parameters whatsoever on what the code is doing is an absolutely ridiculous assertion.
No, it comes across as if y'all are having a bad faith argument about something outside of your field of expertise...
Most React apps don't put an infinite loop in their components. The vast majority of the time it sets up initial state, maybe sets up a skeleton while loading some customer data, then shows a page with a few sections and a dozen inputs.
So "holy fuck" you should probably calm yourself down.
I'm not happy about how bloated most React sites are, and I've mostly stopped using it unless clients specifically request it after years of it being my main framework, but...
> The issue is that these huge frameworks have made the web a horrible slow mess.
I don't think this is accurate. Most bloat in the web is caused by:
a) developers don't taking any time to optimize, lazy load, cache, minimize dependencies...
(This is partly on React, or may be on the culture around React that has made all of this normal and acceptable.)
b) the 300 tracking scripts every site has to try to squeeze as much revenue as possible
(I remember being shocked, some years ago, when I saw a site with 50 trackers. May be it was The Verge? Or some newspaper? Now I don't even bat an eye when the number is in the hundreds.)
React sites can be extremely fast if the developer cares, and the bloat it introduces is rarely relevant. The OP article describes a button as 78K, but that's because it's loading the whole of react for just a button.
If your page has hundreds of buttons, you don't bring 78K hundreds of times, and so complex sites built with React are not that inefficient.
As a Devops engineer, do you have stats on how much of that slowness is the framework or the actual app code?
> a) developers don't taking any time to optimize, lazy load, cache, minimize dependencies...
> (This is partly on React, or may be on the culture around React that has made all of this normal and acceptable.)
Yes, that, too. But you are forgetting that React makes all that opimizing work necessary in the first place.
Networks are fast. Machines are crazy fast. Almost 30 years ago I was doing on-line adaptation of Postscript print files. So some form input and re-rendering the Postscript with the updates from the form values. Basically instantaneous.
Well, it depends on what you mean by “fast”: bandwidth or latency? While the bandwidth has improved enormously over the years, latency… not so much. And it never will due to the simple fact that the speed of light is limited.
Most of the slowness seems to come about by treating latency as something that doesn’t matter (because the testing is done on a local, low-latency network) or will improve radically over time because bandwidth did (which it will not).
Unfortunately, React wants to be both a rendering library and also manage state by tying it to the component lifetime, which encourages cascaded fetching - exactly the kind of workload that is sensitive to latency.
His point isn't "network/hardware is fast, so let's be inefficient": it is the opposite. "network/hardware is fast, so why is the page still slow?". On lower powered devices and slower networks, it's even more vital to author lean applications and web pages — but "things are slow even when the hardware and network are fast" is a simple canary that we are swimming through some problems.
> a) developers don't taking any time to optimize, lazy load, cache, minimize dependencies...
> ...
> b) the 300 tracking scripts every site has to try to squeeze as much revenue as possible
Having seen the dynamics up close, I'd say it's far closer to the truth to say that the reason developers don't have time for a) is because they are having to spend all their time on things like b). I've not met a developer who doesn't want to build a better experience. I have met many developers who can't do so, for reasons outside their control.
Characterising it as "if the developer cares" puts the blame in entirely the wrong place.
It's both. The majority of web developers today suck, plain and simple. They thought they could make a lot of money doing web dev and don't approach engineering as an art form or a science. They just scrape by and do not level up on their own outside of or during work.
I've had to come in and rewrite apps before where the developers had full leeway and still produced an unmaintainable behemoth of third-party components loosely taped together.
Also, React is a nightmare. An absolute minefield with zero cohesive vision, with an ever-changing API and a culture of shaming developers who haven't switched to the new React paradigm-of-the-year. For a framework meant for serious adults, I'd check out mithril. It's small, API-stable and intuitive, and gets right out of your way.
I think React is a “nightmare” in similar way that JavaScript is a ”nightmare” - it certainly can be, if you abuse it, and it makes it a little too easy to do so.
However, you can take “just the good parts” and ignore the rest. For me, that means using React as a rendering library and managing state almost entirely outside of it.
I've introduced mithril at three different companies to audiences of non-UX engineers and it went well each time, resulting in small, static, API-driven single page applications. For my Software Engineering class, I'm able to get the basics across in a day and let students iterate without having to set up build tools for them. Huge fan.
React seems to be a self-perpetuating ecosystem at this point, and I keep reading about the next framework-of-the-month being tied to a specific vendor or having an uncertain future with funding/bugs/forks.
If I were making a component rendering type library before React I would probably end up making some fake attributes on HTML elements the way Angular and a lot of other people do. It's a pretty simple idea. Pretty much everybody was doing it about the time of Backbone and Angular etc. etc. I'm sure you can think of other examples.
But whoever first came up with JSX said hey, if we're already making non standard HTML why not go all the way, allow you make your own semantic tree that we "render down" to HTML.
This of course allows you in fact separate out the media target - HTML, Native App, PDF, graphics from your renderable representation of that in code, and thus have different renderers for the same declarative way of structuring content.
So to me JSX is actually a sensible step up in abstraction layer, although not all the way yet, because you still need to have lots of specific knowledge of your particular media rendering target.
This is perhaps of particular interest to me as in about 2004 I was working on a media management system where the idea was you would feed in multiple markup formats, and a configuration for the media, and then use an in house declarative language to dynamically do things in each media, without having to have much understanding of how the media worked internally because our rendering pipeline took care of that - generated pdf, DHTML website (fancy menus), HTML help, and emails - with of course possibility of saving data for reuse in different media and cross media styling (use same company logos, color schemes, email addresses without having to write code for them in each media etc.)
I would never want to write template files in something other than JSX at this point. Every library that does binding via HTML attributes is a huge step back, as far as I'm concerned.
I'd also say React's one way data binding was a big step forward when it was released. Where it (and TBH, many other SPA frameworks at the time) missed the boat was form handling, which it turns out is like 90% of the Internet and internal applications.
I wouldn't say it's 90% (although my last quibble regarding percentages in this very thread got downvoted to 0) but it is tedious and sort of difficult because of the tediousness, but not sure I have ever seen any solution for forms that made me say, damn I like working with this.
What is truly remarkable about it is that it’s just JavaScript (after some transpilation), which means you can easily use JavaScript’s control structures. Conditional rendering has never been so easy!
Dev: Hey, I added that screen you asked for- take a look and tell me what you think- any layout changes, wording, etc.
PM: Looks great! Okay, the next thing is...
Dev: Hold on! I need to go back and clean up some of the code I put in there to test a few ideas, and there's a loop in there that has some side effects if some if the timing is off.
PM: This looks fine. Let's move on to the next thing..
If the PM is like that, the dev should eventually learn not to speak up until they're ready to move on to the next thing. To be clear, the PM should listen to the dev.
But the system persists because both people are complicit.
When starting from scratch: yes. When maintaining a mature application: no, because then you need to keep in sync the app and balsamiq and there is neither the time nor the will for that. And the money.
One screen per paper I print with special guides. So, I've got various resolution represented. The I just take pictures of the drawings, load them into this webtool and connect them together.
I’ve worked with plenty of developers who will argue that it’s fine on their development environment and their machine on the same network with test data and that it must be $OTHER_TEAM who is causing it. Arguably more of them than ones who really care. The problem is it only takes 2-3 of those people to bring the whole thing crashing down.
I would go farther and say it's not even a lack of "optimization", it's a bloat of spaghetti logic that no sane person would ever write, driven by teams that don't talk to each other and are constantly pushed by stakeholders to add more layers instead of cleaning anything up
It has nothing to do with the frameworks. Except maybe that they empowered developers, including the ones cranking out bad code
Exactly. If it's a common enough occurrence that most React SPA's are slow and bloated, it may not be the framework's fault, but if changing to a simpler framework makes it better, then it's just a semantic argument
> the 300 tracking scripts every site has to try to squeeze as much revenue as possible
Just the other day I was appalled by a new record, 1604.
I'm increasingly of the opinion this stuff needs to just be banned outright by law. None of the businesses I've talked to seem to be aware of how dishonest it looks to say "we value your privacy" while trying to get users to agree to get more companies than there were pupils in my secondary school to analyse them.
But for this to be effective, the browser should be cooperating and working on the user’s behalf to limit tracking. (You know, the whole reason why WWW calls it “user agent” — it should be on the user’s side.)
Unfortunately >90% of browsers use an engine made by the greatest beneficiary of user tracking. Hundreds of billions in future profits might be endangered by giving users actual control. The proverbial fox guarding the hen house.
> the browser should be cooperating and working on the user’s behalf to limit tracking
I hear Microsoft is working on a new browser that gives the user more control over cookies:
1. It shows a confirmation dialog before setting a cookie
2. The site can declare a machine readable policy (P3P) specifying what the cookie will be used for, which the browser uses to automatically decide if the cookie should be permitted.
They plan to call it "Internet Explorer" or something.
Where do these 1600 trackers even come from? Does every text writer add their own in the CMS? Is it not managed centrally? Or does every web component load their own flavour?
I didn’t even know there were 1600 different distinct trackers around.
Did the page have any ads? Because ads themselves often also contain lots of third-party tools, for fraud detection, the bidding part, tracking, retargetting...
>the 300 tracking scripts every site has to try to squeeze as much revenue as possible
Let's say tracking for revenue is required and not an argument to be made. The question I never quite understand is why cant we have ONE scripts to rule them all? I remember there was a company / services that may be called Segment? And quick google search doesn't have anything familiar, that offers something like that.
Nobody trusts anybody else. The site wants to over estimate clicks, the advertiser wants to under estimate. Of course the numbers won’t match up because you lose people along the way. If you have 300 trackers they can’t all be lying to you.
>The site wants to over estimate clicks, the advertiser wants to under estimate
Only if you show the ads. Many companies do not, but still use lots of trackers. Why? Because their performance marketing team is trying to find the right mix of advertisement channels, so they go for paid search and clicks to Google, Meta and lots of other AdTech. In that case trackers are needed to optimize spending by analyzing user behavior. If certain cohort spends more time on the site, they will get more ads of it. If another cohort leaves the site quickly, they will see less ads. The promise of AdTech in general is that they personalize ads as much as possible to reduce your customer acquisition costs (CACs) - you won't waste money on showing ads to people who won't buy your product. So they need the data and they have to own it, because personalization is their competitive advantage.
Arh! That makes a lot more sense. Thank You. Sometimes I do wish I could learn a lot more about online advertising. But it is mostly a forbidden topic on HN.
1. React is bigger and slower than it needs to be. There are likely better choices today.
2. Most websites will be bigger and slower than they need to be due to the endless September of new devs, and the rarity of being given space to focus on size/performance. As React is popular, it means even if React was tiny and fast, these websites would still be slow.
Why would React be bigger and slower than it needs to be? It's a very mature project with a professional development team behind it, I'm sure we can trust them to tackle whatever unnecessary bloat they may have. I think we should be able to trust that anything that is in there serves a purpose, and that it serves hundreds of niche edge-cases that someone will eventually run into but are non-obvious until it's widely used.
These kinds of statements are only true if you're willing to sacrifice in other areas such as maintainability, security, stability, compatibility, accessibility, extensibility or something similar.
I understand your answer is in good faith, but it still sounds like the same generic answer given when someone questions the engineering quality of any other popular product or service.
The fact is that plenty of teams are mature and professional and yet most software still suffers from bloat, slowness, bugs. Why would React be different?
Preact, for comparison, is only 5kb or so, and has almost 1:1 feature parity. It's not fully drop-in without the compat, and even experienced React devs can nitpick about it, but that's not the point: the mere fact that it exists and gets the job done is enough to raise doubts about the need for React to be quite big.
Does React need to lose weight? Maybe, maybe not. But I don't think it's good to shut down those discussions.
I think the same generic answer _does_ apply to most mature projects. Libraries like these should be approached like discussions about starting over in mature software projects; "this time we'll do it correctly", or "this framework is much simpler". This applies very much to libraries such as these.
When the complexity is low, projects are easy to learn, maintain and handle. That really makes them seem better and have advantages – advantages like a much reduced bundle size. But these new setups just don't do the same thing. It's a shell of what the old project did, as it's missing solutions for hundreds of edge-cases and other requirements that were tackled by the mature many-year old project that is maintained by some of the best developers. I'm sure React has a bit of bloat, but I'm willing to trust the React team that the vast majority of it is there for a reason. It might also be the cost of building on top of a very mature solution.
Would you not shut such a discussion down when someone new in the team proposes a complete rewrite?
Preact does not have 1:1 feature parity, if it had it would have been much more widely used (who wouldn't want a free filesize reduction?). Preact has plenty of issues, which is why it isn't as widely used.
No, I would not shut down discussions. I appreciate new points of view, and I’m fine with being challenged. I would especially not shut down discussions when my assumptions are nothing but a hunch.
> Preact does not have 1:1 feature parity, if it had it would have been much more widely used
Like another poster said, this is a logical error. Preact is fully featured.
Author here. React’s absolutely mature—no question there, with a skilled team behind it. But the button example highlights something off: a single component outweighing an entire app feels fundamentally broken. There’s clear room for fresh alternatives, especially now. You can see it here on HN—seasoned devs wrestling with React’s wild complexity. Nue’s a stab at fixing that.
> a single component outweighing an entire app feels fundamentally broken.
I think this is an overly dramatic take. Of course react has a fixed overhead. If all you're deploying is the single button, then that overhead is for no benefit. But the overhead gets amortized over your entire app, which most likely has thousands of components. This is like a microbenchmark which only measures the static overhead. Not indicative of a real app.
There's an entire cottage industry of "react" but smaller frameworks out there. Somehow, none of them have caught on.
Preact is the one I'd go for if I wanted a smaller react because it's quite mature and it provides the same API.
> a single component outweighing an entire app feels fundamentally broken
It just doesn't to me, understanding that in react-land, a single component and an entire app will have roughly equivalent size, if you're not pulling in any other dependencies.
No one (I hope) would ever use react for a single button, so it feels like an unhelpful comparison.
I don't think that is fundamentally broken. React is just not the right technology for a single button, and it's not trying to be.
If you tried to use photolitography (the technology used to print the circuits in microprocessors) to do tattoos... well it could probably work, but it would be highly inefficient and expensive and bad.
React is for complex web applications, and it I don't think it's a very valid criticism to say that it is bad for a different use case. To some extent, the React community may have over-promoted React as the final web-dev framework, but that's also a mistake.
In any case, kudos on creating Nue, looks really cool, I'll keep an eye on it ;)
Is it really React or the stuff it lets you bring in? Many React apps have at least one big widget set (say MUI or reactstrap or …) and then a number of “best of breede” components that do various things. It’s rare for components to be styled with plain CSS these days so you probably have to bring in Emotion and styled-components and Tailwind and …. It is all code that goes into the bundle and it’s a burden on your mind because these are all leaky abstractions and don’t absolve you of understanding CSS.
A someone who's been developing for the web for a living since the late 1990s, I agree that nothing absolves the web developer of the need to understand web fundamentals. But laying blame for bloated SPAs at React's feet is misplaced. With SSR, you can ship React apps that work with JS disabled. And with static extraction (a la vanilla-extract) you can do CSS-in-JS with 0 runtime overhead. Being mindful of bundle size and user-perceived performance is essential. For those that pay attention and leverage the web properly as a platform, amazing performance (and capabilities / UX) with React is achievable. See https://Remix.run.
If Preact truly was as feature complete as React, it would be used by everyone by now – it's old enough for most teams to be aware of it. The fact that it isn't widely used is case in point.
> If Preact truly was as feature complete as React, it would be used by everyone by now
That's a false logical conclusion.
Preact (and others, like Svelte and Solid) are not only "as feature complete as React", they don't need some of the features of React (hooks are unnecessary when you have proper reactivity) and they are better at certain features (like SSR).
People using or not using them has nothing to do with feature completeness.
Fair enough. The quoted statement doesn't hold outside the context of the argument that Preact has feature parity. You can build the same apps with Preact and those others, you just need to sacrifice other things.
I get what you're trying to say, but aren't you blowing it a little out of proportion? At my job we have an SPA that loads a dashboard with 20+ widgets, all doing their own requests, transferring 2+ MB (compressed) of JS. It loads in two seconds, with all caches disabled. And I mean full load, not "ready for interaction". It runs on Vue 3.
I agree that the web could be lighter, but "finding one that will do a first load under 10s is close to impossible" sounds like exaggeration - it might not be due to the framework or lack thereof.
Btw, the webapp I'm describing is NOT built by the best of the best.
Now test it again on a 5 year old mobile device on a 3g connection with some packet loss, not in the sterile environment that is your office with a last-gen i7 processor.
Well, the post I replied to said "on a 10G connection peered within 5ms of the host" so I think it's fair to assume they also were in a sterile environment. I'm even on a lower connection with 20ms+ ping!
5 year old mobile isn't as slow as you make it out to be. Cheap 2025 phones is significantly slower than my 8 years old iPad. Also 3G could be fast and it isn't the protocol that makes the speed to <1Mbps.
The thing is, enterprise web applications are not built for phones. This would be like telling someone to run the latest Ubisoft game on a PC from 2-3 generations ago, and expecting it to perform well.
Today's applications are more complex than ever, bloated perhaps, but the demand for features, complex visualizations, etc. rise with the patterns of seeing them more in other applications.
This. So many people—both on the dev side and the annoyed HN commenter side—act as though all websites have the same requirements. They don't. The usage profile varies enormously, and if you treat every website as just a website without considering the context it's used in you're going to either waste a lot of time optimizing things that don't matter or you're going to make your app suck by not adjusting properly for your users.
It's not just 2 MB of JS. I'm describing ALL traffic, also the JSONs received, CSS, images, everything.
Besides, we show many charts, and believe me when I say: financial people are PICKY when it comes to chart functionality. It needs to have EVERYTHING or you're not considered serious.
It sounds like you're developing a turn-key highly interactive application for a very particular niche of users. It makes sense that for them the tradeoff of downloading 2MB of Javascript makes sense versus enjoying their bells and whistles.
But for the rest of the internet, where users sometimes view your page with decrepit browsers riding on hobbled connections, 2MB is too much. Worrying about these people is not blowing it out of proportion. It's basic human decency.
I think you are mostly describing the difference between a web application and web site. Where lately frameworks for building web applications have been used to build web sites.
Sure, but I think there are devs out there that are making that confusion, and parent comment I responded to seems to not be aware of the difference. You know it's not the guns that kill people, it's the web devs.
Yes, because you're rebutting to a post about light(er) web components by saying that we're blowing it out of proportion since your specific case with very specific users can work with 2MB of Javascript. You gave no indication that you're aware of other use cases that will benefit from these smaller frameworks, and even though I am aware you can't put in one couple hundred words post everything about your knowledge you showed zero empathy towards web users that are different than yours. Apologies if that's not the case, I still feel like it's a discussion worth having. More so if you agree with my words.
Heh, I just literally built a toy dashboard in dioxus that loads just about 2MB of code, and then 700KB of css (tailwind, not optimized) and 1.5MB of payload data to visualize.
Then again the 2MB includes ~1.7MB of just static data that I included in the wasm build for convenience since it will always be needed. :D
(this was a learning project in my free time, no I'm not defending this in any way, although I'm actually quite happy with the solution of including static data in my binary)
It's interesting. I believe many of the people here know how it goes. There's no possibility of shrinking this further. It will only expand; we just have too much going on. We do have a genuine use for SPA, though - our webapp IS as complex a web-app can get, we offer no mobile version (for that, get the app).
Transfer's only part of the story (and 2MB is a ton on anything but a great connection)—the rest is memory use, which will tend to be some multiple of the transfer size, plus whatever your code initializes, and processor cycles.
> I see a lot of people angry at "Nue" in various ways
Interesting. I see people making overlay-broad claims without evidence or justification.
> I deal as DevOps/SRE daily with these services, and finding one that will do a first load under 10s is close to impossible
Nobody is going to call in for your help unless something is wrong, so don't be surprised you haven't seen anything right. That just means people are keeping the good stuff secret (and/or they don't work for your company)
> I can't help but think these are people heavily relying on React and missing the overall issue.
That's too bad.
I think that everyone who works on a slow project knows it's ultimately Management's fault, and when a codebase gets so big that nobody feels like they can fix it anymore, that's Management's fault too.
Maybe you can think if Management called you in earlier you could've designed a better thing, but guess what: I think that would be Management's fault too.
> but I can at least root for them
Can you imagine if any of what you said was really True, everybody believed you, and everybody actually stopped using these "huge frameworks [that] have made the web a horrible slow mess", and that actually solved "the overall issue" so that all software is perfect and reliable? What exactly do you think a SRE does in this case? Do you think that's even a job?
I really suggest trying to look at things differently, because I think for your skills there's a huge opportunity sitting right in front of you if you can see it.
The real question is, do we actually need "frameworks"? Pure JS works pretty well, and no JS at all even better.
I recently worked on an SAP project where there was a whole Java layer in front of SAP, and then a huge Angular app on top of it all; but since the point of the application was to manage b2b sales of physical things and it mattered very much whether those things were in stock, almost every screen did a full request to the SAP layer. The need for a thick "rich" client was unclear, and PHP would probably have worked much better.
Hype aside, it seems big organizations are using frameworks as a mean to ensure uniform coding practices and make developers more easily replaceable; but surely there are better ways to achieve that.
Not every page or app needs framework. But building complex app without one would be very hard and time consuming, and your team would need to come up with ways to solve problems like architecture, code structure, routing, data management, state management, etc. So you would basically reinvent all the wheels on your own cost, and you will have a non standard solution, that would not be compatible with libraries out there (for example UI components) and neither with new devs. Before Angular and React came I was building apps with plain JS with jQuery (not a framework, just a lib) and I would never go back there.
I agree. In a recent small project, I ran an experiment: first, I built the app in React, then in Vue, and finally in vanilla JS. In the end, I stuck with the vanilla JS version because it was significantly smaller, easier to deploy, and much simpler to maintain long-term.
As someone who's worked on web apps with and without frameworks, yes, we need frameworks, especially if it's a large one or if there's a team of more than a few people involved.
The good ones these days like Vue or especially Svelte are barely any different to how you'd do things the "vanilla" way except they provide some sane QoL features like components (anyone who says web components are the answer has very obviously never used web components) and sane data flow management to and from said components.
I mean, more power to you if you want to handle complex states without the features a lib like Vue or Svelte provide you, but in my experience you eventually end up with a homecooked framework anyways, even for apps that aren't that complex. And at that point you're just doing React or Angular or Vue, but worse in every conceivable way. Yay for going at it vanilla, I guess?
I always had an issue with that sentence (and I heard it a lot).
Why would experienced software developers always come with a solution worse in "every conceivable way" when implementing logic answering a problem they're having, which would have the huge advantage of being tailored for their own needs?
I'm more of a library developer than an application one but I've seen that many JS webdevs have an aversion toward trying things themselves - instead always going for the most huge/"starred" dependency when they can. I'm not sure the impact of this philosophy is always better for a project's health than the total opposite where you would just re-invent your own wheel.
I do have seen multiple attempts at doing a specific homemade architecture that worked out well for some applications with very specific needs even 10 years later (For example I'm thinking about a 500k+ LOC JS webapp - not intended to be accessed on a desktop browser, but that's not the only successful long-lived JS project I know with their own archi).
And I guess a lot of webapps do have their own specific needs where the "default framework" solution leads to some inefficiencies or hard-to-maintain / understand mess.
> I mean, more power to you if you want to handle complex states without the features a lib like Vue or Svelte provide you, but in my experience you eventually end up with a homecooked framework anyways
If state needs to be managed client-side (which is not always the case), then yes, a library is helpful. But a "framework" provides much more than state management, and those other things are usually dispensable, IMHO.
The advantage of having a common API across thousands of web apps shouldn't be a point of discussion.
We have one. It's called "the browser". The discussion is whether or not we need a higher level API than that. If we do, maybe that should also be a part of the browser's API.
Frameworks like Vue 3 don't actually work on older browsers since it requires ES2016 support in the browsers.. that means IE 11 and older browsers are out. With Svelte you need Microsoft Edge (IE 11 is not supported). Also, it requires Firefox 74 (released in 2020) or newer Firefox versions.
With React, you can make it work with older browsers using Polyfill etc.
> The discussion is whether or not we need a higher level API than that.
Try using DOM APIs to build anything remotely complex or interactive. There's a reason everyone who only uses browser APIs ends up just dumping strings into the DOM via innerHtml.
> Try using DOM APIs to build anything remotely complex or interactive.
I think the core question is: Are we building something complex or interactive. I don't see the need for React or other frameworks unless you're storing a lot of mutable states client-side. But more often than not, all I see is replicating the database through API endpoints.
Spot on. HTML, JS, and CSS deliver a clean separation of concerns—a perfect blank slate for killer products. You just need a few key pieces to tie it all together: templating with loops for repeating HTML chunks and a way to stitch in headers, footers, or sidebars. For apps, a routing system is a must. And HMR to supercharge your dev workflow. That’s Nue in a nutshell.
>> HTML, JS, and CSS deliver a clean separation of concerns
> There's nothing clean about this separation, and concerns are never as neatly separated as people pretend they are.
It's very clean and something repeated by almost every UI framework and document system. The separation is between structure, style, and interactivity. Most web apps actually fits the document models where you have content pages and forms. But people wants to bring desktop and game UI patterns into that. And make it a mess.
> something repeated by almost every UI framework and document system.
That is, hardly any UI framework separates these things. From Windows APIs to SwiftUI there's rarely a system which tries to separate these concepts. Because however hard you pretend they are separated, they never are.
> Most web apps actually fits the document models where you have content pages and forms.
Even in a document your styles are linked to the structure of your document.
> Because however hard you pretend they are separated, they never are.
That would hold true for whatever systems. The pretention is just for making it easier to do the job without extraneous effort. Cascading is a nice pattern for applying properties in the case of a document. JS was originally intended for scripting (not for full-blown application) and the DOM API works fine for that. Without that, we would have to put everything in HTML or have something like Flash.
Remember how you started with how every UI system and framework was somehow this separtaion of style and presentation and structure and interactivity?
And now it's "they are never separated, and this holds true for whatever systems"
> The pretention is just for making it easier to do the job without extraneous effort.
In reality there's a lot of extraneous effort especially when systems become more complex. BEM was invented not because CSS was great and amazing at reducing effort, but because it was adding a great amount of effort for a very large number of designs.
CSS Scoping was finally, thankfully, added not because cascading nature of CSS reduces a lot of effort.
The rest of your comment has nothing to do with what I said.
> And now it's "they are never separated, and this holds true for whatever systems"
What I described as separation is a a decomposition into modules which are linked together through a contract. CSS has cascading and selectors, while JS has the DOM API. Otherwise, it would still be attributes on tags.
BEM is just a development technique, not a technical requirement or capability. Without cascading, we would probably have components and inheritance.
> Remember how you started with how every UI system and framework was somehow this separtaion of style and presentation and structure and interactivity?
On Android and iOS, you have XML for layout. QT and GTK have support for CSS like styles. I remember at least one of the have supported XML for layout definition. They're not required, but they make it easier to build the UI as it almost always have a tree structure.
Your comment shows that you don‘t have a lot of experience in that matter. „Pure JS“ (there is no such thing) has perhaps the tiniest standard library of anything out there. The rest is browser vendor code, of which a lot depends on browsers and versions. Hell, they didn‘t even get date parsing right.
I worked at a startup where one of the original devs had “strong opinions” on JavaScript frameworks. “It’s all bloat!!! We don’t need that crap”. So consequently all the new engineers had to learn this dude’s codebase, which turned into to be… A framework! Only instead of a documented one that had plenty of support it was an unholy mess that required extra time to build all the stuff missing from the it’s-not-a-bloated-framework-but-pure-JavaScript-framework.
Guess what happened the day after the dude left the company? All the engineers immediately started to replace the unholy mess of “totally not a framework” framework with an actual one.
Guess what happened to development productivity and product quality? They went up dramatically.
IMO, this framework is built for use cases normally handled by React-based static site generators. For instance, a simple marketing site for a company. In these use cases, React is obviously an overkill. You wouldn't want your users to download, parse, and execute 2.8 kB of the React runtime just for simple buttons, tabs, and routing.
However, I don't find this framework suitable for more complex state-driven applications. If you want to build X's front end with this framework, you're just shooting yourself in the foot. It won't take an hour before you hit the framework's design limitations.
Author here: You’re right that Nue shines for simpler sites—like marketing pages, blog, and documentation. But calling it just a static site generator misses the mark. This latest release (check mpa.nuejs.org/app/?rust) handles a Rust-powered SPA with event sourcing over 150k records—far beyond ‘simple.’ For state-driven apps, Nue’s model-first approach keeps things clean and scalable—limitations are there, sure, but they’re not the foot-shooter you might think. Right tool, right job—totally agree—just saying Nue’s toolbox is bigger than it looks!
> Nue’s model-first approach keeps things clean and scalable
Like I understand why you say this, but as someone who spent the 2000s building "model first" web apps (and desktop applications), I don't miss it in the slightest. Immediate mode-esque render loops didn't catch on just because it's a fad, it really does fit a lot of highly interactive things better.
Of course the bigger problem is people using something that's great for heavily interactive web applications for building things that _don't need_ that interactivity...
Nue looks great, and I think it stands on it's own two feet. The constant React bashing just turns me off it more than anything (and that's not about React specifically, I have no real love for it, just that kind of project marketing isn't my cup of tea)
> Web SaaS companies just wanting to use "common" frameworks
Companies obviously want to use what works well and been tested and tried in production. If Nue achieves that with significant benefits outweighting the migration costs it will become the new common.
The "problem" with React is that it improved developer experience and efficiency by a ton compared to what was there before it, and not because of anything else.
I often hear it said that devs should use slow machines and connections for development. That's a great idea (and it can be simulated) in theory, but in practice very few people are going to buy old ThinkPads to test on. So a solution should probably be done in software, i.e. at the level of compilers and runtimes.
i.e. if JS engines weren't so fast, bloated frameworks would be impossible, even on dev hardware.
So I'm wondering if just like C++ compilers have optimization levels, perhaps there should be negative optimization levels, where all your code runs 10x slower by inserting dummy instructions (or perhaps a browser for testing that uses a naively implemented JS engine).
This would allow you to directly experience the pain you're causing without leaving the comfort of your fancy dev machine.
Then again by the sound of it, the release build of the app running on v8 already takes 10 sec to load, so we have already achieved the goal of gross lag without special tooling, so clearly people just don't care (or are working in systems where they feel powerless to fix it)?
The context of what the application does matters. I'm extremely cautious when people hype up "download sizes", when such size is less than 1MB, because this is usually a sign of cosmetic obsession and/or disassociation from the real world value offered.
A 200-300kb "bloated" single page app which does the job of a 10MB "minimalistic" downloaded store app – is IMHO pretty incredible. It's doing the same work at nearly 1/50th the size, all else being similar (externally loaded images and stuff). Heck, even a 1MB page load size is still 1/10th smaller.
Sure, it can be argued that the browser does most of the heavylifting. The same can be said of Android or iOS too, definitely the OS offers _even more_ heavylifting than the browser.
As I wrote in my comment it's a cool project but the way it's presented as a takedown of React is so ironically wrong. People pick React when they need a rendering layer and want to write the rest themselves. People who need a monolith SSG that is optimized for this thing choose Vue/Astro/Next and the like and that is Nue's niche. If you write a rendering library that beats React at its use cases then be my guest please brag about it
Thanks for the take—glad you think the project’s cool. I get where you’re coming from: React’s a rendering layer for folks who want control, while Nue’s tackling a broader scope, closer to Vue/Astro/Next combo. The ‘takedown’ vibe isn’t the goal, though—more like highlighting how web standards can slash bloat across the board, even for something as ‘simple’ as a button. Nue’s not here to just beat React at rendering; it’s rethinking the whole stack to avoid needing so many layers in the first place. Fair point on use cases—definitely food for thought as we push forward
Cool, good luck! Building on top of Web standards is definitely a great idea and your (non-Rust) demo is pretty good. If I wanted to build a static webapp and was in the mood to play with something new I might try it.
So far this "re-thinking" is just dumping loads of innerHtml's and trashing the entire DOM.
The only reason it's fast is because browsers have been optimized beyond any sane reason.
E.g. your table demo removes and re-adds all rows on every button press. This is not re-thinking. This is throwing all we've learned out of the window and starting from scratch.
> I deal as DevOps/SRE daily with these services, and finding one that will do a first load under 10s is close to impossible
I am currently in Indonesia on extremely flimsy and slow wifi at 1-2 bars that maybe tops out at 50mbps on a good day if no one else is on it and the gods align to grace me with a decent speed. Day-to-day, it's around 25mbps.
Doing a hard refresh of Linear (not affiliated in any way other than using them for work, but I know they use React), a complex project view that includes many graphs and other things like that, the full load time for everything on screen is 5.6 seconds with ~15MB of content loaded (this includes images and interactive graphs). DOMContentLoaded finishes at 360ms and the full interactive load is finished at 600ms, with me being able to click on tickets and navigate to them at the roughly 1s mark or less. Back home Linear load instantly for me with full interactivity, and the cached version of it even here in Indonesia is similarly fast.
It's not the frameworks slowing things down, it's usually all the bullshit that the business forces on its users that the devs have 0 say over. The app I work on loads really, really fast on dev builds that don't have any of the idiotic tracking BS enabled (for example on staging builds, which aren't even fully optimized builds compared to regular prod builds), but because the marketing, data and sales teams want their google analytics and 7 other tracking softwares, the whole thing slows to an unbearable crawl as we load in dozens of MB of packages each bigger than the Vue library controlling the whole thing.
A 10-second load time on a 10G connection??? That’s a peak throughput of 1.25 gigabytes per second. Even if we’re being conservative and assuming you’re only getting a quarter of that speed, that’s still around 3 GB downloaded in 10 seconds.
There’s no legitimate way a dashboard or notes app should be anywhere near that size. That’s not “just a bit of JS bloat” — it’s multiple orders of magnitude beyond what would be reasonable. The claim is not just exaggerated — it’s wildly misleading for anyone unfamiliar.
fwiw, I did not have the same take away as you from that part of the comment. I think the intent, and the way I read it, was, "Even when eliminating bandwidth and latency as a factor it still takes 10 seconds to load."
Indeed. This button comparison is quite telling, ragardless of the exact details. Definitely going to look what Nue is made of. It's refreshing to take a closer look at modern web standards — Nue or not.
> 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.
If you make a React page you will see that it is absolutely instant to do things. React isn't a huge framework. It's a very fast library. Even if you add in all the extras such as routing, it's all instant. It's almost jarring how instant it is.
A dashboard taking ages to load isn't going to be React.
"Instant" can mean different things to different people.
I have an HTMX/Flask/Bootstrap app that feels instant for most requests on the LAN, except when it doesn't.
Often React apps are pretty snappy, but if you want to do complex data validation on controlled forms, where the state updates for every keystroke, it can drag you down. There are good frameworks for doing uncontrolled forms in a disciplined way
but it's another thing to add to your bundle. React is also not fast enough to do animations so you have a lot of .show/.hide (or display: none) CSS has facilities to do transitions and animations that are pretty good but I always find it a little nervewracking for a JS application to have state in React state variables and any other kind of state. Some ImGUI frameworks have components that look superficially like React components but are fast enough to animate every frame, which makes me feel like I am in control and get the animation to look exactly what I want.
> I always find it a little nervewracking for a JS application to have state in React state variables and any other kind of state. Some ImGUI frameworks have components that look superficially like React components but are fast enough to animate every frame, which makes me feel like I am in control and get the animation to look exactly what I want
I know what you mean there. I had the same feeling back when I was doing frontend things.
Last time this was posted, the author called out headlessui for being too complex, and presented a half-broken, non-accessible Select component as alternative.
Digging around the code, I found questionable decisions such as throwing away the entire dom when re-rendering a list.
I want framework authors to be clear about the tradeoffs they make. The Svelte and HTMX devs openly discuss the weaknesses of their solutions vs industry standards and are open about previous mistakes.
I'm a lot more open to "coding in untyped strings" these days, but if you ship yet another syntax on top of html without proper tools (lsp or whatever way for it to play nicely with typescript), then I find it rather lame. I'd rather just write truly vanila js and html, instead of using another "framework", for no apparent benefit.
Nue indeed looks interesting. I could not immediately understand whether it uses a one-way data binding. Without it, and without a reactive model of some sort, building large UIs becomes a pain.
The React-based button from some framework is either over-engineered, or does way more than just a button. Using or not using such a component is a choice.
React may be a bit large (like 30-50 kB for a "hello world"), but preact is below 6 kB and gives you 90% of the React power for lighter-weight apps.
Also, the point of React is building huge and hugely complex dynamic UIs. There are much lighter-weight tools to add small bits of interactivity to mostly static pages, which are still the majority of the Web. (Ironically, HTMX is 14 kB, 2.5 timex larger than preact.)
Anything that forces React off its boring throne of forced ubiquity is a good thing in my book, not only for its lack of optimization, but its unwillingness to move past its outdated APIs and state management patterns. The amount of limitations I've faced using it compared to other libraries / ecosystem is enough to drive anyone mad.
I will say these claims about 10-second load times are highly exaggerated though. I've built several large applications with Vue and React, and once compiled, load within 2-3 seconds, with any remaining time spent requesting data at the mercy of your servers, which is going to happen in any client-side application, including native apps; so this isn't browser technology's fault.
Once cached, loads instantly -- and anyone complaining about cold starts can take their criticism to native app makers for phones, or motherboard manufacturers for long boot times. It's hardly an issue because of caching, and I tend to think the complainers about the modern web are forgetting how much more complex our applications are these days. Raw speed for lack of features? Or a little bloat for more capabilities? Pick one, and accept the tradeoffs. Maybe one day browser tech won't force us to choose.
While there is a case to be made for slow internet connections (this is where Svelte and other compiled runtimes come in with SSR), for the average enterprise using a private SaaS, or home internet customers using public SaaS apps on the web, by-and-large the experience is going to be just fine, unless the team who built the app didn't optimize.
All that aside, it's refreshing to see more ground being broken in the area of speed — I'm all for it.
Well said. The average person these days is mostly buying faster computers and phones so they can run more and more bloated web pages that just get in the way of getting to the text, images or video they want.
Qwik has the right idea for speeding time to interactive for complex web applications. This seems to be doing the same old thing as every other framework.
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
Author here: It’s true—Nue’s view layer is untyped. That’s by design. React’s ecosystem has devs slapping TypeScript on everything—even CSS—which is overkill. Nue flips it: presentation stays clean and semantic, web standards do the heavy lifting, and real static typing (like Rust or Go) shines in business logic where it counts. Thoughts on this?
This is a silly take. There were certainly plenty of large projects written in JS before Typescript existed or became popular, some maintained by small teams or single individuals. There are plenty of large projects written in Python pre-typing, in PHP, etc.
I personally choose to work with typed languages most of the time, and I’m thoroughly convinced of their value, but acting like it is literally impossible to write a large project without types is just inaccurate.
So I should probably preface and say that it is not possible within the budget I have (We are ~2 full time developing and maintaining everything on a 140k LOC platform spanning from infrastructure, backend, multiple frontends).
Yeah, it just means those teams had to do a lot of work themselves which type systems do automatically. Given that the entire point of computing is automating things which a human could have done by hand, it makes more sense to talk about cost rather than capability.
We are not really over worked. Nobody puts in more than 30 hours, and we deliver the features the business need.
However, we do have types and don't do type coercion. Types are sound full stack db -> backend -> frontends. We don't do any funky things. We don't use SSR (as the business does not require it). We test well, but not too much. We keep a sane architecture.
We can also skip out on a lot of project shenanigans and mostly focus on our work.
We don't (yet) use AI as a part of our workflows, and frankly, I don't see we can keep this way of working with the current gen AI.
> There are plenty of large projects written in Python.
There are, but they are certainly a pain in the ass to work with.
I once had to work on a semi-large Python codebase and got so frustrated that I wanted to port the code to some other language. The best part? I wrote the majority of that codebase myself, just months earlier.
Just keep in mind there are a thousand people right behind you who would be ecstatic to be able to work on this "nightmare" in order to earn a paycheck.
This seems incredibly shortsighted. If you're building an application by yourself you're gonna remember the relations and dependencies - but even on a small team (say ~4 devs) or even if you don't pick it up after a while, there is going to be stuff you forget.
It's also nice when you move stuff around, you can rely on the LSP to rename and fix everything that breaks. If you have a simple website it's fine, but when you start to have multiple components... Losing typing is a huge deal.
Svelte team also switched to JS with JSDoc a few months back[0].
You can see the majority of their repo is JS and not TS[1]
The cited reason[2]:
> As a Svelte compiler developer, debugging without a build step greatly simplifies compiler development. Previously, debugging was complicated by the fact that we had to debug using the build step. In addition, using JSDoc does not affect compiler’s development safety because the type is almost equivalent to TS.
There was a lot of noise when this happened. Rich Harris (Svelte team) even had a comment on this on HN[3]. Dev sphere similarly thought they were crazy. But Svelte seems fine and no one seems bothered by this now.
As long as author ships type def, it should behave just like a TypeScript library for all intents and purposes.
TypeScript is not "real" static typing in the same sense as Go, Rust, C#; the type information disappears the moment you build it.
function fn(x: string) {}
Will happily accept:
fn(2)
At runtime (and thus the need for schema validators like Zod, Valibot, et al because dev-land "static typing" is a façade)
> Rich and the rest of the Svelte team are still using typscript
To be clear, they are not "using" TypeScript, it's more accurate to say they are providing TypeScript bindings.
Their codebase (as in the actual code they are writing) is undoubtedly JS[0] with `.d.ts` bindings for TypeScript[1]. Author can also do the same and provide TS bindings at any point in the future.
Had I had the opportunity to choose a language across the entire stack with mature wide adopted frameworks and libraries, I had done it.
Had there been something line Rust, Go, Java, C#, etc. that would work end to end, that would have been amazing.
In practice, even the weak safety typescript provides catches so many bugs before they hit production that it is indeed worth it - I have more than 140k LOCs of Typescript in production, and that would not be manageable without types.
> I have more than 140k LOCs of Typescript in production, and that would not be manageable without types
The Svelte team achieved it with JSDoc. Google's JS style guide also focuses on JSDoc for the same reasons[0].
And to be just a tad pedantic: you have JS in production; your TS is only in dev.
> Go, Java, C#, etc. that would work end to end, that would have been amazing.
It's not that you can't; it's that you choose not to (and yes, generally for good and valid reasons). There are end-to-end solutions for C# (e.g. Blazor), for example, that are perfectly fine depending on your use case (not great for all use cases). Fable is another example using F#[1]
There are also libraries like Bootsharp[2] that are doing interesting things, IMO, and has some of the same energy as OP's project (moving the typing and logic into a runtime that supports runtime static types and interfacing minimally with JS)
> Even for the parts that are being compiled to JS: You wouldn't say: You can not have C++ in production, only binaries.
I would say that because it can be decompiled; the type information is still present. Same with C#. I can decompile the binary and still see the type information.
The process of going from TS to JS is lossy; you cannot get back the type information.
I would absolutely say "I have C++ in production" or "I have C# in production" but not say "I have TypeScript in production". "We build our app with TypeScript" is accurate, but it is transpiled -- not compiled -- into JavaScript. Your Node.js server then interprets that JavaScript and executes C++.
That is not right, When you compile to binaries, you do type erasure in CPP, som of the stuff can not be reconstructed or inferred, especially when using o flags.
JS -> TS is easy, you just re-anotate with `: any` everywhere.
>And to be just a tad pedantic: you have JS in production; your TS is only in dev.
This is not even pedantic, it's wrong. You have JS/TS in both dev and prod, with javascript being the actual runtime code in both, and typescript checking your code at build time in both. If you're running javascript compiled/checked by , and written in, typescript, it's not uncommon or unreasonable to call it typescript.
> Google's JS style guide also focuses on JSDoc for the same reasons
Google uses TS internally. Any JS is strictly legacy code at this point. The link you posted even says this at the top:
> Please note: This guide is no longer being updated. Google recommends migrating to TypeScript, and following the TypeScript guide.
Also, Google's style guides are not really authoritative outside of Google. They are for some people, who choose to adopt them as their own, but you really shouldn't point to them as the end-all-be-all argument-stopper. Google has a lot of its own idiosyncrasies. Their C# style guide puts braces on the same line, for example, because Google primarily uses Java internally.
> To be clear, they are not "using" TypeScript, it's more accurate to say they are providing TypeScript bindings.
Interesting that you say it's more about providing "bindings", and not really "using". Much of the types in the svelte codebase are never exported outside of svelte, and they are only consumed internally.
The problem they were having was with transpilation, since the browser doesn't run JS.
From Rich Harris (months after svelte switched to JSDoc) [1]:
> removing types from your own code is clownish, epically misguided behaviour, but whatever — to each their own
I would suggest going through the issues and PRs in the codebase to see how invested the Svelte team is in typescript.
> TypeScript is not "real" static typing in the same sense as Go, Rust, C#.
That is true for Go, Rust, C#. But the same thing is also true for languages like C, and Generics in Java.
I'm sure both of those languages have weak type systems, but are definitely statically typed.
I think the fact that type information is lost after being compiled isn't really a classifier for typed/non-typed. Ultimately it all comes down to machine code, and that certainly isn't typed either.
You can write a function in go or rust, then write code in assembly to call it with any old nonsense. It is no different. The whole point of static typing is that it happens at compile time, not runtime.
Does Go’s type system perform runtime type validations? My impression was that it does not. But Go probably supports reflection on the type information at runtime which could be used to implement a runtime type validator, right?
> TypeScript is not "real" static typing in the same sense as Go, Rust, C#; the type information disappears the moment you build it.
The type information in both Rust and Go disappears the moment you build it. The generated assembly is completely untyped: if you pass invalid objects to a compiled Rust function that you've dynamically loaded, you will cause problems, even memory safety issues, because Rust does not do any type checks at runtime.
In the same way, if you call Typescript-defined functions from Javascript with the wrong types, you'll get problems. But if you write everything in Javascript, and don't ever use type assertions, you won't have issues. (In practice, I believe there are a couple of other issues you can run into, typically involving variance and mutability, but these are very rare. Also, some older APIs return `any` that should return `unknown`, but that can be fixed.)
It's also worth keeping in mind that all languages have and require schema validation, it just might look different. Both Rust and Go have schema validation libraries - typically they parse the data directly into the correct format, but in Rust you could do something like `let x: HashMap<String, JsonValue> = string.parse()` and get roughly the same effect as Javascript's JSON.parse, it's just that JS/TS has a built-in data structure to represent arbitrary JSON data, whereas Rust does not.
> To be clear, they are not "using" TypeScript, it's more accurate to say they are providing TypeScript bindings.
To be clearer: they are absolutely using Typescript. The functions (and other parts of the code) are annotated using Typescript's extension of JSDoc types, which means Typescript can parse and typecheck this code as if it were "normal" Typescript, including generating type definition files. The .d.ts files in the source code are used to define additional types and interfaces that can be used in the .js files (you can see the first file you linked to import type definitions from ESTree, for example). The type checking step can be seen in the package.json file[0]. This is all explained in the comment from Rich Harris that you linked before.
Using JSDoc rather than conventional Typescript syntax makes writing your source code more complicated, but in this case the Svelte team figured it would benefit them more in the long run to still be writing code that could be interpreted by a normal Javascript runtime. However, it really is just a different syntax for Typescript, and that's how they are using it.
It’s not real static typing. A compiled typescript project is just javascript, which will still gladly accept incorrect types. The types only matter during compilation.
This is the real-est static typing that exists. "Static" refers to build time. By definition static types are checked at build time, not run time. If you want types to be checked at run time, that's called "dynamic" typing.
Sure, you're technically correct. But TS is compiled in to JS, which is dynamically typed at runtime. You're still ultimately in a dynamically typed language.
In addition, in a typical statically typed, compiled language, your only place where you interact with data that isn't guaranteed to be type-conformant is at a foreign function interface, whereas in Typescript all your interaction with third-party libraries is via regular JS and may or may not be type conformant.
Rust compiles into WASM, x86, etc, which are dynamically typed for all intents and purposes. They certainly don't understand or enforce Rust's type system invariants any more than JavaScript enforces TypeScript invariants. If you call a Rust function from WASM and pass it malformed data, the WASM runtime will happily execute it.
(pretty sure WASM actually has some integer types, so I guess maybe it is technically "statically typed" but not in any interesting sense--we could similarly say that JavaScript is "statically typed" because every variable has a static "any" type).
You're confusing "real static typing" with runtime type information. TypeScript has "real static typing" (if you disagree, ponder for a moment the meaning of "static"). A TypeScript program cannot natively query the _TypeScript type_ (not to be confused with the corresponding JavaScript type) of one of its variables in the way, for example, Go can. But neither can C, or C++, or Rust, all of which are unquestioningly statically typed.
Svelte is a bad example. They have roughly identical type checking before and after that switch. The switch is mostly just an aesthetic preference for one syntax over another and an ideological stance about being able to run code directly in a browser without a build step.
I have been doing pro webdev since 1995 and since I got my initial experience without all of the contemporary tooling, my process has evolved to require very rapid iteration: the delay of a compile step can often break my concentration and prevent a flow state.
> Svelte team also switched to JS with JSDoc a few months back
1. They still use types via JS Doc
2. They only switched to that for their internal development
3. User-facing code has all the type support and TS support you'd expect
> Rich Harris (Svelte team) even had a comment on this on HN[3].
And here's literally what he said:
--- start quote ---
Firstly: we are not abandoning type safety or anything daft like that — we're just moving type declarations from .ts files to .js files with JSDoc annotations. As a user of Svelte, this won't affect your ability to use TypeScript with Svelte at all — functions exported from Svelte will still have all the same benefits of TypeScript that you're used to (typechecking, intellisense, inline documentation etc). Our commitment to TypeScript is stronger than ever
Author coming out here: Types matter, and Nue’s take is to use them where they truly shine. Adding them to naturally untyped spots like HTML or CSS? That’s just extra weight we can skip.
I prefer types over tests everywhere. If I’m passing props to a component and I get a TypeScript error, that’s a test I didn’t need to write or run. I love finding errors like this at compile time instead of at runtime. Just because HTML and CSS are untyped by default doesn’t say anything about whether types are useful for them. Does Nue have any way to protect against those kinds of errors or does some other architectural decision obviate the need for this kind of protection?
I’m not hating on Nue. At first glance, there’s a lot to like here, but I have to disagree on this point.
I guess many web developers would climb on a roof and throw stones, because then they really needed to learn HTML and using its elements semantically. And probably many of their web components would no longer type check either, forcing them to reimplement or use simpler elements.
Your views are not "naturally untyped spots like HTML or CSS". They are custom templates with custom syntax and logic. And they would definitely benefit from types.
Personally, I consider it a strike against a frontend framework if I can't type check my templates. They're entirely data-driven — exactly the kind of place where type checking is the least effort but still a a big help.
In any nontrivial project, templates become a large fraction of my LOC, and it's already challenging to confirm they work right and don't break. Type checking that I'm passing in the data they expect, and that they're reading valid properties, is a cheap way to get a big win.
Web standards are great, but I'm not sure what "heavy lifting" they do that would make me feel like type checking was unnecessary.
I agree. It's far too easy to make a change to your model that removes/renames some property, but not update one template that you forgot uses it too. Without screendiff testing, that sort of bug will easily make it into prod.
This is one of the reasons I like C#'s .cshtml (Razor) syntax. The entire file is compiled to C#, so when you do `<div>@Model.Foo</div>` the build will fail if Foo doesn't exist. String-based (rather than compiled) view templating is, IMO, a mistake.
I am not on the React bandwagon, currently using HTMX
But I would very much prefer to see TypeScript in a framework. Optional TS is ok but "untyped by design" feels like an anti-pattern, even HTMX has TS types available.
> React’s ecosystem has devs slapping TypeScript on everything—even CSS—which is overkill
"We don't use Typescript because there are people that exist who use it for CSS when using React" is one hell of an argument that makes absolutely zero sense.
>"We don't use Typescript because there are people that exist who use it for CSS when using React"
This not at all what was being conveyed, you made that up in your head. The OP didn't say they were not using Typescript because someone else used it for CSS, but that's what you seem to have written.
> React’s ecosystem has devs slapping TypeScript on everything—even CSS—which is overkill
It's actually EXACTLY what they're saying. They're using it as an example of why they don't use Typescript (ie people use React take it too far by using it for React). What does React that have anything to do with not using Typescript?
I probably have nearly the exact opposite opinion of where static typing is the most beneficial. I think it’s precisely at the UI rendering layer, because that tends to be where you’re dealing with the data types with the largest number of properties, deep nesting, etc.
I pretty much enjoy using MaterialUI with React (MUI) and have statically typed CSS: `<Stack sx={{ alignItems: "center"}}></Stack>` - I get full IntelliSense/autocompletion for the sx props (i.e. alignItems when typing 'al') and their value (i.e. 'center' when typing 'c') etc. Sx-props are composable, so you can centralize common used sx/css etc.
Any typos or invalid props/value will result in a compiler error.
I agree with most other commenters: Type safety is a great feature to have. And to intentionally dismiss it or only grant it to certain aspects of the application (where does business logic start and end anyway?) is a really bad sign for me.
how can "not typed" be "by design" and presented to us as a feature. Your project looked interesting but your presentation here makes me have big doubts
I worked with react before typescript, react with flow, angular 1 (large projects), and these days I mostly use react with typescript.
I don’t use it for css, but for the view components and code I find typescript actually makes me both faster and my code is more reliable. To me this is one of the killer features of react that other libraries are in various stages of catching up to: full static type checking end to end. (Also through the API to the backend with a little more work).
Typed JSX is one of the handful of key innovations that made React successful, IMO. I think you need to really understand what you're replacing before you can replace it.
Frankly that's a good reason to never give Nue serious consideration. It's all fine when you're building small apps one view at a time. When you have an application with hundreds of views and you need to refactor, that's when you need the types, otherwise you'll never see the tail end of oh we missed that this needed to be renamed there too.
I honestly can't see what's wrong with using TypeScript anywhere in place of JavaScript. Unless you're making a simple script or a throwaway prototype, then you're pretty much always better off with it. It's invaluable during development and it's compiled away at build time.
Nothing in your view is "web standards". And nothing in web standards can do the heavy lifting of showing things like "`nam` is not defined on object `user`"
if (!user || typeof user.nam !== 'string') {
throw new Error("Missing or invalid 'nam' on user");
}
Contemporary JavaScript has optional chaining, default values, and reflective tools like Object.hasOwn, which are all web standards. You just have to know how to use them.
Jesus, this is a regression not a feature, for christ sake.
Typed CSS via emotion/styled-components is an amazing feature to call it overkill. This alone is enough to dismiss nue.
Last time, I promise: please, PLEASE don't use ChatGPT (or others) on us. It's _extremely_ obvious, and it takes away 90% of your credibility. I'd much rather read a bit of broken English than read this kind of slop. It's a huge reason why I can't take this seriously.
ALL your docs are chatgpt. All of them. All your issues. Your comments here. Are you even real? Yes? Then TALK to us.
Please. It's me typing: Tero "tipiirai". I’m Finnish, not a bot. Documentation? Mostly me, some help from contributors. Comments here? Check my HN history. This stuff is impossible to prove.
Of course it's impossible to prove, which is why so many people are doing it, like you/your team, at least recently. At some point in the past your blog seems to have gone from "real" to "slop".
I've seen enough LLM sh*t to know.
I know you'll never admit this. I don't care about that. But please understand that your credibility goes out of the window with this; it doesn't make it look more professional, especially to developers.
If I'm extremely wrong here, I genuinely apologize, but I would be very, very surprised.
There’s a lot of negativity around this so I just thought I’d chip in and mention my appreciation for it. Projects are allowed to not be typescript, and I actively stay away from it as much as possible when working with browsers.
I don’t work in TypeScript, I don’t write in typescript, and I (along with everyone) don’t deploy typescript. I have multiple different build processes in my project to remove different types from different dependencies that are incompatible with one another just to untype them.
So personally I find standard js a huge selling point :)
Sadly not because it's been about 6 years since I looked at it! (We ended up switching to React.)
IIRC it's pretty close, but you'll still end up writing things like `{ type: String, required: false }` where in React you'd just write `string | undefined`.
I'm sure I would find many more issues if I was using it in anger, because it's building on a foundation that didn't have Typescript in mind. E.g. see this thread:
> IIRC it's pretty close, but you'll still end up writing things like `{ type: String, required: false }` where in React you'd just write `string | undefined`.
In Vue you also write `string | undefined` since Vue 3.
Also note that the thread you linked is 4 years old.
> Also note that the thread you linked is 4 years old.
So 2 years into Vue 3. Has anything changed?
I mean it's not bad enough to be a dealbreaker any more like it was with Vue 2. The real dealbreaker is still the reactivity system which leads to spaghetti very quickly.
I mean a rapidly changing front end codebase is always going to be entangled mess no matter if it’s react, plain JavaScript or even “native app code”. Front ends are where the rubber meets the road and have to deal with fuzzy weird human shit and miles of edge cases. That is just the nature of the beast.
Even if you attempt to tame it and make “the prefect codebase” it’s still gonna be a mess.
If anything React and typescript help it from being an even larger mess full of homegrown idioms that are normally baked into the framework.
There is no such thing as not using a framework. You either pick an existing one or build your own. Very often the sensible choice is to pick an existing one.
You could always massively reduce the frontend by not duplicating half the backend business logic in the browser. By not having isolated backend/frontend teams off in their own worlds and only using fancy JS where fancy JS is actually needed.
Server rendering of JS only gets you partially in a better state when the fundamental idea is based around generating a massive amount of JS for the browser.
Typescript support and usage with Vue is very large. Vue itself is written in TS and most large libs are also written in TS. According to /r/vuejs and my personal experience also most new apps.
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.
Svelte is definitely much less verbose and requires less code. Performance is also way better but it might not matter for many use cases.
The drawback is that since Svelte is really a language[1] you now need a compiler and custom dev tools to make it all work. This requires some serious effort to maintain and evolve.
I love Svelte and have been using it almost daily for years... but the team really needs more resources to accomplish their vision and maintain it for the foreseeable future. It's amazing that huge companies like Apple are adopting Svelte (eg: Apple Music) and not investing in it.
I work with react for a decade now, and with Svelte for past 3 years. Svelte is obviously a newer generation of framework, and works for me a lot better than React. But I agree there are some rough edges, mostly around the ecosystem
I learned React back in the class component days. I recently picked it back up and found functional components and hooks to be absolutely baffling. Does anyone know why they went down this route?
Trust me, the function based components are way too simpler. Just a function that returns HTML. That's it. compose your UI as those functions. These functions can take arguments to customise their output (rendered HTML) as arguments (called props) or can call special functions from React (called hooks) such as asking the React to "remember" a value for you (state) or cache something for you (useMemo) so as to not compute it every time or trigger rendering if value of certain variables change (useEffect) or at the component start (useEffect with no dependencies mentioned) and that's all the React that you need to know for I would say your 95% of the needs.
React compiler (already used for Facebook and Instragram code base) further renders the use of certain hooks unncessary thus making React a lot more simpler.
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.
The author uses something like `list.push(...objects)` in his demo code, and I believe this is the culprit. Passing many (~100,000) arguments to a method at once using the spread operator is known to cause a stack overflow, because, in JavaScript, each argument is placed on the call stack.
I see a number of issues, but don't have time to look into them.
1. Spreading when you probably don't need a copy: sortEntries. Sorting is probably where the overflow happens. Just sort in place or use Array.from or slice.
2. Excessive use of array functions. In my experience, a C style for loop performs better when you need performance. Create an empty array before, perform your business logic inside the block, and push to the array.
3. I don't know how filter is called, but it potentially loops through all of the events three times in the worst case.
4. paginate manually creates a JSON string from the returned entries. I don't know why, it seems inefficient.
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!
If you're actually doing something better and your results actually stack up under scrutiny I don't see the problem.
I think most people get uncomfortable because it's often untrue in marketing. So if it's true (to the best of your knowledge and after outside probing) then by all means.
At this point I don't even understand why everything has to be a SPA. It's complicated and inefficient and should probably be only used with highly interactive applications like some kind of Photoshop or Ableton live for the web, which means very few apps should use this paradigm. Granted, I'm not much of a frontend dev... but what I know is that if "instant search and other operations over 150,000 records" is a problem then it's probably best to re-think the paradigm.
With SPA, all your backend has to do is spit out data and sometimes validate it, leaving your front-end completely in charge of presentation and user interaction. You can even have completely separate teams working on it. It feels a lot less complicated than the alternative.
The law is based on the reasoning that in order for a product to function, the authors and designers of its component parts must communicate with each other in order to ensure compatibility between the components. Therefore, the technical structure of a system will reflect the social boundaries of the organizations that produced it, across which communication is more difficult. In colloquial terms, it means complex products end up "shaped like" the organizational structure they are designed in or designed for. The law is applied primarily in the field of software architecture, though Conway directed it more broadly and its assumptions and conclusions apply to most technical fields.
That "backend" vs. "frontend" split is entirely artificial. That code you would run server-side to convert your data into a fully-rendered page is still very much part of your "frontend" organizationally, even though it might be hosted on the server.
(Strictly speaking you can have a web service that's purely about spitting out raw data in a form that other organizations can use, but that's the kind of thing that Semantic Web and Linked Data standards are intended to address. Not something that your garden-variety website has to be concerned with.)
SPAs are great for the hordes of B2B SaaS apps out there, which for the most part are just some fancy variants of a table. They're not a Photoshop, but they're still highly interactive.
I think the exact opposite is true, B2B SaaS apps don't need to be an SPA to deal with fancy variants of a table. You can create highly interactive UI with things like Rails and Hotwire, sprinkles of JS or even HTMX. SPA's are bloat and often driven by designers who focus on flashiness rather than good UX.
If you look at the documentation at nuejs.org/docs, you'll see how Nue is really more about apps that focus on content rather than single-page apps (SPAs). However, this release is all about SPAs.
I recently thought about just using ASP.NET MVC with Razor pages for a quite simple app at work. But I'm already familiar with SPAs, so with that background I chose to "just use Vue as always (or Solid or Svelte, I like all three of them)" as SPAs have some advantages, e.g. separation of concerns, easier integration of libs like agGrid or eCharts.
Without that knowledge, I agree that good old SSR (MPA) is easier and more maintainable. And more robust.
Both way can work fine, enough great examples out there. The real problem is, imho, we shouldn't need a (graphical) UI at all. That's where all this discussion comes from. When the whole "frontend" disappears in a year or 10, it will make a lot more sense.
IMO, most SPAs are bloated. MPAs are cleaner and more forgiving.
The only reason to still stick to an SPA instead of an MPA is that the app is so bloated you want the user to only have to load it once.
And people say "lazy loading!" but by the time you've implemented lazy loading in a SPA, you could have just used an MPA to keep things modular and memory efficient.
SPAs became popular at a time when companies thought everyone was going to move to progressive web apps. Then the bloated frameworks came along, PWA interest has faded, and here we are.
The above are all my opinions, apologize in advance if they come off as speaking objectively.
This happened to a team I know. They built a flashy SPA dashboard because it was easy to copy-paste from templates. It worked great—until a real-world requirement, like a data grid, came along.
I don't think the "a button in X is 40% heavier than an SPA" is a fair comparison; including a framework will add weight, but these frameworks are not intended for single components. Compare apples to apples, then we can make a fair comparison.
That said, how does Nue compare to htmx and other frameworks leveraging the modern web standards?
There is no such things as a true apples to apples comparison for libraries such as this. They all cherry pick something and ignore a ton of things such as:
- accessibility
- amount of libraries with plug-and-play solutions to common problems
- security
- scalability
- rendering performance
- maintainability
- browser support
- browser extension interference
- hundreds of other niche edge-cases that someone will eventually run into but are non-obvious until it's widely used
React is really well-thought out and well made by hundreds of professional contributors that have worked on it for years. The premise that hobbyists can make a better overall solution in less than 8 months is strange. At best they can make a smaller solution, but it will have to sacrifice in other areas.
React and the react ecosystem fail at many of the criteria you’ve listed. You might argue “that’s not reacts fault” but when I look at a website that takes 15+ seconds to load its content on a gigabit connection , I’m never surprised when it’s react. Lots of sites have massive issues with rendering performance, scalability and maintainability even with react.
What react does do is give you a clean separation of concerns across team boundaries and allow for reusable components . But the cost you pay for that is a boat load of overhead, complexity, maintainability concerns, and react specific edge cases
A 15+ second load on a gigabit connection is impossible to have anything to do with the React library, as React is only kilobytes big and has no impact on the host.
It’s not just about the size of the payload, it’s about the stuff happening in the background and the constant diffing of the various DOMs that react has. I can tell I’m on a react site by how laggy it is. Some devs manage to do better but I can still tell.
Another wonderful feature of react is it will fully render the page on my iPad and then quickly replace it with an error message. Absolute brilliance.
You didn't ask me, but I have what seems like an esoteric use for React: I only use React for the components, because vanilla/native web components are a major pain in the ass to work with.
You don’t need to wrestle with React’s state management monster unless you’re into that sort of thing.
Depends on the project. For websites I like to use a statically generated Nextjs site served by nginx[1] and for SPAs Nginx that serves a Vite-built static bundle with a backend that’s in whatever language the backend team chose.
> You might argue “that’s not reacts fault” but when I look at a website that takes 15+ seconds to load its content on a gigabit connection , I’m never surprised when it’s react.
> A 15+ second load on a gigabit connection is impossible to have anything to do with the React library, as React is only kilobytes big and has no impact on the host.
Perfectly proving my point.
It's not react-the-framework's fault, yet those sites are always react sites.
This is the "everyone who drinks water dies, therefore drinking water is deadly" argument. I'd also guess lesser known frameworks have a higher proportion of better developers - i.e people taking the time to research and try new technologies probably are more competent. You're also forgetting about the trillions of wordpress (and similar) websites that exist.
It’s much more of a “everyone who chooses this flavor of soda dies”. Maybe it’s the soda, maybe it’s the people it attracts.
> I'd also guess lesser known frameworks have a higher proportion of better developers - i.e people taking the time to research and try new technologies probably are more competent.
And this is the “you’re holding it wrong” argument.
Facebook and Airbnb are the poster children for react (one of them wrote react). They are both perfect examples of absolutely disastrously monsters of websites plagued with issues related to all of the problems react supposedly solved.
I'm not sure if I got this correctly, but it seems like you're misunderstanding what Vite actually is or does.
For having built what is essentially a bundler, I would've guessed you were more familiar with what it does, or, perhaps even have used it to build your tool.
Vite can bundle framework-less html files. It can create an SPA without any JS faff. You just have to point it to the right direction. When you instantiate a Vite app, you have to make the conscious decision to use React under the hood.
As for Nue, I think it's a cool idea, but I don't see what it does that I couldn't do with Astro, which has way larger community support and can work with pretty much all JS frameworks OOB.
BTW, I think it's really disingenuous to compare a React SPA bundle with an SSG output. You have essentially no functionality for handling state mutations beside events. You could achieve a much better middle ground by using a compiled framework like Svelte or Solid.
I resonate with what you're saying so I'm mostly just curious how long you've been developing front end code. I think those who have had had to run the gauntlet of naked JS in the 90s developed the discipline to intuitively code untyped.
I've been enjoying JS since it was first added to Netscape and I also loathe the creeping bloat that is endemic to web development these days.
In the event that I want an "intellisense" dropdown capability in a project, I'm a big fan of JSDoc. I think the bootcamp kiddies these days just don't have enough experience to get by without the intellisense crutch.
What do you mean by "lighter than a React button"? Do you mean lighter than the entire React runtime, plus a React button?
If so, that's somewhat disingenuous because even though a page with a single button would require the entire runtime, a second React button would be significantly cheaper than that.
As the previous commenter said - you don't need a new runtime instance per button, so the comparison doesn't really work (for the smallest binary size, you could provide a native application doing the bare minimum to display the UI too, if the platform has an OS-provided UI framework).
It's still a neat toolkit, since not every website needs a big framework - but comparing runtime sizes is like choosing C over C++ because a `int main() { printf("Hello World\n"); }` binary is smaller.
I think it's relevant in the sense that it shows if you're building a simple app, there's a lot of overhead.
It doesn't claim that you're going to get that overhead for every time you instance a button. I don't see how anyone would think that.
I think the comparison works fairly well. It should be clear to everyone that it compares apples and oranges, since it's two different kind of apps it's comparing. So it makes you think. If they just compared the size of the framework itself, or a single button vs a single button, you may think "oh but as soon as you add any kind of complicated code, there will probably be so much boilerplate with Nue that it'll end up being bigger"..
This comparison is disingenuous and off-putting. When I read "a React button" I assume you are talking about `<button>` and the React runtime, not some third party libraries.
flawed example for a framework. Tell me...are 2 buttons going to be 80% heavier? why use react if all you build is a button? you need a tractor to pick your groceries from store?
So, nothing is worthy of discussion or can claim any benefits over the incumbents until it has become an incumbent itself? How is it supposed to attract the necessary users to get bloated if they can’t talk about it in relation to the established players?
JS frameworks have often valued DX first over what it outputs. Frontend devs also frequently care more about a) their own tooling and b) how it looks, to a much higher priority than the performance and stability of their output. At least from my own experience in the community :)
Oh my god, yes this is hitting the nail on the head in a way I hadn't thought before. The bloat comes from the discipline (or lack of) more than the framework.
IMO, those who have only worked in React tend to be unfamiliar with the layers of native capability that React is built upon, and so they are stuck in the React bubble unless they want to learn a ton of (admittedly crufty, but useful) web fundamentals.
Solid.js is doing amazing w/re to its bundle size. Its been in development for something between 6-9 years depending on how you count and it is still very very slim.
- 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
> 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
Weren't the main points on the main page that it was small ("lighter than a React button"), and could handle large amounts of records ("far past where JavaScript (and React) would crash with a stack overflow error")?
Those points are only true if you're comparing to a React app that uses bloated frameworks and inefficient list manipulation (as other commenters pointed out, `list.push(...items)` causes problems)
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’m the author. To clarify: a button installed via ShadCN/Vite’s official docs (https://ui.shadcn.com/docs/installation/vite) ends up way heavier than a full Nue SPA. It’s not a jab at React devs—just showing how web standards can flip the script on bloat. Any thoughts on framing this comparison better?
Can you give some examples of some of these standards that make Nue stand out and other frameworks don't use? It seems that if other frameworks make use of these standards we would get a similar performance boost across the ecosystem.
Seems like it should be Meta with billon dollars that should be doing that. The whole point is framework like React are made for DX and dev flow at company of that size.
Mention that you know you are missing dozens of features instead of blaming it on “web standards” would definitely help frame it better. Do you think Vite doesn’t know about web standards? It reads pretty naively.
Also I recommend just not making a web framework. There are many of them, some very similar to Nue. Your effort could be placed on improving what is out there. I suspect that is a lot harder and less fun than just making something new. But if you manage to contribute then you’ll be helping an entire community of people whereas a new web framework will likely see almost no adoption before it is abandoned.
It's like someone making a hello world in C using the std, then one hand crafting the console print but losing literally everything else. Of course, if my goal was to just write hello world then it would make sense but 99.9% of people in the world will use something else, invalidating the point.
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…
The author is using a trick they've used in almost every past submission: They implement much less than the component they compare themselves to, and then show how much smaller their own solution is.
> Built with Vite, TypeScript, Tailwind, and Shadcn/UI, following the official ShadCN/Vite documentation exactly — no additions or removals.
Would be interesting to run Webpack Bundle Analyser [1] (or similar for vite bundler) to see if the proposed stack in the doc is bloated by some major dependencies.
Edit : seems the question I was responding for was a rhetoric question posted by the author. I guess the « smaller that a button » is a smart catchphrase but I wouldn’t use it for too long as soon a Nue becomes popular. Great work, I wish you much success and hope to use it in day to day work some time soon !
Does your button component implement all the functionality included in the Vite/shadcn bundle? E.g. the different variants, states, loading etc.?
I'm sorry if it does, then I'll take my accusation back, but I've seen this happen in almost all of your Nue submissions. People keep bringing up this criticism, and you never retract your misleading comparisons.
The Nue button demo isn’t claiming to replicate every feature of the Vite/ShadCN bundle—no variants, states, or loading spinners here, just a lean example to show size and simplicity. The point’s not to ‘beat’ ShadCN at its own game but to highlight how web standards can cut bloat dramatically, like a button smaller than a full SPA. I get the criticism—comparisons can feel loaded—but it’s less about misleading and more about spotlighting a different approach. Happy to tweak the framing if it’s coming off wrong.
> The point’s not to ‘beat’ ShadCN at its own game but to highlight how web standards can cut bloat dramatically, like a button smaller than a full SPA.
Then why isn't there any disclaimer or explanation that your Nue button has fewer features than the one you compare it to? You clearly intend for the reader to make this comparison, but you deceive them by not mentioning that your solution isn't equivalent.
> Happy to tweak the framing if it’s coming off wrong.
It would be great if you could do that! Though I'm not holding my breath - you've done this many times before, people have complained many times before, and you keep doing it.
I know I'm just one voice, but your marketing strategy is so deliberately deceitful that I'll honestly never consider Nue as a serious contender for any project, nor other software you write, until you stop doing this.
- `nue create simple-blog`
This highlights content-driven websites.
- `nue create simple-mpa`
This is today’s SPA demo, where 'MPA' stands for multi-page applications. It shows how client-side routing and view transitions can seamlessly connect content-heavy pages with app-like views.
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.
And importantly, does the app have clear loading states when it has to block on something? Making sure something happens immediately can make things feel fast even if you're waiting on the network.
> Does the app avoid unnecessary roundtrips to the server?
Guess what, using server-rendered pages avoids all unnecessary roundtrips by definition, because the entire page is loaded in one go. You can augment a server-rendered site with client-side SPA features for seamless interaction within the page, but that's not a key requirement either.
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.
Weird that the current state of things for a simple, noninteractive site is some kind of framework and not just “write the HTML with a little JS where needed,” which works perfectly well and requires no additional baggage.
> 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.
Author here. No need to update the resume yet—titles do keep shifting! React’s monolithic style has muddied the waters, making it tough to build clean business logic, prioritize performance, craft CSS design systems, or just focus on user experience. Nue’s here to unblock that—giving each role room to shine with leaner tools, not cramming everyone into the same heavy stack.
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.
Author here. You’re spot on. I took away the React association and added a direct link to the JS code [1] that hit the ‘Maximum call stack size exceeded’ wall. TypedArrays can do wild stuff, no doubt, but yeah, it’s not exactly vanilla JS—and still lags a tight WASM setup. Appreciating the nuance here!
The new wording is much more nuanced, appreciated! Also the fact that you link to the actual code that broke down, making it possible to verify the claim. Less ammunition for the people who actually are skeptical of the project instead of just nitpicky like me ;)
Speaking of the code in question, it looks pretty sensible - there's a bit of low-hanging fruit where one could avoid creating redundant arrays by turning chained calls to map and filter into one for-loop and such, but that's about it.
What confuses me is that there's no point in the code where I see any recursion, here or in the other JS files that seem relevant, so how does one end up with a call stack overflow?
(not questioning that it crashed for you, it's just that I don't see any obvious flaws in the implementation, so I'm curious to lean what the "gotcha" is in case I ever bump into something like it myself)
The stack overflow is caused by an `arr=[...]; events.push(...arr)` in `add_events`. Replacing that with `for(const x of [...]) events.push(x)` gets rid of that issue, and the JS-backed build is then snappier to search & filter than the WASM/Rust version.
Oh duh, yeah using spread syntax for function calls is definitely limited to fewer than 150,000 arguments in any browser that I know of. Don't expect everyone to know that, but I sure did, stupid that I didn't spot that. Thanks for pointing it out!
(funny enough I tend to use for(let i = 0; i < arr.length; i++) loops most of the time anyway because the iterator protocol adds too much overhead for my tastes, so I wasn't likely to ever bump into this in the first place)
I would imagine browsers optimize the iterator protocol away for arrays. At least on https://jsben.ch/iJFZ4 for..of is a smidge faster than an old-school loop.
You accidentally included the array initialization in the benchmarked code ("setup block" vs "boilerplate block"), dwarfing everything else. If we're talking about an already allocated array the difference is pretty big:
… but in a way you're correct that this is rarely the actual bottleneck in the surrounding code. Still, "death by a thousand papercuts" and all that. Plus having old-school for-loops as a habit makes it easier to spot the true botllenecks.
In your defense, the "use it for data initializing" suggestion isn't exactly helpful text either.
Also, for the record: I presume you tested on Chrome, but on Firefox the difference between the two loop styles is quite a bit larger (and generally slower than Chrome, so perhaps also a consideration when optimizing for "slowest browser" as the bottleneck).
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.
Most IRL software failures like poor performance, lack of stability, unmanageable technical debt, etc are going to be systems and human failures 90%+ of the time, not the individual tool or framework choices.
It’s human failure 100%. Big frameworks just lower the baseline such that this failure becomes more acceptable, less immediately aware, and masks candidate selection.
If you want to achieve something smaller or faster you have to measure for it. Odds are if you cannot execute without a big framework telling you how to proceed you will not be able to measure it either way.
Fair point—new tools pop up constantly, often just piling more layers on React’s bloated stack. Nue’s not that. It’s a fresh start, built on web standards and closer to the metal, not another abstraction treadmill. That’s why a button can be lighter than a whole app—less cruft, not more boilerplate. Tomorrow’s Olde might still fight yesterday’s bloat; Nue’s dodging that trap from day one
Yes. On that version, Chrome 134.0.6998.89's devtools on my Macbook (M2 Max) are indicating 100 to 250 millisecond interaction times and a 160 ms frame when entering text into the search field.
I get the same numbers. Interestingly, JavaScript performs faster below 100,000 entries due to the lack of a JS-to-WASM bridge, but it eventually crashes when the records keep increasing
Loading the page on Fast 4G connection takes 9,61 seconds before I see _any_ content on the screen. This is loading the "all contacts" page that shows 12 items with a title, excerpt, time stamp and user name. Is this expected performance? Network shows the app downloading huge 4/1 megabyte chunks.
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.
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.
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?
Absolutely brilliant I've been following Nue for a while and every release gets more and more impressive.
Thank you so much for putting in the hard work by making it and I hope others can understand why this is important and use it instead of cargo culting React and making the web worse every single year.
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.
"mostly" for sure; it's a good mental model and allows me to build modular applications etc, but I hate that a nontrivial amount of code and headspace is spent on things like re-renders, memoization, useCallback, dependency arrays, etc. I hope the React compiler will finally solve this, because the competition (apparently?) has (I haven't had the time to look into e.g. vue yet).
Absolutely, it would be nice if we found the right abstraction to get rid of that part as well. Basically every non-React framework's answer to that is Signals (aka change tracking), where React is doubling down on unidirectional data flow and thus dependency arrays. React Compiler indeed solves the 99% of performance related memo-s.
For effects you still will have to understand the mental model (which I'd argue is inherent in the domain and not incidental to the tech).
From reading Nue's docs on Interactivity, it seems to opt-out of the discussion by going back to good old manual UI refreshs. I personally would not choose that, too many pre-React debugging nights spent on chasing state<->UI desynchronization bugs.
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.
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.
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.
1. It's an SSG and competes with projects like Astro or Solid or Next. Comparing to React is apples to oranges.
2. Benchmarks are just numbers without details. React+ReacDOM gzipped/minified is 40 kb in 2025. I doubt a button adds 30 kb. But if you really want to make small SPAs, Preact is just 4 kb and it doesn't require to learn a new bespoke templating DHTML-style thing.
3. From FAQ
> The WebAssembly example in our demo isn't about raw performance — it demonstrates something far more important: what becomes possible when your business logic is properly separated from presentation.
> But when your business logic lives in its own pure layer, entirely new possibilities emerge. Rust is just one example — you could model complex financial calculations, build sophisticated data visualization engines, or create real-time collaboration systems. Your logic can evolve independently of the interface, enabling the kind of architectural advances that the React monolith prevents.
The writer was high or delusional or bad at explaining the point. Nothing prevents you from putting logic into "its own pure layer" in any language. You can make it messy and impure with Rust/WASM/... just as you can keep it pure with pure JS. And it's not "entirely new" because people separated business logic for literally decades (and believe it or not many of them even did it while using React at the same time)
And meanwhile the Rust version is slower and bigger. "What becomes possible" is a mystery.
"React monolith" just takes the cake. React literally doesn't care how you separate your business logic, it's just a rendering layer. This ironically is a monolith SSG that does routing, YAML frontmatter, Markdown extensions, syntax highlighting and what not. Again, you are thinking about something like MarkoJS or QwikJS. Before you are trying to take something down you should probably understand the basics.
Don't get me wrong, it's a cool project. But it could be more humble because authors don't seem to fully understand themselves what exactly they are proposing.
The videos. The very first video. Animations like this are done to hide the fact it’s slow by hiding it behind a fancy animation. Used to do this when we were stuck on 3g connections…
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
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.
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 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.
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."
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.
Google decides what goes in a browser these days. Since React came out of Facebook there is approximately (checks notes) -ZERO chance in hell- of that happening
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.
Regarding Rust, are we talking about a Rust backend with RPC/REST or is it simply WebAssembly compiled from Rust? If the latter, how is the data synced for CRUD?
Congrats, Nue seems to be an impressive and well-thought-out design system & framework. It feels like a strong candidate to become the "Web Standards Stack" —finally freeing developers from the complexity and bloat of modern frontend tooling.
I've been following Nue for a while now, and I'm eager to use it for real world apps. Any updates on when the design system will be released? I know you're ambitious, but I'd suggest launching a single design system first to test the waters, gather feedback, and gain traction — rather than waiting to release everything at once (but losing out to the ecosystem).
I'm eager to dive into the design systems, definitely coming. But first, I wanted this release to prove Nue isn’t just for ‘hobby projects,’ a label plain website generators often get stuck with. This SPA demo was key—showing how working closer to web standards really shines for complex apps, not just simple sites.
this is why inertia.js is a positive path forward.
it relegates React, Vue etc to be view layers - purely view layers. all models / state etc handled by your monolith Rails, Laravel server. this simplifies a lot of things.
frameworks like Vue & Svelte have scoped styles which preserve knowledge of CSS. While Tailwind is convenient - a lot of people won't know the capability of CSS
and why it was named cascading & the customability of CSS for the user.
But what if it is not the frameworks that are bloated but the application developers that make bloated applications? Then how would this fix anything ...
Here's the react-table example app with 112,500 records, just like your example. I am not really seeing much of a performance difference (and this is in dev mode - it would be faster if built for production):
The main benefit React is giving my app is just the ability to update the DOM automatically and efficiently, without me worrying about doing anything but updating the state variables. I have a feeling some very well crafted prompt to the best AI in the world could just about generate something that can also do this in like 500 lines of JS, in a single file. Once we have that, we can get rid of React maybe?
I also hate JSX, and have my app setup so I create GUI elements programatically like "button = new Button("Save", db.save)". Templating has so many friction points I find it to not even be worth the complexity, expecially once you have templates containing other templates with looping and conditionals, etc, and you end up with just an extra layer of cognitive load. No thanks. We can do better. With the capabilities of modern JS (classes, imports, etc) we can phase out React and Vue.
> 150,000 records — far past where JavaScript (and React) would crash with a stack overflow error
I think react-virtualized and stack tables can easily handle 1 million rows client-side without a problem (I saw the demo somewhere).
Web development is about convenience, and the speed of development is far more important than ultra optimizations. People simply don't care about super optimizations because servers are so fast these days, and bandwidth is cheap, almost free.
> People simply don't care about super optimizations
Could be, but some optimizations in Nue really stand out. Check out bundle size, HMR speed, build speed, and especially repository size. An empty Next.js project weighs over 300MB, a Vite button is around 150MB, while a Nue SPA clocks in at just 2MB.
I would love to check out the bundle size! Will you ever create a fair comparison, where your Nue implementation has all the same features as the versions you compare it to? All the comparisons I've seen so far are deceitful since they implement much less. If Nue actually produces smaller bundles, why not create an actually fair comparison?
A Vite button? You mean Vue? Vite is just a bundler lol.
Also, would like to see some comparisons to Preact, as that's an (almost) drop-in replacement for React with SUPER small bundles. I'd be impressed if you manage to beat that.
Make a demo with react-virtualized[0] and see if it crashes. Hint: It will not[1]. React can easily render 1 million rows with high performance without relying on WASM [2]
Here is the demo of react-virtualized[3], in which I entered 10m as the row count and scrolled to the bottom without crashing.
Because he constructs a giant JSON by joining individual entries. Rendering that directly on the DOM will always cause the performance issues (even at the 10k entries). That's why you need to use virtualized list, it can be done in plain JS or using libraries like react-virtualized.
`events.push(...arr)` puts all arguments on the call stack before calling the method, which causes the error. Don't push tens of thousands of items at once.
It has nothing to do with architecture, but rather understanding how the DOM works. The DOM is notoriously slow, so you should never render a huge number of rows at once. You can render millions of rows in plain JavaScript without impacting performance.
Here, I have recreated your JS example with searching and filtering and it does not crash. It's trivial to reuse a similar approach with the real backend and real events from the event source.
The point should not be using the spread operator at all costs. There are other ways in javascript to push multiple elements in an array that are more efficient than the spread operator.
The fact you didn't even stop to wonder why the error was a stack overflow when you weren't using recursive functions is also telling.
You're solving a problem nobody has. If you encounter this problem, you shouldn't think "ah, let's yeet the JS engine because it clearly isn't good enough for my awesome SPA", you should think "hm, maybe I shouldn't render 10000000000 records in the DOM".
What's next? "Oh I have a memory leak, let's get a subscription on RAM modules and just keep adding them!"
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.
The bloat isn't coming from "huge frameworks" like React.
To give some concrete numbers: a barebones react project created with `pnpm create vite -t react-ts` clocks in at ~60KB compressed:
A vue project (`pnpm create vite -t vue-ts`) is even smaller at ~25KB: I've created plenty of medium-sized projects with React/Vue clocking in at 200-300KB compressed (excluding image assets). You can still realistically use those on 2G — yes I've tried, not just in dev tools, but when I was actually rate limited to 2G.> 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.
You can create that kind of garbage with any framework, or without framework. You can actually do worse with the traditional way of using third party dependencies wholesale (the jQuery way), you can be downloading 200KB for 1KB of actually used code.
Edit: Also, the comparison in the article is pretty stupid. A full view in React is not much larger than "a React button", it's upfront cost + marginal cost.
Author here: Fair point—React’s baseline isn’t a monster. ~60KB compressed for a barebones Vite/React setup, or even ~25KB with Vue. Medium projects at 200-300KB are definitely workable.
But here’s the point: a single React/ShadCN button, straight from their official docs, still outweighs Nue’s entire SPA demo. Add more widgets—tabs, modals, whatever—and that gap only widens. Nue is flipping the script. Web standards let us start lean and stay lean—smaller codebases, faster HMR, quicker builds. That’s the win: efficiency that scales without piling complexity.
> a single React/ShadCN button
So don't use ShadCN? It's so weird to put up this strawman app and then be like "see what's wrong with React"? Like showing two boards nailed together and being like "can you believe I needed all those power tools just to do this?"
> Add more widgets—tabs, modals, whatever—and that gap only widens
This is the benchmark I want to see. Two full-featured apps built with minimal prod dependencies. There's a pretty good chance that the various ShadCN modules share many of their dependencies so that importing more doesn't necessarily mean a linear increase in bundle size. It could be that once you build something full-featured, React projects come in smaller, or at least not big enough to invalidate the other upsides of choosing it.
But the OP did implement a fully featured app as the Nue comparison half of the benchmark. I have never used Nue and don't know if I ever would. I just think to be fair to the OP, even if incremental cost declines as you keep adding stuff in React, there's no way it is negative, which means the benchmark you asked for logically must have a similar result?
> Two full-featured apps built with minimal prod dependencies.
This isn't what you see in the real world. I'd rather see comparisons to real life (where 99.9% of web apps are bloated garbage) than nonsense synthetic benchmarks like that.
Does an ecosystem like that exist for Nue? If not, it’s the only fair comparison. The ShadCN button comes with styles and behavior that wasn’t implemented in the Nue demo.
The problem is you could also just do that to Nue, there’s nothing really preventing that.
If your team or company has bad dependency hygiene, changing a single framework is not going to help you.
An extra 100-200KB compressed is a ~100ms one time cost once in a while for the majority of my users, and ~1s for 95%+ of users. At that point I'm going to optimize for developer productivity (which includes breadth of ecosystem). I can be both productive and respectful to my users with these common frameworks.
Note that I'm very mindful of web performance, and I've been quite vocal on this site about some alarming trends like calling for the end of bundling (native esm) and roundtrips for everything (liveview and co., or at least the abuse of them). In my experience waterfalls and roundtrips are the number one thing hated by people on slow and/or unreliable networks; 100KB added to a flat bundle at load is almost nothing.
> An extra 100-200KB compressed is a ~100ms one time cost once in a while for the majority of my users, and ~1s for 95%+ of users. At that point I'm going to optimize for developer productivity
Is that 100ms on fiber? Cable? 5G? 4G?
Is that for the first button? Or each button? And what happens when you next need to manage dates as objects? Do you pull down dayjs or do you wrangle it yourself? What other libraries do you need to add? How's build speed? How much time to the linters take as they cascade through all that code? How are your Next.js (a pretty standard companion to react) version updates going? Keeping up with security alerts?
I'm biased against React because I manage a team trained in classic web design who now have to manage a giant React codebase and learn its special way of doing things, and it's a slog.
Agencies are going to keep building with React because they can get 90% of a project done in no time flat, and they don't have to deal with the infra challenges after they get their check. Small clients like us will continue to fall for it and slowly grind to a halt as the infrastructure pulls the team to a standstill.
No, adding another button does not duplicate the entire underlying libraries used to display said button.
Yeah, I don’t even know why people who are that clueless about frameworks are commenting; it takes less than an hour of learning of modern web development, from scratch, to shut down that notion. And other libraries to manage dates and stuff? Excuse me? How does that have anything to do with the rendering framework? Completely orthogonal choices.
And asking about basic math on download speed is golden. No idea how someone can “manage a team trained in classic web design” without that knowledge and then pretend to care about performance.
Eh, I'm clueless about this aspect of the framework (if you can call such a steaming pile of resume-driven-development such), and honestly I'm thankful for it.
Libraries like dayjs add complexity to the overall codebase and it's another piece of code you need to keep track of, update, and repair when its makers decide to go a different direction with it or some script kiddie decides to introduce a backdoor into it.
I think your larger concern shouldn't be about the "clueless people" who are commenting on this thread and rather the number of upvotes my comment got (especially compared to your rant). Clearly it struck a chord.
People are commenting and upvoting because the choices that went into building React leaves a lot of room for frameworks like Nue, Vue, hell even HTMX. Just because (it sounds like) you've staked your career on thinking React, the McDonalds of frameworks, is awesome doesn't change that.
No I’ve not staked my career on React, I’m not even primarily a front end guy and React is my least favorite framework among popular ones, but thank you for your concern. I was debunking one ridiculously wrong comment criticizing my least favorite framework with solid, reproducible statistics, but that’s apparently a rant compared to your very insightful questions like “100ms to download 100KB, is that fiber? Cable? 5G? 4G?”, then okay. You clearly struck a chord with a large number of people so out of touch that they believe a copy of React is required for each button, and pride themselves on such ignorance because it’s “resume-driven-development”, so congratulations.
(Another tip: Don’t bring votes into discussions, it’s both against site guidelines and laughable.)
> I'm biased against React because I manage a team trained in classic web design who now have to manage a giant React codebase and learn its special way of doing things, and it's a slog.
What special way is that? One of the big draws of React is its minimal api surface, and the ability to write standard JS alongside of your presentational HTML.
I am also curious what "classic web design" actually means, I have a theory, but I am curious all the same
I was speaking directly to the reactive framework itself (which is a smart way to get around some limitations), the div salad it pushes developers to sustain, and the fact that they felt they had to rewrite HTML such that instead of typing <h2> devs have to type something like <Heading.
HTML is a pretty simple markup language and abstracting from it doesn't seem to make any sense.
And I think your theory about what I mean by "classic web design" is probably right; keeping the JS separate from mark-up is one example of how I wish I could go back in time.
But I can't. So it's time to learn to manage people who want to go this direction.
Meta wrote React for Facebook mainly, and most other projects won't touch that scale. In my organization's case it's like we're water-skiing behind an aircraft carrier. It's the wrong tool for the job, and having three people manage 37k lines of code (excluding libraries) is tough.
> HTML such that instead of typing <h2> devs have to type something like <Heading.
...but they don't? Just use <h2> haha
Although payload can be indicative of page load speed, there are many good reasons Lighthouse scores are more complex than that. Specifically, at the start of this thread the criticism was that the js work in modern web apps is slow. I have thus far managed to avoid using react so I don't know the actual numbers, but I don't think the conversation should be reduced to payload size, even if it is obviously important. When I profile problematic pages, other than sites that don't properly scale their images, it is not usually network that bogs them down, it is the rendering.
Even focusing on Lighthouse score or similar for a basic app is totally missing the point of Nue as presented on the linked page. It about a framework designed for speed that can handle data at scale, that is easier to control and personalize, and easier to model and thus architect. And yes, of course, most any framework can be used for good work, but the relevant question here is which one promotes it the most from start to finish, and makes it the easiest to implement. Speaking only for myself, this focus is great to see.
How much is it React/Nue and how much is everything else?
HTML has evolved in the last 15 years to be a platform for applications. The early Bootstrap was a terrible Rube Goldberg machine because CSS didn't have civilized layout mechanisms such as grid and flexbox. Newer frameworks like Tailwind are more sensible, but still add 50k to your bundle, and if your app is complex and developed under deadlines you probably have components that use Tailwind and Bootstrap and emotion and styled-components and raw CSS and you still have to write some SCSS to get the styles just right in the end.
I've been investigating the accessibility of various <Modal> components and found that they all suck because they do complicated things with <Portal>(s) and various-aria-attributes. HTML has had a <dialog> component that properly hides the rest of the page since 2022 but barely anyone was using it.
If you stuck to using Tailwind or Bootstrap or raw CSS and used a minimal widget set you can make small applications with any framework. If you wrote raw CSS and made the most of the widgets that come in HTML5 (like the new stylable <select>) you can make tiny applications.
Tailwind, at least for the last couple major versions, only adds the classes you actually use (plus the resets). Baseline size of the resets is far below 50k.
Great point about the dialog element. I used it in a project recently for the first time... It was very nice to not involve a framework-heavy "portal" scheme, etc.
You’ll add at least 100kb of text for class names styling each HTML element using tailwind.
Since those class names are repeated, they will be gzipped to a very small size. And on top of that browsers/devices are much happier about HTML sizes than about JS sizes. See Performance Inequality Gap: https://infrequently.org/2024/01/performance-inequality-gap-...
I think Nue just puts you in the mindset of trying to keep the codebase as small and lightweight as possible. I wanted to rebuild my website with Nue and there was something telling me to avoid Motion, Tailwind CSS, etc. This philosophy can actually prove very helpful in the long term, however I feel that by using Nue you're really compromising on DX (development is much slower), although that might be because I'm not so familiar with creating websites without a framework. In any case, it's definitely worth a try.
> React’s baseline isn’t a monster.
Yes it is. It’s not size, it’s logic: Every time the component rerenders, the root loop is executed. Why? The root loop reassigns every useEffect, reruns every useState, every other hook (and useSearchParams is executed n times for n components that need it in the hierarchy) when only the HTML needs rerender.
(Yes the programmer can optimize/memoize, and yes “a hook’s execution time is very short” (but multiplied by every cell in the table, when needed)). Must be the fault of the programmer if the framework has a super-intensive concept at the root.)
I'm old enough to remember when this simplified model was why people thought React was better than alternatives.
I know, right? And where is Preact, Inferno and others sped-up React-like now?
What do you mean where are they? They are still around. Preact especially is doing really cool work adding signals on top of a similar to react model.
> It’s not size
That's what TFA is complaining about: size. But nice pivot, hope your head isn't spinning too much.
Yeah, react developers don’t even realize that there is execution time as well as download time for an app.
this means the example wasn't made to be lightweight. You'll need an apples to apples example to convince any detractor. Implement the same app using two different toolsets, document the process with each and then benchmark it
To be honest, I am very confused with this benchmark. It is misleading.
What is the actually size of the production build portion only for that button part? Because I think that the ShadCN button source code is not equal in size for the button that client downloads in production environment. Especially if you have SSR.
If you look at the demo, all of the payload comes from react and the tailwindcss classes that the shadcn button refers to.
It's dishonest to call this the payload of "one shadcn button" since it's basically all react/tailwindcss fixed cost and not literally a shadcn button.
But still, that's a decently broad demo to fit in a small payload, so the exaggeration kinda takes away from that.
The main thing I care about in client development is the state management solution since that's where most of the complexity comes from, and it's what makes or breaks an approach. In React, I use MobX which I see as the holy grail.
Whether Nue is nice to use or not for me is gonna come down to how nice this is to work with: https://nuejs.org/docs/interactivity.html
> It's dishonest to call this the payload of "one shadcn button" since it's basically all react/tailwindcss fixed cost and not literally a shadcn button.
Does the ShadCN button work without paying that cost?
Sure. If you just want the shadcn button by itself, it will generate this html: <button class="{tailwindcss classes}" />.
And it has a dependency on some common tailwindcss classes that will get injected into your bundle.
Most shadcn components depend on tailwindcss classes, and how the whole shtick works is that tailwindcss only includes in your bundle the classes that your components use across your app. Which is kind of a clever integration for a ui component 'package manager' for reducing bundle size.
But most importantly, consider that OP's demo has very minimal CSS because they aren't using a CSS framework, and that has nothing to do with their Nue framework. It's not like their Nue framework comes with an optimized answer to tailwindcss/shadcn; you have to bring your own solution.
So if you use tailwindcss/shadcn with React, you'd certainly use it with Nue.
What Nue should do instead is add libraries to either side necessary to reach parity with the other side. Nue has built-in routing, so it would be fair to add react-router-dom to the React side. And they wouldn't have 100 people calling them out for the dumb benchmark.
Are you really going to build a site which just consists of a button?
If I'm working with a payload budget and I'm using React I guess so?
Stop. You really do not need to be acting like this.
Your question is, incredibly, more dishonest than the original claim. Truly impressive.
What's dishonest about my question? Please keep your personal attacks to yourself.
Seems like you should be correct. A shadcn button is just react, tailwind, and @radix/react-slot. But if you simply create a new shadcn Next.js template (i.e. pnpm dlx shadcn@latest init) and add a button, the "First Load JS" is ~100kB. Maybe you could blame that on Next.js bloat and we should also compare it to a Vite setup, but it's still surprising.
Yeah, but my point is that you download the runtime and core of React/Tailwind just once for the whole web page and those should be removed from the test, or at least there should be comparison which includes the both cases.
You only need couple images on your webpage and that runtime size becomes soon irrelevant.
So the question is, that how much overhead are React/Tailwind CSS adding beyond that initial runtime size? If I have 100 different buttons, is it suddenly 10 000 kilobytes? I think it is not. This is the most fundamental issue on all the modern web benchmarking results. They benchmark sites that are no reflecting reality in any sense.
These frameworks are designed for content-heavy websites and the performance means completely different thing. If every button adds so much overhead, of course that would be a big deal. But I think they are not adding that much overhead.
> Yeah, but my point is that you download the runtime and core of React/Tailwind just once for the whole web page and those should be removed from the test, or at least there should be comparison which includes the both cases.
You think a test that is comparing the size of apps that use various frameworks should exclude the frameworks from the test? Then what is even being tested?
Actual overhead when the site is used in reality? How much ovearhead are those 100 different buttons creating? What is the performance of state managing? What is the rendering performance in complex sites? How much size overhead are modular files adding? Is .jsx contributing more than raw HTML for page size? The library runtime bundle size is mostly meaningless, unless you want to provide static website with just text. And then you should not use any of these frameworks.
This sounds like ChatGPT’s voice :)
It really doesn't sound like ChatGPT’s default voice, though it is pretty good at taking on different voices so in a sense you could say that about almost anything. It does use em-dashes, which people have recently started way over-indexing on as a ChatGPT tell, but lots of posters on HN have been using em-dashes for longer than ChatGPT has existed.
It does read like marketing material, though.
It's not just the em-dashes for me. It's actually more these parts:
But here’s the point:
That’s the win:
Those sound exactly like ChatGPT when I tell it to write in a more direct, opinionated style.
It reads like pretty much every piece of tech marketing/evangelism in the last several decades. Which, sure, ChatGPT nails pretty well if you tell it to do that, but... I don't think that has high specificity as a ChatGPT tell.
Generic marketing speak is generic.
I agree with everybody else: it smells like ChatGPT. And I thought this before reading this chain.
Actually, going through their entire profile, it makes it even more obvious:
> Author here. No need to update the resume yet—titles do keep shifting! React’s monolithic style has muddied the waters, making it tough to build clean business logic, prioritize performance, craft CSS design systems, or just focus on user experience. Nue’s here to unblock that—giving each role room to shine with leaner tools, not cramming everyone into the same heavy stack.
> Author here. React’s absolutely mature—no question there, with a skilled team behind it. But the button example highlights something off: a single component outweighing an entire app feels fundamentally broken. There’s clear room for fresh alternatives, especially now. You can see it here on HN—seasoned devs wrestling with React’s wild complexity. Nue’s a stab at fixing that.
Looks like they switch to ChatGPT-mode for most of their Nue replies.
I agree with you this is absolutely ChatGPT output. This should result in instant bans from HN in my opinion. I only come here to hear from human beings.
It does, and it muddies the waters a lot. Why does it read like a sales pitch?
ChatGPT learned that voice from actual people, you know.
And yet, over the last year or two, people using ChatGPT to write their comments stand out like a sore thumb. The overall structure, the specific style of using em-dashes, semicolons, and colons...it's blindingly obvious.
If you just go back a couple months and read OP's comments, they sound very different from everything they've posted today: https://news.ycombinator.com/item?id=42734300
To be clear, I don't really care, I use ChatGPT all day every day, but just letting OP know it's often pretty obvious when you have it write for you.
Yep, I read through some of their comments -- it is strange. I would certainly like to see people improve their grammar, punctuation, and general consistency; but, let's face it, people rarely care to.
Call me paranoid (because, let's admit it, I am) but... after all, it's the Internet, and it's 2025! There's been enough controversy about the political power of speech over the past decade alone, that I can see people running their stuff through ChatGPT just to stay on the safe side and make things sound blandly "professional": just so they can avoid being taken the wrong way by a random reader who happens to strongly object to some particular aspect of their communication style.
(Goodness knows I've found myself on either side of all that at different times -- personally, I find it highly inauthentic to make noncommittal "positive" statements in lieu of plain observations. It's absolutely grating; while some other people seem to require it, and can be indeed quite self-contradictorily harsh about it.)
I can definitely see a major use case for LLMs there -- though I do find the implications quite terrifying. Call it political correctness, call it jamming stylometry, call it a day. Either way there's definitely some sort of power differential here that needs to be examined and I think the world is less prepared than ever to confront whatever its meaning turns out to be.
Which brings me to my other point:
>To be clear, I don't really care, I use ChatGPT all day every day, but just letting OP know it's often pretty obvious when you have it write for you.
Now this I don't quite understand. Pointing something out ("letting someone know") generally implies you want someone else to care about that something, even if you honestly don't. So, since you don't care -- why is it that you want others to? Honest question.
Would love to get some help on documenting Nue! Crazy amount of work for a non-native English speaker doing both coding and docs.
Yeah, that was ambiguous. I don’t care if people use ChatGPT to write for them, but don’t be so lazy with it that it’s so obvious and bland.
Isn’t using compressed numbers pretending that network bandwidth is the only cost of bloat?
All that JS, once decompressed, needs to be parsed and actually evaluated. That is where it hurts even people on gigabit connections.
I think frontend bloat has arrived at such an absurd level that it kind of makes me wish broadband and mobile speeds, and JS engine speeds, had paused their advancement for 15 years so that FE developers would have had to learn to write good code. Presently there is a whole generation of developers who built their whole careers in this era where you can get acceptably mediocre performance even with wildly inefficient code and an absurd amount of dependencies, most of them barely used on a given page. They’ve never been challenged to do any better, so i don’t really blame them.
> The bloat isn't coming from "huge frameworks" like React.
I agree. This is such a familiar cycle. People still blame Java for things that were really the fault of the average "enterprise Java developer".
The reality is that these frameworks don't automatically lead to bloated code shipping everything.
Just to add Svelte (`pnpm create vite -t svelte-ts`) ~8KB
> You can create that kind of garbage with any framework, or without framework
I would think it would be quite a challenge to accomplish the given task without a framework?
before React took over, "SPAs" were written with jQuery and Bootstrap, and it was common to see a project with multiple copies of different versions of jQuery. Totally possible to bloat a website without a framework. just go old school!
Downloading =/= executing. Downloading 60 kb of compressed JavaScript isn't the problem, the problem is running that JavaScript, and all the resulting web calls that JavaScript will do, and all the resulting compute it will take to... I dunno, make the button round or whatever. Load time is no longer a solid metric for a good experience, that's very late 00's of anyone to say, the metric now is how long until the page is laid out, and the controls on it are responsive?
Edit: Also how hot is my phone?
absolutely. page performance is the result of a hairball of initial asset loads, AJAX calls, ad-hoc roundtrips, telemetry bloat, ...
It's so convoluted, and very app specific. Core web vitals provide the right framework to think about what is relevant, but in reality your app likely requires dedicated instrumentation to capture these phases accurately.
I test my damn sites on a fucking iPhone 6 from 2014. Executing that JS is a breeze.
React etc. runs just fine on absolute garbage kiosks. If you introduce 10MB of additional JS on top of 60KB of React, it's those 10MB's fault.
Downloading 60kb of compressed javascript takes way longer than executing it.
Executing 60kb of JS can take between 0s and infinity. You can't summarise it like this.
It's gonna sound elitist but every one of these confident assertions on the part of, for the purposes of discussion I'm assuming are defensive React developers, reinforces that a sizable contingent of the aforementioned developer community has no grasp whatsoever on the fundamentals of programming.
Hate me if you will, but holy fuck. "Downloading this code takes WAY more time than running it" with NO parameters whatsoever on what the code is doing is an absolutely ridiculous assertion.
Agreed. I don't think people realize that 5mb of a PNG is way different than 5mb of JS. The browser parsers that PNG way way faster than it parses JS.
The PNG also doesn’t then go off and start pulling even more data down off the network.
No, it comes across as if y'all are having a bad faith argument about something outside of your field of expertise...
Most React apps don't put an infinite loop in their components. The vast majority of the time it sets up initial state, maybe sets up a skeleton while loading some customer data, then shows a page with a few sections and a dozen inputs.
So "holy fuck" you should probably calm yourself down.
>You can create that kind of garbage with any framework, or without framework.
The whole point of the framework is to make even absolute garbage stick together. (While making the developer replaceable.)
I'm not happy about how bloated most React sites are, and I've mostly stopped using it unless clients specifically request it after years of it being my main framework, but...
> The issue is that these huge frameworks have made the web a horrible slow mess.
I don't think this is accurate. Most bloat in the web is caused by:
a) developers don't taking any time to optimize, lazy load, cache, minimize dependencies...
(This is partly on React, or may be on the culture around React that has made all of this normal and acceptable.)
b) the 300 tracking scripts every site has to try to squeeze as much revenue as possible
(I remember being shocked, some years ago, when I saw a site with 50 trackers. May be it was The Verge? Or some newspaper? Now I don't even bat an eye when the number is in the hundreds.)
React sites can be extremely fast if the developer cares, and the bloat it introduces is rarely relevant. The OP article describes a button as 78K, but that's because it's loading the whole of react for just a button.
If your page has hundreds of buttons, you don't bring 78K hundreds of times, and so complex sites built with React are not that inefficient.
As a Devops engineer, do you have stats on how much of that slowness is the framework or the actual app code?
> a) developers don't taking any time to optimize, lazy load, cache, minimize dependencies...
> (This is partly on React, or may be on the culture around React that has made all of this normal and acceptable.)
Yes, that, too. But you are forgetting that React makes all that opimizing work necessary in the first place.
Networks are fast. Machines are crazy fast. Almost 30 years ago I was doing on-line adaptation of Postscript print files. So some form input and re-rendering the Postscript with the updates from the form values. Basically instantaneous.
> Networks are fast.
Well, it depends on what you mean by “fast”: bandwidth or latency? While the bandwidth has improved enormously over the years, latency… not so much. And it never will due to the simple fact that the speed of light is limited.
Most of the slowness seems to come about by treating latency as something that doesn’t matter (because the testing is done on a local, low-latency network) or will improve radically over time because bandwidth did (which it will not).
Unfortunately, React wants to be both a rendering library and also manage state by tying it to the component lifetime, which encourages cascaded fetching - exactly the kind of workload that is sensitive to latency.
> Yes, that, too. But you are forgetting that React makes all that opimizing work necessary in the first place.
Isn't the runtime state optimization the only responsibility of React. It's a library. The rest goes for Vite, Deno et al.
Low powered android devices are a thing. Networks outside of Metro US, EU, and parts of Asia, are also a thing.
Check out google maps there’s more to the world than your open office.
His point isn't "network/hardware is fast, so let's be inefficient": it is the opposite. "network/hardware is fast, so why is the page still slow?". On lower powered devices and slower networks, it's even more vital to author lean applications and web pages — but "things are slow even when the hardware and network are fast" is a simple canary that we are swimming through some problems.
How would you spec such a "lower powered" Android device?
1. Even those low-powered Android devices are basically supercomputers
2. The Javascript bloat hurts those devices immensely. See "Performance Inequality Gap 2024" https://infrequently.org/2024/01/performance-inequality-gap-...
> a) developers don't taking any time to optimize, lazy load, cache, minimize dependencies... > ... > b) the 300 tracking scripts every site has to try to squeeze as much revenue as possible
Having seen the dynamics up close, I'd say it's far closer to the truth to say that the reason developers don't have time for a) is because they are having to spend all their time on things like b). I've not met a developer who doesn't want to build a better experience. I have met many developers who can't do so, for reasons outside their control.
Characterising it as "if the developer cares" puts the blame in entirely the wrong place.
It's both. The majority of web developers today suck, plain and simple. They thought they could make a lot of money doing web dev and don't approach engineering as an art form or a science. They just scrape by and do not level up on their own outside of or during work.
I've had to come in and rewrite apps before where the developers had full leeway and still produced an unmaintainable behemoth of third-party components loosely taped together.
Also, React is a nightmare. An absolute minefield with zero cohesive vision, with an ever-changing API and a culture of shaming developers who haven't switched to the new React paradigm-of-the-year. For a framework meant for serious adults, I'd check out mithril. It's small, API-stable and intuitive, and gets right out of your way.
> The majority of web developers today suck
Because they are what we called script kiddies back then, copy-pasting from SO and now LLMs.
I do not even know if they would classify as "junior" devs.
This does not apply to ALL web developers, but many.
They still existed and wrote shitty code 20 years ago, or 30 years ago.
> React is a nightmare ... culture of shaming developers who haven't switched to the new React paradigm-of-the-year
proceeds to shame and suggests changing to the new paragdigm of the year.
> For a framework meant for serious adults
I have been using mithril for a decade. It isn't the new paradigm of the year. It's been API stable for a long time.
And the sentence you quoted is a dig at React and the React ecosystem, not individual developers.
Nice try, though!
mithril is hardly the new paradigm of the year
> Also, React is a nightmare.
I think React is a “nightmare” in similar way that JavaScript is a ”nightmare” - it certainly can be, if you abuse it, and it makes it a little too easy to do so.
However, you can take “just the good parts” and ignore the rest. For me, that means using React as a rendering library and managing state almost entirely outside of it.
I've introduced mithril at three different companies to audiences of non-UX engineers and it went well each time, resulting in small, static, API-driven single page applications. For my Software Engineering class, I'm able to get the basics across in a day and let students iterate without having to set up build tools for them. Huge fan.
React seems to be a self-perpetuating ecosystem at this point, and I keep reading about the next framework-of-the-month being tied to a specific vendor or having an uncertain future with funding/bugs/forks.
https://mithril.js.org/
I'd think it has about 60% cohesive vision, but that's just a ballpark, 0 seems way to low though.
Fair. I'm curious, what do you think are the best-designed and most cohesive parts of React?
The idea of JSX is I think genius.
If I were making a component rendering type library before React I would probably end up making some fake attributes on HTML elements the way Angular and a lot of other people do. It's a pretty simple idea. Pretty much everybody was doing it about the time of Backbone and Angular etc. etc. I'm sure you can think of other examples.
But whoever first came up with JSX said hey, if we're already making non standard HTML why not go all the way, allow you make your own semantic tree that we "render down" to HTML.
This of course allows you in fact separate out the media target - HTML, Native App, PDF, graphics from your renderable representation of that in code, and thus have different renderers for the same declarative way of structuring content.
https://github.com/chentsulin/awesome-react-renderer
So to me JSX is actually a sensible step up in abstraction layer, although not all the way yet, because you still need to have lots of specific knowledge of your particular media rendering target.
This is perhaps of particular interest to me as in about 2004 I was working on a media management system where the idea was you would feed in multiple markup formats, and a configuration for the media, and then use an in house declarative language to dynamically do things in each media, without having to have much understanding of how the media worked internally because our rendering pipeline took care of that - generated pdf, DHTML website (fancy menus), HTML help, and emails - with of course possibility of saving data for reuse in different media and cross media styling (use same company logos, color schemes, email addresses without having to write code for them in each media etc.)
sorry about last part, old programmer wandering.
I would never want to write template files in something other than JSX at this point. Every library that does binding via HTML attributes is a huge step back, as far as I'm concerned.
I'd also say React's one way data binding was a big step forward when it was released. Where it (and TBH, many other SPA frameworks at the time) missed the boat was form handling, which it turns out is like 90% of the Internet and internal applications.
I wouldn't say it's 90% (although my last quibble regarding percentages in this very thread got downvoted to 0) but it is tedious and sort of difficult because of the tediousness, but not sure I have ever seen any solution for forms that made me say, damn I like working with this.
What is truly remarkable about it is that it’s just JavaScript (after some transpilation), which means you can easily use JavaScript’s control structures. Conditional rendering has never been so easy!
I've seen this happen many times:
Dev: Hey, I added that screen you asked for- take a look and tell me what you think- any layout changes, wording, etc.
PM: Looks great! Okay, the next thing is...
Dev: Hold on! I need to go back and clean up some of the code I put in there to test a few ideas, and there's a loop in there that has some side effects if some if the timing is off.
PM: This looks fine. Let's move on to the next thing..
If the PM is like that, the dev should eventually learn not to speak up until they're ready to move on to the next thing. To be clear, the PM should listen to the dev.
But the system persists because both people are complicit.
Isn't this one of the main selling points of apps like Balsamiq, you can present something that looks sketch like rather than a completed page.
https://balsamiq.com/product/
When starting from scratch: yes. When maintaining a mature application: no, because then you need to keep in sync the app and balsamiq and there is neither the time nor the will for that. And the money.
I'm still designing on paper with crayons (not a joke)
I design with pencils, but I thought crayons would give the PM something to chew on when there is technical discussion.
Are your designs huge ?
One screen per paper I print with special guides. So, I've got various resolution represented. The I just take pictures of the drawings, load them into this webtool and connect them together.
Like a super low budget Balsamiq
I'm kinda digging the idea.
Maybe I'll show HN, it's one of those ideas I have that just feels "too dumb" to be useful outside of my universe.
That's a good point. I didn't mean to demean React developers: I've been one for years and I can't say I optimized everything I could've.
The blame for not caring enough about performance and UX is on the whole industry. That does include developers, but not just them.
How can you close the ticket without "taking any time to optimize, lazy load, cache, minimize dependencies..." if that is in the AC/DoD?
Why don't those developers that care put important things the AC/DoD?
Maybe they're not doing Scrum?
I’ve worked with plenty of developers who will argue that it’s fine on their development environment and their machine on the same network with test data and that it must be $OTHER_TEAM who is causing it. Arguably more of them than ones who really care. The problem is it only takes 2-3 of those people to bring the whole thing crashing down.
I would go farther and say it's not even a lack of "optimization", it's a bloat of spaghetti logic that no sane person would ever write, driven by teams that don't talk to each other and are constantly pushed by stakeholders to add more layers instead of cleaning anything up
It has nothing to do with the frameworks. Except maybe that they empowered developers, including the ones cranking out bad code
> developers don't taking any time to optimize, lazy load, cache, minimize dependencies...
I built much more performant apps without lazy loading or caching when using html and a sprinkle of JS.
Exactly. If it's a common enough occurrence that most React SPA's are slow and bloated, it may not be the framework's fault, but if changing to a simpler framework makes it better, then it's just a semantic argument
We built a document management system as React SPA which is very performant.
Key: when user clicks on something, this causes 0 to 1 HTTP requests.
We didn’t do lazy loading or caching either.
> the 300 tracking scripts every site has to try to squeeze as much revenue as possible
Just the other day I was appalled by a new record, 1604.
I'm increasingly of the opinion this stuff needs to just be banned outright by law. None of the businesses I've talked to seem to be aware of how dishonest it looks to say "we value your privacy" while trying to get users to agree to get more companies than there were pupils in my secondary school to analyse them.
EU has laws that give back control to users.
But for this to be effective, the browser should be cooperating and working on the user’s behalf to limit tracking. (You know, the whole reason why WWW calls it “user agent” — it should be on the user’s side.)
Unfortunately >90% of browsers use an engine made by the greatest beneficiary of user tracking. Hundreds of billions in future profits might be endangered by giving users actual control. The proverbial fox guarding the hen house.
> the browser should be cooperating and working on the user’s behalf to limit tracking
I hear Microsoft is working on a new browser that gives the user more control over cookies:
1. It shows a confirmation dialog before setting a cookie
2. The site can declare a machine readable policy (P3P) specifying what the cookie will be used for, which the browser uses to automatically decide if the cookie should be permitted.
They plan to call it "Internet Explorer" or something.
Where do these 1600 trackers even come from? Does every text writer add their own in the CMS? Is it not managed centrally? Or does every web component load their own flavour?
I didn’t even know there were 1600 different distinct trackers around.
Did the page have any ads? Because ads themselves often also contain lots of third-party tools, for fraud detection, the bidding part, tracking, retargetting...
>the 300 tracking scripts every site has to try to squeeze as much revenue as possible
Let's say tracking for revenue is required and not an argument to be made. The question I never quite understand is why cant we have ONE scripts to rule them all? I remember there was a company / services that may be called Segment? And quick google search doesn't have anything familiar, that offers something like that.
The reason we still have 300 scripts is that ad-tech companies want direct control over their tracking rather than relying on an intermediary.
So they make it harder or more limited to integrate with tools like Segment.
> why cant we have ONE scripts to rule them all
Because those tracking scripts are provided by competing advertising platforms and they want to own the data.
Nobody trusts anybody else. The site wants to over estimate clicks, the advertiser wants to under estimate. Of course the numbers won’t match up because you lose people along the way. If you have 300 trackers they can’t all be lying to you.
>The site wants to over estimate clicks, the advertiser wants to under estimate
Only if you show the ads. Many companies do not, but still use lots of trackers. Why? Because their performance marketing team is trying to find the right mix of advertisement channels, so they go for paid search and clicks to Google, Meta and lots of other AdTech. In that case trackers are needed to optimize spending by analyzing user behavior. If certain cohort spends more time on the site, they will get more ads of it. If another cohort leaves the site quickly, they will see less ads. The promise of AdTech in general is that they personalize ads as much as possible to reduce your customer acquisition costs (CACs) - you won't waste money on showing ads to people who won't buy your product. So they need the data and they have to own it, because personalization is their competitive advantage.
Arh! That makes a lot more sense. Thank You. Sometimes I do wish I could learn a lot more about online advertising. But it is mostly a forbidden topic on HN.
Yeah, I think both these are true:
1. React is bigger and slower than it needs to be. There are likely better choices today. 2. Most websites will be bigger and slower than they need to be due to the endless September of new devs, and the rarity of being given space to focus on size/performance. As React is popular, it means even if React was tiny and fast, these websites would still be slow.
Why would React be bigger and slower than it needs to be? It's a very mature project with a professional development team behind it, I'm sure we can trust them to tackle whatever unnecessary bloat they may have. I think we should be able to trust that anything that is in there serves a purpose, and that it serves hundreds of niche edge-cases that someone will eventually run into but are non-obvious until it's widely used.
These kinds of statements are only true if you're willing to sacrifice in other areas such as maintainability, security, stability, compatibility, accessibility, extensibility or something similar.
I understand your answer is in good faith, but it still sounds like the same generic answer given when someone questions the engineering quality of any other popular product or service.
The fact is that plenty of teams are mature and professional and yet most software still suffers from bloat, slowness, bugs. Why would React be different?
Preact, for comparison, is only 5kb or so, and has almost 1:1 feature parity. It's not fully drop-in without the compat, and even experienced React devs can nitpick about it, but that's not the point: the mere fact that it exists and gets the job done is enough to raise doubts about the need for React to be quite big.
Does React need to lose weight? Maybe, maybe not. But I don't think it's good to shut down those discussions.
I think the same generic answer _does_ apply to most mature projects. Libraries like these should be approached like discussions about starting over in mature software projects; "this time we'll do it correctly", or "this framework is much simpler". This applies very much to libraries such as these.
When the complexity is low, projects are easy to learn, maintain and handle. That really makes them seem better and have advantages – advantages like a much reduced bundle size. But these new setups just don't do the same thing. It's a shell of what the old project did, as it's missing solutions for hundreds of edge-cases and other requirements that were tackled by the mature many-year old project that is maintained by some of the best developers. I'm sure React has a bit of bloat, but I'm willing to trust the React team that the vast majority of it is there for a reason. It might also be the cost of building on top of a very mature solution.
Would you not shut such a discussion down when someone new in the team proposes a complete rewrite?
Preact does not have 1:1 feature parity, if it had it would have been much more widely used (who wouldn't want a free filesize reduction?). Preact has plenty of issues, which is why it isn't as widely used.
No, I would not shut down discussions. I appreciate new points of view, and I’m fine with being challenged. I would especially not shut down discussions when my assumptions are nothing but a hunch.
> Preact does not have 1:1 feature parity, if it had it would have been much more widely used
Like another poster said, this is a logical error. Preact is fully featured.
Author here. React’s absolutely mature—no question there, with a skilled team behind it. But the button example highlights something off: a single component outweighing an entire app feels fundamentally broken. There’s clear room for fresh alternatives, especially now. You can see it here on HN—seasoned devs wrestling with React’s wild complexity. Nue’s a stab at fixing that.
> a single component outweighing an entire app feels fundamentally broken.
I think this is an overly dramatic take. Of course react has a fixed overhead. If all you're deploying is the single button, then that overhead is for no benefit. But the overhead gets amortized over your entire app, which most likely has thousands of components. This is like a microbenchmark which only measures the static overhead. Not indicative of a real app.
There's an entire cottage industry of "react" but smaller frameworks out there. Somehow, none of them have caught on.
Preact is the one I'd go for if I wanted a smaller react because it's quite mature and it provides the same API.
> a single component outweighing an entire app feels fundamentally broken
It just doesn't to me, understanding that in react-land, a single component and an entire app will have roughly equivalent size, if you're not pulling in any other dependencies.
No one (I hope) would ever use react for a single button, so it feels like an unhelpful comparison.
I don't think that is fundamentally broken. React is just not the right technology for a single button, and it's not trying to be.
If you tried to use photolitography (the technology used to print the circuits in microprocessors) to do tattoos... well it could probably work, but it would be highly inefficient and expensive and bad.
React is for complex web applications, and it I don't think it's a very valid criticism to say that it is bad for a different use case. To some extent, the React community may have over-promoted React as the final web-dev framework, but that's also a mistake.
In any case, kudos on creating Nue, looks really cool, I'll keep an eye on it ;)
Compare React and Preact:
https://preactjs.com/
I use Preact often and very, very rarely run into an issue that justifies React being almost 20x the size.
Is it really React or the stuff it lets you bring in? Many React apps have at least one big widget set (say MUI or reactstrap or …) and then a number of “best of breede” components that do various things. It’s rare for components to be styled with plain CSS these days so you probably have to bring in Emotion and styled-components and Tailwind and …. It is all code that goes into the bundle and it’s a burden on your mind because these are all leaky abstractions and don’t absolve you of understanding CSS.
A someone who's been developing for the web for a living since the late 1990s, I agree that nothing absolves the web developer of the need to understand web fundamentals. But laying blame for bloated SPAs at React's feet is misplaced. With SSR, you can ship React apps that work with JS disabled. And with static extraction (a la vanilla-extract) you can do CSS-in-JS with 0 runtime overhead. Being mindful of bundle size and user-perceived performance is essential. For those that pay attention and leverage the web properly as a platform, amazing performance (and capabilities / UX) with React is achievable. See https://Remix.run.
Oh I agree. Was just addressing OP’s argument that surely React is as optimised and small as it can possibly be. I’m personally not convinced.
If Preact truly was as feature complete as React, it would be used by everyone by now – it's old enough for most teams to be aware of it. The fact that it isn't widely used is case in point.
> If Preact truly was as feature complete as React, it would be used by everyone by now
That's a false logical conclusion.
Preact (and others, like Svelte and Solid) are not only "as feature complete as React", they don't need some of the features of React (hooks are unnecessary when you have proper reactivity) and they are better at certain features (like SSR).
People using or not using them has nothing to do with feature completeness.
Fair enough. The quoted statement doesn't hold outside the context of the argument that Preact has feature parity. You can build the same apps with Preact and those others, you just need to sacrifice other things.
Again, there's no such thing as "feature parity" because some (many?) of React features are not required by other frameworks.
E.g. you don't need React hooks because Preact has signals: https://preactjs.com/guide/v10/signals/
Does this mean that Preact doesn't have feature parity? For a very strict definition, no it doesn't. Does it mean you need to sacrifice anything? No.
Same goes for many other frameworks. In modern landscape when it comes to features and abilities React is actually quite a poor offering.
Not really. Developers are as susceptible to marketing as anyone. React is backed by Facebook. Preact is... not.
I get what you're trying to say, but aren't you blowing it a little out of proportion? At my job we have an SPA that loads a dashboard with 20+ widgets, all doing their own requests, transferring 2+ MB (compressed) of JS. It loads in two seconds, with all caches disabled. And I mean full load, not "ready for interaction". It runs on Vue 3.
I agree that the web could be lighter, but "finding one that will do a first load under 10s is close to impossible" sounds like exaggeration - it might not be due to the framework or lack thereof.
Btw, the webapp I'm describing is NOT built by the best of the best.
Now test it again on a 5 year old mobile device on a 3g connection with some packet loss, not in the sterile environment that is your office with a last-gen i7 processor.
Well, the post I replied to said "on a 10G connection peered within 5ms of the host" so I think it's fair to assume they also were in a sterile environment. I'm even on a lower connection with 20ms+ ping!
5 year old mobile isn't as slow as you make it out to be. Cheap 2025 phones is significantly slower than my 8 years old iPad. Also 3G could be fast and it isn't the protocol that makes the speed to <1Mbps.
Could be a desktop PC with 25/3 ADSL where somebody is streaming Netflix and a game console is updating itself.
The thing is, enterprise web applications are not built for phones. This would be like telling someone to run the latest Ubisoft game on a PC from 2-3 generations ago, and expecting it to perform well.
Today's applications are more complex than ever, bloated perhaps, but the demand for features, complex visualizations, etc. rise with the patterns of seeing them more in other applications.
This. So many people—both on the dev side and the annoyed HN commenter side—act as though all websites have the same requirements. They don't. The usage profile varies enormously, and if you treat every website as just a website without considering the context it's used in you're going to either waste a lot of time optimizing things that don't matter or you're going to make your app suck by not adjusting properly for your users.
I know I'm weird because I grew up in the 90s, but 2 MB of JS to show a dashboard with widgets still doesn't quite compute in my brain.
It's not just 2 MB of JS. I'm describing ALL traffic, also the JSONs received, CSS, images, everything.
Besides, we show many charts, and believe me when I say: financial people are PICKY when it comes to chart functionality. It needs to have EVERYTHING or you're not considered serious.
It sounds like you're developing a turn-key highly interactive application for a very particular niche of users. It makes sense that for them the tradeoff of downloading 2MB of Javascript makes sense versus enjoying their bells and whistles.
But for the rest of the internet, where users sometimes view your page with decrepit browsers riding on hobbled connections, 2MB is too much. Worrying about these people is not blowing it out of proportion. It's basic human decency.
I think you are mostly describing the difference between a web application and web site. Where lately frameworks for building web applications have been used to build web sites.
Sure, but I think there are devs out there that are making that confusion, and parent comment I responded to seems to not be aware of the difference. You know it's not the guns that kill people, it's the web devs.
Interesting that you think that I'm not aware of the difference, lol. Whatever.
Yes, because you're rebutting to a post about light(er) web components by saying that we're blowing it out of proportion since your specific case with very specific users can work with 2MB of Javascript. You gave no indication that you're aware of other use cases that will benefit from these smaller frameworks, and even though I am aware you can't put in one couple hundred words post everything about your knowledge you showed zero empathy towards web users that are different than yours. Apologies if that's not the case, I still feel like it's a discussion worth having. More so if you agree with my words.
Heh, I just literally built a toy dashboard in dioxus that loads just about 2MB of code, and then 700KB of css (tailwind, not optimized) and 1.5MB of payload data to visualize. Then again the 2MB includes ~1.7MB of just static data that I included in the wasm build for convenience since it will always be needed. :D
(this was a learning project in my free time, no I'm not defending this in any way, although I'm actually quite happy with the solution of including static data in my binary)
It's interesting. I believe many of the people here know how it goes. There's no possibility of shrinking this further. It will only expand; we just have too much going on. We do have a genuine use for SPA, though - our webapp IS as complex a web-app can get, we offer no mobile version (for that, get the app).
Transfer's only part of the story (and 2MB is a ton on anything but a great connection)—the rest is memory use, which will tend to be some multiple of the transfer size, plus whatever your code initializes, and processor cycles.
> I see a lot of people angry at "Nue" in various ways
Interesting. I see people making overlay-broad claims without evidence or justification.
> I deal as DevOps/SRE daily with these services, and finding one that will do a first load under 10s is close to impossible
Nobody is going to call in for your help unless something is wrong, so don't be surprised you haven't seen anything right. That just means people are keeping the good stuff secret (and/or they don't work for your company)
> I can't help but think these are people heavily relying on React and missing the overall issue.
That's too bad.
I think that everyone who works on a slow project knows it's ultimately Management's fault, and when a codebase gets so big that nobody feels like they can fix it anymore, that's Management's fault too.
Maybe you can think if Management called you in earlier you could've designed a better thing, but guess what: I think that would be Management's fault too.
> but I can at least root for them
Can you imagine if any of what you said was really True, everybody believed you, and everybody actually stopped using these "huge frameworks [that] have made the web a horrible slow mess", and that actually solved "the overall issue" so that all software is perfect and reliable? What exactly do you think a SRE does in this case? Do you think that's even a job?
I really suggest trying to look at things differently, because I think for your skills there's a huge opportunity sitting right in front of you if you can see it.
Well most stuff going wrong in apps is actually managements fault. At least in my experience. Either directly or hidden in their decision making.
The real question is, do we actually need "frameworks"? Pure JS works pretty well, and no JS at all even better.
I recently worked on an SAP project where there was a whole Java layer in front of SAP, and then a huge Angular app on top of it all; but since the point of the application was to manage b2b sales of physical things and it mattered very much whether those things were in stock, almost every screen did a full request to the SAP layer. The need for a thick "rich" client was unclear, and PHP would probably have worked much better.
Hype aside, it seems big organizations are using frameworks as a mean to ensure uniform coding practices and make developers more easily replaceable; but surely there are better ways to achieve that.
Not every page or app needs framework. But building complex app without one would be very hard and time consuming, and your team would need to come up with ways to solve problems like architecture, code structure, routing, data management, state management, etc. So you would basically reinvent all the wheels on your own cost, and you will have a non standard solution, that would not be compatible with libraries out there (for example UI components) and neither with new devs. Before Angular and React came I was building apps with plain JS with jQuery (not a framework, just a lib) and I would never go back there.
I agree. In a recent small project, I ran an experiment: first, I built the app in React, then in Vue, and finally in vanilla JS. In the end, I stuck with the vanilla JS version because it was significantly smaller, easier to deploy, and much simpler to maintain long-term.
As someone who's worked on web apps with and without frameworks, yes, we need frameworks, especially if it's a large one or if there's a team of more than a few people involved.
The good ones these days like Vue or especially Svelte are barely any different to how you'd do things the "vanilla" way except they provide some sane QoL features like components (anyone who says web components are the answer has very obviously never used web components) and sane data flow management to and from said components.
I mean, more power to you if you want to handle complex states without the features a lib like Vue or Svelte provide you, but in my experience you eventually end up with a homecooked framework anyways, even for apps that aren't that complex. And at that point you're just doing React or Angular or Vue, but worse in every conceivable way. Yay for going at it vanilla, I guess?
> but worse in every conceivable way
I always had an issue with that sentence (and I heard it a lot). Why would experienced software developers always come with a solution worse in "every conceivable way" when implementing logic answering a problem they're having, which would have the huge advantage of being tailored for their own needs?
I'm more of a library developer than an application one but I've seen that many JS webdevs have an aversion toward trying things themselves - instead always going for the most huge/"starred" dependency when they can. I'm not sure the impact of this philosophy is always better for a project's health than the total opposite where you would just re-invent your own wheel.
I do have seen multiple attempts at doing a specific homemade architecture that worked out well for some applications with very specific needs even 10 years later (For example I'm thinking about a 500k+ LOC JS webapp - not intended to be accessed on a desktop browser, but that's not the only successful long-lived JS project I know with their own archi). And I guess a lot of webapps do have their own specific needs where the "default framework" solution leads to some inefficiencies or hard-to-maintain / understand mess.
> I mean, more power to you if you want to handle complex states without the features a lib like Vue or Svelte provide you, but in my experience you eventually end up with a homecooked framework anyways
If state needs to be managed client-side (which is not always the case), then yes, a library is helpful. But a "framework" provides much more than state management, and those other things are usually dispensable, IMHO.
> The real question is, do we actually need "frameworks"?
Yes. The advantage of having a common API across thousands of web apps shouldn't be a point of discussion.
The advantage of having a common API across thousands of web apps shouldn't be a point of discussion.
We have one. It's called "the browser". The discussion is whether or not we need a higher level API than that. If we do, maybe that should also be a part of the browser's API.
It would be easier if "the browser" is just one target.
As it is, there multiple browsers supporting different levels of features.
That's the whole reason why frameworks are made in the first place dating back to jQuery.
The days of IE6 which justified jQuery are long gone.
All browsers that matter now support a solid common set of features which should be sufficient for the vast majority of cases.
> All browsers that matter now support a solid common set of features which should be sufficient for the vast majority of cases.
All it takes is one of those non majority use cases and you're going to need some kind of dependency to get things consistent
Frameworks like Vue 3 don't actually work on older browsers since it requires ES2016 support in the browsers.. that means IE 11 and older browsers are out. With Svelte you need Microsoft Edge (IE 11 is not supported). Also, it requires Firefox 74 (released in 2020) or newer Firefox versions.
With React, you can make it work with older browsers using Polyfill etc.
You still can‘t style select elements in anything but brand new alpha chrome. It‘s been 20 years since that feature was requested.
> The discussion is whether or not we need a higher level API than that.
Try using DOM APIs to build anything remotely complex or interactive. There's a reason everyone who only uses browser APIs ends up just dumping strings into the DOM via innerHtml.
> Try using DOM APIs to build anything remotely complex or interactive.
I think the core question is: Are we building something complex or interactive. I don't see the need for React or other frameworks unless you're storing a lot of mutable states client-side. But more often than not, all I see is replicating the database through API endpoints.
Any user facing website that is not a portfolio site is interactive. The days where the web is display-only are long past.
„The browser“ doesn‘t exist. So no, we don‘t have one.
Pure JS is that interface... you're arguing for multiple unnecessary abstraction layers piled on top of each other.
More abstraction != easier to use.
Spot on. HTML, JS, and CSS deliver a clean separation of concerns—a perfect blank slate for killer products. You just need a few key pieces to tie it all together: templating with loops for repeating HTML chunks and a way to stitch in headers, footers, or sidebars. For apps, a routing system is a must. And HMR to supercharge your dev workflow. That’s Nue in a nutshell.
> HTML, JS, and CSS deliver a clean separation of concerns
There's nothing clean about this separation, and concerns are never as neatly separated as people pretend they are.
> For apps,
For apps you need actual app-like things where your separation of concerns looks like the right image here: https://x.com/simonswiss/status/1664736786671869952
>> HTML, JS, and CSS deliver a clean separation of concerns
> There's nothing clean about this separation, and concerns are never as neatly separated as people pretend they are.
It's very clean and something repeated by almost every UI framework and document system. The separation is between structure, style, and interactivity. Most web apps actually fits the document models where you have content pages and forms. But people wants to bring desktop and game UI patterns into that. And make it a mess.
> It's very clean
It's not
> something repeated by almost every UI framework and document system.
That is, hardly any UI framework separates these things. From Windows APIs to SwiftUI there's rarely a system which tries to separate these concepts. Because however hard you pretend they are separated, they never are.
> Most web apps actually fits the document models where you have content pages and forms.
Even in a document your styles are linked to the structure of your document.
> Because however hard you pretend they are separated, they never are.
That would hold true for whatever systems. The pretention is just for making it easier to do the job without extraneous effort. Cascading is a nice pattern for applying properties in the case of a document. JS was originally intended for scripting (not for full-blown application) and the DOM API works fine for that. Without that, we would have to put everything in HTML or have something like Flash.
> That would hold true for whatever systems.
Remember how you started with how every UI system and framework was somehow this separtaion of style and presentation and structure and interactivity?
And now it's "they are never separated, and this holds true for whatever systems"
> The pretention is just for making it easier to do the job without extraneous effort.
In reality there's a lot of extraneous effort especially when systems become more complex. BEM was invented not because CSS was great and amazing at reducing effort, but because it was adding a great amount of effort for a very large number of designs.
CSS Scoping was finally, thankfully, added not because cascading nature of CSS reduces a lot of effort.
The rest of your comment has nothing to do with what I said.
> And now it's "they are never separated, and this holds true for whatever systems"
What I described as separation is a a decomposition into modules which are linked together through a contract. CSS has cascading and selectors, while JS has the DOM API. Otherwise, it would still be attributes on tags.
BEM is just a development technique, not a technical requirement or capability. Without cascading, we would probably have components and inheritance.
> Remember how you started with how every UI system and framework was somehow this separtaion of style and presentation and structure and interactivity?
On Android and iOS, you have XML for layout. QT and GTK have support for CSS like styles. I remember at least one of the have supported XML for layout definition. They're not required, but they make it easier to build the UI as it almost always have a tree structure.
> What I described as separation is a a decomposition into modules which are linked together through a contract.
wat
> Without cascading, we would probably have components and inheritance.
indeed. That is why I wrote what I wrote about BEM and CSS Scoping
> They're not required, but they make it easier to build the UI as it almost always have a tree structure.
Those systems have support, but there's rarely, if ever, a true separation of styling and structure. There's a reason for that, illustrated here: https://x.com/simonswiss/status/1664736786671869952
The separation between CSS and HTML is a good idea in a very theoretical abstract academic sense. It never ever worked in practice.
Your comment shows that you don‘t have a lot of experience in that matter. „Pure JS“ (there is no such thing) has perhaps the tiniest standard library of anything out there. The rest is browser vendor code, of which a lot depends on browsers and versions. Hell, they didn‘t even get date parsing right.
"Pure" JS exists as a concept, not a project.
Having a tiny standard library is also a good thing, not a bad one... I'm not saying its an ideal API but in general, smaller==better (within reason).
I worked at a startup where one of the original devs had “strong opinions” on JavaScript frameworks. “It’s all bloat!!! We don’t need that crap”. So consequently all the new engineers had to learn this dude’s codebase, which turned into to be… A framework! Only instead of a documented one that had plenty of support it was an unholy mess that required extra time to build all the stuff missing from the it’s-not-a-bloated-framework-but-pure-JavaScript-framework.
Guess what happened the day after the dude left the company? All the engineers immediately started to replace the unholy mess of “totally not a framework” framework with an actual one.
Guess what happened to development productivity and product quality? They went up dramatically.
IMO, this framework is built for use cases normally handled by React-based static site generators. For instance, a simple marketing site for a company. In these use cases, React is obviously an overkill. You wouldn't want your users to download, parse, and execute 2.8 kB of the React runtime just for simple buttons, tabs, and routing.
However, I don't find this framework suitable for more complex state-driven applications. If you want to build X's front end with this framework, you're just shooting yourself in the foot. It won't take an hour before you hit the framework's design limitations.
Just choose the right tool for the right job.
Author here: You’re right that Nue shines for simpler sites—like marketing pages, blog, and documentation. But calling it just a static site generator misses the mark. This latest release (check mpa.nuejs.org/app/?rust) handles a Rust-powered SPA with event sourcing over 150k records—far beyond ‘simple.’ For state-driven apps, Nue’s model-first approach keeps things clean and scalable—limitations are there, sure, but they’re not the foot-shooter you might think. Right tool, right job—totally agree—just saying Nue’s toolbox is bigger than it looks!
> Nue’s model-first approach keeps things clean and scalable
Like I understand why you say this, but as someone who spent the 2000s building "model first" web apps (and desktop applications), I don't miss it in the slightest. Immediate mode-esque render loops didn't catch on just because it's a fad, it really does fit a lot of highly interactive things better.
Of course the bigger problem is people using something that's great for heavily interactive web applications for building things that _don't need_ that interactivity...
Nue looks great, and I think it stands on it's own two feet. The constant React bashing just turns me off it more than anything (and that's not about React specifically, I have no real love for it, just that kind of project marketing isn't my cup of tea)
Thanks for your reply! The misconception might stem from the lack of clarity in the documentation regarding how islands (components) work.
- How do I declare local states (instance variables) in an island?
- How do I fetch and display data from an API?
- Where should we place data that is normally kept in contexts/stores in other frameworks?
These are common problems faced when developing an SPA, but missing in the documentation.
hmm, it looks like you've got a bug in the demo app. if you type too quickly into the search bar, the entire app slows to a halt.
seems like you'd want to move the filtering logic off the main thread, or you'd want to reinvent React's "Fiber" suspendable rendering architecture.
> Web SaaS companies just wanting to use "common" frameworks
Companies obviously want to use what works well and been tested and tried in production. If Nue achieves that with significant benefits outweighting the migration costs it will become the new common.
The "problem" with React is that it improved developer experience and efficiency by a ton compared to what was there before it, and not because of anything else.
I often hear it said that devs should use slow machines and connections for development. That's a great idea (and it can be simulated) in theory, but in practice very few people are going to buy old ThinkPads to test on. So a solution should probably be done in software, i.e. at the level of compilers and runtimes.
i.e. if JS engines weren't so fast, bloated frameworks would be impossible, even on dev hardware.
So I'm wondering if just like C++ compilers have optimization levels, perhaps there should be negative optimization levels, where all your code runs 10x slower by inserting dummy instructions (or perhaps a browser for testing that uses a naively implemented JS engine).
This would allow you to directly experience the pain you're causing without leaving the comfort of your fancy dev machine.
Then again by the sound of it, the release build of the app running on v8 already takes 10 sec to load, so we have already achieved the goal of gross lag without special tooling, so clearly people just don't care (or are working in systems where they feel powerless to fix it)?
> So a solution should probably be done in software
In Chrome you can simulate a slow connection on a slow device via the dev tools. Firefox has a similar feature.
It's not entirely what you're suggesting (which is sort of like Chaos Monkey but for web apps I guess?)
Some way to simulate a slow CPU
Chrome DevTools have that too.
The context of what the application does matters. I'm extremely cautious when people hype up "download sizes", when such size is less than 1MB, because this is usually a sign of cosmetic obsession and/or disassociation from the real world value offered.
A 200-300kb "bloated" single page app which does the job of a 10MB "minimalistic" downloaded store app – is IMHO pretty incredible. It's doing the same work at nearly 1/50th the size, all else being similar (externally loaded images and stuff). Heck, even a 1MB page load size is still 1/10th smaller.
Sure, it can be argued that the browser does most of the heavylifting. The same can be said of Android or iOS too, definitely the OS offers _even more_ heavylifting than the browser.
Rarely is that a problem with react itself. Poorly written applications exist in every flavor of language, framework and library.
Some frameworks though make it easy to fall into a good default, and others don't.
Yep, the more complex an app can be, the more complex the app will be
As I wrote in my comment it's a cool project but the way it's presented as a takedown of React is so ironically wrong. People pick React when they need a rendering layer and want to write the rest themselves. People who need a monolith SSG that is optimized for this thing choose Vue/Astro/Next and the like and that is Nue's niche. If you write a rendering library that beats React at its use cases then be my guest please brag about it
Thanks for the take—glad you think the project’s cool. I get where you’re coming from: React’s a rendering layer for folks who want control, while Nue’s tackling a broader scope, closer to Vue/Astro/Next combo. The ‘takedown’ vibe isn’t the goal, though—more like highlighting how web standards can slash bloat across the board, even for something as ‘simple’ as a button. Nue’s not here to just beat React at rendering; it’s rethinking the whole stack to avoid needing so many layers in the first place. Fair point on use cases—definitely food for thought as we push forward
Cool, good luck! Building on top of Web standards is definitely a great idea and your (non-Rust) demo is pretty good. If I wanted to build a static webapp and was in the mood to play with something new I might try it.
So far this "re-thinking" is just dumping loads of innerHtml's and trashing the entire DOM.
The only reason it's fast is because browsers have been optimized beyond any sane reason.
E.g. your table demo removes and re-adds all rows on every button press. This is not re-thinking. This is throwing all we've learned out of the window and starting from scratch.
Nue JS reactive library is based DOM diffing. The next version also has keyed rows.
I looked into the code linked elsewhere in the thread and then just watched the behavior in the browser dev tools.
Delete the entire thing, recreate, delete the entire thing, recreate. That's as far as the amazing web standards will take you.
As soon as you start talking reactive, dom diffing, and keyed rows, you're literally in the territory of the frameworks you so love to berate.
Frameworks, especially modern ones, do all that and so much more (and leverage web standards whenever possible if those give an advantage)
> I deal as DevOps/SRE daily with these services, and finding one that will do a first load under 10s is close to impossible
I am currently in Indonesia on extremely flimsy and slow wifi at 1-2 bars that maybe tops out at 50mbps on a good day if no one else is on it and the gods align to grace me with a decent speed. Day-to-day, it's around 25mbps.
Doing a hard refresh of Linear (not affiliated in any way other than using them for work, but I know they use React), a complex project view that includes many graphs and other things like that, the full load time for everything on screen is 5.6 seconds with ~15MB of content loaded (this includes images and interactive graphs). DOMContentLoaded finishes at 360ms and the full interactive load is finished at 600ms, with me being able to click on tickets and navigate to them at the roughly 1s mark or less. Back home Linear load instantly for me with full interactivity, and the cached version of it even here in Indonesia is similarly fast.
It's not the frameworks slowing things down, it's usually all the bullshit that the business forces on its users that the devs have 0 say over. The app I work on loads really, really fast on dev builds that don't have any of the idiotic tracking BS enabled (for example on staging builds, which aren't even fully optimized builds compared to regular prod builds), but because the marketing, data and sales teams want their google analytics and 7 other tracking softwares, the whole thing slows to an unbearable crawl as we load in dozens of MB of packages each bigger than the Vue library controlling the whole thing.
A 10-second load time on a 10G connection??? That’s a peak throughput of 1.25 gigabytes per second. Even if we’re being conservative and assuming you’re only getting a quarter of that speed, that’s still around 3 GB downloaded in 10 seconds.
There’s no legitimate way a dashboard or notes app should be anywhere near that size. That’s not “just a bit of JS bloat” — it’s multiple orders of magnitude beyond what would be reasonable. The claim is not just exaggerated — it’s wildly misleading for anyone unfamiliar.
fwiw, I did not have the same take away as you from that part of the comment. I think the intent, and the way I read it, was, "Even when eliminating bandwidth and latency as a factor it still takes 10 seconds to load."
Indeed. This button comparison is quite telling, ragardless of the exact details. Definitely going to look what Nue is made of. It's refreshing to take a closer look at modern web standards — Nue or not.
> 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.
If you make a React page you will see that it is absolutely instant to do things. React isn't a huge framework. It's a very fast library. Even if you add in all the extras such as routing, it's all instant. It's almost jarring how instant it is.
A dashboard taking ages to load isn't going to be React.
"Instant" can mean different things to different people.
I have an HTMX/Flask/Bootstrap app that feels instant for most requests on the LAN, except when it doesn't.
Often React apps are pretty snappy, but if you want to do complex data validation on controlled forms, where the state updates for every keystroke, it can drag you down. There are good frameworks for doing uncontrolled forms in a disciplined way
https://react-hook-form.com/
but it's another thing to add to your bundle. React is also not fast enough to do animations so you have a lot of .show/.hide (or display: none) CSS has facilities to do transitions and animations that are pretty good but I always find it a little nervewracking for a JS application to have state in React state variables and any other kind of state. Some ImGUI frameworks have components that look superficially like React components but are fast enough to animate every frame, which makes me feel like I am in control and get the animation to look exactly what I want.
> I always find it a little nervewracking for a JS application to have state in React state variables and any other kind of state. Some ImGUI frameworks have components that look superficially like React components but are fast enough to animate every frame, which makes me feel like I am in control and get the animation to look exactly what I want
I know what you mean there. I had the same feeling back when I was doing frontend things.
I dislike the disingenuous discussion around it.
Last time this was posted, the author called out headlessui for being too complex, and presented a half-broken, non-accessible Select component as alternative.
Digging around the code, I found questionable decisions such as throwing away the entire dom when re-rendering a list.
I want framework authors to be clear about the tradeoffs they make. The Svelte and HTMX devs openly discuss the weaknesses of their solutions vs industry standards and are open about previous mistakes.
I'm a lot more open to "coding in untyped strings" these days, but if you ship yet another syntax on top of html without proper tools (lsp or whatever way for it to play nicely with typescript), then I find it rather lame. I'd rather just write truly vanila js and html, instead of using another "framework", for no apparent benefit.
Nue indeed looks interesting. I could not immediately understand whether it uses a one-way data binding. Without it, and without a reactive model of some sort, building large UIs becomes a pain.
The React-based button from some framework is either over-engineered, or does way more than just a button. Using or not using such a component is a choice.
React may be a bit large (like 30-50 kB for a "hello world"), but preact is below 6 kB and gives you 90% of the React power for lighter-weight apps.
Also, the point of React is building huge and hugely complex dynamic UIs. There are much lighter-weight tools to add small bits of interactivity to mostly static pages, which are still the majority of the Web. (Ironically, HTMX is 14 kB, 2.5 timex larger than preact.)
We also created fixi, which is sort of preact to htmx’s react:
https://github.com/bigskysoftware/fixi
a goal of fixi is to be smaller uncompressed than preact is compressed, to force us to be minimalist
This is really nice and simple.
I wonder how would the Web develop if something like this appeared in 1997 along with DHTML.
Most websites are fast before the marketing departments comes to bloat it with ads.
10s of site loading time without ads or videos is crazy, none of the 100 websites I'm using daily are way faster than that.
> I deal as DevOps/SRE daily with these services, and finding one that will do a first load under 10s is close to impossible
Come on. That can't possibly be true.
Anything that forces React off its boring throne of forced ubiquity is a good thing in my book, not only for its lack of optimization, but its unwillingness to move past its outdated APIs and state management patterns. The amount of limitations I've faced using it compared to other libraries / ecosystem is enough to drive anyone mad.
I will say these claims about 10-second load times are highly exaggerated though. I've built several large applications with Vue and React, and once compiled, load within 2-3 seconds, with any remaining time spent requesting data at the mercy of your servers, which is going to happen in any client-side application, including native apps; so this isn't browser technology's fault.
Once cached, loads instantly -- and anyone complaining about cold starts can take their criticism to native app makers for phones, or motherboard manufacturers for long boot times. It's hardly an issue because of caching, and I tend to think the complainers about the modern web are forgetting how much more complex our applications are these days. Raw speed for lack of features? Or a little bloat for more capabilities? Pick one, and accept the tradeoffs. Maybe one day browser tech won't force us to choose.
While there is a case to be made for slow internet connections (this is where Svelte and other compiled runtimes come in with SSR), for the average enterprise using a private SaaS, or home internet customers using public SaaS apps on the web, by-and-large the experience is going to be just fine, unless the team who built the app didn't optimize.
All that aside, it's refreshing to see more ground being broken in the area of speed — I'm all for it.
Generally, the thing that slows down "bloated" pages (a somewhat broad term) is either chained API calls, or GTM
Swapping out your render layer won't change that
Well said. The average person these days is mostly buying faster computers and phones so they can run more and more bloated web pages that just get in the way of getting to the text, images or video they want.
Qwik has the right idea for speeding time to interactive for complex web applications. This seems to be doing the same old thing as every other framework.
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
Author here: It’s true—Nue’s view layer is untyped. That’s by design. React’s ecosystem has devs slapping TypeScript on everything—even CSS—which is overkill. Nue flips it: presentation stays clean and semantic, web standards do the heavy lifting, and real static typing (like Rust or Go) shines in business logic where it counts. Thoughts on this?
> ... slapping TypeScript on everything—even CSS—which is overkill
Yikes, this framework will never fare well in any decent sized or above project.
Even Typescript is problematic sometimes, as it has several forms of coercion.
I manage 2 large scale production apps using Typescript (Along with the rest of the infrastructure) with a small team.
This simply would not be possible, had I not been guaranteed that things at least type check when reading diffs from PRs.
This is a silly take. There were certainly plenty of large projects written in JS before Typescript existed or became popular, some maintained by small teams or single individuals. There are plenty of large projects written in Python pre-typing, in PHP, etc.
I personally choose to work with typed languages most of the time, and I’m thoroughly convinced of their value, but acting like it is literally impossible to write a large project without types is just inaccurate.
No, you are right, it is possible.
But it would be significantly more expensive.
So I should probably preface and say that it is not possible within the budget I have (We are ~2 full time developing and maintaining everything on a 140k LOC platform spanning from infrastructure, backend, multiple frontends).
Yeah, it just means those teams had to do a lot of work themselves which type systems do automatically. Given that the entire point of computing is automating things which a human could have done by hand, it makes more sense to talk about cost rather than capability.
That feels more like you're being abused rather than a framework problem.
We are not really over worked. Nobody puts in more than 30 hours, and we deliver the features the business need.
However, we do have types and don't do type coercion. Types are sound full stack db -> backend -> frontends. We don't do any funky things. We don't use SSR (as the business does not require it). We test well, but not too much. We keep a sane architecture.
We can also skip out on a lot of project shenanigans and mostly focus on our work.
We don't (yet) use AI as a part of our workflows, and frankly, I don't see we can keep this way of working with the current gen AI.
> There are plenty of large projects written in Python.
There are, but they are certainly a pain in the ass to work with.
I once had to work on a semi-large Python codebase and got so frustrated that I wanted to port the code to some other language. The best part? I wrote the majority of that codebase myself, just months earlier.
I ranted about it here: https://avi.im/blag/2023/refactoring-python/
Yeah I mean, I've worked on a multi-million-line Python 2 codebase. It wasn't easy, but it certainly wasn't impossible.
Not sure why you're being downvoted -- large, legacy, untyped Python projects are a nightmare to work with.
Just keep in mind there are a thousand people right behind you who would be ecstatic to be able to work on this "nightmare" in order to earn a paycheck.
The only way it's possible is if you keep them in your head.
> There are plenty of large projects written in Python pre-typing, in PHP, etc.
Just a nit. Modern PHP is typed and has been for years.
> There are plenty of large projects written in Python
I've worked on one of those, and I would not recommend it.
This seems incredibly shortsighted. If you're building an application by yourself you're gonna remember the relations and dependencies - but even on a small team (say ~4 devs) or even if you don't pick it up after a while, there is going to be stuff you forget.
It's also nice when you move stuff around, you can rely on the LSP to rename and fix everything that breaks. If you have a simple website it's fine, but when you start to have multiple components... Losing typing is a huge deal.
WebStorm and the like do a fine job inferring types, saving me a lot of time.
Having the author come out and say that being untyped is a feature, is definitely one way to kill of any potential interest for that framework.
For the record, author is not crazy.
Svelte team also switched to JS with JSDoc a few months back[0].
You can see the majority of their repo is JS and not TS[1]
The cited reason[2]:
There was a lot of noise when this happened. Rich Harris (Svelte team) even had a comment on this on HN[3]. Dev sphere similarly thought they were crazy. But Svelte seems fine and no one seems bothered by this now.As long as author ships type def, it should behave just like a TypeScript library for all intents and purposes.
[0] https://news.ycombinator.com/item?id=35932617
[1] https://github.com/sveltejs/svelte
[2] https://github.com/sveltejs/svelte/pull/8569
[3] https://news.ycombinator.com/item?id=35892250
From the link [3] you posted,
> If you're rabidly anti-TypeScript and think that us doing this vindicates your position, I'm about to disappoint you.
Rich and the rest of the Svelte team are still using typscript, just through JSDoc + type definition files.
In contrast the Nue team seems to want to keep the view layer untyped.
From the parent comment
> real static typing (like Rust or Go) shines in business logic where it counts
it seems they don't consider typescript to be "real" static typing.
TypeScript is not "real" static typing in the same sense as Go, Rust, C#; the type information disappears the moment you build it.
Will happily accept: At runtime (and thus the need for schema validators like Zod, Valibot, et al because dev-land "static typing" is a façade) To be clear, they are not "using" TypeScript, it's more accurate to say they are providing TypeScript bindings.Their codebase (as in the actual code they are writing) is undoubtedly JS[0] with `.d.ts` bindings for TypeScript[1]. Author can also do the same and provide TS bindings at any point in the future.
[0] https://github.com/sveltejs/svelte/blob/main/packages/svelte...
[1] https://github.com/sveltejs/svelte/blob/main/packages/svelte...
And this is definitely a problem.
Had I had the opportunity to choose a language across the entire stack with mature wide adopted frameworks and libraries, I had done it.
Had there been something line Rust, Go, Java, C#, etc. that would work end to end, that would have been amazing.
In practice, even the weak safety typescript provides catches so many bugs before they hit production that it is indeed worth it - I have more than 140k LOCs of Typescript in production, and that would not be manageable without types.
And to be just a tad pedantic: you have JS in production; your TS is only in dev.
It's not that you can't; it's that you choose not to (and yes, generally for good and valid reasons). There are end-to-end solutions for C# (e.g. Blazor), for example, that are perfectly fine depending on your use case (not great for all use cases). Fable is another example using F#[1]There are also libraries like Bootsharp[2] that are doing interesting things, IMO, and has some of the same energy as OP's project (moving the typing and logic into a runtime that supports runtime static types and interfacing minimally with JS)
[0] https://google.github.io/styleguide/jsguide.html#jsdoc
[1] https://fable.io/docs/
[2] https://sharp.elringus.com/
> you have JS in production; your TS is only in dev.
As my sibling says, this is wrong. We indeed have TS in production.
Even for the parts that are being compiled to JS: You wouldn't say: You can not have C++ in production, only binaries.
The fact is that we don't write any JS as a part of our platform.
> It's not that you can't; it's that you choose not to
I think I made that quite clear in my comment.
> a language across the entire stack with mature wide adopted frameworks and libraries
The process of going from TS to JS is lossy; you cannot get back the type information.
I would absolutely say "I have C++ in production" or "I have C# in production" but not say "I have TypeScript in production". "We build our app with TypeScript" is accurate, but it is transpiled -- not compiled -- into JavaScript. Your Node.js server then interprets that JavaScript and executes C++.
That is not right, When you compile to binaries, you do type erasure in CPP, som of the stuff can not be reconstructed or inferred, especially when using o flags.
JS -> TS is easy, you just re-anotate with `: any` everywhere.
Anyways, you are word juggling now.
Type definitions are definitely compiled with CPP. Type erasure only happens with polymorphism types. You can actually view the types with ghidra.
> Your Node.js server then interprets that JavaScript and executes C++.
Umm...no? V8 specifically compiles it into machine code directly.
There used to be a pseudo-translation layer in the CrankShaftScript days, but that hasn't been true in almost a decade.
> I can decompile the binary and still see the type information.
Also no. The de-compiler can _infer_ the types, much like how V8 tries to infer the type. But the actual type information is gone.
Even in languages like Java where most of the type information is preserved, some things are still lost (e.g. generic methods with dynamicinvoke)
>And to be just a tad pedantic: you have JS in production; your TS is only in dev.
This is not even pedantic, it's wrong. You have JS/TS in both dev and prod, with javascript being the actual runtime code in both, and typescript checking your code at build time in both. If you're running javascript compiled/checked by , and written in, typescript, it's not uncommon or unreasonable to call it typescript.
> Google's JS style guide also focuses on JSDoc for the same reasons
Google uses TS internally. Any JS is strictly legacy code at this point. The link you posted even says this at the top:
> Please note: This guide is no longer being updated. Google recommends migrating to TypeScript, and following the TypeScript guide.
Also, Google's style guides are not really authoritative outside of Google. They are for some people, who choose to adopt them as their own, but you really shouldn't point to them as the end-all-be-all argument-stopper. Google has a lot of its own idiosyncrasies. Their C# style guide puts braces on the same line, for example, because Google primarily uses Java internally.
> To be clear, they are not "using" TypeScript, it's more accurate to say they are providing TypeScript bindings.
Interesting that you say it's more about providing "bindings", and not really "using". Much of the types in the svelte codebase are never exported outside of svelte, and they are only consumed internally.
The problem they were having was with transpilation, since the browser doesn't run JS.
From Rich Harris (months after svelte switched to JSDoc) [1]:
> removing types from your own code is clownish, epically misguided behaviour, but whatever — to each their own
I would suggest going through the issues and PRs in the codebase to see how invested the Svelte team is in typescript.
> TypeScript is not "real" static typing in the same sense as Go, Rust, C#.
That is true for Go, Rust, C#. But the same thing is also true for languages like C, and Generics in Java. I'm sure both of those languages have weak type systems, but are definitely statically typed.
I think the fact that type information is lost after being compiled isn't really a classifier for typed/non-typed. Ultimately it all comes down to machine code, and that certainly isn't typed either.
[1]: https://x.com/Rich_Harris/status/1699490194565578882
You can write a function in go or rust, then write code in assembly to call it with any old nonsense. It is no different. The whole point of static typing is that it happens at compile time, not runtime.
Does Go’s type system perform runtime type validations? My impression was that it does not. But Go probably supports reflection on the type information at runtime which could be used to implement a runtime type validator, right?
> TypeScript is not "real" static typing in the same sense as Go, Rust, C#; the type information disappears the moment you build it.
The type information in both Rust and Go disappears the moment you build it. The generated assembly is completely untyped: if you pass invalid objects to a compiled Rust function that you've dynamically loaded, you will cause problems, even memory safety issues, because Rust does not do any type checks at runtime.
In the same way, if you call Typescript-defined functions from Javascript with the wrong types, you'll get problems. But if you write everything in Javascript, and don't ever use type assertions, you won't have issues. (In practice, I believe there are a couple of other issues you can run into, typically involving variance and mutability, but these are very rare. Also, some older APIs return `any` that should return `unknown`, but that can be fixed.)
It's also worth keeping in mind that all languages have and require schema validation, it just might look different. Both Rust and Go have schema validation libraries - typically they parse the data directly into the correct format, but in Rust you could do something like `let x: HashMap<String, JsonValue> = string.parse()` and get roughly the same effect as Javascript's JSON.parse, it's just that JS/TS has a built-in data structure to represent arbitrary JSON data, whereas Rust does not.
> To be clear, they are not "using" TypeScript, it's more accurate to say they are providing TypeScript bindings.
To be clearer: they are absolutely using Typescript. The functions (and other parts of the code) are annotated using Typescript's extension of JSDoc types, which means Typescript can parse and typecheck this code as if it were "normal" Typescript, including generating type definition files. The .d.ts files in the source code are used to define additional types and interfaces that can be used in the .js files (you can see the first file you linked to import type definitions from ESTree, for example). The type checking step can be seen in the package.json file[0]. This is all explained in the comment from Rich Harris that you linked before.
Using JSDoc rather than conventional Typescript syntax makes writing your source code more complicated, but in this case the Svelte team figured it would benefit them more in the long run to still be writing code that could be interpreted by a normal Javascript runtime. However, it really is just a different syntax for Typescript, and that's how they are using it.
[0]: https://github.com/sveltejs/svelte/blob/80557bbc1c8a94c43a95...
It’s not real static typing. A compiled typescript project is just javascript, which will still gladly accept incorrect types. The types only matter during compilation.
This is the real-est static typing that exists. "Static" refers to build time. By definition static types are checked at build time, not run time. If you want types to be checked at run time, that's called "dynamic" typing.
Sure, you're technically correct. But TS is compiled in to JS, which is dynamically typed at runtime. You're still ultimately in a dynamically typed language.
In addition, in a typical statically typed, compiled language, your only place where you interact with data that isn't guaranteed to be type-conformant is at a foreign function interface, whereas in Typescript all your interaction with third-party libraries is via regular JS and may or may not be type conformant.
Is there such a thing as a statically typed language? CPU opcodes don't type-check their parameters.
And Go/C/Rust compiles to ASM, a dynamically typed language at runtime.
Rust compiles into WASM, x86, etc, which are dynamically typed for all intents and purposes. They certainly don't understand or enforce Rust's type system invariants any more than JavaScript enforces TypeScript invariants. If you call a Rust function from WASM and pass it malformed data, the WASM runtime will happily execute it.
(pretty sure WASM actually has some integer types, so I guess maybe it is technically "statically typed" but not in any interesting sense--we could similarly say that JavaScript is "statically typed" because every variable has a static "any" type).
> The types only matter during compilation.
That's pretty much the definition of static typing.
You're confusing "real static typing" with runtime type information. TypeScript has "real static typing" (if you disagree, ponder for a moment the meaning of "static"). A TypeScript program cannot natively query the _TypeScript type_ (not to be confused with the corresponding JavaScript type) of one of its variables in the way, for example, Go can. But neither can C, or C++, or Rust, all of which are unquestioningly statically typed.
Svelte is a bad example. They have roughly identical type checking before and after that switch. The switch is mostly just an aesthetic preference for one syntax over another and an ideological stance about being able to run code directly in a browser without a build step.
It's not an "aesthetic preference"; it's a functional preference for debugging and iteration speed as cited by the team.
Fair enough. Perhaps what I mean is that they don’t have a strong aesthetic opposition to JSDoc, which is presumably rare among TypeScript developers.
This is why I prefer to stick with JS and JSDoc.
I have been doing pro webdev since 1995 and since I got my initial experience without all of the contemporary tooling, my process has evolved to require very rapid iteration: the delay of a compile step can often break my concentration and prevent a flow state.
https://news.ycombinator.com/item?id=43548647
Which is quite hypocritical coming from a compiling framework and thus such a ridiculous stance.
We hate build steps in our build step.
Svelte uses JSDoc and has TS validate that. Nue uses nothing. This analogy makes no sense.
Svelte still exposes types though, right? Like as a svelte user, you wouldn’t know it was written in JS?
I don’t use svelte, that’s just my understanding from when the TS -> JS switch was announced
> Svelte team also switched to JS with JSDoc a few months back
1. They still use types via JS Doc
2. They only switched to that for their internal development
3. User-facing code has all the type support and TS support you'd expect
> Rich Harris (Svelte team) even had a comment on this on HN[3].
And here's literally what he said:
--- start quote ---
Firstly: we are not abandoning type safety or anything daft like that — we're just moving type declarations from .ts files to .js files with JSDoc annotations. As a user of Svelte, this won't affect your ability to use TypeScript with Svelte at all — functions exported from Svelte will still have all the same benefits of TypeScript that you're used to (typechecking, intellisense, inline documentation etc). Our commitment to TypeScript is stronger than ever
--- end quote ---
Compare that to Nue's author's take
JS with JSDoc is basically just awkward Typescript.
You're speaking as though it is a fact, but I think it depends on your coding style and temperament for iteration delays.
Author coming out here: Types matter, and Nue’s take is to use them where they truly shine. Adding them to naturally untyped spots like HTML or CSS? That’s just extra weight we can skip.
I prefer types over tests everywhere. If I’m passing props to a component and I get a TypeScript error, that’s a test I didn’t need to write or run. I love finding errors like this at compile time instead of at runtime. Just because HTML and CSS are untyped by default doesn’t say anything about whether types are useful for them. Does Nue have any way to protect against those kinds of errors or does some other architectural decision obviate the need for this kind of protection?
I’m not hating on Nue. At first glance, there’s a lot to like here, but I have to disagree on this point.
Neither HTML, nor CSS are naturally untyped.
Actually, React is not typed enough.
Looking at the mozilla docs: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/sp...
You can see that eg. <span /> is not allowed to hold all types of elelemts.
How awsome weould it be, if th type system actually captures this.
I guess many web developers would climb on a roof and throw stones, because then they really needed to learn HTML and using its elements semantically. And probably many of their web components would no longer type check either, forcing them to reimplement or use simpler elements.
There was a time where front-end devs would have sat down and cried had they had to make closing tags.
Ever heard of XHTML?
There's a reason it's dead.
This is a great idea!
Your views are not "naturally untyped spots like HTML or CSS". They are custom templates with custom syntax and logic. And they would definitely benefit from types.
Some people like things that you might not like.
Personally, I consider it a strike against a frontend framework if I can't type check my templates. They're entirely data-driven — exactly the kind of place where type checking is the least effort but still a a big help.
In any nontrivial project, templates become a large fraction of my LOC, and it's already challenging to confirm they work right and don't break. Type checking that I'm passing in the data they expect, and that they're reading valid properties, is a cheap way to get a big win.
Web standards are great, but I'm not sure what "heavy lifting" they do that would make me feel like type checking was unnecessary.
I agree. It's far too easy to make a change to your model that removes/renames some property, but not update one template that you forgot uses it too. Without screendiff testing, that sort of bug will easily make it into prod.
This is one of the reasons I like C#'s .cshtml (Razor) syntax. The entire file is compiled to C#, so when you do `<div>@Model.Foo</div>` the build will fail if Foo doesn't exist. String-based (rather than compiled) view templating is, IMO, a mistake.
I am not on the React bandwagon, currently using HTMX
But I would very much prefer to see TypeScript in a framework. Optional TS is ok but "untyped by design" feels like an anti-pattern, even HTMX has TS types available.
> React’s ecosystem has devs slapping TypeScript on everything—even CSS—which is overkill
"We don't use Typescript because there are people that exist who use it for CSS when using React" is one hell of an argument that makes absolutely zero sense.
Making zero sense of your own take of the argument makes absolutely zero sense
what?
>"We don't use Typescript because there are people that exist who use it for CSS when using React"
This not at all what was being conveyed, you made that up in your head. The OP didn't say they were not using Typescript because someone else used it for CSS, but that's what you seem to have written.
> React’s ecosystem has devs slapping TypeScript on everything—even CSS—which is overkill
It's actually EXACTLY what they're saying. They're using it as an example of why they don't use Typescript (ie people use React take it too far by using it for React). What does React that have anything to do with not using Typescript?
I mean it's quite literally "we don't use typescript because some developers over-use it" which is essentially the same thing
I probably have nearly the exact opposite opinion of where static typing is the most beneficial. I think it’s precisely at the UI rendering layer, because that tends to be where you’re dealing with the data types with the largest number of properties, deep nesting, etc.
I pretty much enjoy using MaterialUI with React (MUI) and have statically typed CSS: `<Stack sx={{ alignItems: "center"}}></Stack>` - I get full IntelliSense/autocompletion for the sx props (i.e. alignItems when typing 'al') and their value (i.e. 'center' when typing 'c') etc. Sx-props are composable, so you can centralize common used sx/css etc.
Any typos or invalid props/value will result in a compiler error.
I agree with most other commenters: Type safety is a great feature to have. And to intentionally dismiss it or only grant it to certain aspects of the application (where does business logic start and end anyway?) is a really bad sign for me.
how can "not typed" be "by design" and presented to us as a feature. Your project looked interesting but your presentation here makes me have big doubts
I worked with react before typescript, react with flow, angular 1 (large projects), and these days I mostly use react with typescript.
I don’t use it for css, but for the view components and code I find typescript actually makes me both faster and my code is more reliable. To me this is one of the killer features of react that other libraries are in various stages of catching up to: full static type checking end to end. (Also through the API to the backend with a little more work).
That's one way to find a niche audience.
Typed JSX is one of the handful of key innovations that made React successful, IMO. I think you need to really understand what you're replacing before you can replace it.
> slapping TypeScript on everything—even CSS—which is overkill
Nope. Hard disagree. I want the developer experience of autocompletion of CSS variables, and I want build errors when someone makes a mistake.
Type everything.
Frankly that's a good reason to never give Nue serious consideration. It's all fine when you're building small apps one view at a time. When you have an application with hundreds of views and you need to refactor, that's when you need the types, otherwise you'll never see the tail end of oh we missed that this needed to be renamed there too.
I honestly can't see what's wrong with using TypeScript anywhere in place of JavaScript. Unless you're making a simple script or a throwaway prototype, then you're pretty much always better off with it. It's invaluable during development and it's compiled away at build time.
I respect those who use and enjoy TS, but I have less respect for the argument that it should be used in place of JS everywhere.
You’re replacing runtime trust with compile-time trust, but at the cost of flexibility and speed. That’s not always worth it.
TypeScript solves problems I stopped having 20 years ago.
Uh oh, you've summoned the typesetters
Nothing in your view is "web standards". And nothing in web standards can do the heavy lifting of showing things like "`nam` is not defined on object `user`"
You really don't understand what types give you, do you?
Where are you going to put the code above in this:
</section>Are you going to write ifs for every permutation of possible typos? (Let's ignore for a second that it's not just typos)
At that point, why not just use vanilla JS and no framework? Literally zero build time and zero bytes of framework code. And it's fast as hell.
Jesus, this is a regression not a feature, for christ sake. Typed CSS via emotion/styled-components is an amazing feature to call it overkill. This alone is enough to dismiss nue.
Last time, I promise: please, PLEASE don't use ChatGPT (or others) on us. It's _extremely_ obvious, and it takes away 90% of your credibility. I'd much rather read a bit of broken English than read this kind of slop. It's a huge reason why I can't take this seriously.
ALL your docs are chatgpt. All of them. All your issues. Your comments here. Are you even real? Yes? Then TALK to us.
/rant.
Please. It's me typing: Tero "tipiirai". I’m Finnish, not a bot. Documentation? Mostly me, some help from contributors. Comments here? Check my HN history. This stuff is impossible to prove.
Of course it's impossible to prove, which is why so many people are doing it, like you/your team, at least recently. At some point in the past your blog seems to have gone from "real" to "slop".
I've seen enough LLM sh*t to know.
I know you'll never admit this. I don't care about that. But please understand that your credibility goes out of the window with this; it doesn't make it look more professional, especially to developers.
If I'm extremely wrong here, I genuinely apologize, but I would be very, very surprised.
There’s a lot of negativity around this so I just thought I’d chip in and mention my appreciation for it. Projects are allowed to not be typescript, and I actively stay away from it as much as possible when working with browsers.
I don’t work in TypeScript, I don’t write in typescript, and I (along with everyone) don’t deploy typescript. I have multiple different build processes in my project to remove different types from different dependencies that are incompatible with one another just to untype them.
So personally I find standard js a huge selling point :)
> I guess this is targeting the vuejs crowd
Vue is written in TS and has first-class support for it, even at the template layer.
Vue with SFCs is not actually typescript because typescript can not parse the SFC syntax, you need a forked typescript called `vue-tsc` for that.
Shows what a hack vue really is.
Only since Vue 3 though, and the types are still not as good as React.
Vue 3 has 6 years at this point.
Also, could you expand on the fact that types are "still not as good" as React?
Can you make an example?
Sadly not because it's been about 6 years since I looked at it! (We ended up switching to React.)
IIRC it's pretty close, but you'll still end up writing things like `{ type: String, required: false }` where in React you'd just write `string | undefined`.
I'm sure I would find many more issues if I was using it in anger, because it's building on a foundation that didn't have Typescript in mind. E.g. see this thread:
https://www.reddit.com/r/vuejs/comments/l456fl/is_vue_3_real...
> IIRC it's pretty close, but you'll still end up writing things like `{ type: String, required: false }` where in React you'd just write `string | undefined`.
In Vue you also write `string | undefined` since Vue 3.
Also note that the thread you linked is 4 years old.
> In Vue you also write `string | undefined` since Vue 3.
I took that example from the current official Vue 3 docs: https://vuejs.org/guide/typescript/overview#general-usage-no...
> Also note that the thread you linked is 4 years old.
So 2 years into Vue 3. Has anything changed?
I mean it's not bad enough to be a dealbreaker any more like it was with Vue 2. The real dealbreaker is still the reactivity system which leads to spaghetti very quickly.
> I took that example from the current official Vue 3 docs:
Yes, that API also exists as compatibility with the Options API, but this is what you should use:
https://vuejs.org/guide/typescript/composition-api.html#typi...
> So 2 years into Vue 3. Has anything changed?
Yes, e.g. templates are type-checked now. If you have specific things that aren't supposed to work, please list them.
> The real dealbreaker is still the reactivity system which leads to spaghetti very quickly.
I've had much better experiences with Vue than with React in this regard.
> most react people now use TypeScript because first class types in your view layer are super useful
Most people use TypeScript because React apps have grown to 200k lines of mostly entangled code with business logic and are unmanageable without it.
If one goes in a different direction there's less need for it.
I mean a rapidly changing front end codebase is always going to be entangled mess no matter if it’s react, plain JavaScript or even “native app code”. Front ends are where the rubber meets the road and have to deal with fuzzy weird human shit and miles of edge cases. That is just the nature of the beast.
Even if you attempt to tame it and make “the prefect codebase” it’s still gonna be a mess.
If anything React and typescript help it from being an even larger mess full of homegrown idioms that are normally baked into the framework.
There is no such thing as not using a framework. You either pick an existing one or build your own. Very often the sensible choice is to pick an existing one.
You could always massively reduce the frontend by not duplicating half the backend business logic in the browser. By not having isolated backend/frontend teams off in their own worlds and only using fancy JS where fancy JS is actually needed.
Server rendering of JS only gets you partially in a better state when the fundamental idea is based around generating a massive amount of JS for the browser.
Most of the Vue devs I know, also use TypeScript for the same reasons.
> I guess this is targeting the vuejs crowd
Typescript support and usage with Vue is very large. Vue itself is written in TS and most large libs are also written in TS. According to /r/vuejs and my personal experience also most new apps.
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:
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.
Svelte is definitely much less verbose and requires less code. Performance is also way better but it might not matter for many use cases.
The drawback is that since Svelte is really a language[1] you now need a compiler and custom dev tools to make it all work. This requires some serious effort to maintain and evolve.
I love Svelte and have been using it almost daily for years... but the team really needs more resources to accomplish their vision and maintain it for the foreseeable future. It's amazing that huge companies like Apple are adopting Svelte (eg: Apple Music) and not investing in it.
[1] https://gist.github.com/Rich-Harris/0f910048478c2a6505d1c321...
TanStack Query (formerly known as React Query) is absolutely compatible with Svelte. https://tanstack.com/query/latest
I work with react for a decade now, and with Svelte for past 3 years. Svelte is obviously a newer generation of framework, and works for me a lot better than React. But I agree there are some rough edges, mostly around the ecosystem
No, the support is quit limited not as many features are supported.
I transitioned to svelte and I’m finding it around 3x to 2x times less complex than React
I learned React back in the class component days. I recently picked it back up and found functional components and hooks to be absolutely baffling. Does anyone know why they went down this route?
Trust me, the function based components are way too simpler. Just a function that returns HTML. That's it. compose your UI as those functions. These functions can take arguments to customise their output (rendered HTML) as arguments (called props) or can call special functions from React (called hooks) such as asking the React to "remember" a value for you (state) or cache something for you (useMemo) so as to not compute it every time or trigger rendering if value of certain variables change (useEffect) or at the component start (useEffect with no dependencies mentioned) and that's all the React that you need to know for I would say your 95% of the needs.
React compiler (already used for Facebook and Instragram code base) further renders the use of certain hooks unncessary thus making React a lot more simpler.
Hooks require less boilerplate to set up and reuse stateful logic across components
If you havent watched it yet, the talk that introduced hooks explains much better than I can: https://youtu.be/dpw9EHDh2bM
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:
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.
The author uses something like `list.push(...objects)` in his demo code, and I believe this is the culprit. Passing many (~100,000) arguments to a method at once using the spread operator is known to cause a stack overflow, because, in JavaScript, each argument is placed on the call stack.
Spreading arrays and objects is such a common performance hit. It works fine for small instances but falls over in large instances.
Here's the JS CRM engine https://github.com/nuejs/nue/blob/master/packages/examples/s...
I see a number of issues, but don't have time to look into them.
1. Spreading when you probably don't need a copy: sortEntries. Sorting is probably where the overflow happens. Just sort in place or use Array.from or slice.
2. Excessive use of array functions. In my experience, a C style for loop performs better when you need performance. Create an empty array before, perform your business logic inside the block, and push to the array.
3. I don't know how filter is called, but it potentially loops through all of the events three times in the worst case.
4. paginate manually creates a JSON string from the returned entries. I don't know why, it seems inefficient.
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!
Nue is a very cool project but if you want people to take the project seriously you should probably tone down your confrontational marketing :)
Also, I checked the demo and there's like 100kB of WASM code you're not taking into consideration in that React button comparison?
Anyway, congrats on the project. I'm really curious to see how the whole vision will turn out.
100% agree, I felt very put off by the tone, I think HTMX pull it off by not taking itself too seriously and also having good insights.
I wish the homepage talked more about how nue approach the problems rather than how better than other framework it is.
I think you're right on the marketing. I'll tone down.
The comparison uses the non-wasm version at mpa.nuejs.org
If you want an alternative view, I like the confrontational tone. You know what you excel at and attack your competitors with it.
I really dislike how all the other JS UI libraries are basically the same and espouse the same ideas.
Svelte was way better when Rich Harris was straight up attacking react devs at conferences and shaming them for poor performance.
Being "nice" just ensures entrenched players stay entrenched.
I wrote "tone down" not "completely remove" ;)
Rich and HTMX have a much different tone while shaming React.
If you're actually doing something better and your results actually stack up under scrutiny I don't see the problem.
I think most people get uncomfortable because it's often untrue in marketing. So if it's true (to the best of your knowledge and after outside probing) then by all means.
At this point I don't even understand why everything has to be a SPA. It's complicated and inefficient and should probably be only used with highly interactive applications like some kind of Photoshop or Ableton live for the web, which means very few apps should use this paradigm. Granted, I'm not much of a frontend dev... but what I know is that if "instant search and other operations over 150,000 records" is a problem then it's probably best to re-think the paradigm.
With SPA, all your backend has to do is spit out data and sometimes validate it, leaving your front-end completely in charge of presentation and user interaction. You can even have completely separate teams working on it. It feels a lot less complicated than the alternative.
Yes Conway's Law:
https://en.wikipedia.org/wiki/Conway%27s_law
The law is based on the reasoning that in order for a product to function, the authors and designers of its component parts must communicate with each other in order to ensure compatibility between the components. Therefore, the technical structure of a system will reflect the social boundaries of the organizations that produced it, across which communication is more difficult. In colloquial terms, it means complex products end up "shaped like" the organizational structure they are designed in or designed for. The law is applied primarily in the field of software architecture, though Conway directed it more broadly and its assumptions and conclusions apply to most technical fields.
That "backend" vs. "frontend" split is entirely artificial. That code you would run server-side to convert your data into a fully-rendered page is still very much part of your "frontend" organizationally, even though it might be hosted on the server.
(Strictly speaking you can have a web service that's purely about spitting out raw data in a form that other organizations can use, but that's the kind of thing that Semantic Web and Linked Data standards are intended to address. Not something that your garden-variety website has to be concerned with.)
OTOH you now need an API and glue code in the frontend. I'm not saying it's not worth it but it's definitely more work.
That's a debate spanning multiple decades. Your last sentence is not true all the time.
SPAs are great for the hordes of B2B SaaS apps out there, which for the most part are just some fancy variants of a table. They're not a Photoshop, but they're still highly interactive.
I think the exact opposite is true, B2B SaaS apps don't need to be an SPA to deal with fancy variants of a table. You can create highly interactive UI with things like Rails and Hotwire, sprinkles of JS or even HTMX. SPA's are bloat and often driven by designers who focus on flashiness rather than good UX.
Even if you use Rails or HTMX to get it done, you're still building an SPA.
Couldn’t be more wrong
If you look at the documentation at nuejs.org/docs, you'll see how Nue is really more about apps that focus on content rather than single-page apps (SPAs). However, this release is all about SPAs.
Yes, sorry for venting on your thread. I do appreciate the idea of leveraging web standards though.
I recently thought about just using ASP.NET MVC with Razor pages for a quite simple app at work. But I'm already familiar with SPAs, so with that background I chose to "just use Vue as always (or Solid or Svelte, I like all three of them)" as SPAs have some advantages, e.g. separation of concerns, easier integration of libs like agGrid or eCharts.
Without that knowledge, I agree that good old SSR (MPA) is easier and more maintainable. And more robust.
Both way can work fine, enough great examples out there. The real problem is, imho, we shouldn't need a (graphical) UI at all. That's where all this discussion comes from. When the whole "frontend" disappears in a year or 10, it will make a lot more sense.
IMO, most SPAs are bloated. MPAs are cleaner and more forgiving.
The only reason to still stick to an SPA instead of an MPA is that the app is so bloated you want the user to only have to load it once.
And people say "lazy loading!" but by the time you've implemented lazy loading in a SPA, you could have just used an MPA to keep things modular and memory efficient.
SPAs became popular at a time when companies thought everyone was going to move to progressive web apps. Then the bloated frameworks came along, PWA interest has faded, and here we are.
The above are all my opinions, apologize in advance if they come off as speaking objectively.
This happened to a team I know. They built a flashy SPA dashboard because it was easy to copy-paste from templates. It worked great—until a real-world requirement, like a data grid, came along.
There's a crossover with crossplatform apps (like React Native), which is a force multiplier for some applications / orgs / etc.
Not the discussion, but SPAs are fundamentally safer against XSS, in the sense that data and code have different paths.
I don't think the "a button in X is 40% heavier than an SPA" is a fair comparison; including a framework will add weight, but these frameworks are not intended for single components. Compare apples to apples, then we can make a fair comparison.
That said, how does Nue compare to htmx and other frameworks leveraging the modern web standards?
There is no such things as a true apples to apples comparison for libraries such as this. They all cherry pick something and ignore a ton of things such as:
React is really well-thought out and well made by hundreds of professional contributors that have worked on it for years. The premise that hobbyists can make a better overall solution in less than 8 months is strange. At best they can make a smaller solution, but it will have to sacrifice in other areas.React and the react ecosystem fail at many of the criteria you’ve listed. You might argue “that’s not reacts fault” but when I look at a website that takes 15+ seconds to load its content on a gigabit connection , I’m never surprised when it’s react. Lots of sites have massive issues with rendering performance, scalability and maintainability even with react.
What react does do is give you a clean separation of concerns across team boundaries and allow for reusable components . But the cost you pay for that is a boat load of overhead, complexity, maintainability concerns, and react specific edge cases
A 15+ second load on a gigabit connection is impossible to have anything to do with the React library, as React is only kilobytes big and has no impact on the host.
It’s not just about the size of the payload, it’s about the stuff happening in the background and the constant diffing of the various DOMs that react has. I can tell I’m on a react site by how laggy it is. Some devs manage to do better but I can still tell.
Another wonderful feature of react is it will fully render the page on my iPad and then quickly replace it with an error message. Absolute brilliance.
So what stack are you using with React?
You didn't ask me, but I have what seems like an esoteric use for React: I only use React for the components, because vanilla/native web components are a major pain in the ass to work with.
You don’t need to wrestle with React’s state management monster unless you’re into that sort of thing.
Depends on the project. For websites I like to use a statically generated Nextjs site served by nginx[1] and for SPAs Nginx that serves a Vite-built static bundle with a backend that’s in whatever language the backend team chose.
[1] https://martijnhols.nl/blog/how-much-traffic-can-a-pre-rende...
> You might argue “that’s not reacts fault” but when I look at a website that takes 15+ seconds to load its content on a gigabit connection , I’m never surprised when it’s react.
> A 15+ second load on a gigabit connection is impossible to have anything to do with the React library, as React is only kilobytes big and has no impact on the host.
Perfectly proving my point.
It's not react-the-framework's fault, yet those sites are always react sites.
This is the "everyone who drinks water dies, therefore drinking water is deadly" argument. I'd also guess lesser known frameworks have a higher proportion of better developers - i.e people taking the time to research and try new technologies probably are more competent. You're also forgetting about the trillions of wordpress (and similar) websites that exist.
It’s really not.
It’s much more of a “everyone who chooses this flavor of soda dies”. Maybe it’s the soda, maybe it’s the people it attracts.
> I'd also guess lesser known frameworks have a higher proportion of better developers - i.e people taking the time to research and try new technologies probably are more competent.
And this is the “you’re holding it wrong” argument.
Facebook and Airbnb are the poster children for react (one of them wrote react). They are both perfect examples of absolutely disastrously monsters of websites plagued with issues related to all of the problems react supposedly solved.
I think companies should make web developers use a decade-old bargain-basement laptop at least once a month.
Each team member could take their turn using it so that it's already tooled up for the project they are working on.
Is there a full-blown SPA demo made with htmx?
How is Vite relevant to the discussion? It's like saying the UI based on Visual Studio is lighter.
Because Vite emphasizes "Optimized build" in their marketing
Slower builds might make developers more thoughtful of the bloat, but I still think it’s tangential.
That said, how does Nue compare to, say, Svelte?
I'm not sure if I got this correctly, but it seems like you're misunderstanding what Vite actually is or does.
For having built what is essentially a bundler, I would've guessed you were more familiar with what it does, or, perhaps even have used it to build your tool.
Vite can bundle framework-less html files. It can create an SPA without any JS faff. You just have to point it to the right direction. When you instantiate a Vite app, you have to make the conscious decision to use React under the hood.
As for Nue, I think it's a cool idea, but I don't see what it does that I couldn't do with Astro, which has way larger community support and can work with pretty much all JS frameworks OOB.
BTW, I think it's really disingenuous to compare a React SPA bundle with an SSG output. You have essentially no functionality for handling state mutations beside events. You could achieve a much better middle ground by using a compiled framework like Svelte or Solid.
I resonate with what you're saying so I'm mostly just curious how long you've been developing front end code. I think those who have had had to run the gauntlet of naked JS in the 90s developed the discipline to intuitively code untyped.
I've been enjoying JS since it was first added to Netscape and I also loathe the creeping bloat that is endemic to web development these days.
In the event that I want an "intellisense" dropdown capability in a project, I'm a big fan of JSDoc. I think the bootcamp kiddies these days just don't have enough experience to get by without the intellisense crutch.
Incredible marketing blurb! Not a single bit of detail about how this works
What do you mean by "lighter than a React button"? Do you mean lighter than the entire React runtime, plus a React button?
If so, that's somewhat disingenuous because even though a page with a single button would require the entire runtime, a second React button would be significantly cheaper than that.
Yes. React runtime included. Benchmark and details here: https://nuejs.org/docs/react-button-vs-nue.html
As the previous commenter said - you don't need a new runtime instance per button, so the comparison doesn't really work (for the smallest binary size, you could provide a native application doing the bare minimum to display the UI too, if the platform has an OS-provided UI framework).
It's still a neat toolkit, since not every website needs a big framework - but comparing runtime sizes is like choosing C over C++ because a `int main() { printf("Hello World\n"); }` binary is smaller.
I think it's relevant in the sense that it shows if you're building a simple app, there's a lot of overhead.
It doesn't claim that you're going to get that overhead for every time you instance a button. I don't see how anyone would think that.
I think the comparison works fairly well. It should be clear to everyone that it compares apples and oranges, since it's two different kind of apps it's comparing. So it makes you think. If they just compared the size of the framework itself, or a single button vs a single button, you may think "oh but as soon as you add any kind of complicated code, there will probably be so much boilerplate with Nue that it'll end up being bigger"..
This comparison is disingenuous and off-putting. When I read "a React button" I assume you are talking about `<button>` and the React runtime, not some third party libraries.
flawed example for a framework. Tell me...are 2 buttons going to be 80% heavier? why use react if all you build is a button? you need a tractor to pick your groceries from store?
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.
So, nothing is worthy of discussion or can claim any benefits over the incumbents until it has become an incumbent itself? How is it supposed to attract the necessary users to get bloated if they can’t talk about it in relation to the established players?
All I am saying is that being lightweight, when you have been around for less time than a mature solution, is a mute point.
It's a cop out way to differentiate because you are clearly not comparing apples to apples.
You have a fraction of the features and a fraction of the bug fixes. You are trying to make it sound like you are a 1:1 replacement, when you are not.
FYI, you probably meant to say “a moot point.”
https://www.grammarly.com/blog/vocabulary/moot-point/
Touché
I don’t think React has ever been considered lightweight, judging from the mostly negative reactions from this website when it first came out.
JS frameworks have often valued DX first over what it outputs. Frontend devs also frequently care more about a) their own tooling and b) how it looks, to a much higher priority than the performance and stability of their output. At least from my own experience in the community :)
Oh my god, yes this is hitting the nail on the head in a way I hadn't thought before. The bloat comes from the discipline (or lack of) more than the framework.
IMO, those who have only worked in React tend to be unfamiliar with the layers of native capability that React is built upon, and so they are stuck in the React bubble unless they want to learn a ton of (admittedly crufty, but useful) web fundamentals.
Solid.js is doing amazing w/re to its bundle size. Its been in development for something between 6-9 years depending on how you count and it is still very very slim.
I feel the same. I started using svelte to build widgets with few requirements that were deployed as web components, it was great for that.
Looking at the project:
To convince me that Nue is a framework worse using, please show that Nue:> 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
Weren't the main points on the main page that it was small ("lighter than a React button"), and could handle large amounts of records ("far past where JavaScript (and React) would crash with a stack overflow error")?
Those points are only true if you're comparing to a React app that uses bloated frameworks and inefficient list manipulation (as other commenters pointed out, `list.push(...items)` causes problems)
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’m the author. To clarify: a button installed via ShadCN/Vite’s official docs (https://ui.shadcn.com/docs/installation/vite) ends up way heavier than a full Nue SPA. It’s not a jab at React devs—just showing how web standards can flip the script on bloat. Any thoughts on framing this comparison better?
Can you give some examples of some of these standards that make Nue stand out and other frameworks don't use? It seems that if other frameworks make use of these standards we would get a similar performance boost across the ecosystem.
Seems like it should be Meta with billon dollars that should be doing that. The whole point is framework like React are made for DX and dev flow at company of that size.
Mention that you know you are missing dozens of features instead of blaming it on “web standards” would definitely help frame it better. Do you think Vite doesn’t know about web standards? It reads pretty naively.
Also I recommend just not making a web framework. There are many of them, some very similar to Nue. Your effort could be placed on improving what is out there. I suspect that is a lot harder and less fun than just making something new. But if you manage to contribute then you’ll be helping an entire community of people whereas a new web framework will likely see almost no adoption before it is abandoned.
It's like someone making a hello world in C using the std, then one hand crafting the console print but losing literally everything else. Of course, if my goal was to just write hello world then it would make sense but 99.9% of people in the world will use something else, invalidating the point.
Maybe don't compare apples to oranges at all. No one is using react for a single button.
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…
[0] https://mpa.nuejs.org/app/
Scrolling works now on iOS safari! That was a quick fix. Thanks to the author (and bug reporter!)
Now do macOS Safari......
The author is using a trick they've used in almost every past submission: They implement much less than the component they compare themselves to, and then show how much smaller their own solution is.
How is the SPA less than the button?
It’s not the button that’s big but the stack [0]
> Built with Vite, TypeScript, Tailwind, and Shadcn/UI, following the official ShadCN/Vite documentation exactly — no additions or removals.
Would be interesting to run Webpack Bundle Analyser [1] (or similar for vite bundler) to see if the proposed stack in the doc is bloated by some major dependencies.
0 https://nuejs.org/docs/react-button-vs-nue.html
1 https://www.npmjs.com/package/webpack-bundle-analyzer
Edit : seems the question I was responding for was a rhetoric question posted by the author. I guess the « smaller that a button » is a smart catchphrase but I wouldn’t use it for too long as soon a Nue becomes popular. Great work, I wish you much success and hope to use it in day to day work some time soon !
Does your button component implement all the functionality included in the Vite/shadcn bundle? E.g. the different variants, states, loading etc.?
I'm sorry if it does, then I'll take my accusation back, but I've seen this happen in almost all of your Nue submissions. People keep bringing up this criticism, and you never retract your misleading comparisons.
The Nue button demo isn’t claiming to replicate every feature of the Vite/ShadCN bundle—no variants, states, or loading spinners here, just a lean example to show size and simplicity. The point’s not to ‘beat’ ShadCN at its own game but to highlight how web standards can cut bloat dramatically, like a button smaller than a full SPA. I get the criticism—comparisons can feel loaded—but it’s less about misleading and more about spotlighting a different approach. Happy to tweak the framing if it’s coming off wrong.
> The point’s not to ‘beat’ ShadCN at its own game but to highlight how web standards can cut bloat dramatically, like a button smaller than a full SPA.
Then why isn't there any disclaimer or explanation that your Nue button has fewer features than the one you compare it to? You clearly intend for the reader to make this comparison, but you deceive them by not mentioning that your solution isn't equivalent.
> Happy to tweak the framing if it’s coming off wrong.
It would be great if you could do that! Though I'm not holding my breath - you've done this many times before, people have complained many times before, and you keep doing it.
I know I'm just one voice, but your marketing strategy is so deliberately deceitful that I'll honestly never consider Nue as a serious contender for any project, nor other software you write, until you stop doing this.
Let's try this a different way: What would it take for you to retract your misleading comparisons?
You keep acknowledging and then repeating the deceit. You even solicit ways to stop being deceitful only to reject the many suggestions.
> Happy to tweak the framing if it’s coming off wrong.
It's coming off wrong (because it is wrong). So go ahead, your move.
Page height/vertical scrolling is also broken in both Chrome and Firefox on Android. On FF the comment box gets hidden under the menu bar.
Probably the page height gets forced with percentage or vh, which should be usually avoided. If forcing is wanted, svh or dvh should be used.
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.
There are currently two examples:
- `nue create simple-blog` This highlights content-driven websites.
- `nue create simple-mpa` This is today’s SPA demo, where 'MPA' stands for multi-page applications. It shows how client-side routing and view transitions can seamlessly connect content-heavy pages with app-like views.
Source code here:
https://github.com/nuejs/nue/tree/master/packages/examples
Is there any documentation about them?
For example what is this 200kb binary for?
https://github.com/nuejs/nue/blob/master/packages/examples/s...
Here's the source, I believe: https://github.com/nuejs/nue/blob/master/packages/examples/s...
I also spent five minutes clicking around and couldn't find a sample of what the code looks like
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.
And importantly, does the app have clear loading states when it has to block on something? Making sure something happens immediately can make things feel fast even if you're waiting on the network.
> Does the app avoid unnecessary roundtrips to the server?
Guess what, using server-rendered pages avoids all unnecessary roundtrips by definition, because the entire page is loaded in one go. You can augment a server-rendered site with client-side SPA features for seamless interaction within the page, but that's not a key requirement either.
Rendering and loading an entire new page just to open a dialog seems pretty unnecessary to me.
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.
Weird that the current state of things for a simple, noninteractive site is some kind of framework and not just “write the HTML with a little JS where needed,” which works perfectly well and requires no additional baggage.
React itself is not huge
> 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.
"internet creationist" make you sound like God either chose you to be a content creator, or ordained the internet into being...
I know a guy whose middle name is "Almighty God".
I've actually wondered how that looks on a resume :D
Author here. No need to update the resume yet—titles do keep shifting! React’s monolithic style has muddied the waters, making it tough to build clean business logic, prioritize performance, craft CSS design systems, or just focus on user experience. Nue’s here to unblock that—giving each role room to shine with leaner tools, not cramming everyone into the same heavy stack.
If you still use webmaster, perhaps updating is a good idea. Haven't seen that term used in the wild since the early? 2000s
it is time for a comeback
Don't forget to mention "vibe coding" somewhere too
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.
[1]: https://github.com/hackfixme/miu
> 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.
Author here. You’re spot on. I took away the React association and added a direct link to the JS code [1] that hit the ‘Maximum call stack size exceeded’ wall. TypedArrays can do wild stuff, no doubt, but yeah, it’s not exactly vanilla JS—and still lags a tight WASM setup. Appreciating the nuance here!
[1]: https://github.com/nuejs/nue/blob/master/packages/examples/s...
The new wording is much more nuanced, appreciated! Also the fact that you link to the actual code that broke down, making it possible to verify the claim. Less ammunition for the people who actually are skeptical of the project instead of just nitpicky like me ;)
Speaking of the code in question, it looks pretty sensible - there's a bit of low-hanging fruit where one could avoid creating redundant arrays by turning chained calls to map and filter into one for-loop and such, but that's about it.
What confuses me is that there's no point in the code where I see any recursion, here or in the other JS files that seem relevant, so how does one end up with a call stack overflow?
(not questioning that it crashed for you, it's just that I don't see any obvious flaws in the implementation, so I'm curious to lean what the "gotcha" is in case I ever bump into something like it myself)
The stack overflow is caused by an `arr=[...]; events.push(...arr)` in `add_events`. Replacing that with `for(const x of [...]) events.push(x)` gets rid of that issue, and the JS-backed build is then snappier to search & filter than the WASM/Rust version.
Oh duh, yeah using spread syntax for function calls is definitely limited to fewer than 150,000 arguments in any browser that I know of. Don't expect everyone to know that, but I sure did, stupid that I didn't spot that. Thanks for pointing it out!
(funny enough I tend to use for(let i = 0; i < arr.length; i++) loops most of the time anyway because the iterator protocol adds too much overhead for my tastes, so I wasn't likely to ever bump into this in the first place)
I would imagine browsers optimize the iterator protocol away for arrays. At least on https://jsben.ch/iJFZ4 for..of is a smidge faster than an old-school loop.
You accidentally included the array initialization in the benchmarked code ("setup block" vs "boilerplate block"), dwarfing everything else. If we're talking about an already allocated array the difference is pretty big:
https://jsben.ch/FgDA6
… but in a way you're correct that this is rarely the actual bottleneck in the surrounding code. Still, "death by a thousand papercuts" and all that. Plus having old-school for-loops as a habit makes it easier to spot the true botllenecks.
... derp, yes. It was way too early in the morning, and I misread "is part of the benchmark" as "is not part of the benchmark"...
In your defense, the "use it for data initializing" suggestion isn't exactly helpful text either.
Also, for the record: I presume you tested on Chrome, but on Firefox the difference between the two loop styles is quite a bit larger (and generally slower than Chrome, so perhaps also a consideration when optimizing for "slowest browser" as the bottleneck).
What does event sourcing have to do with searching or "instant keypresses"? It's a storage pattern for recording events, not a way to search.
Like, you're searching a single table for text messages, not a stream of events.
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.
Most IRL software failures like poor performance, lack of stability, unmanageable technical debt, etc are going to be systems and human failures 90%+ of the time, not the individual tool or framework choices.
It’s human failure 100%. Big frameworks just lower the baseline such that this failure becomes more acceptable, less immediately aware, and masks candidate selection.
If you want to achieve something smaller or faster you have to measure for it. Odds are if you cannot execute without a big framework telling you how to proceed you will not be able to measure it either way.
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.
Fair point—new tools pop up constantly, often just piling more layers on React’s bloated stack. Nue’s not that. It’s a fresh start, built on web standards and closer to the metal, not another abstraction treadmill. That’s why a button can be lighter than a whole app—less cruft, not more boilerplate. Tomorrow’s Olde might still fight yesterday’s bloat; Nue’s dodging that trap from day one
The animations makes it feel slow, the lack of any throttling/debouncing means that my input feels slow too.
The animations are always a deal breaker. And then WASM.
Are you talking about this 150,000 record Rust version?
https://mpa.nuejs.org/app/?rust
Yes. On that version, Chrome 134.0.6998.89's devtools on my Macbook (M2 Max) are indicating 100 to 250 millisecond interaction times and a 160 ms frame when entering text into the search field.
I get the same numbers. Interestingly, JavaScript performs faster below 100,000 entries due to the lack of a JS-to-WASM bridge, but it eventually crashes when the records keep increasing
Why would you ever have 100,000 entities on a page? What is the business use case for this?
Loading the page on Fast 4G connection takes 9,61 seconds before I see _any_ content on the screen. This is loading the "all contacts" page that shows 12 items with a title, excerpt, time stamp and user name. Is this expected performance? Network shows the app downloading huge 4/1 megabyte chunks.
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.
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.
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?
React is fine. Next.js is evil.
Absolutely brilliant I've been following Nue for a while and every release gets more and more impressive.
Thank you so much for putting in the hard work by making it and I hope others can understand why this is important and use it instead of cargo culting React and making the web worse every single year.
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...
They are from the same example. Here's the source code:
https://github.com/nuejs/nue/tree/master/packages/examples/s...
Look for "view" and "model" folders
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.
"mostly" for sure; it's a good mental model and allows me to build modular applications etc, but I hate that a nontrivial amount of code and headspace is spent on things like re-renders, memoization, useCallback, dependency arrays, etc. I hope the React compiler will finally solve this, because the competition (apparently?) has (I haven't had the time to look into e.g. vue yet).
Absolutely, it would be nice if we found the right abstraction to get rid of that part as well. Basically every non-React framework's answer to that is Signals (aka change tracking), where React is doubling down on unidirectional data flow and thus dependency arrays. React Compiler indeed solves the 99% of performance related memo-s.
For effects you still will have to understand the mental model (which I'd argue is inherent in the domain and not incidental to the tech).
From reading Nue's docs on Interactivity, it seems to opt-out of the discussion by going back to good old manual UI refreshs. I personally would not choose that, too many pre-React debugging nights spent on chasing state<->UI desynchronization bugs.
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.
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...
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.
1. It's an SSG and competes with projects like Astro or Solid or Next. Comparing to React is apples to oranges.
2. Benchmarks are just numbers without details. React+ReacDOM gzipped/minified is 40 kb in 2025. I doubt a button adds 30 kb. But if you really want to make small SPAs, Preact is just 4 kb and it doesn't require to learn a new bespoke templating DHTML-style thing.
3. From FAQ
> The WebAssembly example in our demo isn't about raw performance — it demonstrates something far more important: what becomes possible when your business logic is properly separated from presentation.
> But when your business logic lives in its own pure layer, entirely new possibilities emerge. Rust is just one example — you could model complex financial calculations, build sophisticated data visualization engines, or create real-time collaboration systems. Your logic can evolve independently of the interface, enabling the kind of architectural advances that the React monolith prevents.
The writer was high or delusional or bad at explaining the point. Nothing prevents you from putting logic into "its own pure layer" in any language. You can make it messy and impure with Rust/WASM/... just as you can keep it pure with pure JS. And it's not "entirely new" because people separated business logic for literally decades (and believe it or not many of them even did it while using React at the same time)
And meanwhile the Rust version is slower and bigger. "What becomes possible" is a mystery.
"React monolith" just takes the cake. React literally doesn't care how you separate your business logic, it's just a rendering layer. This ironically is a monolith SSG that does routing, YAML frontmatter, Markdown extensions, syntax highlighting and what not. Again, you are thinking about something like MarkoJS or QwikJS. Before you are trying to take something down you should probably understand the basics.
Don't get me wrong, it's a cool project. But it could be more humble because authors don't seem to fully understand themselves what exactly they are proposing.
Nue still continues to advertise with clickbait?
The animation makes it look so incredibly slow…
Yeah, they should remove all animations so it feels instant and really snappy instead.
Disable the "appears" class in chrome inspector, and it's all instant. (faster than the macos mail.app)
Which animation exactly?
All of them? It should feel instant. A UI does not benefit from artificial delays.
Gotcha. This is something Nue will tackle later trough design systems, where motion design is an option to choose, ditch, or tweak.
The videos. The very first video. Animations like this are done to hide the fact it’s slow by hiding it behind a fancy animation. Used to do this when we were stuck on 3g connections…
Fade in/out animation.
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
BTW preact + hooks + router (preact-iso) is 10 kb. It's a good starting point.
And SVG icons should use svg `<use>` tag and shouldn't be counted in code size.
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.
> if your'e using Tailwind CSS version XXX, why does the browser have to reload it every single time?
Security: https://www.stefanjudis.com/notes/say-goodbye-to-resource-ca...
This refers more to tracking, not security directly, though I suppose there is some overlap
This is also doesn't explain why the browser would constantly need to redownload the same files assuming the original requester was the same.
The browser could also introduce an ersatz delay to throw off the tracking.
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?
That post didn’t explain what it actually is. Is it a JavaScript framework? A WASM library? Something else?
Comparing a JavaScript app to anything wasm is false equivalence because wasm can’t do the DOM.
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.
Not an April fool's joke btw!
I thought it was an April fools joke, glad I'm not the only one.
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.
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.
I feel like some of react’s innovations should be built into browsers. Jquery got built in with document.queryselect.
Google decides what goes in a browser these days. Since React came out of Facebook there is approximately (checks notes) -ZERO chance in hell- of that happening
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.
https://dayssincelastjavascriptframework.com/
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.
Regarding Rust, are we talking about a Rust backend with RPC/REST or is it simply WebAssembly compiled from Rust? If the latter, how is the data synced for CRUD?
Congrats, Nue seems to be an impressive and well-thought-out design system & framework. It feels like a strong candidate to become the "Web Standards Stack" —finally freeing developers from the complexity and bloat of modern frontend tooling.
I've been following Nue for a while now, and I'm eager to use it for real world apps. Any updates on when the design system will be released? I know you're ambitious, but I'd suggest launching a single design system first to test the waters, gather feedback, and gain traction — rather than waiting to release everything at once (but losing out to the ecosystem).
I'm eager to dive into the design systems, definitely coming. But first, I wanted this release to prove Nue isn’t just for ‘hobby projects,’ a label plain website generators often get stuck with. This SPA demo was key—showing how working closer to web standards really shines for complex apps, not just simple sites.
In the meanwhile on the App/Play store some native apps like YouTube weight around half a GB... but only the web is bloated
Replace N in Nue with V for Vue, and it will be perfection.
this is why inertia.js is a positive path forward.
it relegates React, Vue etc to be view layers - purely view layers. all models / state etc handled by your monolith Rails, Laravel server. this simplifies a lot of things.
frameworks like Vue & Svelte have scoped styles which preserve knowledge of CSS. While Tailwind is convenient - a lot of people won't know the capability of CSS
and why it was named cascading & the customability of CSS for the user.
But what if it is not the frameworks that are bloated but the application developers that make bloated applications? Then how would this fix anything ...
Would you be able to hook this up to https://www.convex.dev/?
Couldn't switch to docs from the page linked here, Chrome on macOS. Refresh and it works. Big hopes killed in an instant.
Just do VanillaJS...the W3C is your framework.
Is it trying to sell Backbone.js-style MVC as a replacement for React?
No thanks, JSX is fine.
why would 150,000 records break React and throw overflow exception ?
Because that demo crashes with vanilla JavaScript at around 110,000 records
Here's the react-table example app with 112,500 records, just like your example. I am not really seeing much of a performance difference (and this is in dev mode - it would be faster if built for production):
https://n9vr4n-5173.csb.app/
it doesn't make sense.
If React is good enough to power Facebook, it's good enough for your <1k users app.
I like this. Cant wait to see it being released.
How does it involve Rust? Server side or wasm?
Nah this is crazy
love the demo and overall reason for this, hope it gets the following and support it deserves!
imo the primary benefit of react is the nice component library.
The main benefit React is giving my app is just the ability to update the DOM automatically and efficiently, without me worrying about doing anything but updating the state variables. I have a feeling some very well crafted prompt to the best AI in the world could just about generate something that can also do this in like 500 lines of JS, in a single file. Once we have that, we can get rid of React maybe?
I also hate JSX, and have my app setup so I create GUI elements programatically like "button = new Button("Save", db.save)". Templating has so many friction points I find it to not even be worth the complexity, expecially once you have templates containing other templates with looping and conditionals, etc, and you end up with just an extra layer of cognitive load. No thanks. We can do better. With the capabilities of modern JS (classes, imports, etc) we can phase out React and Vue.
> What's next We're improving the developer experience in three distinct phases: Framework -> Design -> Cloud
So the "cloud" part is where the enshittification will begin. Been there, done that, switched away from next.js :|
This is cool. Though I think what could be improved is using folder routing, it works surprisingly well.
I really like the use of markdown and extending it. I think this is the way to go.
Also how you are thinking about app theme and design is really good.
This button demo... really ambivalent about it.
Do the AI's generate slow and bloated React, or lean React that works well with the new compiler?
A React comparison is a straw man when there are already popular alternatives that are considerably smaller than React.
> 150,000 records — far past where JavaScript (and React) would crash with a stack overflow error
I think react-virtualized and stack tables can easily handle 1 million rows client-side without a problem (I saw the demo somewhere).
Web development is about convenience, and the speed of development is far more important than ultra optimizations. People simply don't care about super optimizations because servers are so fast these days, and bandwidth is cheap, almost free.
But it's an interesting project. Good luck.
> People simply don't care about super optimizations
Could be, but some optimizations in Nue really stand out. Check out bundle size, HMR speed, build speed, and especially repository size. An empty Next.js project weighs over 300MB, a Vite button is around 150MB, while a Nue SPA clocks in at just 2MB.
I would love to check out the bundle size! Will you ever create a fair comparison, where your Nue implementation has all the same features as the versions you compare it to? All the comparisons I've seen so far are deceitful since they implement much less. If Nue actually produces smaller bundles, why not create an actually fair comparison?
A Vite button? You mean Vue? Vite is just a bundler lol.
Also, would like to see some comparisons to Preact, as that's an (almost) drop-in replacement for React with SUPER small bundles. I'd be impressed if you manage to beat that.
This exact demo will crash with vanilla JavaScript (in Chrome 134.0). This React would also crash — unless the computation relies on WASM
Make a demo with react-virtualized[0] and see if it crashes. Hint: It will not[1]. React can easily render 1 million rows with high performance without relying on WASM [2]
Here is the demo of react-virtualized[3], in which I entered 10m as the row count and scrolled to the bottom without crashing.
[0] https://github.com/bvaughn/react-virtualized
[1] https://www.youtube.com/watch?v=1JoEuJQIJbs
[2] https://medium.com/@priyankadaida/how-to-render-a-million-ro...
[3] https://bvaughn.github.io/react-virtualized/#/components/Lis...
*Update: Here I made a table with 1 million rows with search, filtering, and pagination. In plain Javascript:
https://htmlpreview.github.io/?https://gist.githubuserconten...
Could you give a code example? Also, by crash, do you mean the mentioned stack overflow error?
If so, why would the stack be involved when talking element count?
Because he constructs a giant JSON by joining individual entries. Rendering that directly on the DOM will always cause the performance issues (even at the 10k entries). That's why you need to use virtualized list, it can be done in plain JS or using libraries like react-virtualized.
This works, plain JS 150k rows
The exact error is "Maximum call stack size exceeded" when the WASM- engine is replaced with this JS engine:
https://github.com/nuejs/nue/blob/master/packages/examples/s...
There is currently no demo about the crash, but you can setup this locally.
`events.push(...arr)` puts all arguments on the call stack before calling the method, which causes the error. Don't push tens of thousands of items at once.
If you're architecture is based on event sourcing, this is kind of the point
It has nothing to do with architecture, but rather understanding how the DOM works. The DOM is notoriously slow, so you should never render a huge number of rows at once. You can render millions of rows in plain JavaScript without impacting performance.
Here, I have recreated your JS example with searching and filtering and it does not crash. It's trivial to reuse a similar approach with the real backend and real events from the event source.
https://htmlpreview.github.io/?https://gist.githubuserconten...
*Update: Here is 1 million rows table with search, filtering and pagination. In plain Javascript:
https://htmlpreview.github.io/?https://gist.githubuserconten...
The point should not be using the spread operator at all costs. There are other ways in javascript to push multiple elements in an array that are more efficient than the spread operator.
The fact you didn't even stop to wonder why the error was a stack overflow when you weren't using recursive functions is also telling.
What do you mean?
You're solving a problem nobody has. If you encounter this problem, you shouldn't think "ah, let's yeet the JS engine because it clearly isn't good enough for my awesome SPA", you should think "hm, maybe I shouldn't render 10000000000 records in the DOM".
What's next? "Oh I have a memory leak, let's get a subscription on RAM modules and just keep adding them!"
No. Back when supporting ie 9 we had tables with a million rows and dozens of columns and it runs fine.
>People simply don't care about super optimizations because servers are so fast these days, and bandwidth is cheap, almost free.
Sigh.