Vue vs React vs Svelte Part.6

Vue vs React vs Svel ..

2:デフォルトの名無しさん
20/10/27 14:12:34.02 2R4nrYNG.net
・jQueryトップページ
URLﾘﾝｸ(jquery.com)
・ダウンロード、CDN
URLﾘﾝｸ(jquery.com)
・ブラウザサポート
URLﾘﾝｸ(jquery.com)
・jQuery UI
URLﾘﾝｸ(jqueryui.com)
・jQuery UI ダウンロ－ド
URLﾘﾝｸ(jqueryui.com)

・リファレンス等
URLﾘﾝｸ(js.studio-kingdom.com)
URLﾘﾝｸ(alphasis.info) (URLﾘﾝｸ(alphasis.info))
URLﾘﾝｸ(www.jquerystudy.info)

3:デフォルトの名無しさん
20/10/27 14:13:07.59 2R4nrYNG.net
Q. jQueryはどのバージョンを使えばいいのですか？
A. IE9以上であれば、jQuery 3.0以上を使用してください。
IE8以下にも対応するならば、jQuery 1.12を使用してください。
補足
jQuery 1.9 までは一系統しかなく、古いブラウザも含めて全て対応していました。
その後、古いブラウザを切り捨てるためにバージョンを分岐させました。
古いブラウザにも対応した1系（1.10、1.11、12）と
古いブラウザを切り捨てた2系（2.0, 2.1, 2.2）です。
1系と2系は対応ブラウザの違いだけで機能は全く一緒です。
機能が同じなのにメジャーバージョンが違っているのが分かりにくい
ということでバージョン番号の付け方を変えることになり、
新たに古いブラウザを切り捨てたjQuery 3.0、そして古いブラウザにも対応した
jQuery Compat 3.0がリリースされる予定でした。
しかしマイクロソフトが古いIEのサポートポリシーを変更し
サポート中であるOSで動く、最新のIEしかサポートしなくなったために、
2016年1月でVista上のIE8のサポートが終了しました。
そのため予定されていたjQuery Compat 3.0がなくなり、
jQueryは3.0に一本化されました。

4:デフォルトの名無しさん
20/10/27 14:13:31.16 2R4nrYNG.net
jQuery 3.0正式版がついにリリース。通常版のほかに、Ajax機能を省略したスリムビルド版も提供
URLﾘﾝｸ(www.publickey1.jp)

2006年1月にjQueryが初めて世の中に登場してから10周年となる今年。jQuery 3.0の正式版が登場しました。
jQuery 3.0 Final Released! | Official jQuery Blog
これまでjQueryは、、モダンブラウザのみをサポートすることで軽量化と安定化をはかった
「jQuery 2.x」系と、Internet Explorer 8以前を含む古いバージョンのブラウザまで
サポートする互換性重視の「jQuery 1.x」系の2系統が存在しました。
また、フル機能のjQuery 3.0のほかに、Ajaxの機能を省略して軽量化したスリムビルド版のjQuery 3.0の提供が行われます。
Along with the regular version of jQuery that includes the ajax and effects modules, we’re releasing a “slim” version that excludes these modules.
通常バージョンとしてAjaxやエフェクトモジュールなどを含んだjQueryと同時に、これらを外した“スリム”バージョンも提供する。
最近のWebアプリケーションではjQueryのAjaxを使うことは少なくなったと思われますので、スリム版のjQueryで十分だという開発者も多いでしょう。
圧縮後のサイズは通常版が30kbなのに対し、スリム版は23.6kb。

5:デフォルトの名無しさん
20/10/27 14:15:29.26 2R4nrYNG.net
jQueryはオワコン？いやいやjQueryのシェアはまだまだ増えてます。
誰が初めたかわからない中身のない脱jQueryキャンペーンこそがオワコンだったのです。
URLﾘﾝｸ(w3techs.com)
jQuery
2017年 71.9%
2018年 73.1%
2019年 73.6%
2020年 74.2%
　　2月 74.4%（1ヶ月で+0.2%）
　　6月 75.5%（4ヶ月で+1.1%）
　　8月15日 76.2%（2ヶ月で+0.7%）
　　10月15日 76.5%（2ヶ月で+0.3%）
　　10月25日 76.7%（0日で+0.2%、10ヶ月で+2.5%）
Vue.js　0.4%（1年で+0.1%）
Angular　0.4%（1年で+0%）
React　0.3%（1年で+0%）

6:デフォルトの名無しさん
20/10/27 14:22:42.13 5aYZ+KyB.net
>>1 書き忘れた
★推奨NGワード
jQuery
Ruby
C#
Blazor
全くスレタイと関係ないものばかりなので、連鎖あぼーん有効で問題ないでしょう。透明あぼーんもオンにしときましょう。

7:デフォルトの名無しさん
20/10/27 15:26:28.81 h2IDmsrX.net
シェアを根拠にｊQueryを自慢してるやつは
マクドナルドのハンバーガーを自慢するのと同じだってことに気づけ

8:デフォルトの名無しさん
20/10/27 16:37:25.48 xK7hqc+R.net
マクドナルドのハンバーガーの何が間違っているか言えるか？
あれは、「一番普及してる＝美味しい」としてしまったこと
美味しいが間違いなのであって「一番普及している＝総合的に優れている」という
結論であれば間違いじゃないんだよ
「美味しい」というのは優れている要素の1つでしかない、
「一番普及している＝安い」ということだってできる。もちろん一番安いわけでもないだろう
いろんな要素があって、それらを総合的に見た時優れている。
「マクドナルドのハンバーガーは総合的に一番優れている」という言い方ならおかしくもなんともなかった
あの話は「美味しい」にしたところが間違いなだけ。
一番普及しているという事実には、そこに優位な理由が存在していることを意味している
jQueryもそうだわな。Windowsだってそうだ。
すべての面で他より勝ってることなんてありえない
しかし一番普及しているものは総合的に優れているということなら正しい

9:デフォルトの名無しさん
20/10/27 16:43:47.62 yDmA/b17.net
ウェンディーズのハンバーグが一番旨かったと思うが
ウェンディーズは死んでしまった
良いものが残るとは限らない

