FAQ

@QwikDev は自己認識のある AI ですか？

はい、そしてとても面白いです！フォローしてください

なぜ Qwik という名前なのですか？

元々は *qoot* という名前でしたが、検索しにくいと考えました。コミュニティメンバーの @PatrickJS__ が *Qwik* という名前を提案し、builder.io の社内投票の後、名前を変更しました！

Qwik は他のフレームワークとどう違いますか？

Qwik は、コンポーネントの作成において *React*、*Vue*、*Svelte* と同様の開発者エクスペリエンス（DX）を提供する最初のフレームワークです。 瞬時にインタラクティブな **ライブHTML** を提供し、ハイドレーションの必要性を完全に排除することで実現しています。 Qwik アプリケーションは、ユーザー操作時にアプリの状態全体をブートストラップする必要がなく、イベントハンドラをすぐに実行します。 この技術は 再開可能性 と呼ばれています。

その結果、開発者は意識することなく、デフォルトで非常に高性能なアプリケーションを作成できます。 Qwik で構築されたアプリケーションは、コンポーネントの数や複雑さに関係なく高速であり、JS ペイロードに関して O(1)（一定時間）です。

なぜまた新しいフレームワークが必要なのでしょうか？

簡単に言うと、Qwik は他のフレームワークでは解決できない問題を解決するからです。 Qwik は、アプリケーションの複雑さに関係なく、インスタントオンの起動パフォーマンスを実現します。 Qwik アプリは、コンポーネントの数に関係なく、同じ量の初期 JS を提供します。Qwik は最初のオープンソース O(1) フレームワークです。

Qwik City とは何ですか？

Qwik City は、Qwik の上に構築された追加の API セットです。 それを *Qwik* をコア、*City* を追加の API（ルーティング、データ読み込み、エンドポイントなど）と考えてください。 私たちはそれを Qwik のメタフレームワークと呼んでいます。 Qwik City と Qwik の関係は、Next.js と React、Nuxt と Vue、SvelteKit と Svelte の関係に似ています。

Qwik は学習が難しいですか？

Qwik は React（およびその他の JSX ベースのフレームワーク）を念頭に置いて設計されており、簡単に学習でき、迅速な生産性を促進します。 コンポーネントの開発は React とほぼ同じであり、ルーティングは Nextjs などからヒントを得ています。

しかし、新しい概念、例えば 再開可能性 やきめ細かいリアクティブ性などを学ぶ必要がありますが、学習曲線は急峻ではないと考えています。

また、インタラクティブな チュートリアル も用意されています。

それらの $ 記号は何ですか？

Qwik アプリでは、通常よりも多くの $ 記号（例：component$()、useTask$()、<div onClick$={() => console.log('click')} /> など）を見かけるかもしれません。これは、遅延読み込み境界のマーカーとして機能します。 Qwik はアプリケーションを小さなチャンクに分割します。これらのピースはコンポーネント自体よりも小さいです。 イベントハンドラ、フックなどでは、$ は オプティマイザー と開発者の両方に、それがいつ発生するかを知らせます。

例

import { component$ } from '@builder.io/qwik';
 
export default component$(() => {
  console.log('render');
  return <button onClick$={() => console.log('hello')}>Hello Qwik</button>;
});

$ 構文のおかげで、上記のコンポーネントは次のように分割されます。

import { componentQrl, qrl } from '@builder.io/qwik';
 
const App = /*#__PURE__*/ componentQrl(
  qrl(() => import('./app_component_akbu84a8zes.js'), 'App_component_AkbU84a8zes')
);
 
export { App };

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',
  });
};

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

注：$ は jQuery、Svelte、または他のフレームワークとは関係ありません。

ユーザー操作時に JS を要求するのは遅くありませんか？

ユーザー操作時に *ダウンロード* する場合のみです。 その代わりに、Qwik は サービスワーカー を介してバックグラウンドスレッドで現在のページの JS モジュールを *プリフェッチ* し、ユーザーがアプリケーションと対話する際にブラウザの キャッシュ からそれらのモジュールを *取得* します。

