state of 2024

The third edition of the biggest frontend report.

Now, with expanded data for versatile insights.

6028

responders

139

countries

23

experts

State of Frontend 2024

Chapter 1:
Introduction

Welcome to the State of Frontend 2024 report – third time the charm!

Aleksandra
Dąbrowska

Report’s Editor-in-Chief

The frontend universe in the post-pandemic world seems to be doing alright, but it is not without reminiscing about the good (not-so) old times when the world had to move online, new tech projects were overflowing, and waves of funding were high. Now, the industry seems to have shaken off the glitter of the gilded era and entered a phase of practicality and simplicity.

Wondering how this influenced the daily work of frontend teams, we decided to expand the report’s scope and ask more detailed questions (while hoping for the grace of our participants, who had to put more time in to complete the survey). Some sections are new (AI, a11y), and some mark our evergreen staples. So, if possible, we compared data from The State of Frontend 2022.

Report in numbers

6028

responders

139

countries

23

experts

This edition is our most comprehensive survey yet, with 6,288 responses from developers, engineers, and tech enthusiasts across 139 countries.

Our community spans the globe, with the largest number of responses coming from countries like the USA, Poland, Germany, and France. We’re also thrilled to have heard from individuals in places as diverse as Andorra, the Maldives, Mauritius, Senegal, and Guinea-Bissau—where a single yet equally important voice represented each country. We are extremely grateful and send a big thanks to each and every one of you who took the time to fill out the survey. Without your experiences, we couldn’t create this resource for the community, helping us understand where frontend development is headed.

Regarding industry affiliations, IT services led with 29.7%, followed by finance, banking, and fintech (13.9%) and retail and e-commerce (11.6%). Other notable sectors included entertainment, healthcare, and education. Beyond these major industries, there was significant diversity, with 13% of respondents falling into the “Other” category. This group represented a wide array of fields, including consultancy, marketing, art, AI, nonprofits, agriculture, blockchain, environmental services, aerospace, defense, and game development. The breadth of industries highlights the growing role of frontend development, reaching not only traditional tech areas but also specialized sectors.

What is your industry?

IT services 29.7 %

Finance, banking, fintech 13.9 %

Retail, e-commerce 11.6 %

Entertainment, media 6.6 %

Healthcare 5.5 %

Education 5 %

Transportation, logistics 4.2 %

Manufacturing 2.7 %

Telecommunications 2.6 %

Real estate 1.6 %

Travel 1.5 %

Legal, law 1.3 %

Events 0.8 %

Other 13 %

source: tsh.io/state-of-frontend

Such valuable data required professional treatment. This year, we consulted with 23 industry experts to dive deep into the trends, challenges, and innovations shaping the world of frontend development. We hope their interpretations of survey results and thoughtful commentary will give you new perspectives and ideas to implement daily. Give them some love by clicking on their links and following them on social media! 

Finally, we’ve got a surprise for you—at the bottom of the page, you’ll find the State of Frontend 2024 for Tech Managers. We asked 260 C-levels and tech managers additional questions about the business side of the frontend industry. They shared the biggest frontend challenges for the upcoming year, initiatives they’re undertaking, painpoints in modernizing/updating/rewriting their apps and hiring specialists to their teams. 

Since technology and business work hand in hand, we hope this extra knowledge brings us closer to the big picture of the state of the frontend in 2024.

Chapter 2:
NEW! Edition for tech managers

New! Edition for tech managers

The State of Frontend 2024 offers insights into new technological topics and a completely different business perspective. We have asked C-level executives about their attitudes towards organizing the work of frontend teams and keeping up with the constant technological changes.

You are very welcome to download a copy by filling out the form below.

Discover the perspective of 260 C-level executives on the current frontend affairs.

40%

simplify their applications to boost performance rather than introduce new features.

25.9%

plan to modernize their applications with React (and related ecosystems).

68.9%

want to introduce AI, mostly for developer support (e.g., code assistants).

68%

cite a lack of available skills as the main hiring pain point.

Fill out the form to download the business report:

Only updates about new interviews. Privacy policy.

Chapter 3:
Teams & Technology

Chapter 3.01:
Team composition

What is your position?

Full-stack Developer 33.5 %

Senior Frontend Developer 32.2 %

Mid Frontend Developer 20 %

Junior Frontend Developer 10.1 %

Backend Developer 1.5 %

Quality Assurance 0.1 %

Other 2.7 %

source: tsh.io/state-of-frontend

How many people are there in your company?

10-99 29.8 %

more than 1000 21.1 %

100-199 11.2 %

200-499 10.9 %

less than 10 10.7 %

I'm a freelancer 9.4 %

500-999 6.9 %

source: tsh.io/state-of-frontend

Which of the following best describes your company?

Software development services 44.6 %

Tech-first/Digital-first product 39.8 %

Non-tech-first company 15.6 %

source: tsh.io/state-of-frontend

How do you work?

Only remotely (home office) 44.5 %

Hybrid 42.7 %

Only on-site (office) 12.8 %

source: tsh.io/state-of-frontend

How many years of experience with frontend technologies do you have?

3-5 years 31.1 %

6-10 years 27.8 %

Over 10 years 25.5 %

1-2 years 12.9 %

Less than a year 2.7 %

source: tsh.io/state-of-frontend

What other roles are included in your development team?

Backend developers 69.6 %

Project managers 62.3 %

Full-stack developers 61.9 %

UI/UX designers 61.1 %

QA specialists 38.7 %

Business analysts 24.6 %

Scrum masters 22.5 %

Other 13 %

SEO specialists 9.3 %

source: tsh.io/state-of-frontend

Which roles, other than frontend development, do you feel comfortable with?

Backend developer 70.7 %

Designer 31.3 %

QA specialist 26.4 %

None of the above 11.6 %

SEO specialist 10.4 %

Business analytic 9.3 %

Other 8.4 %

source: tsh.io/state-of-frontend

Seniority, remote work, and the full-stack developer boom
Andrzej Wysoczański – SOFE 2024

Andrzej
Wysoczański

Head of Frontend at The Software House

At last, the numbers are beginning to reflect the shifts in how modern teams are structured. Remote work (44.6% for remote and 42.6% for hybrid) has firmly established itself. Despite efforts by some large companies to bring employees back to the office, most workers continue to operate remotely. We’ve adapted to this way of working so well that reversing it now seems unlikely. Remote work is no longer a temporary fix; it’s become a cornerstone of how teams function today.

Another significant change we’re witnessing is the rise in seniority among developers – 32.2% senior and 20% mid-developers. Young programmers have made the most of the opportunities presented to them, quickly advancing in their careers and joining the ranks of their more seasoned colleagues. It is encouraging to see the next generation stepping up, taking on more responsibility, and solidifying their place in the industry.

But what I find most exciting—and something I’ve been eagerly anticipating—is the evolving role of frontend developers. The old days when frontend devs were confined to working on just one layer of an application are fading away. Today, developers are entrusted with broader responsibilities, which is fantastic news. It’s no longer just about the frontend; developers are increasingly required to handle different stack layers. A frontend developer who can also contribute to backend development and is accountable for their work through testing? Absolutely!

However, one trend that surprised me is the relatively low number of projects involving dedicated QA teams—only 38%, according to recent data. This is a telling sign of where the industry might be headed and raises an intriguing question: Are we on the brink of a return to a more holistic role for web developers, where they handle everything from coding to testing? It’s too early to say with certainty, but the direction we’re heading in suggests that the industry is undergoing a transformation. It’s shaping up to be a very meaningful one.

In short, we’re seeing the rise of more versatile developers, increasingly responsible for the full lifecycle of their work, while the traditional roles and structures within teams are becoming more fluid. This evolution could lead to a more integrated and dynamic future for software development.

Chapter 3.02:
Frameworks

Which frameworks have you used in the last year?