10:デフォルトの名無しさん
20/10/27 16:59:35.60 R4KuGRzg.net
× 良いものが残るとは限らない
○ 美味しいものが残るとは限らない
旨かった＝良いものではない。そこが間違っている
戦略的に"優れているもの"が生き残る
生き残っているものは結局の所、（重要な点が）優れているものなんだよ

11:デフォルトの名無しさん
20/10/27 17:21:32.60 eOQLz2LC.net
ことばあそびですね判ります

12:デフォルトの名無しさん
20/10/27 17:29:22.15 R4KuGRzg.net
>>11
そう。あのコミック自体が言葉遊びだったんだよ。
あれ読んで、一番普及しているものに優れたところはないと
解釈してしまった読者はアホ

13:デフォルトの名無しさん
20/10/27 17:32:23.93 R4KuGRzg.net
「一番売れているのは、一番美味しいからだ」と言ったどこかのモブに対して
イヤイヤイヤイヤ「一番売れているのは、販売戦略が一番優れていたからだろ」と
ツッコミを入れなければいけない所
別の所が一番なんだよと指摘すると、実はこの話は成り立たなくなる

14:デフォルトの名無しさん
20/10/27 18:19:35.54 GDxeid4H.net
jQueryを熱く語ってるの滑稽なんだけど自覚ある？

15:デフォルトの名無しさん
20/10/27 20:29:20.43 hzPxqZHp.net
どのスレが本物なんだ？

16:デフォルトの名無しさん
20/10/27 22:18:04.19 3AmRv/Cj.net
フレームワークは腐る、乱立する
大体同じ内容をメソッド名とか引数パターンだけ
覚え直しという無駄な学習コストの三重苦
ネイティブコードこそ至高

17:デフォルトの名無しさん
20/10/28 11:59:43.20 Mf8tEr2f.net
jQueryが普及してるとか
jQuery使ってれば良いって主張してるけど
jQueryが糞ってことは否定してないしな

18:デフォルトの名無しさん
20/10/28 12:01:11.48 Mf8tEr2f.net
>>16
すごい判る
大抵は覚えることが増えるだけで
思ったほどメリット出ない

19:デフォルトの名無しさん
20/10/28 12:30:28.11 glAUkrzc.net
WebのUIの複雑さに対処するように進化してきてるから
ちょっとしたサイトを作るくらいではメリットを感じられないんだろう

20:デフォルトの名無しさん
20/10/28 12:35:58.13 VmvFGckH.net
>>17
今までjQueryがクソという話が出てないんだから
否定がないのは当たり前だろｗ
お前がこのスレではじめて言ったが明確に否定するよ
jQueryはクソではない

21:デフォルトの名無しさん
20/10/28 12:40:55.43 VmvFGckH.net
>>16
覚え直しという無駄な学習コストの三重苦
Reactは将来移行しなければいけないほどの作業がありますんで
覚悟しておいてください。大丈夫！移行の問題を緩和する仕組みも作りました。
2つのバージョンを共存できるんです！同時に2つのバージョンを使えばいいんです！
React 17では、将来のReactバージョンへの移行の問題を緩和
URLﾘﾝｸ(www.infoq.com)
> Reactチームは、React 16の2年後にReact 17（最初のリリース候補版）を最近リリースした。
> React 17は、2つの同時バージョンが共存できるようにすることで、
> Reactの将来のメジャーバージョン間の移行が簡単になるよう努めている。
他にも沢山変更したいことはあるのですが、移行は大変なので
React 17の後に延期しましたよ。えっへん！
> 特に、React 17は「足がかり」のリリースであり、あるバージョンのReactで管理されているツリーを、
> 別のバージョンのReactで管理されているツリー内に安全に埋め込むことができる。
> […]他の変更はReact 17の後に延期しました。

22:デフォルトの名無しさん
20/10/28 12:40:57.19 XBU5yUok.net
いやまあクソやろ

23:デフォルトの名無しさん
20/10/28 12:48:48.73 VmvFGckH.net
jQueryの凄さにAPIの互換性が高いという点がある。
最新版のjQueryは2020年4月にリリースされた3.5だが
おそらく1.10あたりでもほぼ同じように使える
1.10がリリースしたのは2013年だ

24:デフォルトの名無しさん
20/10/28 13:21:16.49 dpNm0AnW.net
進化しなかったのねーー

25:デフォルトの名無しさん
20/10/28 14:21:23.16 glAUkrzc.net
jQueryで成長が止まった残念なおじさんｗ

26:デフォルトの名無しさん
20/10/28 15:48:02.16 QKhQ72su.net
それはあるね
JSのフレームワークに限らないけど、ライブラリーがバージョンアップの度に破壊的な変更を繰り返して、ライブラリーの更新に合わせて本体を修正するより本体を新規に作り直した方がマシというのはよくある
それで廃れたのがRailsだと思う

27:デフォルトの名無しさん
20/10/28 17:26:28.99 E9S3F981.net
確かにrailsは特に酷い。
railsはrubyと、大量のgemに依存してるだろ？
うっかりrubyのバージョン上げようものならマイナーバージョンアップでも動かなくなるgemが大量に出てくる。
それぞれのgem作者がrubyの破壊的仕様変更に対応しないと今まで使えてたgemが使えない。
これで昔は一世を風靡してた今は使えないgemがかなりある。
だんだんこんなのやってられるか、ってgem作者がrubyワールドから離れてくから。

28:デフォルトの名無しさん
20/10/28 18:15:48.06 MjRcLASo.net
Rubyっつうかウェブ系オープンソース文化はみんなそうだろうな
だからマイクロソフトの.NETがいいんだよね
C#だとほぼ公式のパッケージだけで一通り揃ってて快適に開発できる
互換性の問題もゼロにはならないがほとんど考えなくていい

29:デフォルトの名無しさん
20/10/28 18:56:26.31 NAroBJuS.net
「フレームワークの使い方覚えた、成長したぞ」
その機能は非推奨になりました。これからはこっち使ってね。もっと簡単だよ！
「せっかく成長したのに、なかったことにされた。しかも前より簡単って苦労して覚えた努力は一体・・・」

Angularはそうなったね
Reactもそうなるみたいだね
そのうちVueもそうなるんだろうな

使い方を覚えるのが成長とか思ってるからそうなる

