I'm aware of that - hence the form of my previous comment.
"This time it's different" though.
The difference being: this here is radically less complex and unlikely to become much more.
All this complexity in frameworks was always added in a vicious cycle, namely:
1. Developer looks at a component - they see complexity.
2. They don't know how much of it is due to the business logic being complex and how much is introduced by the framework, which has to deal with the limitations of the platform, so they assume it's the latter.
3. To deal with this they create yet another abstraction and an associated convention, which makes one problem better and a good few others worse.
4. Other developers see the examples and figure that this new method indeed solves that one problem, so they adopt it.
5. The result is ever increasing complexity.
Enter Svelte(and similar technologies): it's not a framework, but a compiler - it doesn't have to play by the same rules, so it (eventually) avoids framework-related complexity.
It's noticeable in the way how Svelte 3 ditched setState() altogether and replaced it with simple variable assignment.
I don't think it's just because the devs get bored. It's because the users crack the shits if their specific use cases aren't handled, and when it comes to 'frameworks' nobody wants to switch or use anything that's not the most popular, so over time they just get more and more bloated trying to handle more use cases.
It's twice as bad if there's financial incentives for having a userbase (see all the tools not owned by FB/Google etc where the contributors sell training etc) because then it literally pays to add as much crap into your library as possible to try and get as many people using it as you can, regardless of the effect it has on quality. Even if something would make more sense as a fork or alternative, it's getting added in, whether it's good for the library and ecosystem or not.
Anyway do you have a minute to talk about our lord and saviour Rich Harris?
https://svelte.dev/