Alpine.js
Angular2+
Angular.js
Ember
HTMX
Lit
Phoenix
Preact
Qwik
React
Svelte
Vue.js
Used and liked
Used and disliked
Want to learn in the future
Not interested
No opinion
7 %
1.9 %
9.2 %
35.6 %
46.3 %
22.1 %
12.8 %
8.3 %
39.4 %
17.4 %
6.7 %
19.3 %
7.2 %
49 %
17.9 %
3.3 %
4.1 %
4.8 %
50.7 %
37.2 %
7 %
2.5 %
36.4 %
27.3 %
26.7 %
6.5 %
2.5 %
14.4 %
32.2 %
44.5 %
1.8 %
0.5 %
9.8 %
34.2 %
53.7 %
9.7 %
3.6 %
16.5 %
35.4 %
34.8 %
4.1 %
1.5 %
24.3 %
29.7 %
40.4 %
69.9 %
15.4 %
7.1 %
5.4 %
2.2 %
25.8 %
3.5 %
43.6 %
12.9 %
14.2 %
44.8 %
8.6 %
24.4 %
13.1 %
9.1 %

source: tsh.io/state-of-frontend

Which rendering frameworks have you used in the last year?

Astro
Docusaurus
Gatsby
Next.js
Nuxt
Remix
SvelteKit
Used and liked
Used and disliked
Want to learn in the future
Not interested
No opinion
25.2 %
2 %
29.9 %
13.6 %
29.3 %
8.7 %
3.2 %
12.9 %
27.2 %
48.1 %
9.4 %
14.2 %
9.4 %
33.5 %
33.4 %
52.9 %
13.8 %
15.3 %
8.6 %
9.3 %
26.5 %
4.8 %
20.8 %
21 %
26.9 %
12.5 %
4.2 %
29.9 %
22.2 %
31.3 %
17.4 %
1.9 %
35.1 %
17.4 %
28.1 %

source: tsh.io/state-of-frontend

Change can often be easier to see the further it is in the rearview mirror

Brian
Rinaldi

Developer Relations Lead at LocalStack / LinkedIn

2023 may look like very little has changed from 2022. React, and Next.js remain the most dominant framework and rendering framework combinations by far. There’s little to indicate this will change in the near term. React remains the de facto framework for web development and continues to improve, with features like React Server Components (RSC) and Actions coming in React 19. Next.js is the de facto full-stack framework for building React applications (Remix is making small but slow inroads, while Gatsby seems to be on life support).

However, in retrospect, we may look back at 2023 and see the seeds of impending change. For example, Astro, which barely registered in last year’s results, is (considering the margin of error) tied with Nuxt for second place among rendering frameworks while retaining very low negative sentiments and very high interest. I fully expect Astro to continue to grow rapidly.

A similar story could be said about SvelteKit, which has grown quickly and is of extremely high interest. Though the latter didn’t make this list, other frameworks and rendering frameworks like Qwik and SolidJS have also been getting much attention across the web development community.

For years, it seemed (to me, at least) that we were stuck in a paradigm where React/Next.js continued to grow rapidly, and the only real viable alternatives were Vue and Angular. There was very little to challenge the traditional single-page application (SPA) way of building web applications. Tools like Astro, SvelteKit, Qwik, and SolidJS bring fundamentally different approaches to web development from this traditional React/Vue/Angular paradigm. That’s not to say that these frameworks will necessarily dethrone React/Next.js. Though it’s possible, we’re also already beginning to see how their unique approaches – things like islands and reusability, for instance – are impacting the direction of React/Next.js.

React's reign continues
Umma Gohil – SOFE 2024

Umma
Gohil

Senior Software Engineer at Deloitte Digital / LinkedIn

With an overwhelming 69.9% of respondents stating they were using React, it’s no surprise it takes the top seat. React goes from strength to strength; we see the community adopting new approaches to building different solutions, whether progressive web apps, server-side rendered apps, single-page apps, or static websites. Its dominance in the marketplace has meant frameworks such as Next.js have also surged in popularity. The framework enables users to work across the stack with its rich ecosystem of server-side rendering, routing, and early adoption of React 19 features, proven to have excellent performance and scalability for various solutions. 

Vue.js, which uses the MVP design pattern, has proven to be a strong contender alongside React, with 44.8% of respondents telling us it was their choice of framework. Nuxt pairs nicely with Vue.js, proven by 52.9% of respondents telling us it’s their rendering framework of choice.

Although these are popular frameworks of choice, we see a shift in the community regarding what they want to learn next. Svelte is gaining much traction from developers, with 43.6% wanting to learn it, followed by HTMX and Qwik. 

Alternatives to what’s popular 

Of course, these are not the only choices available to developers. Astro is a strong contender for many developers, providing various features such as static site generation, server islands, and the ability to integrate interactivity just where you need it within your application. With its flexibility, Astro is a great choice for many applications, and the integration between different frameworks is a fantastic bonus. 

Remix is also starting to gain more traction. With its ability to leverage SSR and enable developers to focus on utilizing best practices with web standards, we are beginning to see more of the community take it more seriously. Its ability to put DX hand in hand with SSG is proving great for developers looking for solutions that scale and perform well when building accessible UIs. One to watch out for. 

A shift in the community

Although React and Vue.js are popular frameworks of choice, developers had some other interesting choices:

  • Svelte is gaining a lot of traction from developers. 43.6% want to learn it, followed by HTMX and Qwik. I’m looking forward to seeing what happens with Svelte’s growth. Given that many developers in the community are learning it, it’s one to watch. 
  • We see a lot of disinterest in Angular.js and Ember, with 49% and 50.7% of respondents telling us so, respectively. 
  • There seems to be a lack of familiarity or relevance with the usage of Phoenix and Ember, signaling potential areas of growth or reconsideration from developers in the future. 

Problems frameworks are solving 

With React becoming the foundation for many web applications, I have noticed the incorporation of several features that help with performance, accessibility, and user experience. With the rise of full-stack frameworks, I am excited to see fewer spinners and blazing-fast performance, with more focus on building accessible solutions. 

I believe these React frameworks will continue to be popular because they make it easy to spin up an app, play around with SSR features, and build a feature-rich application with the latest library features.

Vue.js is great for building applications that require a more traditional approach with MVP. We have seen the community adopt some great solutions with the framework. It works well for much of the community and continues to go from strength to strength. 

With Astro, developers introduce hybrid approaches to web applications. They can decide when and where to load JavaScript into their applications, which parts to keep static, and whether to add frameworks. 

Many frameworks, such as Remix and Next.js, enable developers to work from the server to the user experience. Frameworks like this will continue to gain popularity because it is easy to start up a Next.js app and play around with SSR features, build a feature-rich application.

 

Astro and Svelte rise as React evolves
Josh SOFE 2024

Josh
W. Comeau

Founder and Educator at The Joy of React / Joshua Comeau

It’s been over a decade since React.js was first introduced to the developer community, and it only took a couple of years for it to become the dominant front-end framework. Based on these results, React is still going strong: 85% of survey respondents have used it in the past year, and only about 1 in 5 have an unfavorable opinion.

If we look a bit closer, we see some interesting things happening. Astro has been used by 25% of survey respondents, which is remarkable given that it’s only a couple of years old and wasn’t represented at all in the 2022 survey! Other frameworks have also been growing; since the last survey, Vue’s usage has doubled, and Svelte’s usage has quintupled!

React, meanwhile, has been undergoing a bit of a transformation. While it’s always been capable of rendering on the server, the React team has leaned in, developing new features like Server Components and Actions. The response to these changes has been mixed, and it remains to be seen if the community will follow them in this new direction. “New React” is incredibly cool but not as easy to adopt as previous React features.

We live in interesting times, and I can’t wait to see what the data looks like next year!

Chapter 3.03:
Libraries

Which validation libraries have you used in the last year?

Ajv
class-validator
io-ts
joi
superstruct
valibot
yup
zod
Used and liked
Used and disliked
Want to learn in the future
Not interested
No opinion
5.6 %
2.2 %
4 %
19.5 %
68.7 %
12.1 %
3.1 %
4.5 %
17.5 %
62.8 %
2.3 %
1.6 %
5.2 %
19.4 %
71.5 %
15 %
3.9 %
6.1 %
16.5 %
58.4 %
1.4 %
0.7 %
4.8 %
19.9 %
73.2 %
3.1 %
0.7 %
6.1 %
19.3 %
70.8 %
5.5 %
0.7 %
9.1 %
17.5 %
67.2 %
34.6 %
7.3 %
5.4 %
12.2 %
40.5 %

source: tsh.io/state-of-frontend

Which date management libraries have you used in the last year?

