React涙目？ Reactボタンより軽いNue爆誕！爆速Web開発の新星現る
引用元：https://news.ycombinator.com/item?id=43543241
Reactに頼りすぎてる人が多い気がするなー。問題は巨大なフレームワークがWebを遅くしてることじゃん？DevOpsとして、ロード10秒以下のサービスを見つけるのがマジ無理。10G回線で5ms以内のホストなのに、ホームページとかが10秒以上かかるのはJSのせい。速いブラウザエンジンと諦めモードの人だけが支えてる状態だよね。Nueが革命を起こすとは思わないけど、応援はするよ。
Webの肥大化はReactみたいなフレームワークのせいじゃないよ。Reactのプロジェクトをpnpm create vite -t react-tsで作ると、圧縮後60KBくらい。Vueならもっと小さくて25KBくらい。React/Vueで200-300KBのプロジェクトも普通に作れるし、2G回線でも使えるよ。ホームぺージが10秒かかるのは作り方の問題。jQuery時代より酷いこともできるし。記事の比較も変。ReactのViewはボタンよりちょっと大きいだけ。
作者です。Reactのベースラインは確かにモンスターじゃないね。Vite/Reactで60KB、Vueなら25KBくらい。中規模プロジェクトで200-300KBは全然あり。でもね、React/ShadCNのボタン1個がNueのSPAデモより重いんだよ。タブとか足したら差は広がる一方。Nueはそこを覆す。Web標準で小さく始められて、そのまま小さく維持できる。コードも小さく、HMRも速い、ビルドも早い。効率が良いってこと。
100-200KBの追加は、ほとんどのユーザーにとって100ms程度のコスト。95%のユーザーでも1秒くらい。それなら開発効率を優先するよ。バンドルをやめるとか、ラウンドトリップをなくすとかは良いと思うけど、100KB追加するくらいなら大したことない。
＞100-200KBの圧縮ファイルは、ほとんどのユーザーにとって～
それって光回線？ケーブル？5G？4G？最初のボタン？それとも各ボタン？日付をオブジェクトで管理したくなったら？dayjsを使う？自分で書く？他にどんなライブラリが必要？ビルド時間は？リンターは？Next.jsのアップデートは？セキュリティアラートは？Reactのコードベースを管理するのは大変なんだよ。AgenciesはReactを使うだろうね。90%はすぐ終わるし。インフラのことは気にしないから。小さなクライアントはハマって、チームは止まる。
＞React’s baseline isn’t a monster.
そんなことない。問題はサイズじゃなくてロジック。コンポーネントが再レンダリングされるたびに、ルートループが実行される。useEffectもuseStateも全部再実行される。HTMLだけをレンダリングしたいのに。最適化はできるけど、根本的な問題だよね。
このベンチマークは誤解を招くね。ShadCNボタンのソースコードと、クライアントがダウンロードするボタンのサイズは違うんじゃない？特にSSRを使ってる場合は。
デモを見ると、ペイロードはほぼReactとtailwindcssのクラスから来てる。ShadCNボタン1個のペイロードって言うのは嘘。React/tailwindcssの固定コストじゃん。でも、デモ自体は小さいから、誇張がちょっと残念。クライアント開発で重要なのは状態管理。ReactではMobXを使ってる。Nueが使いやすいかどうかは、インタラクティブ性がどれだけ良いかにかかってる。
＞It’s dishonest to call this the payload of ”one shadcn button” since it’s basically all react/tailwindcss fixed cost and not literally a shadcn button.
ShadCNのボタンはそのコストなしで動くの？
ChatGPTっぽい。
ダウンロードと実行は違うってことだね。60kbの圧縮されたJavaScriptをダウンロードするのは問題じゃなくて、問題はそのJavaScriptを実行すること、それから発生する大量のweb呼び出し、そしてボタンを丸くしたりするためだっけ？にかかる計算量だよ。ロード時間はもう良い体験の指標じゃないんだよね。今はページがレイアウトされて操作できるようになるまでの時間が大事だよね。あと、スマホ熱くない？
60kbの圧縮されたJavaScriptをダウンロードする方が実行するよりも時間かかるよね。
最近のReactサイトが重すぎるのは嫌だし、メインのフレームワークだったけど、クライアントが指定しない限り使わなくなったんだ。
＞問題は、これらの巨大なフレームワークがwebをひどく遅いものにしてしまったことだ。”
これって違うと思うな。webが重いのは、最適化とかをしない怠慢な開発者とか、収益を絞り出そうとする大量のトラッキングスクリプトのせいだと思うよ。Reactサイトも開発者がちゃんとすれば速いし、Reactのせいじゃないことが多い。この記事ではボタンが78Kって言ってるけど、React全部読み込んでるからでしょ。ボタンが何百個もあるページなら毎回78K読み込まないし。
＞最適化とかをしない怠慢な開発者とか…
＞(これはReactのせいかもね)
それもあるよね。でもReactが最適化を必要にしてるってことを忘れちゃだめだよ。ネットワークもマシンもめっちゃ速いじゃん。30年前にはPostscriptファイルのオンラインアダプテーションしてたんだよ。フォームの入力でPostscriptをレンダリングし直すの。ほぼ一瞬だったよ。
低スペックのAndroid端末もあるんだよ。アメリカとかヨーロッパとかアジア以外にもネットワークはあるし。Google map見てみなよ。世界はオフィスだけじゃないんだから。
そんな低スペックのAndroid端末ってどういうスペックにするの？
Alex Russelがこの件について色々書いてるし、スマホ市場の状況に基づいて毎年アップデートしてるよ。分析に基づいて中央値、P75、P95のデバイスを選んで、それに基づいてターゲットを設定できる。
https://infrequently.org/2024/01/performance-inequality-gap-
俺は一番安いスマホを買ったよ。Alcatel 1ってやつ。めっちゃ低スペック。ちょっとやりすぎかもしれないけど、それで動けば他でも動く。
うーん…クールな記事だけど、俺が探してるものとはちょっと違うな。まあいいや、彼が言及してるスマホの構成を見てみよう。
”A51は遅いコアが8つ(4x2.3 GHz Cortex-A73と4x1.7 GHz Cortex-A53)搭載”
Wikipediaを見ると、少なくとも4GBのRAMと4Gインターネットも搭載してる。
Alcatel 1も少なくとも1 GHzのCPUと少なくとも1GBのRAMを搭載してるみたいだ。
PowerMac G3でwebベースのPostscriptレンダリングをやってたんだ。シングルコア32ビットプロセッサ、266 MHz、192MBのRAM。回線は初期のDSL、下り768KB、上り128KBだったと思う。
特に最適化しなくても速かったよ。
だから、今のコンピュータ、特に低スペックのスマホや時計は信じられないほどパワフルで速いって言いたいんだ。ネットワークもね。もし君の技術スタックが基本的なUIレンダリングでそのハードウェアを苦しめて、まともに動かすために最適化が必要なら、根本的に間違ってるよ。
＞最適化とかをしない怠慢な開発者とか…
＞…
＞収益を絞り出そうとする大量のトラッキングスクリプト
間近で見てると、開発者がa)に時間を使えないのは、b)みたいなことに時間を費やさなきゃいけないからってのが真実に近いと思うな。より良い体験を作りたいと思ってない開発者なんて会ったことないよ。でも、自分のコントロールできない理由でそれができない開発者にはたくさん会ったよ。
“開発者が気にすれば”って言うのは、完全に責任転嫁だよね。
どっちもだよ。今のweb開発者の大半はクソだよ、はっきり言って。web開発で金儲けできると思って、エンジニアリングを芸術とか科学として見てないんだ。ただなんとかやり過ごして、仕事以外ではレベルアップしようとしないんだよ。
前に、開発者が自由に開発できたのに、メンテできない巨大なゴミアプリを作ったから、書き直したことがあるよ。
あと、Reactは悪夢。APIは変わり続けるし、新しいパラダイムに移行してない開発者を非難する文化があるし。大人向けのフレームワークなら、mithrilをチェックしてみて。小さくてAPIも安定してて直感的だし、邪魔にならない。
それって、まとまりのあるビジョンが60%くらいあるって感じかな。まあ、ざっくりだけどね。0ってことはないと思うな。 こういうのよくあるよね。 Balsamiqみたいなアプリの売りって、完成したページじゃなくて、スケッチっぽいものを見せられるってことじゃないの？ 最初から作るならそうかもね。でも、成熟したアプリをメンテする時は違うよ。アプリとBalsamiqを同期させる時間も気力もお金もないもん。 ＞どのサイトにもある、収益をできるだけ絞り出そうとする300個のトラッキングスクリプト どっちも正しいと思うな。 なんでReactがもっと大きくて遅くなる必要があるの？成熟したプロジェクトで、プロの開発チームがいるんだから、無駄なものを削ってくれるって信じてるよ。そこにあるものは全部、何かの役に立ってるはず。セキュリティとか、安定性とか、互換性とか、拡張性とか、何かを犠牲にする覚悟がないなら、そういうこと言うべきじゃない。 ReactとPreactを比べてみて。 言いたいことはわかるけど、ちょっと大げさじゃない？うちの会社では、20個以上のウィジェットがあるSPAのダッシュボードがあって、全部リクエストして、2MB以上のJSを転送してるけど、2秒でロードされるよ。キャッシュは全部オフにしてるよ。フレームワークとかの問題じゃないんじゃない？ 今度は、5年前のスマホで3G回線でパケットロスがある状態で試してみてよ。オフィスみたいな恵まれた環境じゃなくてさ。 90年代育ちだから変に思われるかもだけど、ウィジェット付きのダッシュボードを表示するのに2MBのJSって、どうも納得いかないんだよね。 それってJSだけの話じゃないんだよね。JSONとかCSSとか画像とか、全部含めたトラフィックの話だよ。それに、チャートもたくさん表示するし、金融系の人はチャートの機能にめっちゃうるさいんだから。全部入りじゃないと相手にされないんだ。 そもそも、フレームワークって本当に必要なの？Pure JSで十分だし、JSなしならもっと良いじゃん。前にSAPのプロジェクトでJavaの層があって、その上にAngularのアプリがあったんだけど、結局SAPにリクエストばっかりしてたんだよね。リッチクライアントの必要性が不明で、PHPの方が良かったかもね。大企業はフレームワークでコーディングを統一して、開発者を替えやすくしてるだけじゃないかな。 ＞フレームワークって本当に必要なの？ 共通のAPIがあるメリットは議論の余地がないって言うけど、それってブラウザのことじゃない？議論すべきは、それよりも高いレベルのAPIが必要かどうかだよ。もし必要なら、それもブラウザのAPIの一部にすべきじゃないかな。 Pure JSがそのインターフェースじゃん…不要な抽象化レイヤーを重ねてるだけだよ。抽象化が多い＝使いやすい、じゃないからね。 その通り。HTML、JS、CSSは関心の分離ができてて最高だよ。あとは、HTMLの繰り返しとか、ヘッダー、フッターをくっつけるテンプレートと、ルーティングがあれば完璧。HMRがあれば開発も捗るし。それがNueの肝だね。 ＞HTML、JS、CSSは関心の分離ができてる ＞HTML、JS、CSSは関心の分離ができてる コメントにも書いたけど、クールなプロジェクトだけど、Reactの批判として提示するのは皮肉だよ。Reactはレンダリング層が必要で、残りは自分で書きたい人が選ぶんだよ。Vue/Astro/Nextを選ぶのは、モノリスなSSGが必要な人で、Nueのニッチだよ。Reactに勝てるレンダリングライブラリを作ったら、自慢してくれ。 Reactの代わりにこれを使うらしいよ。 作者です。NueのViewレイヤーに型がないのは事実で、それは意図的なんだ。ReactのエコシステムはTypeScriptを何にでも使いたがるけど、それはやりすぎ。Nueは逆で、見た目はきれいでセマンティックに、Web標準が頑張って、静的型付け（RustとかGo）はビジネスロジックで活きるって考え。どう思う？ ＞TypeScriptを何にでも使うのはやりすぎ それは言い過ぎだって。TypeScriptが普及する前から、JSで書かれた大規模プロジェクトはたくさんあったし、小規模チームや個人で管理されてたものもある。PythonやPHPでもそう。 いや、できるのは確か。 それってフレームワークの問題じゃなくて、搾取されてるだけじゃない？ ＞Pythonで書かれた大規模プロジェクトはたくさんある なんで低評価されてるのかわからないけど、古くて型がないPythonプロジェクトは悪夢だよ。 短絡的すぎると思うな。一人でアプリを作るなら関係性とか依存関係を覚えてるだろうけど、小さいチーム（4人くらい）でも、しばらく経つと忘れることってあるじゃん。 作者が型がないのが特徴だって言うのは、興味をなくさせるための作戦かな。 マジレスすると、作者はどうかしてないよ。Svelteチームも数ヶ月前にJSDoc付きのJSに切り替えたし[0]。リポジトリのほとんどがJSでTSじゃない[1]。理由としては[2]、＞Svelteコンパイラ開発者として、ビルドステップなしでデバッグできると開発がめっちゃ楽になるんだって。以前はビルドステップありきでデバッグが大変だったんだよね。それに、JSDoc使ってもTSとほぼ同じ型安全性が保てるらしい。 投稿されたリンク[3]から引用すると、＞もしあなたがTypeScriptアンチで、この件で自分の立場が正しいと思ってるなら、残念なお知らせだよ。 TypeScriptはGo、Rust、C#みたいな”本物”の静的型付けじゃないんだよね。型情報はビルドした瞬間に消えちゃうし。 これはマジで問題だよね。もしスタック全体で、成熟した広く採用されてるフレームワークやライブラリがある言語を選べるなら、そうしてたよ。RustとかGo、Java、C#みたいなのがエンドツーエンドで動けば最高だったのに。実際、TypeScriptの弱い安全性でも、たくさんのバグを本番環境に持ち込む前に見つけられるから、価値があるんだよね。14万行以上のTypeScriptコードを本番環境で動かしてるけど、型がないと管理できないよ。 ＞14万行以上のTypeScriptコードを本番環境で動かしてるけど、型がないと管理できない。 ＞本番環境にあるのはJSで、TSは開発環境だけ。 ＞JSにコンパイルされる部分でも、”C++を本番環境で使うことはできない。バイナリだけだ”とは言わないでしょ。 それは違うよ。バイナリにコンパイルする時、C++でも型消去するし、特にoフラグを使うと再構築できないものもあるよ。JSからTSにするのは簡単でしょ。全部に TypeScriptは本物の静的型付けじゃないよね。コンパイルされたtypescriptプロジェクトはただのjavascriptで、間違った型でも受け入れちゃう。型が重要なのはコンパイル時だけ。 これこそが一番リアルな静的型付けだよ。”静的”っていうのはビルド時のことを指すんだ。定義上、静的型は実行時じゃなくてビルド時にチェックされる。もし実行時に型をチェックしたいなら、それは”動的”型付けって言うんだよ。 確かに技術的には正しいけどさー。TSってJSにコンパイルされるじゃん？で、JSは実行時に動的型付けになるんだよね。結局、動的型付けの言語にいるってことじゃん？ Svelteは悪い例だよ。 「美的センスの問題」じゃないよー。 JSDoc付きのJSって、結局Typescriptもどきって感じじゃん？ 作者だけど言うねー。 HTMLもCSSも、もともと型がないわけじゃないよ。 もしそうなったら、多くのウェブ開発者は屋根に登って石を投げるんじゃないかなー。 昔は、閉じタグを書かなきゃいけないってなったら、フロントエンドの開発者たちは泣いてたと思うよ。 ＞Reactのエコシステムでは、開発者がTypeScriptを何にでも貼り付けていますーCSSにさえーそれはやりすぎです 自分の解釈を意味不明にするのは、マジ意味不明。 ＞”ReactでCSSにTypescriptを使う人がいるからTypescriptは使わない”って言ってるんじゃないよ お前の言う「ウェブ標準」ってのは何一つウェブ標準じゃないし、ウェブ標準じゃ「 頼むからChatGPTとか使うのやめてくれ。バレバレだし、信用度が90%下がる。多少変な英語でもいいから、そんな適当な文章読むよりマシ。マジで勘弁。ドキュメントも全部ChatGPTじゃん。マジで生身の人間なの？話してくれよ。 ＞Vuejsユーザーがターゲットかな？ Vue 3からだけど、型はまだReactほど良くないよね。 Vue 3はもう6年も経ってるけど。 残念ながら6年も前の話だから今は違うかも！(結局Reactに乗り換えたし) ＞たしかにかなり近いけど、Reactなら ＞最近のReactユーザーはビューレイヤーでTypescriptの型が使えるのが超便利だからTypescript使ってる人が多いよね。 Nueは良いよね。でもSvelteに投資しちゃったんだよねー。結構大きめのアプリ書いたんだけど、Reactを見直したらさ、意外と悪くないじゃんってなった。もっとコメントを表示（1）
開発者: 「頼まれた画面作ったよー。見てみて、どう思う？レイアウトとか文言とか、何か変えるところある？」
PM: 「いいね！じゃあ、次だけど…」
開発者: 「ちょい待って！テストで入れたコード整理したいし、タイミングによっては副作用のあるループもあるんだよね。」
PM: 「問題ないでしょ。次行こうよ。」
https://balsamiq.com/product/
収益のためのトラッキングが必要で、議論の余地がないとするよ。 なんで「ONE scripts to rule them all」みたいなのがないんだろう？Segmentって会社があった気がするけど、ググってもそれっぽいのが出てこないな。
1. Reactはもっと小さくて速くできるはず。今ならもっといい選択肢があるかも。
2. ウェブサイトは、新米開発者が多いのと、サイズやパフォーマンスに集中する時間がないせいで、必要以上に大きくて遅くなることが多い。Reactが人気ってことは、Reactが小さくて速くても、ウェブサイトは遅いままってこと。
https://preactjs.com/
Preactをよく使うけど、Reactの方が20倍も大きい理由になるような問題は、ほとんどないよ。
必要だよ。何千ものWebアプリで共通のAPIがあるメリットは議論の余地がないでしょ。
全然綺麗じゃないし、関心事がそんなに綺麗に分かれることなんてないよ。
＞アプリの場合
アプリなら、ちゃんとアプリっぽいものが必要で、関心の分離はこんな感じになるべきだよ：https://x.com/simonswiss/status/1664736786671869952
＞
全然綺麗じゃないし、関心事がそんなに綺麗に分かれることなんてないって言うけど、めっちゃ綺麗だよ。UIフレームワークとかドキュメントシステムとか、みんな言ってるじゃん。構造、スタイル、インタラクションの分離だよ。Webアプリはドキュメントモデルに合うことが多いんだから。みんなデスクトップとかゲームのUIパターンを持ち込もうとするからおかしくなるんだよ。もっとコメントを表示（2）
https://nuejs.org/docs/view.html
型がないViewレイヤーで、初期のAngular 2.0みたいな感じ。Modelファイルは普通のJavaScript。
どこにも型がないのは、Vue.jsの層をターゲットにしてるのかもね。マーケティングの方向性を少し変えた方がいいかも。Reactの人はViewレイヤーに型がある方が便利だからTypeScriptを使う人が多いし。
うわー、このフレームワークはまともな規模以上のプロジェクトじゃ絶対うまくいかないね。
TypeScriptでさえ問題があるのに。小さいチームで大規模なアプリを2つもTypeScriptで管理してるからわかる。PRの差分を読むときに型チェックされてると保証されてないと無理。
個人的には型付き言語を選ぶけど、型がないと大規模プロジェクトは絶対に書けないってわけじゃない。
でも、もっとお金がかかると思うよ。
予算内では無理って言っておくべきだったね（インフラからバックエンド、複数のフロントエンドまで全部2人くらいのフルタイムでやってるんだ）。
確かにそうだけど、扱うのがマジで大変なんだよね。
昔、ちょっと大きめのPythonのコードベースを触って、他の言語に移植したくなった。書いたのは数ヶ月前の自分なのに。
https://avi.im/blag/2023/refactoring-python/ で愚痴ってるよ。
LSPを使って名前を変えたり、壊れたものを修正したりできるのも良いよね。シンプルなWebサイトならいいけど、コンポーネントが増えてくると型がないのはマジで痛い。
この時は結構騒ぎになったんだよね。Rich Harris（Svelteチーム）もHNでコメントしてた[3]。開発界隈も「マジかよ」って思ったみたいだけど、Svelteは今んとこ問題なさそうだし、誰も気にしてないんじゃない？作者が型定義ファイルを出してくれれば、TypeScriptライブラリと変わらんと思うよ。
RichとSvelteチームはJSDocと型定義ファイルを使ってTypeScriptを使ってるんだよね。Nueチームはview layerを型付けしないみたいだけど。親コメントの＞ビジネスロジックではRustやGoみたいな本物の静的型付けが活きるってあるけど、typescriptを”本物”の静的型付けだと思ってないんじゃないかな。
function fn(x: string) {}
これは問題なく通っちゃう。
fn(2)
ランタイムではね（だからZodとかValibotみたいなスキーマバリデーターが必要になるんだよね。開発環境の”静的型付け”は張りぼてだから）。＞RichとSvelteチームはTypeScriptを使ってるって言うけど。
正確に言うと、TypeScriptのバインディングを提供してるって感じかな。コードベース（実際に書いてるコード）は間違いなくJS[0]で、TypeScript用の.d.tsバインディングがある[1]。作者も同じようにして、後からTSバインディングを提供できるよ。
SvelteチームはJSDocでそれを実現してるんだよね。GoogleのJSスタイルガイドも同じ理由でJSDocに力を入れてる[0]。ちょっと細かい話だけど、本番環境にあるのはJSで、TSは開発環境だけだよね。
＞Go、Java、C#みたいなのがエンドツーエンドで動けば最高だったのに。
できないわけじゃなくて、選んでないだけ（まあ、もっともな理由があるんだけどね）。C#（Blazorとか）のエンドツーエンドソリューションもあるし、ユースケースによっては全然ありだよ（すべてに最適ってわけじゃないけど）。FableもF#を使った例だね[1]。Bootsharp[2]みたいなライブラリも面白いことしてると思うし、OPのプロジェクトと同じようなエネルギーを感じる（型付けとロジックをランタイムがサポートするランタイムに移行して、JSとのインターフェースを最小限にする）。
それは違うよ。うちはTSを本番環境で使ってるよ。JSにコンパイルされる部分でも、「C++を本番環境で使うことはできない。バイナリだけだ」とは言わないでしょ。プラットフォームの一部としてJSは一切書いてないよ。
＞できないわけじゃなくて、選んでないだけ
コメントで明確にしたと思うけど。
＞成熟した広く採用されてるフレームワークやライブラリがある言語をスタック全体で使いたい
それは言うよ。だってデコンパイルできるし、型情報も残ってるもん。C#も同じ。バイナリをデコンパイルすれば型情報が見える。「C++を本番環境で使ってる」とか「C#を本番環境で使ってる」とは言うけど、「TypeScriptを本番環境で使ってる」とは言わないかな。「TypeScriptでアプリを作ってる」なら正確だけど、それはJavaScriptにトランスパイルされるだけ。Node.jsサーバーがJavaScriptを解釈して、C++を実行するんだよね。: anyって書けばいいんだから。まあ、言葉遊びしてるだけだよね。もっとコメントを表示（3）
あと、普通の静的型付けのコンパイル言語だと、型が保証されないデータとやり取りするのって外部関数インターフェースだけじゃん。でもTypescriptだと、サードパーティのライブラリとのやり取り全部が普通のJS経由だから、型に合ってるかどうかわかんないんだよねー。
あの変更の前後で型チェックはほぼ同じだし。
あれは単に、どっちのシンタックスが好きかっていう美的センスの問題と、ビルドなしでブラウザで直接コードを実行したいっていう思想的なスタンスの問題でしょ。
チームが言ってるように、デバッグとイテレーションのスピードを重視した機能的な選択なんだってば。
型は大事だし、Nueでは本当に必要なところで使うのが良いと思ってる。
HTMLとかCSSみたいに、元々型がないところに型を足すのは、ただの無駄な重さになるだけじゃない？
むしろReactの型付けが足りない。
mossilaのドキュメントを見てよ。https://developer.mozilla.org/en-US/docs/Web/HTML/Element/sp…
例えば＜span/＞はすべての要素を持てるわけじゃない。
もし型システムがこれを捉えられたら最高じゃない？
HTMLをちゃんと理解して、セマンティックに要素を使わなきゃいけなくなるからね。
たぶん、多くのウェブコンポーネントも型チェックに通らなくなって、作り直すか、もっとシンプルな要素を使わざるを得なくなるだろうし。
「Reactを使っている人がCSSにTypescriptを使うからTypescriptを使わない」って、意味不明すぎない？
あんたが勝手にそう解釈したんでしょ。OPは誰かがCSSにTypescript使ってるからTypescript使わないなんて言ってないってば。nam is not defined on object user」みたいな表示は無理。
VueはTSで書かれてて、テンプレートレベルでもファーストクラスのサポートがあるよ。
あと、Reactより型が”まだ良くない”ってどういうこと？ 例を挙げて。
たしかにかなり近いけど、Reactならstring | undefinedって書くだけで済むところを、{ type: String, required: false }みたいに書く必要があった気がする。
もし今Vueを使ってたら、もっと色々問題点が見つかると思う。だってTypescriptを想定して作られた基盤の上に構築されてないからね。例えばこのスレッドを見て：https://www．reddit．com/r/vuejs/comments/l456fl/is_vue_3_real…string | undefinedって書くだけで済むところを、{ type: String, required: false }みたいに書く必要があった気がする。
Vue 3からstring | undefinedって書けるよ。
あと、リンク先のredditのスレッドは4年前のものだよ。
ほとんどの人がTypescriptを使ってるのは、Reactアプリがビジネスロジックと絡み合った20万行のコードに成長して、Typescriptなしでは管理できなくなったからだよ。違う方向に行けば、それほど必要なくなる。
- Hooks理解すればReactってそんな難しくない。
- 意外とReactも軽量。
- Reactはもう枯れた技術で安心。
- エコシステムがマジでかい。React Queryみたいなライブラリがあるのは強い。
だからしばらくReact使うわ。React compilerがFacebookとInstagramで使われてて、公開ベータも出るみたいだし。React Nativeも対応してるしね。SvelteのrunesはReact compilerには勝てないかも。runes使うとJavaScriptっぽくなくなるんだよね。React compilerのおかげでHooks地獄も減るし。