30:デフォルトの名無しさん
20/10/28 19:18:08.22 L1eiKGsA.net
ヘッダーとかフッターとか
ナビゲーションメニューとか
ハンバーガーメニューみたいなの考えた奴死ねよ
めっちゃ開発しにくいだろ

31:デフォルトの名無しさん
20/10/28 19:18:18.34 oeP+hB3a.net
成長どうの語る前に勉強しろよ

32:デフォルトの名無しさん
20/10/28 21:39:03.34 glAUkrzc.net
>>29
この発言からして本当にjQueryの時点で成長が止まったままの
おじさんらしいなｗ
フレームワークで使われてるイディオムみたいなものは
ネイティブで自前実装するときにも活きてきたりする
実力の底上げになるんだよ
デザインパターン覚えたりしたときみたいにね
お前はそこが限界だったんだなｗかわいそうにｗ

33:デフォルトの名無しさん
20/10/28 21:40:50.17 glAUkrzc.net
バージョンアップごときの変化についていけないのはエンジニアとして終わってるよｗ

34:デフォルトの名無しさん
20/10/28 21:46:09.34 glAUkrzc.net
初めて触るフレームワークだったとしても
普通に1つの仕事やる間に基本＋ちょっとした応用くらいのことは身につけられるし
「学習する労力」というほどのことじゃない
jQueryバカは本当に学習能力が低すぎて辛いのかもしれないがｗ

35:デフォルトの名無しさん
20/10/29 11:09:35.04 Q4uaxLWQ.net
BlazorってクライアントサイドEFCoreってできんのかね？
Queryableをシリアライズして飛ばすだけだからできそうなもんだが

36:デフォルトの名無しさん
20/10/29 11:11:13.80 Q4uaxLWQ.net
クライアントEFCoreが実現したらGraphQLが要らなくなりそうだ

37:デフォルトの名無しさん
20/10/29 12:03:49.84 89EHBpBz.net
>>35
URLﾘﾝｸ(blog.jeremylikness.com)

38:デフォルトの名無しさん
20/10/29 12:14:17.20 wtq/xrTf.net
MSKK必死だな（藁）

39:デフォルトの名無しさん
20/10/29 12:28:48.42 a4oOdv8E.net
>>37
へーもうあるんだ
今までRESTだのGraphQLだのgRPCだのと色々と疲弊してたのって何だったんだろうな

40:デフォルトの名無しさん
20/10/29 15:52:40.12 h1JWOo0w.net
>>30
ハンバーガーは最悪
開発する方だけじゃなくて
ユーザー側も使いにくいわ

41:デフォルトの名無しさん
20/10/29 19:10:36.91 8qIhLtfe.net
>>30
お前が無能なだけだろ
こんなチンケなものすら作れねえのかよ

42:デフォルトの名無しさん
20/10/29 21:46:29.31 j1ERxTiC.net
React使って生産性とか管理しやすさとか
幻想だからよ。
そもそも「管理しやすさ」っていう漠然としたものがなんなのか
と言うのが人によって認識が違う訳よ
オブジェクト思考がなんなのかって事延々と考えるのと同じよ
SQL HTML CSS JavaScriptだけでも覚えること大量にあるのに
それを覚えたばかりの人間がそんなこと理解出来るわけがない
GUIなんて千差万別あるのにReact使ったくらいで
簡単に共通化や再利用などできるわけが無い
そんなくだらない幻想のために一度覚えたHTMLやJavaScript
をまた文法変えて覚え直しさせれられる苦痛が分かるか？
そんなもんに学習コストかけるくらいなら
ネイティブのDOMのコーディングスピードとセンスあげて
毎回ゼロベースで作った方がシンプルで余程生産性が高いに決まってる
共有化さまくってるパーツを使うストレス、
共有化パーツに頼りまくってる画面を解析して改修するストレスがどんなものかぐらい想像つくだろ
コードを使い捨てることが出来る安心感
ネイティブであることの信頼感。これぞ至高

43:デフォルトの名無しさん
20/10/29 22:07:56.68 8qIhLtfe.net
>>42
何が言いたいのかまったくわからん
React使ったらhtmlは文法変えてんの？
変えてねーだろアホかこいつ

44:デフォルトの名無しさん
20/10/29 22:37:42.80 Q4uaxLWQ.net
いやいや共通化はしとけよ
ReactだろうがjQだろうがバニラだろうがそこは同じだ

45:デフォルトの名無しさん
20/10/29 23:08:35.79 hUSN75pF.net
>>43
★jQuery, Ruby, C#, Blazorｷﾁｶﾞｲが書き込んでも無視してください

46:デフォルトの名無しさん
20/10/29 23:08:58.57 hUSN75pF.net
>>44
★jQuery, Ruby, C#, Blazorｷﾁｶﾞｲが書き込んでも無視してください

47:デフォルトの名無しさん
20/10/30 21:30:34.87 MU7FPfmA.net
シングルページってアイデア、結局要らなかったな
URL変わったらloadし直してくれたほうがシンプルで良い

48:デフォルトの名無しさん
20/10/30 21:41:48.97 B0ujDtw0.net
アホには使えないからあっち行け

49:デフォルトの名無しさん
20/10/30 22:03:55.00 5oSTrQLk.net
いちいちURLを変える必要がなくなったというだけ

50:デフォルトの名無しさん
20/10/30 22:32:52.75 wuZkHHST.net
ふつうクライアントサイドルーティングで変えるけどな。エアプ乙。

51:デフォルトの名無しさん
20/10/30 23:25:04.93 c33mewdS.net
ページの初期化は
ブラウザ駆動で
location.reload()でいつでも状態消去出来る
それより、保持し続けたかった画面状態が
画面遷移で消滅してしまう方が問題
保持してるものを破棄するのは簡単だが
無いものを引き継がせたり復元したりするのは大変
ならばセッションに保持しようとすると
今度はそれが残り続けて不具合の要因になる
セッションは意識して破棄するのは面倒
そう考えるとSPAで画面遷移減らすのが最適解

52:デフォルトの名無しさん
20/10/30 23:50:46.09 ZQ+XX0gW.net
★jQuery, Ruby, C#, Blazorｷﾁｶﾞｲが書き込んでも無視してください