この戦略は 推測的モジュールフェッチ と呼ばれ、再開可能性によって有効になります。 ハイドレーションフレームワークは、イベントハンドラを取得するために、ページ読み込み時にコードを熱心にダウンロードして実行する必要があり、そのため、推測的モジュールフェッチを利用できません。

Qwik は何を、どのような順番でプリフェッチするかをどのように認識するのですか？

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

In addition, Qwik insights can be used 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.

Are Qwik apps slow on slow networks?

Quite the opposite.

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

In fact, thanks to Qwik's ability to reduce network waterfalls, it is likely that the requested modules have already been downloaded and stored in the browser's cache at the time of interaction. And even if they haven't yet been cached, Qwik can avoid duplicating the requests and can instead keep fetching the modules that are being requested to start executing them as soon as possible.

As a result, Qwik apps get to be responsive much faster, especially 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 more efficiently.

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

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

Notice that JSX is not React. In fact, JSX is only syntax without semantics. We chose JSX for several reasons

• Familiar syntax: It does not reinvent the wheel but leverages existing JS for loops, conditions, etc. JSX spec is a surprisingly short read
• Ecosystem: Well supported by IDEs, linters, security auditing tools, debugging tools, and highlighters.
• 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: By any margin, JSX is the most widely used template syntax in the world.

Does Qwik use a vDOM (Virtual DOM)?

Qwik uses vDOM only sometimes, and other times it does what SolidJS does (direct DOM update.)

The way to think about it is as follows

If the change in state does not have a structural change then Qwik will most likely not use vDOM. For example

export const NoStructuralChange = component$(() => {
  const count = useSignal(0);
 
  return (
    <>
    {/* This will not cause vDOM to activate. (No DOM structure change, only update text value) */}
     <div>Count: {count.value}</div>
     <button onClick$={() => count.value++}>+1</button>
    </>
  );
});

When there is a structural change, Qwik utilizes the virtual DOM (vDOM). In the following example, the DOM structure needs to be updated (replace <h1> with <button>), so vDOM will be used for rendering

export const StructuralChange = component$(() => {
  const isLoggedIn = useSignal(false);
  return (
    <div>
      {isLoggedIn.value ? <h1>you are logged in!</h1> : <button>Log in</button>}
    </div>
  )
});
 

The important thing to understand is that vDOM doesn't cause performance issues in Qwik. In React, however, invalidating a root component results in vDOM for the whole tree getting created. In Qwik, the decision is made on a per-component basis. And only for components that have structural change AND are changing their structure. If a component is structural (vDOM) but no change in structure is detected, then Qwik skips the component. You can think of it as auto-memoization of all components, this means that vDOM is only employed when the view is changing structurally. This is rare because in most cases the view only changes its values.

In short, Qwik uses vDOM, but significantly less than React in comparable situations.

Why use a vDOM despite its negative reputation?

The question of whether or not to use a vDOM can be seen as a spectrum

• On one extreme is React which uses vDOM for everything all the time. (Good argument can be made that vDOM is slow.)
• On the other extreme is SolidJS which does not use vDOM at all. (Resulting in a very impressive performance.)

Qwik on the other hand uses a vDOM sparingly for two reasons

1. Because non-vDOM solution would require executing code at least once on startup to learn about the component structure. (Something which Qwik explicitly avoids.)
2. Because vDOM has attractive DX properties, especially when you need dynamic components.

For example

const DynamicList = [ CompA, CompB, ...];
export const DynamicExample = component$(() => {
  const idx = Math.floor(Math.random() * DynamicList.length);
  const Component = DynamicList[idx];
  {/* Dynamically chose which component to render */}
  return <Component/>; 
})

The above code <Component/> is super easy to understand. We are dynamically choosing a component to place there. But in Solid, Svelte, Vue, and Angular, this gets complex (see links).