date-fns
Date.js
Day.js
Luxon
Moment
Used and liked
Used and disliked
Want to learn in the future
Not interested
No opinion
53.9 %
4.3 %
5.4 %
8.1 %
28.3 %
22.7 %
4.3 %
7.4 %
17.8 %
47.9 %
37.7 %
3.6 %
5.7 %
13.3 %
39.7 %
15.6 %
4 %
8.2 %
19.3 %
52.9 %
45.1 %
24.9 %
3.1 %
10.1 %
16.8 %

source: tsh.io/state-of-frontend

Which state management libraries have you used in the last year?

Jotai
MobX
Pinia
Redux
Redux Toolkit
React Context API
Zustand
Used and liked
Used and disliked
Want to learn in the future
Not interested
No opinion
11.7 %
2.1 %
13.1 %
21.2 %
52 %
8.1 %
8.5 %
9.4 %
25.3 %
48.7 %
28.3 %
2.2 %
8.4 %
18.4 %
42.7 %
33.4 %
33.4 %
6.9 %
12.4 %
14 %
34.7 %
17.7 %
9.1 %
15.1 %
23.4 %
52.8 %
14.8 %
5.7 %
9.5 %
17.2 %
32.4 %
2.3 %
18.7 %
12.8 %
33.9 %

source: tsh.io/state-of-frontend

Which of the other libraries have you used in the last year?

Lodash
jQuery
Immer
RxJS
Ramda
Underscore
Used and liked
Used and disliked
Want to learn in the future
Not interested
No opinion
57 %
12.2 %
3.7 %
12 %
15.1 %
27.6 %
26.3 %
1.5 %
29.3 %
15.3 %
16.5 %
4.1 %
6.3 %
24.9 %
48.2 %
26.8 %
11 %
11.3 %
19.9 %
31 %
9 %
4.4 %
6.7 %
26.2 %
53.6 %
16.2 %
6.9 %
4.2 %
29.5 %
43.1 %

source: tsh.io/state-of-frontend

Every library is shaped by features and guided by frameworks

Adrian
Hajdin

CEO & Founder at JS Mastery / JS Mastery

From my perspective, the journey of state management library usage depends not only on their features but also on their integration with the evolving framework ecosystem and how well they address specific problems.

The shift towards server-side development has made tools like Context API and Zustand more appealing due to their efficiency and ease of use in client-side scenarios. While still relevant for B2B applications, Redux sometimes feels excessive in this new landscape. This evolution in state management tools reflects broader changes in the development environment and developer preferences.

It’s no surprise that Redux and Redux Toolkit continue to dominate with 33.4% and 34.7% usage, respectively. Redux’s robust ecosystem and mature features have made it a key tool in many projects, and the enhancements brought by Redux Toolkit have made it more appealing. However, the fact that about a third of developers still don’t favor Redux indicates that its complexity and overhead can be a drawback, especially in the context of newer frameworks.

Zod‘s rise in popularity makes perfect sense from a developer’s perspective. Its seamless TypeScript integration, particularly with automatic type inference, solves a major pain point in modern frontend development—ensuring validation and type safety are always in sync.

As a developer educator building a custom CMS for my educational platform, Zod makes validating complex data objects so incredibly easy that I can’t imagine handling validation without Zod’s powerful typescript-first schema-based approach.

The fact that Zod has the highest interest in future learning (13.1%) reflects the industry’s increasing focus on developer productivity and maintainability, i.e., the DX (Developer Experience), which Zod caters to exceptionally well.

While Yup remains a strong contender, its slightly more verbose approach and less intuitive TypeScript support might drive the community’s divided interest.

As someone who frequently works with date management, I find the stats quite telling. date-fns is clearly a strong performer, and its widespread adoption (53.9%) coupled with a very low dissatisfaction rate (4.3%) makes it a reliable choice for many projects. Its modular approach and robust functionality are hard to beat.

On the other hand, while Moment.js remains popular with 45.1% of users, the noticeable dissatisfaction (24.8%) is a sign of shifting preferences. I’ve encountered situations where Moment.js’s size and performance were less than ideal, making the move towards alternatives all the more appealing.

Day.js is catching my eye as a modern, lightweight alternative. With 37.7% of users appreciating its benefits, it’s clear that many developers are looking for a simpler, more efficient solution. From my perspective, Day.js offers a compelling mix of ease of use and performance that aligns well with current best practices.

Overall, seeing how the industry is evolving towards more streamlined and efficient date management solutions is exciting. date-fns and Day.js are definitely worth considering for anyone looking to update their toolkit

As a developer who has leaned heavily on Lodash over the years, I’m not surprised by its strong positive reception, with 57% of users expressing satisfaction. Lodash’s suite of utility functions has been invaluable in simplifying complex tasks and improving code efficiency.

However, it’s interesting to note that only 3.7% of users are keen on learning it in the future. This could suggest that Lodash is already well-integrated into many projects, or perhaps developers are focusing on modern JavaScript features and alternative libraries that offer similar functionality.

jQuery is another tool I experimented with early in my career. The near-even split between those who like it (27.6%) and those who don’t (26.3%) reflects its mixed reputation.

jQuery was revolutionary in its prime, but its once-groundbreaking features are now largely replicated by vanilla JavaScript and more modern frameworks.

The low interest in learning jQuery (1.5%) suggests it’s becoming less relevant as new, more efficient tools and frameworks take center stage.

Chapter 3.04:
Data

Which tools have you used to fetch data in the last year?

ApolloClient
Axios
ky
native fetch
SWR
TanStack Query
tRPC
Used and liked
Used and disliked
Want to learn in the future
Not interested
No opinion
25.2 %
8.9 %
11.5 %
16.7 %
37.7 %
73.6 %
8.6 %
2.1 %
6.2 %
9.5 %
4.1 %
1.2 %
5.6 %
22.5 %
66.6 %
72.4 %
6.8 %
1.7 %
4.4 %
14.6 %
19.9 %
4.9 %
13.4 %
15.7 %
46.1 %
43.4 %
2.8 %
14.3 %
9.8 %
29.7 %
12.7 %
2.4 %
29.8 %
13 %
42 %

source: tsh.io/state-of-frontend

Developers prefer battle-tested solutions

Aleksander
Patschek

Software Architect at The Software House / LinkedIn

The current landscape for data fetching in frontend development is quite stable. Developers commonly use TanStack Query with Axios (73.6%) or the native fetch API  (72.4%), which provide a convenient and effective way to manage data. One key factor is that developers are content with TanStack (43.4%), making creating new data management libraries less appealing.

While an interesting option, SWR (19.9%) hasn’t gained the same popularity as TanStack Query despite being developed by Vercel. This shows that backing by a large company doesn’t guarantee widespread adoption in the tech world. Meanwhile, the continued high usage of ApolloClient (25.2%) reflects the enduring popularity of GraphQL in development.

It’s also exciting to see the rising adoption of tRPC (29.8% want to learn it in the future), a type-safe API solution particularly well-suited for building full-stack applications with Next.js. By enforcing type safety, tRPC significantly reduces the risk of common errors, such as forgetting to update a renamed field in all relevant places. The growing interest in tRPC is likely tied to the increasing use of Next.js for full-stack development.

As for new libraries, it seems there’s little demand for them in this space. The ky (4.1%) example demonstrates developers prefer to rely on well-known, battle-tested solutions. With the increasing complexity of frontend architecture—spanning client-side rendering (CSR), server-side rendering (SSR), incremental static regeneration (ISR), and island architecture—any new library would need to support a wide range of use cases from the start. As of now, I don’t see much room for new data-fetching libraries.

In general, having standardized tools in frontend development is beneficial. It simplifies the learning curve and speeds up development when everyone on a team is familiar with the same tools. This maturity in the frontend ecosystem fosters a preference for established, reliable libraries over newer, unproven ones.

Chapter 3.05:
Hosting

What's your preferred method of hosting applications?

Vercel 36.2 %

AWS 32 %

My own/client's server 24.3 %

Netlify 20.7 %

I don't know/Not my responsibility 19.6 %

Azure 10.4 %

Cloudflare Pages 10.2 %

Google Cloud Platform 9 %

Shared hosting 6 %

Other 6.3 %

source: tsh.io/state-of-frontend

Vercel, AWS and… Netlify!
Brian-2024-SOFE

Brian
LeRoux

Cofounder at Begin / webdev.rip

Vercel (36.2%) and AWS (32%) lead the preferences, reflecting a strong inclination towards managed cloud hosting solutions. React is driving adoption from the frontend, and as workloads mature, more workloads choose AWS for its robust features, scalability, ease of integration with development workflows, and integration capabilities, especially for modern web applications.