53:デフォルトの名無しさん
20/10/31 04:18:19.38 TE/FUBzp.net
確かに少なくともURLは変わった方がいい

54:デフォルトの名無しさん
20/10/31 12:34:03.58 GI9kcxdQ.net
SPAが叩かれるのはSPAを前提としたビューを切り替えたりする
ビューの下らないテクニックが嫌われるだけであって
SPAの考え方自体が悪いわけではないと思う
SPAは基本的にAjaxをバンバン飛ばすから
Ajaxが叩くURLというのは分離されている
画面と関係の無いURLを気軽に定義出来るようになり
「画面」と「画面遷移」だけを減少させることが出来る
URLは減少しない、むしろ更にきめ細かくできる

55:デフォルトの名無しさん
20/10/31 12:37:15.04 GI9kcxdQ.net
シングルページにこだわる必要はないと思う
2個でも3個でも構わないが
とにかく無駄な画面遷移を減らす事が重要

56:デフォルトの名無しさん
20/10/31 13:27:15.39 fxcwqRC2.net
ブラウザに無駄に大量の履歴が残るのを防止出来るし
終わったsessionに対して変に履歴から横入りも防止出来るしメリット多い

57:デフォルトの名無しさん
20/10/31 13:33:14.30 ocpJ6AXX.net
単純にさ、メンテナンスしやすいように小さく分けろってことなんだよね
どうしても密結合しなきゃならないっていうなら話は別だけど
そうでないなら結合度は低く保つのはシステム開発の常識なんだし

58:デフォルトの名無しさん
20/10/31 13:59:51.18 D1wdF0Y3.net
小さく分けるなら別のページにしたほうがわかりやすいんだよね
開発者もユーザーも

59:デフォルトの名無しさん
20/10/31 14:06:46.75 4J8dlMsH.net
別にそんなことないが

60:デフォルトの名無しさん
20/10/31 14:11:33.12 XhxNYcCe.net
ルーターつかえてんのかな？

61:デフォルトの名無しさん
20/10/31 14:19:10.79 fxcwqRC2.net
単にケチつけたいから理由を無理やりひねくりだしてるように見える
パヨ野党と同じ

62:デフォルトの名無しさん
20/10/31 14:32:47.48 XhxNYcCe.net
単に能力不足の認識すらないだけかと

63:デフォルトの名無しさん
20/10/31 15:03:24.58 XHxGyiYd.net
まあ待て
WebAssemblyが全てを薙ぎ倒す

64:デフォルトの名無しさん
20/10/31 15:25:03.69 ocpJ6AXX.net
まであと50年？

65:デフォルトの名無しさん
20/10/31 15:56:06.31 s2pToFD3.net
UNITYの事かな？

66:デフォルトの名無しさん
20/10/31 19:30:23.25 D1wdF0Y3.net
単純明快にページを分ける、というやり方をやめて、わざわざ処理を追加して無理矢理ページ内で遷移したように見せかけるという、複雑で愚かな選択
これによりTwitterのサムネがおかしくなったり様々な問題を招き入れてしまった

67:デフォルトの名無しさん
20/10/31 20:10:22.22 H/mkCvBm.net
バカは黙ってろ

68:デフォルトの名無しさん
20/10/31 21:02:58.40 4J8dlMsH.net
ここでグダってないでツイッター社に説教して来いよもう

69:デフォルトの名無しさん
20/10/31 22:26:48.89 h2KzT8QK.net
ツイッターは一例でしょ。しょぼい会社じゃなくて
ツイッターレベルであっても対応に苦労しているという話だ

70:デフォルトの名無しさん
20/10/31 22:44:41.94 gz3vxsih.net
SPA基本のルーターすらしらんやつが
わめいてるけど無視した方が無難かな。

71:デフォルトの名無しさん
20/10/31 23:02:30.40 h2KzT8QK.net
>>70
今そんな話してないよ
グローバルに保持してる状態の話をしてる

72:デフォルトの名無しさん
20/10/31 23:54:28.99 pGrSKCPz.net
今そんな話してない（恥ずかしいから蒸し返すな）

73:デフォルトの名無しさん
20/11/01 00:03:13.60 6kfHBaw2.net
>>67
匿名掲示板だと反論できなくなった人ってすぐ悪口言うよねｗ

74:デフォルトの名無しさん
20/11/01 00:15:18.28 gLftjTJx.net
謎文脈を発生させて論点をずらす奴もいるけどな

75:デフォルトの名無しさん
20/11/01 10:16:49.22 iVsRUSuF.net
>>66
だからその無理やりページ遷移したように見せかける
っていう部分だけが愚策なんだって
ページ自体が複数も要らないんだよ
見かけ上のページも複数要らない

76:デフォルトの名無しさん
20/11/01 12:27:33.30 BdB3gM+x.net
表面上SPAの癖に
時々別のURLに飛ばす造りって
単にSEO対策なんだろ
SEO稼ぐにはURL多い方が良い
SPAの使い易さとSEOは無関係

77:デフォルトの名無しさん
20/11/01 12:30:09.02 xiHRYmfR.net
別のURLに飛ばしてOKなものなら、飛ばしたほうがいいじゃん
状態を引き継ぐよりもステートレスの方がいいんだから

78:デフォルトの名無しさん
20/11/01 12:38:01.74 7AGTmsus.net
>>77
それな
ステートフルすぎて気持ち悪い

79:デフォルトの名無しさん
20/11/01 13:03:27.79 b3NlQgn4.net
アプリケーションは内部状態を持つのが当たり前だが、その状態をサーバー側に持つか
クライアント側で持つかの違いだけじゃね？
どっちかというとサーバー側とそのAPIがステートレスになってくれた方が嬉しいと思うが。

80:デフォルトの名無しさん
20/11/01 13:10:01.61 6kfHBaw2.net
ステートフル”すぎる”な
表示してない物の状態まで持つな
ページを切り替えるなら状態をクリアしろ
切り替えたように見せかけて裏で状態を維持するとか最悪だぞ

81:デフォルトの名無しさん
20/11/01 13:14:42.09 pdNlK96W.net
>>80
おめー無知すぎんだろ
SPAフレームワークをページ遷移だけで見てるからそれしか言えねえんだよ

