[notpachet]

Sorry, but I have stopped using "developers don't like this" as a measure of the technical quality of anything. A lot of developers like things that are pleasurable to them in the small, but harmful to the codebase in the aggregate, especially over years of maintenance cycles.

[whakim]

I'm not sure I agree with this. One of the elements of a well-designed system (whether we're talking about software libraries or anything else) is that the designer should reward people for doing what they like. If you design something where the correct approach cuts against people's natural inclinations, they'll just use something else. The correct answer is to design paradigms that make the right thing pleasurable.

[notpachet]

I agree that systems should be rewarding to the user. But there are rewards and there are rewards. There are short-term dopamine fix rewards, and then there are the rewards that you can only really appreciate after having invested some time and energy first. It's like fast food vs a lifetime of diet and exercise.

The churn in the frontend ecosystem reminds me a lot of fad dieting: people have never really experienced working in a paradigm that enables them to stay healthy through regular diet and exercise over the long term, so they turn to the latest shiny gizmo hoping that this time it will be different.

[whakim]

I agree with you that there's a balance to be had here (although I will note that there's a pretty big difference in physiological effect between tens of thousands of years of evolutionary history and a few years of writing code). That being said, I don't think we should make "rewarding to the user" a second-class citizen to "technical quality" - I think it's an important component of good technical quality that something is pleasurable to use. My impression is that a lot of self-serious systems designers don't embrace this view because it's easier to blame the technical incompetence of their users.

[arvinsim]

Doesn't matter. Every developer will still be at the mercy of the whims of the majority unless you find your own niche.

[notpachet]

I'm writing this stuff to try and push back against the whims of that majority, because I think they're ill-founded. Just because a majority of people believe something to be good and true, doesn't automatically make it so. It still has to stand up to empirical evaluation on its own merits.

[dgb23]

Lowest common denominator.

[onion2k]

This is true, and especially true for tutorial and course authors. There are a lot of low quality tutorials that are essentially a dev talking about how they prefer to wrute code rather than teaching any useful, generic material that applies universally. Often what works in their courses for a lone junior dev would not scale to a small team, and following their ideas would produce a pretty terrible app.