フロントエンドの進化がマジで速すぎる件！もう勘弁して！
引用元：https://news.ycombinator.com/item?id=43422162
最近FEコードのビルドシステムをyarnからpnpmに乗り換える作業をしてるんだけど、普段はバックエンドエンジニアなんだよね。FEにちょっと手を出しただけで、マジで全部deprecatedになってるのが一番イライラするわ。2022年にapollo CLI使ってた？はい、deprecatedー。graphql-clientとかいう別の設定が必要で、同じオプション全部サポートしてないやつを学んでね！みたいな。古い方使ってpnpmのnode engineチェックをdisableにすればいいじゃんって話だけどさ。dependencyのpatch upgradeしたい？type signatureに頼ってたらご愁傷様！それもpin止めして、誰かがsignatureをアップデートしてくれるのを祈るしかない。何とか動くようになっても、インストール中にdeprecation warningが大量に出てくるのを見てるだけで気が滅入る。FE開発って、breaking changeとかdeprecationとかを積極的に受け入れすぎじゃない？Rustのプロジェクトを4年くらいやってるけど、サードパーティライブラリでminorなbreaking changeが数回あったくらいで、アプリケーションを大幅に変更する必要があったmajorなbreaking changeは1回だけだったよ。JSだと半年も経たないうちに何かを書き直さなきゃいけないってマジありえないわ。
＞FE開発全体がbreaking changeとかdeprecationを積極的に受け入れてるみたいだよね。
これってFEのインフルエンサーがめちゃくちゃ影響してると思うんだよね。FE界隈はSNSとかYouTube、Twitchとかを他の分野より積極的に活用してる気がする。インフルエンサーは常に新しいネタを提供してないと存在意義がないから、常に新しいものを追い求めるんだよね。カンファレンスも活発だし。FEとかJSのカンファレンスって、何かホットな新しいトピックを発表する競争みたいになってるし。FEの講座を売るのも大きな市場だしね。講座のクリエイターは、受講者に700ドルの動画講座を買ってもらわないといけないから、業界を古いものから新しいものへと移行させようと必死になるんだよ。
それめっちゃ面白いね。Web開発のインフルエンサーがそんなにデカい存在だって知らなかったわ。調べてみたら、マジで何百万人もフォロワーがいる人がいるんだね。個人的には、動画でコーディングを学ぶのはマジ無理。テキスト媒体じゃん。じっくり見て、考えて、コードを比較して、参照を辿って、関数を調べる時間が欲しいんだよね。動画形式が好きな人がいるのは別に驚かないけど、未だに理解できないんだよな。動画コンテンツで育って、それでコーディング始めたとしても、どこかのタイミングでテキストのドキュメントを参照する必要があるじゃん？そうなったら、テキストにこだわると思うんだけど、動画の方が面白いってことなのかな。
＞動画形式が好きな人がいるのは別に驚かないけど、未だに理解できない。
だよねー。でも、理由についてちょっと考えがあるんだよね。
あなたは本を読むのが早い？
私は平均よりは早いと思うよ。私がコーディングのトピックを動画で学ぶのが嫌いな理由の一つは、私の読むスピードに比べてマジで遅すぎるからなんだよね。playback speedを上げまくらないと理解できないし。検索性も悪いし、コードをコピーペーストできないし。アメリカでは読解力の低下が問題になってるらしいじゃん。読書スキルが低い人が増えてるから、動画で学ぶ効率がテキストと大差ないんじゃないかな。それに、読書スキルが低い人ほど読書嫌いな傾向があると思うから、動画は嫌なことを避けるための手段なのかもね。根拠はないけど、他の説明よりは納得できるかな。
いや、通勤中とか、運転中とか、掃除中とか、ワークアウト中にaudioを聞けるじゃん。私は高いレベルのこととか、トピックの概要を掴むためにaudioが好きだよ。詳細を調べる時はtextを使うけどね。
＞動画形式が好きな人がいるのは別に驚かない。
そういう“人”って、なりきり学生かプログラマーになりたいキッズでしょ。10年のキャリアの中で、Fireshipの動画で学んでるって言う人に会ったことないわ。
私はYouTubeのMCUの講義でデータベースの内部構造について学んだよ。マジで良かった。
例えばこれ。
https://remix.run/
こういう詐欺師が製品の講座を売ってるんだよ。未メンテのRemixアプリが会社にあったら、それは詐欺師が若手devを騙したってこと。
彼らはそれを宣伝しまくるんだ。
https://kentcdodds.com/blog/a-review-of-my-time-at-remix
https://kentcdodds.com/blog/why-i-love-remix
https://kentcdodds.com/courses
マジ詐欺。でも、ほとんどの人は良い人だから騙されちゃうんだよね。そして、こういうインフルエンサーが出てくる。彼らはcrypto詐欺と同じように顧客のDiscordを持ってる。
Edit: インフルエンサーについての議論で、有名な詐欺師を批判するのをdownvoteする理由がわからない。どのインフルエンサー？その話題が怖い？JS ecosystemの現状は偶然じゃない。
HNでもこういうのに騙されて、フロントエンドの問題についてblog postを書く人がいる。
https://news.ycombinator.com/item?id=39453767
(このスレッド全体が意図的なtestimonialのように見える。)
こういうの買うのやめよう。
Remixはマジで使いやすいと思うけどね。Web standardsを活用してるし(この記事がもっとやるべきだって主張してること)、講座を買わなくても無料で学べるし。講座を売ること自体は別に悪いことじゃないと思うけど、講座を売るために作られたわけじゃないよ。
でも、フロントエンドは変化が早すぎるし、frameworkが毎週のようにリリースされるってのは同意。
いや、Web standards使ってないでしょ。他のframeworkと同じように独自のmental modelとかgotchaがあるじゃん。
RemixはサーバーサイドレンダリングとSPAをいい感じにつなぐし、ほとんどWeb標準でできてるからマジですごいんだよね。クライアントサイドJSがなくてもRemixアプリは動くし。完璧じゃないけど、メリットはたくさんあるよ。フロントエンドの苦労はマジであるけど、「Webは1999年が最高だったんだから変えるな！」みたいな意見はつまんないし、怠慢だと思う。問題解決のために協力して、流行を追うのも、改善の余地がないフリをするのもやめようぜ。
＞mostly with web standards
マジでこれな。React Router v6をレガシーなフレームワークとかアプリに統合するときに苦労するんだよね。全部React Router v6にするなら最高だと思うけど。うちの会社じゃRemixとGraphQL Federationに移行してて、めっちゃ大変なんだわ。ExtJSからJQuery、JQueryからReactのクラスコンポーネントとか、色々終わってない移行がいっぱいあってさ。マジで６個くらいのフロントエンド技術を同時に知ってないといけないのが苦痛。しかも、変な自作のコードがいっぱいあるし。
Kent C. Doddsの教材の質は知らないけど、Remixとの関係は短かったみたいだよ。彼が売ってるコースはRemix（オープンソースプロジェクトとか会社）とは関係ないみたいだし。ちなみに、RemixはReact Routerの開発者が作ったオープンソースプロジェクトで、React Routerをもっと便利にするためのものなんだって。React Routerはめっちゃ使われてるJavaScriptライブラリだし、オンラインコースで稼ごうとする詐欺師が作ったものとは全然違うよ。
RemixがShopifyに売られた時、Kent C. Doddsもお金もらってんのかな？もしそうなら、Remixを宣伝するときにそれを言わないのはちょっと怪しいよね。いい人だけど、そこは気になるんだよな。
6000件以上のコミットがあって、10時間前にも更新されてるリポジトリを「ただの詐欺」って言うのはフェアじゃないと思うな。
それが関係あるとは思えないな。詐欺っていうのは、何も提供せずに価値を搾取することだろ。Remixとそれに関連するコースを作った時間で、Reactのコースを作った方がずっと儲かるはずだ。Remixが間違ってる、とか、ダメなフレームワークだ、っていうのは詐欺とは違うと思う。DenoはNodeと同じ作者で、有料プロダクトがあるから詐欺なのか？俺はそう思わないけど。Remixが詐欺目的で作られたって意見には反対だな。Kentほどの人がお金を稼ぐ方法はいくらでもあるのに。
昔は、”インフルエンサー”って言ったら、コピープロテクトを解除したり、ローディング画面にイントロを追加したり、ハードウェアじゃ無理だと思われてたアニメーションを作ったりできる人が、匿名グループのハンドルネームで活動してたんだよな。口コミはテープとかフロッピーで、BBSとかで広まってたし。今は、他人のやったことにコメントしたり、単機能のパッケージを作るだけ。
確かに、今のテックインフルエンサーになるハードルはめちゃくちゃ低いけど、今まで以上に難しくなってるよね。運ゲー要素が強くなってるってことかも。最近のテックインフルエンサーは、頭もいいし資格もあるけど、特定の分野の専門家ってわけでもないし、革新的でもない。アルゴリズムに選ばれた人たちって感じ。
＞運ゲー要素が強くなってるってことかも
いや、運じゃないよ。カリスマ性だよ。パフォーマンス能力とか、場合によっては道化を演じるスキルとか。人に好かれる才能があるんだよ。学べるけど、プログラミングみたいに一生ものだよ。プログラミングと同じで、生まれつき得意な人もいるけどね。俺は即興演劇と道化の訓練を6年もしてるから、PrimagenとかJoe Roganが何やってるか詳しく説明できるけど、真似できない。前よりは上手くなったけど、彼らのレベルには全然及ばない。
最近になってdevインフルエンサーの動画を見るようになったんだけど（結構楽しい！）、PrimeagenとTheoくらいしか知らないんだよね。おすすめの人がいたら教えてほしいな。どんな人に注目して、何を無視すべきか、自分なりのモデルを作りたいんだ。
Primeはほとんどアンチインフルエンサーだよ。依存関係を増やさないことを推奨することが多いし。AIブームをからかいながら、最新リリースをちゃんとレビューして、コードを学ぶべきだって言ってる。ここで議論されてるようなインフルエンサーとは全然違うと思う。 一番ヤバいのは、それがJS/HTMLの上に構築されてるってことだよね。JS/HTMLって、実はすごく安定した技術なのに。15年前に書いた5KLOCのvanilla JSのWebアプリが、一行も変更せずに10人くらいに毎日使われてるんだぜ。Win32アプリよりも長持ちしてる！フロントエンドの変更は、ほとんどが政治的・組織的な問題だと思う。 数年前に同じことやったけど、マジで面白かったよ。毎週のように変わるReactの依存関係から解放されただけじゃなくて、パフォーマンスも大幅に向上したし（何倍も速くなった）、コードの行数も減ったし、フレームワークのせいで発生した問題を回避する必要がなくなったから、コードもシンプルになったんだよね。Webプラットフォームを長年学んできたから、ライブラリに頼らずに組み込み機能を使えたから簡単だったんだけど、若い開発者はReactしか知らないから、IE6時代の考え方から抜け出せないんだよね。だから生産性は上がるんだけど、依存関係が増えまくって、乗り換えるコストが高くなっちゃうんだ。 ＞若い開発者はReactしか知らないから、IE6時代の考え方から抜け出せないんだよね 安定してるから、古いReactとかKnockoutのアプリは、一行も変えなくてもエンドユーザーは問題なく使えるんだよね。不安定なのは、ツール周りとか依存関係の方。BroccoliとBowerを使ってるプロジェクトに戻るのは悪夢だよ。しかも、それってほんの数年前の話。パッケージのバージョンとHomebrewの依存関係の組み合わせを特定しないといけないんだ。 ＞JSの世界では、半年も経たないうちに何かを書き直さないといけない気がする。マジありえない。 わかるー。気をつければ避けられるけど、JavaScriptの問題って気がするな。少なくとも他の言語よりは。変化を受け入れる文化って感じ。マイナーなライブラリから主要なフレームワークまで、RustとかC++、Pythonよりも破壊的な変更がJSの方が多くない？Emacs Lispはアップグレードしても変更しなくていいし、サードパーティのライブラリも滅多にdeprecatedにならないし、丁寧だよね。JSのコードベースを数ヶ月放置すると、今のツールでビルドできなくなったり、セキュリティの脆弱性を修正するためのアップグレードがマジで大変なことになる可能性あるし。 JSのUIエコシステムは、AndroidとかiOSみたいなUIエコシステムと比較するべきだよ。UIのない環境じゃなくてさ。ReactとSwiftUIを比べるとかさ。SwiftUIは常に変化してて、破壊的で、まだベータ版みたいな状態が10年続いてるのに、特定のAppleのハードウェアとソフトウェアでしか動かないし。大抵UIKit/Cocoaでもアプリの一部を作る羽目になるし。Reactの方が安定してるって。HTML/JSしか触ったことない人は、恵まれてることに気づいてないんだよ。UI技術の普遍的な難しさをJS特有の問題だと思い込んで、他の環境の方が良いと思い込んでるんだ。 ＞JSのUIエコシステムはAndroidやiOSと比べるべき 一方で、React + たくさんのライブラリを使えば、複雑なグラフィックス関連のアプリを数日で書けるんだよね。Win32 APIで同じことをするのに、2005年は数ヶ月かかったよ。Reactによる開発速度はマジでヤバい。 フロントエンド開発とかNPM固有の問題じゃないと思うけど、JavaScriptのエコシステム、特にReact周りの文化的な問題だと思う。2015年頃に、みんながコードを学ぶように勧められて、特にJavaScriptとReactを教えるコーディングブートキャンプを通して学んだのが原因かな。同時に、オープンソースへの熱意と、Githubをソフトウェアエンジニアとしての最初の仕事を得るための、より良いLinkedinのようなものとして使うのが流行ったんだよね。 最悪なのは文化的な側面だよね。このdeprecatedと破壊的な変更地獄は、何百万ものミクロな選択の結果なんだ。「MultiselectDropdownをMultiSelectButtonDropdownにリネームしよう！コンポーネントのAPIも完全に新しいものに変えちゃおう！クールじゃん！」みたいな。互換性を破壊することのコストを理解する文化がないんだよね。Goは後方互換性の約束があるから、Goのライブラリ開発者の互換性に対する姿勢に影響を与えていると思う。10年前に書いたコードが最新のGoバージョンで完璧にコンパイルされて動くのは素晴らしい体験だよ。 JSの文化的な問題は、どの組織もJSを必要としているってことが原因だと思う。その結果、ジュニア/ミッドレベルの開発者が大量にいるし、自然とハイプサイクルが起こりやすいんだよね。もうほとんどの組織はJSスキルで人を雇うべきじゃないんじゃないかな。バックエンドエンジニアを雇って、プログレッシブエンハンスメントされたUIを書くように訓練した方がいいんじゃないかな。 主にフロントエンドエンジニアで、Pythonもやってるけど、マジで同じ気持ち。Pythonはdeprecatedとアップグレード不可能なライブラリと依存関係の寄せ集めだよ。フロントエンドの方がマシだよー。少なくともフロントエンドは、TypeScriptと制限された言語のおかげで被害の範囲が限られてるし。Pythonはマジで何でもできるから、ライブラリ作者も何でもやるんだよ。モジュールのインポート方法を変えたい？どうぞ！メタクラスを作ってクラスの前提を全部ぶっ壊したい？楽しんで！静的型付けが役に立つと思う？無理ゲー。Partial＜T＞みたいなことすらできないし、2つのオブジェクトが同じ型であることを静的にアサートできないし。 だからEmber.jsが大好きなんだよね。残念ながら、人気は落ちちゃったけど（Reactより100万行のレンダリングが遅いとか、ロード時間が長いとかの理由で）、安定したエコシステムを構築したんだよね！他のフロントエンドライブラリでは、こんなにも安定性と安全なアップグレードに力を入れているのを見たことがないよ。 え、今はpnpmを使うべきなの？yarnはどうなったの？npmの何が悪いの？半年くらい目を離したら、インストーラまで変わってるじゃん。npxって何？ エンジニアなら、コアなWeb技術を理解してれば市場価値を高く保てるってことだね。 Webの基礎技術を深く理解してることはめっちゃ重要で、特に大企業じゃ高く評価されるよ。フレームワークなんて engineers からしたら minor detail だからね。すぐに使いこなせるし。だから、深い知識があれば高い市場価値を得られると思う。 「コア」ってのは「ライブラリなし」って解釈してるよ。ブラウザとHTMLファイルだけで何ができるかってこと。 MutationObserverの例を見たんだけどさ。 ＞How can such changes occur to the DOM that aren’t brought about by other code on the page? And if other code on the page brought them about, why didn’t it also perform whatever the MutationObserver is doing?” ユーザー操作でHTMLがDOMに追加されたとするじゃん？その要素にイベントリスナーを付けたい場合、MutationObserverが要素の追加を検知して、リスナーを付けたり外したりできる。初期化コードは一回書けばOK。 ＞How can such changes occur to the DOM that aren’t brought about by other code on the page?” UIパターンがあって、要素のスタイルや操作を定義したいとする。ビジネスロジックにそれをさせたくないから、特定の要素を検出するデコレーターを使うと楽になる。（アーキテクチャの経験からの理論的な例だよ） DOM、events、CSS、WCAG。TypeScriptならtypeとinterface。NodeならNodeのドキュメントにあるライブラリシステム。それだけだよ。 DOMとかeventsとかCSS、WCAGか。TypeScriptやりたいならtypeとかinterfaceキーワード見ればいいし、NodeならNodeのドキュメントのライブラリシステム見ればOK。マジこれだけ。 30年この業界にいるけど、FEで最高の仕事もいくつかやったし、Reactのプロジェクトやったの去年が初めてなんだよね。俺が変なのかな？React知らなくても困ったことないんだよね。「table stakes」って言い過ぎじゃね？ そりゃ「30年の経験」ってのは、履歴書に書いてあるスキルよりも有利に働くことが多いだろうけどさ。ジュニアとかミドルレベルの開発者が自分の能力を示す方法とは違うと思うんだよね。特に応募者がめっちゃ多い時は、パターンマッチングが普通になっちゃってるし。 俺が今まで働いたところ全部、基本的なCSの知識とかweb標準よりも、フレームワークの専門知識を重視するのを嫌がってたな。そんなに珍しいことじゃないと思うけど。Reactのスキルがあるって言うのは悪いことじゃないけど、それを履歴書全体にしちゃう人もいるよね。 反論：15年の経験（C++が10年、Angular/Vueが5年）がある同僚が2年も職がないんだよね。Reactの経験がないから。地元の企業は誰も雇ってくれないし（EUの中規模のテックハブ都市）。近いうちに引っ越さないといけないかも。 FEの仲間には、APIデザインとかUnix tooling、ネットワーク、テストとか、他のたくさんのことを学んでほしいな。同じことを何度もフレームワークを学び直すんじゃなくて。 ＞事実として、”市場価値”を最大化したいなら、Reactがめっちゃ得意じゃないといけない。 俺もFEで10年以上、開発経験は20年以上だけど、あなたに同意するよ。 面接で、特定のフレームワークの経験があるか聞かれたって話を直接聞いたことがあるよ。その人はFEの経験もあって、似たようなフレームワークを使ったことがあったのに、結局、その特定のフレームワークの経験がないって理由で落とされたらしい。 わかるー。そういうフレームワークって独自のパラダイムとか抽象化を追加してくるから、Webのコアな標準を気にしなくても良くなっちゃうんだよね。でもそれって機会損失でもあると思ってて。標準も進化してるのに、多くのWeb開発者は2015年で止まってて、AngularとかReact、Bootstrapとか使ってるし。CSSだってoklchカラーとか変数とかレイヤーとか色々あるのにね。会社とかデザイナーも、フレームワークに縛られて、今できることを活かせてないんじゃないかな。React Nativeとかもそう。OSとかツールを理解せずに使っちゃうから、widgetとかlive activitiesみたいな機能が作れないんだよね。最高のアプリ体験を提供したいなら、専用のアプリ開発者とデザイナーが必要だよ。 いっそのこと、フレームワークを使わないのはどう？HTML5とCSSとVanilla JSで十分できることたくさんあるよ。最初から「フレームワークを選ぼう」ってなるのは間違いだと思うな。大規模なSPAなら別だけど。確かに、フレームワークを使えば無料で手に入るものを自分で書く必要はあるけど、長い目で見ればアップグレードの苦労がない分、むしろ楽だよ。 UIなんてなくても、ASCIIで数字の表を表示するだけで価値を最大化してきた人たちはたくさんいるよ。Perplexityみたいな検索サービスがAPIを食い荒らすようになるだろうし、UIなんて誰も気にしなくなるって。みんな自分のためにデータを見たいんだよ。UIが革新されたのは90年代のreactive-functional-spreadsheetsが最後かな。HTML/ブラウザも一時期はそうだったけど、すぐにsoc．net．brosに悪用されて、結局クローズドなアプリがオープンなインフラの上で動くようになっただけ。 ＞どんなフレームワークを選んでも5年後には廃れるよ。 ＞Angularが廃れるかもって話、それは正しいけど、見落としてる点もあると思う。Angular1と2は全く別物だったし。Angular自体も大きく変わってる。standalone componentsとか、新しいtemplate syntaxとか、signalsとか。Reactもそう。functional componentsとhooksが出てきて、パラダイムシフトが起きた。SSRが流行ったと思ったら、SPAになって、またSSRに戻ったりね。 Angular 2がAngular 1と全然違うってのは同意。Angularは安定してなかったし。Reactは初期のリリースを0．xとしてたけど、Angularはv4くらいまで不安定だったと思う。functional componentsは昔からあったけど、hooksはちょっと後から来た感じ。互換性があるのが大事だよね。class componentsも使い続けられるし。 Angularの新しいバージョンってサポートがすぐ終わっちゃうから、うちのTLMトラッカーじゃリリース初日からもうリスク扱いだよ！ それ、マジで問題だよね。LTSバージョンってことなのに12ヶ月しかサポートないとか短すぎ。 今のReactって10年前のReactと全然違うじゃん。別のフレームワークって言ってもいいくらい。だから、そういう面もあるよね。 今のReactはhooksとか使うのが主流だけど、昔ながらのクラスベースのコンポーネントもまだ使えるし、新しいのと混ぜて使えるから徐々に移行できるんだよね。deprecationもいくつかあったけど、自動でコード移行するツールもあるし。 10年間React毎日使ってて、EmberとかAngularとかバックエンドのフレームワークも色々使ってきたけど、それには同意できないな。hooksくらいしか意味のある変更なかったと思うし、それだって理解するのに1日、使いこなせるようになるのに1週間くらいだったよ。Reactの基本的な使い方は最初から変わってないし。SQLとReactは一番長く使ってるツールだよ。 同じようなこと言ったら、ほとんどのフレームワークも同じだし、JSのパッケージのアップデートも同じだよね。小さな非互換性が積み重なって、結局は作業が発生するってこと。 React Hooksが出てから8年経つけど、Reactのコードはここ8年でそんなに変わってないよ。Reduxを使わなくなったくらいかな。 Reactだけ見てればそうかもしれないけど、みんなそうやって使ってるわけじゃないじゃん。8年前はcreate-react-appが出たばっかりでNext.js v2はwebpack 3だったんだよ。create-react-appはもう古いし、Nextも全然違うし。hooksは2019年にリリースされたし。 ライブラリとかフレームワークが変更されて、プロジェクトのメンテナンスが必要になるのは仕方ないと思うよ。Qtでそうなっても怒らないし。Qtの方が頻度が少ないって言うかもしれないけど、QtはReactよりずっと古いし。Reactが10年前はまだstableだと思われてなかったし。 Reactの世界では、水面下で大きなことが起きてると思うな。新しいコンパイラとか、RNの新しいアーキテクチャとか。ほとんどのユーザーは知らないけど、すごいエンジニアが何年もかけて取り組んでる巨大なプロジェクトだよ。 Reactを10年くらいやってるんだけど、Svelte 5を数日前から触り始めたんだよね。マジでシンプルで使いやすい！簡単な在庫管理アプリを作ってみたら、bundle sizeが9kb(gzip)でビビった。他のフレームワークより全然小さいし、htmxよりも小さいってどういうことなの。 Svelte 5はマジで革新的だと思う。ただのフレームワークって感じがしないんだよね。生のHTML、CSS、JSでフロントエンドを作る延長線上で、最終的に困ることを解決してくれるような、そんな自然な感じ。 確かにね。「時代遅れ」ってのは言い過ぎかも。古いフレームワークでも、人がいて、雇えるなら、しばらく使えるし。せいぜい「古い」とか「レガシー」って感じかな。誰もいなくなったら時代遅れだけどね。 使えるけど、そのうち色々壊れてくるんだよね。依存関係は古くてCVEだらけだし（対応しないといけない契約になってるかも）。開発ツールの拡張機能はもうメンテされてないし、Sentryもサポートやめちゃうし。 偶然だけど、Tailwind v3からv4に移行したばかりなんだよね。Tailwindはあんまり好きじゃないんだけど。移行ツールが全部やってくれたよ。実行したら、v3じゃなくてv4でビルドできて動いた。 Reactだけじゃなくて、同僚がインストールしたよくわからないパッケージも問題なんだよね。 そうそう！マジでやめてほしい！数年しかメンテされないような適当なパッケージを入れるのは、メンテ的にもbundle size的にも最悪。自分でやるのは面倒だけど、そこまで大変じゃないし。 10年前に始めたReactと同じバージョン使ってる？そもそも10年前のReact使える？10年前のプロジェクトを今ビルドできる？ 前の職場では、2013年頃のClojureScriptのコードベースで、ReactベースのUIだったんだ。ClojureScriptとReactの大きなアップグレードを10年間乗り越えて、git blameで2013年〜2014年のコードがたくさん残ってたよ。 話を変えてるじゃん！メンテが全く必要ないなんて言ってないよ。5年ごとに全てが崩壊するわけじゃないって言ってるだけ。もっとコメントを表示（1）
IE6の最終リリース：2008年
IE6をみんなに使わせないようにするキャンペーン：2009年
Microsoftがそのキャンペーンに参加：2011年
Reactの最初のリリース：2013年
いや、そんなことないよ。自制心を持って、プロジェクトに取り込むものをちゃんと吟味すればいいんだよ。vanilla JS/jQueryの時代は、”依存関係の管理”って言ったら、.jsファイルをvendor/ディレクトリにコピペするだけだった。それがnodejs/npmが出てきて、モジュールを自分でプログラムせずにダウンロードしろって言われるようになった。でも、その時点で、数千行の隠れたコードを抱えるよりも、自分でコードを書いて、ボランティアにアウトソースすることに疑問を持つ人も多かったんだよね。プロジェクトをちゃんと管理すれば、目に見えない部分を肥大化させずに済むよ。そのためには、自制心を持って、「このライブラリのこの関数だけが必要だから、ライブラリ全体に依存するんじゃなくて、関数をコピペしてテストを追加しよう」って考えに戻る必要がある。だから、これは人とプロセスの問題であって、JavaScriptの問題じゃないんだよね。JS開発者の中には、この問題に悩まされてない人もたくさんいるし。
＞HTML/JSしか触ったことない人は恵まれてることに気づいてない
Delphi/Free Pascalは20年前のコードがちょっと修正すれば今でもコンパイルできるし、Qtは30年以上開発・メンテされてて、今6th major releaseだし、Win32とかMFC、WinForms、WPFもあるのにね。マジJSエコシステムがあってよかったー。それなしでどうやって生きてきたのか想像もできないわ。
その結果、多くの人が’is-odd’のようなくだらないパッケージを作って使ったんだよね。コーディングは簡単だけど危険がいっぱいだから、真剣に取り組むなら使うべきだ、みたいな。
JS/Web地獄から抜け出すためにFlutterに乗り換えたんだ。ほとんどのWebスタックの複雑さを忘れられたけど、”パッケージを壊してもOK”みたいな文化がDartエコシステムにも忍び寄ってきててマジ勘弁。
ライブラリが変わることに文句言ってるけど、Python 2 -> 3の移行はマジでヤバくて、前にいた会社は100M行のPythonモノリスを3にアップグレードする予定はなかったよ。SqlAlchemy 1 -> 2は8段階の移行が必要で、全部書き直さないといけないし。Reactがhooksを追加しただけで文句言うとかマジ？
フロントエンドのトレッドミルについての記事はたくさんあるのに、逆のことは誰も文句言わないのなんで？
フロントエンド20年やってきて、色んな変化を見てきたから言えるけど、コア技術を知ってる方がエンジニアとして成長できるのは間違いない。でも、それが就職に有利かっていうと、ちょっぴり疑問。採用担当者はパターン認識しがちだからね。
結局、市場価値を上げるにはReactを使いこなせないと厳しい。それが基本で、他の知識はReactができてからって感じかな。著者の意図を誤解してたらごめんね。
ただ、君の言うこともわかる。特にコンサルとか契約の仕事だとね。採用担当者の隣で見てると、使いたい技術を知らない人は即落とされる。テクニカルアーキテクトでも同じだよ。スキルがあっても、技術を ramp up するのが嫌なんだって。
だから、常に最新技術を追いかけないと、履歴書はゴミ箱行きだよ。
MDNを調べてみるといいかも。
dialogって知ってる？
＞https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di…
MutationObserverは？
＞https://developer.mozilla.org/en-US/docs/Web/API/MutationObs…
URLは？
＞https://developer.mozilla.org/en-US/docs/Web/API/URL_API
＞if (mutation.type === ”childList”) {
＞ console.log(”A child node has been added or removed.”);
＞}
DOMの変更って、ページのコード以外で起こることある？もしコードが変更したなら、MutationObserverの処理も一緒にやるんじゃない？
フロントエンド開発は未経験なんだけど、管理ページを作る必要があって。便利で、時代遅れにならない軽量なフレームワークってないかな？もっとコメントを表示（2）
君の言うとおり、それでもいいんだけど、MutationObserverは複雑さを減らすために使えるよ。「divの中身が変わったら、これをする」って感じで、変化の可能性を全部考えなくてもいいんだ。
フレームワークはどれも便利だって言うけどね…！
便利そうなのは：
・Polyfills：標準APIを使って、ブラウザ間の互換性を保つ。
・Web components：JSモジュールをHTMLタグみたいに使えるようにするもの。Litが良いらしい。
・Vite：HTMLとかJSをまとめてくれる。高速で信頼性も高い。色んなフレームワークで使われてる。
・別のチームとか第三者が書いたコードかもしれない
・ブラウザ拡張とか bookmarklet が MutationObserver を設定してるかもしれない
ビルドツールは必要ない。自分で作れるし。
build toolsなんて言ってないし。自分でサクッと作れるし、フレームワークのくだらないこと全部いらない。マジでそれって不安な人が使うか、遅くなるだけだぜ。
ある意味そうだけど、フルスタックエンジニアは”市場価値”のトップには遠く及ばない。フロントエンドの給料には上限がある。ある程度進むと、もうUIを作る必要はなくなる。
ほとんどの企業は、大企業でも、基本的なことを気にしないし、それについて質問もしないし、そういう人を雇わない。「Reactが得意」とか「Next.jsの経験が豊富」とかで判断する。基礎はスクラッチで構築するならいいけど、企業はほとんどそんなことしない。既にあるエコシステムが大きくてドキュメントが充実しているものを使う。それらが得意になれば雇われやすい。基礎は後から学べる。
だから、基礎も大事だと思うけど、雇われ続けたいなら、それがベストな方法じゃないってのもわかる。
フロントエンドエンジニアじゃないんだけど、Reactを10年くらい使ってるよ。Svelteに移行する動きもあるけど、SvelteがReactを超える頃には、それくらい時間が経ってると思う。Angularもそのうち廃れるかもしれないけど、Reactより前からあるし。フロントエンドの進化は早いけど、そこまで酷くないよ。地味な選択をすれば、地味な結果になるってこと。もっとコメントを表示（3）
依存関係を少なくして、地味な選択をすれば、10年放置しても最新の依存関係でビルドできないかもしれないけど、全部書き直す必要は絶対ないはず。基礎を学ぶのは良いことだし、依存関係を減らすべきだけど、フレームワークは5年でなくなるから使わない方が良いって言うのは言い過ぎだと思う。
新しいバージョンとか別のフレームワークに移行したいけど、色々変わってて大変。結局、フロントエンドを書き換えるだけの無駄な時間を過ごすことになるんだ。終わったと思ったらTailwind 4が出たりして。
どうしてもサードパーティのパッケージを使うなら、ちゃんとサポートされてるか、長年活動してる開発者とか組織がバックにいるか、ライブラリ自体が成熟してるか、くらいは確認してほしい。
ClojureScriptは後方互換性を重視してるから、あまり変わらなかったんだと思う。Reactのコードも、ビジネス要件を満たしてて「動いてた」から、2013年から2022年まで全然変わってなかったり。
もうそこでは働いてないけど、初期のフロントエンドを今ビルドできない理由はないと思う。最近はTypeScriptでフロントエンド書いてて、React、TypeScript、色んなライブラリのアップグレードを乗り越えてるよ。
ただ、ライブラリのリリース速度は、他のエコシステム(Clojure, Java, Rustとか)に比べてマジで早い。
フロントエンド以外でも、10年前のプロジェクトはかなりヤバい状態になってると思う。C/C++のプロジェクトでも、コンパイラの改良でコンパイルできなくなることだってあるし。
2015年のReactプログラムなら、今のReactで動くようにするのはそんなに難しくないと思う。Reactの一番大きな変化は、createClassからECMAScript 2015 classesへの移行だった。ReactはECMAScript 2015 classesが登場する前にリリースされたけど、すぐに採用された。だから、10年前のプロジェクトはECMAScript 2015 classesを使ってるはず。もし違ったら、機械的に移行できる。他にも互換性がなくなる可能性はあるけど、全部ドキュメントされてるし、アプリを全部書き換える必要はないよ。
10年前のプロジェクトを、10年前のReactでビルドできるかって？できるよ。古いNode.jsが必要になるだろうけど、npmにはまだ古いパッケージが全部あるし。
