FAQ

Is @QwikDev a sentient AI?

Yes, and I am very funny too! follow me

Why is called Qwik?

Originally it was called qoot, but we thought it would be too hard to search for. One friend of ours, @patrickjs__ came up with Qwik and after an internal poll at builder.io, we changed it!

Why another framework?

The short answer is that Qwik solves a problem that other frameworks can't solve. Qwik has instant-on startup performance no matter the application complexity. i.e. Qwik apps deliver the same amount of initial JS regardless of the amount of components. Qwik is the first open-source O(1) framework.

What is Qwik City?

Qwik City is just an extra set of APIs on top of Qwik, think of it like Qwik as the core, and City as the extra APIs (routing, data loading, endpoints...).

Is Qwik complicated to learn?

We designed Qwik to be extremely easy to learn and become productive in for React developers. Component authoring is pretty much the same as React, and routing is inspired by Nextjs and others.

However, there are fundamentally new concepts to learn, such as Resumability and fine grained reactivity, but we think the learning curve is not steep.

We also have an interactive tutorial to get you started.

What are all those `$`?

You might have noticed there are more $ than usual in Qwik apps such as: component$(), useTask$(), and <div onClick$={() => console.log('click')} />. It's not for nothing. Qwik breaks your application into small chunks; these pieces are smaller than the component itself. For event handlers, hooks, etc. the $ signals to both the optimizer and the developer when it's happening.

Example:

import { component$ } from '@builder.io/qwik';

export default component$(() => {
  console.log('render');
  return <p onClick$={() => console.log('hello')}>Hello Qwik</p>;
});

Thanks to the $ syntax, the component above is split into:

app.js

import { componentQrl, qrl } from '@builder.io/qwik';

const App = /*#__PURE__*/ componentQrl(
  qrl(() => import('./app_component_akbu84a8zes.js'), 'App_component_AkbU84a8zes')
);

export { App };

app_component_akbu84a8zes.js

import { jsx as _jsx } from '@builder.io/qwik/jsx-runtime';
import { qrl } from '@builder.io/qwik';
export const App_component_AkbU84a8zes = () => {
  console.log('render');
  return /*#__PURE__*/ _jsx('p', {
    onClick$: qrl(
      () => import('./app_component_p_onclick_01pegc10cpw'),
      'App_component_p_onClick_01pEgC10cpw'
    ),
    children: 'Hello Qwik',
  });
};

app_component_p_onclick_01pegc10cpw.js

export const App_component_p_onClick_01pEgC10cpw = () => console.log('hello');

Does Qwik download JS when the user interacts?

Nope. In production, Qwik uses a lot of information generated during SSR (Server-Side Rendering) to start prefetching only the bits of interactivity available on the current page as soon as possible (ASAP). This way, when the user clicks or interacts, the JS is already downloaded.

If Qwik prefetches JS, then what's the difference?

Prefetching is not the same as parsing and executing JS, and Qwik does not execute JS until the user interacts.

In addition, prefetching enables Qwik to prioritize the important parts of interactivity before the less important parts.

For example, the "buy now" button is more important than the "add to cart" button, so Qwik will prefetch the "buy now" button first, and then the "add to cart" button.

Qwik does not need to prefetch everything to start running, while other frameworks do need to download the whole critical path before they can start running because of hydration.

Are Qwik apps slow on slow networks?

Not at all! Thanks to prefetching Qwik apps are not more affected by slow networks than other frameworks. In fact because of the fine grained bundling and resumability, Qwik apps can become interactive with much less JS, effectively making them faster on slow networks.

Does Qwik generate too many small files?

In dev mode Qwik generates a lot of small files because it uses the Dev Vite.js server, but in production mode Qwik bundles files in a more efficient way.

Why does Qwik use JSX? Is it React under the hood?

Nope, React is not used at all, but Qwik uses JSX as the template syntax.

Notice that JSX is not React, in fact JSX is only syntax without semantic. We choose JSX for several reasons:

Very simple syntax: It does not reinvent the wheel, but leverage existing JS for loops, conditions... JSX spec is surprisingly simple and small
Ecosystem: Well supported by IDEs, linters, security auditing tools, debugging tools, highlighting...
Similar to HTML: JSX is visually and conceptually similar to HTML, a tree. Other template systems like html templates (lit-html) are not trees but arrays of tokens, making it harder to build on top and transform.
Popular: Like it or not, JSX is the most widely used template syntax in the world.

