MartijnHols

Another theory is your server got compromised but they cleared their tracks. Not every hacker wants to make a quick few cents from a miner that gets shut down in a day or two.

If you saw customer data was being compromised; financial data, government data, electronic patient records etc, and you had the fix. Would you do nothing?

Rate limits don’t work if bots rotate IPs from residential blocks on every request.

What are you looking for? I use Bunny CDN along with Bunny Shield, and together they're better than Cloudflare for me. It's $10/month, but I can afford it for the privacy of my users. Bunny's aggressive bot blocking without bothering the vast majority of users with regular challenge pages provides a much better UX.

I opted for Bunny Shield exactly to combat bots, in particular ones that spoof User Agents and rotate millions of IPs. It works great, detecting the vast majority of bots and challenging them. Much more user friendly than Cloudflare too, which typically resorts to challenging everyone (not that CF was ever an option due to various concerns).

I also added various rate limits such as 1 RPS to my expensive SSR pages, after which a visitor gets challenged. Again this blocks bots without harming power users much.

Telling a new contributor no thank you is hard. Open source contributors are hard to come by, and so I’ve always dealt with PRs like this (albeit before AI days but from people who had never written a line of code before their PR) by leaving a message that it’s a huge PR so it’s going to take a while to review it and a request to make smaller PRs in the future. A couple of times I ended up leaving over a hundred review comments, but most times they were all fixed and the contributor stuck around with many better PRs later.

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.

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 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.

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.

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.

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.

The article mentions they inject a web component. I imagine a bad actor could add something to that. In this case at the very least the author could add a "I hacked your Grammarly extension" text just via CSS, but I'm sure you can go much further, even more so with other extensions (eg password managers).