Philippe Serhal — Software Engineer

OSS made me a better developer

Tue, 03 Mar 2026 00:00:00 GMT

I recently got involved in an open-source project, npmx. This is the meandering story of how that made me a better developer.

It’s never too late to start writing accessible code

I started my career in 2007 at a Canadian government department responsible for web standards. As you can imagine, accessibility was a pillar. We tested websites (actually, there was a standard that mandated spelling it “Web site”; it still haunts me) on a dedicated computer in a closet that had expensive assistive screen reading software installed, and we reported back to departments that didn’t meet the bar. That bar was not very high back then. There was no WCAG 2.0 and no ARIA yet. Gmail and Google Maps had just shown what was possible and the web had become a dynamic free-for-all with little concern for accessibility.

Over the next couple decades, I did graduate research in computational biology, built internal apps for e-commerce fulfillment and delivery operations at a startup, led an internal developer productivity team, and maintained the build platform at Netlify, including all its framework integrations. All this time I wasn’t closely touching production web development for large-scale, diverse audiences. Meanwhile, the capabilities of the web exploded and accessibility patterns evolved with it. I didn’t go out of my way to keep up, neither professionally nor in my countless side projects.

Then in early 2026 I joined a group of people building a modern web app for millions of users. They took accessibility as a given and simply put in the work. PRs weren’t merged if they didn’t meet the accessibility bar. I had to learn if I was going to contribute. I mean, I had to know what I was doing if I was going to be a maintainer, right?!

So I just… learned. I browsed the codebase, learned the patterns, looked up attributes I wasn’t familiar with, got feedback from the linter, from the automated Lighthouse audit and component accessibility tests. I asked Claude for an accessibility review before putting up each PR. I learned from PR review feedback, on my own PRs and on others’. I learned from our #a11y Discord channel.

One month later, I’m far from an expert, but I’ve shifted a lot out of my “things I don’t know I don’t know” bucket; more than ever, with the ease of retrieving information, knowing what to retrieve is what matters most.

Now I’m going back to all my live side projects to set up a11y tooling and make them accessible to a more diverse audience. Because it’s a given for me now too. It isn’t too late for you either.

Internationalization is easy… with a community

My internationalization journey follows a similar arc as above. At my Government of Canada job, all websites were required to be in English and French, the two official languages of Canada. The ColdFusion(!) server read from a Microsoft SQL Server 2005(!) table containing translated strings. Translations were updated by manually writing and executing raw SQL queries ad hoc against the production database(!). Nominally, the process had to go through a lengthy internal request process from some government translation department, even for a single word. In practice, as I was the only French speaker on the team and a junior programmer… it fell on me. (One time, I hit enter on my UPDATE strings SET en = "something", fr = "quelque chose"; query before remembering to add the WHERE key = "something" clause… I’ll never forget the monstrosity of a website that created.)

Over the next 19 years, I never really encountered internationalization again. (Well, okay, as part of my job on the frameworks team at Netlify I do occasionally tear my hair out at the complexity wrought by Next.js’s built-in i18n features.)

It turns out internationalization hasn’t changed all that much in two decades. You extract all user-facing strings somewhere, each mapped to a unique key with translations. You avoid making assumptions about the length of those strings or their direction… The hard part is staying organized, keeping track of what needs to be translated or re-translated, who can translate and review what, which strings are unused and can be cleaned up, and so on. Some of this can be solved with tooling and automation, while some of it is just humans working together. Lunaria solved some of these problems for npmx.

One month in, we support 28 locales. It sort of just… happened, organically.

As with accessibility, I now know that I know or know that I don’t know a number of things that I previously didn’t know that I didn’t know about internationalization and localization. Nope, there was definitely no easier way to put that, I’m sorry.

Nuxt really shines with many contributors

I wasn’t new to Nuxt. It’s my job at Netlify to know a dozen frameworks well. I built @netlify/nuxt (with Daniel Roe!) and help maintain the Netlify Nitro presets. But building one-off demo apps, test fixtures, and small personal projects does not quite expose you to the same strengths and weaknesses of a framework as does collaborating with 200 contributors over just a few weeks.

I knew this in theory, but seeing in practice how Nuxt’s highly opinionated, batteries-included conventions nudge all contributors toward a common Pit of Success has been eye opening. It isn’t a panacea, but much like automatic code formatting it avoids entire classes of bikeshedding and lets everyone focus on shipping features. Two hundred new contributors, most of whom had never worked in Nuxt, were able to effectively contribute over a thousand PRs in just a few weeks. That’s saying something.

I was missing out on great tools

There’s something about OSS where they are always way ahead of the curve in terms of their own developer tools (don’t be shy, I know you’re still using jest and webpack at work). A greenfield OSS project that is itself a developer tool, built by some of the brightest minds in the developer tooling space, is bound to be a goldmine. Here are just a few of those that stood out to me:

knip: knip is incredible. If like me you’d used npx knip here and there for a one-off report, trust me, give it a fresh try—it’s become really good, has really cut down on false positives, and is highly configurable. Install it as a dev dependency in your projects, clean up the clutter, and run it automatically in CI from now on. Oh, and it now has IDE integrations, an LSP server, and an MCP server.
e18e eslint plugin: The e18e crew are now in your linter. You can have your own little James Garbutt in your IDE calling out performance gotchas and bloated dependencies. Don’t worry, eslint plugins now work with…
oxlint: Extremely fast, eslint-compatible linter. It’s here. There’s no need to wait any longer.
oxfmt: Extremely fast, prettier-compatible formatter. It’s now in beta and it works great. Hey, it’s a formatter, you can afford to use a beta.
vue-data-ui: Powerful, beautiful, absurdly full featured and customizable data visualization Vue library.
unocss: Lightweight, portable highly customizable atomic utility CSS engine. Tailwind compatible.

