Vue vs React vs Angular Part.4

レス数が900を超えています。1000を超えると表示できなくなるよ。
2020/06/11(木) 19:01:45.26ID:uGsh0NQC
実際どうなん？
Vue
https://jp.vuejs.org/
React
https://reactjs.org/
Angular
https://angular.io/
※前スレ
Vue vs React vs Angular Part.3
https://mevius.5ch.net/test/read.cgi/tech/1560333895/

★ここではjQueryの話題は禁止です
★jQuery房が書き込んでも無視してください
2020/07/27(月) 14:36:39.82ID:S26P/GM8
OWASPの"REST Security Cheat Sheet"ではただ一言。「セッションベースのユーザ認証を使え」と書いてある。
https://www.glamenv-septzen.net/view/1350#id55be56

ユーザ認証にはセッション管理を使え、とあり、さらに、セッションIDやAPIキー、ログインIDとパスワード、
トークンなどはURLに含めるな、ともある。
他にもこのページにはRESTスタイルで開発するときのセキュリティ上の注意点が解説されている。英語になるが、
内容的には普通のWebサイトと同じように入力チェック＋出力時のJSON/XMLに合わせたエンコーディング、
CSRF対策などをしてください、という流れ。
また以下のページは、逆にRESTなWeb APIを診断する、pentester向けのガイドとなっている。
クロールできたURLだけでは、全部のREST APIの機能を見れたことにはならない可能性があるので、
ソースコード診断（ホワイトボックステスト）も可能なら実施したい、などとあり、参考になる。
2020/07/27(月) 14:37:32.58ID:S26P/GM8
>>817
だからオンラインゲーム無理ってことですねｗ
820デフォルトの名無しさん
垢版 |
2020/07/27(月) 14:38:15.39ID:ffgSx4MU
>>800
最近Next触り始めたけどドキュメントにやたらSSG推してたから、あながちGatsby最高マンダムなんかもなと思うわ
GatsbyはでもGraphqlと結びついとるから気軽にカスタマイズしようとしたらエラー吐きまくる
2020/07/27(月) 14:38:36.28ID:S26P/GM8
>>817
クライアントだけで実装できるものしか
作れないと言ってます。

お前のやり方ではログインが必要なものは作れません。
オークションサイトは作れないし
ブログの管理をすることもできません。
2020/07/27(月) 14:39:56.60ID:Rr+dRFNS
>>803
ド素人がセッションも知らないのか？
CookieにセッションIdメモってサーバーサイドオブジェクトと紐付けるんだよ
2020/07/27(月) 14:41:27.35ID:S26P/GM8
>>822
お前の理屈は、クッキーの代わりにパラメーターでセッションIDを渡せすという
セキュリティ的に脆弱なセッション管理を実装すれば
サーバーに状態は持ってないことになるんやろ？ｗ
アホやなぁと言ってる
2020/07/27(月) 14:42:38.43ID:O6ncpH5Z
>>821
だからSPAのバックエンドにRESTが適してるんだよ
SPAならクライアント側で状態を持てるんだからサーバー側は関数でいいの
サーバーがセッション管理から解放される
これもSPAのメリットと言えるかもしれないね
2020/07/27(月) 14:43:20.19ID:S26P/GM8
もしかしてパラメーターのキーの名前がsession_idじゃなかったら
サーバーサイドに状態を持たせてないことになるとでも思ってるのか？ｗ
2020/07/27(月) 14:44:06.24ID:S26P/GM8
> SPAならクライアント側で状態を持てるんだからサーバー側は関数でいいの

え？ URLにパラメータとかユーザー名とかパスワードを入れればいいんだから
SPA関係ないじゃんｗ
2020/07/27(月) 14:45:41.88ID:S26P/GM8
クッキーを使えばクライアントに状態を持ってる！
例えばセッションIDをクッキーに入れておけば、
ウェブサイトにアクセスしたときにログインしたことになる！
JavaScriptも不要！古くから使われてるログインの仕組みだ！

みたいな話をされてこ困るんだよなぁ（笑）
2020/07/27(月) 14:48:59.96ID:S26P/GM8
クライアントにしかデータを持ってないと
別のパソコンでログインしてもデータが見れなくなる（笑）

