| Yep! Picture this from the engineering or product manager's point of view (especially in the case where it really is simple, and the app is links and forms with a consistent look and feel.) Imagine a split for a Rails app (like what was common in 2000-2010) where you have - Backend engineers managing most of the logic in ERB templates - One designer-turned-frontend guy who is deep on HTML/CSS/JS, spends most of his day writing CSS so the backend engineers don't have to CSS, even for people deep on it, is not very fun. It's especially not fun if your backend devs control the codebase where you can actually define the HTML tags that make up a component. So a really common situation was - Designer-turned-frontend guy burns out, or wants to transition into pure development - You have a hellish search for their replacement, since the pitch is "seeking a person who is interested in a low terminal IC position, is interested in the least fun part of web tech, and whose hand will be slapped if they dare to touch the backend engineers' code." In practice once you lose that one guy, you have months of a gap before you find your CSS expert again. - In the meantime, you have a workforce that doesn't get why look & feel is important and stakeholders who can't understand why no one can put polish on any of their new GUI features, despite building a GUI. SPAs made this much, much easier. Now, frontend devs - Have full control over the structure of a component for styling - Don't have to get the backend devs' permission to change things they know they need to change to style things correctly - Can make reusable components with the same styles, allowing design systems to take off in ways they didn't before - If the person wants to branch out and get more programming experience, some of the logic is on the frontend too. The job isn't "all styling, all the time, leave the logic to the other teams" and there are areas to show skill. Retention is 10 times easier and there are fewer key people who can never take a vacation. - And critically - you have a team for whom look and feel is not an afterthought, with the power & ability to make code changes. No more explaining to stakeholders why buttons look totally different page-by-page and why the team can't be convinced that consistent branding is important for businesses. |