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.
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?
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.
> 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.
> 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.
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.
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.
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
> 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.
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.
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.
> 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.
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.
I think with necessary effort websites with most of the frameworks could be loaded quite fast (with some obviously it is easier), the thing is it's rarely the priority compared to the business needs that are getting addressed.
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.)
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
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.
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!
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.
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.
- 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")?
If the authors of this project mean to say that a button in react wouldn’t work without including the react library (which is why the button is supposed to be 73kb), it’s a weak point, because the react library would be reused by other parts of the app bundle at this point.
This is misleading to people and the promise is so shallow that it almost feels insulting.
I really like the approach but the demo [0] doesn’t really work on iOS Safari (although might be my outdated 16.7.8 version).
Scrolling doesn’t work, the layout and buttons have weird line breaks, the native search button is embedded in the custom designed one, leading to 2 icons…
> 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.
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.
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.
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.
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.
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.
[+] [-] fcpk|11 months ago|reply
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.
[+] [-] oefrha|11 months ago|reply
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.
[+] [-] ikurei|11 months ago|reply
> 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?
[+] [-] jeffhuys|11 months ago|reply
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.
[+] [-] geocar|11 months ago|reply
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.
[+] [-] bambax|11 months ago|reply
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.
[+] [-] mapcars|11 months ago|reply
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.
[+] [-] maxloh|11 months ago|reply
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.
[+] [-] docmars|11 months ago|reply
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.
[+] [-] andai|11 months ago|reply
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)?
[+] [-] rdsubhas|11 months ago|reply
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.
[+] [-] martinsnow|11 months ago|reply
[+] [-] throwaway290|11 months ago|reply
[+] [-] sensanaty|11 months ago|reply
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.
[+] [-] ellinoora|11 months ago|reply
[+] [-] sheepscreek|11 months ago|reply
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.
[+] [-] robertlagrant|11 months ago|reply
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.
[+] [-] SebastianKra|11 months ago|reply
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.
[+] [-] nsonha|11 months ago|reply
[+] [-] CodeCrusader|11 months ago|reply
[+] [-] nine_k|11 months ago|reply
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.)
[+] [-] maelito|11 months ago|reply
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.
[+] [-] selfmodruntime|11 months ago|reply
Come on. That can't possibly be true.
[+] [-] CyberDildonics|11 months ago|reply
[+] [-] lern_too_spel|11 months ago|reply
[+] [-] jbreckmckye|11 months ago|reply
Swapping out your render layer won't change that
[+] [-] chidam333|11 months ago|reply
[deleted]
[+] [-] davedx|11 months ago|reply
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
[+] [-] wg0|11 months ago|reply
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.
[+] [-] tipiirai|11 months ago|reply
[+] [-] JodieBenitez|11 months ago|reply
[+] [-] pier25|11 months ago|reply
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.
[+] [-] codedokode|11 months ago|reply
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.
[+] [-] uasi|11 months ago|reply
[+] [-] canterburry|11 months ago|reply
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.
[+] [-] edweis|11 months ago|reply
[+] [-] arijun|11 months ago|reply
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")?
[+] [-] greg0r|11 months ago|reply
This is misleading to people and the promise is so shallow that it almost feels insulting.
[+] [-] leonhard|11 months ago|reply
[0] https://mpa.nuejs.org/app/
[+] [-] n2d4|11 months ago|reply
[+] [-] aziaziazi|11 months ago|reply
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.
[+] [-] h14h|11 months ago|reply
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.
[+] [-] bryanhogan|11 months ago|reply
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.
[+] [-] imiric|11 months ago|reply
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
[+] [-] vanderZwan|11 months ago|reply
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.
[+] [-] zol|11 months ago|reply
[+] [-] austin-cheney|11 months ago|reply
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.
[+] [-] mary-ext|11 months ago|reply
[+] [-] supermatt|11 months ago|reply
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.
[+] [-] unchar1|11 months ago|reply
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.