その後のフロントエンド環境の変化スピードは皆さんがご存知の通りで、わずか3ヶ月前の情報が古びてしまうようなペースで発展を続けています。カンブリア爆発を思い起こさせるように様々なライブラリやツールが生まれ消えていきました。挙げるとキリがありません。依存してしまったアプリケーションを今のフロントエンド環境に置き換えるのは至難の業です。部分から手を入れていく必要があります。いう仕組みでフロントエンドで発展したツールを取り込みました。廃れたときに同じ問題に遭遇することになります。コアを小さく保ったままモジュールで利用する機能を取捨選択することができます。モジュールへの依存も最小のインターフェースで疎結合を保っているので、環境の変化への追随も比較的限定できるのではないかと考えています。いう考え方が生まれて規約とリフレクションで振舞いが定義されることになりました。規約で想定されているユースケースの範囲内であればスムーズに最小限のコードで実装できます。規約にあわない要件を実現するためにに非常にトリッキーな実装が必要になったり、リフレクションと動的コード生成が多用されるスタックトレースを見てもどこに問題があるのかさっぱりわからない、といった状況が発生します。内部でどのように動いているのかわかりづらい実装、規約という暗黙のルールへの依存は、自分の足を撃つトリガーになってしまうのです。リフレクションやアノーテーションは最小限に抑えられており、コードを追えば理解できる素直でシンプルな設計ポリシーにもとづいています。使ってきたため同等レベルの生産性(機能性)が保証されないとストレスを感じてしまう、というのも考慮した点でした。型安全性で改修やフレームワークやライブラリのバージョンアップは確実に楽になります。その代わりに新規にコードを書くときに大量のボイラープレートが必要となってしまっては、これまでの環境から良くなったとは言えません。実装すべき機能に集中してサクサク書ける手軽さ、心地良さも重要な選定基準です。比べても同等以上に気持ちよくコードが書けるフレームワークだと感じています。素晴らしさを語ってきました。今度は逆に他の候補を採用しなかった理由、どの選定基準で採用を取りやめたのかを説明したいと思います。サーバーサイド開発ではデファクトスタンダードとなるフレームワークで、エコシステムの充実ぶりは他の追随を許しません。型安全でないアノーテーションを多用するフレームワークですが、アノーテーションはメタ情報でしかなく、コンパイル時に正しいかどうかを保証してくれるわけではありません。動的評価型のエンジンです。いう仕組みで設定ファイルを減らす仕組みを持っています。スキャンしてアノーテーションをもとに自動的にインスタンスを生成しコンテナに登録してくれます。便利に見えますが、問題があったときにその原因を特定するのが非常に困難な仕組みになります。ファイルではなく専用のブートクラスローダーによって処理されます。軽量フレームワークと言えば最初にあがる候補だと思います。採用しているという実績を持ちます。同等レベルの生産性」という観点で見たときに、標準で提供される機能があまりに少ないがため選外となりました。session、ファイル出力、非同期処理はサポートされていません。モジュールで提供される追加機能もあわせて考えれば言わずもがなです。層だけなので、それ以外の選択についても簡単に説明したいと思います。モジュールが提供されています。同様に型安全性を重視して選択しました。提供するスタイルを取ることが多くなりました。重要なプロジェクトではやはりサーバーサイドレンダリングが確実です。考えるとサーバーサイドレンダリングはまだまだ必要です。実装された型安全なテンプレートエンジンです。影響を受けているように見受けられ、テンプレート言語としての仕様の成熟度は高いと判断しました。魅力とその選定理由について説明してきました。サーバーサイド開発の選択肢として、自信を持ってオススメできるプロダクトです。サーバーサイド開発を検討される際に、この記事が一助となれば幸いです。さんへの感謝で本記事を締めたいと思います。ついてのお問い合わせやご応募は、TwitterとFacebookでも随時受付中です!オフィス見学もお気軽にどうぞ!お仕事のご依頼・ご相談・お問い合わせはこちらまで。メールでのお問い合わせいつでもお気軽にお問い合わせください。お問い合わせフォームはこちらです。