The irony is that we are now all very enthusiastic about a text based user interface.

UI, in my mind, has always been the hardest part of the stack. It is even more true today. A front-end dev must: - Deal with a subjective human (not an objective machine) - Deal with designers and product managers - Be constrained by the back-end engineer and infrastructure - Make it work on multiple devices and browsers - Use the framework someone else chose - Not break anything

Kudos to all front-end devs out there!

I don't mean to minimize the effort of FE as I agree it is under-appreciated. But if the BE folks don't work closely with PMs and designers then you're already fucked and no amount of FE lipstick will make up for it.

Your comment made me curious: what kinds of insights have you seen BE folks miss due to not working closely with PMs and designers?

Obviously it depends on the product/project, but the backend (data modeling, state management, data locality, etc) is crucial to how the product works and UX. The most common gaps I've seen are ineffective reasoning about the state of the user over time, permutations of different logical states, and consistency across surfaces owned by different teams. A good BE product engineer can get their head around the whole problem space and reason about the UX holistically in a way that can provide a huge amount of value to designers and product managers in interactive sessions. If BE does not get a seat at the table you often end up with non-sensical PRDs, designs missing critical details, or worse visual typos end up being interpreted as requirements.

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.

Not only are good frontend engineers rare, but I've also noticed that it seems to be common for the best ones to migrate out of frontend work. They get tired of spending all day fighting with colleagues who have coding skills but not design acumen, and the same traits that make them a good frontend engineer also make it very easy to transition to a role that comes with a less psychologically costly work environment.

That, and you have to spend so much time justifying your value. Most people can appreciate when things look nice. However the bar is usually pretty low, set to above “barely working” in most cases. That, coupled with the things you mentioned above, makes the field difficult.

Personally, I love front end work. I love the crazy challenges and weird constraints. I love seeing a UI — something that a human interacts with — at the end of the process. Server side work can be interesting for a little while, but if I don’t see the results in the UI, it feels hollow.

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.

Yeah I totally get that.

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.

If your skills support it, perhaps try repositioning yourself as "a designer who codes" or "UX Engineer".

I’m not a designer, though. And that would be selling my engineering skills short. Coding is a relatively small part of good software engineering.

Yeah I moved out of frontend work for the backend. Backend work is a series of black boxes. You can make a million mistakes and it won't necessarily be an issue. With the frontend your work is exposed for everyone to see and critique. Not only that, but it's very hard to actually compartmentalize changes. A component that looks fine in isolation might be completely out of place in a larger peice. I frequently found myself near panicking that I didn't mess something up before launch because it was nearly impossible to handle all cases that we cared about through tests. Of course we would hire people to run through the site once before launch. But what about after we fix all the bugs? Did we introduce new ones after fixing the old? Are all of our translations stoll appropriate? Where they ever?

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.

Personally I try to find work where:

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.

Spot on.

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.

I'm mostly a backend engineer, but I occasionally have to make UIs. It's not only that it's the hardest part of the stack (I agree with that, but it can also be an interesting challenge), it's also that it's the part of the stack where everyone and his dog think they have a say. It's infuriating really.

Thanks for this, my peers thought I was insane to move in the front end about 10 years ago (after having been in the industry for 10 years already).

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.

Yeah, agreed. Somehow CSS and a very general concern for UX have become my most valuable skills as a developer. I think the title of the article isn't correct. It should be "The Negative Impact of Responsive Design by People Who Aren't Good At It."

Indeed. It’s really a bummer that “frontend engineer” has more become synonymous with “react engineer”.

Thanks for saying so. I was a front-end developer for many years, and felt both the difficulty and the persistent lack of appreciation for that difficulty. I ended up quitting and just becoming a designer, because if I'm not going to get any respect, at least I shouldn't have to keep running on the treadmill of new technologies. I have also done back-end development, and it is certainly difficult in its own way, but for the money I'd rather work on that than the front end.

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.

I like the mental model and I have often witnessed the meddling you mentioned. My favorite kind of meddling: The current state of a software product is presented to C-Level. After listening (usually) for a few minutes one of the most senior people in the room starts expressing a strong opinion about how a certain color should be changed. Now the color scheme discussion starts. The complexity of enabling an interaction of a user with the software through the interface is not discussed at all. At least changing a color usually doesn't harm the usability too much.

They just feel like they should say something about it, and that's the low hanging fruit.

That's called bike shedding! People tend to avoid complex stuff as it's much easier to discuss the simple stuff

You've outlined it so well! "you're stuck between... 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.

You don't see the value add?

People have even gone all the way back and started writing inline styles again. (Tailwind)

Thanks for sharing. Do you still implement your own designs or "throw it over the wall"? Any tips on making the switch?

> Over the years it's become clear to me that frontend is probably the hardest part of the stack.

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.

I agree wholeheartedly that frontend work is very, very complex (and has only gotten more so in recent years), but I disagree it's the hardest part of the stack simply because you typically don't have to worry about scale.

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.

The frontend isn't done after the initial work. Requirements frequently change and update as management gets new ideas. Additionally, the frontend isn't spared from the concerns of scaling. You'll often be tasked with demands to decrease load from clients to help the backend keep up, which will involve lots of clever caching and tricks like debouncing. Finally, scaling on the backend isn't nearly as hard these days given all of the existing tech you can leverage like k8s and the cloud. Modern tech has only made the frontend harder as requirements have increased.

Let's see a show of hands: Who among us have had to worry about scale?

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.

Honestly that’s the reason I stayed in backend work. Frontend seemed to be too much like the English language- more exceptions than rules, only changing nearly constantly.

I’m grateful to those who have the patience and skill for it.

Generally speaking, interfacing with users is the hardest part of almost any program. Even when writing simple CLI tools, 80-90% of the code is often UI-related, even though it barely qualifies as an 'interface'. Flags, documentation, sanitization, reasonable error messages, type-checking and sanity-checking the inputs...and then, generally, a handful of lines of actual, useful code.

I think UI's are an inherently hard problem and HTML/CSS/JS are the completely wrong tools for the job. Every time I'm doing front end webdev it feels like I'm trying to hammer square blocks into round holes.

At a previous job I did (not tech related) I had to use some internal web app, and that thing was absolutely full of these mistakes, everything has padding, the text has padding, the box around the text has padding, the table row cotaining that box has even more padding.

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

This is pure for my information only.

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?

There are nice technical solutions. Media queries + flex + grid (when you need it) give you all the tools you need. There's just a lot of ways to do it wrong.

I use flexbox exclusively. My personal opinion is that if you're using media queries for anything other than "screen" vs "print" you're absolutely doing it wrong, in particular, media queries for screen size are a red flag.

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.

Thank you for your answer. I'm more curious about your approach. Would appreciate if you have some pointers in that direction. Like some sample/gist or blog posts etc.

Hope this helps. I used to do a lot of work in GTK's Glade and Qt's Designer. I was surprised how simple flexbox made it to just recreate those ideas in CSS.

https://jsfiddle.net/c16rwabo/1/

I know we all generally just do what the boss tells us but:

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

Frontend is complex. That's also why some people think the tech stack is "overly complicated". Deploying rich interactive user interfaces with the push of a button to the entire world is a marvel, why would people expect that to be easy anyway?

Yeah, but none of that's the hard part, the deploy to the entire world is the easy part. The hard part is that the entire UI system is designed around the premise of formatting XML based documents with modifier tags, even though that premise is completely wrong for most systems.

> You need someone with a deep knowledge of html, css, and the supportive web apis.

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.

> What's even more rare is a UX designer that also thinks about these things, who are worth a million bucks.

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.

User interface developers have always been less numerous and undervalued.

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.