まあそれでいいなら普通のウェブサイトのほうがいいだろうねｗ
HTML+CSS+jQueryで
2020/07/27(月) 15:03:07.49ID:Rr+dRFNS
アホのために説明してやるか

Cookieとサーバーサイドのオブジェクトの紐付けで擬似的にリクエスト間の状態維持を実現する手法がセッションな
従来のシステムではよく使われていたが思ったよりメモリ消費がバカになんねえなぁってことで今はもう廃れた

今どきのセッション管理はサーバーサイドのオブジェクトではなくCookieなどに暗号化したデータを含める方式で実装されている
そうすれば極僅かなCPUの負荷増でメモリ消費をぐっと抑えることができるようになる
リクエストに乗せたくない重大な機密や大きすぎるデータは永続化層で管理する
これがメモリに乗るのはデータ利用するその時とキャッシュされた時だけ
これでサーバーサイドのリソース効率がだいぶ良くなった
ついでにいうと水平スケールもしやすくなって一石二鳥

SSRはこの時代の流れに逆行してサーバーサイドに大量の状態オブジェクトを生成してクライアントと紐付けて管理するという愚行をおかしてしまっている
SSRの特性上どうしてもﾋビューに関するほとんどの状態をサーバーのメモリ上に確保してクライアントが去りゆくまでずっと維持し続けなければならない
これがどれだけリソース効率が悪い邪悪なアーキテクチャかは猫でもわかるだろう
クラウドファーストなこの御時世ではサーバーサイドのリソース増加はコストに直結する
こんな金食い虫のアーキテクチャではやってられんのだ
2020/07/27(月) 16:01:20.39ID:FzUtUUvl
>>793
ちなみにWappalyzerでは検知出来ないけどReact Developer Toolsなら検知されるパターンもある
多分Webpackの難読化の影響かとは思うが
Amazonの欲しいものリストのページやプライムビデオのページとかそんな感じ
2020/07/27(月) 16:11:00.85ID:A4vSpavl
>>797
AngularはMaterial系が主流だからBootstrapの対応はあんま良くないな
2020/07/27(月) 16:18:49.53ID:SDAq9vDF
>>829
> 今どきのセッション管理はサーバーサイドのオブジェクトではなくCookieなどに暗号化したデータを含める方式で実装されている

その方式はデータが大量になったときに破綻するので
セッションIDぐらいしか入れない
2020/07/27(月) 16:20:12.25ID:SDAq9vDF
>>829
> SSRはこの時代の流れに逆行してサーバーサイドに大量の状態オブジェクトを生成してクライアントと紐付けて管理するという愚行をおかしてしまっている

SSRとは無関係
2020/07/27(月) 16:22:25.22ID:SDAq9vDF
https://ssr.vuejs.org/ja/

従来の SPA (シングルページアプリケーション) と比べて、SSR の利点は主に次の点にあります:

・検索エンジンのクローラが完全に描画されたページを直接解析するため、SEO が向上します。
現在のところ、Google と Bing は同期的 JavaScript アプリケーションのインデックスを作成できます。
同期がキーワードです。あなたのアプリケーションが読み込み中にスピナが表示され、
Ajax 経由でコンテンツを取得する場合、クローラーはあなたが完了するまで待たないでしょう。
つまり、SEO が重要なページで非同期にコンテンツを取得する場合は、SSR が必要な場合があります。

・特にインターネットの遅さや遅いデバイスでは、コンテンツの再生時間が短縮されます。
サーバで描画されたマークアップは、すべての JavaScript がダウンロードされて表示されるまで待つ必要がないので、
ユーザは完全に描画されたページをすぐに見ることができます。これにより、一般的にユーザーエクスペリエンスが向上し、
コンテンツの所要時間が直接コンバージョン率に関連付けられているアプリケーションにとっては重要になります。
2020/07/27(月) 18:22:17.80ID:TfnjDE3E
>>820
たしかにたいていのことにプラグイン用意されてるからなんとかなってるけどじゃあ自分でgraphQL拡張するプラグイン作れと言われたらウッってなる。
2020/07/27(月) 19:12:49.38ID:UFheIHQs
>>835
Next使ってる？
Gatsbyと比較してそれぞれになんか思うことあったら教えてほしい

