トップカバー

ご挨拶

こんにちは。saffronです。
今回は私が所属しているFASTにおいてSvelteを選んだ理由や実際にどのような良い点があったかを、主に技術的観点からお話できればと思います。

FASTにおける技術選定

私たちFASTでは、以下の基本方針に則って技術を選定しています。

高パフォーマンスが実現できる技術を選定する
サービス全体でなるべく技術一貫性を保ち、複雑さを抑える
メンテナンス性と拡張性が高い技術を選定する

この基本方針にあるように、私たちはパフォーマンスを維持しながらメンテナンス性を維持できる言語や仕組みを採用していくことに注力しています。
この方針に従って、以下の技術スタックを採用しました。

バックエンド: Rust
モバイルアプリケーション: Kotlin

では、この基本方針に則った最適なフレームワークは何なのか？を考えました。

弊社には現状、主にバックエンドエンジニアの背景を持つエンジニアと、デザイナーとしてキャリアを歩んできた方が多く在籍しており、HTML/CSSを書けるデザイナーと、PHP/Goなどのようなテンプレートエンジン的な記述に慣れているバックエンドエンジニアの双方が理解しやすく、歩み寄りやすいフレームワークとしてSvelteが選択肢になりました。

Svelteが私たちに提供してくれたもの

私たちが実際にSvelteを採用したことで実際に得られたものはいくつかありましたが、その中でも最大のポイントはコンパイル型のフレームワークであることによって多くの利点を得られたことです。

仮想DOMを捨てた、コンパイル型のフレームワークであることによる利点

SvelteはReactなどが仮想DOMを使用し、リアクティブ性を実現しているのとは異なるアプローチを取っています。
Svelteは実行前にビルドプロセスがあり、純粋なHTML/JS/CSSとしてクライアントに提供されており、これが多くの利点をもたらしています。
私たちは主に以下の点において、Svelteの良さがあると感じています。

バンドルサイズが小さい
ロード時間を短くし、FCPを改善
レンダリング順などをチューニングするパフォーマンスチューニングのコスト削減

バンドルサイズ

Reactは仮想DOMを使用しており、その関係上ランタイムとしてのJSライブラリが大きく、チューニングしても削減できないロードやレンダリング時間としてそれが表面化することが多くあります。
Svelteは仮想DOMを使用せず、リリースのバンドルサイズがReactと比較してかなり小さいことが知られています。

ロード時間・FCPの改善

FCP(First Contentful Paint)は、ページ内で最初のコンテンツがレンダリングされるまでの時間を示し、Webページを作る上で最も重要な指標と言っても過言ではない指標です。
Googleのパフォーマンス分析ツールである、web.devでもこのことは大きく取り上げられており、FCPの低下は顧客と提供者双方にとって機会の損失であることが明確です。

Svelteはバンドルサイズが小さく、仮想DOMのランタイムロード時間が無いため、FCPが標準的に速い傾向にあります。仮想DOMはオーバーヘッドであるというのはSvelteの作者である、Rich Harris氏がSvelte公式のBlog内で力説しており、FCPの高速化が求められる現代ではSvelteは現代の要求に即したフレームワークと言えます。

パフォーマンスチューニングのコスト削減

Reactなどで複雑なWebアプリケーションを作成した際に課題になるのが、不要なレンダリングや再計算のコストが高くそれをチューニングするために膨大な時間を費やす必要があるという点です。

軽量なアプリケーションであればさほど問題にならないこともありますが、大規模になってくると複雑なeffectやmemo化、ただでさえ複雑になりやすい状態管理において、今のプロジェクトで採用している状態管理ライブラリは何だったか(Redux/Zustand/Jotai...)など、考慮しなくてはならないことが増えてしまいます。
これらの考慮事項は、後からのパフォーマンス改善のタスクがチームの負荷になりやすく、開発チームが新しい機能を作ることに専念できなくなってしまいます。

ReactやVueを選ばなかった理由

フロントエンドのフレームワークを選択する際に、最初に選択肢に挙がるのはReactだと思います。
しかし、ReactはuseEffectやuseState、それぞれの状態管理ライブラリの使い方など複雑な点が多く、フロントエンドを専門にしていない人からするとつまづきやすいポイントがいくつかあります。

この際にポイントとなるのは近い書き方をするVueとの比較になります。Vueは<template>タグでのテンプレートを使用してリアクティブさを提供する形で、これはSvelteの構文と似た特徴があります。

しかし、Vueと比較した際に以下のようなコードではSvelteの方が見通しが良いと考えました。

Vue:

<li v-for="item in items">
  {{ item.name }}
</li>

Svelte:

{#each items as item}
    <li>{item}</li>
{/each}

Svelteの構文はHTML/CSSからある程度独立しており、Vueよりもどの要素がeachされるのか？が明確になると考えました。
Svelteの書き方はPHPやGoにも通じるものがあります。

PHP:

<?php foreach ($items as $item) { ?>
    <li><?= $item ?></li>
<?php } ?>

Go:

{{ range . }}
<li>{{ . }}</li>
{{ end }}

PHPやGoはフロントではなく、サーバーサイドでページをレンダリングするため、HTMLとしての宣言とJSのロジックとそれぞれのテンプレートのロジックは完全に分離されています。この分離が無駄に見える時もありますが、tsxなどで状態とロジックと宣言が同居してしまうようなコードを書いてしまうことを考えると仕様レベルで分離されていることはコードの品質維持に貢献すると考えました。

以上のような理由からSvelteを選択することになりました。実際のメンバーのスキルセットに即した現実ベースの採用でもありましたが、デザイナーとエンジニア双方が触りやすいフレームワークとして新規ページの作成をデザイナーが行い、それをエンジニアが動かすというフローが確立できました。

私たちは何を提供できるのか・ソフトウェア開発の価値とは？ - Svelteで最大化する価値創造

ソフトウェアエンジニアをしていると目先の開発や改善にフォーカスを向けてしまいがちですが、一度原点に帰ってみると、ソフトウェア開発において顧客、エンドユーザーに対しての最大の価値提供とは何なのでしょうか？

技術選定において、最大の価値提供は将来性と現状の天秤にかけ、最大の効率と安定を提供することだと思います。これを具体化したものが冒頭の技術選定の基本方針です。
私たちがSvelteを選択したのは先述の現実的な背景に加え、このような観点から見ても挑戦する価値のあるフレームワークだと感じたからです。

ReactやVueほどのエコシステムの規模はないですが、SolidJS、Svelte、Qwikなどの登場によりフロントエンドは事前ビルドの風が確かに吹きつつあります。今Svelteをメインで採用することで、バンドルサイズ低減の利益を享受しつつ仮想DOMを使用しないフレームワークの知見を深め、新時代に対応した開発を進めることで、長期的に三方に最大の利益を創造することを目標としています。

弊社では、事業規模の拡大に伴いフロントエンドエンジニアとして開発、効率化などを積極的に推し進められる方を積極的に募集しております。
本記事をお読みいただき、「詳しく話しを聞いてみたい」、「Svelteでの開発に興味がある」と思われましたら、弊社Webサイトのカジュアル面談ページから面談をお申し込みいただけると幸いです。

https://thefast.co.jp/casualtalk

まとめ

Svelteは標準のHTML/CSSから乖離しすぎず、デザイナー・バックエンドエンジニア・フロントエンドエンジニアの誰から見ても理解しやすい
バンドルサイズが小さいことにより、Reactなどと比較して何もしなくてもパフォーマンスが良い
会社や開発について、ご興味がある方や詳しく話しを聞いてみたい方は、ぜひカジュアル面談のお申し込みをお待ちしております！

Discussion