state of 2024

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.

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.

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.

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.

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.

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.

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.

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!

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.

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.

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.

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.

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 Webpack, 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!

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.

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.

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.

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.

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!

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

GraphQL

At first, I was shocked that GraphQL is declining (42.4% in 2022 to 26.4% in 2024) because it was supposed to be a shiny new solution. GraphQL was supposed to solve bottlenecks by giving the frontend the flexibility to query only the data it needs, eliminating the need for constant backend intervention and speeding up front-end development.

I even wrote at SOFE 2022: […] GraphQL, micro frontends, and web components divide apps so that everybody in the software team can work on their part, which later will be incorporated into a larger whole. But every developer is responsible for their area and determines how it will be done. This 100% fits the concept of broader developer autonomy with countless problem-solving options.

But then I started thinking about it, and I just had to confront people working with GraphQL with those survey results. The most common complaint is that GraphQL is too complicated a solution for the problems it was supposed to solve – while flexible, it also introduces significant complexity to the development process. The investment of setting up and maintaining GraphQL becomes questionable when you realize that the primary benefit is avoiding conversations between frontend and backend teams. Instead of streamlining work, you’re now maintaining a sophisticated system simply to avoid collaboration.

Moreover, the complexity of GraphQL often requires developers to have a full-stack understanding, blurring the line between frontend and backend roles. This can result in higher costs, as teams need to invest time and resources into learning and maintaining the system or prolonged process of hiring full-stack talent.

Progressive Web Apps 

I noticed an identical issue with PWAs (44%). They were introduced as a hybrid solution, combining the best features of web and native mobile apps. The idea was to create a single app that could run seamlessly on any platform, from desktop browsers to mobile devices, while still offering the speed and offline capabilities of a native app. On paper, it sounds like an ideal solution: one codebase, multiple platforms, and an app-like user experience without needing app store approvals.

However, I think PWAs often turn into complex “monsters” that try to do too much at once and may not be necessary for the business problem at hand. For example, if a simple website or native app could more efficiently meet the user’s needs, why invest in a hybrid solution that introduces additional layers of complexity? 

Moreover, the “one-size-fits-all” approach of PWAs can lead to performance issues or usability compromises, especially when trying to mimic native app features that PWAs are not fully optimized for. This can result in a poor user experience, negating the very benefits that PWAs are supposed to offer.

Developing and maintaining a PWA can require significant resources, time, and expertise, and the return on investment of building such a large and complex application isn’t always guaranteed. Maybe that’s why 36.1% of respondents predict PWAs will lose popularity. 

A similar technology revision can be seen in micro frontends. In many scenarios, it may make more sense to simplify the approach rather than over-engineering a solution.

There was a golden time when there was plenty of funding for developers and new technology. Now, the mindset has shifted – we may have introduced overly complex solutions to address what was, at its core, a simple communication issue between teams. Instead of solving the problem efficiently, we’ve layered on unnecessary complications.

The grand trophy goes to user experience, with 90.4%. It’s heartwarming to see developers care about users who will use their products. However, I’ve recently noticed that the UX topic is being beaten to death, and a new, much broader concept is entering the industry conversations.

A Digital Experience Platform (DXP) is a comprehensive solution beyond traditional UX, typically focusing on a single interface or interaction. Instead, a DXP encompasses the entire user journey, spanning multiple systems and touchpoints. For example, when booking a vacation, a user might start by checking hotel reviews on Google, then compare prices on Booking.com, and finally use the hotel’s app to track their reservation. Each step contributes to one seamless experience, yet they involve various websites and applications.

The key difference is that DXP looks at the complete web experience, uniting all the fragmented interactions into one cohesive journey. From the user’s perspective, these steps may seem disconnected, but they all contribute to the same goal—the vacation booking process. A DXP helps businesses stitch together these moments into one smooth, end-to-end experience.

Unlike UX, which is often interface-specific, DXP is much more marketing-oriented. It helps businesses, like hotels, understand a user’s entire journey across multiple platforms. With a DXP, a hotel can track how many users check reviews on Google, share their booking experience on Facebook, or arrive from Booking.com or Airbnb. This detailed observability helps businesses gain valuable insights into user behavior, allowing them to optimize each touchpoint for a satisfying end-user experience.

DXPs are seen as the new CMS but offer far more than simply managing content. While traditional CMS tools handle content for a single platform, DXPs oversee the entire digital ecosystem, tracking and analyzing not just the content but the entire user journey across platforms.

By embracing DXPs, businesses can break down these silos and move towards a more integrated and user-focused strategy. Instead of using technology as a barrier between teams, the goal is to use it to improve collaboration, creating a seamless, consistent experience for users across all touchpoints.

The second highest score is 85.7% for developer experience, and it made me wonder because recently, I’ve noticed that the definition of what we understand by “DX” has changed drastically. 

In the past, it primarily revolved around making the development process more enjoyable for engineers, focusing on tools and environments that improved personal satisfaction and job comfort. Now, it’s less about creating a “pleasant” work environment and more about boosting developer efficiency and productivity. Companies are no longer looking to make developers “comfy” but faster, smarter, and more effective.

However, my observation across successful projects is that the most efficient teams often turn out to be the most satisfied anyway! When their workflows are organized, developers feel a sense of accomplishment from getting things done quickly. Even when teams are under tighter deadlines, the satisfaction often comes not from a relaxed work environment but from the feeling that they are working to solve a particular problem and delivering value. 

That said, simply telling developers to “work faster” will not be well-received. Teams won’t respond positively to pressure unless they see tangible results. However, when you show them performance metrics, and they start recognizing improvements in their productivity, their perspective changes. The focus shifts from the immediate discomfort of hard work to the long-term benefits of working smarter, not harder. I often tell my teams, “You’ve been working overtime, and I appreciate that, but instead of putting in extra hours, I’d rather you figure out how to avoid the need for overtime altogether.” This approach encourages them to think critically about their workflows and find more efficient ways to accomplish the same tasks.

Ultimately, modern DX aims to empower developers to work smarter, not harder, streamlining their processes to be more productive without sacrificing quality or mentally burning out.

Interestingly, while AI tools like code generators and automation platforms are often thought of as ways to boost productivity, my internal analysis shows they don’t always provide significant gains in efficiency. This is because AI tools still require human oversight to ensure they don’t make mistakes, meaning developers spend time continuously monitoring, supervising, and correcting AI-generated output. 

Another case here is headless CMS. Once seen as a revolutionary idea, it maintains rather steady popularity (39.4% in 2022 and 48.5% in 2024). Initially, headless seemed like a good way to increase autonomy since it separates the frontend from the backend, allowing each team to work independently. However, what I see in practice is that this approach has proven to be inefficient. Teams became isolated, working in silos without communicating, which resulted in fragmented projects and a lack of cohesive strategy. Over time, it became clear that collaboration and communication are essential for maintaining a broader project perspective. Again, technology prevents people from talking to each other. 

It’s like trying to write a book with 40 different authors who never communicate—each section might be well-written, but the story won’t flow, and the reader will struggle to read through.