Next・Firebase・Stipe他でアプリ作ろうと思ってたけど、仰せの通りGatsbyはプラグインが充実しとるからGatsbyでええやん感が増してるわ
完成形に近いスターターに出会えればGatsbyの方が完成まで早そうやし
2020/07/27(月) 20:05:37.52ID:TfnjDE3E
ごめんNextは使ってない。
あれ基本サーバー側も含めた構成で全部静的配信したかった自分のSSGニーズと合わなかったしあまり検討しなかった。
Gatsbyとは違って個人ユースではなく企業サービスのビルディングブロックといった印象。いろいろいじる前提のプロ向けっぽい。
SSGモードも後付けされたけどだったらGatsbyでいいかなって。

ちなみに >>836 の strapiもfirebaseもプラグインあるね。
strapiのは試したこともある。特に困ることなかったｗｗ
838デフォルトの名無しさん
垢版 |
2020/07/27(月) 20:06:31.68ID:CctcRh4x
全ページSSRにすればJSオフでも見れて快適ですね。
2020/07/27(月) 20:12:01.61ID:0Re8MG/Y
SSRした結果をファイルにキャッシュしておけば
静的ページとほぼ同じでサーバーの負荷も殆どないしね
2020/07/27(月) 20:48:34.75ID:u51QqKbm
SSRを使うよりトップページを静的なS3とかにしたら良くない？
SSLの関係とかで出来ないのかな
2020/07/27(月) 20:51:01.79ID:9y96d1KX
その静的なS3を作るのにSSRを使うんでしょ？
842デフォルトの名無しさん
垢版 |
2020/07/27(月) 21:55:19.91ID:Ri9S2nsL
>>829
馬鹿はお前
パフォのためにコーディングの面倒さを犠牲にして
cookieみたいなヘッダいじったり
暗号化みたいな余計なことするくらいなら
メモリ倍くらいに増強してセッション使うわ
楽だからな。
ローバラがあるならセッションも諦めて全部
DBかローカルストレージのどっちか
とりあえずクッキーはない
2020/07/27(月) 21:59:13.37ID:fnBRfBHK
>>842
お前はもうちょっと世の中を見たほうがいぞ
REST APIはクッキーに暗号化してデータを埋め込む方式だ
どのREST APIもそういう設計になってるはずだ
2020/07/27(月) 22:13:05.38ID:q4lb5yU9
>>840
SEO気にするサイトはトップページだけ
indexされればいいわけじゃないと思うよ
2020/07/27(月) 22:17:35.56ID:fnBRfBHK
>>844
お前いつの時代のエセSEO業者だよｗ

SEOといったらページごとにテーマを決め
そのテーマに絞って内容を書くことでより多くのページを
検索に引っかかるようにするのが常識だろ
2020/07/27(月) 22:37:08.39ID:q4lb5yU9
>>845
なんなの？
2行つながってるわけだがトップページだけやればいいと誤解したのか？

そもそもweb appやSSRの文脈で「テーマに絞って内容を書く」ってアホじゃないの？
web appが動的に生成したpageをどうsearch engineにindexさせるかって話だろ。
staticなcontentsのSEOの話など誰もしていない
2020/07/27(月) 23:18:48.25ID:P2Gsimd7
Ruby on Rails では、未経験者が、1か月で作ったポートフォリオにも、ログイン機能はある

かよちんの動画

【ポイントは一つ】プログラミング未経験でも受かるポートフォリオの作り方
https://www.youtube.com/watch?v=la0rkh6wlxA

ログイン、投稿、コメント、いいね、検索、マイページ機能

Rails + Bootstrap
Github, Heroku
848デフォルトの名無しさん
垢版 |
2020/07/28(火) 09:14:18.81ID:KJ/jhVY+
>>675
草
Blazorおじおば涙拭けw
2020/07/28(火) 09:29:33.69ID:zKWFaExc
例えばユーザ認証するならFirebaseとか外部サービスに任せればいいだけだろ。。

