Exploring Qwik as a High-Performance Alternative for a Complex Publishing Stack

At Fueled , we stay close to what’s evolving in the front-end ecosystem; not just to experiment, but to be ready with informed guidance when a project calls for a fresh approach. (In case you missed it, the company I joined, 10up , is now the brand of our WordPress practice at Fueled, following a big brand refresh.)

That mindset came into play when Minute Media partnered with Fueled to modernize the front-end architecture behind their large-scale publishing platform, an infrastructure powering hundreds of sites, including Sports Illustrated and SI Swimsuit.

They needed a front end that integrated with their proprietary CMS, prioritized performance (particularly time to interactive), and worked well for React-savvy developers. While React and Next.js remained on the table, the client was eager to explore options that might reduce JavaScript execution costs and improve long-term maintainability.

This post walks through how we assessed various frameworks, where tradeoffs emerged, and why Qwik’s approach to performance and developer experience made it the right fit in this specific context.

Identifying the Right Fit for a Complex Front-End Rebuild

A major part of wanting to rebuild the infrastructure was to lay down a base that could achieve performance gains (prior to adding 3rd party javascript), in the hope that their entire stack could eventually be performance-optimized to gain an SEO advantage. They also wanted a codebase that was easier for other developers to work with.

Although avoiding React/Next wasn’t an absolute requirement, they wanted to explore other options as they currently were not getting the performance that they wanted out of React – specifically, they mentioned their Javascript execution time, and thus time to interactive, was too high.

Underscoring this desire to move away from React, they had already built an initial POC with Express and ETA.

The Alternatives

In choosing a framework, I looked at several possibilities. I’ll quickly describe them and then show a simple Button component for developer experience comparison.

React and Next.js

Given the client’s skepticism about React/Next.js, choosing this option meant that I would have to convince them that they weren’t using these techs in the most performant way, currently. I did see some things in the codebase that were overly convoluted and used more code than they might need. But because the client wanted to rebuild the front end incrementally, I didn’t have the full context of what an ultimate React/Next.js rebuild would look like. This made it hard for me to guarantee that we’d be able to avoid a similar fate with the new codebase. Further, although App Router has made significant improvements, hydration costs can still be high with a large application.

The biggest advantage to using React was that Minute Media’s developers were used to it.

Here’s a button component in React:

Svelte and SvelteKit

Svelte and SvelteKit use a similar hydration technique to React, which would probably end up with similar performance. Additionally, the syntax would be unfamiliar for React devs. For example, here’s that same button in Svelte:

Solid and Solid Start

Solid with Solid Start seemed as though it may offer the performance desired due to its fine-grained reactivity model. While it still uses hydration, it minimizes unnecessary renders by directly updating only the parts of the DOM that need to change. And developers coming from React would be familiar with the JSX syntax. Here’s the button again in Solid:

Vanilla Javascript with a Light Templating Engine

While this option would likely be performant, even with their small POC, I was seeing issues with props drilling in the templates. It seemed like once the application grew, the developer experience would really start to suffer, especially for developers that were used to building components in React. Here’s the button using the ETA templating engine:

Qwik with Qwik City (The Recommendation)

Qwik diverges from the hydration model considerably, offering significant performance gains, especially in time to interactive. It does this with what it calls, “resumability.” That link goes into a lot of detail about what that means, but I’ll try to summarize.

Essentially, instead of downloading the React bundle and having React parse and reconstruct the virtual DOM (which delays interactivity), Qwik “pauses” execution on the server and resumes in the client. No hydration happens immediately, and instead the Javascript is loaded on demand, in tiny, individualized files, when needed by an interaction.

Here’s that button component in Qwik:

Ultimately, I decided to recommend Qwik and Qwik City. While I had to caveat my recommendation with the fact that the community around Qwik isn’t nearly as robust as React and Next, the combination of developer experience and performance seemed to fit the client’s request perfectly.

Hydration vs. Resumability

The key difference between Qwik and NextJS is how Javascript is executed in the client.

What is Hydration?

Hydration is the process of taking a server-rendered HTML page and attaching client-side JavaScript to make it interactive. In frameworks like Next.js, pages are often pre-rendered on the server (SSR or SSG) and then hydrated in the browser to enable client-side interactivity.

How Hydration Works in Next.js (Pages Router)

1. Server-Side Rendering (SSR) or Static Generation (SSG)
2. Client-Side JavaScript Loads
3. Hydration Completes

Example of Hydration in Next.js

What Happens?

1. The server sends this page as plain HTML with h1, p, and button.
2. The browser renders the HTML instantly.
3. React’s JavaScript loads and hydrates the page by:
4. Now, clicking the button updates the count dynamically.

What About App Router?

App Router does improve on this considerably with the “use client” directive, Suspense boundary, and dynamic imports. But there’s still a hydration step needed, whereas Qwik only sends a tiny bit (around 1kb) of initial JS to attach the event listeners that enable resumability.

Additionally, the fact that Qwik handles all of this without the developer having to think about the separation makes it much easier to work with.

Issues with Hydration

Mismatch Between Server and Client HTML

If the server-generated HTML doesn’t match what React expects on the client, you’ll see a hydration warning.

Example:

• The server renders a number like 0.8432.
• The client hydrates with a different number like 0.1923.
• Mismatch error!

Heavy JavaScript Hydration

If your page has too many interactive elements, hydration can be slow and no interactivity works until React fully re-renders the page and attaches events.

What is Resumability?

1. Server sends HTML + a small amount of JavaScript.
2. Qwik pauses execution on the server.
3. When a user interacts with the page, only the needed JavaScript is loaded.

Why Resumability Is Faster

• No hydration step: The app is interactive instantly because event listeners are already in the HTML.
• JavaScript runs only when needed: Instead of downloading the entire app, Qwik loads only the necessary code for the interaction, in tiny, individual files.
• Zero hydration mismatches: Since Qwik doesn’t “re-hydrate” the page, there’s no risk of mismatches.

Example in Qwik

• The page loads instantly.
• Only when the user clicks the button is the event handler code downloaded and executed.
• No need for hydration because Qwik resumes from where the server left off.

Why We’re Paying Attention to Qwik

Qwik’s architectural approach—especially its “resumability” model—offered tangible benefits in this case: lower time to interactive, fewer hydration pitfalls, and a surprisingly smooth onboarding experience for developers coming from React.

But this isn’t a universal prescription. React continues to evolve, and the ecosystem around Qwik is still maturing. Our goal wasn’t to find a silver bullet. It was to find the best fit given the client’s goals, team, and performance requirements.

That process—of evaluating new tools with clear-eyed rigor and real-world constraints—is core to how we approach front-end architecture at Fueled. Staying curious, testing assumptions, and validating results in production environments helps us better serve our clients, and contribute thoughtfully to the broader web development community.

If you’re exploring ways to modernize a complex front end or want to collaborate with me or other engineers who think this way, reach out to Fueled. We’re always up for solving hard problems with teams that care about getting it right.