82:デフォルトの名無しさん
20/11/01 13:22:07.47 b3NlQgn4.net
”すぎる”と”すぎない”の境界がわからんなぁ。
気持ち悪く感じるのは主観だろうからどうしようもないが。

83:デフォルトの名無しさん
20/11/01 13:36:14.94 6kfHBaw2.net
>>81
俺はMVC+Vue.jsのような軽い使い方までは否定してない
SPA的な全部JSでやっちゃえって考え方が駄目だ

84:デフォルトの名無しさん
20/11/01 15:59:43.06 iVsRUSuF.net
webサイト画面構成のビューの作法というか
テンプレみたいなのを誰かが勝手に定義するから
害悪になるんだって
Webサイトにはヘッダーフッターやサイドバーや
ナビメニュー、バーガーメニューがあるべきとか
パンくず付けるべきだとか
SPAのサイトは見かけ上のURLで画面を切り替えるように
すべきとか、こういうの一体誰がなんの権限があって
決めてんの？
実装がどれだけ面倒になるかも考えずにさ
ビューの構造考えてる奴らに「シンプルにしろよ、馬鹿が」
って言ってやりたいわ

85:デフォルトの名無しさん
20/11/01 17:46:49.50 08kl5AwG.net
>>84
音声ブラウザで適切に読むため

86:デフォルトの名無しさん
20/11/01 17:52:41.96 m91l8dFg.net
馬鹿たちかい。
サーバーサイドでステート維持するのは
実装大変だし、バカ高いコストになりますよ。
スケールの設計とかした事あんですかね？

87:デフォルトの名無しさん
20/11/01 18:17:26.00 6C0NmMQH.net
ステートサーバー用意するだけだな
簡単にスケールする
SPAにすると最初はフロントにステートがあったんだけど
SEOとか諸々の事情でやっぱSSRにしなきゃってなって
サーバーサイドにめちゃくちゃステートを持つことになる
ステートをスケールしたいだけなのにフロントもスケールもしなきゃならなくなって最悪

88:デフォルトの名無しさん
20/11/01 18:42:58.59 m91l8dFg.net
>>87
スーテトサーバー

笑

89:デフォルトの名無しさん
20/11/01 18:49:19.76 CuITjVo7.net
SSRにしたらサーバーにめちゃめちゃステート？笑
エアプここに極まるｗｗｗ

90:デフォルトの名無しさん
20/11/01 18:53:46.69 6C0NmMQH.net
>>88
なにわろてんねん
 >>89
お前がエアプ

91:デフォルトの名無しさん
20/11/01 18:58:35.18 m91l8dFg.net
>>88
ステートだ
笑

92:デフォルトの名無しさん
20/11/01 19:07:51.52 6C0NmMQH.net
>>91
ステートサーバーも知らねえのか？

93:デフォルトの名無しさん
20/11/01 19:52:37.28 afatmBQ+.net
>>88
え

94:デフォルトの名無しさん
20/11/01 20:25:37.03 kxmM4HKM.net
ステートサーバーってガチで何

95:デフォルトの名無しさん
20/11/01 20:32:08.23 m91l8dFg.net
>>94
低脳が使うやつ。

96:デフォルトの名無しさん
20/11/01 20:34:01.14 m91l8dFg.net
MSの基地外じゃね？

97:デフォルトの名無しさん
20/11/01 20:46:35.28 wlH1XftD.net
redisとかじゃねぇの

98:デフォルトの名無しさん
20/11/02 02:53:11.95 ZpVsHyOp.net
SvelteはNY Timesのほかに
Square Enix
Apple
Spotify
Google Arts
Alaska Airlines
などが使い出したようだ
超頑張れ

99:デフォルトの名無しさん
20/11/02 14:29:41.24 WhiKrslV.net
URLﾘﾝｸ(qiita.com)

100:デフォルトの名無しさん
20/11/02 19:37:37.29 bHgm/NDo.net
もういい加減クソみたいなアプリ開発するのも
メンテするのもウンザリだ

101:デフォルトの名無しさん
20/11/03 15:18:43.93 4OxOM+4k.net
jsからいかにして逃げるか、が今後のwebエコシステム成功の鍵になるだろうね
jsの上にフレームワークを乗せる方式にはも限界が来てる
svelteやblazorがその礎になるだろう

102:デフォルトの名無しさん
20/11/03 15:38:32.86 Ir5rYGmc.net
エアプ乙。
svelteはjs。
reactやvueなんかよりもjsらしいjs。
mskk真面目に仕事しろ。

103:デフォルトの名無しさん
20/11/03 16:09:19.65 5u+9d5PC.net
Svelteの利点はコンパイラ言語というとこ
つまりその気になれば別の言語でも同じことができるということだ
JavaやC#に置き換えるといったことも可能だろうね

104:デフォルトの名無しさん
20/11/03 16:14:13.80 GWTG5CXG.net
もうこれでいいんじゃね？
Google Web Toolkit (GWT) は、Javaを使ってウェブ用Ajaxアプリケーションを開発できるオープンソースのJavaソフトウェア開発フレームワークである。Apache License 2.0でライセンスされている
URLﾘﾝｸ(ja.wikipedia.org)

105:デフォルトの名無しさん
20/11/03 16:15:48.21 GWTG5CXG.net
Google Web Toolkit：現実的な開発に即したAJAX
URLﾘﾝｸ(codezine.jp)
JavaをJavaScriptとHTMLに変換する開発フレームワークの利用
　AJAXアプリケーションの開発は簡単なものではありません。というのも、
AJAX（Asynchronous JavaScript and XML）の開発言語であるJavaScriptの
全貌を把握している開発者はほとんどいないからです。さらに悪いことに、
JavaScriptの実装はブラウザによって違いがあるため、互換性という厄介な問題もあります
（「補足記事1　以前のWeb UIおよびAJAXのJavaScriptの弱点」を参照）。
GmailとGoogle MapsによってAJAXの名を知らしめたGoogleが、
この問題を解決するために世に送り出したのがGoogle Web Toolkit（GWT）です。

106:デフォルトの名無しさん
20/11/03 16:22:23.19 5u+9d5PC.net
考え方としては同じことだね
昔から求められ研究されていたものが周辺技術の進歩により実用的な段階になりつつある
AIも昔からあるけど実用化したのはごく最近だった
WEBの世界でもまた同じようにイノベーションが起こる
JSは世界に不要です