ってか相変わらずスレチで伸びてるな。SPAって言葉が独り歩きしすぎだよ。
個人的にWEB開発者として重要な変化は、
・リアクティブ
・IDE(VSCode含む)による環境の統一やコード補完
・ホットリロード
この３点だろ。SPAだろうとSSR主体だろうと共通して劇的に楽になった。
あとは作りたいものに合わせてフレームワークなり言語選ぶだけだろ。

大手のサイトにフレームワークが導入されてないとか見たが、jQueryだけなんてサイトは案件的にありえない。
少なくともリアクティブでデータドリブン。どのライブラリを選定するかは大きな違いじゃない。
個々の要素は確実に進歩してるよ。
2020/07/28(火) 10:16:16.19ID:lvYKtUnl
でもほとんどのサイトがSPAだとオーバースペック、UX低下(非SSRの場合)、リソース消費量激増(SSRの場合)、人材不足だから非SPAを選んでるんだよな
複雑なUIをどうしても避けられない高度なSaaS、社内システムなど、ならSPAを採用するメリットはあるかもしれんが、そうでないならデメリットのほうが大きい
2020/07/28(火) 10:44:41.06ID:87VWo28p
>>849
SSRゴミカス野郎にリアクティブやらせたらデータと表示が一致させられなくて死ぬ

>>850
ゴミカス自称フロントエンジニアのゴミのようなUI/UXスキルはどうしようもないほど低レベル
コイツらにまともなUIを作れるわけがない
一生かかってもゴミセンスから抜け出せない
2020/07/28(火) 12:14:03.62ID:q6n5SbdD
VueとかNext.js使ってる人は
結局SPAとしては使わずに、SSRで使ってるということか？
2020/07/28(火) 12:19:12.90ID:Mb4DOiRz
やっぱ社内システムが正解か
2020/07/28(火) 15:27:54.67ID:zKWFaExc
>>852
SPA最大の利点はサーバの負担が軽い事だと思う。
フロントのためのロジック丸ごと省略できるから。
主に製作者側の都合なんだけどね。

例えば情報系サービスをスクラッチで作るとして、最初からスマホアプリとブラウザ版を作るならSPAも悪くない。
バックエンドは完全に共通になるしメンテ楽だわ。

ただ現状、WEBを作る場合ほとんどのケースでNextでSSRが最適解になるなあ。
855デフォルトの名無しさん
垢版 |
2020/07/28(火) 15:55:06.78ID:XpAjM/1U
かわいいときと
https://www.youtube.com/watch?v=zGPsPV24haE
2020/07/28(火) 16:02:20.88ID:3p32kQjL
>>854
デベロッパーだけの都合でもないよ
クラウドのランニングコストを支払う運営の都合でもある
2020/07/28(火) 16:08:18.16ID:6+Fa5W01
>>854
SPA vs サーバーでその処理を行うだったらそのとおりだけど
実際にはサーバーで処理を行うとは限らないんだよ

例えばAjaxを使ってJSONだけ読み取ってローカルの
テンプレートエンジンで処理をする。
マルチページで作るんだからこれはSPAではないよ。
JSONだけ読み取るのは現在のページ（URL）での処理だけ

それでもサーバーの負荷はわずかに減ると思うかもしれないけど
ボトルネックは通常データベースアクセスになるので
単にサーバーのCPUの休み時間が増えるだけ

> 例えば情報系サービスをスクラッチで作るとして、最初からスマホアプリとブラウザ版を作るならSPAも悪くない。
> バックエンドは完全に共通になるしメンテ楽だわ。
それもSPAである必要はないね。JavaScript（Ajax）で作ればいいだけ
2020/07/28(火) 16:10:31.74ID:6+Fa5W01
それにしてもURLが異なれば、通常はJavaScriptの処理も
まるっきり変わってしまうのになんでSPAにしようとしてるんだろうね
単にマルチページ+JavaScript（Ajax=テンプレート+JSON）でいいじゃない？
2020/07/28(火) 16:21:42.86ID:87VWo28p
ここでいうSPAフレームワークはリアクティブなんだよ
ajaxで取得したデータは自分で処理書かないといかんだろが

それとコンポーネント化
これらを理解できねーゴミクズたちが必死に浅い知識でSSR自慢しに来ている
わからねえならあっち行けよ
2020/07/28(火) 16:37:29.84ID:6+Fa5W01
まああれだな。新しい技術ができたら、それは銀の弾丸だとばかりに
それが正しい、それでやるべきだ！といういつもの流れ

