Front End Roles at Scale: Front End vs UI
When it comes website/web-app development, the typical way to approach it is to split it into two separate domains: front-end and back-end, to correspond with the client and server. So far this has worked well, and this paradigm doesn't seem to be changing any time soon.
Whilst there can be overlap between the front and back end, these days the front-end realm is deep enough to itself be considered a broad concept, so it warrants addressing how this concept could be split up into further separate domains with a goal of increasing productivity and software quality. Realistically, one person can only ever do so much to a certain standard, and to get the productivity and quality that is desired by so many, high attention needs dedicating to specialised areas, umbrella'd by the term "front-end". By not choosing to view the front-end realm as separate domains of equal importance, then the quality and productivity of the project is jeopardised, especially with larger projects.
It can be difficult to know how to separate the front-end into different areas without having any goals, and indeed the goals can differ from project to project based on numerous factors, but in general most projects would probably agree that their product should be:
- maintainable
- scalable
- flexible
- practical
- performant
- aesthetic
- user-friendly
- accessible
- secure
In order to achieve these goals in the front-end realm, many tools, technologies, concepts and ideas have evolved over time, but it's rare to find somewhere that achieves all these goals, and achieves them all equally well. These goals can be achieved by setting up and following the right processes and practices, and do not only have to be the result of teams consisting of superheroes.
The front-end realm may seep into the back-end realm in the form of API integrations and server calls etc, but whilst the front-end realm is being considered separate to the back-end realm, the "design/UX" realm also needs to be considered, as there is also plenty of overlap with the front-end realm.
This is where the term "UI" comes into play. The "UI" can be thought of as the visual "look and feel" of how content/data is presented and how it is interacted with by the user, and is essentially the bridge between the design/UX realm and the front-end realm, for all intents and purposes. The bridge between the front-end realm and the back-end realm can be thought of as the API; how data is retrieved from and/or sent to the server by the client.
With all these realms in mind, each realm might be responsible for delivering the following in a project, taking into account the goals laid out earlier:
- Design styleguide (design/UX)
- UI component library (UI)
- Application views (frontend)
- Back-end system (backend)
Whilst there's no real reason to assume a front-end developer can't maintain the UI component library whilst also being responsible for implementing it and integrating it with the backend API, the recommendation will be that they shouldn't. Essentially, the creation of the library and the implementation of the library will be considered separate roles undertaken by separate people.
As well as all the other goals previously laid out, several other considerations also need to be taken into account when creating a UI component library:
- Adheration to design styleguide
- Prototype implementations of components
- Conduct user-research on prototypes
- Documentation of components
- DX of components
- Testing of components
Not taking into account that these considerations all require specific skills and disciplines (though it's an important point to note), arguably satisfying all of these considerations to a high standard is a full-time job in and of itself simply down to how long it would take. This is why third-party UI component libraries are so popular; they offer an out-the-box solution to something that should otherwise require another employee.
From this, the conclusion is that a UI developer is someone who builds/maintains a UI component library, creates prototypes and works closely with design/UX, whereas a client-side developer/front-end API developer is someone who integrates the component library with the backend API, and works more closely with the back-end developers. Remember that this separation of concerns with regards to front-end development is recommended to allow a team to be as productive as possible in a normal working schedule, and predominantly affects larger teams/projects.
Whilst the separation of the UI is perhaps the most significant, there are still other concerns with regards to front-end development that also have arguments for them to be considered full-time jobs as well. Some common time-consuming tasks of front-end developers include:
- Create local development environment
- Create build scripts etc.
- Review code
- Deploy code/CI
- Project architecture
- Solution architecture
- Ensure code is secure
- General debugging
These can be thought of as "operational" tasks, and form the "Front-End Ops" domain. Again, in order to satisfy the goals previously laid out, and in order to achieve some of the above tasks to a high standard, then it could arguably require the work of a full-time job to act as a sort of "front-end gatekeeper", taking ownership of the above operations.
In summary, the tangible roles that have been recognised to encompass "front-end development" at scale are:
- Create/maintain UI component library/styleguide
- Prototype implementations of components
- Conduct user-research on prototypes
- Documentation of components
- DX of components
- Testing of components
- Create container components
- Integrate UI components
- Handle implementation of backend API
- Handle implementation with CMS
- Contribute to component library & ops
- Create local development environment
- Create build scripts etc.
- Review code
- Deploy code/CI
- Project architecture
- Solution architecture
- Ensure code is secure
- General debugging
A toolkit for architecting and constructing modular front-end user-interfaces
Github | NPM | Homepage | Wiki
A front-end framework for creating modular, configurable and scalable UI components
Interact with DOM elements that follow the Synergy naming convention
A set of Higher-Order Components for rendering UI elements that follow the Synergy naming convention
Style DOM elements that follow the Synergy naming convention (including BEM) using JavaScript
A UI grid-system for React applications, styled with Polymorph
Style DOM elements that follow the Synergy naming convention (including BEM) using Sass