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.

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?

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.

Ok, so in the setup you describe can the js engineers focus on software engineering and not be involved in the choice of components and UI layout design? I.e. they can have all that handed to them by a designer? I didn’t know that, in my experience the JS engineers also design the UI layout (but have designers work on CSS styling )

The recurring theme in this whole discussion is "it depends", and that is the case here as well.

If you're building a relatively simple UI, using common features like buttons and text boxes and maybe some simple charts, you might well do what has been mentioned in this thread. You can identify reusable pieces that the designers can use to define layouts and specify styling and that the programmers can use to implement those things in code. This is an easy method of UI design and implementation, and often it is all you need.

If you're building something more challenging -- a rich document editor, a game, an interactive 3D visualisation of a complicated data set, basically anything that isn't just a combination of standard controls and UI patterns -- then the main part in your UI might not fit that component model very well at all. Now you're going to have to approach both the UI design and the programming from a different direction, just as you would in desktop, mobile or embedded software. This is harder, because you're moving away from patterns and tools that are well understood and readily available, and instead you're building something original. However, it's also much more flexible for the same reason, and sometimes that's what you need.

Even in the latter case, you will often need standard features in your UI that can be designed and built as individual components as well. There's no rule that says you can't have a hybrid with both reusable components for the simpler, recurring features and then one or more features that are more sophisticated.

So, if you start off with something new or large, your UI/UX designers would be the ones driving all the work. Then once you're working on something established, then your developers might suggest components based on common patterns they know, and then ask designers to validate it. And then once you're adding trivial things, like another field to a form, you wouldn't involve the designer at all.

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.

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.

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.

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.

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.