The State of Frontend in 2022
Discover more from The Pragmatic Engineer
The State of Frontend in 2022
Analysis of The State of Frontend survey with 3,700 respondents. What engineering practices and technologies are gaining momentum in the field?
👋 Hi, this is Gergely with the monthly free issue of the Pragmatic Engineer Newsletter. If you’re not a full subscriber yet, you missed the deep-dive on Game development basics, the one on How Uber is measuring engineering productivity, and a few other issues. Subscribe to get this newsletter every week 👇
Two weeks ago, we dived into trends with native iOS and Android engineering and tried to answer the question where mobile engineering is headed. This week, we’ll circle back to frontend engineering, and follow up from a topic from February.
In February, I shared how, in collaboration with The Software House — a product development agency based in Poland — I was running the State of Frontend 2022 survey, writing:
“I’ll share my own in-depth analysis of the frontend world in the newsletter after the survey closes. I’d greatly appreciate your help by filling out this 8-minute survey.“
More than 3,700 people filled out the survey from 125 countries, and close to 1,000 respondents likely came from this newsletter. Thank you, if you helped! The results are out, and this is my analysis of the survey.
In this issue, we will cover the survey results:
Who filled out the survey?
How frontend engineers work
Engineering practices
Technologies used
Developer tools
Vendors
Much of this issue analyzes the results of State of Frontend 2022 and adds my own context.
Note that this issue can be too long to read in an email. Read the full issue online.
1. Who Filled Out the Survey?
3,700 respondents across 125 countries filled out the survey. The 5 countries with the most responses were the US, Poland, UK, Germany and India.
Surprisingly few engineers filling out the survey work at non-tech companies. Only 18% of people filling out the survey said they work at non-tech-first companies. 82% identified as working at a software development company, developer agency or a tech-first or digital-first company. It’s hard to tell if the survey didn’t reach people who work at more traditional companies, or if more engineers really are working at places where software is core to the business.
Either way, the survey results come overwhelmingly from places where tech and software are more of a profit than a cost center. Read more about profit centers vs cost centers at tech companies.
2. How Frontend Engineers Work
Remote work has been the biggest change in the past two years in software engineering. The rise of remote work should not be surprising, but how quickly it happened certainly is. A whopping 56% of respondents reported working remote, and 5% of respondents work only in the office. The concept of mass remote work is so new that the survey in 2020 did not even measure this data point.
The big question, looking ahead to 2023, is whether full-remote work will be here to stay, or whether hybrid work will gain more popularity. Most engineers clearly prefer working remote — there’s no commute involved, fewer taps on the shoulder. However, it remains a challenge to share information and replicate spontaneous discussions that have existed in the office.
Working within larger frontend teams is becoming more common. 27% of respondents reported working at a company with more than 50 frontend engineers. At the same time, 30% of developers shared how 5 or fewer frontend developers work at their company. 50% of respondents work at companies with 10 or more frontend engineers.
This statistic shows an interesting duality. There are almost as many frontend engineers who work at companies with massive frontend teams as there are ones working on few-person teams or alone.
The developer experience and the expectations at these companies are vastly different. Large companies will have developer experience and frontend Platform teams more often. Mentorship is more common. In smaller places, a lot more is down to each developer, and there are fewer options to get feedback.
As a frontend engineer, I’d recommend, over time, working in both environments to maximize learning.
The statistics of 50% of frontend engineers working at companies with 10 or more frontend developers and 27% of them at places with 50 or more could also be an interesting prompt for teams building tools for larger frontend teams. The number of these places seems to be growing.
Scrum and Kanban are more widespread, but less so at digital-first companies. For project management, 69% of respondents use Scrum or Kanban. Scrum at 52% is somewhat more common than Kanban — at 33% — and 17% of respondents use both. 2 out of 3 frontend developers use one of these two methods when completing projects.
Companies whose respondents did not report using either of these methodologies tend to be mostly tech-first or digital-first companies, which rhymes with findings in my article How Big Tech Runs tech projects and the curious absence of Scrum.
It’s not just frontend engineers who do frontend development. Here are some of the job titles shared this year by people doing frontend development :
Bootcamp student just starting out learning frontend
Self-taught developer studying at a non-technical university who fell in love with frontend
Product manager who sometimes pushes code to production
Developer advocate who helps out the frontend team every now and then
Frontend development architect
Design system director
A designer who also codes
Graphic designer and developer
Head of Everything: a one-person developer shop doing everything, including frontend development
This should not be surprising. But it’s always a nice reminder of how frontend is an accessible area and one where it’s still common enough to get involved without much frontend background.
3. Engineering Practices
Unit testing is widespread among frontend engineers with close to 75% of respondents writing these kinds of tests. Integration and end-to-end tests are also common, with about half of respondents having written these tests.
I’ll be honest: I was surprised to find that such a high percentage of survey respondents wrote unit tests. This is because while unit testing is a no-brainer for backend development — where all functionality is business logic, and thus unit tests are an immediate win — frontend engineering includes a lot of visual parts where unit tests are not a good fit.
However, frontends are becoming more complex and contain much more business logic. Also, as soon as more than a few engineers work on a frontend codebase, unit tests — and integration tests — are an easy way to reduce regressions in the codebase.
To me, the relatively high percentage of unit testing shows just how much frontend engineering is maturing. It also is an indication that frontend development is no longer about just the UI. We’ve moved well beyond the “HTML and CSS” parts, and most frontend developers are, in fact, software engineers building for the long term, with maintainability in mind.
Code reviews are common enough within the industry, with 80% of respondents mentioning they follow this practice. I was curious to find out, however, in what environments are code reviews done less frequently? There is strong connection between the size of the frontend engineering team and whether engineers do code reviews:
Engineers working at large companies are the least likely to not do code reviews. Engineers working at companies with 50 or fewer employees are twice or more as likely to not do code reviews than those working at larger companies.
One-person companies — understandably — are the most likely to not do code reviews.
This should not be surprising. The more engineers there are, the more value code review brings not just in spotting issues, but also in spreading knowledge better.
CI/CD - continuous integration and continuous deployment - is widespread within the industry, with 79% of respondents saying they use CI.
Still, I’m curious to see about a fifth of engineers who don’t use CI/CD when it has become increasingly simple to set up a CI pipeline to deploy code to production right after code has been merged into main. This can be done using solutions like GitHub Actions, GitLab CI, Vercel, Netflify and many others. Doing this makes sense even if you’re working on a solo project. It saves time from you having to manually deploy every time.
Once CI is in place, it’s then also straightforward enough to add a condition to only deploy if your tests are passing. Tooling for CI/CD has become much easier to set up in the past few years — and the fact that the vast majority of frontend engineers in this survey use these tools shows how far frontend engineering has come.
Not writing unit tests, not having CI/CD, and not doing code reviews are correlated. This was a very interesting finding of this survey. Taking these three activities:
Write unit tests
Have CI/CD in-place
Do code reviews
Engineers who do at least two of the above activities are almost certain to do all three.
This finding should not be a huge surprise, as these three tools are connected. CI/CD makes less sense when there are no automated tests to run. Most code review tools integrate seamlessly into CI/CD tools.
Still, this finding suggests that, by introducing unit testing and setting up CI/CD, code reviews will likely follow. Or, perhaps the other way: engineers who want to do code reviews tend to write tests and will set up CI/CD.
Engineering practices worth mentioning (which survey respondents brought up) are below. Use these as inspiration to try out other approaches, if you’ve not done so yet:
Trunk-based development
Feature flags and feature toggling
Pair programming
Linting
Code style guidelines
JSDocs
Stakeholders map
Design sprints
Prototyping
Semantic releases
“Fix-them-together days”
Visual regression tests
Extreme Programming
4. Technologies
TypeScript has become the de facto language of frontend engineering. If you are not using TypeScript, you are in the small minority of frontend developers, with 84% respondents having used the language last year:
Typescript showcases are a testament of why strongly typed languages make software engineers more productive: they result in fewer errors and regressions that can be avoided with a clean type system in place.
Statically typed programming languages mean that types of variables need to be known at compile time. This is usually done by the programmer declaring the type — for example, whether a variable is an integer or a string. Strongly typed languages are some of most widely spread: Java, C#, Go, C, C++, Haskell, Swift, Kotlin are all in this group — together with Typescript.
With dynamically typed languages, type checking takes place during runtime. Languages with dynamic types include Python, PHP, Ruby, and Javascript. Dynamically typed languages tend to be less verbose — thanks to types not being declared in the code — and can offer more freedom, utilizing types that will only be defined during runtime.
There is a difference between dynamically typed languages that are strongly typed at runtime, meaning that the compiler refuses to act with objects that are incompatible types. For example, it will throw an error if you try to add a string object to an integer one. Python and Ruby are both in this group. Statically typed programming languages tend to be strongly typed, enforcing types at compile time.
However, Javascript is an example of a weakly typed language, meaning that the language acts on objects with incompatible types, so it will add a string to an integer. The result will be an outcome that follows a set of inconsistent rules.
Those versed in mobile and backend development will be all too familiar with the benefits that statically typed languages have. Yes, they do come with a bit more upfront investment in specifying the types, but in return, typing helps avoid — it’s no wonder that the most popular languages on the backend, and on mobile, are all strongly typed: Java, C#, Go, Swift, Kotlin.
Python and Ruby are popular on the backend because, although they are not statically typed, they are strongly typed: if types don’t match, the runtime throws an error and halts execution.
One of the biggest problems with Javascript is that countless mistakes make it into production thanks to the weak type system. Typescript addresses this area in an elegant way — and it makes software engineers more productive.
As Marcin Gajda, frontend team manager at The Software House puts it:
“After far too many years of web development feeling laborious and painful, frontend developers don’t want to relive the experience of switching between the code editor and the browser back and forth multiple times to guess why ‘undefined is not a function.’”
Read more about Typescript findings
React is here to stay, and Next.js is on a meteoric rise. 76% of respondents said they used and liked React the past year, and 43% said the same about Next.js — whose framework is built on top of React. The popularity of Vue remains unchanged in this survey at 28% compared to 29% years ago. Svelte seems to be becoming less popular, with 22% of respondents saying they used and liked it, versus 33% from two years ago.
Axios, Lodash and Moment are some of the most frequently used frontend utilities. 61% of respondents said they used and liked Axios, a promise-based HTTP Client. Lodash is a utility library providing utility functions, making it easier to iterate arrays/objects/strings, manipulate and test values, and other neat addons. 46% of respondents said they used and liked it, while 20% said they used it and disliked it. Moment is a library to manipulate dates — 34% said they used and liked it, and 41% said they used and disliked it.
Redux is frequently used but generally disliked. Redux is a state container for JavaScript apps, which helps centralize the application state for complex projects. Surprisingly, more survey respondents said they used and disliked it (47%) vs those who used and liked it (37%).
The reason for these mixed feelings comes from Redux having a much higher barrier to entry in learning how to use it well. Also, building complex applications without proper state management is unwise to do. Redux offers predictable state management. However, in return, it demands you understand its opinionated approach to this problem space, using the View/Actions/State model and updating state in an immutable way.
Redux brings unfamiliar concepts to many frontend engineers, such as Action Creators, Reducers, Store, Dispatch and Selectors. While all of this might sound overly complex, complex mobile applications tend to follow the model that Redux enforces: making state changes in immutable ways. Learn more about Redux here.
5. Developer Tools
Visual Studio code won, with JetBrains a far second. The overwhelming majority of frontend developers use the free Visual Studio Code: a fast developer tool that comes with a very powerful extensions system:
And Visual Studio Code is not just winning among frontend developers: it’s the most popular development environment, globally, according to the Stack Overflow 2021 developer survey.
I can’t say I’m surprised, but this is because in 2007-2013 I was working on the Microsoft stack, using Visual Studio as my main editor, at the time when a license easily cost $1,500-5,000/year. Visual Studio was a great tool to use. However, I never quite appreciated just how much Microsoft was ahead in integrated development environments (IDEs) until I switched stacks.
In 2015, I started to develop iOS using XCode and could not believe how poor the environment was. I lost all my powerful tools like refactoring with one click, conditional breakpoints. Plus the performance of XCode was horrendous back in the day. Android development was not much better using Android Studio.
Jetbrains have consistently been building good IDEs. For example, while at Uber, we moved over from Android Studio to IntelliJ for Android development. However, even Jetbrain’s tools did not feel like they were on the same level of developer experience with Visual Studio — as far as 10 years earlier.
Microsoft quietly moved the best parts of Visual Studio into the free Visual Studio Code edition. While the company might have cannibalized its own Visual Studio market — why pay $1,500-8,000/year/seat for a Visual Studio subscription, when you can do so for free, with VS Code? The company has also positioned itself to be the #1 tool that developers use.
And Microsoft’s acquisition of GitHub has arguably made more of a reason to use VS Code. VS Code online works seamlessly with GitHub, providing a familiar IDE interface from within the browser. VS Code online will pose serious competition to CodeSandbox and StackBlitz, two popular online code editors among frontend engineers.
Some of Big Tech is also moving over to VS Code across software engineering. Facebook is a good example since the company moved over from Atom to VS Code as the company-wide preferred development environment. As I covered in Inside Facebook’s Engineering Culture:
“Visual Studio Code is the integrated development environment (IDE) most engineers use, currently. Facebook uses a customized distribution of this tool. It has built several internal plugins to make work more seamless. There is a push to make it a no-brainer tool of choice for all Facebook software engineers to use this tool by the end of 2022. As with all tooling, Facebook never requires engineers to use a specific tool, and this is no different to VS Code.
Before 2020, most Facebook engineers used Atom, especially those working with the www monorepo. Back then, Atom was the officially supported tool, especially thanks to the internally developed – and later open-sourced – Nuclide integration. Nuclide provided a first-class development environment for React Native, Hack and Flow projects.”
Eslint, Prettier and Webpack are the “default” build toolset for frontend engineers. Eslint is a static code analyzer that is easy to add to most code editors — may that be VS Code, IntelliJ or others. Prettier is an opinionated code formatter that works very well with JavaScript, TypeScript, CSS, HTML, GraphQL and Markdown. Prettier also supports all major code editors.
Webpack is a static module bundler that compiles modules — JavaScript/TypeScript files, CSS/SASS, Handlebars and many others—of your project to static assets. It discovers dependencies and does clever repackaging. The goal of Webpacka is to reduce runtime size and reduce latency of loading resources. Webpack has advanced capabilities like allowing dependencies to load asynchronously, at runtime, to reduce initial loading time.
One thing that’s surprised me is that less than 10% of all respondents have built and used their own custom solutions for developer tools. This is surprising since frontend engineering lends itself to hacking your own tools. However, it also shows that there’s so many tools for each common development problem and that it’s easier to use that tool — and contribute to it — if some features are missing.
6. Vendors
As usual, I am to be independent in my assessment of vendors. It is for this reason that I don’t accept sponsorships or disclose any affiliation. I have no affiliation with any vendors mentioned in this report and have not been paid to mention any of them. See more in my ethics statement.
Vercel is gaining significant momentum. In two years, Vercel has gone from 6% of respondents deploying their code to the service to 25% of respondents doing so in 2022. Vercel has just overtaken competitor Netlify in this space. With its current growth rate, it might become the most popular service to host frontends.
In what is a coincidence, I interviewed software engineers Malte Ubl in June, where he talked about his 11 years at Google and why he ended up leaving the Big Tech giant for Vercel, where he is now CTO. When asked about why he made the switch, Malte said:
“I then decided I was ready to go all-in on a problem space I’m excited about, and joined Vercel. I felt there is a multitude of untapped opportunities that can be transformative to help people write software better.”
In the interview, Malte talked about how he thinks edge computing is one of the most exciting things to come in software development, and how his work at Vercel will be around this:
“One of the most exciting things in tech is the move to Edge computing. Vercel, Cloudflare and other companies give the ability for clients to run code; not on the client, but very close to the client — therefore on the Edge.”
And, indeed, since Malte joined, Vercel kept innovating on Edge computing. Vercel launched regional Edge Functions on 20 October 2022 — allowing for even lower latency experiences than before, and the company continues to be an innovator in this field. This frontend infrastructure-level innovation coming from Vercel is interesting, as it’s exactly what I’d expect AWS or Cloudflare to be driving. However, neither AWS nor Cloudflare are embedded as much into the frontend community as Vercel is.
It’s interesting to see just how much momentum Next.js is gaining — the framework that Vercel built on top of React. Next.js has become the second most popular framework behind React, as per the survey.
Vercel capitalizing on the popularity of Webpack by building their own solution is an interesting - and logical - strategic move. At the end of October, Vercel announced Turbopack, which they described as a “successor to Webpack”, claiming it is 700x faster than Webpack and 20x faster than Vite. However, these statements turned out to be dubious at best, as later the creator of Vite unveiled how Vercel seemed to have cherry-picked an inpractical use case to come to this number.
Gatsby failing to increase in popularity, despite heavy funding, is a surprise to me. Gatsby is a static site generator and a startup that gained a lot of press through relatively large fundraising rounds. In September 2019, the company raised $15M in its Series A. Then in May 2020 it announced raising $28M as Series B funding in an effort to ‘become how the web is built.’
Still, despite more than $40M in funding, the framework is surprisingly unpopular. 17% of respondents said they used and disliked the framework, and 11% said they used and liked it. While 36% of respondents named Next.js as their favorite static-site generator, only 8% said it was Gatsby.
Gatsby seemed to have missed its window of opportunity to gain bigger traction: in 2020-2021, the static site generator was notoriously slow in generating sites, and this performance issue likely put off many developers. A good example comes from Netflify VP of development experience Jason Lengstorf who, in 2020, wrote:
“If we're not careful, some of Gatsby's magic can bite us by slowing our build times down significantly. And when I say ‘significantly,’ I mean significantly. We recently helped one of our customers with optimizing their extremely image-heavy Gatsby build and got this email back: ‘I was able to get the build times down from 4.8 hours to right around 10 minutes!’”
Gatsby seems to be in a difficult position. Its main competitor is Next.js. However, ‘Next.js’ is not a company: it is merely one product that Vercel builds, but Vercel makes its revenue off of hosting and infrastructure services. Gatsby has also invested into a global Edge network — making a play for the same business that Vercel is targeting. However, I see it as a strategic mistake to try to sell a performant infrastucture offering with a framework that is remembered for its slowness.
Unless Gatsby can pull an unexpected trick out of its hat, I’d expect the company to struggle to raise any future funding, and Gatsby could become more of a niche player than it already is.
AWS is popular among frontend developers, and GCP and Azure less so. An interesting comparison is looking at what cloud providers frontend engineers named as places they deploy their code, versus what software engineers said on the Stack Overflow Developer Survey in 2022:
AWS is the most popular destination both for frontend engineers and for most software engineers to deploy their code. However, fewer respondents in State of Frontend 2022 named Azure or GCP as a Platform they use, as opposed to the Stack Overflow Developer Survey.
My theory on the difference is twofold:
Vercel and Netfify have taken a large chunk of the frontend hosting market, and they could grow further.
Some frontend engineers don’t seem to know the Platform where they deploy their code, and this could especially be true for engineers working for clients. They do their work, and check in the code. Chances are that the code gets deployed on AWS, Azure, GCP, Vercel, Netlify or another vendor.
Takeaways
The full study comes with analysis on other topics. Experts in the field — like Kent C. Dodds — the cofounder of Remix — and Jay Phelps — web platform engineer at Netflix — give their opinions on various areas.
Frontend engineering has matured, but there are still a lot of changes and excitement. Looking through the results, the days of frontend engineers having to learn new web frameworks almost every year — which was typical in the 2010s — might be behind us. Just looking at web frameworks showcases this well enough.
React has taken the place of the most-used framework and has been holding stable for years. Vue, Svelte and Angular are all mostly unchanged in popularity — though all are trending somewhat downward. Next.JS has unexpectedly apparated from practically out of nowhere and is becoming the framework of choice for many engineers.
Mobile vs frontend is a topic few people talk about, but it’s top-of-mind for many engineering leaders. It’s still common to have three “frontend-related” engineering teams:
Web
iOS (native)
Android (native)
If CEOs had their way, there would be only one team: a ‘frontend’ team that builds one codebase, which then works as a website and an iOS and Android app.
In the roundtable discussing what might change in 2023 for frontend, I noted that I expect to see more of a push to have a “unified” frontend team, which might be building a web experience using React, and a unified app using React Native. Over time, I also expect smaller companies to overwhelmingly opt to have one team build their website and mobile app, while larger companies and Big Tech will keep highly specialized web and native mobile teams.
In a past issue, I dived into how the landscape of native mobile engineering is changing — and it’s similar to the lines above.
Microsoft becoming the silent enabler of web development is surprising. Across the report, 84% of web engineers use TypeScript (built by Microsoft), and 74% code with Visual Studio Code (also Microsoft). Stack Overlow’s Developer 2022 survey shares how 87% of developers use GitHub for personal use (GitHub is owned by Microsoft) and 55% for professional use, while 65% of developers use npm (also owned by Microsoft).
No other company comes close to being as integrated to the frontend developer’s life than Microsoft. The company is in a very strong strategic position, and I’ll be interested to see how Microsoft might utilize all the goodwill and attention it has acquired among software engineers in moving the industry forward, and helping their own business grow further.
I talked more about the findings of the State of Frontend 2022 report in this video, where I was joined by Sendil Kumar Nellaiyapen, my former team mate at Uber who is leading Uber’s web payments team Joel Albert, CTO at MCD Partners, and Marek Gajda, CTO and co-founder at The Software House. Watch it here.
What trends are you seeing in frontend engineering? Do they rhyme with findings in this survey? Leave a comment below with your observations.
Featured Pragmatic Engineer Jobs
Software Engineer at DevZero. $150-175K. Seattle, Washington.
Founding Senior Fullstack Engineer (JavaScript) at Playht. $150-200K + equity. San Francisco or Remote.
Senior Backend Engineer at Vital. $70-140K + equity. Remote.
Principal Backend Enginee at Pento. £120-135K. Remote.
Senior Backend Developer at Founda Health. Amsterdam, Netherlands.
Staff Software Engineer at Qualified.com. San Francisco or Remote.
Infrastructure Team Lead at Ometria. £90-150K. United Kingdom or Portugal.
Full Stack Engineer, Video & Messaging at BetterUp. Remote (US).
Staff Full Stack Engineer at BetterUp. Remote (US).
Founding Engineer at Complete. $160-205K + equity. San Francisco.
Senior Backend Engineer, Platform at Jock MKT. $140-200K + equity. Boston or Remote.
Software Engineer at Harver. €55-90K. Netherlands.
Founding Engineer at Zählerfreunde. €70-90K + equity. Munich or Remote (EU).
Engineering Manager at Highlight. $165-204K + equity. Remote (US).
Founding Engineer at Holidu. €90-110K. Munich, Germany.
Senior Java Engineer at SNOMED. £58-80K. Remote (UK, Germany, Denmark or Canada).
See more senior engineer and leadership roles with great engineering cultures on The Pragmatic Engineer Job board - or post your own.
Join The Pragmatic Engineer Talent Collective
If you’re hiring, join The Pragmatic Engineer Talent Collective to start getting regular drops of outstanding software engineers and engineering leaders who are open to new opportunities. It’s a great place to hire developers - from backend, through fullstack to mobile - and engineering managers and executives.
If you’re open for a new opportunity, join to get reachouts from vetted companies. You can join anonymously and leave anytime
You’re on the free list for The Pragmatic Engineer. For the full experience, become a paying subscriber. Many readers expense this newsletter within their company’s training/learning/development budget.
The State of Frontend in 2022
Some of the results, such as the percentage of people using Continuous Integration, surprised me. I can't say for sure but I have the suspicion that people confuse using a pipeline in a CI server with the practice of CI, which implies everybody integrating all their code/changes at least daily in the main branch.
I'm afraid, that less people than indicated are following this CI practice and that many simply refer to using jenkins/github actions or similar, while working using Feature Branches of several days duration.
In the DORA reports, in order to avoid these problems, they didn't ask directly if they did CI, but they asked how often they put all the code together in the main branch, or if each change triggered an automatic test suite or if they give priority to restore the build when there is an error.
I'd be interested in how UI dev is set-up in companies that have a shared frontend across teams, so central vs decentral vs hybrid setup and also how that plays together with UX people / Design System.