フロントエンドの未来

この物語はフィクションです。

なんとなく僕らと職種の近い(ツインテールの)女の子が書いた、現在のフロントエンド界隈に対する感想と疑問と問題定義という設定です、登場する人物・団体・名称等は架空であり、実在のものとは関係ありませんよ

最近久しぶりにフロントエンドを担当することになった。もともとマークアップエンジニア(これも死語かな？)として今の会社に就職したけれど、色々と自分で勉強してみている内にサーバーサイドにも興味が湧いて、ここ2年程フロントエンドから離れていた。だから久々にフロントエンドを触ってみて、「React？聞いたことあるかも？」、「Fluxって何？」みたいな状態で、相変わらずの技術の変性のスピード感にちょっとどぎまぎしている。

私がReactを知ってから3年、初めてBackboneを触ってから6年(…年齢がばれるなぁ)、フロントエンドの世界は本来知っているべきことを知ったうえでさらに進化してきたなと思う。クライアントサイドのMVCフレームワークが生まれる前のころは、当時の私みたいなプログラムの書き方の分からない人や、JavaScriptを軽視してたプログラミングのできる人による、jQuery一辺倒の保守性にひどく欠けたプログラムの書き方が普通で、他の人の書いたWebページのコードを引き継ぐのは本当に苦痛でしかなかった。

Backbone、Ember、Angular、Spine、Vue、…本当に数えきれないほどのクライアントサイドMVCが出てきて、消えていった、そのどれも勉強してみると面白いと思った。根本を見失ってしまってはダメだと思っていて、結局のところこれらMVCフレームワークのどれもが解決したいのは、保守性の担保できるわかりやすいモジュール化、MVCという単語を生み出したSmalltalkの目指していた所と何も変わらないと思う。ただ、MVC以外にも考え方は色々とあって、その上でみんながたどり着いてとりあえずは今のところベストと考えられる一つの答えがReact + Reduxなのかなと思う。

少なくとも私はReact + Reduxがとても好き。
immutableな実装を強いるフレームワークは、昔からlispが好きでしょうがない私にとってとても相性が良い…

…閑話休題

そんなReact + Reduxという現時点での素敵な組み合わせをもっても、現状のフロントエンドにはやっぱり不満がある。本当はこれが一番の問題且つ本題で、相変わらずビルドシステムは混在していてー{gulp, npm script, Makefile, grunt?!}、bundlerも然りー{browserify, webpack, componentってのも昔あったかな？}、MVCフレームワークの混在っぷりは前述のとおり、数あるaltJSなんて数えたくもない。そしてこれらをうまく組み合わせてたかだか1ページのHTMLを作り上げるのにどれだけ労力がいるのか考えると…というか実践してみると、正直楽しくはあるけれど、若干辟易してもくる。

私はWebAssemblyがすごく気になっている。
もともとEmscriptenが好きで、UnityによるC#->C++->LLVM-IR->JavaScriptとかみていてすごく萌えたし、WebAssemblyは最初のターゲットはC/C++と謳っているので、もしかしたら一瞬でも「HTMLとCSSとC/C++ができます」っていえるマークアップエンジニアが重宝されるときが来るのかもと考えると楽しくなってくる。

だから早くみんな面倒くさいビルドから距離をおいて、未来を見越してWebAssemblyを使ってC/C++でフロントエンドを実装しちゃえばいいのに…そう思いながら今日も大好きで大嫌いなJavaScriptを書いている私もなんだかなー