107:デフォルトの名無しさん
20/11/03 16:23:49.40 GWTG5CXG.net
昔から何度も負けてる歴史

108:デフォルトの名無しさん
20/11/03 16:28:30.69 5u+9d5PC.net
そして次は勝つ
時代の節目ってのはいつもそうだった

109:デフォルトの名無しさん
20/11/03 16:31:55.29 GWTG5CXG.net
「次は勝つ」と言ってるやつは、たいてい期限を付けない
いつまでに勝てるという見通しがないからだ
負けたら「次は」更に負けても「次は」と言い続ける

110:デフォルトの名無しさん
20/11/03 17:51:06.56 XR+zjtJR.net
JSすらまともに使いこなせない
不十分な負け犬の遠吠えにしか
聞こえないけど。

111:デフォルトの名無しさん
20/11/03 18:27:50.80 5u+9d5PC.net
使いこなした上でより良い道具を模索するのがプロ
jsにしがみつく人は駄目だ

112:デフォルトの名無しさん
20/11/03 19:10:53.10 XR+zjtJR.net
使いこなしてなさそーーなのから返信きた！

笑

113:デフォルトの名無しさん
20/11/03 19:17:24.29 M97chx1r.net
PHPの機能ではなくHTMLの機能で他HTMLのインクルードがないのは不便
これが出来ればかなり可能性広がる

114:デフォルトの名無しさん
20/11/03 20:12:28.79 C42spRT+.net
JavaScriptなんか使いこなせるようになってもなあ

115:デフォルトの名無しさん
20/11/03 20:19:41.36 XR+zjtJR.net
>>113
具体的に？

116:デフォルトの名無しさん
20/11/03 20:49:36.32 M97chx1r.net
>>115
HTML部品を細かく外部部品にできる
cssとかJavaScriptとか画像付きで
サーバサイドのクソインクルードと違ってdevtoolsから
呼び出し関係を把握出来る

117:デフォルトの名無しさん
20/11/03 20:54:04.83 OA2PBkaW.net
部品ごとにリクエスト走るの？クソやん

118:デフォルトの名無しさん
20/11/03 20:54:11.24 Vb+pPlne.net
バージョンアップですぐに知識が陳腐化するのが問題だよな
Reactが一番メジャーと言っても、他にもたくさんあるし、React自身もバージョンアップで変わるし、Reactの周辺技術も変わるし

119:デフォルトの名無しさん
20/11/03 21:01:35.34 XR+zjtJR.net
>>116
ReactやVuejsのコンポネント
あるいは純粋なWeb Componentsではダメという事？

120:デフォルトの名無しさん
20/11/03 21:13:02.42 M97chx1r.net
ソースと画面上のdevtool解析に差異があるから不便

121:デフォルトの名無しさん
20/11/03 21:20:57.47 XR+zjtJR.net
>>120
ん？
使ってもいない人かな？

122:デフォルトの名無しさん
20/11/03 23:12:36.36 GS5jRb/7.net
それだけならejsとかのテンプレートエンジンでいいのでは

123:デフォルトの名無しさん
20/11/04 00:27:26.22 ICDUObZn.net
jsを嫌ったところでweb開発では結局npmライブラリ使うんだからjs/tsからは逃れられんと思うけどね

124:デフォルトの名無しさん
20/11/04 09:32:04.09 CWKX+qbt.net
JSは嫌いじゃない。むしろ肯定する
嫌いなのはサーバサイドのビューの生成支援技術
特にDBやモデル層と密結合してるものは最悪
とりあえず純粋なデータの形でJSON化して文字化け防止
エンコしてJavaScript側に埋め込んどけば
JavaScriptで復元して、いかようにでもビュー構築
できるのに
そういう事を知らない奴がサーバサイドフレワの
ゴミみたいなビュー機能使いやがる

125:デフォルトの名無しさん
20/11/04 09:52:12.35 TofTvuAt.net
パッケージ問題はwasmにビルドして相互運用って形なるので気にしなくていい
JSが消え去るのも時間の問題だ

126:デフォルトの名無しさん
20/11/04 09:59:29.81 5hLgPx47.net
>>124
サーバーサイドならModelが型を持ってるからメタデータを処理してCRUDを生成するなんてことが実用的な水準でできるけどJSONじゃ無理でしょ？

127:デフォルトの名無しさん
20/11/04 12:51:36.28 nYZgiQyo.net
サーバーサイドで完結するなら遅延評価とかでDBへの負担を最小にできるけど、一旦JSONにするとN+1とかリクエスト連発とか高負荷になるもんな
それでGraphQLとか流行り始めてるけど

128:デフォルトの名無しさん
20/11/04 12:56:06.12 LzSTpY+2.net
domain modelからview modelへの変換も実装量としては無視できない
これをスクリプトでやるなんて正気じゃないよ

129:デフォルトの名無しさん
20/11/04 15:17:00.07 wF8lqQTT.net
GWTってまだ生きてたんか
SWTと同じくらい長生きだな

130:デフォルトの名無しさん
20/11/04 16:54:45.12 sbTiCV0L.net
URLﾘﾝｸ(dev.to)
wasmって今のところjsよりそんなに極端に速いわけではなさそうだけど
普通のwebアプリをwasmにしても大して恩恵は受けられないんじゃ

131:デフォルトの名無しさん
20/11/04 18:28:12.23 annEOGEQ.net
>>130
ゲームとかのグラフィックス用途だけだよ。

132:デフォルトの名無しさん
20/11/04 19:30:08.96 CWKX+qbt.net
鯖の負荷を減らすにはクライアントサイドの
ブラウザに仕事させるのが最善
ネットワークアクセスが頻繁になるけかもしれんが
キープアライブとかあるし大した問題ではない
同時接続数はローバラ噛ませてスケールアウト
擦るのが定石でそれだけ利益産むだけの接続数が
来てるんだから必要経費
サーバサイドはレンダリング支援は要らん
バリデーションはフロントサイドとDBの制約で十分
ハッキングしてくる奴に律儀にエラーメッセージ
返してやったりエラーハンドリングしてやる必要ないからな
関連はJOIN覚えろ
ORMとかクエリビルダとかクソなんだよ
最悪複数回SQL飛ばせば外部テーブルのレコード取ってきたり
SQL飛ばさずに連想配列の配列からデータ漁るメソッド
作っとけば工夫すればコーディング爆速になるのに
ちまちまとバリデーションとかリレーションとか
定義するフレームワークは馬鹿
つまりwebアプリは全部糞なんだよ！
ネイティブJavaScriptが至高
ネイティブSQLが至高
expressのみが至高