I’ll be adding these and more to my toolbox.

You can just build what you wish existed

Now more than ever, if there is something missing that software can solve for you, for your family, for your friends, for your employer, for your client, you (yes, you) can just build it. If existing software isn’t cutting it, you can just build your own. If existing software is funded by interests whose actions are fundamentally incompatible with your values, you can just build your own.

In all these cases, you can go much, much farther by finding like-minded people and building together.

Hold fast to the one noble thing.

— Four Ways to Forgiveness, Ursula K. Le Guinn (1995)

You can find your people again and again

I’ve heard that a key to happiness and fulfillment is to find your people. I think that’s incomplete: you have to keep finding more people; all sorts of people, across all the spheres of your multifaceted existence. Find the people who share your sense of humour. Find the people who share that weird, technical passion of yours, and those obsessed with that obscure fantasy author you love. Find the people who share your fundamental values (P.S.: really hold on to these most of all). It turns out there’s quite a large and varied supply of people out there, and you never know what might make them yours after all.

In npmx, I found people who cared about a daily challenge they and others were facing, and believed they could come together and… just build the solution—without putting others down, without monetization, with inclusivity in mind from the start, just building, building, building without borders. Devs already working on a solution to this? Join our team! You, you and you! Have ideas from another problem space that connect these two worlds? Oh hello, atproto friends, come on in! Leading expert on a11y passionate about making this a rich experience for all abilities? Yes please, teach us your ways.

These are my people. They may be your people.

“Then you came here,” she said.

“Then I came here.”

“And learned?”

“How to walk,” he said. “How to walk with my people.”

— A Man of the People (Four Ways to Forgiveness), Ursula K. Le Guinn (1995)

A few of my people

Announcing npmx: a fast, modern browser for the npm registry — npmx.dev
How to Make Your First Open Source Contribution — whitep4nth3r.com — Getting involved in open source doesn’t have to be scary! Understand how to find a great project and make your first contribution in this guide from Salma.
A Virtuous Circle — danielroe.dev — There’s a reason why building npmx has been such a blast so far, and it’s one of the most powerful patterns in open source software development. It’s also why ‘the 10x developer’ is an incredibly dangerous myth.
npmx: converging communities — The story of the many people and communities that converged to build npmx together.
Sponsoring npmx — It’s more important than ever that companies come together across competitive boundaries to sponsor and support the open ecosystem that lifts all boats.
vue-data-ui is on npmx npmx is on vue-data-ui — graphieros.com — Graphieros explores a minimal npm-based workflow and why it exists.
The month. npmx — alexdln.com — Alex reflects on the project, warm stories, wonderful people, and a look into the future.
Collaborating with npmx — How the e18e community is collaborating closely with npmx to make best practices more visible and accessible to everyone in the ecosystem.
Finding an accessibility-first culture in npmx — Abbey Perini talks about how accessibility is a deep part of the npmx culture.
npmx: With a Little Help From My Friends — johnnyreilly.com — How to contribute to npmx.dev, and thoughts on Johnny’s experience with the project.
npmx: A Lesson in Open Source’s Collaboration Feedback Loops — opensourcepledge.com — npmx’s success is reminding us why Open Source is such a special social phenomenon.
Rising community at tomorrow’s horizon — trueberryless.org — Telling the story of a newly founded community.
Open source needs community. Community needs open source. — zurichjs.com — Why ZurichJS cares about getting people into open source.
From a Bluesky post to my favorite open source community — sybers.fr — The best open source projects aren’t just about great code. They’re about the people behind them.
Storybook 💙 npmx — storybook.js.org — We’re huge fans of what the npmx community is building. Today’s alpha is just the starting line, and we’re proud to be running alongside them.
Open source, what’s in it for me? — jensroemer.com — Reflections on learning, community, and change.
npmx goes social with atproto — Announcing npmx speakers, and congratulations on launch day!
VoidZero and npmx: Building Better Tools Together — voidzero.dev — How VoidZero and npmx.dev share a vision for making JavaScript developers more productive, and how real-world feedback from open-source builders helps improve our tooling.
The npmjs.com that developers deserve - What is npmx? (video) — An introductory video showcasing Alex’s favorite features of npmx and the open-source idea behind it.
Community, Open Source, and npmx — farisaziz12.bsky.social — npmx isn’t just an npm browser, it’s a fast-moving open source train that welcomes you aboard the moment you show up.
Overcoming Imposter Syndrome: My First Open Source Contribution — paulie.codes — The most important part of open source is the people, and everyone has something valuable to bring to the table.
From a Newsletter Link to My First Open Source Contribution — How discovering npmx through a newsletter led to a first meaningful open source contribution and a new perspective on community-driven development.
npmx Is Open-Source Done Right — How the ethos and practices of npmx represent a healthy open-source ecosystem that should be the standard, not an exception.
Joy of open source — childish fun of making things together.

Web frameworks: 2025 in review

Tue, 27 Jan 2026 00:00:00 GMT

2025 brought 13 major framework releases and 52 security vulnerabilities across the most widely used fullstack frameworks. Many weren’t obscure edge cases, but issues that forced maintainers, platforms, and developers to confront the real cost of abstraction.

As a software engineer on the frameworks team at Netlify, my job is to track changes like these closely, support new releases on day one, and make sure they don’t become your problem.

This post covers what happened in 2025. I’ll walk through six themes that defined the year, with context on how we got here and what they signal for teams building and shipping in 2026.