AWS may have pioneered the serverless movement, but all credit goes to Netlify’s (20.7%) impressive rise with front-end developers. As workloads mature to full-stack requirements, migrating to AWS for better pricing, determinism, and availability still makes good business sense. 

Alternative providers have a challenging road ahead. The diversity of hosting platforms indicates a competitive market that is healthy for innovation and gives developers a wide range of choices. Developers may increasingly adopt hybrid or multi-cloud strategies, combining the benefits of managed services with self-hosted solutions to balance cost, performance, and control.

The high number of self-hosting on personal or client servers (24.3%) suggests that many developers still prefer custom environments with complete control, possibly for specific use cases or to meet client requirements, particularly when security measures are required.

Chapter 3.06:
Continuous integration

Have you used continuous integrations?

Yes 79.9 %

No 20.1 %

source: tsh.io/state-of-frontend

Which CI solutions have you used?

GitHub Actions 68.1 %

GitLab CI 33.6 %

Jenkins 31.1 %

Azure DevOps/Pipelines 18.8 %

Bitbucket Pipelines 13.4 %

Circle CI 12.6 %

Travis CI 6 %

Other 5.1 %

source: tsh.io/state-of-frontend

Closing the gap with CI tools

Adam
Polak

VP of Technology at The Software House / LinkedIn

I’m glad to see the continued growth of automation in software development. At this point, Continuous Integration (CI) has become an essential part of the process, though there’s still about 20% room for improvement. However, with the growing number of available tools and how easy integration has become, I expect that gap to close in the coming years—a promising sign for developers looking to focus on and master one tool.

So, which one should you choose? I recommend GitHub Actions (68.1%). Unsurprisingly, it’s the most popular choice among developers—it’s widely available, easy to use, and will become even more streamlined with upcoming improvements, such as deeper integration with GitHub Copilot.

One thing that surprised me was that Jenkins still held a 31% popularity share. It’s a bit outdated, but its appeal lies in being one of the few options available for on-premise setups. In most cases, I’d recommend cloud-based CI/CD solutions. But if moving your pipelines to the cloud isn’t an option, GitLab CI offers a modern, self-hosted alternative.

Chapter 3.07:
Micro-frontends

Have you used micro-frontend over the last year?

Yes 23.6 %

No 76.4 %

source: tsh.io/state-of-frontend

What micro-frontend solution have you used?

Webpack 5 Module Federation 51.8 %

Single SPA 35.5 %

Open Components 6.3 %

SystemJS 6.1 %

Bit 5.9 %

Qiankun 1.8 %

Luigi 1.5 %

Piral 1.3 %

Other 16.7 %

source: tsh.io/state-of-frontend

I don't see the drop compared to 2022 as a bad sign
Luca-SOFE-2024

Luca
Mezzalira

Serverless Specialist Solutions Architect at AWS / Building micro-frontends

Adoption declined significantly from 75.4% of respondents who reported using micro-frontends in 2022 to 23.6% in 2024. This sharp decline suggests a shift in the industry’s approach to front-end architecture

Over the past 3.5 years, I’ve worked with around 100 teams globally to implement micro-frontends at various scales. Some companies that didn’t truly need micro-frontends attempted to implement them, partly explaining the decline. Many realized that micro-frontends require more than technical know-how—they also demand organizational and cultural changes, which they weren’t ready for.

Another key factor is the growing investment in server-side rendering (SSR) and static-site generation (SSG) architectures, which incorporate similar concepts. Technologies like Astro’s server islands, React Server Components in Next.js, and HTMX are excellent examples. When used effectively, these can be powerful tools for building micro-frontends, as they share many of the same principles. Even Malte Ubl, Vercel’s CTO, mentioned in an interview that React Server Components will play a pivotal role in Vercel’s micro-frontend strategy.

Module Federation (51.8%) is becoming the standard for client-side applications, used not just for micro-frontends, but also for monolithic architectures that need frequent updates to specific system parts. With the new version of Module Federation decoupling from previous dependencies, I expect its adoption to grow even further.

Single SPA (35.5%) is another solid alternative, often preferred for its opinionated guidance. 

A framework worth watching is Piral. Although it didn’t receive many votes this year, it is adding useful tools like a discovery service, which simplifies decision-making and makes micro-frontend implementation easier.

Looking ahead to 2025, Vercel is set to release its micro-frontend solution as a first-class primitive, and many large organizations are already implementing micro-frontends. The main challenge remains aligning technology, organizational structure, and culture for success.

We’ll also see more companies offering micro-frontend solutions integrated with AI. I’ve spoken to a few startups working on exciting new tools that blend front-end development with generative AI. It’s shaping up to be an exciting year for micro-frontends!

Chapter 3.08:
Package manager

Which package manager do you mostly use?

NPM 56.6 %

Yarn 21.5 %

PNPM 19.9 %

None 0.6 %

Other 1.4 %

source: tsh.io/state-of-frontend

NPM remains the most widely used package manager, securing 56.6% of votes
Miguel-SOFE

Miguel
Ángel Durán García

Software Engineer & Dev Content Twitch Streamer at midudev / Twitch

This dominance is unsurprising, given its long-standing role as the default package manager for Node.js and its vast, comprehensive ecosystem. NPM’s seamless integration with Node.js workflows and its extensive package registry make it the go-to choice for many developers, especially those new to the field who often encounter it first.

However, it’s notable that alternative package managers are steadily gaining ground:

  • Yarn’s stable presence (21.5%). Yarn maintains a significant user base due to its performance benefits and advanced features like workspaces, which are especially useful for large-scale projects and monorepos. Yarn’s improvements, such as enhanced speed and reliability, still resonate with developers prioritizing performance in their workflows.
  • PNPM’s rising popularity (19.9%). PNPM is rapidly gaining popularity, reflecting increasing interest in its unique approach to package management. Its key appeal lies in its efficient handling of dependencies, notably its ability to save disk space through a non-duplicating system—an advantage for projects with complex dependency trees. PNPM’s performance improvements make it a compelling alternative, especially as developers seek faster CI/CD pipelines and better developer experiences.
  • Bun’s Emerging Interest. Though not officially listed in the survey, Bun was mentioned 48 times in open responses, indicating budding interest in this newer package manager. Bun’s built-in package manager offers a significant performance boost, making it attractive to developers looking to optimize their workflows.

I’ve started using PNPM more frequently, and it has become my primary package manager. Its speed, performance, and stability are standout features, and I experience fewer issues with peer dependencies and less noise in installation outputs.

Bun’s impressive speed has also caught my attention. I’ve been experimenting with Bun, especially for smaller, fast-paced projects requiring quick installations and deployments.

Future Outlook

NPM’s position as the default package manager for Node.js makes it unlikely to lose significant market share anytime soon. Its pre-installation with Node.js ensures that new developers and many projects will continue to default to NPM, reinforcing its dominance.

However, the potential removal of Corepack—a tool that simplifies the use of alternative package managers—could affect how easily developers can switch to tools like Yarn or PNPM. Despite this, Yarn and PNPM continue attracting users due to their improvements over the traditional NPM experience. Yarn’s advanced features and PNPM’s rapid growth, driven by its efficiency and performance, suggest that while NPM may remain the market leader, these alternatives will continue to gain ground as developers seek tools that better fit their specific needs.

Chapter 3.09:
JavaScript runtime

Which JavaScript runtime do you mostly use for frontend web development?

Node 96.6 %

Bun 10 %

None 2.7 %

Deno 2.6 %

Other 0.6 %

source: tsh.io/state-of-frontend

Node.js continues to dominate the JavaScript runtime landscape with a staggering 96.6% adoption rate
Miguel-SOFE

Miguel
Ángel Durán García

Software Engineer & Dev Content Twitch Streamer at midudev / Twitch

This dominance is unsurprising, given Node.js’s long-standing reputation as a reliable, versatile, well-integrated runtime. It has become a cornerstone of frontend development, largely due to its vast library of npm packages, frameworks like Express and Next.js, and seamless integration with the tools and workflows developers rely on.