オブジェクト指向は死ね！
RailsもララベルもReactもAnglarも死ね！

133:デフォルトの名無しさん
20/11/04 19:35:24.63 rm1hfGRH.net
クライアントでやれと言いつつ
結合はサーバーでやれと？

134:デフォルトの名無しさん
20/11/04 22:48:53.58 K1ME6Nao.net
相手したらあかんやつや

135:デフォルトの名無しさん
20/11/04 23:20:52.63 8aX5ek4k.net
どっちがサーバでどっちがクライアントかも分かってないぞそいつ
お茶碗持つほうが鯖とかそんなレベル

136:デフォルトの名無しさん
20/11/05 00:10:38.34 cYudjgB5.net
>>135
お茶碗持つほうが鯖はさすがに草

137:デフォルトの名無しさん
20/11/05 07:06:59.54 zkmm5QOl.net
jQueryバカがボコボコに論破するたび過激になって帰ってきて草

138:デフォルトの名無しさん
20/11/05 07:09:42.40 zkmm5QOl.net
>>120
debugビルドでsourcemap吐き出させると
devtool上でも手書きのソースが表示されるよ

139:デフォルトの名無しさん
20/11/06 23:55:42.90 dY0FwNqN.net
スレタイAngular外されたか
個人的には好きなんだけど使う奴が少ないんだよなあ
Angular+nest+typeormの組み合わせが快適で重宝してる

140:デフォルトの名無しさん
20/11/07 00:19:17.46 4eYXXeZK.net
遅かれ早かれすべて外されるよｗ

141:デフォルトの名無しさん
20/11/07 13:47:20.36 H4/lc4DC.net
じきにwasmスレになるだろうね

142:デフォルトの名無しさん
20/11/07 22:00:52.91 vkENrb2s.net
普通にDOM操作してる分にはJSで十分速いんだよなぁ。
最近WasmでFFmpegをブラウザに移植、とかあったし、TensorflowでWasm利用したりしてる。
そういう従来PCやサーバのOS上で直に動いていた物がそのままWebに移植されて予想もしてなかった新しい組み合わせを生む、みたいな方向性に期待してる。

143:デフォルトの名無しさん
20/11/07 22:17:58.99 alCltY04.net
十分速いもなにも、現状DOM APIはJS用しかない。WASMにもないのでJS経由でないといじれない。
偉そうに宣伝してくる他言語のフレームワークも最終的にJSのAPI呼んでる。

144:デフォルトの名無しさん
20/11/08 06:37:58.90 Xo0sFQ6l.net
>>143
Domを使う場合JSがネイティブだね。
Wasmの場合canvasに直接描画するのが本流。ゆえにDom上のUI資産は一切使えない。

145:デフォルトの名無しさん
20/11/08 07:21:32.68 LFeopa9V.net
wasmでUInt8Array作ってcanvasに流し込む形かな。ゲームとかならそれで良さそう。
いやでもゲームなら高速描画を求めてWebGLやcanvasのAPI使うからwasmで完結はしないかも。
ゲーム以外だとUI周り全部wasmで描くとランタイム大きくなるし。

146:デフォルトの名無しさん
20/11/08 08:21:28.89 YnyAcD/m.net
ゲームとかだったらいいんだけどねぇ。
複合UIをCanvasベースで作り直しとかｗ
CSSのレスポンシブ関連機能相当のものやイベントシステムも再実装か？ｗ

147:デフォルトの名無しさん
20/11/08 11:55:41.56 n8ymm8S9.net
id変えて3連投
内容もトンチンカンだし
何がしたいんだ

148:デフォルトの名無しさん
20/11/08 11:56:26.00 n8ymm8S9.net
土曜も含めて5連投か

149:デフォルトの名無しさん
20/11/08 12:22:25.95 Xo0sFQ6l.net
馬鹿登場(^o^)

150:デフォルトの名無しさん
20/11/08 12:48:49.25 LFeopa9V.net
何か変な事言ってる？

151:デフォルトの名無しさん
20/11/08 12:59:39.96 Xo0sFQ6l.net
ID:n8ymm8S9
こいつ

152:デフォルトの名無しさん
20/11/08 14:26:55.01 l0qFfY14.net
canvasで描画されたサイトはスクレイピングできなそうだけどどうなの

153:デフォルトの名無しさん
20/11/08 16:13:42.91 0eCVrRMZ.net
>>144
>Wasmの場合canvasに直接描画するのが本流。ゆえにDom上のUI資産は一切使えない。
別に「一切使えない」という訳ではない。
Edit要素やチェックボックスなんかをHTMLのFormで書きたい人はWasmからでも
書ける。
例えば、EmscriptenならC++ソース内でEM_ASMの中にJSコードが書けるので
そこでなんでもHTMLコードは書ける。

154:デフォルトの名無しさん
20/11/08 16:17:14.07 0eCVrRMZ.net
>>152
基本その通りで、AI技術などを使わない限りはページを解析できなくなる。
だから文書中のキーワードから自動的に検索エンジンに登録される事ができなく
なってしまう。
その意味で検索エンジンに登録して欲しい内要はcanvasで書かずに
HTMLのtextareaやpやdiv要素などの中に書いた方が良い。
そしてWasmを使ってもそのようにすることは可能。

155:デフォルトの名無しさん
20/11/08 16:32:27.74 477xwJw7.net
ただそうするとwasmを使う意味がなくなる

156:デフォルトの名無しさん
20/11/08 16:41:28.75 Xo0sFQ6l.net
>>152
Wasmに求められてる事のは、
ブラウザー内でネイティブアプリを動作させることでは？

157:デフォルトの名無しさん
20/11/08 16:42:06.83 Xo0sFQ6l.net
>>155
JS使えないのがWebが主流になったからって
慌ててWasmに逃げようかと考えるから
そんな疑問になる。

