Having done all three, I have a mental model with two axes: appreciation and meddling. It might be appropriate to sketch it here.
With design, the result of your work ends up being visual, so you get a lot of appreciation for it. Maybe too much, sometimes. On the other hand, everyone has an opinion about how you could do your job better, and they're happy to stick their fingers into your work (because it's so easy, you know?).
With back-end development, nobody is going to meddle in your work except other engineers: by meddle, I mean step in and tell you how to do it better. That's because they don't know what you do at all. The other side of that opaqueness, though, is that you rarely get credit for good work. Stuff just works the way it should.
Front-end development is in between the two. People will give you credit when things work the way they should, and when they look nice, and so on. But, half the time when an application is "snappy" and performant, they'll credit the designer for it (ha ha). At the same time, they'll also tell you how things "should" work, based on how other applications do it. Meanwhile, you're stuck between what the designer approved, and what the back-end supports, and you're just doing your best to make it all work.
Couple that with the fact that the whole front-end world has gone completely bonkers, reinventing the wheel so many times in the last 10 years I'm surprised my head hasn't separated from my body.
It's funny that things have come full-circle these days, going back to server-rendered views. My career literally witnessed the entire move from HTML -> SPA -> HTML again. It only took roughly 16 years.
Strangely, even though I’ve been doing this for twenty five years and I’ve never been better at it, in today’s bullshit interviewing environment, I can’t get a job because I can’t solve algorithms or do system designs in forty five minutes. And so I’m sitting on the sidelines right now. It’s the most bizarre experience of my career.
I’ve created projects that are used by the entire business and customer facing part of the company, which are so rock solid and user-friendly that the users and even developers who’ve come after me completely takes the functionality for granted.
One feature in particular, I came up with a lot of the UI myself, even while working with a designer. I made the backend work. I spent a lot of effort making it just feel good. It went out, I got congratulations, it was great. Now, 3 years later, it still works with minimal maintenance. Entire processes of the business have been built on top of that functionality. Everyone completely takes for granted that this highly complex system has worked with nearly zero issues for years, and allowed a ton of new features using it as a base.
And honestly building something complex that works so well that everyone takes it for granted is an amazing feeling.
I’m just extremely lucky to have management that recognizes it and has seen the value in that contribution. But I don’t know how I’d ever sell this to another company if I were to look for another job in the future.
While I don't do frontend work, I still push UX and management to minimize the surface area and complexity of the frontend. Keep to simple html elements, flowing top to bottom with minimal css, etc.
1. I'm the only FE dev, with a strict separation between BE and FE work (and a BE team that's happy with this arrangement).
2. I'm given the keys to the castles in terms of technology and architecture for the FE.
This lets me maximize time spent understanding our product, our users, and iterating with PM/Design.
Front end is how I got started programming, both as a hobby and professionally. It has a certain tangible quality to it that makes it both approachable and satisfying, but that often gets misconstrued as "easy". It's not easy!
I spent several years doing mostly-FE work and all the bikeshedding and meddling and "just make it do X why is it so hard?" burned that appreciation right out of me. It's also the first thing to get blamed for every bug and error, because it's what you see and interact with, which is just exhausting.
I took the technical skills I learned and transitioned to mostly backend where there's more "trust" (i.e., I don't understand what you do so I'll just let you do it) and autonomy. A small part of me misses the visually demonstrable part of front end, but the work culture around it I don't miss one iota.
Kudos to all front-end devs out there!
Of course many FE engineers have the chops to solve for these things, as well as PMs and designers with technical background, deep domain expertise, and other qualifications that can make up for these gaps. I came up professionally in the early web days and building startups where it was normal to wear many hats, so it's more about skillsets than rigid titles and role definitions. I've just seen a very common gap that a lot of ostensibly professional proddev folks, even at top companies, have borderline magical thinking about the deeper layers of the product stack.
This led to an app that could fit like 4 table rows on a standard 1080p display, and every row of that table had very little actual info
On top of that, for some ungodly reason text size was defined by view width, and on some of the old 4:3 displays that were there, it was damn near unusable
Imagine a system processing billions of records per day/week/month, dealing with data caching, data warehousing, providing realtime notifications to users and external systems, managing queue workloads, handling inbound requests from various APIs, syncing data between backend systems, running multiple data stores and scaling across multiple regions, redundancy, and handling incidents that arise on the backend. This is typical for complex web software.
A frontend system that provides the interface to that backend system will usually not have issues arise in the middle of the night due to the automated processes happening on the backend, will not have to worry about how many users are using the system nor how much underlying data there is.
No matter how difficult it is to do the initial development of the frontend (or to keep that code updated when browsers change), at the end of the day once the development is done it's static code interfacing with a much more complex underlying system that requires constant attention as underlying data and business requirements evolve.
Last place I worked that struggled with "scale" tried All The Things except one: simplification. It was like being a little kid in a royal court filled with naked people complimenting each other's fashion choices.
Tell me about it. I've been struggling for years to get our designers to think of their designs as more than pixels on a screen. I'm really tired of having to be the accessibility police, or explain that small viewports and mobile devices aren't synonymous for the nth time.
But it’s so important for SaaS type companies to do this correctly, I felt like I was treading water and stagnant with "backend code" that was mostly just piping the db data to the UI.
Back in the day, Mitch Kapor (Lotus 1-2-3) was widely panned for claiming design is a skill set separate from programming, and should be valued equally.
Not much has changed since.
> frontend is probably the hardest part of the stack
Again, this has always been true. Especially in terms of fit & finish. It's really no comparison. And it gets harder over time.
The real bummer with UI work is when you nail it, almost no one will notice.
And this is just for working in the browser. Once you your product is big enough you just know there will be requests for a native app on mobile. Oh but also the mobile version of the website needs to keep working. So now you're adding in requirements of learning Swift, Java, and the platform specific UI frameworks/SDKs.
I learned how hard frontend is when developing a browser-based game.
The backend code was simple and easy to test with unit tests.
Frontend though is a slog to write, and even greater slog to test.
I wonder how much better frontend would be if JavaScript wasn't the chosen language. It's just such a bad language in so many ways.
Has flex+grid eased the situation somewhat? With media + container queries?
If not, why not? Are these models too complex or the browsers still are buggy/inconsistent in their implementation of these layout algorithms?
To me, the trick to using flexbox effectively is to use it to create fully reactive layouts the way that Gtk or Qt would design them. I create flexbox interfaces in terms of "VBox" and "HBox" containers, I use flex-grow to handle the concept of "box packing."
Once I started seeing it through this lens, and when CSS finally added calc() and other functions writing good and consistent frontend UIs that mimic precisely how almost all other desktop software behaves became incredibly simple.
The only real complaint I have is that after I have a finished product, going back and making changes is harder than what other techniques might afford, thankfully HTML added <template> and by incorporating that liberally into my designs I've regained some of the original careless flexibility I had before it.
> being able to write complex UIs that can work on any browser, any device, with all assistive technologies, and all languages, is extremely hard
Why do we keep doing this? If you get rid of the animations, popups, and invasive ads, then with what's left you can probably do away with all of this crap.
I’m grateful to those who have the patience and skill for it.