1. kkeethのエンジニア雑談チャンネル
  2. No.321 「今のwebフロントエン..
2023-12-23 17:08

No.321 「今のwebフロントエンドで学ぶこと」

はい❗第321回は,現代の Web フロントエンドで開発する際に学ぶツールや環境についてお話しました💁


自分もフロントエンドの領域で数年エンジニアとしてお仕事してきましたが,今はもっと複雑度が増しており,エコシステムの変化も凄まじく,楽しい半面大変すぎるわ!という気持ちですw

今はもう若い子に教えていただいてばかりですが,自分としてもしっかり楽しんでいきたいと思いますー♪


ではでは(=゚ω゚)ノ


ーーーーー

♪BGM

騒音のない世界「さんさんドライブ」

https://soundcloud.com/baron1_3/sunsun

See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.

00:10
はい、みなさんこんにちは。kkeethこと桑原です。
本日もやっていきましょう、kkeethのエンジニア雑談チャンネルです。
この番組では、web業界に関することや、エンジニアリング、いろんな技術についての雑談などの情報を発信していきたいと思います。
で、今日はですけども、まあ何の記事読もうかっていうか、何の勉強しようかなとか、何の話しようかなと悩んだんですけど、
せっかくこうアドベントカレンダーがいろんなところで飛び交ってて、まあ僕もいくつか読ませていただいて、
まあ学びになりそうだなというか、棚卸しをしようかなと思ったのが、今のフロントエンドで学ぶことというところのタイトルを付けていただきました。
フロントエンドというか、webフロントエンドですね。
正式にフロントエンドっていうと、普通にwebじゃなくても、ネイティブアプリでも、クライアントアプリなんでもかんでも、
フロントエンドと言えちゃうフロントエンドですよね。
あの、講義の意味でのフロントエンドという話になると思うので、
まあ明確に言うと、webフロントエンドで学ぶことというところを棚卸ししていこうかなと思います。
そもそもフロントエンドっていうか、クライアントサイドって、技術剪定とかいろんなものがあるんですけど、
言語的には正直一つないし二つぐらいしかないわけですよね。
例えば、今僕がやっているwebフロントエンドというと、
まあJavaScriptもしくはTypeScriptを学ぶというか、これで書くことがほぼ前提。
逆に言うとこれ以外の言語ってあんまなくて、
まあ実は世の中にあるかもしれないですけど、僕は知らないし、あんまそんな主流で書くことでもないし、
まあ最終的にはブラウザーが処理するものなので、
ブラウザーが理解できるっていうのがHTMLとCSSとJavaScriptしかないというので、
そのロジカルなところを担当するのは基本JavaScriptです。
なのでまあ学ぶ言語としてはJavaScriptを一個か、
まあそれの拡張言語であるTypeScriptを学ぶぐらいしかないんですよね。
まあiOS、AndroidだとしてもJavaもしくはKotlinとか、
まあセーフトですよね。
オブジェクティブCもやる可能性ゼロじゃないですけど、とかをやりますけど、
まあそれぐらいものしかないと。
まああと、コトリマルチプラットフォーム?でしたっけ?
KMM?KMPだっけ?
あ、ちょっと名前忘れました。
とかもあったりはしますけど、
だいたい置いといて基本的には言語と言われるものは1つないし2つぐらいです。
絞られている。
サーバーサイドとかバックエンドの人たちは大量の言語があるんですよね。
PHPもあれば、Rubyもあれば、Pythonもあれば、
ラストもあれば、Node.jsもあればということで、
たくさんの言語があったりするので、
そもそもサーバーサイドの人たちは言語レベルから大変選定しなきゃいけないところがあるんですけど、
フロントエンドとかクライアント側は基本的には選択肢がかなり少ないので、
他のところですね、それ以外のところで学ぶこととかやらなきゃいけないことがたくさんあるねっていう話は別であります。
で、特にウェブフロントエンドはその幅がかなり広く、
表現力も高いし、どんどんどんどんブラウザーも進化をしてしまっているので、
やれることが増えたせいで、
学ぶこともかなり増えたなっていうのは正直ありますけど、
まあさておき、その辺を今日はざーっとトナレーションをしていこうかなと思っています。
ウェブフロントエンドの学ぶことですね。
まあとりあえず、
現代のフロントエンドのエンジニアでやること、
まあさっき言った通り、学ぶこととしては言語でまず、
03:00
JavaScriptとTypeScript、もしくはHTML、CSSみたいなところですね。
HTMLはまあいいとして、CSSもだいぶ進化してきて、
あれですね、昔できなかったことがどんどんできるようになりました。
昔はそのオールドCSSとか、いわゆる拡張CSS言語ですね、
みたいなのもあるし、
CSSに対するUIフレームワークと言われるものですよね。
まあ最近だとTailwindがすごくホットなものになってますけど、
まあそんなようなものもたくさん生まれたりするので、
まあ一概にCSSだけを学ぶって結構大変ですし、
CSSでやりたいことをなかなかできないっていうのは、
今なりこう悩み続けてるわけで、
なんかGridもできたし、
Flexboxみたいな便利なものもあったりするんですけど、
それでもやりたいことができなくて、
うーんってなったりすることがしょっちゅうあるので、
CSSは意外と難しい。
まあさっき言ったとき、その辺は学ぶとして、
まあそれ以外のところで学ぶとしたらまずは、
まあパッケージマネージャーから学ぶのは多分そうだろうなと思いました。
NPMとかYARNとか、
最近だとPNPMがすごく流行ってますよね。
まあとにかく早いし、
パッケージをちゃんとキャッシュしてくれるってところが本当に強くて、
PNPMを使ってる現場もかなり増えてきてる印象がありますし、
いろんなところでPNPMも使われてるなってのがありました。
逆にYARNを使ってるところってのが、
まあリポジトリ見たら使われてるんですけど、
まあ今新しくやるってなったときに、
YARNを使うっていう選択肢をされる方
あんまりいないなと思いましたね。
みなさんはやっぱりPNPMに移っていくのか、
まあそもそもNPM自体も結構進化したってのがあります。
あとはまあVANを使ってる方もいらっしゃいますよね。
僕まだ全然VAN触ってないので、
いい加減触らなきゃいけないと思ってはいますし、
頼もろししなきゃいけないんですけどね。
なんかとにかく早いらしいです、VANは。
まあ単純にVANが盛り上がってって正直あって、
僕ノードジェスでやったことがあるので、
まあノードジェスとかVANとかその辺、
バックエンド周りのJavaScriptってなんだかんだ興味関心はあるので、
DENOは触らないかもしれないですね。
DENO、名前は好きですし、
ノードを逆転したみたいな感じですけど。
なんかわからないけど、
結局今年も一年DENO一回も触れなかったんですよ。
ていうのでDENOも多分触らないかもしれないですね。
ていうのでまあとりあえずフロントエンドの人が
真っ先にやるのは多分エコシステムにどうやって依存するとか、
どう頼るかっていうんですね。
にアクセスできるためのパッケージマネージャーを最初に、
まあ勉強じゃないですけど、
普通に使っていくことになると思うので、
あとは、
ランタイムの話か、
ランタイムノードJSでDENO版って、
さっきも出した名前が三つ連なるんですけど、
ランタイムも、
基本ノードJSでいいんじゃないですか?
パッケージマネージャーの方は。
DENOは言った通りですけど、
ウェブ標準互換でいけるっていうのは確かに強いらしいですけど、
やっぱりエコシステム周りは自前というか、
自分たちで自由に選びたいというので、
それと環境を、
ちょっと僕は切り分けたいなって正直あるので、
ノードJSか版で、
このままいきたいなと思いますけど、
基礎からやるんだったらノードJS一択なんじゃないでしょうかね。
最初から版とかDENOでやるのは、
どうなんですかね。
僕触ってないからなんとも言えないですけど、
ハードル高いというか、
大変なんじゃないかなっていう気はしてます。
06:00
まあそんな勘で喋るのは置いといて。
で、続いて学ぶとしたら、
言語もやりました。
DOMもやりました。
CSSというスタイリングもやりました。
装飾もやりましたと。
その辺の周辺のエコシステムとかライブラリもやりました。
で、なると、
次あるのはやっぱりフレームワークですよね。
結局ここに尽きると思いますけど。
まあ今現代だと何学ぶかって、
多分リアクト一択なんじゃないですか。
とりあえずスタートでやるんだったらリアクトで、
いわゆるJSXでアプリケーションを作っていくっていうところに
慣れていくのがいいと思います。
で、なぜJSXかって言ってると、
現代のフレームワーク、
たくさん他にもあります。
Vueもありますし、
Angularと言われるものもあります。
で、PREACT、
プリアクトというものかちょっと分からないですけど。
あるし、あとスベルト、ソリッド、
クイック、なんたらかんたらって、
あとアストロ?
なんたらっていっぱい出てきますね。
まあアストロ結構最近話題というか、
僕の周りでは名前どんどん聞くようになりましたね。
でもまあ僕は大体使ってないですし、
あれですけど。
っていうのもあったりするんですけど、
まあそれらのフレームワークがほぼほぼ大体、
裏でというか中ではJSXをやっぱり使っていって、
JSXを書くことになると。
まあVueとかはJSXを書かないんですけど、
まあ最終的にコンパイルとか、
トランスパイルする時に、
一回JSXに変換をしているんですよ。
内部的には。
というのでJSXに結局依存をするよねって話ではある。
で、それのまあ根源じゃないですけど、
スタートがリアクトだったんですよね。
これも結局メタ社、
まあ当時のFacebook社が作ったはずです。
JSXも。
リアクトもそうですけど。
これの流れにどのフレームワークも
最近乗っかっているんであれば、
まあそのままJSXで行くんだろうなと思ったりするので、
まあこれに慣れておくのは全然いいかなと思ったりしてます。
で、あとはまあまあ、
インストールする、ダウンロードするとか、
歴史の話をしても、
まあリアクトがこの中では一番長いんですよね。
アンギュラーも長いっちゃ長いんですけど、
このアンギュラーって言っているのは、
アンギュラーJSではないですね。
前のアンギュラーフレームワークではないので、
歴史的にはまだ浅いというところで、
まあリアクトが一番長いですよね。
また強いて、
まあ突っ込んで学ぶというか、
突っ込んで使うんであれば、
リアクト、ビュー、アンギュラー、アップリアクトと、
まあスベルト、ソリッド、クイックというのは分けた方がいいかもですね。
いわゆる仮想ドムを使うか使わないかみたいな話です。
仮想ドムは何ぞやみたいな話はありますけど、
まあ要はアプリケーションをJSで作っていくときに、
ツリー構造ですね、
ドムのツリー構造とか機構造とかを内部的に持っておいて、
擬似的にドムっぽいもの、
まあ単純にJSON形式みたいな形なんですよ、
中身を見ると。
そういうものを内部的に持っておいて、
ドムのどこが変更になりましたという差分の検知をするわけですね。
その差分のところだけJSで計算して書き換えてしまえば良いと。
ちょっとページ全体をもう一回レンダリングしなくて良くなるよねっていう、
その仮想ドムみたいなものが中身的にあります。
これはこれで一つ早くなる一方で、
実はオーバーヘッドがでかくなったりするみたいな話もあったりするし、
結局計算処理し直すとしても、
その中身が結構でかいコンポーネントとかドムだったりすると、
割とコスト高いわけですよね。
パフォーマンスもちょっと影響出たりするし、
あとハイドレーション問題も結構あって、
ハイドレーションも書き換えですね。
ドムが書き換えられる度に何度も何度もやり直すと、
結構時間かかって、
どこまでキャッシュ化をするかみたいなのが結構難しかったりするんですよね。
その辺も柔軟にかつコントローラブルに設定ができるっていう意味でも、
09:02
やっぱりリアクトがこの中で一律の長があるなと思うので、
とにかく困ったらリアクト入れとけば、
そうはないと思いますし、
いろんなものが学べると思います。
今のモダンな開発ってこんな感じなんだっていうのは、
大体もうメタ社のリアクトが生み出してると思って良いと思います。
ので、リアクトから入ればいいんじゃないのかなと思いますね。
エコシステムとかサードパーティーのライブラリーもものすごく充実してますからね。
ほぼほぼ。
数字的に言うとリアクト一況です。
それのラッパーフレームワークですね。
いわゆるSSRとかSSGとか、
いろんなものをラップして、
吉谷にかつアプリケーションを作るという意味では便利にしたものとして、
レンダリングフレームワークがあるんですけど、
ラッパーとしては、
NEXT、NUXT、あとGatsby、Remix、
さっき出ましたね、ASTRO。
ASTROは確かにラッパーフレームワークとしているのか。
まあいいと思います。
あとスベルトキットですね。
先ほど言ったリアクトのラッパーがNEXTJSみたいなやつですね。
みたいな感じのラッパーフレームワークの名前だとあげました。
NUXTはもちろんVueJSのラッパーですね。
Gatsbyはラッパーっちゃラッパーなんですけど、
これも一応リアクトのラッパーと思っていただいていいと思います。
最近使わなくなりましたね、Gatsbyもね。
静的エイサイトジェネレーティング、
SSGに使うフレームワークですね、Gatsbyは。
中身はGraphQLを使っています。
これに完全に依存するので、
この辺は結構モダンで面白かったんですけど、
あんま最近Gatsbyはやっぱり効かなくなりましたね。
それも含めて個人ブログとかを作る人も結構いらっしゃったと思いますけど、
NEXTでいいんじゃないのっていう話が今の流れなんじゃないかなって気はしてます。
あとは、リミックスアストロも、
去年、一昨年くらいから名前が結構聞いたし、
ステイトオブジェイスでも結構ドーンと上に来た気はします。
リミックスは本当にノータッチで全然触ってないんですけど、
アストロは軽く見たりはしましたね。
さっき言ったリアクトとかビューとか、
ソリッドも使えるのかわかんないけどとかの、
それぞれのフレームワークで作ったコンポーネントって、
やっぱりそれぞれのAPIとかインターフェースの書き方をするじゃないですか。
その書き方のコンポーネントをガチャンと持ってきて、
使えるようにしますよってしてるのがアストロです。
アストロの中にはリアクトが動いたりビューが動いたりするみたいな話で、
なんかすごいカオスな状況じゃないって気はしますけど、
そういうことがでもできるっていうのがアストロですね。
リアクトスベルトキットは名前の通りスベルトのラッパーフレームワークです。
こちらも数字だけで言ったらもちろんNXJSが一強です。
なんだっけ、2億ダウンロードいったんだっけ?みたいな話ですね。
年間で。
ほんと一強っちゃ一強です。
それの二大巨頭だったNXTも今全然数字的にはNXTにはるか負けていますので、
やっぱりリアクトNXTがフロントエンドのフレームワーク戦争で勝利したって感じですね。
伸び率で言うとやっぱりスベルトキットと、
あとソリッドも数字的には少ないんですけど伸び率は本当に強くて、
去年から5倍に伸びたんですよね。
なのでソリッドのラッパーフレームワーク、ソリッドスターとかみたいなものもあって、
その辺が今後どう来るかですね。
今年のステートオブJS2023の結果は結構僕は楽しみにしてますね。
あとはビルドツール、バンドルツールみたいなものですね。
そしてウェブパックが、
ウェブパックはもう歴史的にずっと僕らフロントエンドのほぼバンドルツールといえば
12:04
デファクトでしょうみたいな覇権を取っていたと思いますが、
最近はもうウェブパックじゃなくなりましたね。
脱却することがかなり増えたと思うし、
僕もウェブパックあんまり最近触らなくなりましたね。
今はビートが一番流行ってるんじゃないでしょうかね。
僕もずっとビート使ってますね。
というかやっぱり速いって正義ですし、
そんな設定周りを複雑にウェブパックみたいにやらなくてよくなったっていうのはすごく強くて、
ウェブパック何が辛いかって、
毎回毎回メジャーバージョンアップするためにあんま買い互換しなかったりしたり、
落とし穴がいっぱいあったりするっていうのは結構あるんですよね。
完全に互換がないわけじゃないですもちろん。
それはそうだと思うんですけど、
でもなんだかんだ毎回毎回のペインがあったので、
もう疲れちゃったなっていうのは正直あると思います。
あとはESビルドもそうですね、話題です。
これも速いからっていっぱいありますけど、
ちょっと中身まで見てないですけど、
中身まで見てるいろんなブログ書かれてる方もいらっしゃるので、
その説明はそちらにお任せします。
ESビルドもいいんじゃないかと思いますけど、
僕はビートでいいんじゃないですかね。
あとはロールアップもなかなか、
もう名前あんま聞かなくなりましたけど、
ライブラリーを作られている方とかだと、
ロールアップ使うのいいんじゃないのとかですね。
NEXTを使っている方はターボパックとかもいいと思います。
あとSWCをビルドツールにするのは、
僕あんまどうなんですかね。
SWCを使っている人もいらっしゃると思いますけど、
なんか違う気がしてます。
あとパーセルとスノーパックですね。
パーセルはパーセルバンドラーが正式名称だと思います。
スノーパックとかパーセルとかあるんですけど、
この辺は興味あれば触ってみればぐれの感覚です。
僕はなんかもう今はビートでいいんじゃないのって気がしますね。
NEXT.jsのターボパックはどうなんですかね。
僕もこれまだ触ってないんですけど、
ちょこちょこ名前は聞きますけど、
一旦僕は置いていきます。
まあやっぱデファクトじゃないですけど、
いろんな人たちが使っているビートを使うのでいいんじゃないですかね。
あとテストフレームワーク、
あと多分出てくると思いますけど、
でもビートがいいなと思ったりしてますね。
ついでにやっぱりテストフレームワーク喋ると、
テストフレームワークは、
現代とやっぱりもうジェストがほぼ一挙なんじゃないでしょうかね。
僕も新しくテストを書くってなったら、
もうジェストを入れます。即入れます。
昔みたいにMOCAとかチャイとか、
えーとなんだっけ、
JASMINEとかいっぱいあったんですよ、
テストフレームワークって。
あるんですけど、
あと言いついテストフレームワークなのか、
単なるユニットテストなのかってところがいっぱいあるんですけど、
ユニットレベルだともうほぼジェストで一挙なんじゃないでしょうかね。
あと食ってかかるというか、
ダークホースというとさっき出ましたビートですね。
ビートの互換のあるBテストというフレームワークがやっぱり強いなと本当に思ってます。
ビートのスピード感でそのままテストを実行できるというのも強いと思いますし、
書きやすさというところもあると思うので。
あと言いついとして、
サイプレスとかプレイライトとか、
パペッタ?パペティアって読むんでしょうね。
これ確かパペッタって読み方じゃないんですよね。
パペティアが確か正しい読み方だった気がしますけど、
その辺を使うとかですね。
あとテストフレームワークと言ったら、
テストランナーの話もね、ちょっとしたい感はありますね。
昔で言うとカルマとかあったんですけど、
僕カルマすっげー好きだったんですけどね。
全然使わなくなりましたね。
テスティングフレームワークとテストランナーという2つのセットで書いてた時代も昔はあったんですけど、
まあ今はとりあえず書くんだったらジェストかなと。
15:00
それもリアクトを書くんだったらほぼジェスト一択なんじゃないですかね。
と思ったりしてます。
別に僕はジャスミンとか使ってもいいと思います。
あとはノードジェストのテスティングフレームワークって言ったら、
エイバーってものもありましたね。
もうメンテナンスしなくなった気がするんで、
まあやらなくてもいいと思います。
あとはテスティングライブラリーって言われるものですね。
特にリアクトテスティングライブラリーとかあったりすると思います。
リアクト用のやつですけど、テスティングライブラリーありますね。
他の各種フレームワーク用にも対応したものも出てるはずですけど。
まあそんな感じでその辺をやるといいと思います。
あとビジュアルリグレッションテストという名目で多分ストーリーブックがここに上がってる気はしてますけど。
コンポーネントタイムでのビジュアルリグレッションテストですね。
なかなかフロントエンドのビジュアルリグレッションテストのフレームワークってそうそう多くなく、
まあそんなにやられてる方もいたかわかんないですけど、
やっぱりある意味越したことはないし便利だなというところで。
あとレグスーツってものも実は昔あったんですよね。
昔って言っても今も全然あるし、多分メンテナンスしてる気はしますけど。
フロントの人がやるとちょっとハードル高そうな印象も正直あって、
やっぱり簡単だし使い慣れているストーリーブックでそのままテストかけられるのは強いよねと思ってますので。
そんなところですかねテストフレームワーク。
まあとりあえずやるんだったらジェストから入ればいいと思います。
ビートを使っている環境であればビートテストから入るのも一つ分かりやすいと思いますけど、
テストの勉強するんだったらジェストで一回やるのがいいんじゃないでしょうかね。
あとMockどこでやるかとかMockサーバーがみたいな話はあったりしますけど、
まあ今はMSWでいいんじゃないですかね。
Mockサーバー、MSWほぼ一択だと思ったりしてます。
僕の会社の開発環境とかザーッといろんなプロジェクト見てますけど、
大体MSW使ってる案件がやっぱ多いなと思いますね。
E2Eもタイプレスじゃなくて完全プレイライトの方が今増えたなって印象がすごく強いですね。
あとアンギラ使ってる環境、現場であれば、
アンギラ用のE2Eフレームワークがあるんですけど、ちょっと名前忘れました。
があるんで、アンギラ使ってる人たちはちょっと特殊かもしれないですね。
これ明日も届けたいと思います。
すいませんけどここでガツンと切っちゃいます。ごめんなさい。
じゃあこのところで今日は終わっていきたいと思います。
明日も同じようにフロットエンドの技術の話やっていきたいと思います。
じゃあ今日も頑張っていきましょう。
ありがとうございました。バイバイ。
17:08

コメント

スクロール