What we’ll cover:

Security under the microscope
The Next.js team delivered
Agent experience became a thing
React Server Components matured
Signals won – except in React
Performance ‘Rustification’ continued

Security under the microscope

This year saw vastly increased scrutiny from security researchers. No fullstack web framework was spared.

Framework	Vulnerabilities
Nuxt	1 high-severity CVE (7.5) leading to CDN cache poisoning
Remix / React Router 7	3 high-severity CVEs (7.5, 7.5, 8.2), plus 6 more before publication
Next.js	4 low, 5 moderate, 3 high, 2 critical—including a 10.0 that rippled across the React ecosystem
Astro	2 low, 7 medium, 5 high
Angular	3 high-severity CVEs (7.1, 7.7, 8.5)
SvelteKit	4 high, 1 moderate

The deep dive on the Remix/React Router vulnerability by Rachid Allam is worth nerding out on.

With most of these 52 vulnerabilities involving servers, some developers quietly held their “I told you so”s while yearning for a time when frontend frameworks didn’t touch the backend at all.

The Next.js team delivered

After years of criticism around transparency, vendor lock-in, and ecosystem fragmentation, 2025 was the year the Next.js team took constructive feedback to heart.

The team proposed a Deployment Adapter API and shipped an alpha in Next.js 16—designed in close collaboration with engineers at Netlify, Cloudflare, Google Firebase App Hosting, Deno, SST, and AWS Amplify.

This working group opened lines of communication across the ecosystem: they shared early RFC drafts, gave advance notice of upcoming releases, and coordinated planning. A security group was also established where Next.js platform providers receive early notice (under embargo) of CVEs, giving time to apply platform mitigations, patch adapters, and prepare customer communications.

Source: Next.js Conf 2025

These are major positive developments for Next.js developers and fans of the open web. Credit goes to Jimmy Lai and the whole Next.js team for turning over a new leaf.

Agent experience became a thing

As AI coding agents moved from weekend vibe coding to daily workflow, frameworks started explicitly shipping agent experience (AX) improvements.

Out of the box, browser logs weren’t visible to agents. Next.js shipped a dead-simple solution: forward these to the dev server logs. Other frameworks will follow.

Source: @RobKnight__ on X

Every major framework shipped its own MCP server in 2025:

In October, Ryan Florence and Michael Jackson unveiled their vision for Remix 3: a new framework built with agent experience in mind from the ground up.

React Server Components matured

React Server Components (RSCs) have had some ups and downs, after being first introduced five years ago.

It was a nice promise: What if you could render your site on the server and selectively opt parts of the component tree into client hydration—not just on initial page load, but on all subsequent interactions and navigation?

Source: joshwcomeau.com/react/server-components

Years of iteration and false starts followed. A stable implementation didn’t land until mid-2023 with Next.js 13.4. Then came another period of experimentation:

Shopify built Hydrogen v1 on RSCs, then abandoned them completely with v2
Remix showed an early prototype (and later pivoted away from React entirely with v3)
Waku launched as an experimental minimal RSC framework
The RedwoodJS team spent years working through RSC implementation challenges
Tanner Linsley’s team quietly tinkered away on RSC support for TanStack Start

RSCs in 2025

In 2025, RSCs reached their next stage of maturity. Maintainers of React, React Router, Waku, Vite, and others came together to collaborate on a shared foundation: @vitejs/plugin-rsc.

It’s no coincidence that in the past year alone:

React 19 shipped with stable RSC support
Next.js 16 leaned further into RSCs with Cache Components
React Router 7 launched RSC support in preview
Parcel shipped native bundler support
RedwoodSDK launched with RSC support on day one
Waku moved to alpha
TanStack Start moved closer than ever to experimental RSC support 👀

Signals won–except in React

As we discussed last year, rendering frameworks have rallied around Signals as the basis for reactivity. In 2025, the trend continued:

Angular 20 stabilized its signal APIs
Angular 21 introduced Signal Forms and made “zoneless” the default
Vue shipped a beta of Vapor Mode (goodbye, Virtual DOM!)

Meanwhile, React, virtually (pun intended) the only holdout, dug in further with React Compiler 1.0, a band-aid to address shortcomings of its reactivity model.

Performance ‘Rustification’ continued

The ecosystem kept doubling down on step-function performance improvements by moving to Rust (and occasionally Go or Zig).

Next.js and Turbopack:

Next.js 16 promoted Turbopack to stable and made it the default
Result: 2–5x faster builds for everyone
rspack also shipped Next.js support (yes, you can now use Next.js with three bundlers: webpack, rspack, and turbopack)
Vercel added support for the Bun runtime (Zig!)

Vite and VoidZero:

VoidZero’s efforts to rewrite a unified Rollup + esbuild replacement in Rust hit a milestone with the Vite 8 beta
Typical improvement: 4–10x faster builds

TypeScript in Go:

Microsoft announced in March they were rebuilding TypeScript in Go
By December, they were gearing up for production
Promise: stability and 10x speedups—worth opting in now

The year in brief

Money moved

The framework ecosystem saw significant consolidation and investment in 2025:

Date	Event
March	Netlify sponsored TanStack
July	Vercel acquired NuxtLabs (employer of Nitro and most Nuxt core maintainers)
September	Mux, Webflow, and Cloudflare ($150K) sponsored Astro; Cloudflare sponsored TanStack
December	Anthropic acquired Bun
January 2026	Cloudflare acquired Astro