Is there a Router for Qwik available?

Yes! Qwik City includes a directory-based router, and it is inspired by Nextjs and others.

Do I need a server to deploy Qwik apps?

You can easily deploy a Qwik App in any serverless environment thanks to our adaptors, we also support a vanilla-node adaptor for Nodejs-based servers, such as Express.

You can deploy your Qwik app as a static site, if there is no need for SSR, thanks to our SSG (Static Site Generation) adaptor.

SPA (Single Page Application) or MPA (Multiple Page Application) is faster

It Depends. for SPAs most of the cost is paid upfront, downloading everything at the beginning of the session. So when a user interacts with the app the cost is minimal.

MPAs are extremely fast to load because they don't need to download that much JS, but when the user navigates it usually means a full page reload. A full page reload is usually super fast because browsers are extremely fast to download and parse HTML, but the MPA approach is not for everyone since sometimes it's ideal to keep state between navigation, and SPA does that very well.

Qwik is a unique framework that is both MPA and SPA at the same time.

Can Qwik do SPA?

Of course! Qwik City includes the <Link> component which triggers a SPA navigation. With Qwik, developers don't need to choose between SPA and MPA, every site is both at the same time.

MPA vs SPA is no longer an architectural decision taken at beginning of the project, but a decision made for every link.

Can Qwik do Static Site Generation (SSG)?

Yes! It's part of all Qwik City starters, learn how to do Static Site Generation here.

But... with other frameworks I can also do MPA and SPA

Not quite, other frameworks suggest removing all the <Scripts> at the root to generate an MPA, effectively removing all the interactivity along with the SPA navigation.

And if scripts are not removed, then each full-page reload become very expensive, because every page reload means that the framework needs to hydrate the entire page. Qwik, however, does not have a hydration cost for each page load.

Will migrating to Qwik be so much work?

It depends. if you are coming from React, porting your components to Qwik should be straight forward. But on top of that, thanks to Qwik React you can use all the React ecosystem, so you can use any of your React components, and any React library in a Qwik App.

Can I enjoy the rich React ecosystem?

Yes! Qwik can run React components natively, check out the docs.

You will be amazed!

Does Qwik do partial hydration?

No. Partial hydration (or island architecture), popularized by Astro, is about breaking the app into islands of interactivity to avoid full-page hydration where all existing components in the page need to be downloaded and executed.

For this to work, developers need to manually define the islands, and then manually describe in which situations they should be hydrated. The islands also cannot communicate with each other.

Instead, Qwik components do not hydrate at all. Qwik achieves this through a powerful serialization system that serializes only the necessary state in the reactivity graph. This way, the app can resume without eagerly running any JS.

We think resumability scales without the negative trade-offs of partial hydration.

Does Qwik have community?

Yes! there is a growing community of Qwik developers at Discord and GitHub. They are making amazing contributions to the framework, building sites at scale and helping each other. Join us.

Is Qwik production ready?

Yes! but it depends. Qwik has been in development for 2 years now, and we reached the beta milestones, meaning that we are confident that Qwik is ready for production, and there are not expected breaking changes.

Builder.io and a lot of teams are already using Qwik in production, so you will not be alone.

Qwik serializes too much data in the HTML

False. Qwik serializes only the data that is needed for the current page. If a page has 1000 components but only one is interactive the amount of data serialized is proportional to the amount of interactivity, not the amount of components.

Who builds Qwik?

An amazing team of contributors around the world living in Discord, and a few full time developers at Builder.io: Misko, Adam and Manu Almeida.

Is Qwik open source?

Yes, MIT and dependency-free, installing Qwik will not bloat your node_modules nor your lawyers.

Does Qwik have any downsides?

Yes. Every framework, possessing its own strengths and weaknesses, involves a trade off.

As a relatively new JS framework, Qwik's community and ecosystem are still under development and while growing rapidly, you might not find yet ALL the possible community projects, patterns and best practices you're used to from more popular frameworks.
Qwik can load JS apps of any scale - instantly, so its main advantage over current technologies is on initial page load and time to interactive. If your use case is a single page app and you don't mind the time it takes your app to load, adopting Qwik at this stage might not offer you immediate benefits.

We are constantly working on improving the developer experience and capabilities to make Qwik delightful to use for any use case, so stay tuned.

FAQ