00:07
はい、みなさんこんにちは。kkeethことくわはらです。本日もやっていきましょう。
kkeethのエンジニア雑談チャンネル。この番組では、ウェブ業界やエンジニアリング、
いろんな技術についての情報を、雑談形式で発信していきたいと思います。
で、今日はタイトルにありますJSフレームワークの変遷をまとめているところと書いてますけど、
このタイトルにした背景が、明日ですね、OOC、オブジェクトオリエンティッドカンファレンス2024が開かれますと。
参加される方もたくさんいらっしゃると思います。
数年ぶり、コロナ禍があったのでOOCはだいぶ間が空いたんですけど、シャープ2がついに明日開催されますと。
前回と会場は同じで、東京はお茶の水上司大学であります。
厳密にすると、お茶の水駅みたいなのがあるんですけど、
あそこではなくて別の駅にお茶の水上司大学があるっていうのはそこだけ気をつけてください。
で、前回も、ちなみに弊社株式会社ユメミはスポンサードさせていただいて、今回もしてます。
で、スポンサーブースも出していたんですけど、前回はさらにランク高いプランで出してて、
登壇ワークを1本確かいただいてたと思います。
で、そこで僕が喋らせていただきました。
僕全然設計に詳しくないんですけど、設計とエンジニア組織、開発チームとかって割とリンクするものあるよねって、
前回ね、CFPを実は出したんですよ。
第1回の時僕CFPを出して、自分でも登壇したいなっていうので出したんですけど、
そのタイトルが今日のJavaScriptのフレームワークとかJSの開発設計とか思想の変遷とか歴史をたどっていって、
今のモダンフロントエンドの開発設計の思考とか思想っていうのはどうなんだろうっていうのを自分なりにまとめながら話してみようっていうCFPを出したんですね。
で、前回はそれでリジェクトを送られまして、スポンサーブース、スポンサーワークが会社であったのでそこで違う話をしたんですね。
で、今回第2回は別にCFPは出してないんですけど、
弊社の新卒園ジニュアルの方がリジェクトオブジェクトオリエンティティカンファレンスという公式のイベントをやりたいというので、
僕もそこにちょっとだけ関わらせていただいてて、その効果は過去にいろんな放談をリジェクトをいただいた方にアクセスをして、
今回のそのタイトルを改めて深掘りとか、掘り返しで喋ってみませんかっていろいろお声掛けをしてたんです。
その中の一つに僕のJSフレームワークの編成のお話も引っかかったらしくて、お声掛けいただきまして、
僕的には面白そうだなっていうので、開拓をして一応応募を出したというところですね。
で、今回めでたく採択になったので、リジェクトオブジェクトオリエンティティカンファレンス2024、
2024っていうか来年もやるかは知らないですけど、
今年のオブジェクトオリエンティカンファレンスのリジェクト版の方ですね。
来週の金曜日ですね、29日の夜18時半からスタートでやります。
03:04
厳密なタイトルは設計カンファレンスエクステンズOOCというものですね。
いわゆるリジェクトのお話です。
もう既にコンパスのページが公開されてますので、興味ある人はそこから見て参加許可していただければなと思いますが、
絶賛スライドは未だにゼロページです。進捗は全くのゼロですけど、
メモ書きだけバーッと書いてて、あとはそれを書き起こすだけだろうというところまで一応行けてます。
今回でも登壇者の方々の顔ぶれ見てますと、やっぱり知ってる人何名もいて、
いろんな方々が自分の設計の話をしゃべるんだろうっていうんですけど、
本編というかOOC本体の方では著名な方々であったり、
設計に関してはもう第一人者みたいな方々が登壇されます。
なので、この顔ぶれいりゃそりゃそうだよねみたいなところは正直あるんですけど。
なので、お茶を濁す感じにはなってしまうかもしれないです。
特に僕の登壇はお茶を濁すかもしれないですけど、冒頭だし僕1本目なので、
あんまりハードルも高くないので、もうサクッとしゃべって、
あと他の人たちの学びを聞こうかなっていうところでいますので、
全然今緊張してないっていうのが今回の逆に不安でありますね。
こいつスライド大丈夫かっていうのを自分で思いながらですけど。
余談をさせておき、本編に入っていきたいと思います。
で、JSフレームワークで歴史をわざと調べつつまとめつつですけど、
しゃべっていきたいと思いますが、歴史を語る上で、JSのフレームワークですね。
の歴史を語る上で、何のフレームワークをピックアップするかっていうのがすごく悩ましいんですけど、
まあまあ、やっぱ著名というか、名前を馳せたものばっかりが上がってきますね。
はい、ザクッと時系列でしゃべりますと、
スタートは1990年代末から2000年代初頭じゃないかっていうふうに言われています。
ここからいわゆる黎明期という方もいらっしゃいまして、
Javascriptに登場したのが1995年ですね。
Chrono Triggerが発売されたやつですね。
当初はですね、フロントエンドの開発というと、いわゆるフォームにバリデーションとか
簡単な動的要素をちょっと入れてるぐらいの振る舞いっていうのがJSからやってたんですけど、
それが2006年に超有名な、今でも現役で動いているJQueryが爆誕しました。
これが2006年でジョン・レシグが作って、これが一気にJavascriptの注目を浴びるフレームワーク。
フレームワークと言うと僕は違和感しかなくて、こいつはライブラリだろうと思ってますけど。
これのおかげでですね、ウェブ解析がだいぶ劇的に簡単化した。
DOM操作っていうのがすごく楽になったのが本当にでかくてですね。
そこからウェブのページっていうのを動的に操作したり振る舞いを加えるっていうところに
かなり注目とその使いやすさっていうのが入っていったっていうところですね。
あとはクロスブラウザー互換性問題っていうのもJQueryが助ける一助となったんですね。
その使いやすさから一気に人気になった。
そこからAJAXみたいな思想も出てくるんですけど、それはフレームワークの歴史ではちょっとないですけど、
それもあってJQueryとの親和性がAJAXとはやっぱり高かったので、JSが一気に広まっていったっていう歴史がある。
06:05
そこから2010年代初頭まで動きます。
ここでその当時流行ってたいわゆるMVなんちゃらみたいなお話が飛び交ってて、
フロントエンドだとやっぱりMVCですね。
モデルビューコントローラーパターンっていうのがだいぶオッドな話題でした。
その当時は旧三大JavaScriptフレームワークと言われるものですね。
一つがBackbone.js、一つがEmber.js、もう一個がAngular.jsですね。
AngularはGoogleが作った例のフレームワークで、今のAngularではないフレームワークですね。
これらが2010年代に登場しまして、それぞれがほぼ2010年、2011年にリリースをされてて、
各社、各エンジニアがそれを使ってアプリケーションを作っていきました。
どのフレームワークも基本的にはMVCパターンっていうのを採用したフレームワークで、
どれを使うか、思想と好みな感じはすごくありましたけど、
確か若干Backboneが早く出てたはずですね。
というので、こっちが先駆けなんじゃないかなって僕は感触はありますね。
MVCパターンを使っていたので、ちゃんとコントローラーとビューとモデルが分離されてた。
なので振る舞いと構造っていうのをしっかり分けて、
データのところをゴニョゴニョするっていうモデルっていう思想がはっきりしてましたね。
逆に言うとそのせいか、ドムの方の操作っていうのが、
どこまで切り分けるかが難しかったんですけど、
AngularJSが割とMVCと言っておきながら、
ビューとコントローラーがかなり近かったっていうのはありますね。
割とドムにまだまだ頑張れるだろうっていう思想がAngularにはあって、
いわゆるディレクティビーみたいなのをどんどんAngularは設定をして、
いろんな操作とか振る舞いを書いていくんですけど、
割とビューとコントローラーの依存性が高かったので、
僕はあんま好きじゃなかったし、
当時は革新的に注目を浴びたんですけど、
実際書いてみるとめっちゃ大変で、うーんって思いながらでした。
そんな時代があって、そっから2010年代後半の時期ですね。
から現代のフレームワークがちょっとずつ生み出されていくと。
ちょうど2013年にリアクトが登場ですね。
当時のFacebook、今のメタ社からリアクトっていうものがリリースされました。
いわゆる仮想ドムと宣言的UIっていうのを導入して、
コンポーネントベースの開発を一気に売り出したっていうのが、
やっぱりこの先書きはリアクトだと言って良いでしょうと思います。
ここから一気にですね、JavaScriptのフレームワークの設計質は
みんなこれに寄ってったって感じがあります。
いわゆる宣言的UIとコンポーネントベースっていう開発のフレームワークになったっていうのが、
すごくドラクティックな変化だったなと思います。
2010年代にMVCパターンが設計したと思いきや、
そのちょっと後にいきなりコンポーネントベースっていう風に変わっていったのが
かなり面白かったし、それだけドラスティックに色んなものが変わったので、
フロントエンドの開発者としては楽しかったし、
変化が激しすぎて大変だったってどっちの面もありますね。
09:02
それとほぼ同時期ですね、2014年にEvan Youが
個人でView.jsっていうのを開発してリリースをしましたと。
より簡潔な書き方、APIを提供していて、
開発柔軟性も重視したフレームワークとしてかなり注目がありましたね。
中国とか日本、いわゆるアジア圏ですごくView.jsは伸びていったっていうのが記憶がありますけど、
そこからアメリカでも人気を集めて世界的に有名になったっていう流れだった記憶があります。
それらの流れを見てGoogle社が新しくフレームワークを作り直して、
昔の旧AngularJSと全く別物のフレームワークとしてAngularというのがリリースされました。
これが2016年ですね。
これが本当に厳しいというか互換性が全くないので、
昔の資源、AngularJSの時の書き方全く使えなくてですね。
もうほぼ作り直しっていうところにアビ強化を僕は聞いてましたね。
いろんなところ。
もしくはもうAngularJSの方の書き方で作ったアプリケーションをそのままメンテナンスをするっていう
強い意思で運営されてた会社さんもいらっしゃいますけど、
もうほぼなくなったんじゃないですか。
未だに生き残っている可能性はゼロではないですけど、
もう一気にやっぱり不採となってしまったので作り直そう。
これシステム的には動いてるし、
枯れてるって意味ではメンテナンスすればいいって話ですけど、
採用の文脈で言うと、
旧AngularJSでうちは開発しますって言うとエンジニア多分毛嫌いすると思うので採用できないんですよね。
というので不採って単純にシステムだけの話じゃなくて会社の未来の話を考えると
どうやったって変えなきゃいけないっていうそういう視点はあるなと思ってて。
その間あってAngularJSは乗せ替えるか置き替える人たちが増えたと思いますが、
置き替えるんだったらAngularJSではなくて、
リアクトとか今一番話題のやつの方がいいんじゃないっていう
エンジニアさんもたくさん多分いらっしゃったんじゃないかなっていうのが僕の予想です。
で、AngularJSのでも唯一というか大きかったのは、
リアクトとビューってのはやはりビューをベースにしたフレームワークでした。
要は見た目のところに重きを置いているフレームワークで、
振る舞いとかデータってところは別でどこで担保しましょうと言うんですけど、
AngularJSはやっぱりいわゆるフルスタックフレームワークに近いところがあって、
細かいところとかいろんなライブラリとか多数の機能っていうのを
エコシステムに頼るんではなくて自身のフレームワーク内に機能として持っている。
これが大きかったと思います。
もう一個はTypeScriptベースで再設計されてました。
デフォルトでTypeScript使えるようになっているし、
コンパイラーとかトランスパイラーも入ってます。
あとはテストもボイラープレートに入ってたので、
本当の意味で最初プロジェクトスタートするっていう意味では
AngularJSがしっかり揃っていた。
CLIもしっかり揃っていたっていう意味では、
そこはさすがGoogle社だなと思いましたけど。
ただインターフェースとか書き方がちょっとドロークトクすぎて、
ここに違和感というか気持ち悪さを感じた方も多分いるんじゃないかなと思います。
慣れればなるほどって感じにはなるんですけど、
僕も最初これなんだみたいな感じはありましたね。
12:00
リアクトドビューに慣れてしまったせいで、
AngularJSの書き方があまりにも特殊すぎたので、
学習コスト高いなってはちょっと思いましたけど、
ただ後半的に思うのは、
学習コストってどのフレームワークも使っても、
結局エコシステムもいろいろガチャガチャ混ぜ合わせて、
開発環境を作っていくと、
ことを加味すると、あんまコストは実際には変わらない気はしました。
ただスタートという意味では、
AngularJSは速いっちゃ速いですけど、
スタート、ダッシュはできないなって感じましたね。
その意味ではリアクトとかビューで、
まず作れるものをガリガリ作っていって、
ビジネスとか要件に応じて、
いろんなライブラリとかをどんどん導入していって、
っていう風な流れがあったんですけど、
最終的にはあれもこれもどうせいるよねっていうので、
一番最初にいろんなライブラリとかを検討したりすると思うんですけど、
そういうのを加味して開発環境を作るんであれば、
Angularみたいにもうワンセットになってます、
っていうものの方が良かった気がします。
ただインターフェース、書き方ってところの神話性が、
エンジニアとしては微妙だなって。
エンジニアって主語が大きいですね。
僕はそう感じました。
で、現代まで戻ってくるわけですけど、
現代もしくは次世代のフレームワークっていうところで、
Next.jsとNext.jsっていう、
いわゆるラッパーフレームワークっていうものが、
そこから起きてくると。
やはりリアクトとビューっていうのは、
先ほど言いましたけど、
UIとかビューの方を担保する、
そこを主戦場とするフレームワークですので、
アプリケーション全体を開発するっていう意味では、
そこ以外のいろんなものを加味しなきゃいけなくて、
そういうのをワンセットにしてくれるフレームワークは、
やはり需要というかニーズがあった。
その中で、
Next.jsって実はだいぶ前からあったんですけど、
一時期Next.jsが出て、
もう猫もシャクシもNext.jsで良くないっていう流れが、
一瞬、プロントエンド界隈にはあったんですね。
僕は副業してても、
どの会社でも、
うちNext.js使ってるとか、
Next.jsを次でやりたいんだよねっていう話、
もうめちゃめちゃ聞きました。
とにかくNext.jsっていうワードが出てて、
そんなかっていうぐらいですけど、
使ったら分かります。
その当時のビューとかリアクトの大変さを、
Next.jsがいろいろラップしてくれてて、
とりあえずNext.jsを入れてれば何とかなる、
感は確かにあった。
そっから多分Next.jsのバージョン8か9ぐらいからかな。
ドラスティックに、
Next.jsの思想を丸パクリじゃないですけど、
ほぼほぼ踏襲をして、
新しく生み出したNext.jsっていうのが、
すごくホットになって、
そっからもうラップフレームワークを使って、
開発するのがベースになったなっていう感触はありますね。
Linux vs Next.jsの話で、
kentoshi.さんが挙げてたポイントが、
1つはラーニングカーブと、
学ぶ知識の有用性。
あー、はいはいはい。
ラーニングカーブはよく出ますけど、
学ぶ知識の有用性は面白そう。
Linuxの方がウェブスタンダードに即した設計なので、
無駄な知識になりづらいとおっしゃってました。
それはね、僕も思ってます。
フレームワークのAPIとかインターフェースに乗っかるのはいいですけど、
ウェブ標準に乗っかってるかっていうと、
そこが僕は結構怪しくて、
JSXも本来ウェブ標準かというと怪しいんで、
そういう意味ではリアクトってどうなのって話はあります。
で、いくんだったら、
ウェブコンポーネンツがむしろウェブ標準になっていくので、
ウェブコンポーネンツベースのフレームワークの方が、
いいんじゃないって気はしますけど、
ウェブコンポーネンツベースのフレームワークって、
15:01
開発に耐えられないんですよね。
大変だし、書き方ムズってなってて。
そこのこう、難しさとか有用性っていうのは、
バランスとってくれるフレームワークが出てきたら、
もっといいなと思ったりします。
はい、あとご意見ありがとうございます。
で、あとはラッパーフレームワークとして、
ネクストナクト出たんですけど、そこから、
そもそも仮想ドムに依存するからパフォーマンス悪いとか、
オーバーヘッド生まれるじゃんっていうので、
そこにマッタをかけた、スベルトっていうのが生まれて、
で、さらにスベルトのラッパーフレームワークとして、
サッパーっていうのが生まれた。
で、今はサッパーではなくて、
スベルトキットっていう名前で、
新たに作り直されてて、
だいぶエコシステムの周波数も高くなって、
スベルトキット使われて、
会社さんも結構増えたなっていう感触があります。
ま、やっぱ高発的なものもあって、
全身のペインっていうのをしっかりカバーしてるっていうのは、
でかいよなと思いますね。
とはいえ、まだネクストの一況時代は終わらんとは思ってますし、
一況で着地すんじゃないかなと思います。
それに唯一マッタをかけられるのが、
今のところはリミックスだろうなって感じはありますよ。
さておき、ラッパーフレームワークが出たところで、
メリットとしてはやはり、
サーバーサイトレンダリングとか、
静的サイトジェネレーティングとかも可能にするっていうところですね。
選択肢と実際に必要なのどうだのっていうところに、
重きを置いていくと、
やっぱラッパーフレームワークでいいよねって話があって、
今はこれがもうデファクトといって良いでしょうと思います。
で、軽微なものとか、やっぱり側だけを欲しい、
データとかなんちゃらは基本的にAPIか、
キャッシュで担保するからいいよっていうんだったら、
そのリアクトとかビューでいいんじゃないのっていう気はしますね。
あとは、JSのフレームワークとかで歴史を語ろうとは絶対、
ストアライブラリーの話も本当はしなきゃいけないんですけど、
今回フレームワークだけの話でとどめます。
ただ、ツールチェーンってのお話はやっぱり神はしないといけなくて、
昔のWebpackとか、あとNPMバグワーとかたくさん、
その辺のお話もあったんですけど、
最近はバンドラーとしてBeatと、
Snowpackも一応まだあるとは思うんですけど、
ほぼほぼBeatを一挙なんじゃないかな、感じがあります。
これらのツールのおかげで、ラッパーを使わないんであれば、
Beatからのテンプレートを使うほうがかなり良いでしょう。
体験も速いし、ビルド速度が圧倒的に速いのでね。
やっぱりESビルドが速いなっていうところはありますけど。
で、開発体験の向上とか、
テンプレートの豊富、リッチさっていうところが
どんどん向上していって、今に至るっていう感じですね。
というので、JSフレームワークの歴史っていうのは
Web技術の進化とやはり進んできているのはありますけど、
そもそもの世間のニーズに合わせるための
何の機能必要ですかとか、
どういうライブラリーが必要だかっていうところが
加味して進んできたっていうのがやっぱりあるので、
ビジネスとセットで進んできたっていうのはすごくあると思ってますので、
新しいニーズとか新しい時代どうなるかっていうのは、
今の人たちが何を求めているかってところにやはりつけるので、
今のところまとめている限りだと、
設計思想の変遷って僕はあんまない気がしてます。
結局人が何を好んでて、何をペインと感じるかってところに
重きが置かれる気がしてるんで、こんなところかな。
18:02
新しいアイディアとかアプローチも全然ウェブ開発にもたらされていて、
ウェブなのにファイル操作ができるようになったりとか、
よりウェブとモバイルですかね、
モバイルのネイティブAPIをコールするみたいな体験が
近づいていっているっていう感触があるので、
その境界線がどんどんグレーになっていくっていうのが
ざっくり見えているところではあるんです。
もうちょっと僕がまだ調べ始めたばっかりではあるので、
今後も何か学んだ結果、
こうなったもんなっていう予想があったらまた
朝方で喋っていきたいなと思います。
はい、今回はこんなところで終わっていきたいと思います。
いつも聞いてくださり本当にありがとうございます。
ではまた次回の主力でお会いしましょう。
バイバイ。