Infrastructure companies are betting on frameworks as a strategic layer. Vercel deepened its Vue ecosystem ties, Cloudflare went all-in on Astro, and Anthropic’s Bun acquisition signals AI companies see JavaScript runtimes as infrastructure worth owning.

Other notable releases

A few releases didn’t fit the “major framework” category but still shaped the year:

Node.js 24 (May) – Continued the ESM transition and promoted URLPattern to a built-in global
Vite 7 (June) – Incremental improvements ahead of the Rust-powered Vite 8
Nitro v3 alpha (October) – The server engine powering Nuxt, AnalogJS, and SolidStart got a ground-up rewrite

Worth watching

The honorable mentions that didn’t get their own section; grouped by theme.

Data and caching patterns

Frameworks got smarter about when to fetch and when to cache. Astro shipped Live Content Collections, enabling runtime data fetching through the unified Content Layer API—useful for avoiding expensive rebuilds when CMS content changes frequently. Next.js 16 introduced Cache Components, a stable caching model that consolidates previous experiments (“use cache”, Partial Prerendering, Dynamic IO) into one coherent approach.

Middleware and server boundaries

The line between “frontend framework” and “backend framework” kept blurring. Next.js renamed middleware to proxy after years of confusion about its capabilities—clarifying that it handles routing decisions at the edge, not business logic. They also added Node.js runtime support, addressing a long-standing request.

React Router shipped actual middleware, and SvelteKit introduced Remote Functions: server-only code in .remote.ts files callable directly from components with full type safety, explicit module boundaries, and no JavaScript funny business.

Async patterns and component models

Svelte introduced experimental await support for use directly in components—their answer to React Server Components and <Suspense>. Meanwhile, Ryan Florence and Michael Jackson unveiled Remix 3’s radical new direction: ditching React entirely, embracing micro-packages built on the Web Platform, and returning to imperative this.update() state management. Their pitch? A baggage-free framework for the LLM era.

Ecosystem convergence

Vite’s dominance continued: Fresh switched to Vite, Ember completed its migration, and Angular defaulted to Vitest for testing. As predicted last year, Vite’s Environment API saw its first wave of adoption. TanStack Start ships fully on it, Astro 6 will follow, and React Router 7.10 and Nuxt 4.2 added opt-in support (stable soon in Nuxt 5).

Nitro’s role evolved from server engine to Vite plugin, with TanStack Start removing it from core in favor of letting users choose Nitro or alternatives like Netlify’s Vite plugin. Other Nitro-powered frameworks will likely follow.

OpenTelemetry gained momentum for framework observability: SvelteKit shipped built-in OTel traces, Nitro is working toward support, and TanStack Start is exploring automatic instrumentation for server functions, middleware, and route loaders.

The e18e (Ecosystem Performance) initiative quietly made everyone’s lives better by slimming and unifying dependencies across the board and cleaning up the ecosystem at large.

Finally, TanStack Start quietly added experimental Vue support (alongside React and Solid), leaning further into their framework-agnostic approach.

What to expect in 2026

Some reliable predictions for the year ahead:

Angular will drop v22 in May and v23 in November (per their fixed release schedule), going deeper into fine-grained reactivity and the Vite ecosystem.

Astro 6 will ship with a revamped dev experience and internal cleanup.

Nuxt 5 will ship shortly after Nitro v3 graduates to stable—with huge DX and performance gains from the rebuilt engine. You can try it today.

Waku 1.0 might graduate from alpha to stable as a minimal RSC alternative.

TanStack Start 1.0 will presumably launch its own RSC implementation and graduate from RC to stable.

Next.js 17 will likely drop in October. The Next.js team has increased roadmap transparency with partners like Netlify, though this hasn’t translated to much public visibility yet 🤐.

Security vulnerabilities will continue to target your projects. Keep dependencies up to date with Renovate or Dependabot, and follow the Netlify changelog.

Frameworks will keep converging on fundamentals (though don’t hold your breath for React to ditch its vision and move to Signals).

Coding agents will keep improving at web development, and frameworks will keep evolving to meet their needs. Expect a shift from MCP to Agent Skills.

Phew, you’re all caught up. What are you excited to try this year?

Stay informed in 2026 by following the Netlify changelog.

Frontend frameworks, a 2024 year in review

Fri, 17 Jan 2025 00:00:00 GMT

The world of web development is constantly evolving and 2024 was no exception. We know you’re too busy shipping features to keep up with it all.

Luckily, Netlify is full of web nerds with a passion for building a better web—our Frameworks engineering team has been keeping tabs and taking notes (seriously, you don’t want to know how many Discord servers we’re in). It’s part of how we managed to achieve day-one support for Next.js 15, Svelte 5, Angular 18, Astro 5, and even pre-release support for Nuxt 4. So why not share our insights with the community?

Keep reading for a primer on the trends and plot twists we saw this year, some quick-fire frontend framework news, a dozen releases including some exciting newcomers, and what to expect next year. You’ll be up to speed in no time.

Frameworks copied one another’s homework

Server Functions pattern spreads

Next.js’s Server Actions provide a tRPC-like developer experience when crossing the browser-server chasm: call a function on your server from the browser and the framework transparently turns this into a fetch request to your server under the hood, with full type safety.

This year saw this pattern spread to other full-stack frameworks:

React 19 finally shipped stable Server Functions, a generalization of Server Actions, via the new "use server" directive.
Astro shipped stable Actions, following the same pattern.
SolidStart 1.0 shipped with support for both Solid Actions and a more general "use server" directive. (Although 1.0 only shipped this year, this was actually the very first instance of this pattern!)
TanStack Start shipped a beta with support for Server Functions that can even be called seamlessly from both the browser (turned into a fetch request) and the server (called as-is).

