Hyperappは、JavaScript製のミニマルで関数型パラダイムを利用したGUIアーキテクチャと状態管理機構を備えた、フロントエンドアプリケーション構築ライブラリです。私が初めて、このライブラリを知ったのは先日、新QiitaでReactをやめてhyperappを採用した背景という記事で見かけたからでした。その記事で、いくつか気になった点があったことへの言及と自分なりにフロントエンドアプリケーション開発における言語・フレームワーク・ライブラリに対するスタンス、それを踏まえてHyperappとは、どのようなライブラリなのかについて説明できたらと思います。結論から言うとHyperappは素晴らしいものでした。それ故に何が素晴らしいのかを良く考える必要があると思いました。
先日の記事で気になった点
それでは、まず気になった点について言及していきます。記事全体に関しては、まだ完全に噛み砕けていない箇所と、さらに踏み込んだ、「ドメイン層やデータ層と合わせて実現している」と言う個人的にかなり興味深い別記事が上がり情報量が増える点を考慮して、コメントは控えさせていただきます。部分的に気になった記事は以下の点になります。
- 実体は単なる Object です。 immutable.js とかそういう余計なものは使いません。
まず前提として、ReactはImmutable.jsの使用を必須とはしていません。ReactのProps, State自体が単なるObject、つまりデータの名前と値のマッピングであるという点は同じです。Immutable.jsの使用は必須ではありませんが、推奨はされています。詳細は公式ページや別記事を参照していただけると助かりますが、仮想DOMの速度の改善や一般的なイミュータブルデータ構造の恩恵を得る、という点が重要だと思われます。Hyperappの仮想DOMのdiffアルゴリズムについては調べていないため、もしかしたら大きな利点になるかもしれません。しかし、イミュータブルデータ構造を利用することは明らかな利点となります。不変であるが故にデータ構造同士の同値比較が容易であったり、豊富なコレクション関数が備わっていたり、関数・メソッドから副作用を取り除き処理を予想しやすく単体テストが書きやすくなるなどの利点はHyperappであっても得ることができ、使う価値は大きくあります。
- 息の長いライブラリ
アプリケーション開発における全体の機能性の一部を切り出した、プレゼンテーション層のみにフォーカスしたライブラリ、と言う点では確かに息が長いであろうことに同意です。しかし、今までのJavaScript史におけるライブラリやフレームワークの遷移を除いてみるとDOM操作(標準API・jQuery)による無秩序な手続き処理に対するMVCアーキテクチャという形・仮想DOMを利用しDOM操作の抽象化を手に入れた。など、もっと根本的な考え方の変更による進化というポジティブな見方をした場合に、Hyperappは仮想DOMというベースに乗っかっている以上、これからのパラダイム変化に耐えうるものかどうかと言うのは疑問が残ります。むしろそれが今あるフロントエンド開発における大きな問題点を改善するものであるならば、変更は喜んで受けるべきであると個人的には考えます。
- 「拡張性とメンテナンス性を持ったリッチなクライアントアプリ」
Hyperappは冒頭で述べた通り、ミニマルな機構です。アプリケーションの状態の変化に対して、反応し仮想DOMを通じて見た目を変化していくという目的を達成するためのライブラリです。そのため、拡張性とメンテナンス性に直接貢献しているか疑問です。それを担保するのは、Hyperappをどう運用していくか、どんなものと組み合わせていくか(Immutable.jsもそのうちのパーツの一つです)、そこが大きな課題だと思います。
私はHyperappのアーキテクチャの参考元であるElmがどちらかと言うと、この課題にフィットしていると考えます。その理由は、実質的にElmで定義される関数が一切の副作用を持たない、実行時エラーが起きない点。強力な型システムにより型エラーをいち早く発見できる点。全てのデータ構造がイミュータブルであり、機能・ライブラリが豊富である点。標準でフォーマッタ・テストツールが定まっている点。様々が挙げられます。勿論デメリットとして日本語情報が不足している(しかし、今年より急増しつつあります)。プロダクト採用事例がまだごく一部の企業であること。JavaScriptライブラリにフルで依存するような場合には適していない(その場合には、あっさりElmを捨ててください。それが美徳です。)。等がデメリットとしてが挙げられます。
最後に一つ、Reactの良さとしてReact Nativeの存在についての言及が無いように見えました。マルチプラットフォームに一つの考えが活かせることは魅力として非常に強いと思います。
Hyperappの良さは何なのか
それではHyperappの良さとは何なのかを個人的に考えてみました。一つの意見として参考にしていただければと思います。参考記事として、2018 年は Hyperapp の年だ とHyperapp — 1 KBのビューライブラリを読ませていただきました。端的に言うとライブラリが小さい(1KB)であることが大きな利点・役割を見出してきます。
高速なプロトタイプ作り
React等のフルスタックなフレームワークと比較して、ボイラプレートが少なく、難しいことを考えること無く、パッと作り始めることができます。これは、仕様が固まっていない段階のプロトタイプやアプリケーション開発を学んでる段階で利点となり得ると思います。
Webフロントプログラミングを学ぶ教材
フロントエンドの設計の良し悪しを学ぶには多かれ少なかれ学習コストを割く必要があります。そのために必要な作業として、フレームワークの目指す哲学・アーキテクチャを学ぶことが挙げられます。Hyperappはとてもサンプルがシンプルで、学習コストが極端に少ないです。また、既存のフレームワークの殆どで言えますがHyperappは、アプリケーションのためのステートマシンと見ることができます。これは、オートマトンの概念を実践的に学ぶことができる最適な教材です。async/awaitを利用した非同期処理の概念を組み合わせて学ぶことにも向いていると思われます。
OSS貢献チャンス
これは前述したHyperappそのものが教材であるという点の延長なのですが、ライブラリの全容を把握することが容易なので、バグや改善点をすぐ指摘することが比較的容易です。Hyperappそのものに貢献が容易でもありますし、Hyperappという教材を通して自分なりの仮想DOM実装を作り上げたり、Hyperappを低レイヤと定め自分のフルスタックフレームワークを構築してOSSとして提供することも容易になります。
以上が、私の考えるHyperappの良さになります。これからも様々な人の意見やフロントエンド開発の発展に繋がればなと思います。
本音
途中でポロッと漏れていましたが、大規模で拡張性・保守性を考えるのであれば、Angular, ReduxなどのフルスタックなフレームワークやImmutable.js、TypeScript/Flowなどの後付の型安全を求めるのは土台がJavaScriptであるが故に、所々から無理が生じてきます(もちろん昨今の急速な進化は、ものすごいと思います)。それであればベースの言語から関数に副作用を含まない、豊富なイミュータブルコレクション、強力な型システムを備えたElmを視野に入れましょう。もしかしたら多大な時間の浪費を抑えれるかもしれません(私は1年以上浪費しました)。Elmの強力な生産力を裏付けるためにElmなんか作ろう会というものを頻繁に開催しています。Elmを初めたばかり(数ヶ月)の初心者から~Elmの達人まで幅広く揃えて1時間という制限でモノづくりをしています。クオリティに差は生じるものの、ほぼ全ての人が毎回実装を終えています(これは驚異的な結果であると個人的に思います)。半信半疑な人は是非参加して、その強力さを実感してみてください。手厚くサポートいたします。もちろんこれはJavaScriptを捨てるということではなく、状況に応じて使い分けて行くべきであると言うことです。Hyperappは上で述べた通り、簡単なプロトタイプ作りに積極的に使っていこうと思っています(何の記事かわからない方向になってしまって申し訳ありません)。