そこから一方戻って、というブームがあったんだが実際はどうだろうか？
やりすぎだった。それが全てではない。適材適所だな。と気付いて
ようやく一人前の技術になると思うよ。今はまだブームの段階
2020/07/28(火) 16:40:02.39ID:qSy4jWEn
再利用性、テスタビリティ、クラウドコスト削減
2020/07/28(火) 16:49:49.58ID:3p32kQjL
>>859
リアクティブとSPAは関係ないだろう
マルチページじゃリアクティブできないとでも？
2020/07/28(火) 16:51:19.91ID:3p32kQjL
>>859
コンポーネントもSPAに限った話じゃないし
いにしえのJSFやASPNETですらサポートしてる
他のフレームワークもほとんどすべてがサポートしてるだろう
2020/07/28(火) 16:55:16.95ID:87VWo28p
>>860
ゴミクズの一味はおめえだよ
中身スカスカのレスいらないから
二度と来るな
2020/07/28(火) 16:57:08.31ID:87VWo28p
>>862
うざい
流れ読めねえならレスすんな
2020/07/28(火) 17:02:54.59ID:6+Fa5W01
フレームワークでテストがしやすくなったというのも疑問点が残るよね。
例えばクリックしたら色が変わるってのをどうやってテストをしているのか
書いてみてほしいものだが
2020/07/28(火) 17:26:57.21ID:diSWTXUe
web e2e test sweet とか
web e2e testing framework とかで検索してみたら？
2020/07/28(火) 17:32:31.17ID:6+Fa5W01
テストがやりやすいと言う割に
ググらないといけないと言うねｗ
2020/07/28(火) 17:35:54.49ID:zKWFaExc
>>857
その場合でも各ページの元になるhtmlはサーバが返すだろう？
ルーティングもサーバで処理する。それだとあまり美味しくない。
SPAの利点はWEBサーバのコード不要で静的ファイルを返すだけになり身軽になる事。
クライアントの帯域とコンピューティング予算を利用するスタイルだから、こっちは楽になるのは当然。
APIとDBサーバだけなら開発の負担はぐっと軽くなる。
逆にSPAの限界は、どうやっても肥大するJS。大規模には不向き。

いわゆるマルチページ（初めて聞いたが意味は分かる）が良いならNextでSSRすればいいよ。
どっちが良いという話じゃないし。
2020/07/28(火) 18:01:58.05ID:q6n5SbdD
>>860
Wappalyzerで国内サイトを
40社程度調べたところだが、React-frameworkで
有名らしいNext.jsもGatsbyほとんど使われてない。
Gatsbyに関してはWappalyzerで集計すらされてない。完全ランク外

ブームといえる状態にも来てないと思う。
名前は有名になってるのに導入があまりされてないのは調べてはみたけども
導入する価値がないと考えたサイトが多い証拠なんじゃないかな
2020/07/28(火) 18:11:40.11ID:2t1H/VoS
マルチページという言い方はレトロニムだね
2020/07/28(火) 18:13:16.31ID:OfeQkEiK
>>870
新聞社のサイトで既に動いてるのがあって置き換えると思うか？
大手じゃなく新しいサイトを調べて
2020/07/28(火) 18:19:22.00ID:2t1H/VoS
>>872
劇的にユーザビリティが向上するなら置き換えるのでは？
ようするに大したメリットないってことか
2020/07/28(火) 18:31:52.93ID:3p32kQjL
ほとんどすべてのサイトでは不要かむしろUXを悪化させるんだからSPAなんてものが流行るわけがない
コンサルさんは飯の種になるから必死に広めようとしてるようだけどな
2020/07/28(火) 18:38:12.60ID:diSWTXUe
数学わからないおじさん「数学なんて必要ない！」
英語わからないおじさん「英語なんて必要ない！」
こういう人はいくら必死に必要ない必要ない喚き続けても誰からも尊重されずバカにされてるよｗｗｗ
2020/07/28(火) 18:38:54.39ID:O4fp8d0k
要らないんならこのスレ来なきゃ良いのに
2020/07/28(火) 18:42:44.44ID:diSWTXUe
>>876
不安でしょうがないんでしょｗ
精神的安定を得るため叩くしかないｗ
実際に必要ないとしても知れば恐れることなどないものを。
無知とは恐ろしいねｗｗｗ
2020/07/28(火) 18:45:47.58ID:q6n5SbdD
>>872
基幹業務と違ってWebのフロントは短期間でリニューアルする。
大手ほど資金力あるから制限なくStackを選べる。

