albatrosary's blog

UI/UXとエンタープライズシステム

最近のJavaScriptフレームワークの評価とか

最近JavaScriptフレームワークについて色々指標のようなものを提示するブログが流行っているようだ。適材適所のもと、これは大規模向きとか小規模向きとか早いだの遅いだの。加え「gitなんか覚えなくたって死なない」とか、UXうえい！みたいな話だと思いきや内容がUIに限ったこととか。

一体最近のフロントエンドはどうなってるんだ？という雰囲気になってきましたので、少しメモ的に書きました。

JavaScriptフレームワークについて

JavaScriptフレームワークの状況を見ると（フレームワークかライブラリかの議論は置いておき）

  • DOM
  • Web Components
  • Virtual DOM

に分かれます。JavaScriptフレームワーク初期の頃はDOMを直接操作するものが多く出現してきましたが、レスポンスなど扱いに難しい面もあり、他のアプローチが考案されました。それがWeb Compoents系のフレームワークです。ただこれにも良し悪しがあり、現在はDOMを間接的に操作するVirtual DOMのフレームワークが出てきました。感覚の問題ですが、個人的にはWeb Compoents系とVirtual DOM系は真逆にいるように思えます。

さて、例えばDOM系の代表としてBackbone.js、Web Components系の代表としてAngular、Virtual DOM系の代表としてReact.jsを比較し、大規模向き、小規模向きという比較には無理があります。少し乱暴な言い換えですが

  • DOM操作は大規模向き
  • Web Componentsは中規模向き
  • Virtual DOMは小規模向き

と言っているようなもので、その議論には意味がありません。かつ、大規模、小規模というのはどのくらいのプロジェクト人数、工数（？）を指しているのでしょうか？エンタープライズ系だと100人-300人で大規模かもしれませんし、20人でも大規模という人もいます。そして冷静に考えると2人、3人でしか開発ができないフレームワークというのが存在するのかな？

よくある優れてる劣っている系のJavaScriptフレームワークの比較ブログでHello Worldに毛が生えたくらいのコードで大規模、小規模を判断しているものが多くなっていますが、そういう単純な話でプロジェクト採用のフレームワークは確定しません。組織によって異なりますが、私自身はほぼ次の基準でフレームワーク採用の判断をします：

  • アサインされた技術者の素量
  • その技術の理解度
  • （自身の）マネージメント力

プロジェクトで利用される技術はアサインされたメンバーで決まります。最先端な人が集まりやりきれるのならVirtual DOM系のフレームワークを選ぶのも良いかと思いますし、 Web Componentsが好きならAngularのようなフレームワークもいいと思います。jQueryで育ち愛着があるならBackbone.jsでもいいと思います。

「gitとか覚えなくても」について

デザイナーであろうがマネージャーであろうが基本的な操作は覚えてくださいという一言で終わりです。まったく使えない本人は困りませんが、一緒に仕事をしている人が迷惑します。 以前から言われている通りフロントエンドは色々やるべきこと、覚えるべきことがあります：

  • HTML
  • CSS
  • JavaScript
  • JavaScriptフレームワーク
  • altJS
  • CSS Preprocessor
  • CSSフレームワーク
  • HTMLテンプレート
  • セマンティック
  • 開発ツール(grunt, gulp, bower, yo, yeoman, slush, etc)
  • git
  • github
  • その他諸々

色々触ってみてより好みするくらいの方が良いと思います。技術を触らないで必要/不必要ということを言ってても何も変わりません。

UXについて

UXについて議論したり話をするときには対象となる期間を明確にすることが重要で、それらは

  • 一時的UX
  • エピソード的UX
  • 累積的UX

の三種類に分けることができます。もっと長い期間で考えるとUXはライフサイクルなどで構造化することもできます。さまざまな経験から色々な順番で互いに幾重にもなるのでUXに決まった流れはありません。UXセミナーでUIデザインの話だけするのは少し疑問に思います。UXデザイン白書くらい読んで頂きUXを語って欲しいと。

最後に

最近のフロントエンドはカオス化しているというのがありますが、物事を整理して考えると特段そういう印象は無いはずです。フロントエンドアーキテクチャは中途半端な技術ではありませんので、気軽に取り掛かろうとすると火傷します。そのためにも「自らコードを書く」ことによって、実施しているプロジェクトには「この組み合わせが良い」を探す必要があります。

何はともあれコードを書きましょう。