フロイドの狂気日記

時は流れ、曲も終わった。もっと何か言えたのに。

PR

Reacct/VueよりもAngularの方がwebの良い未来だったはず

PR

仕事でVueを使っている。DBに数百テーブルあるような規模のアプリを複数連携させているような中規模~大規模案件の改修作業である。Vueは2.X系。3.Xでどうなったかはわからないけれど、使ってみた感想はjquery2.0じゃねえか、というものだった。

 

Angularで仕事をしたあとだと自由すぎて、こんなの中規模以上アプリで使うなんて狂ってるとしか思えなかった。もちろんAngularを知らなければ、jqueryよりいいよね、とだけ思っただろう。すでにwebの世界ではreactとvue勢力に2分されつつあるか、react1強になりつつあるみたいなので残念に思っている。

 

■モダンフレームワークと対極にいるjqueryおじさん

かつて、というか今も使われ続けるjqueryというライブラリがある。これはお手軽にDOM操作ができるのでかつてはバニラjsより重宝され、webアプリでは長い間使われ続けた。てか今も使われている。一方で、jqueryUIだのjqueryDatepickerだのと派生ライブラリが大量に生産され、使ってるのかどうかわからんようなライブラリを大量に読み込んではアプリを重くし、適当に書いて動くのでスパゲッティコードになりやすいということで、やがて嫌われ始めた。今ではモダンフレームワーク必須の人々に侮蔑的な目で見られてさえいる。jqueryの弱点を解決するのがフロントエンドのフレームワークだと思ったのだが、形を変えてもとに戻ったように見える。

 

■Angularの強制力という魅力をプログラマは拒否した

Vueとの決定的な違いは強制力だろう。Angularはありとあらゆる場面で書き方を強制する力をもっており、最終的には誰もが同じ書き方をする、という点が魅力だった。そしてそれがよりよいwebの未来になったはずだった。

 

たとえばAngularには明確なライフサイクルがあって、どのタイミングで何をするかを明示的に書かされる。細々としたルールもあって、面倒くさいが一度理解すると、どのタイミングで何をするのかを考えてコードを書くようになる。これは、データの流れや処理を追うことが極めて簡単になり、チームコーディングに向いていると思った。

 

Angularはcomponent作成時に3つファイルを作ることを強制する。css,html,tsの3つなのだが、これによって各component専用の処理、view、デザインを明白化することができ、globalのcss定義とは一線を引くことを強制できる。プロジェクトのメンバーが増減したり、クライアントからの機能要望が増えても、マネージャーはファイル管理の設計をせずにすむ。一つの機能に対して、専用のレイアウトや処理を用意したければ、componentに付随したhtml/cssに書けばいい。あるディレクトリの下に新規画面専用のCSSファイルを作っていいでしょうか?だとか聞かなくていいのだ。

 

Angularは型を強制する。変数を定義するたびに、その値がなにかを明瞭化しなければエラーでコンパイルしてくれない。非常に細かい。any型などの適当な抜け道もあるが、どうせ型を強制されるなら、その変数がなにかを考えるようになる。

 

Angularはjsとtsの混在を拒否する。基本的にtsで書かないと怒られる。document.getElementByIdのようなバニラjs構文を書くことは許されない。js構文のすぐ上に// ts-ignoreと書くと動く。いちいちそんなコメントするぐらいならtsで統一しようというふうになるだろう。

 

Angularはほとんどすべての機能を提供するのでサードパーティ製品があんまりいらない。これも素晴らしいメリットで、Angularが提供するデフォルトの機能で大抵のwebアプリは作れる。大規模になってもそれは変わらない。jquery時代に悩ました、誰がメンテナンスしているかわからないライブラリは不要となった。

 

Angualarは後方互換性を保持しているので、書き方が変わらない。1.X系を一気に切り捨てた反省からか、2.0~今に至るまで互換性に気を配っている。僕が数年前に買ったAnguar2.0~4.0時代のkindle本を読み直しても通じる。

 

言うなればjquery時代のwebのダメさすべてをフレームワークで強制的に解決したようなものだった。だが残念ながらAngular時代は始まる前に終わったように見える。

 

■手軽さに勝てないプログラマ世界

Vueに手を出せばわかるが、ほとんど半日で学び終わる。componentの作り方を覚えて、v-if、v-modelのようなデータバインドを理解すれば、アウトラインは覚えたも同然だ。component内でjs処理を混ぜこんでも問題ないし、フレームワークはデザインの適応やjsの処理順に強制力をもたせていない。そのためすべて自分たちの手で設計し、把握しなければならない。chromeの拡張デバッグ機能があろうと、長くアプリを開発保守していけば破綻する運命にある。それでもAngularより利用者が多いのは手軽さ故だ。jqueryがそうであったように。

 

reactで大規模アプリを見たことがないのでなんとも言えないが、hooksの流行を見るに、どこかの誰かが作った小さいコードを参照する、だとか、記述を少なくするほうに進化するということに大勢のプログラマは抗えない。状態管理のお作法とて、1年-2年で変化するなんて信じられん。reduxで状態管理をしたアプリの保守は誰がやるっていうのだろう。それともrecoilが出てきたので全面刷新をします、とかやっていたりするのだろうか。

 

手軽さゆえに属人性を排除できず、やがてデスマーチになっていくことや、人材の流動性によって、各プロジェクトの参入後の説明コストは上がり続ける。だったらweb業界全体の手癖の悪さをフレームワークが強制することで、結果的に業界全体の開発効率は上げることができる。プロジェクトごとにではなくwebフロントエンドのすべてが、である。Angularがデファクトを取った世界線なら、それさえ可能だったように見えるのは気のせいか。

 

■終わりに

どの時代に作られたかによって同じフレームワークでもお作法が違っていて、設計者によって大幅にアプリテイストが変化するようなフレームワークデファクトを取ったのは残念極まりない。react/vueだとバベルの塔を作りがちなweb界隈の手癖の悪さは治らんだろうなあと思うし、それどころかクールな進歩によって次々に作業を増やして新規概念を積み上げていくことになるだろうから、ころころクライアントを変える僕のような人間には辛い。それでもZennにAngularのエントリが投稿されるのは少ないし、reactは多数のエンジニアが求めた答えのように思える。一つのアプリに長く関わるというなら正しいのかもしれない。

それでもGoogleがweb開発者のビッグブラザーになっていただきたい人生だった。