日経、朝日、読売新聞を見てみたが
web frameworkすら使われてないじゃないかｗ
読売はWordPressだな、CMS
さすがIT後進国

IT先進国はどうか？NY Times見てみたがSvelte が使われてるな
どうやらSvelte採用のトップクラスサイトだったようだ。

Svelte の公式サイトではReactやVueを
traditional frameworksと表現して暗に時代遅れだと言ってるのが気になる

https://svelte.dev/

SpotifyとかYandexも使ってるな
https://www.wappalyzer.com/technologies/javascript-frameworks/svelte
2020/07/28(火) 19:14:33.13ID:q6n5SbdD
>>856
零細サイトを除いたらランニングコストはオンプレミスのが安いし
クラウド要らない派

クラウドはバックエンドの構築、運用ができない企業が使うものだと思ってる
2020/07/28(火) 19:15:26.80ID:diSWTXUe
日経電子版のマイクロフロントエンドとPWA
https://hack.nikkei.com/blog/rnikkei_microfrontends_pwa/

SSRもやっとる
881デフォルトの名無しさん
垢版 |
2020/07/28(火) 19:15:32.97ID:y6zNnWpS
お前らが提案するフレームワーク名
毎回変わってて草
2020/07/28(火) 19:23:18.06ID:O4fp8d0k
>>879
零細ってイメージは違うと思うが
https://xtech.nikkei.com/atcl/nxt/column/18/00001/02776/
2020/07/28(火) 19:30:27.08ID:q6n5SbdD
>>882
上場企業でもほとんどがバックエンドの構築、運用ができない企業に該当する
開発を外部に丸投げしてるから運用のノウハウもない
2020/07/28(火) 19:31:59.50ID:3p32kQjL
本当に良いものは長く使われる
SPAはすぐに次のトレンドに置き換えられるだろう
Svelteなどなどすでにその兆候がある
2020/07/28(火) 19:42:45.57ID:zKWFaExc
過去の遺産があれば大規模なリニューアルは難しいだろうよ。
それは否定しない。いろんな事情あるからね。
ただ内部で開発ガッツリしてる系のサービスはおおよそNextなりVue使ってる感じ。
以前みたDMMの記事は面白かったよ。興味があればDMM Insideとか見るといい。
2020/07/28(火) 19:50:27.97ID:BMfiR1yf
どこそこの大手アプリはうまく行った！

こういうロジックでフレームワークを推奨してくる人には警戒したほうがいい
アプリのスケール感を全く考えてないから

日曜大工ツールセットで作るべき物を巨大重機で作ろうとするようにおかしなことになる
2020/07/28(火) 19:55:35.33ID:zmkVdjHm
フロントフレームワークって基本はSEO切り捨てていい部分のページ向けにまず作ってみるっていうのが大前提だと思う
2020/07/28(火) 19:56:21.61ID:zKWFaExc
>>886
サイトの規模がトラフィックの事を言ってるならそれは間違いだよ。
単純に作りやすさ保守メンテを考えれば考慮に値する技術が沢山あるという事。
2020/07/28(火) 19:56:57.82ID:87VWo28p
トップページをワッパライザしてSPA使われてねーとかほざいてるゴミ
2020/07/28(火) 20:07:19.55ID:ijkedvTd
>>888
保守、メンテナンスを考えるとSPA人材の少なさが大きな問題だな
WEB系フレームワーク使う人って、やっぱ、新しいもの好きが多いんだよね
んで、要領良くチャラチャラ生きてきたせいか知らんけど、責任感もない人が多くて、すぐに新しいものに目移りしたり、転職しちゃう
こういう連中に、数年後に、ちょっと前に流行ったあのフレームワークなんだけど、君が作ったやつ、あれメンテナンスしほしいなー、って言うとすげー嫌がるんだわ
ただでさえ少ない人材が、年月を重ねるとまじで皆無になる
で、連中はコピペ人間かよって思うぐらい同じようにこういうんだ、「新しい素晴らしいフレームワークに載せ替えましょう。お見積りはこれぐらいで」
信用ならねぇわ、古くから愛用されて、これから先もずっと生き残ると思われる技術、それを使う技術者こそが信用にたりうる
2020/07/28(火) 20:07:45.73ID:q6n5SbdD
>>889
ゴミはおまえのこと