158:デフォルトの名無しさん
20/11/08 16:50:00.20 0eCVrRMZ.net
>>156
例えば、Win32のEditControl相当のものは、canvasで作ることも出来るが
pre要素で作ろうと思えば作れる。
例えばqiitaのプログラムコードの表示はpreタグで作られているから
それと同じことをWasmでやればよい。

159:デフォルトの名無しさん
20/11/08 16:54:09.62 Xo0sFQ6l.net
Wasmでsilverlightの土台整ったんで
是非復活してください。

160:デフォルトの名無しさん
20/11/08 18:10:44.66 4ZBfhd92.net
googleのクローラーさんがwasm読めるように頑張ってくれれば良いだけだよね
あとは任せた

161:デフォルトの名無しさん
20/11/08 18:40:18.29 LFeopa9V.net
いくらGoogleのクローラでもCanvasに独自実装されたUI全てに対応するのはちと辛かろう（リソース食う量が段違いだし）。有名フレームワークがあるならそれに対応するのはあるかも。
フレームワークがSEOに弱いとわかりつつwasmに行くのが先か、
wasmフレームワークが流行る可能性があるとGoogleがクローラを進化させるのが先か。
等面俺は普通にDOM使うかな～

162:デフォルトの名無しさん
20/11/08 18:47:40.39 qWxYWVGv.net
JSON LD

163:デフォルトの名無しさん
20/11/08 18:51:35.75 0eCVrRMZ.net
クローラーがcanvasの文字列に対応するには、(OCRみたいな)画像からの文字認識が必要。

164:デフォルトの名無しさん
20/11/08 18:53:52.25 0eCVrRMZ.net
ややこしいのは、HTMLだとテキストを全部、HTML要素の中に書いておいて
見えない領域は必要に応じてスクロールするようになっているが、
nativeとのマルチプラットフォームライブラリのWasmの場合だと独自に
スクロールして必要な部分しか画面には出さないので、文字認識しても
クローラーは見えない部分には対応しにくい。

165:デフォルトの名無しさん
20/11/08 20:33:25.42 JilxLgos.net
SEOとかLanding Pageだけ対応しとけばあとは割とどうでもいいんじゃないの？

166:デフォルトの名無しさん
20/11/08 21:32:11.88 Xo0sFQ6l.net
なんでSEOせにゃならん要件でWasm使うのかい？
もしかして某板の基地外？

167:デフォルトの名無しさん
20/11/09 15:47:31.41 FX8TY8PI.net
いや俺はSEO対策には詳しくないが、海外のサイトでWasmでcanvasで文字を
描画した場合に問題になることが議論されていたから、それに影響された。
もし、問題にならないと思うんなら別にそれでいい。

168:デフォルトの名無しさん
20/11/09 17:17:14.74 VFcbnqG0.net
> なんでSEOせにゃならん要件でWasm使うのかい？
これを読んで、SEOに悪影響はないという主張だと理解したわけ？
外国の方ですか？ｗ

169:デフォルトの名無しさん
20/11/09 19:02:52.34 FX8TY8PI.net
>>167 は >>165
へのコメントのつもりだった。

170:デフォルトの名無しさん
20/11/09 20:59:08.82 kTDxgGid.net
これすごくない？
ブラウザ上で動画生成や変換ができるWebAssembly版FFmpeg「ffmpeg.wasm」レビュー
URLﾘﾝｸ(gigazine.net)

171:デフォルトの名無しさん
20/11/09 21:02:21.41 Pd2sIgMn.net
いよいよJSもオワコンか
長い暗黒時代だった

172:デフォルトの名無しさん
20/11/09 21:21:29.85 TdfpQ1ub.net
reactでhooksが主流の今、reduxを学習する意味は大きいだろうか？

173:デフォルトの名無しさん
20/11/09 21:26:32.07 IuElySO5.net
安心しろ

どうせhooksもすぐ消える

174:デフォルトの名無しさん
20/11/09 22:03:01.37 fNXcH97V.net
確かに

175:デフォルトの名無しさん
20/11/10 07:06:06.27 vuF+5ADy.net
setXXXってネーミング、いまいちだよな

176:デフォルトの名無しさん
20/11/10 23:46:01.54 fk8fv8d/.net
Vueって本当に簡単なんですか？
言うことを聞いてくれなくて時間の浪費が半端ないです。
これを乗り越えた先にパラダイスはあるのか

177:デフォルトの名無しさん
20/11/11 01:36:23.59 a7EdH0Sq.net
ないよ
今、JavaScriptやjQueryで苦労してる人が
使うものであって、苦労していなければ Vue を使っても
使いづらくなるだけ
使う目的が違ってる。Vue に適したことじゃないと
Vue を使うのはデメリットしかない

178:デフォルトの名無しさん
20/11/11 10:25:16.82 tAzuyT8U.net
イベントループでcpu100%ですね判ります

179:デフォルトの名無しさん
20/11/11 16:18:28.96 I+IsX3ig.net
ReactやVueは最初が辛いですが、一度覚えてしまえば一生使える技術ですので。

180:デフォルトの名無しさん
20/11/11 16:24:54.56 3P5nZf65.net
>>179
なわけ

181:デフォルトの名無しさん
20/11/11 16:46:28.44 7b/Ck3VW.net
>>176
一応真面目に答えると天地の差でパラダイスになるけど、、
言う事を聞かないってのが何を指してるのか分からんとなんとも

182:デフォルトの名無しさん
20/11/11 16:56:32.16 uSbtgdeR.net
>>181
どんなときにパラダイスになりましたか？
具体例を聞かせてください

183:デフォルトの名無しさん
20/11/11 17:51:10.78 YsOPtgNE.net
何がどう難しいのかさっぱりわからん
フレームワークって単にその仕様を覚えるかマニュアルみて調べるだけじゃん
もしマニュアルみてもわからないならお前の能力がゴミなだけ

184:デフォルトの名無しさん
20/11/11 18:17:26.74 5hZ83BHh.net
マニュアルに、こういう場合はこうするって
全てのパターンが網羅されてるなら、そのとおりだろうね（笑）
難しいところがない＝考えることがなにもないってことだから馬鹿でもできるね