You have 1 article left to read this month before you need to register a free LeadDev.com account.
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?
Let’s take a look at the industry first, before defining the job. In the good old days, front-end development involved catering to desktop browsers (mostly Internet Explorer), most of the websites were static pages with links here and there, with dropdowns and carousels if you’re feeling fancy. We only had HTML, CSS, and JavaScript to make those pages come alive, we used tables to align elements on the screen and used gifs to fake the “round border” effect on elements.
The setup of this was relatively straightforward: we’d have the back-end code in something like PHP or Java, we’d occasionally inject pieces of HTML, and include a few JavaScript files as a `script` tag at the beginning of the page.
Today, it’s much more interesting. JavaScript is widely used on the backend now, and TypeScript is widely used for front-end development. We can’t limit ourselves to the “browser” or “desktop” either. We have a whole zoo of devices and ways to access our applications. It’s also possible today to be a front-end developer that only focuses on developing tools that are used to build other tools.
The front-end knowledge we expect today
Let’s take a look at what we tend to associate with modern front-end development, on top of the good old “HTML/CSS/JavaScript” requirement that never went away.
TypeScript is a language on its own, and it’s basically a default for the web and beyond now. It brings the benefits of statically typed languages to what can be overly flexible and boundless JavaScript.
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.
Server-side rendering (SSR). Instead of injecting patches of front-end code into the backend, we can just run front-end code on the server itself. It’s still the front-end code, likely written in React and using other front-end libraries. It’s just executed on the server now first, instead of the browser. The browser sees only HTML, with small patches on JavaScript to make it interactive. Almost exactly as in the old days, just approaching it from a different direction and written with front-end tools and languages.
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.
Product engineer. These are people focusing on functionality, rather than visual components. They may be dipping their toes into the pure “backend” area, but might have no idea about CSS and animations. This is close to what we used to call “full-stack”, only the “stack” here is TypeScript or JavaScript.
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.
DevOps, delivery engineer, platform engineer. These people focus primarily on everything related to CI/CD, builds, and observability. They can sometimes be confused with DX engineers.
Conclusion
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 brings a new set of expectations, not only for HTML/CSS/JavaScript skills, but a deep understanding of TypeScript, linting, modules and bundling, CI/CD, testing, various front-end frameworks, npm packages, and monorepos.
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!
