Everyone always likes to blame the front-end engineers for being slovenly, but my experience is that; UI is just messy. It's just hard to program cleanly.
Not to mention, modern UIs are generally more complex than the old VB days (at least, my programs are): they have to adjust to various screen sizes. They are almost always client/server apps and need to account for more failure modes. They are built on top of a mess of a document layer that was never intended to be an application layer.
This last point is the reason the front-end space has so much churn. It's still an unsolved problem, and may never be well-solved, but I'm glad folks are trying to solve it. React was a step-change for me in terms of building better UIs. I'm looking forward to the next step-change.
Lastly, before someone makes the argument: no; we aren't going to stop building applications on top of the DOM + CSS. Not until someone comes up with an alternative that gives us the same ease of distribution and broad base adoption.
Edit: I should note, I'm a full-stack dev, and have been more back-end than front-end for most of the early part of my career. The backend is always easier for me at least, but I don't think it's because front-end devs are hipsters.
I'm an almost entirely frontend dev (iOS + macOS now, web development in the past) and this is what I've come to believe. It's easy to program UI cleanly if it's extremely basic or not very usable — but the second you want an animated transition between states, or to remember what the user checked on the last page so that you can keep it checked on this page, or any number of other things that you need to do if you actually want people to _enjoy using your software_, it gets much harder.
My take is it's because building UI is building software for humans, and humans often want behavior that doesn't allow for clean abstraction. Backend dev is more about building for other software -- not that it's easier, just a different set of problems.
Never really thought about it this way but I completely agree
In a way I find this meme even funnier now because of how backwards it is. Often times it's the backend that's really clean and organized and the frontend is a hot mess.
I think if you actually used hooks, you'll notice this immediately. It's not a matter of "looking cooler", a lot of language theory went into making UI development functional and less stateful, which in turn makes it far easier to manage complex applications. A small team can maintain a pretty huge beast if using hooks effectively.
IMO there's significant complexity in building a feature-rich frontend client. The "thicker" the client, the worse it gets. There's definitely a lot of 'I think this looks cooler' going around, but also we shouldn't forget that the need to come up with something better is partially a response to very real, very-not-imagined, frontend complexity.
Doing complex things is always complex, but when SIMPLE things are complex, then something is going very wrong.
And this is exactly where we are with most JS frameworks these days. Layer upon Layer of abstraction, and instead of the complexity the dev has to deal with decreasing as a result of it being abstracted into frameworks offering simple interfaces, complexity increases.
Have you been saying the same thing since 2014? JS frameworks have never been simpler, never been more discoverable thanks to TS, and there are plenty of levels of abstraction a developer can put between themselves and vanilla JS. But even calling React too-far-abstracted-to-be-simple is comical; it's a simple system offering composition of components.
You're using this straw man to demean the author, but I think you miss an interesting point: it can be very hard in software developer to articulate the good and bad. "Uncle Bob" refers to this as "code smells", where you can't quite say immediately what's wrong here, just that you don't like it much. Something smells bad.
And maybe the point of Solid is to point out a mistake React made in their implementation of hooks. Hooks were badly needed, no doubt, but often times an okay solution to a really serious problem can look like a great solution.
The back end went through a lot of this already. That's why the patterns are more stable there, and why you feel less churn. The front end is exciting precisely because there's so much to still figure out!
To people who know what they are doing more code than necessary to accomplish a task is the code smell.
To people who are super insecure vanity code is required because patterns are memorized, so any deviation from the unnecessary boilerplate is the code smell.
While I agree, I think a lot of developers are oversensitive to boilerplate, sometimes to their own detriment. And the effort to shave off boilerplate quickly runs into diminishing returns. Beyond a certain point you end up with code that is harder to use because of the layers of abstraction you've added to avoid the last-mile developer writing unnecessary boilerplate.
But I am a touch typist, whereas I'm noticing more and more developers who are not, so maybe there's something there.
UI developers focus on user interface, and much of that has to do with looks, style, and personal ergonomics. In a way, it makes sense that the engineers steeped in this type of problem set would be oriented to thinking this way. Even if they aren't initially, the probably will be over time.
In my experience, backend development is often simpler because you can move any state out of your own code into dedicated external components, like databases and queues. With frontend code, you have to manage state; there’s nowhere else for it to go.
> "Ohhh, an OO pattern with a couple of one-liner lifecycle methods is just WAY too much code! Higher likelihood for errors and worse developer experience."
...
> "So instead, I'm going to replace this with a functional pattern, that crams a couple of lifecycle functions into a closure, and is riddled with edge cases and common developer mistakes."
This article perfectly crystalizes why my career has tracked toward the backend over the past decade. All of the virtual ink in this article, and honestly most of the complexity in the field overall... and it seems to really all just boil down to, "I think this looks cooler."