Programming

This is a very surface level overview of the frameworks it covers. The title is a bit of a reach, as it wouldn’t give anyone enough information to make a more educated decision about which framework to use.

Are you the author? I think it could be improved by including:

• metrics - number of apps that use each, number of job offerings, github stars
• who backs each project, and how much can we trust them to continue developing it in a way that’s friendly to developers
• for React specifically, a bit more info on the prominent frameworks - Next.js, Vite, Gatsby, CRA/CRACO, or ejected CRA - since the difference between them is substantial
• a high level description of the use case that the framework is designed for, as well as use cases where it isn’t well suited or has drawbacks.
• how does the development experience differ? Is there a lengthy build step? Does it offer hot reloading? Does it come with a built-in linter or integrate easily with one?
• Does it have a bundled testing framework, and how does that compare to other offerings? For example, CRA comes with jest and it can be a pain to configure jest to properly handle all of your dependencies - it doesn’t use the same build pipeline as your app and will fail if you’re using newer dependencies that use import statements instead of module.exports and you don’t individually configure each one. Vitest, by contrast, uses the same build pipeline as Vite.
• Ease of writing unit tests, component tests, and e2e tests (even if that means pulling in another library)
• ease of use with or without typescript
• some more substantial example apps per framework, like a to-do list that uses a simple API (preferably the same API in all cases). Currently the examples don’t even show what the code looks like with basic styling

If you are the author, I saw your article on Typescript and would also like to say that you can configure your linter to not warn about using any. There’s even a no-implicit-any rule that you can use if you only want explicit any types but don’t want, for example, responses from API calls to have that type by default.