Component-level prerendering goes mainstream

Historically, there were SSG sites and SSR sites. A few years ago, many frameworks started supporting hybrid sites, where some routes can be prerendered (or statically rendered) and others dynamically rendered. Next.js’s App Router even does this automatically based on heuristics.

Lately, frameworks have been taking this even further, by allowing for parts of a page to be prerendered (the static shell) and the rest to be rendered on the server on the fly. This was popularized by React with <Suspense> and Streaming SSR, but it isn’t until recently that meta-frameworks have started to fully implement this in a way that can be directly used by web developers: Remix has supported it since 2023 and Next.js first announced experimental support for what they called Partial Prerendering (PPR) that same year.

Source: https://astro.build/blog/future-of-astro-server-islands/

This could take up a whole other post (and probably will 👀), but here’s the gist of the 2024 update:

One year after experimental PPR in Next.js 14, Next.js 15 shipped without any updates to PPR, as the team wrangles complexities this uncovered.
React Router 7 shipped with the same functionality as Remix 2.
The upstart React-based TanStack Start framework shipped a beta with the same pattern.
Astro 5 shipped Server Islands, meeting the same needs but with a web-standard implementation allowing for any platform to cache the static shell or even individual dynamic islands.

If you’re wondering why the React Suspense-based approaches aren’t trivially cacheable, watch this video and notice how the static shell and the dynamic components are coupled as a single response body—or wait for our upcoming deep-dive post on this!

A signal by any other name would smell as sweet

To handle interactivity in the browser without letting web developers handle everything manually (think jQuery) or re-rendering the whole page on every change, frameworks must keep track of the intricate web of dependencies between all the variables in your site’s UI and in your data. This is usually called the framework’s “reactivity” model.

A framework’s reactivity model is a big part of what makes each framework unique. It manifests itself to you in the framework’s syntax and constraints, molds your mental models, is a major determiner of performance, and—let’s be honest—is a common source of bugs! As an example, you’re likely familiar with React’s reactivity model: Hooks (introduced in 2018 in React 16.8) and, previously, methods like shouldComponentUpdate and friends.

Reactivity models have changed in bursts since the first frameworks in 2010. (For a much deeper dive, start with A Hands-on Introduction to Fine-Grained Reactivity, The Evolution of Signals in JavaScript, or anything Ryan Carniato of Solid.js has written.) We are witnessing another burst: this year, three major frameworks shipped brand-new reactivity models:

Svelte 5 introduced Runes, heavily inspired by Solid.js Signals.
Angular 18 introduced experimental zoneless change detection and Angular 19 continued to iterate on this new Signals-based reactivity.
React shipped a beta release of React Compiler, an approach relying on static analysis at build time of your components to compute dependencies. This approach has been used by Svelte for years, but is quite a departure from the more common runtime reactivity model of most frameworks, like Vue’s.

What’s more, a proposal to bring a standard Signal implementation to JavaScript moved to stage 1 this year.

Astro leveled the playing field

