<p>エンジニアの mizchi です。本記事は plaid advent calendar の 8日目になります。</p>
<p>フロントエンドに携わる人なら、フロントエンド開発にまつわるものは、ブラウザの中で開発が完結するはずだ、と考えたことがないでしょうか。僕は個人的にブラウザ上で開発が完結すべきであって、技術的にも不可能ではない、と思っています。これは開発環境と実行環境が同じであるべきという <a href="https://ja.wikipedia.org/wiki/%E3%82%A2%E3%83%A9%E3%83%B3%E3%83%BB%E3%82%B1%E3%82%A4">アラン・ケイ</a> の Smalltalk と同じ発想です。</p>
<p>筆者はブラウザ上で Git/GitHub の操作ができる <a href="https://nedi.app/">https://nedi.app/</a> というエディタを作成したり、そこから markdown のプレビューだけを高速化したり <a href="https://mdbuf.netlify.com/">https://mdbuf.netlify.com/</a> というMarkdown プレビューツールを作ったり、最近は <a href="https://relaxed-franklin-8384b4.netlify.com/">https://relaxed-franklin-8384b4.netlify.com/</a> (名前はまだない)という開発ツールを趣味半分仕事半分で作っています。PWA、オフラインキャッシュ、 WebWorker、node ツールチェインが発達した今なら、これが可能なのではないか？ ということで、その環境を試作した話です。</p>
<h2>ゴール: フロントエンドでフロントエンドをビルドする</h2>
<p>ブラウザ上でフロントエンドが開発できると、何が嬉しいでしょうか。まず、ブラウザさえあればよいので、開発構築が容易になります。特にプログラミング教育では、いかに最初の一歩を踏ませるかが大事で、その上で視覚的なインパクトが伴うフロントエンドや、ゲームエンジンは特に入門向きだと思っています。(HTML/JS/CSS が入門向けの環境かどうかは、Web 開発以外の観点で議論の余地があると思いますが…)</p>
<p>また、開発者向けの実用的な側面でも、現代の GUI の開発は、ビルドに伴うファイル転送とプレビューなどの必要で発生している各種 IO への負荷が大きい問題を解決できる可能性があります。今までは書き出すしかなかったメモリ上の中間状態を引っこ抜いたり、プロセス的な距離が近くなるので開発ツールの効率を考え直したり、そのための差分検知のあり方が大きく変わるはずです。</p>
<p>ツールとプレビューがセットになった環境があると、動かせるコードのシェアが容易になります。ReactNative の開発者ならば、 <a href="https://snack.expo.io/">https://snack.expo.io/</a> で簡単なコードのシェアをしたことがあるのではないでしょうか。</p>
<p>というわけで、フロントエンドでフロントエンドをビルドする、またはその開発ツールについて考えると、次のテーマが浮かび上がってきます。</p>
<ul>
<li>永続層: ファイルシステム</li>
<li>ツールチェインの解決</li>
<li>ネイティブプラグイン</li>
<li>エディタ</li>
</ul>
<h2>永続層: ファイルシステム</h2>
<p>現実には永続化とファイルストレージの問題があります。手軽な永続層として使われる localStorage は単なる KVS、しかも同期ブロッキングな API なので、プログラミングで大量のデータを扱うには不向きで、 IndexedDb は非同期で高速ですが、 <strong>ホスト OS の空き容量サイズが一定値を下回ると消える可能性がある</strong> という挙動で実装されてあることが多く、現実に発動することは稀ですが、大容量を扱う可能性があるものとしては、完璧に信頼できるストレージではありません。</p>
<p>仮想ファイルシステムは、一旦は揮発する開発環境として扱う、という従来のブラウザツールによくあるポリシーを採用するのは不可能ではないのですが、 2019 年現在、 <a href="https://wicg.github.io/native-file-system/">Native File System</a> という API が提案され、Chrome で開発者フラグを建てると使うことができます。これに活路が見いだせるかも？と期待しています。</p>
<p>これは、限定的なホスト環境へのファイル読み書き機能です。この機能を使って、一旦はブラウザストレージに書き込んだものを、単一ファイルへの内部状態の書き出しを実装すれば、非効率とはいえ、ホスト環境のディスクへの永続化が可能です。まだ試していないですが、簡易なファイルソケットとして実装すれば、双方向の RPC も実装できるかもしれません。(となるとブラウザ単独で完結するという旨味もなくなるんですけどね…)</p>
<p>Native FileSystem 現在は単体ファイルの Read or Write, またはディレクトリの Read のパーミッションしかないのですが、 単体ファイルへの Read &amp; Write や、ディレクトリへの Read &amp; Write パーミッションがあると、使い勝手の良いブラウザ開発環境のストレージが実装できる可能性があります。</p>
<p>とはいえ、歴史的にはブラウザからのファイルシステムへのアクセスは、 ActiveX 経由の悪意あるディスクトラバースとして悪用された過去があるので、セキュリティ的に危険な機能です。慎重に議論されて実装される必要があるとは思っています。</p>
<p>参考:</p>
<ul>
<li><a href="https://developer.mozilla.org/ja/docs/Web/API/IndexedDB_API/Browser_storage_limits_and_eviction_criteria">ブラウザーのストレージ制限と削除基準 - Web API | MDN</a></li>
<li><a href="https://www.html5rocks.com/ja/tutorials/offline/quota-research/#toc-chrome">モダンブラウザのストレージ容量と調査方法まとめ - HTML5 Rocks</a></li>
<li><a href="https://mizchi.hatenablog.com/entry/2019/09/08/090057">Chrome(Canary) の Native File System API で ローカルファイルの読み書きをする - mizchi's blog</a></li>
</ul>
<h2>プリプロセス | バンドリングの課題</h2>
<p>永続ストレージ問題は(問題はあるものの)解決されたとして、次に立ちふさがるのは現代のフロントエンドツールチェインです。</p>
<p>node.js 向けのツールチェインは、古くから isomorhic や universal javascript という概念があるのですが、多くはブラウザ向けに動くように調整された shim と一緒にビルドすることが可能です。</p>
<p><a href="https://qiita.com/kyrieleison/items/4ac5bcc331aee6394440">Universal / Isomorphic JavaScript について - Qiita</a></p>
<p>しかし、ここに標準ライブラリの net や fs といったモジュールを使うと話がややこしくなります。素朴な http 通信に限ったとしても、ブラウザはアクセス先に CORS の制約を受けます。このため、特にプロキシなどを用意しない場合、 CDN ぐらいしかアクセスできません。こうなると npm から tar.gz を落とす、といった、npm/yarn のツールチェインの入り口が閉じられてしまいます。</p>
<p>fs もブラウザ環境での永続層を想定しない結果として、 fs のよく使われるポリフィルは存在しません。一応、 <a href="https://github.com/jvilk/BrowserFS">https://github.com/jvilk/BrowserFS</a> という IndexedDb をバックエンドにできるツールがあるのですが、あまり現代的ではない古い設計なのと、素朴な read &amp; write を行うだけで、シーケンシャルなファイルアクセスができず、とても遅いです。</p>
<p>この結果、 React や Vue のような、フレームワークのランタイムは比較的に簡単に扱うことが可能なのですが、ブラウザでパースできない JSX や Vue SFC を扱うためのツールチェインをブラウザ側にもってくるのが、ひと手間かかります。具体的には、ユニバーサル性を謳うどのツールも、ツールチェインの依存のどこかで fs を無意識に依存のどこかで含んでいて、それらをモック化しつつビルドするのは、一手間かかります。</p>
<p>ライブラリのコアがブラウザでも動くことを謳いながら、ツールチェインのどこかで Isomorphism が失われるのは他の環境でもよく発生します。例えば eslint のプラグイン や textlint のプラグインは、外部ファイル参照の解決に fs を使いに行くものが多いので、ここをなんらかのインメモリキャッシュに差し替えたりしなければなりません。逆に言うと、それさえすれば動くものも多いです。</p>
<h2>解決策: CDN</h2>
<p>Proxy を設置しない場合、 CDN でフロントエンドのツールを引っ張ってくる必要があるのですが、幸いなことに便利な CDN がいくつかあります。</p>
<ul>
<li><a href="https://www.jsdelivr.com/">https://www.jsdelivr.com/</a> npm のファイルへの CDN</li>
<li><a href="https://unpkg.com/">https://unpkg.com/</a> npm へのファイルへの commonjs でビルドしたものを返してくれる CDN</li>
<li><a href="https://www.pika.dev/cdn">https://www.pika.dev/cdn</a> npm へのファイルのうち、 package.module で ESM でビルドしたものを返してくれる CDN</li>
</ul>
<p>内部パスやカスタムローダーで特殊なファイルを解決する際は jsdelivr, module が指定されていたら pika.dev, それ以外は unpkg などの使い分けすると効率よく引っ張ってこれそうです。 npm は unpublish が特別な場合を除いてできないので、一度引っ張ってきたらローカルキャッシュに入れてしまっても構わないはず。</p>
<h2>ネイティブプラグインの問題: WebAssembly は使えるか?</h2>
<p>フロントエンドでフロントエンドを開発しようとすると次に問題になるのはネイティブプラグインです。有名所で、 node-sass などが C で書かれた libsass でコンパイルされたプラグインですね。</p>
<p>現代のフロントエンドは、 その為の開発ツールは基本的に JS で書かれてはいるのですが、またそうではないものも wasm で提供されるようになりはじめています。例えば <a href="https://github.com/kkos/oniguruma">正規表現エンジンの oniguruma</a> は Atom などで使われ、Sublime や Atom や VSCode で連綿と引き継がれてきた使われる共通の TextMate 仕様のコードハイライト定義で使われていたのですが、これが <a href="https://github.com/NeekSandhu/onigasm">NeekSandhu/onigasm: Oniguruma regex library on the web using WebAssembly</a> という wasm 版 oniguruma が提供されるようになったことで、 VSCode Online のウェブ版のビルドが実現されています。</p>
<p>とはいえビルドサイズが膨らむことが多く、PWA のオフラインキャッシュと組み合わせてロード時間を短縮する必要があったりします。</p>
<p>wasm のパッケージを登録できる <a href="https://wapm.io/">https://wapm.io/</a> を眺めていると、想像していたより幅広いツールが日々ビルドされています。(使い物になるかはともかく…)</p>
<p>最近登録されたものを見てると、 wasi でファイルシステムが触れるようになったのが大きいですね。jq の wasm ビルドがあったり、極端なものだと、 wasm でビルドされた python があったりします。</p>
<ul>
<li><a href="https://wasi.dev/">WASI |</a></li>
<li><a href="https://wapm.io/package/jq">https://wapm.io/package/jq</a></li>
<li><a href="https://wapm.io/package/python">https://wapm.io/package/python</a></li>
</ul>
<p>とはいえ wasi も結局ブラウザで使うにはモックかインメモリキャッシュに差し替える必要があるので、これらはだいぶ辛そう…</p>
<h2>というわけで、作ってみた</h2>
<p>決めたこと</p>
<ul>
<li>超巨大ファイルストレージは扱わない(超巨大ファイルを扱うための git 組み込みもしない)</li>
<li>FS も複雑なものを扱わない想定でフラットに展開する</li>
<li>ブラウザ上で動く rollup コンパイラでインメモリに展開し、ライブラリは CDN から引く</li>
<li>エディタは vscode で実績がある monaco-editor で、 TypeScript を編集してフロントエンドのコードをプレビューする、という単目的なツール</li>
</ul>
<p>できたのがこれ</p>
<p>URL: <a href="https://relaxed-franklin-8384b4.netlify.com/">https://relaxed-franklin-8384b4.netlify.com/</a></p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/70c48f8c-2a80-4900-a271-91adcc5f78bf/b4d3778564f04badf9b6562a331b256a.png" alt=""></p>
<p>ソースコード <a href="https://github.com/mizchi/bundle-on-browser">https://github.com/mizchi/bundle-on-browser</a></p>
<p>注意: 読み込みが遅いしバギーです。リロードで動かなかったりしたら、 DevTool &gt; Application &gt; Clear Site Data でキャッシュを破棄してください。</p>
<p>ドラッグアンドドロップできる可変レイアウトは <a href="https://github.com/mizchi/react-unite">https://github.com/mizchi/react-unite</a> という昔作った Unity 風のレイアウトシステムを引っ張り出しました。タブが他のペーンに移動できたりして楽しいと思います。</p>
<p>lodash, preact, react, vue, svelte で動作確認をしています。(workspace タブの preset を見てみてください)</p>
<p>CDN の一回目の読み込みは遅いですが、二回目以降はキャッシュされて早いです。これによって、ブラウザ上でバンドルしてるにも関わらず、十分高速なプレビューが実現できています。</p>
<p>NativeFileSysetem が有効になっているならば、 Cmd+S で現在のファイルシステムのダンプを示す json を保存でき、Cmd+O でそれを読み込むことができます。</p>
<h2>ブラウザ上のコンパイラの実装について</h2>
<p><a href="https://github.com/mizchi/web-compiler">https://github.com/mizchi/web-compiler</a> では、 ブラウザ上で動く rollup に、以下の機能を組み込んで、それ自体がブラウザで動くようにバンドラをコンパイルしました（ややこしい）</p>
<ul>
<li>ESM のバンドル</li>
<li>typescript の読み込み(tsx の解決)</li>
<li>npm のバージョンの解決</li>
<li>CDN からのファイル実体の解決</li>
<li>svelte の読み込み(なんとなく)</li>
<li>terser による minify</li>
</ul>
<p>その結果、4MB あって読み込みが重くなってしまったのですが、ブラウザでもサーバーでも、<code>npm install @mizchi/web-compiler</code> で次のコードが動くようになりました。</p>
<pre><code class="language-js">import { compile } from &quot;@mizchi/web-compiler&quot;;
const pkg = {
  dependencies: {
    &quot;lodash.flatten&quot;: &quot;*&quot;
  }
};

