[BigJono]

I'm almost done with it as well.

I can actually handle the churn and the random rewrites, a lot of them have been marked improvements, that doesn't bother me. What bothers me is when things change in ways that make them more complex than they were before, which also happens constantly.

Not only that but I'm sick and tired of tool developers pandering to noobs. Nobody should ever be learning to use a library like React before understanding the programming language they're working with. For the React team to come out and say something as stupid as 'classes are too hard', in the context of the sheer wall of accidental complexity around the front end space, is a joke.

All the problems with PHP back in the day are going to come back with a vengeance when our new generation of coders that don't understand basic language constructs all graduate to tool making.

[Tade0]

I'm trying to focus on the good parts of it, like: at least our jobs are safe.

Anyway do you have a minute to talk about our lord and saviour Rich Harris?

https://svelte.dev/

[lwansbrough]

This was literally the exact same pitch Vue made when it came out. The developers get bored and add complexity. Don't get your hopes up.

[Tade0]

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.

[Can_Not]

Are there any svelte tutorials/examples that specifically target vuejs users?

[Tade0]

I haven't seen any, but as a relatively early proponent of Vue(as in: I was there when v2 came out), I found Svelte even easier to get into than Vue.

Anyway Rich Harris' presentation is a good starting point:

https://youtu.be/AdNJ3fydeao

[xmprt]

God why did you show this to me. Now I really want to build something with Svelte but the project that I'm working on currently is built in Vue...

[BigJono]

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.