We have the best of both worlds by using a vDOM sparingly. During creation, we employ SSR, and most client updates are non-structural. When structural updates are necessary, they are localized to the specific component without affecting its children, thus containing any potential slowdown caused by vDOM.

Is there a Router for Qwik?

Yes! Qwik City includes a directory-based router, inspired by Next.js 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 adapters. We also support a vanilla-node adapter for Node.js-based servers, such as Express.

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

Which is faster: SPAs (Single-Page Application) or MPAs (Multi-Page Application)?

It depends. For SPAs, most of the cost is paid upfront by 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 as they don't need to download as much JS as their SPA counterparts. However, when the user navigates, it usually requires a full page reload. A full-page reload is typically super fast because browsers are extremely fast at downloading and parsing HTML. But, since sometimes, it's ideal to keep state between navigation, the MPA approach is not ideal for every project. In this case, SPA does that very well.

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

Can Qwik do SPA?

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

MPA vs SPA is no longer an architectural decision taken at the 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.

Can't I create an MPA or SPA with other frameworks?

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 becomes 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 require a lot of effort?

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 of 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.

In which languages is Qwik written?

Most of Qwik is written in TypeScript, a superset of JavaScript that adds optional static typing and other features. However, the Qwik compiler (or optimizer) is written in Rust, a language that is very fast and memory efficient.

Qwikにはコミュニティがありますか？

はい！DiscordとGitHubには、成長を続けるQwik開発者のコミュニティがあります。彼らはフレームワークに素晴らしい貢献をし、大規模なサイトを構築し、互いに助け合っています。参加しましょう。

Qwikは「Alex Russell承認済み」のフレームワークですか？

はい！PWA、W3C TAG、WC、TC39 & ES6、Chrome Frame、Dojoなどへの貢献で知られるAlex Russell(@slightlylate)は、JavaScriptフレームワークに対してしばしば非常に批判的です。それにもかかわらず、彼はQwikを承認しています。

Qwikは本番環境で使用できますか？

はい！Qwikはすでにバージョン1.1です。Qwikは3年間開発されてきました。Qwikは本番環境で使用できるものと確信しており、破壊的な変更は予想されていません。

Builder.ioや多くのチームがすでに本番環境でQwikを使用しているので、あなただけではありません。

QwikはHTMLに過剰なデータをシリアライズするという噂は本当ですか？

違います。Qwikは現在のページに必要なデータのみをシリアライズします。ページに1000個のコンポーネントがあっても、インタラクティブなコンポーネントが1つだけの場合、シリアライズされるデータ量はコンポーネントの数ではなく、インタラクティブ性の量に比例します。

誰がQwikを開発していますか？

Discordで活動する世界中の素晴らしい貢献者チームと、Builder.ioのフルタイム開発者数名：Misko、Adam、Manu Almeida。

Qwikはオープンソースですか？

はい、MITライセンスで、依存関係なしです。Qwikをインストールしても、`node_modules`も弁護士も肥大化しません。

Qwikには欠点がありますか？

はい。すべてのフレームワークには、それぞれ長所と短所があり、トレードオフが含まれます。

1. 比較的新しいJSフレームワークであるため、Qwikのコミュニティとエコシステムはまだ開発中で、急速に成長していますが、より人気のあるフレームワークから慣れ親しんでいる可能性のあるすべてのコミュニティプロジェクト、パターン、ベストプラクティスが見つかるわけではない可能性があります。
2. Qwikは、どんな規模のJSアプリでも瞬時にロードできるため、現在のテクノロジーと比較した最大の利点は、最初のページロードと対話時間です。ユースケースがシングルページアプリケーションであり、アプリのロード時間に問題がない場合は、現時点でのQwikの採用はすぐにメリットをもたらさない可能性があります。

私たちは、開発者のエクスペリエンスと機能を継続的に改善し、あらゆるユースケースでQwikをより使いやすくするために取り組んでいるため、ご期待ください。