6 ms·

I think the issue that the article skirts around is that front-end work involves UI design and styling. So sure, both involve using sophisticated modern program

I think the issue that the article skirts around is that front-end work involves UI design and styling. So sure, both involve using sophisticated modern programming languages etc, but the presence of visual styling work is unique to the front end and specifically what a lot of back end programmers feel they are unable to contribute to. I know that many javascript engineers feel similarly about their design and styling skills, but still, in my opinion the presence of UI design and styling in frontend work is the main contributor to the cultural/team separation.

Silhouette 6y ago
We have been rendering HTML and adding styling from the back end since long before JS was cool... I think the real distinction here is between programming and interface design, which are also separate skills that any given person might or might not have, but that is true whether they happen be coding for the front or the back end at the time.
- d--b 6y ago
  Well depends what you call "backend", I tend to think of it as the business code that the interface operates with. Namely the API. I work in finance, so there the backend consists of gathering data and applying statistics on it. The frontend is a presentation of the data and a way to interact with it. The webserver code that renders web pages definitely belongs to frontend dev.
  - Silhouette 6y ago
    Personally I would call code running on the user's device the front end and code running on some server or other remote device the back end. YMMV. Maybe this explains the difference in our perspectives. To me, other than perhaps the very first data collection where maybe the source is only accessible from the back end, whether things like statistical analysis or rendering of the results happen on the front or the back end is something you will decide on its merits for each project, not something that is necessarily tied to the mechanical programming skills or libraries on one suffer or the other.
    - deleted 6y ago
      [deleted]
    - bcrosby95 6y ago
      This would mean server side rendering is back end development. Traditionally working in templated languages was considered a front end job despite being translated server side.
      - Silhouette 6y ago
        Perhaps, but once you start generalising there are lots of grey areas and overlapping possibilities, which I suppose is my main point here. For example, say you're working on a web app that controls some device. On the back end, you might not be talking to a database, at least not in the sense of SQL or NoSQL we usually mean in the context of web apps. Maybe instead you're integrating with some internal API that controls the hardware. In that situation, maybe you're exposing that internal functionality to the front-end web app via some HTTP-based API, which might be substantial but is mostly a wrapper for the internal functionality with things like security incorporated. Who should be responsible for that middle layer? Do you have a separate person/team whose responsibility is just to bridge between the front-end code and the internal API? Should the person/team responsible for the front-end also be responsible for the HTTP-based API it talks to, and hand off to some other person/team who work on the hardware-facing code behind the internal API? Should the internal team also be responsible for the HTTP-based API? I don't think there are any "right" answers in a situation like this. You probably have people with front-end skills. You probably have people with low-level hardware hacking skills. Some or all of those people might also have back-end skills. You've certainly got three distinct but related areas here. Depending on the project and the mix of people you have available, there are several potential ways to handle this situation that might be effective.
jmchuster 6y ago
I think of UI/UX designer as kind of a distinct role from programming. Sure, if you don't have any designers, then your frontend person is also your designer, so in that case, it makes sense that their job is distinct from backend. The opinion I've adopted from my designer friends, though, is that once you have a designer in-house and the site's basic design has been established, what is more important is that the developers notice and care about details. That's not something I would consider a frontend vs backend developer trait, just more of a general engineering attitude. Do you notice that the padding here doesn't match up, do you question why this form is laid out differently from all the other ones, how does this flow from page to page work, do you go find a designer and work with them until it's right. I would posit that the same person who cares that the UI is consistent and makes sense would also be pointing out why is our code formatting all over the place, why we use different libraries in different places to do the same thing, why our patterns and architecture is inconsistent. If you just copy/paste in random UI pieces and call it done, then you're probably also copy/pasting in random stackoverflow snippets on the backend and just recompiling until the tests pass.
- Myrmornis 6y ago
  OK but my understanding is that modern approaches to client side JS are based around the concept of web components. In which case, even though the JS code encompasses many areas of software engineering (data flow, dealing with asynchronous events, MVC-like architectures to achieve separation of concerns etc) there is no escaping the fact that part of your code is directly representing a DOM which is rendered as a UI. So I'm not sure I believe that client-side JS can really be divorced from the design of the UI. Sure, the CSS can be done by someone else, but the choice of components that exist in the (virtual) DOM is necessarily very much part of the UI design isn't it?
  - jmchuster 6y ago
    Right, that's why designers generally work with a component library, in an application like Sketch that is designed for building websites and mobile apps. Your component library might first start off with just all the basic HTML stuff, but that eventually becomes tailored to your company's own custom stuff. You're not just hiring abstract artists who then whip up a fever dream in photoshop.