const code = `export default 1`;
const out = await compile({
  entry: &quot;/index.js&quot;,
  files: {
    &quot;/index.js&quot;: code
  },
  pkg,
  tsConfig: `{
    compilerOptions: {
      target: &quot;es5&quot;
    }
  }`
});
console.log(out);
</code></pre>
<p>ファイルシステム上の絶対パスと、そのエントリーと、解決すべきパッケージの dependencies が書かれた package.json と、その tsconfig.json です。これらを仮想 FS として、足りないものは CDN から引いています。</p>
<p>rollup のプラグインの規約がとてもわかり易いので、ハックしやすかったです。 <code>rollup(...).generate()</code> はブラウザ環境で動くことを知っていれば、あとは何でもできると思います。</p>
<h2>エディタ</h2>
<p>VSCode で使われてる monaco-editor を使っています。</p>
<p><a href="https://github.com/microsoft/monaco-editor">https://github.com/microsoft/monaco-editor</a></p>
<p>VSCode は electron(node) への依存が極力切り離されているので、ブラウザで起動可能なビルドが作れます。(<a href="https://github.com/microsoft/vscode/blob/master/scripts/code-web.js">https://github.com/microsoft/vscode/blob/master/scripts/code-web.js</a> を参照)</p>
<p>試してみたところ、永続層が実装されていないのでインメモリで揮発してしまうのですが、ここを実装すると任意のバックエンドの VSCode が作れそうでした。</p>
<p>ここまでわかったので、さらに VSCode をハックして monaco 上で TypeScript の設定を読んだり、仮想 FS 上で TS の補完を扱ったりできたり、といったものを実装したのですが、それについては別途 12/9 の ginza.js で話す予定です。</p>
<p><a href="https://ginzajs.connpass.com/event/154596/">Ginza.js#7 - connpass</a></p>
<h2>未来</h2>
<p>現状、フロントエンド開発すべてを Web に移す、といったことはまだ無理ですが、用途を絞れば、たとえば用途特化のオーサリング環境や学習用の開発環境などとしては十分実用的なものが作れると思います。</p>
<p>PWA によってオフラインツールが作りやすくなった今、みなさんも思い思いのエディタを自作してみてはいかがでしょうか。以上、フロントエンドでフロントエンドをビルドする話でした。</p>


フロントエンドでフロントエンドをビルドする

<html><head></head><body><p>こんにちは、monoi &amp; komukomo &amp; tik-sonです。<br>
11/18-11/21にかけてサンディエゴで開催された <a href="https://events19.linuxfoundation.org/events/kubecon-cloudnativecon-north-america-2019/" target="_blank" rel="noreferrer">KubeCon + CloudNativeCon North America 2019</a>に参加してきたので、その様子をご紹介したいと思います。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/a7eaaca0-b5f9-470d-ae8d-2235c892f22a/image--5-.png" alt="image--5-"><br>
サンディエゴの景色。めちゃくちゃ過ごしやすい気候でした。</p>
<h2 id="Anthos Day">Anthos Day</h2>
<p>メインカンファレンス前日のDay Zeroには、様々な企業がイベントを開催していました。<br>
私たちはその中でAnthos Dayに参加しました。</p>
<p><a href="https://cloud.google.com/anthos" target="_blank" rel="noreferrer">Anthos</a>はGoogle Cloudが開発しているプラットフォームで、特定のクラウドに依存しないアプリケーション開発・実行環境を提供しています。<br>
例えば<a href="https://cloud.google.com/kubernetes-engine" target="_blank" rel="noreferrer">GKE</a>をオンプレミスで動かすサービスなどを提供しています。</p>
<p>"Anthos Day"と言いつつも意外とGKE本体についてのアップデートの発表もあり、GKEユーザーである私たちに有意義な内容が多かったです。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/04915593-5d9b-476e-95c0-7f84dc02b3f1/image--6-.png" alt="image--6-"><br>
Anthos Dayでのセッション</p>
<h2 id="日本人交流会">日本人交流会</h2>
<p>Day Zeroの夜には<a href="https://kubecon-jp.connpass.com/event/145278/" target="_blank" rel="noreferrer">日本人交流会</a>が開催されました。<br>
一昨年は30人程度だった参加者も今年は150人ほどまで増えたようで、ここからもKubernetesの盛り上がりが感じられました。</p>
<p>Kubernetesの知見を持った多くの方と情報交換ができ、また日本に帰ってからも継続できる繋がりを作ることができたのは非常に良かったです。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/02e6efd5-5802-438b-b5fb-5ae77ceb1c05/image--7-.png" alt="image--7-"></p>
<h2 id="Kubecon開幕">Kubecon開幕</h2>
<p>今年のKubeconには1万人以上が参加していたようで、会場は熱気に包まれていました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/3b5d72ae-a5a4-4e4f-b29f-69b6c058e7e0/image--8-.png" alt="image--8-"></p>
<p>Kubernetesのユーザーというより、Kubernetesシステムまわりの開発者やプラットフォーム提供者によるセッションが多かったです。<br>
データベースやログ・監視系、セキュリティやサービスメッシュなどをはじめとした、あらゆる分野のプレイヤーがKubernetesエコシステムに参加しており、Kubernetesの柔軟性や拡張性の高さを感じるとともに、エコシステムの広げ方のうまさも改めて感じました。</p>
<p>意外なところでは、米国では金融機関や政府もKubernetesやCI/CDのオートメーションなどを活用したモダンなアーキテクチャを構築している事例も発表されてました。<br>
また、オンプレミスで運用している事例も多かったことも驚きました。</p>
<p><img src="https://ik.imagekit.io/newt/61b151f921640c0018173598/9ace13e0-de61-491f-9b1b-f4091d3d1ace/image--9-.png" alt="image--9-"><br>
会場には卓球台やレトロなゲームマシンもありました</p>
<h2 id="Anthos / GKEのPMとのミーティング">Anthos / GKEのPMとのミーティング</h2>
<p>Anthos / GKEの機能に関するフィードバックや、高速にスケールアウトすることが求められるKARTEにおいてKubernetesをどのように使うべきかなどに関してディスカッションしました。<br>
アーキテクチャの構成に関する事例や内部仕様、自分たちが気づいていなかった他機能との連携など、公式ドキュメントを見るだけでは得にくいような情報も得ることができ大変有意義でした。</p>
<p>ミーティング後には、<a href="/google-cloud-next-tokyo-19/">毎度恒例</a>のPLAIDオリジナルの漢字Tシャツをプレゼントし喜んでいただけました。（笑）</p>
<h2 id="まとめ">まとめ</h2>
<p>KubeConに参加した中で、PLAID社員がどのような動きをしていたかについて紹介いたしました。<br>
セッションの内容自体はWebで公開されているものが多いですが、どのようなセッションが人気で何に対して盛り上がっているのかを体感したり、実際に開発者やユーザと交流したりできたため、多少コストは高め（フライト時間は往復で約1日..!）ですが、意味のある時間を過ごすことができたかと思います。機会があればまた参加したいと思います。</p>
<h2 id="最後に">最後に</h2>
<p>PLAIDではKubernetesなどのインフラの特性をフルに生かし、魅力的なプロダクトを作るエンジニアを募集しております。もし興味があれば、<a href="https://www.wantedly.com/projects/234957" target="_blank" rel="noreferrer">こちら</a>からカジュアルに話を聞きに来てください！<br>
また、エンジニアだけではなく、KARTEの技術的・機能的サポートを行うプロダクトスペシャリストも募集しております。プロダクトスペシャリストに関しては、<a href="https://www.wantedly.com/projects/332135" target="_blank" rel="noreferrer">こちら</a>をご覧いただけると幸いです！</p>
<div class="wantedly-visit-button" data-visit-button-id="lyE_IgY4VF5ukBo_EUKZLg" data-width="300" data-height="60"></div>
<script>
  (function(d, s, id) {
    var js, fjs = d.getElementsByTagName(s)[0];
    if (d.getElementById(id)) return;
      js = d.createElement(s); js.id = id;
      js.src = "https://platform.wantedly.com/visit_buttons/script.js";
      fjs.parentNode.insertBefore(js, fjs);
    }(document, "script", "wantedly-visit-buttons-wjs"));
</script>
</body></html>

KubeCon in San Diegoに参加してきました！