web エンジニアなら>>859のようにAjaxという言葉を使わない
Ajaxの定義と経緯を調べてこい

おまえが良く使うreactiveについてもはっきりした定義がない
2020/07/28(火) 20:08:41.59ID:O4fp8d0k
ajaxって最早死語だよね
893デフォルトの名無しさん
垢版 |
2020/07/28(火) 20:32:28.27ID:y6zNnWpS
XHRだよな
2020/07/28(火) 20:39:29.09ID:q6n5SbdD
https://svelte.dev/blog/write-less-code

SvelteによるReact, Vue批判
コードが冗長すぎてうんこだと批判されてる。

Reactすこし触ったときにアホみたいにevent handler出てきて
なんでこんなめんどくさいことやってんだろうと思ったけど直観は正しかったようだ。

SvelteはcompilerだからJSの特殊さに縛られないらしい
たしかにコードがすごい短い

JS嫌いな人にはあってるかもしれないな
2020/07/28(火) 20:52:57.67ID:SAOER8re
だんだんPHPみたくなってきてんな
2020/07/28(火) 21:31:22.28ID:lUQSji2Q
テレ朝 react
日テレ vue
フジ nuxt
TBS 使ってない

TBS以外はSPA
TBSもがんばれ
2020/07/28(火) 21:36:52.82ID:nGd9+Z82
まあ正解だけ覚えてりゃいいと思ってる奴はこの仕事は向いてないよ。
2020/07/28(火) 21:50:29.84ID:87VWo28p
>>891
お前がゴミクソじゃねえか
俺はReactHooksが出る前のバージョンでWebアプリは数プロジェクト作ってる

全く問題ないどころかコンポーネント化が完璧にできているからメンテも楽

何が最新好きだよ？最新じゃなくてもSSRじゃ考えられないくらい開発しやすいわ

お前がゴミクソすぎてまったく使えないのはわかった
Ajaxがどうとか今さらそんなもので勝ち誇るなゴミクズ
レベルが低すぎるんだよ
クソみたいなUIしか作れないゴミクズの分際でうるせえわ
さっさとここから消えろ
2020/07/28(火) 22:06:51.74ID:nl0WhoWH
多分こないだのBlazorくんと同一人物なんだろｗ
聞き齧った話しを言いふらしてちやほやされたいだけ。
おそらく自分では何も作ったことないｗ
2020/07/28(火) 22:13:46.26ID:6+Fa5W01
>>871
マルチページがいやなら、SRP（単一責任の原則）設計といえばいいんじゃね？ｗ
SPAって1ページになにもかも突っ込んでしまってよくない
大きなものを作る時は小さなものの組み合わせにしたほうが良いよね
SPAの方が速くなることがあるのは事実だけど作るのが大変になる
2020/07/28(火) 22:14:33.23ID:WSKW8SBY
ずっとvueやってたけど最近react覚え始めたら難しすぎるわ
vueのcreatedとかmountedとかわかりやすいの名前だったなあって
2020/07/28(火) 22:19:36.33ID:6+Fa5W01
>>878
> 基幹業務と違ってWebのフロントは短期間でリニューアルする。

なるほど（笑）
だからこそさ、フロントの役目はなるべく少なくして
サーバー側でやったほうが良いんじゃないかｗ

フロントとサーバーが同じ言語で出来るのがメリットのように
言ってるけど、分離したほうが良い。そして変化の少ないサーバーサイドと
変化の大きいフロントインドに分けて、フロントエンドのコードはなるべく少なくする

SPAの速いよりも、メンテナンス性の方が大事だろ？
フロントとサーバーが一体化されてるフレームワークだと
フロントを変えようと思った時サーバーまで引きづられてしまう