Silhouette 6y ago

We have been rendering HTML and adding styling from the back end since long before JS was cool... I think the real distinction here is between programming and interface design, which are also separate skills that any given person might or might not have, but that is true whether they happen be coding for the front or the back end at the time.

d--b 6y ago
Well depends what you call "backend", I tend to think of it as the business code that the interface operates with. Namely the API. I work in finance, so there the backend consists of gathering data and applying statistics on it. The frontend is a presentation of the data and a way to interact with it. The webserver code that renders web pages definitely belongs to frontend dev.
- Silhouette 6y ago
  Personally I would call code running on the user's device the front end and code running on some server or other remote device the back end. YMMV. Maybe this explains the difference in our perspectives. To me, other than perhaps the very first data collection where maybe the source is only accessible from the back end, whether things like statistical analysis or rendering of the results happen on the front or the back end is something you will decide on its merits for each project, not something that is necessarily tied to the mechanical programming skills or libraries on one suffer or the other.
  - deleted 6y ago
    [deleted]
  - bcrosby95 6y ago
    This would mean server side rendering is back end development. Traditionally working in templated languages was considered a front end job despite being translated server side.
    - Silhouette 6y ago
      Perhaps, but once you start generalising there are lots of grey areas and overlapping possibilities, which I suppose is my main point here. For example, say you're working on a web app that controls some device. On the back end, you might not be talking to a database, at least not in the sense of SQL or NoSQL we usually mean in the context of web apps. Maybe instead you're integrating with some internal API that controls the hardware. In that situation, maybe you're exposing that internal functionality to the front-end web app via some HTTP-based API, which might be substantial but is mostly a wrapper for the internal functionality with things like security incorporated. Who should be responsible for that middle layer? Do you have a separate person/team whose responsibility is just to bridge between the front-end code and the internal API? Should the person/team responsible for the front-end also be responsible for the HTTP-based API it talks to, and hand off to some other person/team who work on the hardware-facing code behind the internal API? Should the internal team also be responsible for the HTTP-based API? I don't think there are any "right" answers in a situation like this. You probably have people with front-end skills. You probably have people with low-level hardware hacking skills. Some or all of those people might also have back-end skills. You've certainly got three distinct but related areas here. Depending on the project and the mix of people you have available, there are several potential ways to handle this situation that might be effective.

jmchuster 6y ago

I think of UI/UX designer as kind of a distinct role from programming. Sure, if you don't have any designers, then your frontend person is also your designer, so in that case, it makes sense that their job is distinct from backend. The opinion I've adopted from my designer friends, though, is that once you have a designer in-house and the site's basic design has been established, what is more important is that the developers notice and care about details. That's not something I would consider a frontend vs backend developer trait, just more of a general engineering attitude. Do you notice that the padding here doesn't match up, do you question why this form is laid out differently from all the other ones, how does this flow from page to page work, do you go find a designer and work with them until it's right. I would posit that the same person who cares that the UI is consistent and makes sense would also be pointing out why is our code formatting all over the place, why we use different libraries in different places to do the same thing, why our patterns and architecture is inconsistent. If you just copy/paste in random UI pieces and call it done, then you're probably also copy/pasting in random stackoverflow snippets on the backend and just recompiling until the tests pass.

Myrmornis 6y ago
OK but my understanding is that modern approaches to client side JS are based around the concept of web components. In which case, even though the JS code encompasses many areas of software engineering (data flow, dealing with asynchronous events, MVC-like architectures to achieve separation of concerns etc) there is no escaping the fact that part of your code is directly representing a DOM which is rendered as a UI. So I'm not sure I believe that client-side JS can really be divorced from the design of the UI. Sure, the CSS can be done by someone else, but the choice of components that exist in the (virtual) DOM is necessarily very much part of the UI design isn't it?
- jmchuster 6y ago
  Right, that's why designers generally work with a component library, in an application like Sketch that is designed for building websites and mobile apps. Your component library might first start off with just all the basic HTML stuff, but that eventually becomes tailored to your company's own custom stuff. You're not just hiring abstract artists who then whip up a fever dream in photoshop.