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嫌いな人にはあってるかもしれないな
904:デフォルトの名無しさん
20/07/28 20:52:57.67 SAOER8re.net
だんだんPHPみたくなってきてんな
905:デフォルトの名無しさん
20/07/28 21:31:22.28 lUQSji2Q.net
テレ朝 react
日テレ vue
フジ nuxt
TBS 使ってない
TBS以外はSPA
TBSもがんばれ
906:デフォルトの名無しさん
20/07/28 21:36:52.82 nGd9+Z82.net
まあ正解だけ覚えてりゃいいと思ってる奴はこの仕事は向いてないよ。
907:デフォルトの名無しさん
20/07/28 21:50:29 87VWo28p.net
>>891
お前がゴミクソじゃねえか
俺はReactHooksが出る前のバージョンでWebアプリは数プロジェクト作ってる
全く問題ないどころかコンポーネント化が完璧にできているからメンテも楽
何が最新好きだよ？最新じゃなくてもSSRじゃ考えられないくらい開発しやすいわ
お前がゴミクソすぎてまったく使えないのはわかった
Ajaxがどうとか今さらそんなもので勝ち誇るなゴミクズ
レベルが低すぎるんだよ
クソみたいなUIしか作れないゴミクズの分際でうるせえわ
さっさとここから消えろ
908:デフォルトの名無しさん
20/07/28 22:06:51 nl0WhoWH.net
多分こないだのBlazorくんと同一人物なんだろｗ
聞き齧った話しを言いふらしてちやほやされたいだけ。
おそらく自分では何も作ったことないｗ
909:デフォルトの名無しさん
20/07/28 22:13:46 6+Fa5W01.net
>>871
マルチページがいやなら、SRP（単一責任の原則）設計といえばいいんじゃね？ｗ
SPAって1ページになにもかも突っ込んでしまってよくない
大きなものを作る時は小さなものの組み合わせにしたほうが良いよね
SPAの方が速くなることがあるのは事実だけど作るのが大変になる
910:デフォルトの名無しさん
20/07/28 22:14:33 WSKW8SBY.net
ずっとvueやってたけど最近react覚え始めたら難しすぎるわ
vueのcreatedとかmountedとかわかりやすいの名前だったなあって
911:デフォルトの名無しさん
20/07/28 22:19:36 6+Fa5W01.net
>>878
> 基幹業務と違ってWebのフロントは短期間でリニューアルする。
なるほど（笑）
だからこそさ、フロントの役目はなるべく少なくして
サーバー側でやったほうが良いんじゃないかｗ
フロントとサーバーが同じ言語で出来るのがメリットのように
言ってるけど、分離したほうが良い。そして変化の少ないサーバーサイドと
変化の大きいフロントインドに分けて、フロントエンドのコードはなるべく少なくする
SPAの速いよりも、メンテナンス性の方が大事だろ？
フロントとサーバーが一体化されてるフレームワークだと
フロントを変えようと思った時サーバーまで引きづられてしまう
結局、動的なサーバー処理 と 静的（＋JavaScriptで動き付け）なフロントエンドという
設計のほうが長い製品寿命が得られる
912:デフォルトの名無しさん
20/07/28 22:21:05 q6n5SbdD.net
ゴミクズ連呼してる基地外は何に切れてるんだろうな
こんな感情的な奴はまわりでも低品質なコードしか書いてない
913:デフォルトの名無しさん
20/07/28 22:22:46 6+Fa5W01.net
>>894
> コードが冗長すぎてうんこだと批判されてる。
マジそれ。コードが短ければバグも少なくなる。
テストできるようにするのは良いけど、そのために冗長になってテストが大変になってる。
完璧なテストなんかやめて、テストできない部分を意図的に残すが
その部分は最小限のバグのないコードで書けるようにしたほうが良いと思うよ
914:デフォルトの名無しさん
20/07/28 22:24:19 uRzl2y8u.net
>>899
ﾜｯﾁｮｲ付きならもうちょい分かるのにな
915:デフォルトの名無しさん
20/07/28 22:24:22 6+Fa5W01.net
>>897
> まあ正解だけ覚えてりゃいいと思ってる奴はこの仕事は向いてないよ。
そこでいう間違いっていうのは、すぐに陳腐化して負債になるコードな
わずか数年後にレガシーコードになってしまうものを覚えてどうする？
そういうコードを書くならちゃんとお前がメンテナンスしなきゃいかんぞ？
916:デフォルトの名無しさん
20/07/28 22:25:32 uRzl2y8u.net
>>901
もうライフサイクルメソッドはHooksで置き換えられるからそんなに難しくないぞ
917:デフォルトの名無しさん
20/07/28 22:28:56 6+Fa5W01.net
Hooks使ってない人は過去に作ったプロジェクトを修正してるの？
それとも工数もらえないから放置？
プロジェクトを再開する時、これはもうレガシーですねとかいって
改修作業するの？
918:デフォルトの名無しさん
20/07/28 22:29:54 BBDnKqXC.net
まあもってあと3年だろうな
その後はもう別のオモチャに乗り換えてる
919:デフォルトの名無しさん
20/07/28 22:32:50 6+Fa5W01.net
フロントは変化しやすいってことを考えると
フロントの処理が多くなりすぎてるんだろうな
920:デフォルトの名無しさん
20/07/28 22:36:17.62 uRzl2y8u.net
大体黎明期に大きく変わって段々落ち着いてくるもんだけどね
921:デフォルトの名無しさん
20/07/28 22:38:58.53 BBDnKqXC.net
SvelteもいいけどElmもいいな
とにかくレトロJSと別言語ってのが筋がいい
レトロJSの都合から解放されるだけでなくWASMへの移行にも期待できる
TSも別言語っちゃそうだけどこいつはレトロJSの面影が強く残ってるのが減点
922:デフォルトの名無しさん
20/07/28 22:40:50.68 6+Fa5W01.net
○○は嫌いなんだ！だからレトロと言おう、レガシーと言おう！
という印象操作。脱jQueryも同じ仲間
レトロとかレガシーとか脱とか言ってるのに
それが現実にならないのは悔しいだろうなぁｗ
923:デフォルトの名無しさん
20/07/28 22:43:39.89 87VWo28p.net
>>899
おめーはアホだからブレザー野郎と区別すらつかねえんだなゴミクズ
924:デフォルトの名無しさん
20/07/28 22:45:19.56 uRzl2y8u.net
なんかQiitaとかでReact始めましたって人が皆classでコンポーネント書いてるのはチュートリアルがHooks対応してないって事なん？
925:デフォルトの名無しさん
20/07/28 22:46:23.80 gqXSWBcd.net
>>913
んーでも実際レトロじゃないか？
ブラウザで動くのがそれしかない&資産（負債）が溜まりすぎて移行できないっていう、言語自体の良さ以外の理由で生き残ってるあたりレトロ臭がキッツい
WASMでそのあたりが変わって行くと素晴らしいことだが、残念ながらまだもう少し時間がかかりそうだ
926:デフォルトの名無しさん
20/07/28 22:48:09.63 87VWo28p.net
>>908
んなもんどんなフレームワーク使っていても同じだろゴミクズ
バックエンドのフレームワークも数年で変わってるだろゴミクズ
フロントが変化しやすいってなんだゴミクズ
テメーが使えてねえだけだろ
927:デフォルトの名無しさん
20/07/28 22:49:50.17 3CrWemqz.net
>>916
なぜブラウザでしか動かなかったらレトロなんだ？
そのブラウザはどこでも動くんだがｗ
928:デフォルトの名無しさん
20/07/28 22:50:09.02 3CrWemqz.net
> WASMでそのあたりが変わって行くと素晴らしいことだが
そのWASMはどこでも動かない（笑）
929:デフォルトの名無しさん
20/07/28 22:51:42 gqXSWBcd.net
>>918
ブラウザでしかうごかないからレトロとは言ってない
ブラウザで動くのがそれしかないという理由で生き残ってきたのがレトロ臭キツいって言ってる
930:デフォルトの名無しさん
20/07/28 22:51:59 3CrWemqz.net
>>917
重要なのはフロントとサーバーが分離できてるって所
一つでどでかいシステム作るよりも
小さなコンポーネントを組み合わせたほうが良い
931:デフォルトの名無しさん
20/07/28 22:55:35 3CrWemqz.net
>>928
今まで他の言語が採用できない理由を考えたほうが良いよ
採用する機会はいままで幾度となくあった
もともとHTMLのscriptタグはJavaScript以外にも
対応できる設計で、実際VBScriptだって使えた。
一時期はRubyとかPythonとかも動かそうという動きがあった
だがそれが実現しなかったのは、JavaScriptほどのメリットがなかったからだよ
JavaScriptは生き残ってきただけじゃない
他の言語が参入できなかったという事実を無視してはいけない
932:デフォルトの名無しさん
20/07/28 23:02:33.70 lUQSji2Q.net
>>915
確認したらclassになってるわ
これは公式ドキュメントから読む真面目な層がかわいそう＆公式がんばれ
933:デフォルトの名無しさん
20/07/28 23:05:34.03 a5zIbkTG.net
フレームワークを使う時は、あとからフレームワークを
捨てられるように設計することが重要なんだよな
934:デフォルトの名無しさん
20/07/28 23:10:40.59 nl0WhoWH.net
よく考えたらもう一年近くクラスコンポーネント書いてないわｗ
全部ファンクションコンポーネント＋フックAPI
createClassはそうでもなかったけどクラスコンポーネントはホンマ嫌いやったわ。
全部単なる関数で書けて最高に幸せ。
そもそもJSにclass構文持ってきた池沼は地獄に落ちろと思う。
935:デフォルトの名無しさん
20/07/28 23:31:39.67 mivdLBHR.net
wasmに期待してる人は一度使ってみなよ。期待してるようなものと全然違うことがわかるから
936:デフォルトの名無しさん
20/07/28 23:52:09.55 2KWkEgO3.net
Ruby on Rails では、ビジネスロジックをサーバー側へ寄せていく。
GUI には、React を使っても、コンポーネントとして使う。
フレームワークとしては使わない
Bootstrap なら、素人でもレスポンシブ対応できる。
規約だけのフレームワーク・Stimulus も使う
Reactive なら、Stimulus Reflex とか
pjax(ajax + historyAPI のpushState)も使える。
HTML のbody だけの入れ替え。
head 部分は送らないから、エコ
他にも、メール送受信、S3 へ保存、画像変換とか
デフォルトで、一式揃っているから、新規起業は、Rails で作るのが多い
937:デフォルトの名無しさん
20/07/28 23:53:37 aNS9pQMY.net
つまりReact、Vue、Svelte、Blazorの完成形がPHPということでよろしいか？
938:デフォルトの名無しさん
20/07/29 00:05:20 s57ohzf0.net
>>922
メリットがなかったんじゃなく単にセキュリティ担保が難しかっただけだな
939:デフォルトの名無しさん
20/07/29 00:13:05 eJvQS3yX.net
>>900
デスクトップアプリは全部そういう構造なんだが
設計ちゃんとしてれば詰め込みすぎでヤバいなんてことにならない
940:デフォルトの名無しさん
20/07/29 00:15:27 CwVjY0Ri.net
メニューの階層が深すぎて設定項目がどこか見当たらないのはその為か
941:デフォルトの名無しさん
20/07/29 07:21:08.28 hp9tDP0D.net
>>926
マジでそれ。実際に書いて使ってみれば一発でわかるような事がわかってないレスが多い。
942:デフォルトの名無しさん
20/07/29 07:54:26.38 SyrCKSn4.net
Blazor(wasm)を実際に使ってるが期待以上だった
バイナリサイズ、速度は今でも十分悪くないが今後急速に改善されるだろう
943:デフォルトの名無しさん
20/07/29 08:27:56 z6Fnx3oM.net
速度は今でも十分悪くない>>675-677
今後急速に改善される>>703
944:デフォルトの名無しさん
20/07/29 08:34:53.28 8XPBM7zm.net
>>934
体感的には全く問題ない
そう言ってるだけ
945:デフォルトの名無しさん
20/07/29 09:02:16.85 mK2eufmg.net
>>918 >>920
JSはbrowserで動く唯一の言語という特権が
あるから今の地位がある。
優遇されてるのにweb frameworkではJSは人気がない。
WappalyzerでみてもJS系web framework利用者は少なく
最大シェアでもExpressの7%
1%以上のシェアのものはExpressとNext.jsしかない
ちなみにASP.NETはシェア52%
946:デフォルトの名無しさん
20/07/29 09:05:03.00 mK2eufmg.net
>>922
WebAssemblyならJSの縛りはなくなるし
JSを完全に捨て去ることができる。
947:デフォルトの名無しさん
20/07/29 09:06:31.89 WjPZZ4ye.net
しかし現実は圧倒的にjQueryが
シェアナンバーワンなのである
948:デフォルトの名無しさん
20/07/29 09:08:10.26 HdZsRsXr.net
JavaScriptって1回死んだよな
それをGoogleがAJAXで復活の呪文させてしまった
あのときJavaScriptでは無理だからちゃんとしたプログラミング言語とUIツールキットを載せようってなってたら違った未来があったのかな
949:デフォルトの名無しさん
20/07/29 09:16:44.12 mK2eufmg.net
>>934-935
Wasmはbrowserで実行されるわけだからユーザーが
体感的に気にならないスピードになればいいだけだ。
C#使える人にとっては開発のスピードはすでに最速になってる。
SoCのスピードは毎年30%近くあがってるから、
ソフトウェア変えなくても今1秒かかってる処理が
まったく気にならないレベルになってしまう。
950:デフォルトの名無しさん
20/07/29 09:20:22 mK2eufmg.net
>>938
jQueryおじさんそれweb frameworkじゃないから
936の統計に入ってない
機能不足
951:デフォルトの名無しさん
20/07/29 09:25:31.50 o9vqi2Lj.net
>>941
そりゃjQueryはフレームワークに圧倒的な差で勝ってしまうからなぁ
DOM APIの薄いラッパーなので速度は早い
ライブラリのサイズも小さい
HTML/CSSとの連携で最小限のJavaScriptコードで実現するから
952:デフォルトの名無しさん
20/07/29 09:47:39.79 txbtiYJP.net
jsが駄目ならtsで良いじゃん。c# も使えるけどtsが言語的にc#に劣る部分なんてほとんど無いよ
953:デフォルトの名無しさん
20/07/29 10:35:46.94 10XNhQ52.net
>>936の統計に含まれてないのは
jQueryが圧倒的に勝ってしまうから？
954:デフォルトの名無しさん
20/07/29 10:47:58.41 V+4Qinl6.net
jQueryって云わばフレームワークを使わない場合のPHPみたいなもんだしな
955:デフォルトの名無しさん
20/07/29 11:03:51.07 10XNhQ52.net
PHPみたいなもの＝Vanilla JSでは？
956:デフォルトの名無しさん
20/07/29 11:06:25.30 mK2eufmg.net
>>942 >>944
jQueryおじさんって複数いたのか
すでに書いたように機能が不足しててweb frameworkに分類されない
最低でもrouting機能くらいないとweb frameworkとは呼べない
jQueryはJS Libraryの項目で集計されてる
URLﾘﾝｸ(www.wappalyzer.com)
>>943
TSはJSに変換する以上、どうしてもJSの機能や速度に制限受ける
957:デフォルトの名無しさん
20/07/29 11:16:17.13 10XNhQ52.net
>>947
JavaScriptでルーティングをすること自体がおかしい
JavaScriptが無効だと動かないサイトになるだろ
958:デフォルトの名無しさん
20/07/29 11:30:28.04 hp9tDP0D.net
>>947
機能はc#並みにはあるよ。
jsとwasmの速度の違いはリソースのコンパイルとロードにかかる時間だけだよ
959:デフォルトの名無しさん
20/07/29 11:40:16.13 mK2eufmg.net
>>948
機能も目的も違うしjQueryはweb frameworkと
比べても意味ないんだけどそれわかんないの？
DBとかbackendの開発したことないでしょう？
960:デフォルトの名無しさん
20/07/29 12:07:21 Boda6iPr.net
とりあえずjQueryはスレチだからやめとこうぜ。
961:デフォルトの名無しさん
20/07/29 13:00:00.34 5RXUD99q.net
>>943
しょせんトランスパイラ
JSの束縛からは逃げられない
TSがwasmを吐き出すようになったらスタートライン
962:デフォルトの名無しさん
20/07/29 13:05:12.48 DSEEm0x9.net
blazorの遅さは体感的に問題ないと言ったり
JSの速度はやたら気にしたりよく分からん
asm.js→wasmで解決したJSの束縛って一体なんなのさ
963:デフォルトの名無しさん
20/07/29 13:11:37.06 Boda6iPr.net
wasm触ったことないんだが、ブレイクポイント設定できるのかね？
これが出来ないなら採用は無いな。
964:デフォルトの名無しさん
20/07/29 13:12:41.13 sM8Vohnx.net
JSの文法とライブラリに縛られるってこと
それを回避するためにスマートでないコード生成が必要になることもあるだろうな
965:デフォルトの名無しさん
20/07/29 13:13:28.04 sM8Vohnx.net
>>954
Blazorはブレーク効くよ
966:デフォルトの名無しさん
20/07/29 13:59:05 mK2eufmg.net
>>953
C#の出来がいいからだよ
gameとかもたくさんC#で開発されてるし言語として速い部類。
そして開発生産性が高い
Blazorの速度問題は改善の余地が相当あってMSが取り組んでるし
最も将来性がある
967:デフォルトの名無しさん
20/07/29 14:12:51.56 HdZsRsXr.net
>>952
TSがwasm吐くよりTSがブラウザーでネイティブサポートされるほうが嬉しいな
968:デフォルトの名無しさん
20/07/29 14:13:20.50 hp9tDP0D.net
Blazorはc#ランタイムをwasm上で動かしてんの？
969:デフォルトの名無しさん
20/07/29 14:26:24.81 Boda6iPr.net
>>956
まじか。一体どんな理屈で動作してるんだ。。
ブラウザ側にフックが既に組み込まれてるのかな。
970:デフォルトの名無しさん
20/07/29 14:43:46.23 E/WNSRes.net
>>958
最悪のパターンだよそれ
それやっちゃうとTSなのに環境差異出まくってTSにトランスパイルする別の言語が作られかねない
971:デフォルトの名無しさん
20/07/29 16:01:14.84 z6Fnx3oM.net
wasm吐くts = AssemblyScript
URLﾘﾝｸ(www.assemblyscript.org)
972:デフォルトの名無しさん
20/07/29 16:57:16.90 blHj/j43.net
TSがブラウザ実装されるとかまじで最悪のパターンじゃん
よく考えてから書けよ
IFとしてもWASM一択
973:デフォルトの名無しさん
20/07/29 17:13:00.70 7lzh14Gr.net
Wasmにすれば、たちどころにGUIとかOpenGLとかが簡単に使えたり、高速になったり、ｍゲームが作りやすきうなったりすると思っている人がいるかも知れないが、それは誤解。
そういうものは、ツールキット次第。
Blazorの場合、実行速度も遅いし、ダウンロードサイズも大きいのでJSよりむしろ
悪化するだけ。
つまり、Blazorは悪いツールキット。
974:デフォルトの名無しさん
20/07/29 17:20:25.29 7lzh14Gr.net
Wasmではなくnative的なものでも、
Unityはゲームが作りやすい、WinFormsやQtはGUIが作りやすい、
C++はC#より速い。C++やC#はIDEが充実している、MFCとWin32ならMFCの方
が便利、など、言語やツールキットによってそれぞれ特色があり、千差万別。
Wasmは、アセンブリ言語相当のものだから、それと同様にその上に載る言語や
ツールキットによって、それぞれ待った区別の特徴を持つ状態になる。
サイズの大きさも、GUIのプログラムしやすさも、実行速度も、これから
選べる時代になったと言うこと。
Wasmだから、速度が絶対に速かったり、絶対に便利になったりするわけではない。
便利でも遅いもの、サイズが大きいためにWebでの即時実行には不向きなものもある。
C#をWasm化すると、2重に仮想マシンが載ることになるために基本的に遅くなる。
975:デフォルトの名無しさん
20/07/29 18:41:53 E/WNSRes.net
>>964
まだ黎明期
これから期待通りになるので安心しろ
976:デフォルトの名無しさん
20/07/29 18:44:49 bUZt8h4Z.net
それは何年後だろうね（笑）
977:デフォルトの名無しさん
20/07/29 19:13:19 7lzh14Gr.net
>>966
MSはあらゆるもののサイズがどんどん大きくなっているので、
サイズが小さくなることは望めない。
978:デフォルトの名無しさん
20/07/29 19:18:18 c6dwanT8.net
TSってJSにくらべて微妙にもっさりしてるよね
979:デフォルトの名無しさん
20/07/29 19:39:26.63 E/WNSRes.net
>>968
.NET Coreはいいぞ
980:デフォルトの名無しさん
20/07/29 20:07:53.46 L9553S+3.net
>>969
TSをES2019とかのJSにトランスパイルしたら型情報以外ほぼそのままJSにならない？
981:デフォルトの名無しさん
20/07/29 20:22:45 mK2eufmg.net
>>965
MSの人がC# wasmでAOT compileも選べるようにするとか書いてたから
Speedはかなり速くなる可能性秘めてる。
982:デフォルトの名無しさん
20/07/29 20:55:32 z6Fnx3oM.net
可能性ｗ
末は博士か大臣かｗｗ
983:デフォルトの名無しさん
20/07/29 21:01:39 E/WNSRes.net
実際、覇権とるだろうな
ポテンシャル高杉る
984:デフォルトの名無しさん
20/07/29 21:21:43.49 DSEEm0x9.net
wasm自体が未完成(MVP)で策定中の部分が多いのに将来の覇権なんて分かる訳無いじゃん
C#イイ！ってだけでゴリ押しさ�
985:黷ﾄも反応出来んわ
986:デフォルトの名無しさん
20/07/29 21:29:50.29 1K2jXdqa.net
速度、開発生産性、人材確保、長期サポート
全てにおいて期待が高まり、そしてそれは実現するだろう
なんたって信頼と実績のマイクロソフトだもの
マイクロソフトの提供するDXは、いつだって時代の数歩先を行ってた
987:デフォルトの名無しさん
20/07/29 21:49:56.06 mK2eufmg.net
>>975
Web frameworkの現在の覇権がASP.NET。ぶっちぎりだ。
wasmが仮に流行らないとしたら今のままASP.net MVC Coreとかが
使われるだけだろう
文句つけてるひとはBlazor試したこともないだろう
988:デフォルトの名無しさん
20/07/29 22:01:26 Z+ecNrBH.net
これを持ち上げるのは不本意だけどぶっちゃけASPよりRoRの方がシェア高いやろ
989:デフォルトの名無しさん
20/07/29 22:01:47 +DO1kjO4.net
URLﾘﾝｸ(news.mynavi.jp)
c#よ、そんなに優れているならPHPの息の根を止めてくれ
990:デフォルトの名無しさん
20/07/29 22:06:42.81 Z+ecNrBH.net
>>979
WordPress以上のもん出さんと無理やろね
いや普通にWixの方がいいのは確かなんだけど
991:デフォルトの名無しさん
20/07/29 22:13:53.14 mK2eufmg.net
>>978
Railsは検討してる。9%程度
ASP.NET除いたらけっこういいframeworkだな
ASP.NETは52%
ぶっちぎり
992:デフォルトの名無しさん
20/07/29 22:15:37.99 z6Fnx3oM.net
ソース無し。また妄想かｗ
993:デフォルトの名無しさん
20/07/29 22:42:49.87 mK2eufmg.net
>>982
なんどもソース書いてるだろ
Wappalyzerでの検出結果だ
英語わからないアホな人っぽいな
994:デフォルトの名無しさん
20/07/29 22:45:41.10 jLdEagq7.net
wasmってただの中間コードだろ？
JSの構文解析が終わるのと
wasmのライブラリがダウンロードされるのとのスピード勝負か？
995:デフォルトの名無しさん
20/07/29 22:49:09.80 XelKZAZW.net
1年後の世界へ行こう！
／'⌒`ヽ、 Blazorが世界1のシェア取ってるはず…
ヽ、┗ ノ
`ーｰ' γ⌒ヽ／ﾌﾞﾚｷﾁ＼ ／'⌒⌒ヽ、
,-ｰｰ-､ .||~￣~|/-O-O-ヽ|. （ ┃ ⌒ヽ
/ ┃ ） || 6| . : )'e'( : . |9 ＼ ━┛ ）
.（. ┃ ） || ｀‐-＝-‐ ' ＼＿＿_,ノ
ヽ､＿＿,ノ || ＿(つ¶¶と)＿_
／||'''''| 三 | |'（⌒）
／ '―――` ￣ ＼
`＝＝＝＝＝＝＝＝＝＝＝＝'
996:デフォルトの名無しさん
20/07/29 22:51:15.75 XelKZAZW.net
￣￣￣| | ｌｌヽ _| ヽ
| | |l￣| | l Blazorって未来ではどうなってんの？
| | / ´＼ /
| | ヽ､＿ ｀＾イ
二二二 」 ＿ ＿＿ ｌﾆ二二ｌ､ ＿＿＿_
─┴┐ ⊆ﾌ＿)＿_./ ┌ヽ ヽ┐ ／´ ｀＼
二二二二二二ｌ / | | | |. / ヽ
＿l＿＿＿＿_| ／｀ｰ─‐|＿| |_| / ヽ
| ／｀ヽ__, ─ ､ノ |─l ｌ l
|──/ ／lﾆ/ /二ﾆluul. | ! え？そんなゴミないよ
| ___|￣ | | |_|. l /
└─（ ）(ﾆ| ￣|./二ﾆ) ヽ /
￣￣ / ） >━━━ く
｀ー ´ / ヽ
997:デフォルトの名無しさん
20/07/29 22:56:11.03 z6Fnx3oM.net
WordPressが全ウェブサイトの35%(CMS市場では6割超)のシェアなのにaspが過半数なんておかしい
998:と思ったｗ https://www.similartech.com/compare/asp-net-vs-php やっぱphp以下じゃんｗｗｗ
999:デフォルトの名無しさん
20/07/29 23:04:30 eNj62kDo.net
c#や.NETの何が嫌かって
MS環境やvisual studio前提ってこと
Linuxサーバでyumやapt経由じゃないこと
つまりnodeやRailsと違って
コンテナや仮想環境にデプロイしにくい
IDEって普通のエディタと違って
重いし、勝手なことするし
そんなのlinuxとスクリプト言語で成り立ってきた
web業界で流行るわけが無い
1000:デフォルトの名無しさん
20/07/29 23:29:11 W/CyAtcn.net
>>988
何年前の世界からタイムスリップしてきたんだ？
1001:デフォルトの名無しさん
20/07/29 23:40:23.55 032Rbh94.net
MSのエヴァンジェリストって困る。
名は体を表さず、悪魔。
自分で神の名を名乗るような者にろくなのはいない。
1002:デフォルトの名無しさん
20/07/29 23:43:39.18 032Rbh94.net
>>988
PHPやJSは無料なのに、.NET、C#、ASPは金取られるしね。
MSにこれ以上金を流したら、日本は終わり。
1003:デフォルトの名無しさん
20/07/29 23:56:29.73 032Rbh94.net
日本人は、みんなが力を合わせて、アメリカのIT企業の足を引っ張るべき。
アメリカ企業に就職した人は、国賊認定して徹底的に苛めるべき。
そうでなければ、この国は持たない。
1004:デフォルトの名無しさん
20/07/29 23:59:11.68 032Rbh94.net
技術がなくても、学は無くとも、知恵は無くとも、それぞれが少しずつでいいから、
アメリカ企業にダメージを与えて欲しい。
逆元気玉。
日本人は力を合わせてアメリカ企業を壊そう。
1005:デフォルトの名無しさん
20/07/29 23:59:14.78 5LkEgo4u.net
C#はあれだ
どこから.netなのかよく分からん
1006:デフォルトの名無しさん
20/07/30 00:08:07.98 DFjeaZjZ.net
次スレ。
Vue vs React vs Angular Part.5
ｽﾚﾘﾝｸ(tech板)
1007:デフォルトの名無しさん
20/07/30 00:37:25 jUjY7FYi.net
>>988
いつの時代の話だよ
1008:デフォルトの名無しさん
20/07/30 00:37:43 jUjY7FYi.net
>>991
あほ
1009:デフォルトの名無しさん
20/07/30 01:04:08.37 9quanFrk.net
アメリカ企業に金を与えては駄目だ。
1010:デフォルトの名無しさん
20/07/30 02:20:13.79 NhByUfR6.net
1年後の世界へ行こう！
／'⌒`ヽ、 Blazorが世界1のシェア取ってるはず…
ヽ、┗ ノ
`ーｰ' γ⌒ヽ／ﾌﾞﾚｷﾁ＼ ／'⌒⌒ヽ、
,-ｰｰ-､ .||~￣~|/-O-O-ヽ|. （ ┃ ⌒ヽ
/ ┃ ） || 6| . : )'e'( : . |9 ＼ ━┛ ）
.（. ┃ ） || ｀‐-＝-‐ ' ＼＿＿_,ノ
ヽ､＿＿,ノ || ＿(つ¶¶と)＿_
／||'''''| 三 | |'（⌒）
／ '―――` ￣ ＼
`＝＝＝＝＝＝＝＝＝＝＝＝'
1011:デフォルトの名無しさん
20/07/30 02:24:32.69 DFjeaZjZ.net
次スレ
Vue vs React vs Angular Part.5
ｽﾚﾘﾝｸ(tech板)
1012:1001
Over 1000 Thread.net
このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 48日 7時間 22分 47秒
1013:過去ログ ★
[過去ログ]
■ このスレッドは過去ログ倉庫に格納されています