結局、動的なサーバー処理 と 静的（＋JavaScriptで動き付け）なフロントエンドという
設計のほうが長い製品寿命が得られる
2020/07/28(火) 22:21:05.99ID:q6n5SbdD
ゴミクズ連呼してる基地外は何に切れてるんだろうな
こんな感情的な奴はまわりでも低品質なコードしか書いてない
2020/07/28(火) 22:22:46.11ID:6+Fa5W01
>>894
> コードが冗長すぎてうんこだと批判されてる。
マジそれ。コードが短ければバグも少なくなる。
テストできるようにするのは良いけど、そのために冗長になってテストが大変になってる。

完璧なテストなんかやめて、テストできない部分を意図的に残すが
その部分は最小限のバグのないコードで書けるようにしたほうが良いと思うよ
2020/07/28(火) 22:24:19.55ID:uRzl2y8u
>>899
ﾜｯﾁｮｲ付きならもうちょい分かるのにな
2020/07/28(火) 22:24:22.02ID:6+Fa5W01
>>897
> まあ正解だけ覚えてりゃいいと思ってる奴はこの仕事は向いてないよ。

そこでいう間違いっていうのは、すぐに陳腐化して負債になるコードな
わずか数年後にレガシーコードになってしまうものを覚えてどうする？
そういうコードを書くならちゃんとお前がメンテナンスしなきゃいかんぞ？
2020/07/28(火) 22:25:32.64ID:uRzl2y8u
>>901
もうライフサイクルメソッドはHooksで置き換えられるからそんなに難しくないぞ
2020/07/28(火) 22:28:56.33ID:6+Fa5W01
Hooks使ってない人は過去に作ったプロジェクトを修正してるの？
それとも工数もらえないから放置？

プロジェクトを再開する時、これはもうレガシーですねとかいって
改修作業するの？
2020/07/28(火) 22:29:54.30ID:BBDnKqXC
まあもってあと3年だろうな
その後はもう別のオモチャに乗り換えてる
2020/07/28(火) 22:32:50.36ID:6+Fa5W01
フロントは変化しやすいってことを考えると
フロントの処理が多くなりすぎてるんだろうな
2020/07/28(火) 22:36:17.62ID:uRzl2y8u
大体黎明期に大きく変わって段々落ち着いてくるもんだけどね
2020/07/28(火) 22:38:58.53ID:BBDnKqXC
SvelteもいいけどElmもいいな
とにかくレトロJSと別言語ってのが筋がいい
レトロJSの都合から解放されるだけでなくWASMへの移行にも期待できる
TSも別言語っちゃそうだけどこいつはレトロJSの面影が強く残ってるのが減点
2020/07/28(火) 22:40:50.68ID:6+Fa5W01
○○は嫌いなんだ！だからレトロと言おう、レガシーと言おう！
という印象操作。脱jQueryも同じ仲間

レトロとかレガシーとか脱とか言ってるのに
それが現実にならないのは悔しいだろうなぁｗ
2020/07/28(火) 22:43:39.89ID:87VWo28p
>>899
おめーはアホだからブレザー野郎と区別すらつかねえんだなゴミクズ
2020/07/28(火) 22:45:19.56ID:uRzl2y8u
なんかQiitaとかでReact始めましたって人が皆classでコンポーネント書いてるのはチュートリアルがHooks対応してないって事なん？
2020/07/28(火) 22:46:23.80ID:gqXSWBcd
>>913
んーでも実際レトロじゃないか？
ブラウザで動くのがそれしかない&資産（負債）が溜まりすぎて移行できないっていう、言語自体の良さ以外の理由で生き残ってるあたりレトロ臭がキッツい
WASMでそのあたりが変わって行くと素晴らしいことだが、残念ながらまだもう少し時間がかかりそうだ
2020/07/28(火) 22:48:09.63ID:87VWo28p
>>908
んなもんどんなフレームワーク使っていても同じだろゴミクズ
バックエンドのフレームワークも数年で変わってるだろゴミクズ
フロントが変化しやすいってなんだゴミクズ
テメーが使えてねえだけだろ
レス数が900を超えています。1000を超えると表示できなくなるよ。
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。