00:16
はい、株式会社ゆめみのキースこと桑原です。この番組では、凡人ジニアの私がどこまでできるかという挑戦のもと、
学んだこと、また考えたことを発信していけたらいいなと思っております。はい、第24回ですね、今回で。第24回は、
フロントエンドの今すごくご活躍されている水淳さんという方がいらっしゃるんですけど、その方が書かれた今後のフロントエンドの予想みたいな記事を
ありまして、それを今日はちょっとピックアップして、私なりにその記事をベースに思ったこととかを述べていければいいかなと思っております。
途中途中引用文が多めだったりするので、あれですけども、
全文読むこともないですし、そのリンクそのものはまたこの配信の概要欄に書いておきますので、それを読んでいただければわかりやすいかなと思いますが、
読みたくないというか、読む時間がなく、ざっくり聞いてみたいという方はこちらの配信だけ聞いていただければと思います。
はい、一応私一度これを読んだことがあって、これ2回目なんですけど、ちょっと思うところがあって、今後は発信します。
一つ目の引用です。クソアプリの中身を覗いてみたらリアクトで…みたいな話も増えてきたので、最新のフレームワークを使えば品質が高いみたいな現象も
薄れてきて、頑張って正しく使いましょうというフェーズというお話ですね。これは僕から、僕はというか多分皆さんもそうだと思うんですけど、
別に最新のフレームワークがホゲホゲみたいな話って、別にこれはいつの時代も変わらないですね。その時代その時代においての最新のフレームワークというのがあって、
フレームワークというか、そもそもツールとか技術そのものっていうのはやっぱりそれ一つで物事は完結するということはなかなか難しいですし、
それ自体がいわゆる銀の弾丸と言われる最強のツールというわけでもないですね。やっぱり一長一短はありますし、
ツールを使えば何事も解決するというわけではもちろんやっぱりないのかなというふうに思っていますね。
なのでリアクトでと言って、リアクトを使うからといって素晴らしいのは必ず作れるというわけではないし、設計もしっかりですし、書き方とか使い方によっては全然
しょぼいアプリが作られてしまうということもよくある話なので、やっぱりツールに頼るというのは良くないというか、ツール依存するというのは良くないと思いますね。
頼るのは別に結構ですけど、それから技術を使うというのは技術は道具ですので、何か問題解決するための道具として選択をしていくのがいいのではないかなと思っています。
またですね、Flowというのがあったんですよ。Flowタイプといわれる型的なものを入れるためのツールがあったんですけど、
そのFlowというのが今後は使わないでしょうねという話です。
03:02
一応使っているのはFacebook社ぐらいしかないんじゃないかと思いますね。
個人で使っている方もいらっしゃると思うし、プロジェクト的には昔使っていて、今もずっとそれを運用しているというプロジェクトもあるのではないかと思いますけど、
個人的にもうFlowは使わないかなと思いますね。
よっぽど理由がない限りはですね、今はタイプスクリプトが生まれて、正直言うと今のところこれが最適解ではないのかなと思っています。
タイプスクリプトがあるんだったら僕はバベルもなくても正直いいのかなと思ったりはしています。
もちろんバベルとタイプスクリプトの互換性ってのもありますし、バベルでも今タイプスクリプトのソースコードもバベルこともできるらしいんで、
バベルはあってもいいしなくてもいいと思っています僕は。
そこは個人とか皆さんで考えるところですかね。
続きまして次はバンドラーですね。
バンドラーって歴史いっぱいあるんですけど、有名なところでいくと全世界的に一番使われているウェブパック。
その次にちょっと前に流行って、今も根強い人気があって、そんなにダウンロード数も低くなく世界的に有名なものとしてパーセルバンドラーとかあるんですけど、
個人的にはパーセルっていうのはやっぱり本アプリというか、ちゃんと本格的なアプリケーションを作るときに使われるバンドラーとしては弱いのかなと思っていますし、
今まだまだ対応できる範囲が狭かったりとか、
ブラックボックスがちょっと強いので、あんまり設定がないっていうところに何がいいか何がいけないかっていうのはやっぱり一端はあると思うんですよ。
というところでやっぱり個人的にはウェブパック一択なのかなというふうに思っています。
今後どうなるかはまだわからないですけど、今のところのバンドラーとしてはウェブパック一択しかないかなと思っていますね。
はい次ですね。次の引用。
ビューの勢いがすごいが、見る限り本質的な設計方針に違いは出ないので、最終的にビューテンプレートを書くかJSXを書くかぐらいの違いしかない。
それぞれ一長一短なので、最終的にはリアクトと同じぐらいの位置に落ち着くだろう。
どちらかを使えるユーザーがあえて乗り換える強い動機はない。
ビューのメリットはJSXを使う必要がなく各種プリコンパイラーがいらなくて導入しやすいというところにあったが、
ビューもいろいろやるためにプリコンパイラーのステップが厚くなってきたので、今はこちらもそう変わらない。
ビューは全体的にむちゃくちゃイメージ、イージー側に倒している言語なので、リアクトより末端での破綻を起こしやすい印象。
この辺トレードオフなので全部ひっくるめて一長一短なので、ゼロベースだったら今はゴブゴブ、ユーザーベースもそれぐらいに収束しそうというお話でしたね。
全く同意ですね。
僕からしても好きな方を使えばいいんじゃないかなと思ったりしています。
個人的にはJSX、昔は嫌いだったんですけど、だんだん書いていくと流石に慣れてくるので、JSXでも今はいいのかなと思ったりしています。
逆にビューテンプレートは確かにイージーな方に倒してあるし、入門ツールとしてはテンプレートの方が書きやすいのかなと思ったりしています。
06:04
またWebコンポーネンツとかHTML標準に従うんだったらテンプレートで書く方がいいのかなと思っています。
やっぱりJSXはWebの進化にはちょっと相反するというか、ちょっとイレギュラーな進化を遂げてしまったな感は正直ありますけど、
一方でJSXって結局全部JSファイルなんですよね。
最終的にHTMLを書くというのはあるんですけど、
ですのでテストしやすいという観点、いろんなところで言ってますけど、という意味ではやっぱりJSXのほうがいいのかなと思ったりしていますね。
まあ書き方の違いなのであれですけども。
ただ個人的には感覚の話でいくと、ビューよりもリアクトのほうがもうちょっと真っ端というか早いところに手が届くような感覚が個人的にはあって、
その他にちょっと書く量が増えたり、冗長的な書き方があると思うところもなくはないですけど、
とはいえやっぱりちゃんと管理できるし、マネジメントできるっていうところでは僕はリアクトのほうが正直言うと好きですね。
はい、そういうところです。
で、あと次の引用としては単方向データフロー。
フラックス的な話ですけど、その単方向データフローっていうのはもう既定路線で今後もまあこのままいくでしょうっていうふうに水下さんもおっしゃられていて、
まあ私もこれは完全同意ですね。
やはり1個なんか方向を決めるというかちゃんとルールを決めてデータっていうのを管理するっていうのはやっぱり大事なことであって、
どっからでもアクセスしたり、どっから制御するとか、ストアにもいつどこでもアクセスできるっていうなんか正直言うとちょっとカオスになりがちだなっていうふうに思っています。
まあそういう意味でいくと個人の思想になるんですけど、私はやっぱりアンギュラーの思想っていうのはちょっとどうなのかなと思っています。
まあアンギュラーはちょっとフラックスじゃなくて完全にストリームでやるので、
ストリームRXの概念でやっていくので、あれはあれでちょっと個人的には好きではあるんですけど、
扱いづらいというかやっぱり取っかかり難しくてですね、チーム開発するんだったらみんながそれを知らないと結構つらいものがあるのかなと思っています。
パッと見てうんって言えない。結構落とし穴だらけなので、やっぱりちゃんと使いこなしたり、しっかりルール決めて格闘するならば、
RXが悪いって言われたけどめちゃめちゃいい技術ではあるので素晴らしいんですけども、
個人的にはアンギュラーよりもいわゆるRXよりも普通のストア概念の方がいいのかなというふうに思ったりはしていますね。
どれぐらい使われているのかちょっと僕もよくわかってないですけどね、本当に。
はい、というところですね。
はい、次です。
SSRやエコシステム同士の連携はNextよりNextの方が優秀。
Next.jsのユーザーも一度はNextを見ておいた方がいいと。
ただし、Vue&VuxはTypeScript連携に難がある。
おそらくVueの競争相手はReactではなく、Next vs Railsという構図になるのではないかという気がする。
NextはNext.jsの発展型だったが、今はどちらかというと規約ベースの設計がどんどんRailsにできているというところで、
09:04
私的には書いたことあるとか両方ともちゃんと精通されている方ならばわかると思うんですけど、
正直言うとこれだけを書くとちょっと飛躍があるかなという感じがしましたね。
特に後半のVueの競争相手はReactではなくNext vs Railsという構図になるのではという、
ちょっと飛躍があるかなと思ったんですけど、わからなくはないですね。
私一応Railsも触ったことあるんで、あれですけど。
エコシステムの連携というのは確かに考えるとNextの方がやっぱり連携が強いのかなというふうには個人的に思ってますね。
書いた感じですけど。
やっぱりサードパーティーのところ、Vue周りのところはみんな活発に作られているし、
みんなVueが好きなんですかね、本当に。
どんどんどんどんVueに沿ったサードパーティーライブラリーがたくさん生まれていて、
そういうところもあってエコシステム連携が特に強いのかなと思ってますね。
僕も技術選定するとき、Nextの強さの一つにはエコシステムっていうのは絶対に理由に入ってくるんで、
Nextよりもですね。
はい、というところはあります。
でも世界中でも同様なのかなというふうに思ったりはしていますね。
勝手ですけど。
ただ、それは強い印象はあるんですけど、
別にNextとNextでもそんな大差はないのかなというふうに思ったりはしています。
あと、本当にタイムリーに今日、日付的には昨日かもしれないですけど、
Next.jsのマイナーバージョンアップが1個できたんですけど、
9.4ですね。
その9.4になったのにものすごい、マイナーの割には機能拡張がすごいされてて、
たくさんの目星機能が追加されているので、
今後またNext.jsがもっともっと流行ってくるというか盛り上がるのかなという気もしなくはないところですね。
ここからちょっとまだちゃんとどの機能が追加されたかって全部終えてないので、
後ほど終えていきたいと思いますけども。
はい、感じですね。
あとはレールズとNextの構図というところが個人的にはちょっと疑問で、
レールズがそんなに利用されているのかなというところが疑問の一点でありますね。
すごい、昔からそうですけど、レールズっていうのはDXがすごい高くてですね、
ものすごいデバッグ機能とかが豊富なんですよね。
なので、圧倒的な機能数とかDXを一度触ったらまあまあ、
凄わしいねっていうのはよく分かるんですよね。
ですし、それがあるからこそスタートアップ企業、今から小人数の企業とかでは、
早く早くプロダクトを作りたいっていう現場においては役に立つというか、
選択肢としてものすごい根強い人気があるんだろうなと思いますけど、
そんな大規模というか、垂直したアプリケーションとしてレールズを使うっていうのは、
個人的にどうなのかなという気はしています。
その理由とか云々はいっぱいあるし、これの議論はいくらでもしゃべれるんであれですけど、
ここではちょっと今日は控えますが、
なので、ナクストバスレールズっていう構図は、
なかなかちょっと飛躍感はなくはないですけど、
12:01
例えるとしたら分かりやすいかなっていう気はしましたね。
次ですね、あとはリアクトフェイスブックがSSRにあまり興味がないので、
SSR周辺のエコシステムに何かありすべて自分で組み上げる体力が必要。
ここに関しては、これもそうですね、書いてある通りだと思いますけど、
ただフェイスブックがSSRにあまり興味ないっていうのが僕はびっくりしましたね。
それの理由とかソースは載ってなかったんで、
何でそうなったのかなっていう気はしますけど、
確かにリアクトにSSRって昔からそんな印象なかったし、
そういうことを本当やりたい人は勝手にどうぞみたいな印象だというような感覚はありますね。
なので先に、Next.jsはもともとあったんですけど、
Next.jsが先にNextからものすごい進化したというか、
インスパイアされて超強化したSSRとかも対応したフレームワークとして登場して、
一気にNext.jsがバーッと流行ったっていう経緯があるんで、
それ見てNext.jsがまたもう一回バージョンアップして追いついてきたかなっていう感じはあるんですけど、
なので、でもそれもNext.jsそのものは確かフェイスブックチームではなかったはずなので開発が。
なので、フェイスブック社はSSRはもうそんな興味ないかなというふうに思いましたね。
というのもあとGoogleが、Googlebotの読み込みがどうなるかっていうのは、
今後Googlebotの仕組みとしてはSPAでもSEOがちゃんと対応されるというか、
Googlebotの進化により特にサーバーサイブレンダリングしなくてもSEOはちゃんと担保できますよっていう時代が来るっていう話がちょいちょい出てきているので、
それがどこまで早く来るのかっていうのはまた別話ですけど、
というのが遅から早から来るのであればSSRはしなくてもいいような選択肢が今後生まれるっていうのはあると思いますので、
その意味で興味ないっていうふうにフェイスブックは思っているのかなっていう勝手に思っています。
はい、そうですね。
なところで次ですね。
ステンシルですね。
ステンシルっていうツールがあるんですけど、
これはですね、僕はこれ触っといて損はないかなというふうに思っています。
というのもWeb Componentsの時代がいつ来るかわかんないですけど、
個人的にはWeb Componentsは遅から早から来ることはわかっていて、
これがもうデファクトスタンダードの時代が来るんだろうなと正直思っているので、
そのWeb Componentsをどういうふうに対応するとか、
Web Components時代にどういう選択肢、ツールを使うのかっていう一択としてステンシルっていうものがあって、
こちらを触ってみるのも別にいいのかなと思っていますね。
先取りっていう意味ですね、いわゆる。
今触るとしたら本当に先取りという意味でWeb Componentsの時代に向けてのツールとして、
これを触っていくのが良いかなと思っております。
何度も言っているWeb Componentsですけど、
いろんな意味でまだまだ今はですね、現時点では成熟していないので、
ちょっと導入はきついかなと思っています。
少なくとも本当にアプリケーション、お金とってやるアプリケーション開発として、
Web Componentsの選択肢はちょっときついかなと今は思っていますね。
15:00
いろんな理由もありますけど、2つあってIEですね、まずは。
IEについては対応をぶった切ってしまってもいいと思っています。
2021年まで対応しなきゃいけない気はしますけど、
もう死ぬことが分かっているブラウザを対応するのもなというのもありますし、
エッジブラウザがChromeのV8エンジンベースになるっていうのはもう決まってきているので、
それに乗っかれるんだったらもう完全にIEは死ぬことが分かっているので、
もう切ってもいいのかなと思ったりしていますが、それ以上はGooglebotですね。
やっぱりWeb Componentsと、まだGooglebotとWeb Componentsのところの対応ができていないので、
今Web Componentsやるとそこが結構苦しい話になってくるので、
まあそういう意味でまだWeb Componentsはないのかなと思っています。
あとWebAssemblyですね、いろんなところで勉強会で話を聞いたりしてるんですけど、
正直申し訳ないですけど、僕はここキャッチアップはできていなくて、
全然自分でもコード書いてないので、ここに関してはお話できませんって感じです。
あとPWAですね、PWA一つ引用しますけど、
SEOを考慮しつつ複雑な画面を持つ全部入りの場合はPWAとSPA技術を兼用することになる。
すでに難しいのにこの上にさらに難しいことをやろうとすると複雑度が爆発するので、
良いワークボックスの導入グレードを留めておいた方がいいのではないかというところですね。
弊社でも何度かPWAをやろうかという案件もなくはなかったんですけど、
なかなか実際に対応する端末とかOSとかを加味して、
さらにクライアントが要求提言に出てきた機能を考えるとPWAじゃないねっていう話が結局多くて、
なんだかんだPWAに対応していなかったんです。
ちょいちょいPWAの中の機能ですね。
Add to Homescreenとかオフライン対応とかキャッシュ回りとかみたいなところをちょいちょい導入したことはありますけど、
やっぱり書かれてる通りワークボックス導入してもうちょっと簡単に書きましょうみたいなところですね。
やっぱりGoogleがワークボックスについての記事を書いてるんですけど、それがすごくわかりやすくてですね。
英語と日本語の記事ももう十分あるんですけど、
あれ一通り読むだけでPWAだいぶ理解できるし、ワークボックスって結構素晴らしいツールじゃんっていうのは多分理解できると思うので、
触ったほうが良さもないでして、見てみて勉強になると思うんですけど、
なかなかやっぱり本アプリケーション開発で導入っていうと全部やるってのは難しいし、
PWAをやる本来の目的っていうのがどこまであるのかっていうのをちゃんと考えた上で導入するのがやっぱりいいっていう話ですね。
そういう意味でそんなに実践で使うケースって僕の中では結果として少ないかなっていうふうに思ってます。
昔はPWA結構来るは思ってたんですけど、やってるのと意外とそうでもないなっていう感じはします。
一番難しいのはそのキャッシュの戦略ですよね。
キャッシュの戦略とかキャッシュの設計、CDNで含めてどうやるかとかそのキャッシュ更新また削除、いつやるのかみたいなところもそうですし、
そのデータの担保、本番のデータベースのデータとウェブ上持っているデータとキャッシュのデータとみたいなところがあって、
18:04
それもどうするかという考えていくと意外とコースがかかるし、リスクもやっぱり取らなきゃいけないので、難しいんですよね。
やっぱり本当にキャッシュは無視できない、難しい範囲には入りますね。
というところです。それ以外またフルSSLとかそれは当たり前かもしれないですね。
プッシュ通知のところですね。プッシュ通知はソファリやらないだろうなってもありますし、
別の技術とかいろんなSaaS機能とかあったりするので、そこでプッシュ通知を実装すればいいと思うので、
PWAとしてのプッシュ通知っていうのがなかなか難しいのかなというふうに思っています。
では最後ですね、IEですね。何度も言っていますが、IEは早く滅んでほしいっていうのも、ここはもう規定路線ですね。
2021年って言うけど、もう今すぐ死んでほしいっていうブラウザーですね。
私はその6とか7で苦しんだことないんですけど、8ぐらいからちょっと対応したことあるんで、やっぱりいい思いではないなーって感じです。
ただモバイル対応するときはどっちかというと、SaaSの方が苦しんだ思いではあって、
みんなChromeで幸せな世界が来てほしいなっていうふうに思ったりはするんですけど、そんな世界が来ないなっていう感じですね。
というところではちょっとベラベラと喋ったんですけど、今後のフロントエンドの話っていうと、そんなところのツールができたので、今日はそれについてちょっとお話していきたいって感じですね。
今後どういう技術が来るかわかんないし、何を対応しなきゃいけないってあるんですけど。
あと、みずつさんが書かれたこの記事っていうのは、確か2018年の10月とか、結構前の記事なんですけど、
前の記事でこのことを書かれて、これを約2年後の今になって読んでも、やっぱりそうですね、正しいなって思うところがいっぱいあるので、
そもそもみずつさんの先継の命があるっていうのももちろんあるんですけど。
というところで、やっぱりだんだんちょっとフロントエンドの技術の進化変化っていうのも、ちょっと落ち着きつつあるのかなっていうふうに思ったりはしてきていますね。
まあでもゆうてJSのフレームワークとして、去年、一昨年でしたっけ?ちょっと覚えてないですけど、一昨年かな、スベルトJSが誕生して、これが爆発的にNPMダウンロード数も伸びてすごく人気になったんですけど、
これを触っておくのも別に悪くはないのかなと思っていますが、個人的にスベルトを使うぐらいの現場だったら、
リアクトでもVueでもいいので、素のリアクトVueとかで簡単にアプリを作るぐらいのほうでもいいのかなと思ったりします。
もちろんスベルトJSを一回触ってみて、機能いっぱい便利なのもありましたし、テンプレートの書き方、これちょっと面白いなっていうのもいくつかあったんですけどね。
ただそれほどフレームワークとしての特徴強みっていうのがあんまり感じなかった。
まあ確かに軽量っていうのはあったんですけど、それだったら別にリアクトのちっちゃいPリアクトですかっけ?っていうのがあるので、それを使うのでいいのかなというふうに思ったりはしていますね。
というところで、フロントエンドの今後の技術がどうなるかわかんないですけど、ちょっと落ち着いてきたのかなというふうにも思っていて、
なので今流行っている3大フレームワーク、Vueとアングラー、海外のことを技術キャッチアップしたり、情報収集するといいのかなというふうに思っています。
21:03
それほど大きくは本当に変化しないかなと、よっぽど破壊的変更ない限りだと思いますけど。
今後フロントエンドやるとしたら、あともう弊社で最近話題になっているのは、やっぱりアクセシビリティですね。
ずっとあったんですけど、アクセシビリティ、あとワイヤリアってやつですね。
この辺はしっかり勉強しておくのはやっぱり今後ありかなというか、海外だとしっかり各ウェブサイトとかで、
うちの会社とか、うちの企業、このサイトではアクセシビリティしっかり対応してますよっていうふうに、
マークをちゃんとウェブサイトの中に表示するっていうのを厳守している会社さんもいっぱいあって、
アクセシビリティは今後はやっぱりもう無視できないなという範囲の一つであると思うんで、そこをしっかり追っていくのはいいのかなと思っています。
あとはやっぱりパフォーマンスですね。パフォーマンスのやり方、技術とか。
古来からずっと続いている技術もやっぱりあるんですし、それは別に悪いことでなく、有用なものはいっぱいあるんですけど、
現代のパフォーマンス改善のための技術とかもあると思うんで、それもやっぱり追いつつ、どれを使うかっていうのは選択しなきゃいけないんですけど、
あとはこうするとお金とビジネスの端になってくるんで、との要素をお話になるんですけど、できる範囲でやっぱり技術者としてベストなものはしっかりみんなで議論しつつ、
そこはやっぱり技術者の世界を担保していかなければいけないなというふうに思っておりますので、
フロントエンドとはいえ、バックエンド、どの技術もあんま分野も変わらないかもしれないですけど、しっかり情報のキャッチアップをしつつ、
かつ、検算も怠らずやっていきたいなというふうに思っております。 ところで今日のお話は以上ですかね。
今日は完全に専門的なお話になってしまって、一般的な話ではないと思うんですけど、また何か思いついたり話してみたいなってことがあったらお話したいと思いますし、
聞いてみたいことがございましたら、レターなりご質問等を送っていただきますと、もうすぐ嬉しいので応募しております。
はい、というわけで以上となります。 ではまた次回の放送でお会いしましょう。
バイバイ。
