The responsibilities we once considered fundamental for front-end developers are changing rapidly. Here’s where we see the role going in 2023.
Times are changing. Fast.
In the last 10-15 years of front-end development, we have managed to transition from HTML with a few dropdowns on JQuery, to full-on Single Page Applications, where the entire logic of the web experience is written on the frontend, and the backend is a very thin layer that mainly handles authorization and fetching data from the database.
To make things even more interesting, the rise of server-side rendering (SSR) and serverless architectures could transition us back to where we started: a world where the code is returned to the server. Except, there might be no “server” anymore, at least as we know it today, and it might be the responsibility of front-end developers to write the code, for the most part.
How do you define a front-end developer?
The front-end knowledge we expect today
Linting and other code safeguards. We expect people to know and use tools like Prettier and eslint/tslint, know why we need them, how to set them up, how to run them, and how they work.
Modules and bundling. We don’t write our code in a single file that is manually connected via the “script” tag anymore. Instead, we write it in smaller modules, and then our build tools assemble that file(s) for us. We expect people to know the tools and concepts that allow us to do that, such as ESM/CJS modules, bundling, webpack/esbuild, code splitting, and asynchronous loading.
Builds and CI/CD. We don’t manually upload that file anymore either. Instead, we now have continuous integration/continuous delivery systems (CI/CD), and we expect people to know how they work, what they do, and how to operate them.
Testing. Front-end code is still code, so we expect test coverage for it, know different types of testing (unit tests, integration tests, end-to-end tests), know tools for that, and actually write them.
Advanced CSS. Nobody writes “pure” CSS anymore – it has too many disadvantages, especially at scale. Instead, we have a whole zoo of methods and tools here: SASS, CSS modules, CSS-in-JS, Tailwind, etc.
Front-end frameworks. React is dominating the field here, but there are others like Vue and Svelte emerging. If you want to write truly interactive interfaces, then these are almost unavoidable because they abstract away the complexities of dealing with the state, data, cross-browser access to DOM, and updating data there “on-the-fly”.
npm, packages. Those are a way to share code openly: any library that we use now is a package that we download from npm. If you’re coming from the Java world, those are the “maven” of the modern frontend.
Monorepos. Monorepos come in and out of vogue periodically. It’s a way to organize code into packages within the same repository, with tools like Lerna or Turborepo helping here.
Serverless. Instead of running a traditional backend/microservice, we can now just write a simple function that service providers like Amazon Web Services (AWS) can run independently on schedule, or in response to an event. The backend as we know it shrinks completely and may not even exist anymore in certain types of apps.
GraphQL. A very flexible way to fetch only the data that is needed at the moment, as opposed to the traditional REST API, where you always have the entire set.
Front-end “full-house” solutions. Setting up everything from the above (and more) from scratch is complicated. Solutions like Nextjs or Remix abstract those complexities away, so that developers can focus on writing customer-facing code instead.
Accessibility. We want (and sometimes are required by government regulations) our apps to be accessible to people who are color-blind, visually impaired, unable to use a mouse or keyboard, and so on.
Observability, analytics, monitoring. We want to be able to see what is happening with our app when people use it, so some familiarity with these concepts and associated tools is a must now.
How to navigate all of this
The above list is not a comprehensive one of course. But I hope it gives an idea of what we see as comprising front-end knowledge today and why I think that the front-end developer role is harder than ever to define.
Instead, it’s time to be explicit about specialization when hiring and considering a future career. For the sake of simplicity, those career paths can be roughly broken down to:
UX, user experience engineer, UX developer. These are people who are focusing exclusively on delivering visual experiences that are loved by the user. They will be serious about design, have a good sense of aesthetics, and know what works from a visual perspective. This is probably the closest to the traditional front-end role.
DX, developer experience engineer. These people never come into contact with customers, or rather, developers are their customers. Not to be confused with product engineers, who just develop user-facing experiences for developers. This one is focusing on developing tools that other developers use to build products.
By now it is clear that the role of a front-end developer has changed dramatically, evolving from just HTML and JQuery, to complicated SPA applications that contain most of the business logic, and now, perhaps even a transition back to a server-side rendering world.
This bears thinking about both when hiring or considering a future career path, where it is highly advisable to think about what kind of specialization you’re actually looking for, rather than trying to cover such a broad spectrum of skills and knowledge.
If you're interested in reading more about front-end topics, check out my front-end development blog, Developer Way!