None of what you said is unique to JavaScript. Take a look at any language that has a similarly large adoption and you'll see similar frustrations. Half-baked frameworks and libraries, largely undocumented popular projects and build tools with steep learning curves.
Why we have so many of the same thing that seemingly solves the same issues? Could it be because people have different needs and requirements that aren't already solved by these tools? Perhaps the tools over complicate things that could be simplified? From Grunt and Gulp, onto Webpack, Parcel and Rollup, and now Snowpack, ESBuild and WMR – Each solving a similar problem much differently from each other due to the new kind of applications and the problems that come with it. To provide a good user experience for a majority of people, there are a lot of things that has to be done to make that possible here and now. Browsers, unfortunately, don't update quick enough to provide the UX until the problem is big enough to warrant a built-in solution. That is how the web has been able to move forward; by peoples innovation in the space and the approaches they took to solve them.
I don't agree that everything has to revolve around MVC. It's not a hammer for every problem. This is why other patterns like MVVM, MVP and other abbreviations were introduced to solve broader needs.
React starting as purely a UI library paved the way for people to find new ways to manage state and data for different kinds of applications and needs. That's how we ended up with what we have today. You can say what you wan't, but I think it's remarkable what people came up with in the past 10 years.
And these solutions are just optional things you can choose in case you have a need for them. React comes with a lot of things for building rich UI. Sure some things may require more code, but so is the nature of writing applications with specific requirements.
Server components, Concurrent Mode and Suspense came out of the frustrations that it was hard to provide great user experience and avoid common pitfalls with async I/O and high performance because they were limited by React. The solutions they came up with, while not perfect (or even ready yet) aims to solve these issues, while avoiding breaking backwards compatibility and that could be further improved upon while also avoiding breaking the API.
With regards to hooks, I agree that it can be annoying to have to manually pass dependencies. But this is unfortunately the nature of JavaScript and React's mission to not break things. The alternative would require massively changing the API. We've seen other attempts at remedying this with projects like CrankJS and SolidJS that takes a clean slate, preserving the concept of React, but taking a more modern approach on these concepts, as they have freedom of designing their own API from scratch.
We seem to agree. I'm not saying React's approach isn't justifiable. It is what it is for reasons.
I just don't agree all that complexity is worth when you need to ship things fast with a decent robustness and performance. Specially when you don't have 100s of devs in the project.
I'm just saying that given React vs Rails, for 80% of projects I'd pick Rails+hotwire+etc... But given Svelte vs Rails, I'm more inclined to pick Svelte now, because it is not so complex, for now at least.
I am curious to know whether you reported it to npm upon your findings. npm questioned me for who to credit on this matter, and they would like to know who the original finder was.
I don't know how many reported it to npm, but when I initially saw the post on HN, I took the steps to report the packages.
I don't know who to credit on this, and neither does npm but OP seems to be the source of these findings, although it would baffle me if they didn't report it to npm.
Why we have so many of the same thing that seemingly solves the same issues? Could it be because people have different needs and requirements that aren't already solved by these tools? Perhaps the tools over complicate things that could be simplified? From Grunt and Gulp, onto Webpack, Parcel and Rollup, and now Snowpack, ESBuild and WMR – Each solving a similar problem much differently from each other due to the new kind of applications and the problems that come with it. To provide a good user experience for a majority of people, there are a lot of things that has to be done to make that possible here and now. Browsers, unfortunately, don't update quick enough to provide the UX until the problem is big enough to warrant a built-in solution. That is how the web has been able to move forward; by peoples innovation in the space and the approaches they took to solve them.