Astro is a fairly recent newcomer that has garnered a lot of buzz lately (in the just-released State of JS 2024 report, it ranked #1 in interest, retention, and positivity).

While staying true to its roots as a minimal framework for content-driven sites, it added some key features in 2024 to quiet some critics:

Actions, Astro’s answer to Next.js’s Server Functions (more on this above).
Server Islands, Astro’s answer to Next.js’s Partial Pre-Rendering (more on this above)
Content Layer, Astro’s answer to Gatsby’s GraphQL Data Layer.
Sessions, Astro’s (experimental) storage-agnostic answer to a common meta-framework provision for user session handling (e.g. Remix sessions, NuxtAuth, NextAuth.js).
Astro DB and Astro Studio (with a pivot away from their own SaaS toward an agnostic layer), Astro’s agnostic layer to interface with relational databases.

Vite is even more ubiquitous

Vite is a full-featured bundler, compiler, and development server for the web.

This year, it was the most favored option for web developers using everything from React to Vue, Svelte, or no framework at all. Its focus on performance, out-of-the-box functionality, and limitless configurability has led to a meteoric rise in just a few years.

Source: https://blog.stackblitz.com/posts/what-is-vite-introduction/

It is also used under the hood by meta-frameworks like Astro, Nuxt, and SvelteKit—in fact, this duality is a big reason for Vite’s success.

This year, Remix shipped support for Vite (and later dropped support for its own compiler), Hydrogen switched to Vite, and even the old-school Ember.js framework is switching to Vite.

This leaves Next.js (Webpack/Turbopack) and Gatsby (Webpack) as the only major front-end meta-frameworks not using Vite.

Nitro isn’t just for Nuxt anymore

Nitro is a full-featured server engine library that provides an agnostic development and production server layer for frameworks to build upon, unlocking out-of-the-box support for dozens of deployment targets, such as Node.js, Deno, Netlify Functions, Netlify Edge Functions, Cloudflare Workers, and so on.

Until recently, it was only used by Nuxt.

This year, AnalogJS 1.0 launched, SolidStart 1.0 launched, and TanStack Start was announced and quickly reached beta. All three of these newcomer frameworks use Vite and Nitro under the hood. What’s more, this combo was repackaged as an intermediary layer called Vinxi—which is used by SolidStart and TanStack Start—significantly lowering the barrier to entry for new frameworks.

Angular also announced that they are exploring switching to Nitro.

More compatibility across runtimes & platforms

2024 was a great year for compatibility!

Deno 2 launched with full compatibility with Node.js and NPM modules. All frameworks now run on the Deno runtime!
The Cloudflare Workers runtime vastly increased its Node.js and NPM module compatibility.
Bun incrementally increased its Node.js compatibility throughout the year.
Next.js announced upcoming support for the Node.js runtime in middleware.
The Vite 6 Environment API shipped, unlocking future improvements to runtime and platform compatibility for a dozen frameworks (more on this below).
Next.js made strides on openness:
- The OpenNext initiative spearheaded by SST was joined by Cloudflare and Netlify.
- The self-hosting docs were augmented and Next.js 15 shipped improvements to self-hosting.
- Vercel spun out a separate Next.js GitHub org with examples for deploying to Vercel competitors.
Node.js shipped experimental support for require() ing ES modules in 22.0.0 and experimental support for TypeScript syntax in 23.6.0!

Developer experience kept improving

Blazing-fast Rust-based build tools are almost here

Multiple efforts to write new compilers and bundlers in Rust are underway and made significant progress in 2024:

Source: https://rspack.dev/blog/announcing-1-0

Turbopack, Next.js’s Rust rewrite of Webpack, was marked as stable in dev and will become the default soon.
Rspack, a straight Rust port of Webpack, shipped a stable 1.0.
Rolldown, a Rollup-compatible bundler written in Rust, shipped its first beta on Christmas and secured funding to accelerate its development, along with Vite and Oxc. In the near future, Rolldown will replace Rollup and ESBuild to power Vite under the hood and nearly all frameworks will get an order of magnitude faster builds and dev servers.

Upgrades became easier than ever

Migration codemods automate the toil

This year, Next.js 15, React Router 7, Astro 5, Nuxt 4, and Svelte 5 all came with an official (sometimes even built-in) upgrade codemod. Most of these were developed and distributed on the impressive Codemod.com platform.

Opt in to breaking changes at your leisure with “future flags”

Gone are the days of choosing between delaying painful upgrades or opting in early to unstable releases. Many libraries nowadays—including to some extent all major frameworks—now follow the “future flag” pattern, where unstable features and breaking changes are shipped incrementally to the current major version, hidden behind a configuration flag. You can explicitly opt into individual flags at your own pace depending on your needs. Notable examples include Astro’s experimental flags, Remix’s future flags, and Angular’s experimental providers.

Some libraries like Nuxt take this approach to its fullest potential—you can quite literally opt into Nuxt 4 in Nuxt 3 by setting compatibilityVersion to 4 , which is just toggling a dozen features and breaking changes. Once Nuxt 4 is released, it will consist only of these toggles becoming the default.

Typechecking the elephant in the room

Although Typescript has been ubiquitous in web development for years now, a small but meaningful corner of web frameworks has remained largely untyped: route params, search params, and cross-references for file-based routes.

Source: https://x.com/gill_kyle/status/1835340921535332433

In 2024, we saw upstart framework TanStack Start tackle this with a fresh approach that brings 100% end-to-end type safety to file-based routing—and much of it inferred. On the other hand, Remix successor React Router 7 moved away from fully-file-based routing and introduced a type generation step in order to achieve similar outcomes. Meanwhile, Next.js, Nuxt, and Qwik are cooking up their own solutions.

Emerging frameworks pushed the ecosystem forward

As made evident by all the movement above, this is a fast-moving space. Much of that is due to innovation and pressure from emerging frameworks. Here’s a quick reference of the ones on our radar this year—and good fodder for your weekend projects in 2025?

AnalogJS, an Angular meta-framework (stable since March 2024)
Deno Fresh, a Preact-based framework optimized for edge rendering (stable since June 2022)
HTMX, a return to basics (stable since November 2020)
One, an experimental React-based framework (just announced in October 2024)
RedwoodJS, a batteries-included full-stack React-based framework (stable since April 2022)
SolidStart, a Solid.js meta-framework (stable since May 2024)
TanStack Start, a new React meta-framework (in beta since December 2024)
Qwik, a novel framework that introduces resumability instead of hydration (stable since May 2023)

News

Major releases

These are the (eleven!) major front-end framework releases that happened this year:

March 14: AnalogJS 1.0
May 21: SolidStart 1.0
May 22: Angular 18
September 6: RedwoodJS 8
October 2: Eleventy 3
October 19: Svelte 5
October 21: Next.js 15
November 19: Angular 19
November 22: React Router 7 (aka Remix 3) (ICYMI: on May 15, Ryan Florence dropped a bomb at React Conf by announcing the Remix framework and the React Router library would merge and the Remix brand would “take a nap”!)
December 3: Astro 5
December 5: React 19

Some other projects had notable releases as well:

April 24: Node.js 22
August 28: Rspack 1.0
October 3: bolt.new
October 9: Deno 2
November 26: Vite 6

Sponsorship and funding changes

Some key projects announced partnership or funding news:

March 26: Builder.io spun out Qwik as a community-owned project
April 24: Builder.io (maintainers of Qwik) raised $20M in funding
July 15: Astro partnered with Netlify
September 30: Evan You founded VoidZero, a VC-backed company, to provide funding ($4.6M) and stability to Vite, Vitest, Rolldown, and OXC
December 2: Astro partnered with Google

Honorable mentions

Source: https://www.solidjs.com/blog/solid-start-the-shape-frameworks-to-come

Frameworks showed renewed interest in single-flighting requests from the browser: Remix introduced Single Fetch (now the default in its successor React Router 7), SolidStart 1.0 shipped with Single Flight Mutations, and TanStack Start is working on the same.

Angular shipped event replay: retroactively applying user interactions that occurred on parts of the page that hadn’t yet been made interactive. It remains to be seen if others will follow suit. In the meantime, Qwik sidesteps the problem entirely by designing for resumability.

Astro stole our hearts by proactively collaborating with the ecosystem to improve the web platform when it found it had reached its limits, making the web better for everyone in the process.

Much of the web development community suddenly migrated to Bluesky at the end of 2024.

What to expect in 2025

Source: https://vite.dev/guide/api-environment

If you’re looking for bold predictions for 2025, look elsewhere. Here are some sure bets we expect in the next year:

Angular releases occur on a fixed schedule, so expect to see Angular 20 in May and Angular 21 in November. Check out the Angular roadmap for hints on what will ship.
Node.js 18 will reach End of Life (EOL) status in April. That only leaves you four months to upgrade your apps. (Upgrade your Netlify builds and functions to Node.js 22 now!)
Nuxt 4—which has been all but ready for months as of writing—will go stable. (Opt in early on Netlify now.)
The Vite Environment API, shipped in Vite 6 at the end of 2024, will lead to great improvements in local dev experience for many Vite-based frameworks, particularly in terms of stability, production parity, and runtime compatibility. (Expect developing Netlify sites to get even simpler 👀.)
TanStack Start, after shipping a beta release at the end of 2024, will ship a Release Candidate in 2025—maybe even a 1.0?
Qwik 2.0 will be released.
TanStack and Netlify will cook something up 👀.

Closing remarks

Whew, you’re all caught up. Stay informed in the new year by following the Netlify Changelog.

What will you build this year?

❝Every now and then I get a random Access Denied page...❞

Thu, 01 Feb 2024 00:00:00 GMT

We received a bug report from one of our customer service associates (let’s call her Sarah) that went something like this:

When I’m using [internal customer service web app], every now and then I get this “Access Denied” page.

I fire off some follow-up questions and start checking the usual suspects: Sarah’s user has the expected roles, her browser is supported and up to date, and so on.

I open up our error tracking service, Rollbar, and find some recent occurrences of HTTP 403 errors for Sarah in this app, coming from the backend service.

It isn’t obvious why a 403 would be returned – according to Rollbar, Sarah’s authentication token is valid, her user has the expected roles, and the resources being accessed should be accessible to her.

Upon closer inspection

I try to reproduce this locally. I spin up development instances of the backend and frontend, and click around. I load up similar pages. I log in as a user with the same privileges as Sarah. No errors.

When I go back to Rollbar, something catches my eye:

{
  "firstName": "Sarah",
  "lastName": "Lastname",
  "email": "sarah.lastname@example.com",
  "roles": ["customer_service", "manager"],
  "tempWorker": "********"
}

What’s this ”********” about? I vaguely recall having seen (and promptly ignored) this string in Rollbar details before, but I’d never thought much of it.

It occurs to me at this point that tempWorker is a field involved in authorization and I’m trying to explain mysterious “access denied” errors. It certainly seems like a plausible connection. Is this just a red herring? Is this even worth pursuing?

I check all the other 403 occurrences for Sarah: they all show ”********”.

I check occurrences of other, non-403 errors for Sarah: they all show "tempWorker": false.

I check 403 occurrences for other users: they all show ”********” as well.

In the meantime, Sarah has responded to my follow-up questions and let me know that “this happens randomly, rarely, to everyone” and they’ve learned to just “log out and back in and that usually fixes it.”

It seems we’re on to something here. It seems unlikely, but all signs point to this false unexpectedly being ”********”, rarely, and randomly, and this being either the cause of — or correlated with — the issue.

Okay. Where do we go from here?

Auth overview

I remind myself how authentication and authorization work in this Node.js service:

Authenticated requests from the browser are sent with a user cookie, containing a signed JSON Web Token (JWT).
When handling a request, the Express.js web server runs an auth middleware that decodes the JWT, verifies its signature and expiry, and populates a hydrated user session object (containing fields like email, roles, tempWorker, etc.) from the resulting payload as req.user.
Before accessing a resource, downstream middlewares use values from req.user to check the user’s permissions against the resource. When a check fails, we return a 403.
Finally, before sending the response, the auth middleware from step 2 checks if req.user has been changed. If so, it set a Set-Cookie response header so that the browser can store an updated JWT.

Working backwards from this, I reasoned that if something were to overwrite req.user.tempWorker during the request handling lifecycle, the new value would be saved by the browser and sent to the server on subsequent requests. Sarah also reported that logging out and back in is the only workaround, which aligns with this hypothesis.

💡 Insight #1: In-memory corruption of the JWT payload may only be reflected on subsequent requests.

Now, remember step 3 above? Ultimately, somewhere there’s a bit of code along the lines of:

if (req.user.tempWorker) res.sendStatus(403);

Simply put, users who are “temp workers” can’t access anything in this app.

Wait — let’s look at that again and fill in the value we’re seeing:

if ("********") res.sendStatus(403);

In JavaScript, nonempty strings evaluate to true. I’ll spare you the embarrassing amount of time it took me to make that connection. This code and I were both expecting this field to always be a boolean.

💡 Insight #2: Any truthy value for tempWorker would result in a 403… and ”********” is truthy.

These ******** asterisks

Okay, we have a working theory. But where are these asterisks coming from?

After clicking around in Rollbar, I see something like this and the answer is immediately obvious:

{
  "apiToken": "********"
}

This is Rollbar’s mechanism for scrubbing sensitive information!

What’s going on here? We still have two big mysteries to solve:

Why would a field called tempWorker be scrubbed?
Why would this cause issues in our app if scrubbing is a downstream transformation at the Rollbar reporting level?

We’ve arrived at the most unbelievable part of the story. Pause here, and try to guess. (Good luck.)

The “tempWorker” mystery, solved

Give up?

The answer to the first question occurred to me suddenly, lying in bed later that day. The question needed to be reframed: What was special about the string “tempWorker” but not “email” or “roles” if you’re trying to scrub sensitive fields?

tempWorker

Oh no.

💡 Insight #3: “pw” is a common abbreviation of “password”.

Could Rollbar be checking, case-insensitively for the substring “pw” anywhere in a field name and scrubbing the corresponding value?

This must not come up often. You don’t see “turnipwood” or “shipwright” very often in a JSON key.

I checked the rollbar.js documentation on scrubbing and found this:

scrubFields A list containing names of keys/fields/query parameters to scrub. Scrubbed fields will be normalized to all * before being reported to Rollbar. This is useful for sensitive information that you do not want to send to Rollbar. e.g. User tokens

Default: ["passwd", "password", "secret", "confirm_password", "password_confirmation"]

Though this confirms the scrubbing happens in the Rollbar SDK (“client side”), “pw” was not listed and there’s no mention of substring matching. I almost abandoned this hypothesis at this point.

Luckily, I decided to check the library’s source code for good measure and there it was… “pw” and 30 other undocumented patterns:

"scrubFields": [
  "pw",
  "pass",
  "passwd",
  "password",
  "password_confirmation",
  /* .... */
]

The docs were lying to me! What else might they be lying about? I pulled up the scrubbing code and found this regular expression:

new RegExp(
  "\\\\[?(%5[bB])?" + scrubFields[i] + "\\\\[?(%5[bB])?\]?(%5[dD])?",
  "i",
);

Uhh. What? Let’s simplify this, using “pw” as an example:

/\\\[?(%5b)?pw\\\\[?(%5b)?\]?(%5d)?/i

What are %5b and %5c? Let’s check with a browser console:

> decodeURIComponent('%5b')
"["
> decodeURIComponent('%5d')
"]"

OK, let’s break it down then:

\\\[? ← 0 or 1 left bracket
(%5b)? ← 0 or 1 encoded left bracket
pw
\\\[? ← 0 or 1 left bracket
(%5b)? ← 0 or 1 encoded left bracket
\]? ← 0 or 1 right bracket
(%5d)? ← 0 or 1 encoded right bracket

Most of this appears to be attempting to capture the full field name, but these capture groups aren’t used… Let’s move on.

The takeaway is that this matches strings that contain “pw” anywhere. This uncovers a second inaccuracy in the docs.

Narrowing in

At this point, two mysteries remained:

Why would the Rollbar reporting module’s scrubbing mechanism affect our application’s behaviour at all? Shouldn’t it only affect what ends up in Rollbar?
Why does this bug occur, as Sarah described it, “randomly”?

It turns out these questions are related.

Rollbar is an error reporting tool. So, when does an error get reported to Rollbar from this service? There are a few scenarios (logged error, uncaught exception, unhandled rejection, etc.), but let’s focus on the happy path: an error has been logged via our logging module:

logger.error({ foo: "extra data" }, err);

In this service, a request logging middleware automatically logs an error whenever a request responds with a 5xx status code.

In this logging module configuration, API requests to Rollbar are nonblocking. In the context of a request our service is handling, this is asynchronous, running in the background, and does not block our delivery of a response.

So, at last, here’s the final puzzle piece solved:

💡 Insight #4: When an error is “logged” in a request handler, the actual logging side effects nondeterministically occur either before or after the response is delivered.

It’s a race condition:

|------------- Request lifecycle -------------|
|^ Start handling request                     |
|         ^ "Log" an error                    |
|                                             |
Scenario 1:                                   |
|            ^ Finish flushing the error      |
|                 ^ Send request response     |
Scenario 2:                                   |
|            ^ Send request response          |
|                 ^ Finish flushing the error |

And it only matters because…

💡 Insight #5: rollbar.js mutates error payloads!

It was obvious from the observations above, but I easily confirmed this by reading the source code.

To summarize: when a request is about to respond with a 5xx status code, an error is logged, and a race condition occurs — if the response is delivered first, great; but if the error payload is scrubbed first (right before being sent to the Rollbar API), this scrubbing mutates req.user such that when the response is about to be delivered, a frivolous and corrupted Set-Cookie header is attached to the response.

When this occurs, the browser updates its cookie with the updated payload. On subsequent requests, this corrupted cookie is sent along via the Cookie header. The JWT in the cookie is perfectly valid, correctly encoded, and cryptographically signed with the service’s secret, so it’s validated, decoded, and parsed by the service and used to populate req.user. The auth middleware sees a truthy req.user.tempWorker (the string ”********”) and sends a 403.

Case closed.

The fix

“Fixing” the bug was the boring part. I applied a temporary fix to clone the user object before logging it, and I opened three rollbar.js issues (one, two, three).

Lessons learned

What are my takeaways from this story? I have only some scattered thoughts:

When investigating difficult bugs, you often need to ignore your instincts. Your instincts tell you “X should work this way” and gloss over X, and “Y should work that way” and gloss over Y, and pretty soon you’re glossing over everything; but something, somewhere isn’t working how it’s intended. Ignore your instincts and follow only the evidence. Write down or say out loud only what you truly, truly know for certain, and draw only logical conclusions from there — or, identify areas where evidence is still missing, devise a way to gather it, and repeat.
In general, it’s safe to assume the bug is likely in your source code. Occasionally, it’s in a library. Sometimes though, it’s three library bugs wearing a race-condition trench coat. Sometimes.
None of this would have been possible with a robust type system… but that’s a post for another day.

Thanks for reading.