The Github API is definitely a good benchmark.

Linear's GraphQL API might be another interesting one to look into https://developers.linear.app/docs/graphql/working-with-the-....

Good point. Also probably the performance problem will come from some slow query on the server side rather than some React code on the UI side.

Not sure I understand the point of this article. It seems that we're trying to talk about how popularity doesn't reflect the most advanced technical solution. But where is that the case? Java's adoption is huge compared to say Clojure or Elixir. One reason why people choose React is due to being able to hire a specific set of developers and leverage the huge eco-system of tools, libraries and information surrounding React. React has reached the late majority now, and it's everywhere. Most of these mentioned libraries, i.e. Svelte or SolidJS, are probably more in the early adopter phase. These things take time.

Depending on what you want to build and how many people will contribute, the answer might vary. HTML/CSS/JS can be enough, but mostly you will need to handle streamlining browser differences etc. explicitly. Frameworks are popular because they can help to streamline these issues. Also there is mostly an eco-system built around these frameworks, so you don't have to build every component from scratch for example. From a business perspective it's easier to say we're hiring for this specific framework (React, Vue etc). vs. we have our own rules and styles. Finally these frameworks also have a social function. It's like a style or taste preference, where a group shares the same preferences.

I doubt that Scrum is about helping developers or whatever this post is trying to imply. It's a very mechanical framework with rigid rules and meetings. It's very fragile and breaks apart as soon as you try to change something. One place where it actually makes sense is when trying to move away from a chaos into a more structured process. This is where Scrum is useful, because it comes with rules to introduce this structure. But it never failed developers, that target group is business people, promising to deliver more in a shorter time via rigid time-boxing.

What exactly is the goal for adding yet another meeting? There is a try to fix these issues within the agile community by "rethinking" instead of simply removing it. If it doesn't work, then remove it.