[1] https://www.airport-suppliers.com/supplier-press-release/the...
[1] https://www.airport-suppliers.com/supplier-press-release/the...
[1] https://martijnhols.nl/blog/how-much-traffic-can-a-pre-rende...
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
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.
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.
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.
I use Preact often and very, very rarely run into an issue that justifies React being almost 20x the size.
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.
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.
That said, how does Nue compare to htmx and other frameworks leveraging the modern web standards?
- 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.
Depends on the context. Is this from:
1. A colleague in your workplace. You go "Hey ____, That's kind of a big PR, I am not sure I can review this in a reasonable time frame can you split it up to more manageable pieces? PS: Do we really need a DSL for this?"
2. A new contributor to your open source project. You go "Hey ____, Thanks for your interest in helping us develop X. Unfortunately we don't have the resources to go over such a large PR. If you are still interested in helping please consider taking a swing at one of our existing issues that can be found here."
3. A contributor you already know. You go "Hey I can't review this ___, its just too long. Can we break it up to smaller parts?"
Regardless of the situation be honest, and point out you just can't review that long a PR.