"Now, wait a minute . . ." you might be saying to yourself,
"Is it really fair to compare a framework that is production ready with one that is not production ready?"

️Probably not

However, I am not going to let that stop me from having a little fun. I created two repos about a month ago: AstroVueStaticSite and QwikStaticSite. They are two different versions of my website. In most ways, they are indistinguishable, but they aren't exactly the same.

Attempting to reach feature parity

Qwik isn't even v1 yet, but it does have a lot of bells and whistles that make it more appealing (to me) over Astro. Despite Qwik's lack of a hydration step, it generates MPAs with client side navigation that takes over after the first load, and this is because it introduces this entirely new concept of resumability. If you haven't heard of it, it makes hydration feel archaic. It makes me wonder why a lot of JavaScript meta-frameworks server-side render only to dispose of the current state and rehydrate on the client. It just seems wasteful. On the other hand, resumuability is quite conservative with its waste; the browser picks up with the framework right where the server left off. Rehydration isn't necessary because the state is serialized into the HTML; there is no need to regenerate the shadow DOM because the real DOM is already the truth.

That all being said, Astro is production ready, and while it doesn't do everything that Qwik does out of the box, it knows its scope. It solves the problem of generating static sites. It doesn't attempt to change anything about the paradigms of how JavaScript frameworks work, and in fact, it works with existing frontend UI frameworks such as Vue and Svelte. It introduces the idea of islands, but it doesn't fundementally change hydration; it only makes it an opt-in process on a component level.

How do we get client side navigation in Astro?

There is this JavaScript library known as @hotwire/turbo. It isn't anything new, but dang it, it handles client side navigation in a way which easily snaps into any existing MPA.

For instance, if you want to keep your layout on the page while the page content is the only thing that needs to change, all you need to do is add the following code to your `layout.astro` file:

javascript:

      
import * as turbo from '@hotwire/turbo'
turbo.start()
// everything below this is just to handle window scrolling
const beforeRender = () => {
  document.removeEventListener('turbo:before-render', beforeRender)
  // scrolls the page to the top
  window.scrollTo(0, 0)
}
document.addEventListener('turbo:load', () => {
  document.addEventListener('turbo:before-render', beforeRender)
})

    

html:

      
<!-- 
  data-turbo-action="advance"
  - makes the back button work
-->
<turbo-frame id="main-content" data-turbo-action="advance" >
  <!-- Surround the things that you want to change on your page with this element -->
  <slot/>
</turbo-frame>

Everything outside this frame will not change on page navigation.

Of course, there are other more complicated ways to use this powerful library, but I just wanted to demonstrate a very specific example. If you are interested in learning more about turbo-frames, this documentation was very helpful for me. There is also a quite informational video on how to do something similar to this with both this library and the Shared Element Transistion API available in Chrome.

More similar than you might think

Both use vite, both use directory based routing with square brackets for url parameters, both use JSX-like syntax to some extent, and because of this, a lot of things were very "copy and paste."

I used Vue along with Astro in order to achieve some of the client-side functionality I achieved with Qwik components, but I also used it because I like Vue. At the end of the day, this is the biggest difference between the repos: Vue vs JSX syntax.

Honestly, my biggest gripe about Qwik so far is it's insistence on being "React-like." As someone who is not a React developer, for fun or for profit, I feel like there are things I like about this syntax, but there are also things I find unintuitive about it such as `useWatch$` or I guess now `useTask$` in the latest development version of Qwik.

That is another thing. I would not recommend using Qwik at this point in time because it is not ready for production. If you start building a Qwik app at this point it time, you will have to make many revisions before a production ready version is released, and as such, I would highly recommend anyone interested in using Qwik to build an app, at this point in time, to seriously consider Astro + their favourite frontend framework instead. It is more stable. It is production ready now. It (probably) won't have major breaking changes before you release.

That all being said. I think Qwik is dank af, and resumability is the future of web frameworks.