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.

[1] https://www.airport-suppliers.com/supplier-press-release/the...

[1] https://martijnhols.nl/blog/how-much-traffic-can-a-pre-rende...

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.

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.

  - 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

This is mostly because of cases where they need to translate a sentence like "[Click here] for more information". When translating it to another language, they may have to move the link to the end e.g. "For more information, [click here]". The only way to achieve that is to shuffle DOM elements around, which can cause interference with interactive apps.

There's still a lot the Google Translate team can do to reduce the interference they cause, but I don't think they can fully eliminate it without some new browser APIs.

It's no wonder frontend has a lot more errors, after all it has to support so many more client variations than a typical backend. It can be very hard to make a big webapp that works well for everyone.

There are so many things to consider, as the original post shows. On top of that is:

  - accessibility
    - screen reader support
    - testing
  - usability
    - animations/transitions can help and are another can of worms
  - SEO
  - consistent user elements -> interface components
  - responsiveness
  - performance
    - minification
    - lazy loading images
    - optimizing images (eg serving a 200 kB webp/avif instead of a 5MB JPG)
  - caching/scaling so your server doesn't go down when Hacker News/Reddit links to it
  - hosting cost
  - security
    - CORS
    - CSP
  - forms
    - validation
    - feedback
    - helping users fill it in correctly with as little friction as possible
  - user content sanitization
  - rate limiting
  - licensing
    - of the content you make
    - images you use
    - libraries you use

There are some areas I noticed Hacker News isn't very interested in, such as web accessibility (other platforms picked that up much better), but I think that has more to do with the not-as-exciting subject than the writer/blog.

1. make so many of them, you'll repeatedly hit gold eventually

2. go the extra yard with research and/or effort

The intro's "The developer had interesting insights" makes it sound like they failed blog was full of opinion pieces. Very few opinion pieces succeed, but they're the easiest to write (i.e. the first category). It might work for some people, but for us unknowns, nobody really cares. Go the extra yard and make it interesting by doing a deep dive of the subject.

I've fully focussed on the second approach. As a consequence, each article takes a lot of time to complete, so I generally don't finish more than one per month. I try to make them all something I can actually be proud of (which is quite a challenge), and then I spend a lot of time tweaking the structure, making things less verbose, and improving scanability – I rely on making sentences bold a lot for that. I try to use relevant images, but I find actually helpful ones are hard to make for developer content. While hiring illustrators is a good idea, I doubt many writers are willing to pay for that.

To make my articles more interesting, I try to make a custom component for each article to spice it up and slowly grow the component library I have available for my blog. It doesn't always work though – for my last article I spent several hours building an easter egg that only 22 people (<0.1%) interacted with it.