Several key factors drive Node.js’s success:

  1. Stability and Trust. Developers value stability and a proven track record, which Node.js offers. As a mature technology, it has been extensively tested in projects across various industries and scales.
  2. Ecosystem. Node.js’s strength lies in its rich ecosystem, particularly the npm package manager, which provides developers with an extensive range of tools to build complex applications efficiently.
  3. Community Support. A large and active community continuously contributes to Node.js’s improvement, making it a reliable choice for developers who want to avoid the risks associated with newer, less established runtimes.

However, other JavaScript runtimes, such as Bun (10%) and Deno (2.6%), are starting to carve out niches. 

  • Bun’s position as the leading alternative is notable. Its focus on its incredible speed and its near-complete Node.js compatibility have drawn attention, even though it’s not quite 100% there yet. Bun also introduces features like a built-in package manager, native TypeScript and JSX support, and unique APIs, though some have sparked debate.
  • Deno, created by Ryan Dahl (the original developer of Node.js), follows a similar path to Bun. While its initial approach of importing dependencies via URLs may have slowed adoption, Deno’s introduction of its package registry, JSR (an alternative to npm), signals a strategic shift. With Deno 2 on the horizon, it will be interesting to see how it evolves and how the community reacts.
Future Outlook

The emergence of Bun and Deno has pushed Node.js to evolve. Node.js recently introduced experimental support for TypeScript syntax (using types as comments), improved ESM and CJS compatibility, enhanced environment variable support, and more.

While Node.js will likely remain the dominant runtime for the foreseeable future, it’s worth watching how Bun and Deno continue growing. Although their adoption rates are still low, developers are starting to recognize their potential, suggesting that these runtimes are still gaining mainstream traction.

While I still use Node.js for many projects due to its stability and vast ecosystem, I am increasingly turning to Bun. Its lightning-fast installations make production deployments quicker, and it excels at creating lightweight, fast APIs, which are becoming more appealing in my workflow. This shift highlights Bun’s growing potential, especially for projects where speed and efficiency are critical.

As web applications become more complex and performance demands rise, the focus on speed, developer experience, and native JSX and TypeScript support in newer runtimes could make them increasingly attractive.

Chapter 4:
Developer & User Experience

Chapter 4.01:
TypeScript

Have you used Typescript in the last year?

Yes 90.6 %

No 9.4 %

source: tsh.io/state-of-frontend

What typing method have you used in the last year?

Flow
JSDoc
TypeScript
Used and liked
Used and disliked
Want to learn in the future
Not interested
No opinion
2.2 %
7 %
8.5 %
36.6 %
45.6 %
38.6 %
12.2 %
10.7 %
15 %
23.5 %
94 %
4.4 %
0.9 %
0.1 %
0.6 %

source: tsh.io/state-of-frontend

In your opinion, what's the state of Typescript?

TypeScript overtook Javascript and became a new frontend standard 53.1 %

JavaScript will turn into something like Typescript 16.8 %

JavaScript and TypeScript are equally popular 16.3 %

JavaScript remains the frontend standard 11.9 %

Everyone will soon forget about TypeScript 1.9 %

source: tsh.io/state-of-frontend

More developers are using TypeScript in 2024 compared to 2022
SOFE-2024 Daniel

Daniel
Roe

Core team lead at Nuxt / roe.dev

90.6% of developers now use TypeScript, up from 84.1% in 2022. More than half of developers (53.1%) are confident that TypeScript has become a new web standard, an increase from 43% in 2022.

This is particularly borne out by key developments. From the TC39 committee, there is a ‘types as comments’ Stage 1 proposal (see its official website and repository). Node.js has also introduced an experimental type-stripping flag. In both cases, the aim is to allow a (subset) of TypeScript to be run without a compile/transpilation step.

Developers are increasingly leaning on TypeScript, not as a compiler or as part of the build process. Instead, its key utility is as a type checker that powers IDEs, linters (through projects like typescript-eslint), and developer experience features. Examples include type-safe routing (in Nuxt, Nitro, TanStack Start, next-typesafe-url), type-checked Markdown front-matter in Astro, and more.

With this focus on TypeScript running in development, the speed of typechecking becomes an important limitation. Build tooling is increasingly leaning toward native code to speed up the feedback cycle when developing, but this will likely mean that type-checking will be the limiting factor for speed. Challenger projects like stc (a Rust type checker) have ended up abandoned, but it may be that something like oxc ends up providing a faster path for type checking in development.

Looking forward, the future looks bright – and type-safe!

Chapter 4.02:
Browser technologies

Which browser technologies have you used in the last year?

Fetch API 82.1 %

Storage API 46.4 %

Websockets API 39.9 %

Clipboard API 38.7 %

ResizeObserver 37.5 %

IntersectionObserver 37.4 %

Service Workers 32.3 %

Geolocation API 28.3 %

Cache API 24.6 %

Web Workers 23.5 %

IndexedDB 18.5 %

File System Access API 16.9 %

Fullscreen API 16.3 %

WebGL 14.2 %

WebAssembly 8.9 %

Extensions API 8.1 %

WebRTC API 6.9 %

CSS Houdini 3.5 %

Resource hints 2.8 %

WebHID API 0.3 %

Other 1.9 %

source: tsh.io/state-of-frontend

We made Fetch happen!
Scott-SOFE-2024

Scott
Tolinski

Executive Producer at Syntax / Syntax

Fetch

It’s both surprising and unsurprising that Fetch has an 82.1% usage rate. On the one hand, it’s amazing how quickly we’ve standardized on Fetch, which is simple enough that most users don’t need external dependencies to make requests. On the other hand, things don’t usually move that fast. This highlights the value of having an easy-to-use, standard API for a widely needed function. Fetch’s adoption is so high that its usage is nearly double that of the next feature on the chart, the Storage API (46.4%).

Local First

From the Storage API (which includes local storage and session storage) to IndexedDB and Service Workers, storing data closer to the client is becoming an increasingly popular technique for faster-loading applications that behave more like native mobile apps. While some developers fully embrace a ‘Local First’ approach with these APIs, others use them to enhance user experience through near-instant loading times. Though some developers focus exclusively on server-side rendering, valuable lessons can be learned from native apps, including default local data loading. It will be interesting to see how the adoption of these technologies progresses in the future.

Many of these APIs could be useful in a progressive web application context. However, we still seem a ways off from true feature completeness, especially with the Filesystem Access API still limited to Chromium-based browsers.

The appearance of CSS Houdini at 3.5% usage is exciting, given the API’s still largely unfinished state. While some developers are using @property to define data types on CSS variables, most of Houdini’s potential has yet to be realized.

Chapter 4.03:
Progressive Web Apps

What is the future of Progressive Web Apps (PWA)?

Popularity will slowly increase 35.1 %

Nothing will change 32.2 %

Popularity will slowly decay 16.8 %

Popularity will explode 8.2 %

PWA will soon be dead 7.6 %

source: tsh.io/state-of-frontend

Most developers do not anticipate groundbreaking changes for PWAs in the foreseeable future
ALEXANDER-SOFE-2024

Alexander
Lichter

Web Engineering Consultant and Content Creator at Developmint / Lichter.io

Currently, 20% of respondents use PWAs for their mobile apps, the third popular choice, after React Native and native development being the top two. Other technologies like Flutter and Cordova may eventually catch up in popularity. 

After Apple initially removed PWA capabilities on iOS in the EU, the decision sparked a significant backlash from the web development community, highlighting the importance of PWAs for users and businesses. Apple ultimately reversed its decision, and progress is slowly being made—such as the recent introduction of push notifications on iOS. This aligns with PWAs as they enjoy broad browser support and increasing integration into desktop and mobile platforms. 

Despite this, only 35% of respondents believe this upward trend will continue, while another 30% think there won’t be much movement in the PWA space, possibly due to a lack of awareness or usage.

Chapter 4.04:
Design systems

What's your favorite design system solution?

shadcn/ui 28.1 %

MUI / Material UI 21.5 %

Bootstrap 11.7 %

Angular Material 7.8 %

Ant Design 7.4 %

Prime 4 %

Bulma 1.8 %

Foundation 1 %

Core UI 0.8 %

NG Bootstrap 0.6 %

Other 15.4 %

source: tsh.io/state-of-frontend

Which design handoff tools have you used during the last year?

