Comment by tipiirai 11 days ago
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!
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's a debate spanning multiple decades. Your last sentence is not true all the time.
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.)
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.
Yes, sorry for venting on your thread. I do appreciate the idea of leveraging web standards though.
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 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.
Not the discussion, but SPAs are fundamentally safer against XSS, in the sense that data and code have different paths.
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.
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.
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.
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.
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 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.
- htmx = 14k as min.gz
- solidjs = 7kb as min.gz
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.
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?
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.