自分なりにUIフレームワーク決めのロジックをまとめたのでメモ書き。 UIフレームワークの大別とそのメリデメをまとめた上で、自分なりの決めのロジックを整理した。
CSS
とJavaScript
によって作られたUIコンポーネントを提供する。
Vuetify
Element
Buefy
Bootstrap Vue
Material Components Web
iView
- オールインワンなコンポーネントを利用出来る
- 「デザインの最小単位」としてのコンポーネント設計をライブラリ仕様で落とせる
- 「画面アクションの最小単位」としてのコンポーネント設計をライブラリ仕様で落とせる
- つまり、コンポーネントの設計・開発コストを大きく削れる
- コンポーネント仕様をアプリケーション単位でいじりにくい
- 仕様を変えるには、裏で書かれている
JavaScript
のロジックを追わないとダメ
- 仕様を変えるには、裏で書かれている
- コンポーネント仕様をコントロール出来る立場の場合
- 新規案件、ゼロからスクラッチするパターン
CSS
のみを提供し、開発者はそこで定められたクラスを利用してデザインを設定出来る。
Bulma
Tailwind
Tachyons
CSS
の提供に止まるため、コンポーネント仕様は自由自在- コンポーネントライブラリで起こり得る「えっ、こんなこと出来ないの、、」が無くなる(こちらの実装でカバー出来る)
JSF
を例に書けば、Renderer
を書いてクラス名だけCSSライブラリに準ずる形にするイメージ
- コンポーネントライブラリで起こり得る「えっ、こんなこと出来ないの、、」が無くなる(こちらの実装でカバー出来る)
CSS
の提供に止まるため、コンポーネント仕様はデザイン・機能共に決めた上で開発をしないといけない- 設計・開発コストの削減にはあんまり寄与しない
- 複雑・高難度なコンポーネントを作らないといけない場合
- CSSフレームワークが、と言うより、コンポーネントライブラリが要件を満たせず候補から落ちる場合
- マイグレーション案件で、既存アプリケーションからコンポーネントの仕様を弄れない場合
- 基本
Vuetify
- デスクトップアプリケーションならば
Element
も入る - ドキュメント量、ドキュメンテーションのクオリティ、機能からして2択なイメージ
Vuetify
はエンプラサポートもあると、仮に社用で用いる場合でも安心さがある
- デスクトップアプリケーションならば
- マイグレーション案件ならばドキュメンテーションを買って
Tailwind
を推す - 会社で用いる場合はデザイナーの画面イメージとも擦り合わせないとダメなので、、
- 1)複雑なコンポーネント要件が無いか確認
- 2)もし無い場合、
Vuetify
で提案 - 3)デザイン要件、デザインイメージ上そぐわない場合は
Element
もしくはiView
- でも、
iView
は内部向けサイト用なイメージで、BtoC向けに必要な華やかさはあんまり無い - Bootstrap系で良いコンポーネントライブラリが無いか、、
- でも、
- 4)もし複雑なコンポーネントがある場合は、CSSフレームワークは特にこだわりが無いので候補全てを並べてディスカッション