11 ms·

The author lost me in the introduction. > "Ohhh, an OO pattern with a couple of one-liner lifecycle methods is just WAY too much code! Higher likelihood for e

The author lost me in the introduction. > "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."

nawgz 5y ago
A factor of two reduction in LOC and an elimination of almost all boilerplate is justifiable in itself. I don't know where the author said "I think this looks cooler"
thomascgalvin 5y ago
UI development seems determined to repeat every mistake we've made on the backend over the past thirty years, while adamantly refusing to ask us about any of those mistakes.
- pier25 5y ago
  Care to elaborate? What mistakes are you referring to?
  - nawgz 5y ago
    None in particular, it's just a classic jibe from those who dislike UI frameworks because they don't use and thus don't understand them
- jakelazaroff 5y ago
  I don’t think there’s much overlap between the two, besides general programming best practices. 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.
jimmont 5y ago
I didn't find the word "think" in the article. Did you mean "feels like this looks cooler"? Feeling does appear to be the prevailing way decisions are made and put forward in the community. I think that's a problem. And one that won't be going away anytime soon.
prea 5y ago
> 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.' 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.
- usrbinbash 5y ago
  > IMO there's significant complexity in building a feature-rich frontend client. 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.
  - nawgz 5y ago
    > this is exactly where we are with most JS frameworks these days 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.
phailhaus 5y ago
The OO pattern is far worse, and it's easy to show why: there is only one lifecycle method of a type for each class. This means that when you have a set of related behaviors, you have to split them up across several lifecycle methods and keep them in sync. Sure, that's fine if you just have "one-liners", but software grows, and over time your class will become difficult to maintain as each of those lifecycle methods start managing several different behaviors, all interrelated. With hooks, this isn't a problem: each set of behaviors can be encapsulated by a single hook that handles all lifecycle events together. This can be further abstracted into its own function, which allows them to be trivially reused in any other component. It's simply not feasible in OO patterns. 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.
christophilus 5y ago
I've been in the industry since the days of VB6 (which I loved). I've never been more productive than I was with VB6 and WinForms. That said, UI has always been a mess, even then. The more feature-rich you want your UI, the gnarlier and messier it gets. 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.
- bradly 5y ago
  VB6 was great. I also really enjoyed RealBasic for desktop apps on the Mac. It just worked. Network programming with sockets was so simple. Now I open XCode and am completely overwhelmed.
- marcellus23 5y ago
  > UI is just messy. It's just hard to program cleanly. 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.
frolicker 5y ago
rr808 5y ago
True but backends are not always refuge. The back end Java version at my company would have a DI container, a few interfaces, factories, configuration files, custom attributes and a few random library dependencies thrown in.
mabbo 5y ago
> "I think this looks cooler." 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!
- austincheney 5y ago
  Super subjective. 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.
  - notpachet 5y ago
    > To people who know what they are doing more code than necessary to accomplish a task 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.
contravariant 5y ago
Seems a bit odd to call the version that repeatedly calls the constructor an OO pattern.
gorjusborg 5y ago
When you say it out loud, it all makes sense. 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.

nawgz 5y ago

A factor of two reduction in LOC and an elimination of almost all boilerplate is justifiable in itself. I don't know where the author said "I think this looks cooler"

thomascgalvin 5y ago

UI development seems determined to repeat every mistake we've made on the backend over the past thirty years, while adamantly refusing to ask us about any of those mistakes.

pier25 5y ago
Care to elaborate? What mistakes are you referring to?
- nawgz 5y ago
  None in particular, it's just a classic jibe from those who dislike UI frameworks because they don't use and thus don't understand them
jakelazaroff 5y ago
I don’t think there’s much overlap between the two, besides general programming best practices. 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.

jimmont 5y ago

I didn't find the word "think" in the article. Did you mean "feels like this looks cooler"? Feeling does appear to be the prevailing way decisions are made and put forward in the community. I think that's a problem. And one that won't be going away anytime soon.

prea 5y ago

> 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.' 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.

usrbinbash 5y ago
> IMO there's significant complexity in building a feature-rich frontend client. 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.
- nawgz 5y ago
  > this is exactly where we are with most JS frameworks these days 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.

phailhaus 5y ago

The OO pattern is far worse, and it's easy to show why: there is only one lifecycle method of a type for each class. This means that when you have a set of related behaviors, you have to split them up across several lifecycle methods and keep them in sync. Sure, that's fine if you just have "one-liners", but software grows, and over time your class will become difficult to maintain as each of those lifecycle methods start managing several different behaviors, all interrelated. With hooks, this isn't a problem: each set of behaviors can be encapsulated by a single hook that handles all lifecycle events together. This can be further abstracted into its own function, which allows them to be trivially reused in any other component. It's simply not feasible in OO patterns. 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.

christophilus 5y ago

I've been in the industry since the days of VB6 (which I loved). I've never been more productive than I was with VB6 and WinForms. That said, UI has always been a mess, even then. The more feature-rich you want your UI, the gnarlier and messier it gets. 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.

bradly 5y ago
VB6 was great. I also really enjoyed RealBasic for desktop apps on the Mac. It just worked. Network programming with sockets was so simple. Now I open XCode and am completely overwhelmed.
marcellus23 5y ago
> UI is just messy. It's just hard to program cleanly. 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.

frolicker 5y ago

rr808 5y ago

True but backends are not always refuge. The back end Java version at my company would have a DI container, a few interfaces, factories, configuration files, custom attributes and a few random library dependencies thrown in.

mabbo 5y ago

> "I think this looks cooler." 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!

austincheney 5y ago
Super subjective. 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.
- notpachet 5y ago
  > To people who know what they are doing more code than necessary to accomplish a task 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.

contravariant 5y ago

Seems a bit odd to call the version that repeatedly calls the constructor an OO pattern.

gorjusborg 5y ago

When you say it out loud, it all makes sense. 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.