I guess that's my cue to leave front-end programming forever, and my current job (I'm not joking). I've been through too many cycles and it will never end. There's no way I'm staying for whatever crazy migration my company is going to go through again. And we have apps written in every single JS framework ever conceived. Time to learn COBOL.
If you don't hate front-end period now, mobile's a hell of a lot easier and I think it still pays better than front-end webdev for some reason. As long as you stay away from the web-tech-on-mobile crap and write actual native code. It's especially easier if you specialize in one of the Big Two, but even working on both isn't that bad. I mean, it's not JS "culture" bad.
iOS is far and away the saner of the two if you wanna pick just one, plus it's an easy gateway to the whole Apple family of devices (watch, TV) including, soon, macOS itself. Android's broadly less pleasant and any devices outside phones that happen to be running it are likely to be batshit insane to work on, but it's still way better than the web, and a ton better than it was back in the 4.x days (let alone the 2.x/3.x split days—oof, it was hot garbage back then)
I don't quite understand this. Since 2013 React has remained a JS framework and introduced 1 new concept(hooks). iOS programming on the other hand(since 2013) has introduced a new language(Swift) and a new paradigm (Swift UI) for writing interfaces. All to target around 25% of the mobile market.
Yeah. It's so annoying how developers open source so much of their work. It's as if they just throw things up on the internet and expect people to use it only if it solves their specific problems. What they fail to consider is how inconvenient it is for their fellow developers who are dazzled by everything that hits front page of HN.
I just left frontend, and I’m the maintainer for express-vue. Vue is great in its current iteration. But the whole JS ecosystem is just horrible right now. Looking at these changes, it’s not for the better.
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.
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.