Figma
Framer
InVision
Marvel
UXPin
Zeplin
Used and liked
Used and disliked
Want to learn in the future
Not interested
No opinion
86.9 %
4.9 %
3.2 %
1.4 %
3.6 %
11.9 %
3 %
13.4 %
17.9 %
53.9 %
8.8 %
10.6 %
3.5 %
23 %
54.1 %
1 %
1.9 %
3.4 %
24.9 %
68.8 %
1 %
1.6 %
3.8 %
24.4 %
69.2 %
12.4 %
10.1 %
4.4 %
19.9 %
53.3 %

source: tsh.io/state-of-frontend

In 2024, TailwindCSS continues to dominate

Jack
Herrington

Principal Engineer and YouTuber at Blue Collar Coder / Jack Herrington

shadcn/ui (28.1%), topping the list, combines Tailwind, Radix, and React but stands out with a different deployment model compared to MUI (21.6%) and Bootstrap’s (11.6%), the next two most popular systems. Shadcn copies implementation files directly into your project, allowing you to customize TailwindCSS classes as needed.

Material UI (MUI), the second most popular design framework (and fourth when used with Angular), is no surprise. MUI is an ‘enterprise framework’ offering accessible, themeable, and highly stylable components with strong performance. The upcoming shift to build-time CSS with the Pigment-CSS library addresses a lingering issue with NextJS, solidifying MUI’s place in the S-tier of component frameworks.

Bootstrap may seem surprising, given its origins in the Web 2.0 era, but it has evolved while maintaining its vast ecosystem of themes and components. The latest version integrates seamlessly with React and requires just one library and one CSS file. It’s even easier to set up than Tailwind, supporting many Tailwind-like utility classes for margins, padding, and more. Don’t underestimate Bootstrap just because it’s been around for a while.

Ant Design (7.3)  takes a solid fifth place. It’s a popular component system that has gained momentum over the years. It offers a lightweight alternative to MUI that fits well within the enterprise space.

On the design tooling side, Figma (86.9%) has become the de facto standard for creating designs. With the addition of developer mode and popular AI plugins that simplify converting designs to code, Figma continues to innovate. After a failed merger attempt with Adobe, Figma introduced enterprise-level support for managing design tokens in the build pipeline – a valuable feature for design and infrastructure teams at Fortune 1,000 companies.

Chapter 4.05:
Styling tools

Which styling tools have you used during the last year?

Plain CSS
CSS Modules
Chakra
Emotion
Less
Linaria
Panda CSS
Sass/SCSS
Styled Components
Styled System
Stylus
Tailwind CSS
Vanilla Extract
Used and liked
Used and disliked
Want to learn in the future
Not interested
No opinion
74.8 %
14.9 %
0.7 %
3.4 %
6.3 %
56.7 %
11.5 %
8.4 %
8 %
15.4 %
13.3 %
7.2 %
9.1 %
27.9 %
42.6 %
16.5 %
12.6 %
6.2 %
25.1 %
39.5 %
18.7 %
15.8 %
4.5 %
31.5 %
29.6 %
1.4 %
1.8 %
4.5 %
31.2 %
61.1 %
3.4 %
2.1 %
10.6 %
28 %
55.8 %
71.8 %
11.8 %
2.7 %
7 %
6.6 %
42.9 %
24.5 %
6.1 %
12.1 %
14.4 %
8.3 %
6.5 %
5.6 %
25.7 %
53.9 %
3.5 %
5.7 %
5.2 %
29.5 %
56.1 %
66.7 %
14.4 %
9 %
5.6 %
4.3 %
7.8 %
3.2 %
8.2 %
23.8 %
57 %

source: tsh.io/state-of-frontend

Developers still value its simplicity and familiarity
Brian-2024-SOFE

Brian
LeRoux

Cofounder at Begin / webdev.rip

Plain CSS remains highly popular, with 74.8% of respondents using and liking it. CSS continues to eat tasks formerly only possible with JavaScript; I think we can expect more of the code we usually outsource to heavyweight JS frameworks to be reduced to a small amount of declarative CSS.  

Sass/SCSS is also a strong contender, with 71.8%. This indicates that while plain CSS is widely used, many developers prefer the enhanced features and preprocessing capabilities provided by Sass/SCSS.

Tailwind CSS boasts a strong 66.7% usage and approval rate. Its utility-first approach resonates with developers, especially in React and Next.js ecosystems. It aligns with modern component-driven development and design systems, where styles are defined within components rather than separate stylesheets.

CSS Modules and Styled Components have a decent level of adoption, with 56.7% and 42.9% of developers using them, respectively. These tools are favored for their ability to scope styles and integrate well with component-based architectures like React.

Chapter 4.06:
Testing

Who's responsible for testing in your software development team?

Developers and QAs 44.7 %

Mostly developers 22.4 %

Only developers 20.3 %

Mostly QA 10.3 %

Only QA 2.3 %

source: tsh.io/state-of-frontend

Have you performed software tests yourself over the last year?

Yes 77.8 %

No 22.2 %

source: tsh.io/state-of-frontend

What type of software tests did you write?

Unit tests 87.4 %

End-to-end UI tests 58.3 %

Integration tests 52.7 %

Other 2.7 %

source: tsh.io/state-of-frontend

What testing tools have you used?

Jest 68.2 %

Cypress 42.6 %

Vitest 39.8 %

Testing Library 39.5 %

Playwright 36.9 %

Mocha 13.8 %

Super Test 3.8 %

Other 9.3 %

source: tsh.io/state-of-frontend

Developers are balancing testing strategies

Cory
House

Founder at ReactJSConsulting, Author at Pluralsight / ReactJS Consulting

It’s encouraging to see that most testing is handled by developers or through collaboration between developers and QA teams (87.4%). Developers can leverage automated tests to speed up development by providing a fast, reliable feedback loop and eliminating time-consuming manual checks. These benefits are lost when testing is solely the responsibility of QA.

Over 77% of respondents report conducting software tests, which is promising, but the majority focus on unit tests, which are insufficient on their own. This isn’t surprising, as unit tests are generally quicker and easier to write. However, end-to-end and integration tests are equally important to ensure the application functions as expected.

While Jest (68.2%) and Cypress (42.6%) remain the most popular testing tools, Vitest and Playwright are gaining traction despite being newer. 

In my experience, the trend is shifting towards Vitest (39.8%) for unit testing, especially as Vite becomes more popular across various JavaScript frameworks. 

Playwright (36.9%) is gaining market share over Cypress thanks to its superior performance, modern testing-library-inspired locators, and simplified setup.

Chapter 4.07:
Code management

What's your favorite desktop code editor?

Visual Studio Code 75.1 %

JetBrains IDE (eg. WebStorm) 17.8 %

Vim 3.1 %

Sublime 0.7 %

Notepad++ 0.4 %

Atom 0.2 %

Other 2.7 %

source: tsh.io/state-of-frontend

What's your favorite browser code editor?

CodePen 33.1 %

CodeSandbox 28.1 %

StackBlitz 19.9 %

JSFiddle 10.4 %

Replit 3.8 %

Other 4.7 %

source: tsh.io/state-of-frontend

What's your favorite version control provider?

GitHub 77.9 %

GitLab 15 %

BitBucket 5.3 %

Perforce 0.1 %

Other 1.7 %

source: tsh.io/state-of-frontend

All quiet on the code management front. Developer preferences remain unchanged

Marcin
Gajda

Team Leader at The Software House / LinkedIn

Desktop code editors

Front-end developers have a clear favorite in desktop code editors: Visual Studio Code (75.1%). Its success rests on two key pillars: being free and offering a vast ecosystem of extensions. Consider support for new frameworks or languages. When the creators or community members behind these tools want to add custom support to an editor, they will always prioritize one that is widely popular and freely accessible. This is where Visual Studio Code holds a distinct advantage over its most prominent paid competitor, the JetBrains IDEs. This advantage allows VS Code to stay a step — or more — ahead, making it an ideal solution for the ever-changing and evolving world of frontend development. 

In second place on the podium is the JetBrains family of IDEs (17.8%), with WebStorm being the solution specifically tailored for frontend developers. Still, people working in different technology stacks may choose more backend-flavored editors like PhpStorm or PyCharm. These tools shine in terms of better out-of-the-box experience, where you don’t need to install a dozen extensions just to get started. They’re favored by developers who have a budget and are tired of tweaking code editors set up — those who need a reliable, ready-to-use toolset. While these paid IDEs may not be as flashy as their free competitors, they promise consistent experience: when they work, they work well.

