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.
(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.)
Without that knowledge, I agree that good old SSR (MPA) is easier and more maintainable. And more robust.
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.
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.
I wish the homepage talked more about how nue approach the problems rather than how better than other framework it is.
The comparison uses the non-wasm version at mpa.nuejs.org
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.
Rich and HTMX have a much different tone while shaming React.
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.
That said, how does Nue compare to htmx and other frameworks leveraging the modern web standards?
- htmx = 14k as min.gz
- solidjs = 7kb as min.gz
- 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
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.
Perfectly proving my point.
It's not react-the-framework's fault, yet those sites are always react sites.
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.
[1] https://martijnhols.nl/blog/how-much-traffic-can-a-pre-rende...
You don’t need to wrestle with React’s state management monster unless you’re into that sort of thing.
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.
Each team member could take their turn using it so that it's already tooled up for the project they are working on.
That said, how does Nue compare to, say, Svelte?
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'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.
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.
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.
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"..