Yosami
Yosami とは Mithril.js をベースにした SPA+SSR のフレームワークです。
このフレームワークは前回ご紹介させていただいた通り私が制作したものです。
しかし、世の中には Vue/Nuxt や React/Next など、素晴らしいフレームワークが既に存在します。
そのような状況でなぜ今更「Yosami」を作ったのか3つの理由を紹介します。
Mithrilを使うため
Mithrilは高速で軽量なフレームワークで、公式のベンチマーク結果によると主要フレームワークの中で最速・最軽量です。
そのパフォーマンス良さに惚れ、趣味、業務ともに採用してきました。
しかし、昨今では SPA+SSR が当たり前の時代になってきており(偏見)、そのための仕組みや定番の方法がないMithrilでは追加の実装が必要となります。
プロジェクトごとにその仕組みを実装すると、実装が統一されず保守コストが増大することは容易に想像がつきます。
そこで別のフレームワーク(Nuxtなど)を利用していましたが、やはりMithrilを使ってアプリケーション実装したいと考えていました。
Yosamiは追加実装なしにMithrilベースのSPA+SSRアプリケーションを構築できます。
参考: チュートリアル01 Hello world
ファイルの分割制約がほしい
例えばnuxt.jsでは.vueファイルにビューもコントロールロジックも記述します。
Railsを長く使っていたためか、役割ごとにファイルが分割されていないことが気になりました。
もちろん、規約と設計を追加して分離することもできます。
しかし、これではプロジェクトや人に依存して分割方法が変わってしまうので、フレームワークレベルである程度統一された制約がほしいと考えていました。
Yosamiは役割ごとにファイルを分割する構造になっています。
参考: プロジェクト構造
Rails風にコードを書きたい
Railsではジェネレータでコードを生成して、便利なDSLでモデルのバリデーションやルートを定義して…といった最高の仕組みが用意されています。
Javascriptでもそのような世界が来てほしいと切に願っていました。
YosamiはDRY原則・CoC原則に従い、RailsをインスパイアしたAPIでアプリケーションを実装できます。
一例を上げるなら、モデルのバリデーション定義はとてもRailsに近いものとなっています。
validates('comment', {presence: true, length: {max: 140}});
まとめ
今回はYosamiを今更作った3つの理由を紹介させていただきました。
もし遊び程度で何かを作る機会があれば試してもらえれば幸いです 