What’s interesting about this year’s results is their striking similarity to those from the State of Frontend 2022.

The top editors—VS Code, JetBrains tools, and Vim—have not seen more than a one-percent shift in usage. This suggests that for two years, we were in a stable period where users stayed with their preferred desktop code editors for a while.

However, it’s important to note that the survey results were collected before the surge in popularity of AI-powered code editors in the summer of 2024. While both VS Code and WebStorm offer plugins for AI-driven suggestions, such as Copilot and JetBrains AI, opinions across the internet suggest that these tools fall short compared to editors like Cursor. Built from the ground up around generative AI, Cursor leverages newly developed large language models like Claude 3.5 Sonnet to provide in-depth analysis of entire codebases.

In our survey, only 0.27% of respondents chose Cursor as their editor of choice, but it’s easy to imagine that this number will likely continue to grow. Cursor is actually a fork of Visual Studio Code, created because VS Code’s extension system didn’t allow for the necessary UI control needed for seamless AI integration.

While I don’t believe VS Code will lose its crown just yet, in an era where dedicated LLMs are becoming increasingly reliable for code generation, editors like Cursor could capture a significant market share. That said, VS Code isn’t standing still. As I write this, an update has been released that expands Copilot’s capabilities. A great editor war is unfolding as we speak.

Browser code editors

An interesting segment of the code editor market is the rise of browser-based editors. Some foresee the future of programming happening entirely in the cloud, with development environments set up on demand, all online. In this vision, browser-based editors would play a significant role.

However, if you take a closer look, this is not what we see in the survey results. Many respondents in the Other field have either written “none” or expressed frustration with these tools. Even the first-place choice, CodePen (33.1%), isn’t a full-fledged code editor in the traditional sense. It’s more of a playground, designed to stitch together HTML, CSS, and JavaScript, running them directly in the browser without requiring manual configuration. This highlights the current use case for browser editors—primarily for sharing quick code examples or reproduction demos rather than full-scale development.

Interestingly, the next two spots on the list—CodeSandbox (28.1%) and StackBlitz (19.9%)—are occupied by editors built on Monaco, the engine that powers Visual Studio Code. This suggests developers crave familiarity with the desktop experience they know and trust, even in the browser.

So why are browser-based code editors met with such reluctance? I believe it’s because developers are accustomed to working with local files, where they have full control over their projects. The cloud layer can feel like an obstacle, adding complexity when debugging issues or investigating problems. The perceived loss of control over the environment and files creates hesitation.

This may change in the future, particularly if a clear technical necessity arises for browser-based editors beyond their current role as demo tools. For now, they remain a convenient but limited option. The shift will require advancements in functionality and a change in perception—perhaps some clever marketing—to make browser-based editors feel like a cooler, more essential part of a developer’s toolkit.

Version control providers

Version control services are where the life of software development takes place, and in our survey, there’s a clear winner: GitHub, with an overwhelming 77.9% of the vote. GitHub’s popularity can be attributed to its generous free tier and its home to nearly all the open-source libraries developers rely on. Backed by tech giant Microsoft, GitHub has solidified its position as the go-to platform for developers.

In second place is GitLab with 15%. After an initial surge in popularity, GitLab’s growth seems to have plateaued, as its share hasn’t changed by more than a percent compared to the State of Frontend 2022 results. This stagnation may explain why GitLab is reportedly exploring the possibility of a sale, as seen in recent news: GitLab explores potential sale.

Trailing far behind in third place is BitBucket, with only 5.3% of the vote. However, BitBucket is another story. While GitHub and GitLab are primarily focused on hosting repositories, BitBucket is part of the Atlassian Suite, and it’s marketed more towards companies that rely heavily on tools like Jira and Confluence for project management.

These results are quite similar to those from the State of Frontend 2022 survey. This suggests that most developers have already chosen their preferred version control provider, and migration between platforms is minimal.

Chapter 4.08:
Low code/No-code

Which low-code platforms have you used in the last year?

None 86.3 %

Airtable 5.7 %

Retool 3.4 %

Microsoft Power Apps 2 %

Salesforce Platform 1.7 %

Oracle APEX 0.5 %

Quickbase 0.4 %

Mendix 0.4 %

OutSystems 0.4 %

Pegasystems 0.1 %

Other 1.8 %

source: tsh.io/state-of-frontend

Which no-code platforms have you used in the last year?

None 67.1 %

Notion 29.2 %

Typeform 7 %

Make 1.6 %

Bubble 1.5 %

Glide 0.4 %

Adalo 0.2 %

Softr 0.1 %

Other 1 %

source: tsh.io/state-of-frontend

Most respondents don’t use low-code or no-code platforms
SOFE-Pawel-2024

Paweł
Płowiec

CEO at Personit Rapid Development Agency / Personit

In the no-code category, Notion (29.2%) and Typeform (7%) dominate, indicating a wide spectrum of tools in this group. No-code is primarily associated with information management and online forms, rather than platforms for building applications or automation.

In the low-code segment, Airtable (5.7%) and Retool (3.4%), solutions for internal use, lead the way. I was surprised by the Flutterflow result (0.12%). This young platform may be a big surprise soon because it’s rapidly developing visual development environment based on a popular framework for creating mobile applications. I predict a significant increase in these statistics in the near future, especially considering that banks like Axis are implementing applications serving 50 million users using this technology.

Chapter 4.09:
Building tools

Which building tools have you used in the last year?

esbuild
create-react-app
Grunt
Gulp
Parcel
Rollup
SWC
Turbopack
Vite
webpack
Used and liked
Used and disliked
Want to learn in the future
Not interested
No opinion
50.2 %
4.2 %
9.1 %
8.4 %
28.1 %
31.3 %
31.5 %
1.3 %
19.5 %
16.4 %
4.6 %
17.1 %
2.6 %
34.7 %
40.9 %
12.9 %
19.5 %
2.7 %
30.6 %
34.2 %
13.2 %
6.5 %
6.9 %
26 %
47.4 %
33.9 %
6.4 %
8.7 %
14.8 %
36.2 %
20.3 %
2.4 %
10.6 %
18.3 %
48.5 %
19.5 %
4.7 %
19.7 %
16.6 %
39.5 %
82.4 %
1.7 %
7.3 %
1.8 %
6.8 %
44 %
38.5 %
2.4 %
6.4 %
8.7 %

source: tsh.io/state-of-frontend

Which linting mechanism have you used in the last year?

ESLint
Prettier
Stylelint
Used and liked
Used and disliked
Want to learn in the future
Not interested
No opinion
89.3 %
6.5 %
1.1 %
0.8 %
2.3 %
87.5 %
7.2 %
1.1 %
1.6 %
2.6 %
30.2 %
4.4 %
10.9 %
14.9 %
39.5 %

source: tsh.io/state-of-frontend

Which website builder tools have you used in the last year?

None 81 %

Shopify 7.9 %

Webflow 6.9 %

Wix 4.3 %

Squarespace 2.4 %

Carrd 0.8 %

Square Online 0.2 %

Other 4 %

source: tsh.io/state-of-frontend

Developers prefer Vite for speed and simplicity

Tan
Li Hau

Software Engineer at Shopee / Li Hau Tan

Building tools

Vite enjoys high satisfaction levels among developers, with 82.4% expressing approval. Its appeal stems from its speed, quick startup times, and minimal configuration requirements, making it a preferred alternative to Webpack. Vite leverages esbuild for fast transpilation and hot reloading during development, which enhances its overall efficiency. 

While Webpack’s usage rates are similar, Vite’s users report overwhelmingly positive experiences. In contrast, Webpack garners mixed feedback, with only 44% of users expressing satisfaction and 38.5% finding it cumbersome due to its complexity and challenging configuration.

Despite sharing a goal of zero-configuration simplicity with Vite, Parcel hasn’t reached the same level of popularity or satisfaction. This may be because Vite implements these principles more effectively, particularly in terms of speed and ease of use, which has resonated more with developers.

Create React App (CRA) has a mixed reception, with nearly equal numbers of developers expressing satisfaction (31.3%) and dissatisfaction (31.5%). Initially developed by Facebook as an easy way to bootstrap React applications, CRA is no longer recommended for production-level React projects. React’s official documentation now advises using frameworks like Next.js, Remix, or Gatsby, which offer server-side rendering, static site generation, and enhanced performance—features increasingly demanded by modern applications.

