6 ms·

Over the years it's become clear to me that frontend is probably the hardest part of the stack. People think they can just shit out some bootstrap react app and

Over the years it's become clear to me that frontend is probably the hardest part of the stack. People think they can just shit out some bootstrap react app and it's perfect, 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. You need someone with a deep knowledge of html, css, and the supportive web apis. A good frontend engineer is incredibly rare, even at big tech. What's even more rare is a UX designer that also thinks about these things, who are worth a million bucks.

smokel 3y ago
The irony is that we are now all very enthusiastic about a text based user interface.
martin_drapeau 3y ago
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!
- dasil003 3y ago
  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.
  - ack_inc 3y ago
    Your comment made me curious: what kinds of insights have you seen BE folks miss due to not working closely with PMs and designers?
    - dasil003 3y ago
      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.
mumblemumble 3y ago
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.
- 128keaton 3y ago
  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.
- dimal 3y ago
  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.
  - BytesAndGears 3y ago
    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.
JodieBenitez 3y ago
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.
gedy 3y ago
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.
Julesman 3y ago
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."
ess3 3y ago
Indeed. It’s really a bummer that “frontend engineer” has more become synonymous with “react engineer”.
karaterobot 3y ago
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.
- hasoleju 3y ago
  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.
  - d0m3 3y ago
    That's called bike shedding! People tend to avoid complex stuff as it's much easier to discuss the simple stuff
Sohcahtoa82 3y ago
> 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.
njovin 3y ago
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.
- zeroCalories 3y ago
  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.
- specialist 3y ago
  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.
dundercoder 3y ago
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.
ertian 3y ago
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.
lispisok 3y ago
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.
yonatan8070 3y ago
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
wg0 3y ago
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?
- mmcnl 3y ago
  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.
- akira2501 3y ago
  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.
  - wg0 3y ago
    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.
    - akira2501 3y ago
      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/ https://jsfiddle.net/c16rwabo/1/
xormapmap 3y ago
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.
mmcnl 3y ago
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?
- yCombLinks 3y ago
  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.
squeaky-clean 3y ago
> 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.
datagram 3y ago
> 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.
specialist 3y ago
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.

smokel 3y ago

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

martin_drapeau 3y ago

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!

dasil003 3y ago
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.
- ack_inc 3y ago
  Your comment made me curious: what kinds of insights have you seen BE folks miss due to not working closely with PMs and designers?
  - dasil003 3y ago
    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.

mumblemumble 3y ago

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.

128keaton 3y ago
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.
dimal 3y ago
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.
- BytesAndGears 3y ago
  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.

JodieBenitez 3y ago

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.

gedy 3y ago

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.

Julesman 3y ago

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

ess3 3y ago

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

karaterobot 3y ago

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.

hasoleju 3y ago
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.
- d0m3 3y ago
  That's called bike shedding! People tend to avoid complex stuff as it's much easier to discuss the simple stuff

Sohcahtoa82 3y ago

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

njovin 3y ago

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.

zeroCalories 3y ago
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.
specialist 3y ago
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.

dundercoder 3y ago

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.

ertian 3y ago

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.

lispisok 3y ago

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.

yonatan8070 3y ago

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

wg0 3y ago

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?

mmcnl 3y ago
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.
akira2501 3y ago
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.
- wg0 3y ago
  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.
  - akira2501 3y ago
    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/ https://jsfiddle.net/c16rwabo/1/

xormapmap 3y ago

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.

mmcnl 3y ago

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?

yCombLinks 3y ago
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.

squeaky-clean 3y ago

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

datagram 3y ago

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

specialist 3y ago

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.