20/07/23 11:13:10.23 /gQkLfku.net
年取って周りの意見が耳に入らなくなった老害JSおじさん
vs
若いBlazor勢力
601:デフォルトの名無しさん
20/07/23 11:20:51.69 BEz0RkVx.net
Blazorの記事見てるけどなんかBlazorのソースってフレームワーク使ってないPHPやJSPみたいなコーディングするんだね
602:デフォルトの名無しさん
20/07/23 11:26:19.24 /b5pS+w+.net
>>594
ウェブシステムのフレームワークってどれもそういうもんだぞ
それが一番ウェブのシステム開発に適してると判断したってことだよ
603:デフォルトの名無しさん
20/07/23 11:37:21.07 1c3WMgKJ.net
>>593
お前老害過ぎるわｗ
604:デフォルトの名無しさん
20/07/23 11:43:47.44 BEz0RkVx.net
タグの中に分岐やループの制御文書くのってなんかレガシーな感じだよね
605:デフォルトの名無しさん
20/07/23 11:49:55.98 /b5pS+w+.net
>>597
ほぼすべてのフレームワークが、それを採用してる。
っていうか、それを採用してないフレームワークを
お前は一つでも言えるの？何も知らんでしょ？
606:デフォルトの名無しさん
20/07/23 11:54:30.03 qQzwkkHt.net
まだ5年くらいしか経ってないJSTL（JSP Standard Tag Library）に
ようやく追いついてレガシー呼ばわりされるとは開発しがいがないね
607:デフォルトの名無しさん
20/07/23 11:55:05.70 qMtp6n+5.net
>>597
KISSの原則だな
人類は奇抜なアイデアに翻弄されて様々なアーキテクチャ浮気したけど
原点回帰かつそれを高度に洗練させたものが結局はイチバンだったというわけだ
608:デフォルトの名無しさん
20/07/23 12:00:44.73 5F2A9vyN.net
>>597
でも他にいい案もなくね？
609:デフォルトの名無しさん
20/07/23 12:02:05.34 qMtp6n+5.net
昔ながらの誰しもが知ってる馴染み深い単純明快でインジェクション安全で型安全でインテリセンスもバリバリ働くRazor構文
それを使って最新のSPAフレームワークと同等以上の成果物を得られる
それってつまりどう考えても最高ってことじゃないか
もうSPAをするのに出来損ないのJS言語やぶくぶく太った醜いフレームワークに疲弊しなければならない暗黒時代は終わった
610:デフォルトの名無しさん
20/07/23 12:04:54.14 /b5pS+w+.net
おそらく>>597はゲームプログラミングしかしたことないんだろ
ゲームはユーザーインターフェースは全部自分で作るという特殊なアプリ
システムアプリではUIはHTML・XML系で作ったほう簡単
動的にUIを変更するならHTML・XML系に分岐やループを書くほうが適している
611:デフォルトの名無しさん
20/07/23 12:06:20.88 BEz0RkVx.net
>>601
制御文の中にタグがあるのはいいと思うんだよ
それを置きたいタグ枠の外で分岐やループしたものをコンポーネント化してそれを
置きたいタグ枠の中に配置すればタグの中に制御文はないという構造にできる
612:デフォルトの名無しさん
20/07/23 12:17:56.42 atvy6zMd.net
>>594
frameworkなしと一緒にするなよ、ぜんぜんちがう
Razor syntaxはasp.net MVCとかでも使われていたし
ちゃんとMVCできれいに分離されてる
実際に使ってみればきれいにフォルダ分類されてるのにきづく
613:デフォルトの名無しさん
20/07/23 12:24:28.50 atvy6zMd.net
>>597
タグの中に書かれてるんじゃない
Razor syntax
URLﾘﾝｸ(docs.microsoft.com)
HTML, CSSがロジックを扱えないわけだから
C#とhtmlの親和性の高いsyntaxが作られている。
ReactのJSXも同様だ。
ぜんぶごっちゃになってるJSPとは違う。
記事だけじゃなくインストールして試してみるべし
614:デフォルトの名無しさん
20/07/23 12:26:50.44 Eu0fAWmh.net
>>594
C#おじさん向けだからな。
615:デフォルトの名無しさん
20/07/23 12:28:17.60 Eu0fAWmh.net
>>597
レガシーな人間向けだからな。
616:デフォルトの名無しさん
20/07/23 12:32:56.87 /b5pS+w+.net
これからは○○の時代！
結局生き残ってるのはjQuery（笑）
617:デフォルトの名無しさん
20/07/23 12:35:26.89 atvy6zMd.net
>>597 594
Blazor WebAssemblyは再利用可能なコンポーネントなわけ。
ネストしたりもできる。
これが原始時代のJSPとかと一緒に見えるなら
WebAssemblyがなんのかという基本のところが
まったく理解できていないことになる。
>>607-608
スクリプトしかできないいつもの低能か
型すらないレガシー言語つかってる人って頭悪いよな
618:デフォルトの名無しさん
20/07/23 12:50:07.46 /b5pS+w+.net
> Blazor WebAssemblyは再利用可能なコンポーネントなわけ。
JavaScriptライブラリなんかも再利用可能なコンポーネントですが？
619:デフォルトの名無しさん
20/07/23 12:51:50.81 Eu0fAWmh.net
C#とTypeScriptは設計者が同じ
TypeScriptがその人の最新作かつ最高傑作
C#は見捨てられたロートル
C#の型表現の古臭いことｗ
C#おじさんの耳の後ろとおんなじ臭いがするよｗ
620:デフォルトの名無しさん
20/07/23 13:02:36.51 BEz0RkVx.net
もうDelphiとか知らんヤツばっかなんだろうな現代では
621:デフォルトの名無しさん
20/07/23 13:08:23.43 GYY/oZAq.net
TypeScriptはトランスパイラから脱却してからがスタートラインかな
622:デフォルトの名無しさん
20/07/23 13:14:36.20 mW7dxmke.net
その前にjapascriptがtypescriptを吸収する
623:デフォルトの名無しさん
20/07/23 13:19:52.31 L3r8FJ9R.net
ブラウザなんかじゃ実行時に型チェックしてエラーにしてもたいしてメリットないんじゃね？
せいぜい、型チェックをスルーしてトランスパイルなしで実行できるようにするくらいかな。
624:デフォルトの名無しさん
20/07/23 13:20:00.25 BEz0RkVx.net
>>615
ES2023～ES2025くらいの間にそういうのもありそうだよね
625:デフォルトの名無しさん
20/07/23 13:39:01.10 eemKZeH7.net
>>616
解析のせいで遅くなるだけでメリットは少ないだろうな
TypeScript処理系をブラウザに載せるのは悪手としかいえない
そんなことせんでもwasmにビルドできればいいんだよ
626:デフォルトの名無しさん
20/07/23 14:00:25.96 Eu0fAWmh.net
wasm用には亜種のAssemblyScriptがあるっちゃある
627:デフォルトの名無しさん
20/07/23 15:20:46.55 atvy6zMd.net
>>612
おまえと違って中級以上は型が必要なのわかっている
TSのおかげで型のない欠陥言語JSをましになってるが
うんこの制限をうけずいちから設計したC#にはとてもかなわない
見捨てられたとかいってる時点でこのバカなにもわかってない
C#は新しい機能をいれてきた言語だ
歴史はあるが常にアップデートされてきてる
互換性に固執しすぎて終わってるPerl , JS, Javaとは全然違う
628:デフォルトの名無しさん
20/07/23 15:23:15.87 atvy6zMd.net
>>615
その前にWebAssemblyが普及して
JSで開発する必要がなくなるよ
629:デフォルトの名無しさん
20/07/23 15:26:34.49 J3e6JLoy.net
>>620
> おまえと違って中級以上は型が必要なのわかっている
Googleのこと？
630:デフォルトの名無しさん
20/07/23 15:27:13.58 J3e6JLoy.net
>>621
お前の予測では、WebAssemblyが普及するのは何十年後？
631:デフォルトの名無しさん
20/07/23 15:36:42.27 atvy6zMd.net
>>623
理解力と先見性がある人はもう移ってるが。
C#とかを理解できない無能はPHPとかJSで開発を続けるだろう
今でもCOBOLやエクセルVBAでシステム開発してるアホな企業があるが
JSで開発というのはそういうやつらと同じ扱いになる
632:デフォルトの名無しさん
20/07/23 15:39:47.59 Eu0fAWmh.net
C#は古いため、初期設計した天才不在の中、バカにどんどんゴミを付け足されたキメラで、醜い。
初期設計した天才はとっくに見捨ててしまったｗｗｗ
その天才は今、TypeScriptに熱心に取り組んでいるｗ
633:デフォルトの名無しさん
20/07/23 15:40:47.10 69DFcaak.net
>>625
なんでこいつ発狂してんの？
634:デフォルトの名無しさん
20/07/23 15:41:26.12 Eu0fAWmh.net
C#は、おじさん
使ってる人も、おじさん
どっちも基本的な考えが古くて、臭う
635:デフォルトの名無しさん
20/07/23 15:46:10.17 atvy6zMd.net
>>626
そいつは頭悪くてC#が理解できなくてコンプレックス持ってる
高機能で高速な言語C#への嫉妬
C#がゲーム開発でめちゃくちゃ使われてるのも知らないみたい
636:デフォルトの名無しさん
20/07/23 15:49:15.74 atvy6zMd.net
低能の相手しても時間もったいないからレスは控えるわ
637:デフォルトの名無しさん
20/07/23 15:50:20.40 Eu0fAWmh.net
作者が見捨てたC#笑
638:デフォルトの名無しさん
20/07/23 15:50:34.45 wQG2WFy/.net
スレタイ読めないジジイは何人おるんや
639:デフォルトの名無しさん
20/07/23 16:12:04.52 BEz0RkVx.net
>>630
Pythonの作者が開発コミュニティから抜けた話は聞いた事あるけどC#もなわけね
640:デフォルトの名無しさん
20/07/23 16:15:12.96 HnEAcPzK.net
リアルな話、c#はWinFormsとUnityにしか使われていない
641:デフォルトの名無しさん
20/07/23 16:18:27.48 BEz0RkVx.net
>>628
っていうかコード補完なしで生きていけない人種ってだけっしょ？
642:デフォルトの名無しさん
20/07/23 16:21:22.71 gbrd0w8z.net
UnityのC#は生のC#じゃないですし
643:デフォルトの名無しさん
20/07/23 16:22:33.29 MBVi+zLE.net
JSもC#もピンキリじゃね
644:デフォルトの名無しさん
20/07/23 16:28:30.99 Eu0fAWmh.net
>>632
MSに勤めてて、どっちもMSの製品だから抜けたというと語弊があるけど、
こっちがC#のリポジトリ
URLﾘﾝｸ(github.com)
こっちがTypeScriptのリポジトリ
URLﾘﾝｸ(github.com)
そしてこれがヘルスバーグ先生のコントリビューション履歴ｗｗ
URLﾘﾝｸ(github.com)
完全にC#は手放しててワロタｗｗｗｗ
ザコグラマにウンコ機能付け足されるだけのC#笑
645:デフォルトの名無しさん
20/07/23 16:41:09.71 NwSW5l99.net
C#は完成されてるから先生が面倒見なくても軌道に乗る
TypeScriptはまだまだ未熟でC#ほど洗練されてないので先生の助けが必要
646:デフォルトの名無しさん
20/07/23 16:53:15.94 Eu0fAWmh.net
つまりC#にザコグラマがどんどん足し続けてる機能は全くの蛇足と言うわけ。
昔は新鮮だった開封数十年のオレンジジュースに、泥水を延々注ぎ続けてるのがC#笑
647:デフォルトの名無しさん
20/07/23 16:56:12.41 gbrd0w8z.net
C++もそんな感じ
648:
20/07/23 17:00:21.44 zbOcxM4i.net
>>639
URL2.0 もそうだったし、
C89 より後ろの C もそう
何かの文書で「言語法律家」と揶揄されていたのを見た記憶があります
649:デフォルトの名無しさん
20/07/23 17:00:44.41 BEz0RkVx.net
>>640
C++とかブラウザと一緒でコンパイラメーカーやコミュニティが先行して入れた機能を後から標準化団体が標準仕様として策定してるような感じじゃないの？
650:
20/07/23 17:02:23.45 zbOcxM4i.net
>>642
C++ は、今は規格が先行しコンパイラメーカーが必死になってついていく感じです
651:デフォルトの名無しさん
20/07/23 18:51:50.01 Eu0fAWmh.net
三大サーベイの中で最もJSに厳しいIEEEの今年のランキングが出たぞーｗｗｗ
Top Programming Languages 2020
URLﾘﾝｸ(spectrum.ieee.org)
あっれれ～？おっかしぃぞ～？ｗｗｗｗ
652:デフォルトの名無しさん
20/07/23 18:59:48.00 6aE6oFxh.net
>>644
ただの感想じゃんｗ
653:デフォルトの名無しさん
20/07/23 22:47:13.26 5yzO6ql9.net
実写版キングダムはテンの再現率が高い。
654:デフォルトの名無しさん
20/07/24 00:10:13.17 yCEn1h9i.net
サーバーサイドレンダリングできる＝ググったときに検索結果に出やすいって認識でおけ？
カップ麺図鑑みたいなもん作ろうとしてて、カップ麺の商品名でググったらそのページが出やすくなるようにしたいのよね
655:デフォルトの名無しさん
20/07/24 07:22:49.10 Xs8DjPMU.net
C#嫌いな人はStackOverflowも使用禁止な
656:デフォルトの名無しさん
20/07/24 07:54:54.35 N+F9nul4.net
GitHubは、Ruby製。
Rubyアンチは、使用禁止！
657:デフォルトの名無しさん
20/07/24 09:07:10.80 c87Ipt6p.net
俺からすればC#, Perl, PHP, JSなんてクソの背比べ
658:デフォルトの名無しさん
20/07/24 09:26:39.30 fpaVh+C9.net
そこで満を持して登場するのが
659:デフォルトの名無しさん
20/07/24 10:02:11 fMjVnhWI.net
jQuery
660:デフォルトの名無しさん
20/07/24 15:03:44.79 VpzRbTvR.net
どうせ不毛ならｊおじとBlaおじの不毛な争いが見たかったな
661:デフォルトの名無しさん
20/07/24 16:17:24.32 v+EKAnTC.net
まるで有毛な争いがあったかのような言い草だ・・
662:デフォルトの名無しさん
20/07/24 18:26:38.54 9v9Epd9J.net
三大ｶﾞｲｼﾞ全員ハゲだからな。
663:デフォルトの名無しさん
20/07/24 21:12:27.82 PfN6NIjK.net
Blazorお姉さんだけど
jQueryおじさんとかはframeworkつかえないし
スクリプトおじさんはC#理解できないし
相手にならない
ところでJSのSPAの最初の読み込みは
何MBくらいになるのが普通？
何MBまで許される？
有名どころのSPA使ってるサイトあったら計測したいから教えてほしい
664:デフォルトの名無しさん
20/07/24 21:34:50.64 9H+RWfuB.net
GMailは？
665:デフォルトの名無しさん
20/07/24 21:46:23.70 j4NCrF6q.net
blazer婆まで出てくるとはｗ
666:デフォルトの名無しさん
20/07/24 21:54:02.91 U/Nd6Iq0.net
>>656
一方SPAを使わなければ、必要なデータだけ読み込むので
数KBですむから、本末転倒になってるんだよなぁ
SPAかどうかはユーザーにとっては関係ない話
ページ表示の目安はGoogleがレポートしている
URLﾘﾝｸ(developers.google.com)
URLﾘﾝｸ(marketingnative.jp)
遅延する時間 ユーザーの反応
0~100ミリ秒 すぐに結果が得られたと感じる。これ以上時間がかかると、操作と反応にずれが生じる。
100~300ミリ秒 少しの遅れを感じる。
1000ミリ秒（1秒）以上 実行したタスクについて関心を失う。
つまり1秒以内だよ。100Mbpsだったら1秒で12.5Mバイトだけど
そんなスピードは出ないだろう。通常だと20Mbpsかねぇ。つまり1.5Mバイト
でも速度制限や回線が遅い場合を考えると500Kバイト程度に抑えたほうがいいだろうね
667:デフォルトの名無しさん
20/07/24 21:55:42.66 U/Nd6Iq0.net
お、Googleの推奨があった。
Googleの推奨は1.6MB。7,866のウェブサイトの平均は 2.43MB。あなたのトップページは？
URLﾘﾝｸ(webtan.impress.co.jp)
通常だと～の計算と近いね
668:デフォルトの名無しさん
20/07/24 21:58:15.51 9H+RWfuB.net
wasmなら最適化も簡単だろう
今後どんどん速くなっていくとおもわれ
669:デフォルトの名無しさん
20/07/24 21:59:19.49 U/Nd6Iq0.net
WebAssemblyはファイルサイズがでかくなる
670:デフォルトの名無しさん
20/07/24 22:01:51.85 U/Nd6Iq0.net
WebAssemblyはバイナリだから小さくなると考えているやつがいるが、
JavaScriptでも配布する時はgzip圧縮をかけるので
バイナリになって小さくなるんだよな
671:デフォルトの名無しさん
20/07/24 22:35:06.44 yCEn1h9i.net
AngularもReactもVueも使ったことあるよーって人に聞きたいんだけど、どれが一番好き？
672:デフォルトの名無しさん
20/07/24 23:16:35.73 PfN6NIjK.net
>>657
GmailのwebはSPAなのか
FirefoxでGmailを計測してみたら170 requestsくらいしてて11MBくらいだった。
しかもこれcache削除しないで測ってるから画像は除外された数字
backgroundで読み込むから読み込み完了まで25秒超えてる。
今はトップページ読みだけで10MB以上でも許される世界になってるのかな？
Gmailでかすぎ？完全にcacheけしたらどの程度いくんだろう, たぶん試さないけど。
673:デフォルトの名無しさん
20/07/24 23:19:14.32 PfN6NIjK.net
>>657
ちなみにBlazor WebAssemblyのサンプルは初回読み込みで17MB程度だが
2回目以降は400kbとすごく小さい
初回通信でバイナリがほとんどcacheされてる
Blazor WebAssemblyのがはるかに優秀
やっぱりJSのSPAの時代は終わりだわ
JSは言語もゴミだし
これからはC#でBlazorの時代と確信した
674:デフォルトの名無しさん
20/07/24 23:27:28.52 PfN6NIjK.net
>>659
non-SPAと比べるのはフェアじゃない
SPAはUXが上というメリットがあるわけだからな
その目安はSPA関係ないし制限1秒はきつすぎる
あとMVNOだとランチタイムで速いところでも10Mbps
10秒待ってくれても12.5MBか
とりあえずBlazorの2回目以降400kbで
改めて優秀さは確認できた
MVNOのうんこ回線のランチタイムでも快適にloadできるはずだ
初回10MB超えるのも5Gきたら気にならない世界かもしれない
675:デフォルトの名無しさん
20/07/24 23:46:29.59 SsZ4AS8R.net
Blazorの初回転送量は1.7MBくらいじゃなかったっけ？開発者ツールの見方間違ってない？
676:デフォルトの名無しさん
20/07/24 23:51:43.42 SsZ4AS8R.net
Blazorのテンプレートなら、Brotliで1.8MBだね
677:デフォルトの名無しさん
20/07/25 00:37:15.39 WCMFimkk.net
ここまでスレタイに全く関係無い話を続けられるの逆にすごいな
ボケがはじまってんのか
678:デフォルトの名無しさん
20/07/25 02:39:20.52 ZlqyHRW3.net
>>664
JavaScriptを主として掛けるからReact
他はhtmlタグが主でJavaScript従な感じ
679:デフォルトの名無しさん
20/07/25 02:51:04.72 uhXYZAuD.net
世界最速のサイトは、Ruby on Rails 製！
URLﾘﾝｸ(dev.to)
元乃木坂46 の川後陽菜のWebサイト、SKIYAKI も速い。
URLﾘﾝｸ(kawagopro.com)
Rails に勝てる、フレームワークは無い！
680:デフォルトの名無しさん
20/07/25 04:22:17.09 icwPneMN.net
>>668-669
どのテンプレートプロジェクト作成した？
Blazor WebAssemblyじゃなくてBlazor Serverになってない？
Storageにダウンロードされたdllとか確認した？
dotnet new blazorserver
で作成するとファイルサイズ小さくなるがそれだとWebAssemblyになってない。
Blazor Serverだとserver sideで動く
wasmで使うtemplateは
dotnet new blazorwasmを使う
本番向けのbuildするとかなり小さくなると書かれているがやり方まだ知らない。
それやったら初回17MBではなくもっと小さくなるかも
やり方知ってる人いたら教えて
681:デフォルトの名無しさん
20/07/25 04:40:17.49 icwPneMN.net
>>668-669
template動かしたときにrelease buildした記憶がないから
自分の書いた17MBはBrotliになってなかったかも
あとで試してみる
sizeはfirefox開発者ツールのnetwork tabでみた
初回1.8MBならぜんぜんOKだね
Blazor WebAssembly、ファイルサイズすごい小さい
682:デフォルトの名無しさん
20/07/25 04:56:22.14 vIjhxGJs.net
フロントエンドフレームワークのかなり網羅的なベンチマークの最新版。
左ほど良い。右ほど悪い。
URLﾘﾝｸ(krausest.github.io)
二回ほど前からblazor-wasmもフロントだから入れろと信者にゴネられてリストされてる。
なお不動の最下位で大恥かいた模様。
683:デフォルトの名無しさん
20/07/25 05:11:49.78 vIjhxGJs.net
最近のビルドについてBlazorプロジェクトのマネージャーであるマイクロソフトのDaniel Rothはchatにて
「Blazor would be 10x slower than JS and not winning speed competitions」
（BlazorはJSよりも10倍遅く、スピード競争に勝つことはない）
と述べた。
684:デフォルトの名無しさん
20/07/25 05:23:04.98 vIjhxGJs.net
AOTサポートにより（JSに勝つことはないにせよ）性能向上が期待され、また宣伝し、信者も大いに期待していたが…
AOT support in Blazor WASM will be postponed and not show up in .NET 5.
Blazor WASMでのAOTサポートは延期され、.NET 5には含まれません。
URLﾘﾝｸ(twitter.com)
延期されたｗｗｗｗ
一時ソースはGitHubのAoT compilation issueへのDaniel Rothの6/6のコメントとみられる。
他の改善アイテムで頑張るってよｗ
(deleted an unsolicited ad)
685:デフォルトの名無しさん
20/07/25 05:51:38.78 VPBor6Kz.net
まあそれも時間の問題だろう
wasmのほうが最適化しやすいのだからそう遠くないうちに逆転する
これはほぼ既定路線と考えていい
686:デフォルトの名無しさん
20/07/25 07:29:16.19 l/9hXNF1.net
これか
Next for Blazor: AOT for 'Massive Speed Gains'
URLﾘﾝｸ(visualstudiomagazine.com)
WASMで動く.NetランタイムがJIT無しのインタープリターだからILの実行が遅いってことね
これじゃあWASMがJSより速いと言っても、延期されたAOT(ILからWASMだよね？)が実装されないと、その速さが Blazor に反映されることは無い
.NET 5に間に合わないならAOTは来年以降
それまで Blazor スレで頑張ってください
687:デフォルトの名無しさん
20/07/25 11:28:31.85 NJ9vLrlx.net
>>675
公開処刑じゃんワロタｗｗｗ
688:デフォルトの名無しさん
20/07/25 13:33:34.03 0jDIZWNk.net
JSの余命もあと1年足らずか
感慨深いな
689:デフォルトの名無しさん
20/07/25 13:38:29.51 cd2WXu1h.net
脱jQueryと言われてから何年経ったっけな？ｗ
690:デフォルトの名無しさん
20/07/25 13:56:24.05 ZlqyHRW3.net
C#erって昔はこんなにスレチなところで延々と講釈を垂れ続けるようなバカじゃなかったはずなんだがなぁ
大体本当に優れてるものならそんな意味の分からん喧嘩なんて売りに来なくても広まるものは広まるだろ
691:デフォルトの名無しさん
20/07/25 13:58:58.64 0jDIZWNk.net
長いJSの歴史の終焉を目の当たりにして感慨深いなぁって思っただけであって喧嘩を売ってるつもりは微塵もない
692:デフォルトの名無しさん
20/07/25 13:59:34.29 ZlqyHRW3.net
>>682
jQueryはWeb"サイト"分野では永劫に使われ続けると思うよ
ブラックボックスってわけじゃないからブラウザベンダーに排除されることもないだろうし
693:デフォルトの名無しさん
20/07/25 14:05:25.78 ZlqyHRW3.net
>>684
その終わるという根拠とやらはなんなの？
694:デフォルトの名無しさん
20/07/25 14:13:44.26 CLKbPK7s.net
jQueryはすばらしいからこそJavaScriptに吸収される形でなくなって欲しいわ
実際、jQueryでしか書けなかったセレクタがJavaScriptに取り込まれたりしてるよね
695:デフォルトの名無しさん
20/07/25 14:16:37.16 4ePue1ew.net
>>686
占いとかそんな感じ
696:デフォルトの名無しさん
20/07/25 14:23:57.80 0jDIZWNk.net
>>686
自明でしょ
697:デフォルトの名無しさん
20/07/25 14:25:56.10 ZlqyHRW3.net
>>689
全然自明じゃないから聞いてるだが
具体的にどんなプロセスでどう終わるのか説明してみたまえ
698:デフォルトの名無しさん
20/07/25 14:30:04.27 0jDIZWNk.net
>>690
より良いものが残る
当たり前
699:デフォルトの名無しさん
20/07/25 14:59:28.18 Lg+2ZtBy.net
じゃあJSは良いから残るのか。
700:デフォルトの名無しさん
20/07/25 18:31:03.23 kGS+eXd8.net
>>683
C#でもunityユーザーとかはマシだからC#erがガイジというよりはBlazorがガイジなんだろう
701:デフォルトの名無しさん
20/07/25 18:41:39.82 DiPEvk/l.net
JSガイジの断末魔
702:デフォルトの名無しさん
20/07/25 21:25:42.82 icwPneMN.net
JavaもVMで動かすなんて遅すぎるしクソとか批判されたが
C#含め普及していった。
Blazor、いやwasmもこれからpeformance改善されて
使う人が増えるのは間違いない
>>693
こうやってマシとか言ってる人はC#使えない人
703:デフォルトの名無しさん
20/07/25 21:30:14.29 ZlqyHRW3.net
煽りに乗りたいヤツはその思いの丈は全部こっちにぶちまけてやってくれ
【本命】Blazor スレ1【真打】
ｽﾚﾘﾝｸ(tech板)
704:デフォルトの名無しさん
20/07/25 21:35:09.44 icwPneMN.net
GmailはSPAらしいけどAngularか？
いくらJSがブラウザ内でBlazorより早いといっても
Gmailだと11MBもサイト開くたびにデータ通信してるように
とてつもなく無駄なことやってる
ダウンロードサイズ、時間を考慮すると
Wasmとあんまり差がないってことにもなる
Blazor WebAssemblyは2回目以降のデータ非常に小さい。
データ消費量が課金にもかかわってくるモバイル回線では
Gmailのように大量にデータ通信するサイトよりwasmのがいいんじゃないか
705:デフォルトの名無しさん
20/07/25 21:42:59.39 ZlqyHRW3.net
>>697
Googleでその手のフレームワーク使ってるサービスって意外とないんだよね
706:デフォルトの名無しさん
20/07/25 23:21:18.28 vIjhxGJs.net
BlazorプロジェクトマネージャーDaniel Roth「BlazorはJSよりも10倍遅く、スピード競争に勝つことはない」
今でも遅いのにブレキチのオナニーのためにBlazorでさらに10倍遅くさせられるGmail哀れｗｗｗｗｗ
707:デフォルトの名無しさん
20/07/25 23:46:07.69 icwPneMN.net
>>699
10倍遅いとか捏造しつこいな
chatでソースないのをいいことに捏造しまくり
708:デフォルトの名無しさん
20/07/26 00:32:01.45 qCaLfESG.net
>>700
JITの無いインタプリタでJSと同等の速度が出るはずないだろ
JITの有無で速度の桁がひとつ変わるとか普通だ
709:デフォルトの名無しさん
20/07/26 00:40:34.12 8c+LEo48.net
>>700
>>696
710:デフォルトの名無しさん
20/07/26 00:42:21.83 Lwmxod4b.net
AoTコンパイラはバスに乗り遅れちゃって早くて一年後♪
嗚呼、それでも「JSにスピード競争で勝つことはない」
ミジメｗｗｗ
Blazorすごい！→宣伝してる俺すごい！
しようと思ってたのにまさかBlazorがC#おじさんのミジメな境遇まで堕ちてくるとはねｗｗｗｗｗ
711:デフォルトの名無しさん
20/07/26 01:14:39.39 5rw0opQZ.net
つかこんなに
フロントエンド界隈のライブラリが乱立して
ビルド構築手順ががわちゃわちゃしてる状況は異常
もうHTML自体をバージョンアップした方がいい
HTMLに直でReactやVueやTS SASSとかを記述して
ブラウザネイティブで解釈できるようにするべき
Bootstrapもどうせみんな使うんだか初めから
HTMLの仕様内に組み込んどけ
712:デフォルトの名無しさん
20/07/26 05:35:40.74 wM09/xME.net
>>701
ソースなしでは信ぴょう性がないし
どうせそういうのは発言の切り取り
Blazor wasmはAOT compile実装の予定あるのだから
速度は大幅に向上する
Browser外ではC#のがJSより速いのだから
speedは十分にはやくなる
713:デフォルトの名無しさん
20/07/26 05:53:06.94 wM09/xME.net
>>704
こんな発言しちゃうのがスクリプトおじさん
セットで仕様化したらどれか失敗したら全部が失敗するだろ
あと必要なcodeだけloadするから無駄な通信が減るのも常識
bootstrapは使ってないサイトたくさんある
View(html)とlogicをセットで仕様化など狂気の沙汰
あとbuildが煩雑なのはうんこframework使ってるからだ。
ASP.net MVCとかならクオリティ高いのがセットになってる
SPAなんてやらずにASP.net Coreみたいなまともなweb framework使えでおしまい
95%のサイトはSPAの必要がない
714:デフォルトの名無しさん
20/07/26 07:13:59.04 pVqRHFCg.net
いいかげんCの民は別スレ行けよ
ここのスレタイ
Vue vs React vs Angular
だから
715:デフォルトの名無しさん
20/07/26 08:13:28.39 8c+LEo48.net
それにしてもAngular使ってるサイトだけは全然見つからないよね
Angular本家とお名前と去年の技術書展くらい(今年はReactに変わってた)
716:デフォルトの名無しさん
20/07/26 08:52:05.09 kppqwmU4.net
WebAssembly使えばこういう問題も回避できるの？
Apple、プライバシー問題のため16ものWeb APIのSafariへの実装を拒否
URLﾘﾝｸ(css-tricks.com)
Appleが実装拒否したAPI一覧:
- Web Bluetooth
- Web MIDI API
- Magnetometer API
- Web NFC API
- Device Memory API
- Network Information API
- Battery Status API
- Web Bluetooth Scanning
- Ambient Light Sensor
- HDCP Policy Check extension for EME
- Proximity Sensor
- WebHID
- Serial API
- Web USB
- Geolocation Sensor (background geolocation)
- User Idle Detection
717:デフォルトの名無しさん
20/07/26 09:16:46.95 J91SE58H.net
>>709
Webはこんな方向に進もうとしてるのか
もはやプラットフォーム（OS）だな
そのうちベアメタル（直接ハードウェア）にインストールできるWebブラウザーとか出てきそう
718:デフォルトの名無しさん
20/07/26 09:34:24.57 2YJHPn7i.net
>>709
ブラウザベンダが実装拒否してるんじゃJSかwasmは関係なく無理だ
もしできるならセキュリティホールだし
719:デフォルトの名無しさん
20/07/26 09:42:00.76 2YJHPn7i.net
ブラウザがなんでもできるようになったらappletやactivexの時みたいにセキュリティ事故が相次いで
何処かの団体がセキュアなもののみを選択したAPIセットを発表して
そのAPIセットを実装したセキュアブラウザみたいなのが登場して
みんなそっちに乗り換えて
需要がなくなった多機能ブラウザは廃れて
すべてが最初に戻る
720:デフォルトの名無しさん
20/07/26 09:59:58.67 8c+LEo48.net
まぁブラウザAPIは基本的なもの以外はサイト毎にそのAPIの実行権限をユーザーが許可するかどうかっていうのが大前提なんだけどね
721:デフォルトの名無しさん
20/07/26 11:36:06.50 J91SE58H.net
もうやってることがbrowse（拾い読み）の域を超えてるね
722:デフォルトの名無しさん
20/07/26 11:36:26.24 mCc1k6Br.net
>>704
同意
もっと言うとHTMLなんか無くした方がいいよね
723:デフォルトの名無しさん
20/07/26 11:42:58.77 C7Nh/5jG.net
>>712
本当にこうなったら笑う
724:デフォルトの名無しさん
20/07/26 12:36:40.14 wM09/xME.net
SPAの特徴まとめてみた
開発の時間とコストが大幅に増える
初期のローディングにかかる時間が増える
SEOの面で不利になる
開発者が少ない
外注する場合にコストが増える
セキュリティが低下する
メリットは高速なページ遷移が可能なことだが
逆に言えばそれが不要ならSPAは必要ないな
むしろコストアップや初回読み込み遅延などのデメリットが上回ってしまう
725:デフォルトの名無しさん
20/07/26 12:43:20.43 kHoCQhob.net
> メリットは高速なページ遷移が可能なことだが
これ体感したことある？
726:デフォルトの名無しさん
20/07/26 13:05:55.45 WcA1r3qH.net
静的HTML+API+Vueの素朴なマルチページ構成がバランスいい
727:デフォルトの名無しさん
20/07/26 13:09:44.19 wM09/xME.net
>>718
画面全体をロードせず、必要な部分を
読み込むので高速になる、と一般的に言われてる。
アプリっぽく軽快に操作できないと困るサイトなら必要だけど
実際のところそこまで素早く操作が必要になるweb appはない気がする。
本当に快適にしたいならnatvie appしかないわけで
SPAは位置づけが微妙、手間とコストかかるわりに微妙すぎじゃないか？
FacebookがSPAで有名な事例だろうけど嫌いだから使わない
728:デフォルトの名無しさん
20/07/26 13:37:49.50 wgRaBi9V.net
SPAはWEBアプリケーションを作るための物であってWEBサイトを作るための物ではないからな
結局は使い分けだよ
�
729:｢界に向けて情報発信するならWEBサイトが基本だからSPAの採用実績が少ないのは仕方ない 複雑になりがちな社内アプリケーションなどは今後はSPAが主流になっていくだろう
730:デフォルトの名無しさん
20/07/26 13:54:45.15 r3Yqqk7H.net
>>717
SSRかSSG使えば初期ローディングとSEOの懸念事項は無くなるんでないかい
Googleだけに関して言えばJSも読んでくれるらしいからSPAでもSEOに関しては問題ない
731:デフォルトの名無しさん
20/07/26 14:27:11.75 BK/V/n6o.net
SPAは自分がユーザーの立場になってみると思ったより使い難いんだよね
732:デフォルトの名無しさん
20/07/26 14:43:43.07 w6lN3yjx.net
全ページSSRにしたらJSが無くても使えるしね。
SPAは便利だね。
733:デフォルトの名無しさん
20/07/26 14:46:29.68 XdP3besl.net
業務系システムとSPAは相性がいい
業務系では複雑怪奇なUIを求められることが多い
そして業務系と言えばJavaかC#
Javaは廃れ行く運命だがC#にはBlazorがある
業務系はもう全部Blazorでいんじゃねえの
734:デフォルトの名無しさん
20/07/26 15:27:13.88 J91SE58H.net
やっぱ業務系か
SPA需要ってPCありきかなと感じていたんだ
Android/iOSならSPAにこだわらずネイティブAppにしちゃったほうがユーザビリティ高いよね
そう考えるとモバイルファーストが謳われてる現在、SPAは下火になっていくのだろうか
735:デフォルトの名無しさん
20/07/26 15:36:09.11 8c+LEo48.net
SPA自体PWAありきなんじゃない？
736:デフォルトの名無しさん
20/07/26 15:50:04.51 3eREBna8.net
非SPAの採用実績と比較したらSPAの実績なんてカスみたいなものだろうね
そしてこれから先もそんなに伸びることはないと思う
そもそもSPAを導入したら何か大きな恩恵を得られるかっていうとほとんどのサイトがいやー別にそれほどでも…って感じでしょ？
糞言語のJSに縛られてSPAを導入するぐらいなら、使い慣れたPHP、Ruby、Pythonでサクッと非SPAで作っちゃったほうが安くて、品質もいい
ということでSPAの生存戦略として、業務系にフォーカスするってのは有効だと思う
今のところBlazorだけが唯一そっち方面で流行しうる下地を持ったSPAフレームワークと言っていい
業務系ではJSもTSも蛇蝎のごとく嫌われてて人材が足りないから、業務系で既存SPAフャ戟[ムワーク三試墲ﾌ生き残りは血ｵしい
Blazorがうまく行ったら、Javaが後追いでパクリを出してくるだろうね
そしたらまた、勢力図が変わるかもしれん
737:デフォルトの名無しさん
20/07/26 15:51:12.91 wM09/xME.net
>>721
Web siteを作るのにSPA framework使ってる人は
ほぼいないしいたらアホでしょう
Web app限定の中でも95%以上はSPA必要ないだろうってこと
>>717のデメリットがメリットを上回る
738:デフォルトの名無しさん
20/07/26 15:55:43.15 J91SE58H.net
Googleが期待したほどSPAは盛り上がらなかったね
それで結局ChromeOSも方針転換してAndroidアプリ・Linuxアプリがインストールできるという流れになってしまった
でもVSCodeのようなWeb技術をベースにしたネイティブアプリも人気があるんだよね
Web技術はマルチプラットフォーム対応アプリを作るのには向いているのかも
739:デフォルトの名無しさん
20/07/26 15:59:33.53 wM09/xME.net
>>721
最終行
業務用のweb appはASP.net系シェアが圧倒的だし今後も変わらない。
ASP.net系は開発生産性が高い
長期でMSがセキュリティとかのパッチ出してくれる
だからASP.netは法人に選ばれる
Windows PC限定にしてWPFとかのnative appだけで作るのもあり
開発スピードが最速になるしUXも最高レベルになる
社内限定ならcross platformなんていらないし
740:デフォルトの名無しさん
20/07/26 16:02:26.11 cZIElTbP.net
ActiveDirectoryに縛られて惰性で使ってるだけ
741:デフォルトの名無しさん
20/07/26 16:06:32.34 wM09/xME.net
>>722
SSR使ったら高速なUXというSPAの数少ないメリットが
失われるちゃうわけでしょ
SEO必要なら最初からSPAは使う必要ないんじゃないかって話になる
無駄に開発コストが増えるだけ損
742:デフォルトの名無しさん
20/07/26 16:11:06.69 wOzQ8kCZ.net
>>731
ふーんJavaよりシェア大きいんだ
俺もネイティブは楽で高品質だから、良いと思うけど、
従業員への配信がめんどくさくないかい？
743:デフォルトの名無しさん
20/07/26 16:13:52.38 wM09/xME.net
>>726-727
SPA調べてまさにそのSPAの中途半端さに気付いた
UXも開発スピードもNative appが最強だから
業務系ならnative appだけもあり
SPAは開発のコストと時間かかるわりにUX改善はたいしたことない
しかもサポート期間が短くメンテナンスも金がかかる
744:デフォルトの名無しさん
20/07/26 16:17:08.52 cZIElTbP.net
blazor wasmで殴りこんで来て今度はネイティブアプリって
マジで何しに来たんだ
745:デフォルトの名無しさん
20/07/26 16:23:42.24 2YJHPn7i.net
>>735
ネイティブと比べた時のBlazorの利点はセキュリティと配信しやすさ
サポート期間と開発生産性はマイクロソフトだから心配してない
746:デフォルトの名無しさん
20/07/26 16:27:20.70 wM09/xME.net
>>734
WindowsならGroup policyとかのシステム管理機能で
Applicationの自動インストールとかできるしdeployは楽だよ
JavaはORACLE所有になってライセンス実質有料になったし
ますます下火になるでしょう
747:デフォルトの名無しさん
20/07/26 17:35:09.81 zlLRIuAw.net
SPAフレームワークが使えないんじゃなくてオメーらゴミエンジニアが使えるレベルに達していないだけな
748:デフォルトの名無しさん
20/07/26 18:00:38.42 ZAj9kjW9.net
どっちにしても、今のSPAフレームワーク使っている奴ならこれからwasmやblazorとかが台頭してきても
それらが使い物になってから手を出しても全然遅くないだろう。
今phpやrailsとかで食えている人ならそもそもwasmに手を出す必要性すらないかもしれない。
749:デフォルトの名無しさん
20/07/26 18:03:22.00 2YJHPn7i.net
使うなら使うで問題ないが、使う価値があるか、は全く別の問題だからなぁ
バカだったら、なんか知らんけど新しいもの、ぐらいの軽い気持ちで採用しちゃんだろうけど
750:デフォルトの名無しさん
20/07/26 18:08:17.16 8c+LEo48.net
>>740
WordPressで済むようなWebサイトにJSフレームワークを入れるのが非効率なのと同様
一般的なWebにwasmなんて不要なはずなんだよ
canvasにゴリゴリレンダリングする様な演算回数が多い様な場合とかそういう場合だよね必要になるとすれば
751:デフォルトの名無しさん
20/07/26 18:10:19.01 pVqRHFCg.net
>>733
> SSR使ったら高速なUXというSPAの数少ないメリットが
失われるちゃうわけでしょ
失われないよ
SSRの仕組みは下記記事分かりやすいからおすすめ
URLﾘﾝｸ(qiita.com)
> SEO必要なら最初からSPAは使う必要ないんじゃないかって話になる
無駄に開発コストが増えるだけ損
同じこと書くけどGoogleに限ればSPAでもSEO的に問題ない
それにSSR・SSGなら他検索エンジンでもSEO的に問題ない
GoogleはJSを読んでくれるっていうのも結構前の話だから、今は他検索エンジンでもOKなやつあるかも
752:デフォルトの名無しさん
20/07/26 18:12:53.56 pVqRHFCg.net
YahooもGoogleのエンジン使ってるみたいだから多分YahooもSPAでSEO的におけやね
753:デフォルトの名無しさん
20/07/26 19:08:50.21 aJKoeTZN.net
SPAでもSEO的に問題ないんじゃなくて
SEO的に問題ないSPAを使うべきだよ
SPAが高速っていうのは2ページ目以降の話で
1ページ目は結局全体を読み込むんだから
静的ページとほぼ同じものをサーバー側から返すようにするべき
そうしないとJavaScriptの処理でレンダリングが遅くなる
2ページ目以降は速いなると言うがGoogleのクローラーなんかはページ読み込みの
タイミングはバラバラなので2ページ目以降も1ページと同じように読み込む。
そうするとSPAの速いっていうこうかがなくなる
ページ読み込みの速さもSEOで重要なので、どのページを最初に読み込んでも
JavaScriptなしで表示されるようにするのが正しいやり方
754:デフォルトの名無しさん
20/07/26 19:09:51.27 aJKoeTZN.net
ようするに2ページ目以降JavaScriptあり（SPA）で表示する
1ページ目JavaScriptなしで表示する
これを実現するためにSPAでサーバーサイドレンダリングは必須なの
755:デフォルトの名無しさん
20/07/26 19:15:51.29 BJnciPIh.net
SEOを考えるような内容のサイトでSPAが効果的な物って例えばどんな物がある？
pgadmin4のような高度なappならSPAが効果的って主張は理解できる
だけどqiitaのようなsiteにSPAを使うメリットは無いと感じた
伝統的なsiteの振る舞いと異なるから直感的な操作感で言うとマイナスまでありえる
756:デフォルトの名無しさん
20/07/26 19:16:05.21 8c+LEo48.net
寧ろSEOが必要ない様な利用者が限られる部分に使うべきなんだよ
EC的なものなら確かにシステム的な側面とSEO的な側面の両方が必要だけど
それ以外のシステムならそもそもトップページ以外検索エンジンにヒットする必要ないものって結構多いはず
757:デフォルトの名無しさん
20/07/26 19:22:21.71 1X4Tbs5Z.net
SS
758:デフォルトの名無しさん
20/07/26 19:25:42.98 1X4Tbs5Z.net
SSRはバックエンドのリソース消費量が増えるから嫌だな
クラウドだとコストにも響いてくる
759:デフォルトの名無しさん
20/07/26 19:27:42.35 ydM4arRa.net
>>747
ないと思うよ。だからReactとかvueとかの
ウェブアプリ用フレームワークはjQueryの代替にはならないし
ウェブサイトがウェブアプリに作り変えられることもない
俺がもう5年ぐらい前に出した結論
そしてこの5年のjQueryのシェアの増え方と
フレームワークのシェアの増え方を見ればそれが
正しかったと証明されてる。
760:デフォルトの名無しさん
20/07/26 20:02:03.99 BYN8HZ/f.net
しかしそう考えると、学ぶべきフレームワーク、人気のフレームワークといった文句でSPAフレームワークが紹介されるのはなぜなんだろう？
そんなに人気があるなら、採用するサイトも増えるはずだけど、ほとんど見かけない
SPAフレームワークを覚えた人は何処で働いていて、どんな成果物を残したのか？
このスレの人の手がけた公開サイトがあるなら、ぜひ知りたい
761:デフォルトの名無しさん
20/07/26 20:22:09.40 zlLRIuAw.net
業務用Webアプリの開発に使うからだろ
Webアプリ作れないゴミエンジニアは格安だから使えなくていいんだよ
762:デフォルトの名無しさん
20/07/26 20:24:15.75 0MyKPfk8.net
業務用アプリだとC#のほうがいいね
763:デフォルトの名無しさん
20/07/26 20:26:03.01 pVqRHFCg.net
>>752
SaaSで使われまくってるよ
てか求人サイトでフレームワークの名前で検索するといっぱい出てくる
静的なWebサイトだとツールのドキュメントとかコーポレートサイトでちょくちょく見かけるかな
SasSでもWebサイトでも無い感じのやつだとTwitterとかYahooとかPixivとか
764:デフォルトの名無しさん
20/07/26 20:29:12.45 zlLRIuAw.net
>>754
裏は好きなの使えばいい
765:デフォルトの名無しさん
20/07/26 20:52:24.56 8c+LEo48.net
>>752
見かける見かけないってそもそもブラウザにインジケーターアドオン入れてから言ってくれよ
どうせ入れてないんだろ？
766:デフォルトの名無しさん
20/07/26 22:06:58.75 6PuC7aMz.net
ふーん
で、何割ぐらいのサイトでSPA使われてんの？
767:デフォルトの名無しさん
20/07/26 22:49:08.46 rfO/oa4K.net
誰も知らないだけでたくさん使われてるよ
768:デフォルトの名無しさん
20/07/26 22:51:16.76 J91SE58H.net
誰も知らないことをなんで知ってるの？
769:デフォルトの名無しさん
20/07/26 22:53:37.55 zlLRIuAw.net
ゴミサイト含めたら圧倒的にほんの少しだろ
そんなにゴミサイトが気になるなら一生気にしていればいい
770:デフォルトの名無しさん
20/07/26 23:03:35.73 iYDWpAIp.net
なんでそんなにSPAを敵視すんの？
771:デフォルトの名無しさん
20/07/26 23:06:58.57 Lwmxod4b.net
自分が分からない・作れない技術が普及したら恥ずかしくて困るから。
それに対するアクションがこんな辺鄙な場所でジタバタ足掻くこととはねｗ
こりゃ仕事できませんわｗ
772:デフォルトの名無しさん
20/07/26 23:10:26.86 8c+LEo48.net
寧ろ
・Wappalyzer
・React Developer Tools
・Vue.js devtools
・Augury
これらの拡張機能(アドオン)を入れずにどうやってないって判断してんだよ
773:デフォルトの名無しさん
20/07/26 23:11:26.10 tvVrKRgD.net
敵視はしてないが純粋に疑問なんだ
これがどれほど役に立つのか
噂に聞くほどの実績が本当にあるのか
今のところそれほど有用ではなさそうだなといった感想
それを覆すほどポジティブな意見が見られない
774:デフォルトの名無しさん
20/07/26 23:21:06.77 ZAj9kjW9.net
そのプログラミングモデルを自分で気に入るか気に入らないかでいいと思うがねぇ。
自分に合わないと思うなら別に使わなくていい。
775:デフォルトの名無しさん
20/07/26 23:31:12.58 zlLRIuAw.net
現に俺様がSPAフレームワーク使って業務アプリ作りまくってるんだからこれが正しいんだよ
SPAフレームワーク使わなかったらもっと開発に時間かかる
さらに実際の業務にも時間がかかるようになる
オメーが知らねえだけで世界を知った気になるな
776:デフォルトの名無しさん
20/07/27 00:08:34.56 Ri9S2nsL.net
フレームワーク自慢程反吐が出るものは無い
フレームワークは何でもそうだけど
フロントサイドだったら
必ずしも全員がHTMLや
CSSの仕様を完璧に理解している訳では無い
View層は特にやり方に絶対の正解がない
DBMSみたいなカッチリとしたデザパタはない。
フレワなしの純粋なHTML CSS
JavaScriptだけなら最初から全てを知っている必要なくて
必要なところだけ即興でググって記述することで
細かな調整ができるけど
フレワでそれを隠蔽したら
頭の中にCSSやHTMLの仕様を完璧に知っている必要がある
まずググるのが難しくなる
必要な箇所だけ自力で修正する事が難しくなる
フレワが自動生成するコードが増えるほど
DevToolsでの解析が難しくなる
自動生成されたclass属性のどれがどんな効果を持っていて
DOM要素にどのような影響を及ぼしているのかの
推測が立てにくくなる
そしてそれを頭の中に完璧に理解してる人間なら
HTMLやCSSや普通のJavaScriptを書いた方が早い
新たにフレワの文法を覚えるのが馬鹿馬鹿しい。
フレワが何種類も乱立してたらなおさらだ。
777:デフォルトの名無しさん
20/07/27 00:15:47.58 b6SXhPTe.net
>>768
オメーがゴミなだけだろ
htmlとcssができないってどんだけ低レベルなんだよ？
デブツールみてわからんとかゴミクズじゃん
とにかくできない奴が声高々に吠えるな
ここにきちんとできている俺様がいるのにゴミが勝手に決めつけんじゃねえよ
778:デフォルトの名無しさん
20/07/27 00:21:48.49 c0Q45HfR.net
>>769
スマンな俺もUI/UXのフレームワークに頼りっきりでCSSは微調整以外は碌に書けん
779:デフォルトの名無しさん
20/07/27 00:23:19.80 vIJ2AS+M.net
このスレはいつみても
どうでも良いことで
盛り上がってんな
780:デフォルトの名無しさん
20/07/27 00:38:02.84 rA5gK0Vx.net
外部向けサイト⇒SPAより非SPAのが向いてる
社内向けサイト⇒人材と既存資産が豊富なC#が有利⇒Blazor
781:デフォルトの名無しさん
20/07/27 00:42:11.06 UrkoV9IC.net
>>765
？
Webアプリ作るなら今のところ最適解がSPAだろ？
なんで化石も含めて大量にあるWebサイトの中でどれくらいの割合使われてるか知りたいの？
782:デフォルトの名無しさん
20/07/27 00:44:08.53 PSP0suJc.net
> Webアプリ作るなら今のところ最適解がSPAだろ？
たまたまSPAになってるだけだと思うけどな
通常はAjaxで十分だと思うよ
783:デフォルトの名無しさん
20/07/27 00:46:12.83 c0Q45HfR.net
>>773
スマホを視野に入れたPWAならSPA構成でいいと思う
784:デフォルトの名無しさん
20/07/27 00:49:34.50 PSP0suJc.net
PWAとSPAにどういう関係があるの？
785:デフォルトの名無しさん
20/07/27 00:50:57.41 b6SXhPTe.net
ゴミクズの知識の薄さがやべえな
786:デフォルトの名無しさん
20/07/27 01:18:09.78 PSP0suJc.net
流れをぶった切って悪いけど、SPAでレスポンシブに
対応したフレームワークって何がある？
787:デフォルトの名無しさん
20/07/27 01:20:38.79 sZwTyFBE.net
>>773
最適じゃないからPHP、Ruby、Pythonなどの伝統的なフレームワークが選ばれる
SPAは僅かな領域だけでしか通用しない
788:デフォルトの名無しさん
20/07/27 01:29:33.69 c0Q45HfR.net
>>778
Bootstrapでも入れたらいいんじゃないか？
BootstrapVueでもReact BootstrapでもNative JavaScript for Bootstrap本家Bootstrap5αでも選択肢は選り取り見取り
789:デフォルトの名無しさん
20/07/27 01:32:36.13 PSP0suJc.net
でもBootstrapはDOM操作をするだろ？
そうするとフレームワークと一緒に使えない
790:デフォルトの名無しさん
20/07/27 01:37:23.48 c0Q45HfR.net
>>781
上に挙げてるが
BootstrapVueやReact Bootstrapのようにフレームワークに特化したパッケージもちゃんとある
791:デフォルトの名無しさん
20/07/27 02:16:55.64 o3qaYBwJ.net
>>781
わろたｗｗｗ
792:デフォルトの名無しさん
20/07/27 02:31:44.31 TfnjDE3E.net
>>778
スレタイのうちどれ使ってるの？
ReactならChakraUI超オススメ。
793:デフォルトの名無しさん
20/07/27 05:19:08.57 P2Gsimd7.net
Rails + React + Bootstrap
Bootstrap は、CSS/SASS を知らなくても、簡単に見た目を整えられるから、
GUI に弱い、サーバー側開発者にとって必要
Rails 6.0 からは、Webpack が標準になったから、Node.js も必須
API モードもある。
描画せず、JSON だけで、やり取りする
794:デフォルトの名無しさん
20/07/27 06:55:20.10 UFheIHQs.net
>>765
お前のその疑問に>>755が答えと探し方、>>764が確認の仕方を書いてくれてるやん
その感想が探してない、確認していない、認めたくない、ってことの証明になってるよ
795:デフォルトの名無しさん
20/07/27 07:43:46.66 Mg1HGRsd.net
>>786
>>755
使われまくってる⇒子供か
いっぱい出てくる⇒子供か
ちょくちょく見かける⇒子供か
求人サイトで～⇒求人に乗ってる情報なんて極々僅かな割合でしかない
Twitterとか～⇒事例たったの3つしか挙げられないのか
>>764
アドオン～⇒ウェブ全体を走査する方法がわからねえだろ少しは考えてレスしてくれ
796:デフォルトの名無しさん
20/07/27 08:15:16.74 c0Q45HfR.net
そもそも>>752が見かけないっていうから
どうやってない事を確認したんだ？って話じゃん
797:デフォルトの名無しさん
20/07/27 10:42:39.38 7YZXD5wT.net
ぶっちゃけてしまうとね
コンサルの養分です
798:デフォルトの名無しさん
20/07/27 12:14:51.29 q4lb5yU9.net
SPAの短所いろいろ書いてSPAって必要なの？って書いたら
批判、炎上するかと思ってたけど予想外にそうならなかった。
SPAに興味ありつつもSPAで開発経験ある人少ないってことだな
SPAは短所もあるからSPAのframework決める前に
SPAでやるかどうかをしっかり考えて決めるべきだと思う。
明らかに向かない用途ってある
SEO以外にもセキュリティ低下とか、開発工期、コスト上昇
JS-SPAなら短いサポート期間とか
799:デフォルトの名無しさん
20/07/27 12:35:21.60 cUoRU5UD.net
SPAは目的じゃないからね
ページの一部を動的に変更するならただのJavaScriptでいいし
全体に近いぐらい変更するならページ移動しても大差ない。
それに下手するとSPAにすることでユーザビリティが低下することがある
例えばURLをブックマークに入れてもそのページにたどり着けなかったり
ブラウザの進む、戻るがまともに機能しなかったりする
ユーザビリティの設計は難しくなるのにその設計をしないで
フレームワークを使ったからSPAになりました。
なにも工夫してないけどSPAなら速くなってるんでしょ？なんて
適当にやってる人が大半
ゲームやフォトショップみたいにアプリ（ウェブアプリ）を起動して
そこからデータファイルを読み込んで編集するツールならいいけど
ページ移動が行われるようなSPAはページ設計が重要になってくるのに
それを理解していない
800:デフォルトの名無しさん
20/07/27 12:36:04.26 q4lb5yU9.net
>>743
SSRだと更新は差分のみだから速いっていう主張だと思うけど
serverもUAも負荷が高くなければページ全体の更新でも
高速にレンダリングできるでしょう
UA側はPCはもちろん2万円の中華SPでもサクサクページ全体を開ける性能ある。
server側の性能さえ十分確保すれば差分更新かページ更新かは
あんまり問題にならないと思う
801:デフォルトの名無しさん
20/07/27 13:14:37.14 q4lb5yU9.net
>>764
Wappalyzer
Firefoxにいれてみたけどおもしろいな
大手でもSPA web frameworkの採用の少なさに気付いた
React人気と言ってる人多いがReact系のweb frameworkはあまり使われてない
ただのUIのライブラリとしてReactを使ってるだけってところばかり
Twitterもそう
>>708
Googleが作ったというにAngular自社で使ってないのが笑えるな
YouTubeはPolymerしか検出されない
Google MapもSPA framework使ってない
Vanilla JSでゴリゴリ書いてるんだろうな
802:デフォルトの名無しさん
20/07/27 13:19:03.18 b6SXhPTe.net
WebサイトみてReactとか使われていないとかいうゴミがいたらオメーの認識が未だに改まってねえからさっさと治せとしか言えない
803:デフォルトの名無しさん
20/07/27 13:21:55.01 hYUf9ncg.net
>>794
誰もReact使ってるサイトがゼロとは言っていない。
React使ってるサイトは0.4%程度だと言ってる。
804:デフォルトの名無しさん
20/07/27 13:24:09.61 FyobjYdi.net
ExtJS 使ってた人居る？
805:デフォルトの名無しさん
20/07/27 13:28:57.64 q4lb5yU9.net
>>781
メジャーなframeworkで
bootstrap使えないやつないんじゃないか
806:デフォルトの名無しさん
20/07/27 13:43:11.84 DcqVOXlA.net
だから言ったじゃん
コンサルの養分なんだよキミタチ
807:デフォルトの名無しさん
20/07/27 13:47:44.32 Rr+dRFNS.net
>>792
SSRはサーバー負荷めちゃ高まるから嫌だ
このサーバーレスの御時世では最悪の選択肢1つと言って過言ではない
だいたいサーバーサイドに状態を持たせるとか大昔に逆行してるし
808:デフォルトの名無しさん
20/07/27 13:52:43.84 TfnjDE3E.net
つまりGatsby最高！
う～んマンダムｗｗｗ
809:デフォルトの名無しさん
20/07/27 13:56:40.28 hYUf9ncg.net
>>799
サーバーサイドに状態を持たせないで作れるものを言ってみ
例としてオンラインゲームは無理な
810:デフォルトの名無しさん
20/07/27 14:01:10.49 Rr+dRFNS.net
>>801
なんでもいいよ
セッション持たないRESTな設計なんて今どき珍しくもない
メモリキャッシュとか言い出しそうだから予め言っとくが
これは高速化のためであってSSRのようにしかたなくリソース食いつぶすゴミとは真反対だからな
811:デフォルトの名無しさん
20/07/27 14:04:19 S26P/GM8.net
> セッション持たないRESTな設計なんて今どき珍しくもない
HTTPはセッション持たないじゃなくて持てないんですが？
あれあれ？すべてのウェブサイトはサーバーサイドに
状態を持たないって話でいいですか？ｗ
812:デフォルトの名無しさん
20/07/27 14:08:52.18 S26P/GM8.net
セッション持たないRESTってなんですかね？
どのユーザーでも同じデータ返すって言ってるんですかね？ｗ
813:デフォルトの名無しさん
20/07/27 14:16:28.42 O6ncpH5Z.net
>>804
バカかな
状態持たなくてもリクエスト（パラメータ）に応じて結果変えられるじゃん
RESTではこれが基本
セッションオブジェクトはあまり使わない
814:デフォルトの名無しさん
20/07/27 14:19:17.79 S26P/GM8.net
>>805
セッションオブジェクトはリクエスト（パラメータ）に応じて結果変えてるので
サーバーに状態は持っていません
はぁ、仕組みを知らないんだな
フレームワークばっかり使ってるから
そういうアホなこと言うんやで（笑）
815:デフォルトの名無しさん
20/07/27 14:20:28.76 S26P/GM8.net
>>805
あとはURLにセッションIDを入れる方式は
セキュリティ的に脆弱なもの扱いだからな
そんなもの提案したら素人だってバレるでｗ
816:デフォルトの名無しさん
20/07/27 14:21:53.57 O6ncpH5Z.net
ん？なんか俺おかしなこと言ったか？
817:デフォルトの名無しさん
20/07/27 14:24:54.73 S26P/GM8.net
言ってますねｗ 気付いて無いんですねｗ
HTTPの仕組みを知ってるのであれば
状態をもたせるやり方を言ってみ
818:デフォルトの名無しさん
20/07/27 14:29:25.84 O6ncpH5Z.net
サーバーにセッションオブジェクト（メモリ）を確保する
セッションオブジェクトに対してセッションIDを発行する
セッションIDリクエストパラメーターやクッキーで維持される
クライアントは複数のリクエストに渡って同じセッションIDをサーバーに渡すので
サーバーはクライアントのリクエストの連続性（セッション）を認識できる
またセッションIDからセッションオブジェクトを引くことでセッションの状態（情報）を継続利用できる
間違っとる？
819:デフォルトの名無しさん
20/07/27 14:30:08 S26P/GM8.net
>>810
RESTでも同じことをしてる
820:デフォルトの名無しさん
20/07/27 14:30:48.23 S26P/GM8.net
ああもしかして、セッションID＝リクエスト（パラメータ）だって知らないのかなｗ
821:デフォルトの名無しさん
20/07/27 14:31:03.28 S26P/GM8.net
セッションIDが魔法の技術とか思ってそうｗ
822:デフォルトの名無しさん
20/07/27 14:32:52.85 O6ncpH5Z.net
いやRESTはセッション使わない構成多いよ
REST＝関数のイメージ
引数に対して戻り値が返る
引数はリクエストパラメーター、戻り値はレスポンスね
RESTは一問一答で完了するパターンが多い
以前のREST呼び出しの内容な作用されない
だからセッションオブジェクトを使わないと言っている
823:デフォルトの名無しさん
20/07/27 14:33:59.07 S26P/GM8.net
URLﾘﾝｸ(itdoc.hitachi.co.jp)
REST APIでは、セッションを使用して、複数のリクエストを同一クライアントによる一連の操作として識別します。
824:デフォルトの名無しさん
20/07/27 14:34:05.80 O6ncpH5Z.net
セッションIDはリクエストパラメーターになることはあるけど
リクエストパラメーターがセッションIDということなはならんよ
825:デフォルトの名無しさん
20/07/27 14:35:55.62 O6ncpH5Z.net
/add?param1=123¶m2=456
この足し算RESTにセッション要るか？
このパラメーターがセッションIDなのか？
826:デフォルトの名無しさん
20/07/27 14:36:39.82 S26P/GM8.net
OWASPの"REST Security Cheat Sheet"ではただ一言。「セッションベースのユーザ認証を使え」と書いてある。
URLﾘﾝｸ(www.glamenv-septzen.net)
ユーザ認証にはセッション管理を使え、とあり、さらに、セッションIDやAPIキー、ログインIDとパスワード、
トークンなどはURLに含めるな、ともある。
他にもこのページにはRESTスタイルで開発するときのセキュリティ上の注意点が解説されている。英語になるが、
内容的には普通のWebサイトと同じように入力チェック＋出力時のJSON/XMLに合わせたエンコーディング、
CSRF対策などをしてください、という流れ。
また以下のページは、逆にRESTなWeb APIを診断する、pentester向けのガイドとなっている。
クロールできたURLだけでは、全部のREST APIの機能を見れたことにはならない可能性があるので、
ソースコード診断（ホワイトボックステスト）も可能なら実施したい、などとあり、参考になる。
827:デフォルトの名無しさん
20/07/27 14:37:32.58 S26P/GM8.net
>>817
だからオンラインゲーム無理ってことですねｗ
828:デフォルトの名無しさん
20/07/27 14:38:15.39 ffgSx4MU.net
>>800
最近Next触り始めたけどドキュメントにやたらSSG推してたから、あながちGatsby最高マンダムなんかもなと思うわ
GatsbyはでもGraphqlと結びついとるから気軽にカスタマイズしようとしたらエラー吐きまくる
829:デフォルトの名無しさん
20/07/27 14:38:36.28 S26P/GM8.net
>>817
クライアントだけで実装できるものしか
作れないと言ってます。
お前のやり方ではログインが必要なものは作れません。
オークションサイトは作れないし
ブログの管理をすることもできません。
830:デフォルトの名無しさん
20/07/27 14:39:56.60 Rr+dRFNS.net
>>803
ド素人がセッションも知らないのか？
CookieにセッションIdメモってサーバーサイドオブジェクトと紐付けるんだよ
831:デフォルトの名無しさん
20/07/27 14:41:27.35 S26P/GM8.net
>>822
お前の理屈は、クッキーの代わりにパラメーターでセッションIDを渡せすという
セキュリティ的に脆弱なセッション管理を実装すれば
サーバーに状態は持ってないことになるんやろ？ｗ
アホやなぁと言ってる
832:デフォルトの名無しさん
20/07/27 14:42:38.43 O6ncpH5Z.net
>>821
だからSPAのバックエンドにRESTが適してるんだよ
SPAならクライアント側で状態を持てるんだからサーバー側は関数でいいの
サーバーがセッション管理から解放される
これもSPAのメリットと言えるかもしれないね
833:デフォルトの名無しさん
20/07/27 14:43:20.19 S26P/GM8.net
もしかしてパラメーターのキーの名前がsession_idじゃなかったら
サーバーサイドに状態を持たせてないことになるとでも思ってるのか？ｗ
834:デフォルトの名無しさん
20/07/27 14:44:06.24 S26P/GM8.net
> SPAならクライアント側で状態を持てるんだからサーバー側は関数でいいの
え？ URLにパラメータとかユーザー名とかパスワードを入れればいいんだから
SPA関係ないじゃんｗ
835:デフォルトの名無しさん
20/07/27 14:45:41.88 S26P/GM8.net
クッキーを使えばクライアントに状態を持ってる！
例えばセッションIDをクッキーに入れておけば、
ウェブサイトにアクセスしたときにログインしたことになる！
JavaScriptも不要！古くから使われてるログインの仕組みだ！
みたいな話をされてこ困るんだよなぁ（笑）
836:デフォルトの名無しさん
20/07/27 14:48:59.96 S26P/GM8.net
クライアントにしかデータを持ってないと
別のパソコンでログインしてもデータが見れなくなる（笑）
まあそれでいいなら普通のウェブサイトのほうがいいだろうねｗ
HTML+CSS+jQueryで
837:デフォルトの名無しさん
20/07/27 15:03:07.49 Rr+dRFNS.net
アホのために説明してやるか
Cookieとサーバーサイドのオブジェクトの紐付けで擬似的にリクエスト間の状態維持を実現する手法がセッションな
従来のシステムではよく使われていたが思ったよりメモリ消費がバカになんねえなぁってことで今はもう廃れた
今どきのセッション管理はサーバーサイドのオブジェクトではなくCookieなどに暗号化したデータを含める方式で実装されている
そうすれば極僅かなCPUの負荷増でメモリ消費をぐっと抑えることができるようになる
リクエストに乗せたくない重大な機密や大きすぎるデータは永続化層で管理する
これがメモリに乗るのはデータ利用するその時とキャッシュされた時だけ
これでサーバーサイドのリソース効率がだいぶ良くなった
ついでにいうと水平スケールもしやすくなって一石二鳥
SSRはこの時代の流れに逆行してサーバーサイドに大量の状態オブジェクトを生成してクライアントと紐付けて管理するという愚行をおかしてしまっている
SSRの特性上どうしてもﾋビューに関するほとんどの状態をサーバーのメモリ上に確保してクライアントが去りゆくまでずっと維持し続けなければならない
これがどれだけリソース効率が悪い邪悪なアーキテクチャかは猫でもわかるだろう
クラウドファーストなこの御時世ではサーバーサイドのリソース増加はコストに直結する
こんな金食い虫のアーキテクチャではやってられんのだ
838:デフォルトの名無しさん
20/07/27 16:01:20.39 FzUtUUvl.net
>>793
ちなみにWappalyzerでは検知出来ないけどReact Developer Toolsなら検知されるパターンもある
多分Webpackの難読化の影響かとは思うが
Amazonの欲しいものリストのページやプライムビデオのページとかそんな感じ
839:デフォルトの名無しさん
20/07/27 16:11:00.85 A4vSpavl.net
>>797
AngularはMateri
840:al系が主流だからBootstrapの対応はあんま良くないな
841:デフォルトの名無しさん
20/07/27 16:18:49.53 SDAq9vDF.net
>>829
> 今どきのセッション管理はサーバーサイドのオブジェクトではなくCookieなどに暗号化したデータを含める方式で実装されている
その方式はデータが大量になったときに破綻するので
セッションIDぐらいしか入れない
842:デフォルトの名無しさん
20/07/27 16:20:12.25 SDAq9vDF.net
>>829
> SSRはこの時代の流れに逆行してサーバーサイドに大量の状態オブジェクトを生成してクライアントと紐付けて管理するという愚行をおかしてしまっている
SSRとは無関係
843:デフォルトの名無しさん
20/07/27 16:22:25.22 SDAq9vDF.net
URLﾘﾝｸ(ssr.vuejs.org)
従来の SPA (シングルページアプリケーション) と比べて、SSR の利点は主に次の点にあります:
・検索エンジンのクローラが完全に描画されたページを直接解析するため、SEO が向上します。
現在のところ、Google と Bing は同期的 JavaScript アプリケーションのインデックスを作成できます。
同期がキーワードです。あなたのアプリケーションが読み込み中にスピナが表示され、
Ajax 経由でコンテンツを取得する場合、クローラーはあなたが完了するまで待たないでしょう。
つまり、SEO が重要なページで非同期にコンテンツを取得する場合は、SSR が必要な場合があります。
・特にインターネットの遅さや遅いデバイスでは、コンテンツの再生時間が短縮されます。
サーバで描画されたマークアップは、すべての JavaScript がダウンロードされて表示されるまで待つ必要がないので、
ユーザは完全に描画されたページをすぐに見ることができます。これにより、一般的にユーザーエクスペリエンスが向上し、
コンテンツの所要時間が直接コンバージョン率に関連付けられているアプリケーションにとっては重要になります。
844:デフォルトの名無しさん
20/07/27 18:22:17.80 TfnjDE3E.net
>>820
たしかにたいていのことにプラグイン用意されてるからなんとかなってるけどじゃあ自分でgraphQL拡張するプラグイン作れと言われたらウッってなる。
845:デフォルトの名無しさん
20/07/27 19:12:49 UFheIHQs.net
>>835
Next使ってる？
Gatsbyと比較してそれぞれになんか思うことあったら教えてほしい
Next・Firebase・Stipe他でアプリ作ろうと思ってたけど、仰せの通りGatsbyはプラグインが充実しとるからGatsbyでええやん感が増してるわ
完成形に近いスターターに出会えればGatsbyの方が完成まで早そうやし
846:デフォルトの名無しさん
20/07/27 20:05:37.52 TfnjDE3E.net
ごめんNextは使ってない。
あれ基本サーバー側も含めた構成で全部静的配信したかった自分のSSGニーズと合わなかったしあまり検討しなかった。
Gatsbyとは違って個人ユースではなく企業サービスのビルディングブロックといった印象。いろいろいじる前提のプロ向けっぽい。
SSGモードも後付けされたけどだったらGatsbyでいいかなって。
ちなみに >>836 の strapiもfirebaseもプラグインあるね。
strapiのは試したこともある。特に困ることなかったｗｗ
847:デフォルトの名無しさん
20/07/27 20:06:31.68 CctcRh4x.net
全ページSSRにすればJSオフでも見れて快適ですね。
848:デフォルトの名無しさん
20/07/27 20:12:01.61 0Re8MG/Y.net
SSRした結果をファイルにキャッシュしておけば
静的ページとほぼ同じでサーバーの負荷も殆どないしね
849:デフォルトの名無しさん
20/07/27 20:48:34.75 u51QqKbm.net
SSRを使うよりトップページを静的なS3とかにしたら良くない？
SSLの関係とかで出来ないのかな
850:デフォルトの名無しさん
20/07/27 20:51:01.79 9y96d1KX.net
その静的なS3を作るのにSSRを使うんでしょ？
851:デフォルトの名無しさん
20/07/27 21:55:19.91 Ri9S2nsL.net
>>829
馬鹿はお前
パフォのためにコーディングの面倒さを犠牲にして
cookieみたいなヘッダいじったり
暗号化みたいな余計なことするくらいなら
メモリ倍くらいに増強してセッション使うわ
楽だからな。
ローバラがあるならセッションも諦めて全部
DBかローカルストレージのどっちか
とりあえずクッキーはない
852:デフォルトの名無しさん
20/07/27 21:59:13.37 fnBRfBHK.net
>>842
お前はもうちょっと世の中を見たほうがいぞ
REST APIはクッキーに暗号化してデータを埋め込む方式だ
どのREST APIもそういう設計になってるはずだ
853:デフォルトの名無しさん
20/07/27 22:13:05.38 q4lb5yU9.net
>>840
SEO気にするサイトはトップページだけ
indexされればいいわけじゃないと思うよ
854:デフォルトの名無しさん
20/07/27 22:17:35 fnBRfBHK.net
>>844
お前いつの時代のエセSEO業者だよｗ
SEOといったらページごとにテーマを決め
そのテーマに絞って内容を書くことでより多くのページを
検索に引っかかるようにするのが常識だろ
855:デフォルトの名無しさん
20/07/27 22:37:08 q4lb5yU9.net
>>845
なんなの？
2行つながってるわけだがトップページだけやればいいと誤解したのか？
そもそもweb appやSSRの文脈で「テーマに絞って内容を書く」ってアホじゃないの？
web appが動的に生成したpageをどうsearch engineにindexさせるかって話だろ。
staticなcontentsのSEOの話など誰もしていない
856:デフォルトの名無しさん
20/07/27 23:18:48.25 P2Gsimd7.net
Ruby on Rails では、未経験者が、1か月で作ったポートフォリオにも、ログイン機能はある
かよちんの動画
【ポイントは一つ】プログラミング未経験でも受かるポートフォリオの作り方
URLﾘﾝｸ(www.youtube.com)
ログイン、投稿、コメント、いいね、検索、マイページ機能
Rails + Bootstrap
Github, Heroku
857:デフォルトの名無しさん
20/07/28 09:14:18.81 KJ/jhVY+.net
>>675
草
Blazorおじおば涙拭けw
858:デフォルトの名無しさん
20/07/28 09:29:33 zKWFaExc.net
例えばユーザ認証するならFirebaseとか外部サービスに任せればいいだけだろ。。
ってか相変わらずスレチで伸びてるな。SPAって言葉が独り歩きしすぎだよ。
個人的にWEB開発者として重要な変化は、
・リアクティブ
・IDE(VSCode含む)による環境の統一やコード補完
・ホットリロード
この３点だろ。SPAだろうとSSR主体だろうと共通して劇的に楽になった。
あとは作りたいものに合わせてフレームワークなり言語選ぶだけだろ。
大手のサイトにフレームワークが導入されてないとか見たが、jQueryだけなんてサイトは案件的にありえない。
少なくともリアクティブでデータドリブン。どのライブラリを選定するかは大きな違いじゃない。
個々の要素は確実に進歩してるよ。
859:デフォルトの名無しさん
20/07/28 10:16:16.19 lvYKtUnl.net
でもほとんどのサイトがSPAだとオーバースペック、UX低下(非SSRの場合)、リソース消費量激増(SSRの場合)、人材不足だから非SPAを選んでるんだよな
複雑なUIをどうしても避けられない高度なSaaS、社内システムなど、ならSPAを採用するメリットはあるかもしれんが、そうでないならデメリットのほうが大きい
860:デフォルトの名無しさん
20/07/28 10:44:41.06 87VWo28p.net
>>849
SSRゴミカス野郎にリアクティブやらせたらデータと表示が一致させられなくて死ぬ
>>850
ゴミカス自称フロントエンジニアのゴミのようなUI/UXスキルはどうしようもないほど低レベル
コイツらにまともなUIを作れるわけがない
一生かかってもゴミセンスから抜け出せない
861:デフォルトの名無しさん
20/07/28 12:14:03.62 q6n5SbdD.net
VueとかNext.js使ってる人は
結局SPAとしては使わずに、SSRで使ってるということか？
862:デフォルトの名無しさん
20/07/28 12:19:12.90 Mb4DOiRz.net
やっぱ社内システムが正解か
863:デフォルトの名無しさん
20/07/28 15:27:54.67 zKWFaExc.net
>>852
SPA最大の利点はサーバの負担が軽い事だと思う。
フロントのためのロジック丸ごと省略できるから。
主に製作者側の都合なんだけどね。
例えば情報系サービスをスクラッチで作るとして、最初からスマホアプリとブラウザ版を作るならSPAも悪くない。
バックエンドは完全に共通になるしメンテ楽だわ。
ただ現状、WEBを作る場合ほとんどのケースでNextでSSRが最適解になるなあ。
864:デフォルトの名無しさん
20/07/28 15:55:06.78 XpAjM/1U.net
かわいいときと
URLﾘﾝｸ(www.youtube.com)
865:デフォルトの名無しさん
20/07/28 16:02:20.88 3p32kQjL.net
>>854
デベロッパーだけの都合でもないよ
クラウドのランニングコストを支払う運営の都合でもある
866:デフォルトの名無しさん
20/07/28 16:08:18.16 6+Fa5W01.net
>>854
SPA vs サーバーでその処理を行うだったらそのとおりだけど
実際にはサーバーで処理を行うとは限らないんだよ
例えばAjaxを使ってJSONだけ読み取ってローカルの
テンプレートエンジンで処理をする。
マルチページで作るんだからこれはSPAではないよ。
JSONだけ読み取るのは現在のページ（URL）での処理だけ
それでもサーバーの負荷はわずかに減ると思うかもしれないけど
ボトルネックは通常データベースアクセスになるので
単にサーバーのCPUの休み時間が増えるだけ
> 例えば情報系サービスをスクラッチで作るとして、最初からスマホアプリとブラウザ版を作るならSPAも悪くない。
> バックエンドは完全に共通になるしメンテ楽だわ。
それもSPAである必要はないね。JavaScript（Ajax）で作ればいいだけ
867:デフォルトの名無しさん
20/07/28 16:10:31.74 6+Fa5W01.net
それにしてもURLが異なれば、通常はJavaScriptの処理も
まるっきり変わってしまうのになんでSPAにしようとしてるんだろうね
単にマルチページ+JavaScript（Ajax=テンプレート+JSON）でいいじゃない？
868:デフォルトの名無しさん
20/07/28 16:21:42.86 87VWo28p.net
ここでいうSPAフレームワークはリアクティブなんだよ
ajaxで取得したデータは自分で処理書かないといかんだろが
それとコンポーネント化
これらを理解できねーゴミクズたちが必死に浅い知識でSSR自慢しに来ている
わからねえならあっち行けよ
869:デフォルトの名無しさん
20/07/28 16:37:29.84 6+Fa5W01.net
まああれだな。新しい技術ができたら、それは銀の弾丸だとばかりに
それが正しい、それでやるべきだ！といういつもの流れ
そこから一方戻って、というブームがあったんだが実際はどうだろうか？
やりすぎだった。それが全てではない。適材適所だな。と気付いて
ようやく一人前の技術になると思うよ。今はまだブームの段階
870:デフォルトの名無しさん
20/07/28 16:40:02.39 qSy4jWEn.net
再利用性、テスタビリティ、クラウドコスト削減
871:デフォルトの名無しさん
20/07/28 16:49:49.58 3p32kQjL.net
>>859
リアクティブとSPAは関係ないだろう
マルチページじゃリアクティブできないとでも？
872:デフォルトの名無しさん
20/07/28 16:51:19.91 3p32kQjL.net
>>859
コンポーネントもSPAに限った話じゃないし
いにしえのJSFやASPNETですらサポートしてる
他のフレームワークもほとんどすべてがサポートしてるだろう
873:デフォルトの名無しさん
20/07/28 16:55:16 87VWo28p.net
>>860
ゴミクズの一味はおめえだよ
中身スカスカのレスいらないから
二度と来るな
874:デフォルトの名無しさん
20/07/28 16:57:08 87VWo28p.net
>>862
うざい
流れ読めねえならレスすんな
875:デフォルトの名無しさん
20/07/28 17:02:54 6+Fa5W01.net
フレームワークでテストがしやすくなったというのも疑問点が残るよね。
例えばクリックしたら色が変わるってのをどうやってテストをしているのか
書いてみてほしいものだが
876:デフォルトの名無しさん
20/07/28 17:26:57.21 diSWTXUe.net
web e2e test sweet とか
web e2e testing framework とかで検索してみたら？
877:デフォルトの名無しさん
20/07/28 17:32:31.17 6+Fa5W01.net
テストがやりやすいと言う割に
ググらないといけないと言うねｗ
878:デフォルトの名無しさん
20/07/28 17:35:54.49 zKWFaExc.net
>>857
その場合でも各ページの元になるhtmlはサーバが返すだろう？
ルーティングもサーバで処理する。それだとあまり美味しくない。
SPAの利点はWEBサーバのコード不要で静的ファイルを返すだけになり身軽になる事。
クライアントの帯域とコンピューティング予算を利用するスタイルだから、こっちは楽になるのは当然。
APIとDBサーバだけなら開発の負担はぐっと軽くなる。
逆にSPAの限界は、どうやっても肥大するJS。大規模には不向き。
いわゆるマルチページ（初めて聞いたが意味は分かる）が良いならNextでSSRすればいいよ。
どっちが良いという話じゃないし。
879:デフォルトの名無しさん
20/07/28 18:01:58.05 q6n5SbdD.net
>>860
Wappalyzerで国内サイトを
40社程度調べたところだが、React-frameworkで
有名らしいNext.jsもGatsbyほとんど使われてない。
Gatsbyに関してはWappalyzerで集計すらされてない。完全ランク外
ブームといえる状態にも来てないと思う。
名前は有名になってるのに導入があまりされてないのは調べてはみたけども
導入する価値がないと考えたサイトが多い証拠なんじゃないかな
880:デフォルトの名無しさん
20/07/28 18:11:40 2t1H/VoS.net
マルチページという言い方はレトロニムだね
881:デフォルトの名無しさん
20/07/28 18:13:16 OfeQkEiK.net
>>870
新聞社のサイトで既に動いてるのがあって置き換えると思うか？
大手じゃなく新しいサイトを調べて
882:デフォルトの名無しさん
20/07/28 18:19:22.00 2t1H/VoS.net
>>872
劇的にユーザビリティが向上するなら置き換えるのでは？
ようするに大したメリットないってことか
883:デフォルトの名無しさん
20/07/28 18:31:52 3p32kQjL.net
ほとんどすべてのサイトでは不要かむしろUXを悪化させるんだからSPAなんてものが流行るわけがない
コンサルさんは飯の種になるから必死に広めようとしてるようだけどな
884:デフォルトの名無しさん
20/07/28 18:38:12 diSWTXUe.net
数学わからないおじさん「数学なんて必要ない！」
英語わからないおじさん「英語なんて必要ない！」
こういう人はいくら必死に必要ない必要ない喚き続けても誰からも尊重されずバカにされてるよｗｗｗ
885:デフォルトの名無しさん
20/07/28 18:38:54 O4fp8d0k.net
要らないんならこのスレ来なきゃ良いのに
886:デフォルトの名無しさん
20/07/28 18:42:44.44 diSWTXUe.net
>>876
不安でしょうがないんでしょｗ
精神的安定を得るため叩くしかないｗ
実際に必要ないとしても知れば恐れることなどないものを。
無知とは恐ろしいねｗｗｗ
887:デフォルトの名無しさん
20/07/28 18:45:47.58 q6n5SbdD.net
>>872
基幹業務と違ってWebのフロントは短期間でリニューアルする。
大手ほど資金力あるから制限なくStackを選べる。
日経、朝日、読売新聞を見てみたが
web frameworkすら使われてないじゃないかｗ
読売はWordPressだな、CMS
さすがIT後進国
IT先進国はどうか？NY Times見てみたがSvelte が使われてるな
どうやらSvelte採用のトップクラスサイトだったようだ。
Svelte の公式サイトではReactやVueを
traditional frameworksと表現して暗に時代遅れだと言ってるのが気になる
URLﾘﾝｸ(svelte.dev)
SpotifyとかYandexも使ってるな
URLﾘﾝｸ(www.wappalyzer.com)
888:デフォルトの名無しさん
20/07/28 19:14:33 q6n5SbdD.net
>>856
零細サイトを除いたらランニングコストはオンプレミスのが安いし
クラウド要らない派
クラウドはバックエンドの構築、運用ができない企業が使うものだと思ってる
889:デフォルトの名無しさん
20/07/28 19:15:26 diSWTXUe.net
日経電子版のマイクロフロントエンドとPWA
URLﾘﾝｸ(hack.nikkei.com)
SSRもやっとる
890:デフォルトの名無しさん
20/07/28 19:15:32 y6zNnWpS.net
お前らが提案するフレームワーク名
毎回変わってて草
891:デフォルトの名無しさん
20/07/28 19:23:18 O4fp8d0k.net
>>879
零細ってイメージは違うと思うが
URLﾘﾝｸ(xtech.nikkei.com)
892:デフォルトの名無しさん
20/07/28 19:30:27 q6n5SbdD.net
>>882
上場企業でもほとんどがバックエンドの構築、運用ができない企業に該当する
開発を外部に丸投げしてるから運用のノウハウもない
893:デフォルトの名無しさん
20/07/28 19:31:59 3p32kQjL.net
本当に良いものは長く使われる
SPAはすぐに次のトレンドに置き換えられるだろう
Svelteなどなどすでにその兆候がある
894:デフォルトの名無しさん
20/07/28 19:42:45.57 zKWFaExc.net
過去の遺産があれば大規模なリニューアルは難しいだろうよ。
それは否定しない。いろんな事情あるからね。
ただ内部で開発ガッツリしてる系のサービスはおおよそNextなりVue使ってる感じ。
以前みたDMMの記事は面白かったよ。興味があればDMM Insideとか見るといい。
895:デフォルトの名無しさん
20/07/28 19:50:27 BMfiR1yf.net
どこそこの大手アプリはうまく行った！
こういうロジックでフレームワークを推奨してくる人には警戒したほうがいい
アプリのスケール感を全く考えてないから
日曜大工ツールセットで作るべき物を巨大重機で作ろうとするようにおかしなことになる
896:デフォルトの名無しさん
20/07/28 19:55:35 zmkVdjHm.net
フロントフレームワークって基本はSEO切り捨てていい部分のページ向けにまず作ってみるっていうのが大前提だと思う
897:デフォルトの名無しさん
20/07/28 19:56:21 zKWFaExc.net
>>886
サイトの規模がトラフィックの事を言ってるならそれは間違いだよ。
単純に作りやすさ保守メンテを考えれば考慮に値する技術が沢山あるという事。
898:デフォルトの名無しさん
20/07/28 19:56:57 87VWo28p.net
トップページをワッパライザしてSPA使われてねーとかほざいてるゴミ
899:デフォルトの名無しさん
20/07/28 20:07:19.55 ijkedvTd.net
>>888
保守、メンテナンスを考えるとSPA人材の少なさが大きな問題だな
WEB系フレームワーク使う人って、やっぱ、新しいもの好きが多いんだよね
んで、要領良くチャラチャラ生きてきたせいか知らんけど、責任感もない人が多くて、すぐに新しいものに目移りしたり、転職しちゃう
こういう連中に、数年後に、ちょっと前に流行ったあのフレームワークなんだけど、君が作ったやつ、あれメンテナンスしほしいなー、って言うとすげー嫌がるんだわ
ただでさえ少ない人材が、年月を重ねるとまじで皆無になる
で、連中はコピペ人間かよって思うぐらい同じようにこういうんだ、「新しい素晴らしいフレームワークに載せ替えましょう。お見積りはこれぐらいで」
信用ならねぇわ、古くから愛用されて、これから先もずっと生き残ると思われる技術、それを使う技術者こそが信用にたりうる
900:デフォルトの名無しさん
20/07/28 20:07:45.73 q6n5SbdD.net
>>889
ゴミはおまえのこと
web エンジニアなら>>859のようにAjaxという言葉を使わない
Ajaxの定義と経緯を調べてこい
おまえが良く使うreactiveについてもはっきりした定義がない
901:デフォルトの名無しさん
20/07/28 20:08:41.59 O4fp8d0k.net
ajaxって最早死語だよね
902:デフォルトの名無しさん
20/07/28 20:32:28 y6zNnWpS.net
XHRだよな
903:デフォルトの名無しさん
20/07/28 20:39:29 q6n5SbdD.net
URLﾘﾝｸ(svelte.dev)
SvelteによるReact, Vue批判
コードが冗長すぎてうんこだと批判されてる。
Reactすこし触ったときにアホみたいにevent handler出てきて
なんでこんなめんどくさいことやってんだろうと思ったけど直観は正しかったようだ。
SvelteはcompilerだからJSの特殊さに縛られないらしい
たしかにコードがすごい短い
JS嫌いな人にはあってるかもしれないな