Linting tools

ESLint (89.3%) and Prettier (87.5%) continue to dominate the linting and formatting space, reflecting their reliability and long-standing reputations as industry standards. Their widespread adoption shows that they effectively meet developers’ needs. 

While not as widely used, Stylelint has growth potential, with 10.9% of developers showing interest in learning it.

Website builder tools

WordPress remains the dominant website builder tool, receiving 108 mentions, which underscores its strong presence and the trust it has built within the web development community.

Chapter 4.10:
Operating systems

Which operating system do you mostly work on?

MacOS 54.7 %

Windows 22.1 %

Linux 13.3 %

Windows + WSL2 9.8 %

Other 0.1 %

source: tsh.io/state-of-frontend

Performance, personalization, and corporate standards
SOFE-24

Sylwia
Wajgel

Frontend developer at The Software House / LinkedIn

Although Windows is the most widely used operating system globally (72% according to Statista), MacOS (54.7%) is the clear choice for most frontend developers. It provides amazing performance (especially with Apple’s M-series silicon chips), a robust command line, and plenty of built-in tools (including the Safari browser). It is also easier for less experienced developers to run CLI commands and programs because many tutorials and documentation assume a Unix-based environment. Regarding personal preferences, many developers also use other Apple devices, which can powerfully work with their workstations. 

Linux (13.3%), with its large number of various distributions, is the best choice for those who value customization, control, open-sourced solutions, and the ease of running commands in a Unix environment.

Employers often provide computers, and this fact could impact the high results of Windows (22.1%), which is a default OS in many companies. Also, Windows now provides great features like Terminal, making the programmers’ work more friendly and reducing the Developer Experience gap between Windows and other operating systems. 

For those who need the best of both worlds—Windows for general productivity and Linux for development tasks, WSL2 (9.8%)is a great option, and this solution is gaining popularity every year.

I think choosing an operating system for web development in 2024 is totally a matter of preferences and budget (if you use a private device) or corporate standards. Although none of those choices will make you a better programmer, some of them can make your work easier, depending on your habits, priorities, and the area of the frontend world that you are working in.

Chapter 5.01:
Artificial Intelligence

Do you use AI in your daily work?

Yes 75.8 %

No 24.2 %

source: tsh.io/state-of-frontend

Which AI tools have you used over the last year?

ChatGPT 90 %

GitHub Copilot 57.4 %

Bard/Gemini 26.6 %

Microsoft Copilot 13 %

Midjourney 10.2 %

Tabnine 8.3 %

v0 6.9 %

CodeWhisperer/Amazon Q for Developers 4.4 %

Codeium 3.74 %

Claude 2.82 %

Supermaven 2.39 %

Replit AI 0.8 %

Other 13 %

source: tsh.io/state-of-frontend

How have you used AI in your frontend development work?

Code assistant 89.3 %

Knowledge source 60.5 %

Code review 34.9 %

Graphics generation 11.8 %

Security analysis 7.5 %

Other 2.2 %

source: tsh.io/state-of-frontend

How have you incorporated AI in your application?

I don't incorporate AI in my applications 51.1 %

Chat assistants 32.4 %

Recommendations 21.6 %

Content generation 20.1 %

Graphics generation 5.2 %

Computer vision 3.9 %

Fraud detection 2.2 %

Funnel optimization 1.6 %

Other 1.5 %

source: tsh.io/state-of-frontend

What is the future of AI in frontend development?

It will forever augment frontend developers work 60.6 %

AI will make up a majority of frontend developers work 20.1 %

It's a temporary trend 9.8 %

People will use AI less and less over time 6.4 %

AI tools will replace frontend developers 3.2 %

source: tsh.io/state-of-frontend

From fear of losing jobs to embracing AI
SOFE-24-Ace

Adewale
Abati

Staff Developer Advocate at Block / LinkedIn

In recent years, developers have had mixed reactions to the rise of AI, often fearing it might “take our jobs.” However, it’s exciting to see that many developers are now embracing AI to enhance their workflows, with 75.8% incorporating it to improve their craft.

It’s no surprise that ChatGPT leads this trend, with 90% of developers using it. Beyond assisting with coding, many—including myself—have found it valuable as a problem-solving tool, a teacher, and a learning resource. 

With 57.4% adoption, GitHub Copilot offers real-time code suggestions, transforming the development process. When its suggestions align with your intentions, it reduces typing time and allows you to focus on project thinking—sometimes even handling parts of it for you! 😀

With nearly half of respondents already integrating AI into their applications, AI will likely become even more prevalent in future software releases. We might soon find it difficult to encounter apps that don’t involve some form of AI, raising questions about how our daily operations will evolve.

One thing is certain: despite any apprehensions about AI’s impact, integrating it into our toolset is undoubtedly the way forward.

Keeping up with AI and its ethical challenges

Ania
Kubow

Software Developer and Course Creator / LinkedIn

Artificial Intelligence rapidly reshapes the software development landscape, pushing us beyond traditional coding paradigms. Developers find themselves in an exciting position, working with AI rather than against it. This sentiment is echoed by 89.3% of respondents who actively use code assistants.

In my experience with leading AI tools through tutorials, I’ve observed how quickly the knowledge I gain can become outdated within months. Staying abreast of these evolving technologies should be a top priority for developers while they are still in their formative stages.

However, with this excitement comes great responsibility. Developers must also address the ethical implications of their work. Issues such as bias in AI models and data privacy concerns present complex challenges that need careful consideration.

Chapter 5.02:
Accessibility

How do you ensure accessibility in your applications?

Semantic, well structured HTML 72 %

Alternative texts, titles and labels 70.3 %

Styles for active and focused elements 53.6 %

Sufficient color contrast 52.2 %

Keyboard navigability 48.9 %

ARIA landmarks 45.9 %

Reducing animations / distracting elements 25 %

Support for visual impaired people 23.8 %

I don't do accessibility / It's not in my responsibilities 17.2 %

Other 0.9 %

source: tsh.io/state-of-frontend

Over 1 billion people worldwide have some form of disability or accessibility need, representing about 16% of the global population
SOFE-2024-SALMA

Salma
Alam-Naylor

Senior Developer Advocate at Sentry / Salma Alam-Naylor

There is a common misconception that accessibility is “just for disabled people”. I have lost count of the number of times I have read or heard someone claim that their app “doesn’t need to be accessible” because “it’s not for disabled people” or “blind people don’t use it”.

Accessibility often becomes a controversial and politicized issue, which perplexes me. Advocating for broad web accessibility should not be considered a “woke” stance but a fundamental aspect of creating an inclusive online experience. It’s disheartening, though not surprising, that 17.2% of survey respondents claim they “don’t do” accessibility or consider it outside their responsibilities.

In fact, a11y addresses needs that can affect anyone, like you and me, at various times—whether permanent (e.g., loss of sight), temporary (e.g., a broken arm), or situational (e.g., being in a noisy environment).

Why do only 72% of developers write well-structured HTML? Imagine if only 72% of doctors provided well-considered care. While 72% is technically a majority, it is insufficient. Many developers neglect important accessibility considerations such as keyboard navigation (essential for users with broken mice), reducing animations (to help those prone to migraines), or including ARIA landmarks (important for visually impaired users).

This issue isn’t due to a lack of educational resources. Although the WCAG specification can be challenging, numerous trusted resources are available to help developers create more inclusive applications. This is due to a lack of attention and empathy and It serves as a stark reminder of the one-dimensional demographic of many of the decision-makers and “leaders” in tech, who (in my lived experience) tend to de-scope accessibility requirements in favor of new wow-factor features in an attempt to please the shareholders (who also usually fall into said demographic). 

Unfortunately, those with accessibility needs often have to advocate for themselves. If you suffered a broken leg, you wouldn’t be expected to crawl off the road and operate on yourself. Accessibility is a right, not a privilege, and as front end developers, we need to do better: much, much better.

Discover hidden performance bottlenecks affecting your app in just two weeks

Don't wait until they impact user experience and revenue. According to SOFE Business,

performance is the main focus of tech managers in 2024.

Get ahead of the competition with our comprehensive 2-week sprint. We'll review 48 critical performance factors, pinpoint issues, and deliver a tailored action plan to boost your app's speed and efficiency. Faster load times, higher conversion rates, and lower infrastructure costs are within your reach.

Book my performance review