Vue vs React vs Angular vs Svelte Part.10

1 名前：デフォルトの名無しさん mailto:sage [2022/03/08(火) 22:57:16.85 ID:D77bZcWT0.net] !extend:on:vvvvv:1000:512 Vue https://jp.vuejs.org/ React https://reactjs.org/ Angular https://angular.io/ Svelte https://svelte.dev/ ※前スレ Vue vs React vs Svelte Part.7 https://mevius.5ch.net/test/read.cgi/tech/1610901677/ Vue vs React vs Angular vs Svelte Part.8 https://mevius.5ch.net/test/read.cgi/tech/1621744952/ Vue vs React vs Angular vs Svelte Part.9 https://mevius.5ch.net/test/read.cgi/tech/1642316774/ ★ここではjQuery, Ruby, C#, Blazorの話題は禁止です ★jQuery, Ruby, C#, Blazorｷﾁｶﾞｲが書き込んでも無視してください Next, Nuxt, Sapper, Gatsby, VuePress, RedWoodなどはおｋ。 VIPQ2_EXTDAT: default:vvvvv:1000:512:: EXT was configured 730 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 4f5f-N/YD) [2022/06/30(木) 19:35:58 ID:6sehYChL0.net] >>718 AngularがTypeScriptだから、Google社もマイクロソフト社もTSなら、TSが主流になるのはあたりまえ。 731 名前：デフォルトの名無しさん mailto:sage [2022/06/30(木) 19:50:20.39 ID:QhRPsPx40.net] 多分大きなプログラム組んで保守したこと無いんでしょ 732 名前：デフォルトの名無しさん [2022/06/30(木) 20:02:10.83 ID:9vHoAPAv0.net] TSはサーバーサイドなら主流になる可能性はあるな フロントではならないと思う 733 名前：デフォルトの名無しさん [2022/06/30(木) 20:13:41.28 ID:9vHoAPAv0.net] Next.jsはVercel依存が大きいな Reactも含めて将来怪しい気がする 734 名前：デフォルトの名無しさん mailto:sage [2022/06/30(木) 20:26:32.56 ID:QezReaSar.net] これからはflutter3でしょ 735 名前：デフォルトの名無しさん (ﾌﾞｰｲﾓ MMb3-/H42) mailto:sage [2022/06/30(木) 22:15:09 ID:2XXd+/VdM.net] >>720 何事もそうだけど困ってない人に有用性を説くのは難しいよね 736 名前：デフォルトの名無しさん mailto:sage [2022/06/30(木) 23:16:48.49 ID:Beg43fXd0.net] >>715 一回作って終わりの人かな？ リファクタリングん時どうすんの？あ！しないの人か 737 名前：デフォルトの名無しさん [2022/07/01(金) 00:46:49.64 ID:oYJ8x66X0.net] プログラミング言語のスレッドだと勘違いしているおっさんが続出 738 名前：デフォルトの名無しさん [2022/07/01(金) 09:35:10.76 ID:6aoBhuJf0.net] >>725 リファクタリングでもJSで問題無いだろ どうせソース見るし 739 名前：デフォルトの名無しさん [2022/07/01(金) 17:11:27.34 ID:R7kYgAoSa.net] ネットだとts絶対許さないマンよく見るけど現実だとお目にかからないよね 740 名前：デフォルトの名無しさん mailto:sage [2022/07/01(金) 18:12:27.71 ID:x/bCmdBF0.net] 絶対許さないとまでは言わんけど無駄やんｗ フロントエンドで何でそんなもの使わなきゃいかんのやｗ CoffeeScript何かを有難がってた奴らが使ってそうだしｗ どうせTS何か10年後には終わってるよ 741 名前：デフォルトの名無しさん mailto:sage [2022/07/01(金) 18:59:43.92 ID:5HWkDFYv0.net] CoffeeScriptがあっという間に廃れたのはJS自身が（CoffeeScriptの機能も吸収して）進化したことと、より良いTSが幅を効かせたことが大きい。TSが死ぬとすれば、それを成すのはより進化したJSか、TSの上位互換言語の台頭だ。 つまり進化は地続きで、TSを学んだり使うことは無駄にならない。もっと言えばTS使い的には歓迎すべきことですらある。 まぁでもMSが力入れてるし採用率もかなり高いし、10年そこらでは死ななさそう。 742 名前：デフォルトの名無しさん mailto:sage [2022/07/01(金) 20:13:43.65 ID:KisKsIWOr.net] フロントエンドでは要らないって言ってる人はバックエンドでは使ってるんだろうか 743 名前：デフォルトの名無しさん [2022/07/01(金) 22:19:19.96 ID:R7kYgAoSa.net] tsとか無駄やんとか言える無邪気な開発僕もしたい 744 名前：デフォルトの名無しさん mailto:sage [2022/07/01(金) 22:44:37.27 ID:l4s2091pr.net] MSが提案してるTypes as Commentsはどうなったの 745 名前：デフォルトの名無しさん mailto:sage [2022/07/01(金) 23:28:49.55 ID:jfzkVg37d.net] jsdocとeslintがあれば十分だと個人的には思ってる 746 名前：デフォルトの名無しさん [2022/07/02(土) 00:56:43.37 ID:RDvzx2LC0.net] 圧倒的にJS採用の方が多いだろ TSはこのままずっと低空飛行だよ 747 名前：デフォルトの名無しさん mailto:sage [2022/07/02(土) 05:55:38.97 ID:eKS9e1d80.net] 確かにガッツリjsdoc書いてあればまぁいいかなと思うけど、むしろTSより面倒くさい上に表現力足らなくない？ >>735 古典的な静的ウェブサイトも含めりゃそうだろうけど、スレタイのライブラリ使うようなウェブアプリ界隈では低空飛行とは言えないと思う 748 名前：デフォルトの名無しさん mailto:sage [2022/07/02(土) 06:16:56.34 ID:PDy9af/xr.net] MS自身がTypeScriptを嫌になったんだろうな VSCodeでの解析も完全にはできない トランスパイルが重くなる そもそもTypeScriptは時代に合わなくなってきた 749 名前：デフォルトの名無しさん mailto:sage [2022/07/02(土) 07:44:27.85 ID:MgQFVCuv0.net] >MS自身がTypeScriptを嫌になったんだろうな なんか唐突だけどTypes as Commentsの話？ 750 名前：デフォルトの名無しさん mailto:sage [2022/07/02(土) 13:14:29.58 ID:OVvPs9zga.net] これから脱tsブームとか到来したりしてな 751 名前：デフォルトの名無しさん mailto:sage [2022/07/02(土) 13:36:01.41 ID:eW+YZHQfM.net] 反TSの人ソースもなしに主観的な事しか言わねぇな。しかも対話もできない。 752 名前：デフォルトの名無しさん mailto:sage [2022/07/02(土) 13:43:43.13 ID:QFi+cmDT0.net] TSはクソだから代わりのものが普及したら乗り換える←わかる TSはクソだからJSを使う←ちょっとわかんないですね 753 名前：デフォルトの名無しさん (ｵｯﾍﾟｹ Sr23-nd1h) mailto:sage [2022/07/02(土) 13:55:46 ID:PDy9af/xr.net] >>738 TypeScriptって書いてるのに読めないの？ 754 名前：デフォルトの名無しさん mailto:sage [2022/07/02(土) 14:43:46.64 ID:MgQFVCuv0.net] 「嫌になったんだろうな」って話に脈絡がないからこれがどこから出てきたのかってことだよ。 MSがTSを嫌になったと思わせるような話がなにか出てきたっけ？ 755 名前：デフォルトの名無しさん (ｵｯﾍﾟｹ Sr23-nd1h) mailto:sage [2022/07/02(土) 15:18:50 ID:PDy9af/xr.net] >>743 そっかすまんね TypeScriptに関するVSCodeのアップデートみてると「これ以上解析するの苦しいから助けて」っていうメッセージが頻繁にあったんだよね 最近はしらんけど まあオープンソースだし当たり前なんだが そもそもTypeScriptもVScodeもMSが開発してるのに別の提案をしてきてるってことはTypeScriptがダメって自ら認めているようなもんじゃね？ 756 名前：デフォルトの名無しさん mailto:sage [2022/07/02(土) 15:36:48.98 ID:P5MS37aDM.net] アロー関数とかasyncとかモダンなJavaScriptの構文ってだいたいMS主導の提案だろ？ そもそもTypeScriptはJavaScriptを改善していくためのPoCの役割を担っている言語で、TypeScriptが必要なくなるのはMSにとっても望ましいことなんだよ 757 名前：デフォルトの名無しさん mailto:sage [2022/07/02(土) 15:46:38.12 ID:vAnwNkKL0.net] >>741 それ分からないって頭弱くね？ｗ そもそもjsのライブラリなのにjsで書けないってｗ あ、書けないじゃなくて書かないって言いたいんだろうけど お前みたいなのは書けないと同義なんだよなｗ 758 名前：デフォルトの名無しさん mailto:sage [2022/07/02(土) 15:50:51.08 ID:MgQFVCuv0.net] >>744 なんかぼんやりした話だな。tsserver事態のメンテはvscodeチームとは関係ないだろうし何の話だろう。 仮にそれが事実だとしても嫌になったのはvscodeチームがであってMS自身がってことじゃじゃないよな。 「別の提案」ってのがまた話の脈絡がわからないが、こっちはTypes as Commentsの話？ 759 名前：デフォルトの名無しさん mailto:sage [2022/07/02(土) 16:12:03.29 ID:2I3j8zDtM.net] 支離滅裂な文章でも文末にｗ付けりゃ人を煽れると思ってるんだろうか… 760 名前：デフォルトの名無しさん mailto:sage [2022/07/02(土) 16:49:58.49 ID:eKS9e1d80.net] Types as Comments なんてまさにTSの発展形なわけで、TS学んで有利になりこそすれ、損は無いよなぁ。 TSは言語仕様を見れば必要以上に便利な演算やマクロ化は避けてあるから、ある程度で解析打ち切りってのは異常でもなんでも無いように感じる。 761 名前：デフォルトの名無しさん mailto:sage [2022/07/02(土) 17:01:32.19 ID:2BlFAt+M0.net] >>745 モダンにアロー関数使って変数の値が極力変わらないスクリプト書いてもIEさんが挙動おかしくなってましたね… 762 名前：デフォルトの名無しさん mailto:sage [2022/07/02(土) 17:28:41.92 ID:3dhQ5vPf0.net] 自分もフロントで型を使って何をするか分かってない ビジネスロジックは書いたらだめだよね 763 名前：デフォルトの名無しさん mailto:sage [2022/07/02(土) 17:32:40.41 ID:XBJNDAlwa.net] NaNしたことない者だけが型を捨てなさい 764 名前：デフォルトの名無しさん mailto:sage [2022/07/02(土) 17:43:54.69 ID:MgQFVCuv0.net] >>751 べつにプレゼンテーションロジックでも役に立つんじゃね？ フロントにビジネスロジック置いたらダメなんて法もないし。 765 名前：デフォルトの名無しさん mailto:sage [2022/07/02(土) 18:21:20.76 ID:eKS9e1d80.net] プレゼンテーション層で型エラー出して遷移が発生しなかったり変なデータ表示したらユーザが誤解して結果的に間違った操作するから、どっちも大事だよね。 つかビジネスロジック一切触れなかったら何も操作できないじょん 766 名前：デフォルトの名無しさん mailto:sage [2022/07/02(土) 19:34:36.69 ID:3dhQ5vPf0.net] >>753 ビジネスロジックがフロント側やいろんなところにあるのは悪手だと思うけどな… でもたしかに日本国憲法には書いてないから言い返せないわ 767 名前：デフォルトの名無しさん mailto:sage [2022/07/02(土) 19:47:59.60 ID:npQqWWfDM.net] どこまでがビジネスロジックにあたるか分からんのでなんとも ソシャゲガチャの確率をフロントで捌くことは無いってのは分かるが 768 名前：デフォルトの名無しさん mailto:sage [2022/07/02(土) 21:03:21.42 ID:MgQFVCuv0.net] 悪手ってのは管理的な 769 名前：意味でかねぇ？ 同じロジックのコードが分散したりしなければべつに困らんと思うが。 [] [ここ壊れてます] 770 名前：デフォルトの名無しさん mailto:sage [2022/07/02(土) 21:17:45.97 ID:3dhQ5vPf0.net] >>757 レイヤードアーキテクチャの考えだと、 ビジネスロジックはドメイン層に書きましょうでしょ でも、この話ってそもそも何のシステム作るかで左右されるよな 771 名前：デフォルトの名無しさん mailto:sage [2022/07/02(土) 21:41:40.49 ID:BrGj2XHMM.net] いつの間にかフロントにビジネスロジックを書くかどうかの議論になってるけど ビジネスロジックを書くなら型必要、そうでないなら不要って合意がされたんだろうか そうでないならそこを議論しても意味ない気がするけど 772 名前：デフォルトの名無しさん mailto:sage [2022/07/02(土) 21:46:38.78 ID:MgQFVCuv0.net] >>758 その境界をクライアント-サーバー間に引かなきゃならん理由はないだろ。SPAとかなら特に。 773 名前：デフォルトの名無しさん mailto:sage [2022/07/02(土) 22:33:24.13 ID:QFi+cmDT0.net] フロントだけでアプリ作れるよ系のサービスは存在そのものが悪になるの？ 774 名前：デフォルトの名無しさん mailto:sage [2022/07/03(日) 00:14:35.00 ID:eO2MvCIb0.net] フロントだけでアプリが作れるように見えるFirebase/Firestoreも実はセキュリティルールとかあるし、本気で活用するならFunctionsとの連携が必要とかもあって、フロントだけでもない 775 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 1bac-hFrK) mailto:sage [2022/07/03(日) 00:39:44 ID:95K4DRnu0.net] フロントだけってなんやねん、気もするけどな 776 名前：デフォルトの名無しさん mailto:sage [2022/07/03(日) 02:57:16.56 ID:anFeH3zOr.net] そんなこといったらデスクトップアプリはフロントだけじゃん 単にコンパイルされて中間ソースがあるだけでツールで簡単に逆アセできてしまう そのために高い難読化サービスがあるわけで 777 名前：デフォルトの名無しさん mailto:sage [2022/07/03(日) 08:09:23.22 ID:8+Zm1fQX0.net] >>760 フロントにドメイン層があるの？ サーバーはインフラストラクチャ層だけか >>759 そりゃ必要でしょう ビジネスロジックって足し算引き算だけじゃないよ 778 名前：デフォルトの名無しさん mailto:sage [2022/07/03(日) 08:42:03.81 ID:BunJQVPiM.net] >>765 ちゃんと読んでレスしてくれよ ビジネスロジックを書くとき型は必要か？なんて質問をしたわけじゃない 779 名前：デフォルトの名無しさん [2022/07/03(日) 09:33:34.86 ID:8+Zm1fQX0.net] >>766 ビジネスロジックなしでも型は必要でしょってことね プレゼンテーションロジックでも型が必要なのは納得しました 780 名前：デフォルトの名無しさん mailto:sage [2022/07/03(日) 19:39:30.15 ID:SOqg0ON00.net] 単に型があればVisualStudioCodeなどでインテリセンスが働いて楽とかそんなもんで そもそもフロントエンドなら大抵はサーバー側とjsonでやり取りするだろうけど それを表示するだけのフロントで全てのAPIのjsonをクラス化するのかよｗって所がねｗ ツール使えば自動で吐き出されるとか言うのかも知れんがｗ C#(Unity)とかだとクラス化した方がコードは書きやすいけど 781 名前：デフォルトの名無しさん [2022/07/03(日) 20:00:04.80 ID:dvm8Yx0S0.net] クラスというよりはインタフェースを定義するって感じかな ただそれだと結局型安全じゃないキャストをすることになるから io-tsとかライブラリを使ってAPIがそれを満たしてるかを動的検証できる型情報を定義してる 782 名前：デフォルトの名無しさん mailto:sage [2022/07/03(日) 20:00:41.12 ID:4SpX/mYh0.net] >そもそもフロントエンドなら大抵はサーバー側とjsonでやり取りするだろうけど >それを表示するだけのフロントで全てのAPIのjsonをクラス化するのかよｗって所がねｗ なんか、「フロント」の認識に大きな隔たりがあるのを感じた。 783 名前：デフォルトの名無しさん mailto:sage [2022/07/03(日) 20:17:50.40 ID:eO2MvCIb0.net] クラス≒型って認識の人は大体クラスベースオブジェクト指向しか知らない人 784 名前：デフォルトの名無しさん mailto:sage [2022/07/03(日) 20:26:41.79 ID:yZSstosFM.net] ECサイト構成するのとメモ帳なり実用アプリ作るのを同列に語ろうとしても無理だよね 785 名前：デフォルトの名無しさん mailto:sage [2022/07/03(日) 22:46:24.69 ID:v7SLZgpRM.net] >>771 そういう認識の人は数値や文字列にも型があることの恩恵には気づけないのかもね 786 名前：デフォルトの名無しさん mailto:sage [2022/07/03(日) 23:02:35.18 ID:R2Xlh7GwM.net] >>771 狭い特定なパターンの型とクラスを持つプログラミング言語だけしか知らないとそこに陥りやすいかもね 例えばWebに身近なところだとWebAssemblyを書くのに最も使われている言語Rustあたりを理解すると何もかも新鮮で一気に視野が広がるかな Rustはクラスも継承もない それなのにメジャーな各言語よりも強力で便利で速い静的な型安全を実現している C/C++と同じ速さで動くのに即時自動メモリ解放なのでミスは起きず安全でガベージコレクションが必要なく高速な初のプログラミング言語 実行前にメモリ安全性からデータ競合の無さそして全ての型安全まで全てをコンパイラが静的に保証してしまう言語がRust フロントエンドでJS/TSメインで補助的にWasmを使う従来のスタイルから フロントエンド全てをRustで記述してWasmで動く新たなスタイルまで登場してきているので 今後のフロントエンドの進化でも注目点 787 名前：デフォルトの名無しさん [2022/07/04(月) 13:41:23.28 ID:jO1cee2ga.net] 関係ない話を突然ぶっこむ人っているよね 788 名前：デフォルトの名無しさん mailto:sage [2022/07/04(月) 22:42:34.12 ID:RYfceo1ir.net] 見事に話の腰を折っていったな 789 名前：デフォルトの名無しさん mailto:sage [2022/07/05(火) 09:10:46.05 ID:1P4+UDaA0.net] Wasmに関してはWasm公式が直々にJSを置き換えるようなものではないと明言してるんだよなぁ https://webassembly.org/docs/faq/#is-webassembly-trying-to-replace-javascript 790 名前：デフォルトの名無しさん mailto:sage [2022/07/05(火) 09:27:05.92 ID:7ktCWAiNM.net] >>777 そう言っとかないと炎上して面倒だからでしょ 世間で実際に置き換わるかどうかと置き換えとして使用できるかどうかは別問題で、 少なくとも後者についてはwasmの公式及び信奉者達は実現するつもりだろうな 791 名前：デフォルトの名無しさん mailto:sage [2022/07/05(火) 09:47:12.59 ID:1Na6iR4Vr.net] 名前がダサいし読みにくいから流行らんのだろ かっちょええ名前にすりゃいいのに 792 名前：デフォルトの名無しさん mailto:sage [2022/07/05(火) 10:01:45.25 ID:1P4+UDaA0.net] >>778 公式の言うことを全く信じないとか、陰謀論者みたいなこと言いますね…… 793 名前：デフォルトの名無しさん mailto:sage [2022/07/05(火) 10:05:49.50 ID:1P4+UDaA0.net] 訂正、信じなくてもいいとは思うけど、公式の言ってることを頭から否定するのはちょっとどうかと思うね 794 名前：デフォルトの名無しさん mailto:sage [2022/07/05(火) 10:16:35.79 ID:wYawBH+gr.net] なんでも斜に構えるのが格好いいと思ってるお年頃なんだろう 795 名前：デフォルトの名無しさん mailto:sage [2022/07/05(火) 12:07:20.02 ID:yTnwAAWuM.net] そうなって欲しいという気持ちはわかるけど 現状ワナビが夢語ってるのと変わらん 796 名前：デフォルトの名無しさん [2022/07/05(火) 17:15:47.11 ID:qwaP2fx0a.net] wasmおじさんまだいるのかよ wasmスレでやりなよ 797 名前：デフォルトの名無しさん [2022/07/05(火) 23:36:47.01 ID:vcOl+iQ90.net] TS型パズルのせいで終業遅れて趣味の時間が削られまくったわ 地味にイライラする 798 名前：デフォルトの名無しさん [2022/07/05(火) 23:42:50.14 ID:vcOl+iQ90.net] Nextjsは細かくサーバー処理とクライアント処理分けられるけどここまでやる必要あるのかね 無駄に突き詰めすぎな気がする せいぜいLaravelとVue程度で良いだろ 799 名前：デフォルトの名無しさん mailto:sage [2022/07/05(火) 23:57:05.76 ID:1P4+UDaA0.net] なぜ自分を棚に上げて他所に原因を求めてしまうのか 800 名前：デフォルトの名無しさん mailto:sage [2022/07/05(火) 23:59:36.80 ID:8EE7RMvOM.net] >>777 その通りでWasmはJavaScriptの機能を代替しない 例えばDOM操作をWasmから直接することはできない そのため各種プログラミング言語で書かれたWasmのプログラムいずれにも補助となるJavaScriptのプログラムが付随している したがってWasmからは間接的にDOM操作を含めて任意のことができる状況となっている 例えばC#だけでSPA含めたフロントエンドを記述できるフレームワークBlazorや 同様にRustだけで記述できるフレームワークYewなど 様々な各言語だけで記述できるフロントエンドのフレームワークがJavaScriptのフレームワークの競合となりつつある 特にRustで書かれたものはガベージコレクションや重い(or大きい)実行ランタイムを必要としないため ダウンロードサイズの点でも実行速度の点でも従来のJavaScriptと比べてほぼ同等となっている 801 名前：デフォルトの名無しさん mailto:sage [2022/07/06(水) 00:12:04.30 ID:mL802MxZ0.net] >>788 WasmからJSを呼び出すオーバーヘッドやGCの無いRustで書いてすらJSで書いた場合よりダウンロードサイズが増えることを意図的に無視してない？ まして所有権に気をつけながらRustで書くのと平坦にJSで書いたものが等速では意味がない。つまりWasmを使うべき場面はそこじゃない。 「その通りで」と言いながら元の文章の意味を都合よく無視した持論を展開するのは詭弁だよ。 802 名前：デフォルトの名無しさん [2022/07/06(水) 00:47:45.67 ID:hw0Myq7K0.net] next.jsってvercelとの抱き合わせ？ 803 名前：デフォルトの名無しさん mailto:sage [2022/07/06(水) 04:05:40.23 ID:iRwSwPVx0.net] Google Cloudつかってこ？ 804 名前：デフォルトの名無しさん mailto:sage [2022/07/06(水) 23:36:06.51 ID:1TXPug1l0.net] Wasm開発側がJSの代用にはならんって言ってるしな、既存のライブラリが使えるとか得もあるけど 805 名前：デフォルトの名無しさん [2022/07/07(木) 13:52:13.98 ID:Q+wrLXon0.net] 案件でReactとVueどっちも触ることがあるんだけど、Reactなんか好きになれないなあ なんかref使ってDOMを意識しなきゃいけないこと多くない？ 案件の性質の違いでたまたまそうなんかなあ depsとかもバグの温床だし書き方冗長だし それが好きな人もいるんだろうけど あとVueのtemplateはいいよね。HTMLそのままだし tsと相性良ければなあ 806 名前：デフォルトの名無しさん mailto:sage [2022/07/12(火) 14:55:23.91 ID:xMX52/DP0.net] >>793 refよりはstateの方が使う ref使わなくてもいい場面で多分ref使ってる canvasとか埋め込みプレーヤーとかwysiwygのエディターとか操作するときはref使う depsはhooksのlintのパッケージがあってそれ使えばバグは余裕で回避できる 807 名前：デフォルトの名無しさん mailto:sage [2022/07/13(水) 01:59:12.26 ID:41tA/9He0.net] ずーっと業務でGoとかのバックエンドやってて最近Vue始めたんだけど書き方多すぎないかこれ...？ まずOptionsAPI、CompositionAPI、script setupと3つある時点で意味わからん。ネットで検索してもコードが読めん。慣れてないだけ？ 808 名前：デフォルトの名無しさん mailto:sage [2022/07/13(水) 03:16:08.34 ID:gUCl+Swj0.net] script setupはComposition API書くためのシンタックスシュガーで、新規コードは全部script setupでいいと思うよ 809 名前：デフォルトの名無しさん (ｱｳｱｳｳｰ Sa09-x/sD) mailto:sage [2022/07/13(水) 08:47:39 ID:yxy6SFg9a.net] 歴史的経緯があるから書き方が増えるのは仕方ないにしてもドキュメントの整備が追いついてないのが困る 810 名前：デフォルトの名無しさん mailto:sage [2022/07/13(水) 09:27:13.93 ID:uixzy4W8r.net] ３つの書き方の名前を認識できるまで調べてるなら経緯も分かりそうなもんだけどね あとネットの記事漁るときは日付ぐらいチェックした方が 811 名前：デフォルトの名無しさん [2022/07/13(水) 10:37:48.05 ID:izDlcYF60.net] ref使わなくていいとこで使っちゃう人はvue使っても同じことになりそう 812 名前：デフォルトの名無しさん mailto:sage [2022/07/13(水) 23:04:39.43 ID:fYvgJCBx0.net] やっぱReactなんやなって > Reactに有利なベンチマークを作ってみた https://qiita.com/uhyo/items/35cb243557df5e1a87fc 813 名前：デフォルトの名無しさん mailto:sage [2022/07/14(木) 14:01:25.86 ID:4YPASV41a.net] https://qiita.com/tronicboy/items/18c36cb713f77af627d8 Reactオワコンってマジ？ 814 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 8d6e-lnzN) mailto:sage [2022/07/14(木) 15:05:14 ID:gqaZzHXf0.net] >>801 あんた日本人？ 815 名前：デフォルトの名無しさん mailto:sage [2022/07/14(木) 18:30:18.24 ID:H3yOuDPs0.net] >>801 この記事の主が表層的にしかReact理解してないから、コメントで突っ込まれまくってるな。しかも後半は技術じゃなくてMetaが嫌いって話してるし。 まぁでも、こういうやんちゃな奴がいる界隈は活気があって良いですよ。石頭でさえなければね。 816 名前：デフォルトの名無しさん mailto:sage [2022/07/14(木) 19:47:30.86 ID:JGI4j5iF0.net] フェイスブックが嫌いってのはかなり多いだろうな実際 817 名前：デフォルトの名無しさん mailto:sage [2022/07/14(木) 19:52:38.14 ID:sdF0D0vF0.net] >>803 しかも匿名ならわかるけど会社名出してるのが凄いな 818 名前：デフォルトの名無しさん [2022/07/17(日) 09:41:45.81 ID:SW0KkSnM0.net] 普段Vueディスってんのにreactディスられたとたん発狂する奴多くない？ 819 名前：デフォルトの名無しさん mailto:sage [2022/07/17(日) 10:13:01.49 ID:k8G1Xh4yM.net] 記事にツッコミどころが多いだけでしょ VueはReactに比べるとコンセプトがstraightforwardなので、良くも悪くも「そういう設計を選んだんだからそうなるよね」で議論が済んでしまう だからこの記事みたいな設計思想に対するディスはあまり見かけない印象 820 名前：デフォルトの名無しさん mailto:sage [2022/07/17(日) 11:24:22.33 ID:vN6ol9NM0.net] 仮想DOMにオーバーヘッドがあるの事実だしな だからsvelteやsolidが生まれた 普段からパフォーマンスにうるさいフロントエンドエンジニアが そこには目を瞑るのはおかしいだろうのは痛いところ突っ込まれた感じ 821 名前：デフォルトの名無しさん mailto:sage [2022/07/17(日) 11:37:33.93 ID:D8ZilbuM0.net] 仮想DOMとuseMemoでパフォーマンス的に困ることほぼ無いんよ。使ったことない人にはわかんないかもだけど『早すぎる最適化は諸悪の根源』だよ 822 名前：デフォルトの名無しさん mailto:sage [2022/07/17(日) 14:40:24.11 ID:vN6ol9NM0.net] そもそものReactの当初の発想は 「クライアント側でのPHP」を目指してたんだぞ 今の人は知らんだろうけど 本質的な面で効率が良くなるわけはないんだよ 823 名前：デフォルトの名無しさん mailto:sage [2022/07/17(日) 15:06:51.43 ID:K5laegAfr.net] Webの技術って欠陥だよな 824 名前：デフォルトの名無しさん mailto:sage [2022/07/17(日) 15:17:25.63 ID:D8ZilbuM0.net] XHPというPHPのライブラリが元になった部分があるだけで「クライアント側のPHP」を目指したなんて事実は無いぞ。 仮に「クライアント側のPHP」という機能を目指したとして、実装としてのパフォーマンスに何の関係があるんだ？ 自分の言いたいことのために都合の良い過去を作り出した上に変なこじつけをするな。完全に詭弁じゃないか。 825 名前：デフォルトの名無しさん mailto:sage [2022/07/17(日) 15:24:26.00 ID:SZhCYswta.net] >>812 PHPみたいにというのはつまりカスタムタグ使って ページを毎回再レンダリングしているように作りたいってことだよ サーバーサイドがそうしているようにね その副産物として仮想DOMやJSXが生まれた 826 名前：デフォルトの名無しさん mailto:sage [2022/07/17(日) 15:32:09.77 ID:D8ZilbuM0.net] >>813 そういう意味なら確かにそうだね 827 名前：デフォルトの名無しさん mailto:sage [2022/07/17(日) 16:30:58.35 ID:zDUNQKdi0.net] >>813 でなんでそれがPHPになんの？ 828 名前：デフォルトの名無しさん mailto:sage [2022/07/17(日) 18:40:14.41 ID:SZhCYswta.net] まずPHPといってるがfacebookの人がPHPと言ってるからそう言ってるがサーバーサイドと言い換えるべきものだよ(ご存じの通りfacebookはPHPのヘビーユーザー) クライアントからリクエストを受けたらサーバーサイドは HTMLを全て「生成し直して」レスポンスを返す 前回の状態など意識せず全て情報を取り直してHTMLを生成する 当たり前だが前回の状態との差分を取って部分的にHTMLを返すなどということはしない 常に丸ごと返す このモデル(HTTPだが)の良いところはHTML生成といううコンテキストにお� 829 名前：｢ては前回の状態と言ったものは意識しないで済むこと 最新の状態を取ってそれをもとにHTMLを生成すればよろしい 当時のフロントエンドはDOMに状態を持たせてajaxはその状態を更新して対応するDOMを更新するというアプリが大多数だった フロントエンドもサーバーサイドのように状態を意識せずに関連するDOMを毎回全部生成できないか？という発想が生まれる React誕生の瞬間である renderとstateを使って状態が更新されたらどの部分を更新するか一切意識することなく常に一枚岩のDOMを返すようにかける 見事サーバーサイドをクライアントに持ち込めた ただしこの動きを実現するためには差分を内部的に検出する仕組みが必要不可欠 本当に毎回DOMを全部生成してたらパフォーマンスが終わる ユーザーはDOMを意識せずに全部返すように書くが 裏で差分を検出してこっそり部分的にDOMを書き換えるようにしよう 仮想DOMの爆誕である そうなるとJSXみたいなものが必要だよねとなってJSX爆誕 これがReactの歴史である 知らんけど [] [ここ壊れてます] 830 名前：デフォルトの名無しさん mailto:sage [2022/07/17(日) 19:22:31.49 ID:HJLgMN7zM.net] パフォーマンスが実用に差し障るほど悪いという話には繋がらないわけだ

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef