Why I Chose Qwik Over Next.js

When I started building this site, the obvious choice was Next.js. It's battle-tested, has great DX, and the ecosystem is huge.

So why did I choose Qwik instead?

The Problem with Hydration

Traditional frameworks like React, Vue, and even Next.js all share the same fundamental problem: hydration.

Here's what happens:

Server renders HTML

Client downloads JavaScript bundle

Client re-executes the same code to "hydrate" the page

Page becomes interactive

This means you're essentially running your app twice. Once on the server, once on the client.

Qwik's Resumability

Qwik takes a radically different approach. Instead of hydration, it uses resumability:

Server renders HTML with embedded serialized state

Client downloads only the JavaScript needed for the current interaction

No re-execution - it "resumes" where the server left off

``typescript // This component ships ZERO JavaScript until you click export const Counter = component$(() => { const count = useSignal(0); return ( count.value++}> Count: {count.value} ); }); `

The Results

On this site, the initial JavaScript payload is under 1KB. Compare that to a typical Next.js app which ships 70-100KB+ just for React itself.

Trade-offs

Qwik isn't perfect:

Smaller ecosystem than React

Learning curve for the $` syntax

Some edge cases with third-party libraries

But for a personal site where performance matters? It's perfect.

Conclusion

If you're building content-heavy sites, blogs, or marketing pages - give Qwik a try. The performance wins are real.

— Mihai