5 ms·
I am sorry but...Front-of-the-side-of-the-up-of-the-what? This is division of labor gone out of control. Complexity doesn't get simplified by merely renaming
by luthfur 6y ago
I am sorry but...Front-of-the-side-of-the-up-of-the-what?
This is division of labor gone out of control.
Complexity doesn't get simplified by merely renaming things. Bloated javascript frameworks and associated "infrastructure" keeps requiring more and more people to manage them.
- jariel 6y agoThis is not crazy, it's been this way in any app of scale for a very long time. You can put a good backend guy on the 'back of the front end' no problem, it's sometimes similar work and it can feel like 'regular coding' - sometimes it helps to have the same team working both sides of the endpoint. But the 'view' components usually require very specific knowledge of the component system and also the ability to work well with the design team, which is a different thing. It's not really a stretch.
- thecupisblue 6y ago>But the 'view' components usually require very specific knowledge of the component system and also the ability to work well with the design team, which is a different thing. They require an understading of UI basics and reading the documentation. That knowledge is rarely specific, it's mostly the same pattern applied in a different manner. If a "good backend guy" can't read that (usually super simple) documentation of the frontend framework and understand how to apply it, I would not call him a "good backend". Just like a frontend dev should be able to read and understand what a node server does, a backend dev should be able to understand basics of UI frameworks, otherwise, it's not a developer we're talking about, it's a glorified typewriter.
- cameronh90 6y agoMy experience is that fundamentally, usually good backend developers are not good UI developers. They don't know or care about how to write nice-to-use interfaces. It's not a technical ability issue in general, though there are a whole bunch of quirks such as browser compatibility that it can seem a little unfair to expect someone who mostly deals with optimising database queries and algorithms to also have to learn. There is always a gap between what the designer produces and what needs to be created to make a fully functioning application. A good frontend-of-the-frontend developer has the passion, experience and user empathy to fill in this gap and make a site that is pleasant to use. I say all this as a backend/platform developer.
- thecupisblue 6y agoI understand your view, but it's just a lens you are used to looking at. At the bottom of the rabbit-hole, you model data and state like you do on the backend and you map that via provided UI layer functions and objects to the renderer. Yes, there are edge case quirks but most of them is stuff you don't need to care about, and when you do, are a google search away. A good frontend-of-the-frontend developer is great at state management and deriving state from the UI model the designer presented it and the data model the backend presented. I believe backend developers have the same skill, just lack experience/"passion" in applying it on the UI end.
- jariel 6y agoSo yes and no. 1) It takes time to get to know the framework, it's know-how, and often the docs are not clear. 2) Good UI work is almost always more than just 'stuff on a screen'. But it doesn't have to be if you have good designers.
- systemvoltage 6y agoAnyone who says front end isn’t bloated and it just feels like coding backend really haven’t tried either one of these or both. Have you tried upgrading your React app that was 1.5 years old? How many times upgrading anything in npm gives you the worst nightmares? It’s not just bloat, it’s the stress that front end dev brings. It’s a chaotic world, constantly changing for god knows why and the entire ecosystem does not value robustness and longevity. In fact, they've made it cool to break things all the time. Robust tools are considered "old fashioned". Apart from Angular, which is a still finicky, the rest of the dependency management is a complete nightmare. I can easily revive a 4 year old backend code. Most likely without a single error. With absolute and 100% certainty, I can guarantee the opposite for any front end code, even Angular projects. Node js, the backbone of managing js projects itself doesn’t value backwards compatibility.
- tomstoms 6y agoNot fair. Upgrading java libs like spring is just as laboursome given enough major releases have lapsed. Backenders need need to get their oumf out of their oumfs, and realize this is all about what you’re used to. Upgrading spring if you know spring is not as hard as upgrading React when you have no clue about React. There’s no significant difference.
- systemvoltage 6y agoI cannot tell you how many times I've stumbled on SO post that just recommends - "Just use Node v10". Usually, with no explanation. Ohhh....
- jariel 6y agoI have been coding UIs for over 20 years on and off, and I've done everything. React is a special beast, I don't like it, yes, it's a little bloated and no, I don't so much think it's quite suited to the front/back of frontend division. Your problem with bloat and fragmentation though, is not about this particular form of division of labour. Front ends change a lot more for a variety of reasons. One reason the front end evolves more is there's more going on, and more detail. The backend is logic, which can be more succinctly articulated by code. That's what code is for. Most code was never designed for UI, and even HTML/CSS was never designed to do what it's doing. A simple web form can involve a lot of cross-cutting artifacts and complex statefulness. Even with a great set of tools it can be quite hard to get right, and requires a different way of thinking than on the backend. Front end problems are usually however, narrow in scope - a screen can usually only ever be so complicated, whereas on the backend, true scale can make a lot of things hard.
- ryanbrunner 6y agoI think this probably scales to team size more than the app scale itself. I've worked on high scale apps before where I was a full stack developer, because we only had a few engineers on the team. When you have 20+ engineers, it makes sense to specialize. When you have 3, it's a huge hit to your productivity. The scale of the app is mostly irrelevant to this.