Aurelia をふわふわと紹介してみる
この記事の目的
Aurelia Framework をゆるーく紹介する。
この記事を読んで得れること
Aurelia Framework のふわっとした理解
フロントエンドフレームワーク
まず、Webアプリケーションのフロントエンド開発で使うフレームワークについてのゆるい理解を展開する必要がありそう。
Web App is 何？
サーバーからユーザーにネットワーク越しにサービスをブラウザ上で提供するアプリケーションのこと。ここの、肝はブラウザとネットワーク越しに、と言う部分になる。社内のイントラ環境で提供されるアプリケーションも上記の構成ならWebアプリケーションになる。この際、使う言語がどうとかはどうでもよい。 ここからさらに、バックエンドとフロントエンドに分かれるのだけど、雑に整理するとブラウザ上で動作するコードがフロントエンドの守備範囲になる。
Only JavaScript
ブラウザ上で動作するプログラミング言語はJavaScript一択になる。異論は認める。ビルドしたら大体みんなJSなのでJSでOK。WebAssemblyには期待してる。さて、ゆるふわな理解の記事なので、ブラウザで動くプログラミングはみんなJavaScriptなことにしとく。
道具というか材料？
使う材料は3つ。HTML5, CSS3, JavaScript、そうこれだけ。
プログラマー is 横着
プログラマーと言う生き物は元来、繰り返し作業が苦手で、嫌いで、めんどくさがりです。偏見かもしれないけど、たぶん正解です。と言うわけで、なるべく横着して便利な道具を使います。それが、ライブラリーとかフレームワークになります。
Aurelia Framework = フロントエンドフレームワーク
これから紹介するAurelia Framework(以下、略してAurelia1)はブラウザで動作するWebアプリケーションのクライアントを作成するためのフレームワークです。さて、これで皆さんふわっとAurelia1を理解できましたね。
なんでAurelia1？
気になりますよね。なんでAurelia"1"なのか。え、そこじゃない？なんで1かと言うと、もうすぐ2がリリースされるからです。まだ、v0.7なのでもう少し先になりそうですが。
他のフレームワークではなくてなぜAurelia1なのか？
フロントエンドのフレームワークは2020年時点では、React, Vue, Angular2が御三家です。ついでに言うと、シングルページアプリケーションと言った複雑で規模な大きな開発ではTypeScriptがデファクトスタンダードの地位を得つつあります。個人的にはFlow好きだったんだけどなぁー。
この状況で、別のフレームワークを選ぶからにはなんか理由があるのか？ない。そこにあるのは好みだけ。
以下真面目に利点だと思うこと
- TypeScript を標準でサポートしてる。ではあるけど、JavaScriptでも書ける。
- Router等の基本機能は標準で含まれている。その他SPAで必要不可欠な機能は公式がpluginを提供している。
- フレームワーク特有の呪文が少ない。ECMAScript2015以降の仕様についていける人なら学習コストが低い。（SPA自体の仕組みは学ぶ必要が無論あるが）
以下欠点だと思うこと
- サードパーティーのpluginが乏しい。必要な場合には自分で作る必要がある。
- 専用のデザインライブラリが乏しい。CSSのフレームワークを組合すとしてもスクラッチで書くCSSの量が増える。（デザインよりの人には良い点かもしれない）
- 採用事例が乏しい。（特に日本語圏、商用はまだないかもしれない。）
- コミュニティー活動が活発ではない。（上とかぶるけど、フレームワークの元コードを読めるエンジニアが一人いれば済む話でもある。）
ざっくりまとめると、エコシステム全体でみるとちょっと厳しいかなと言う感じがするし、あえて他のメジャーなSPAを押しのけて採用する利点が見えない。
じゃあ、なんでと言われて好きだからというポエムはなしにすると、打算としては下記の利点を感じるから
- 教育コストを下げれそう（あくまで、まだ仮説です）。
- v1 はともかくとしてv2 はテンプレートもAPIも野暮ったいところが洗練されて期待が持てそう（あくまで、まだ希望的観測です）。
- DX（開発体験）が良さそう（あくまで、まだN=1 の意見にすぎません）。
以下は自分の経験を振り返りながらですが、フロントエンドの開発者のスタートラインに立とうとすると、結構しんどいわけです。で、しかもメジャーなフレームワークをどれか１つ選ぶと基本それにかかりきりになるし、キャリアもそのフレームワーク固定になりがち。フロントエンドエンジニアになる人も大変ですが、開発チームにエンジニアを連れてこないといけない人たちも大変です。いやだって、第一希望は使ってるフレームワークがりがりかける人、最近だとできたらTypeScriptで！って絞り込み条件が追加されるし、いないですよねー。高いですよねー。こういった状況で、フレームワークは違うけど、なんかしらの経験があればすぐキャッチアップできるフレームワークを採用したならそれだけで、競争力になるんじゃないかなと思うわけです。
ある人がプロダクトや理念やらに共感して、ともかくそこで働きたいなと思っても残念ながら使ってるフレームワークが違うと、うーんとなるわけです。これは、採用側もだし、エンジニア側も。これは、シニアとかミドルのエンジニアに関しての話ですが、Aureliaの良いところはWeb開発の基本線をフレームワークが覆い隠さない思想なので、ジュニアのエンジニアがシングルページアプリケーションの開発する際の負担も減らせるんじゃなかろうかと思うのです。
あくまで、まだ試してないので仮説の域を出ない意見なので説得力は現時点ゼロなわけですが、そういう期待があるので使ってみようかなと。
追記
Qiitaにプレビュー版のAurelia2を使った記事を書きました。
