20/10/27 13:09:05.31 5aYZ+KyB.net
実際どうなん？
※Angularは残念ながら全く話題にならなかったのでSvelteに差し替えました
Vue
URLﾘﾝｸ(jp.vuejs.org)
React
URLﾘﾝｸ(reactjs.org)
Svelte
URLﾘﾝｸ(svelte.dev)
※前スレ
Vue vs React vs Angular Part.5
ｽﾚﾘﾝｸ(tech板)
★ここではjQuery, Ruby, C#, Blazorの話題は禁止です
★jQuery, Ruby, C#, Blazorｷﾁｶﾞｲが書き込んでも無視してください
Angular, Next, Nuxt, Sapper, Gatsby, VuePress, RedWoodなどはおｋ。
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とか画像付きで
サーバ
117:サイドのクソインクルードと違ってdevtoolsから 呼び出し関係を把握出来る
118:デフォルトの名無しさん
20/11/03 20:54:04.83 OA2PBkaW.net
部品ごとにリクエスト走るの？クソやん
119:デフォルトの名無しさん
20/11/03 20:54:11.24 Vb+pPlne.net
バージョンアップですぐに知識が陳腐化するのが問題だよな
Reactが一番メジャーと言っても、他にもたくさんあるし、React自身もバージョンアップで変わるし、Reactの周辺技術も変わるし
120:デフォルトの名無しさん
20/11/03 21:01:35.34 XR+zjtJR.net
>>116
ReactやVuejsのコンポネント
あるいは純粋なWeb Componentsではダメという事？
121:デフォルトの名無しさん
20/11/03 21:13:02.42 M97chx1r.net
ソースと画面上のdevtool解析に差異があるから不便
122:デフォルトの名無しさん
20/11/03 21:20:57.47 XR+zjtJR.net
>>120
ん？
使ってもいない人かな？
123:デフォルトの名無しさん
20/11/03 23:12:36.36 GS5jRb/7.net
それだけならejsとかのテンプレートエンジンでいいのでは
124:デフォルトの名無しさん
20/11/04 00:27:26.22 ICDUObZn.net
jsを嫌ったところでweb開発では結局npmライブラリ使うんだからjs/tsからは逃れられんと思うけどね
125:デフォルトの名無しさん
20/11/04 09:32:04.09 CWKX+qbt.net
JSは嫌いじゃない。むしろ肯定する
嫌いなのはサーバサイドのビューの生成支援技術
特にDBやモデル層と密結合してるものは最悪
とりあえず純粋なデータの形でJSON化して文字化け防止
エンコしてJavaScript側に埋め込んどけば
JavaScriptで復元して、いかようにでもビュー構築
できるのに
そういう事を知らない奴がサーバサイドフレワの
ゴミみたいなビュー機能使いやがる
126:デフォルトの名無しさん
20/11/04 09:52:12.35 TofTvuAt.net
パッケージ問題はwasmにビルドして相互運用って形なるので気にしなくていい
JSが消え去るのも時間の問題だ
127:デフォルトの名無しさん
20/11/04 09:59:29.81 5hLgPx47.net
>>124
サーバーサイドならModelが型を持ってるからメタデータを処理してCRUDを生成するなんてことが実用的な水準でできるけどJSONじゃ無理でしょ？
128:デフォルトの名無しさん
20/11/04 12:51:36.28 nYZgiQyo.net
サーバーサイドで完結するなら遅延評価とかでDBへの負担を最小にできるけど、一旦JSONにするとN+1とかリクエスト連発とか高負荷になるもんな
それでGraphQLとか流行り始めてるけど
129:デフォルトの名無しさん
20/11/04 12:56:06.12 LzSTpY+2.net
domain modelからview modelへの変換も実装量としては無視できない
これをスクリプトでやるなんて正気じゃないよ
130:デフォルトの名無しさん
20/11/04 15:17:00.07 wF8lqQTT.net
GWTってまだ生きてたんか
SWTと同じくらい長生きだな
131:デフォルトの名無しさん
20/11/04 16:54:45.12 sbTiCV0L.net
URLﾘﾝｸ(dev.to)
wasmって今のところjsよりそんなに極端に速いわけではなさそうだけど
普通のwebアプリをwasmにしても大して恩恵は受けられないんじゃ
132:デフォルトの名無しさん
20/11/04 18:28:12.23 annEOGEQ.net
>>130
ゲームとかのグラフィックス用途だけだよ。
133:デフォルトの名無しさん
20/11/04 19:30:08.96 CWKX+qbt.net
鯖の負荷を減らすにはクライアントサイドの
ブラウザに仕事させるのが最善
ネットワークアクセスが頻繁になるけかもしれんが
キープアライブとかあるし大した問題ではない
同時接続数はローバラ噛ませてスケールアウト
擦るのが定石で それだけ利益産むだけの接続数が
来てるんだから必要経費
サーバサイドはレンダリング支援は要らん
バリデーションはフロントサイドとDBの制約で十分
ハッキングしてくる奴に律儀にエラーメッセージ
返してやったりエラーハンドリングしてやる必要ないからな
関連はJOIN覚えろ
ORMとかクエリビルダとかクソなんだよ
最悪複数回SQL飛ばせば外部テーブルのレコード取ってきたり
SQL飛ばさずに連想配列の配列からデータ漁るメソッド
作っとけば工夫すればコーディング爆速になるのに
ちまちまとバリデーションとかリレーションとか
定義するフレームワークは馬鹿
つまりwebアプリは全部糞なんだよ！
ネイティブJavaScriptが至高
ネイティブSQLが至高
expressのみが至高
オブジェクト指向は死ね！
RailsもララベルもReactもAnglarも死ね！
134:デフォルトの名無しさん
20/11/04 19:35:24.63 rm1hfGRH.net
クライアントでやれと言いつつ
結合はサーバーでやれと？
135:デフォルトの名無しさん
20/11/04 22:48:53.58 K1ME6Nao.net
相手したらあかんやつや
136:デフォルトの名無しさん
20/11/04 23:20:52.63 8aX5ek4k.net
どっちがサーバでどっちがクライアント�
137:ｩも分かってないぞそいつ お茶碗持つほうが鯖とかそんなレベル
138:デフォルトの名無しさん
20/11/05 00:10:38.34 cYudjgB5.net
>>135
お茶碗持つほうが鯖はさすがに草
139:デフォルトの名無しさん
20/11/05 07:06:59.54 zkmm5QOl.net
jQueryバカがボコボコに論破するたび過激になって帰ってきて草
140:デフォルトの名無しさん
20/11/05 07:09:42.40 zkmm5QOl.net
>>120
debugビルドでsourcemap吐き出させると
devtool上でも手書きのソースが表示されるよ
141:デフォルトの名無しさん
20/11/06 23:55:42.90 dY0FwNqN.net
スレタイAngular外されたか
個人的には好きなんだけど使う奴が少ないんだよなあ
Angular+nest+typeormの組み合わせが快適で重宝してる
142:デフォルトの名無しさん
20/11/07 00:19:17.46 4eYXXeZK.net
遅かれ早かれすべて外されるよｗ
143:デフォルトの名無しさん
20/11/07 13:47:20.36 H4/lc4DC.net
じきにwasmスレになるだろうね
144:デフォルトの名無しさん
20/11/07 22:00:52.91 vkENrb2s.net
普通にDOM操作してる分にはJSで十分速いんだよなぁ。
最近WasmでFFmpegをブラウザに移植、とかあったし、TensorflowでWasm利用したりしてる。
そういう従来PCやサーバのOS上で直に動いていた物がそのままWebに移植されて予想もしてなかった新しい組み合わせを生む、みたいな方向性に期待してる。
145:デフォルトの名無しさん
20/11/07 22:17:58.99 alCltY04.net
十分速いもなにも、現状DOM APIはJS用しかない。WASMにもないのでJS経由でないといじれない。
偉そうに宣伝してくる他言語のフレームワークも最終的にJSのAPI呼んでる。
146:デフォルトの名無しさん
20/11/08 06:37:58.90 Xo0sFQ6l.net
>>143
Domを使う場合JSがネイティブだね。
Wasmの場合canvasに直接描画するのが本流。ゆえにDom上のUI資産は一切使えない。
147:デフォルトの名無しさん
20/11/08 07:21:32.68 LFeopa9V.net
wasmでUInt8Array作ってcanvasに流し込む形かな。ゲームとかならそれで良さそう。
いやでもゲームなら高速描画を求めてWebGLやcanvasのAPI使うからwasmで完結はしないかも。
ゲーム以外だとUI周り全部wasmで描くとランタイム大きくなるし。
148:デフォルトの名無しさん
20/11/08 08:21:28.89 YnyAcD/m.net
ゲームとかだったらいいんだけどねぇ。
複合UIをCanvasベースで作り直しとかｗ
CSSのレスポンシブ関連機能相当のものやイベントシステムも再実装か？ｗ
149:デフォルトの名無しさん
20/11/08 11:55:41.56 n8ymm8S9.net
id変えて3連投
内容もトンチンカンだし
何がしたいんだ
150:デフォルトの名無しさん
20/11/08 11:56:26.00 n8ymm8S9.net
土曜も含めて5連投か
151:デフォルトの名無しさん
20/11/08 12:22:25.95 Xo0sFQ6l.net
馬鹿登場(^o^)
152:デフォルトの名無しさん
20/11/08 12:48:49.25 LFeopa9V.net
何か変な事言ってる？
153:デフォルトの名無しさん
20/11/08 12:59:39.96 Xo0sFQ6l.net
ID:n8ymm8S9
こいつ
154:デフォルトの名無しさん
20/11/08 14:26:55.01 l0qFfY14.net
canvasで描画されたサイトはスクレイピングできなそうだけどどうなの
155:デフォルトの名無しさん
20/11/08 16:13:42.91 0eCVrRMZ.net
>>144
>Wasmの場合canvasに直接描画するのが本流。ゆえにDom上のUI資産は一切使えない。
別に「一切使えない」という訳ではない。
Edit要素やチェックボックスなんかをHTMLのFormで書きたい人はWasmからでも
書ける。
例えば、EmscriptenならC++ソース内でEM_ASMの中にJSコードが書けるので
そこでなんでもHTMLコードは書ける。
156:デフォルトの名無しさん
20/11/08 16:17:14.07 0eCVrRMZ.net
>>152
基本その通りで、AI技術などを使わない限りはページを解析できなくなる。
だから文書中のキーワードから自動的に検索エンジンに登録される事が
157:できなく なってしまう。 その意味で検索エンジンに登録して欲しい内要はcanvasで書かずに HTMLのtextareaやpやdiv要素などの中に書いた方が良い。 そしてWasmを使ってもそのようにすることは可能。
158:デフォルトの名無しさん
20/11/08 16:32:27.74 477xwJw7.net
ただそうするとwasmを使う意味がなくなる
159:デフォルトの名無しさん
20/11/08 16:41:28.75 Xo0sFQ6l.net
>>152
Wasmに求められてる事のは、
ブラウザー内でネイティブアプリを動作させることでは？
160:デフォルトの名無しさん
20/11/08 16:42:06.83 Xo0sFQ6l.net
>>155
JS使えないのがWebが主流になったからって
慌ててWasmに逃げようかと考えるから
そんな疑問になる。
161:デフォルトの名無しさん
20/11/08 16:50:00.20 0eCVrRMZ.net
>>156
例えば、Win32のEditControl相当のものは、canvasで作ることも出来るが
pre要素で作ろうと思えば作れる。
例えばqiitaのプログラムコードの表示はpreタグで作られているから
それと同じことをWasmでやればよい。
162:デフォルトの名無しさん
20/11/08 16:54:09.62 Xo0sFQ6l.net
Wasmでsilverlightの土台整ったんで
是非復活してください。
163:デフォルトの名無しさん
20/11/08 18:10:44.66 4ZBfhd92.net
googleのクローラーさんがwasm読めるように頑張ってくれれば良いだけだよね
あとは任せた
164:デフォルトの名無しさん
20/11/08 18:40:18.29 LFeopa9V.net
いくらGoogleのクローラでもCanvasに独自実装されたUI全てに対応するのはちと辛かろう（リソース食う量が段違いだし）。有名フレームワークがあるならそれに対応するのはあるかも。
フレームワークがSEOに弱いとわかりつつwasmに行くのが先か、
wasmフレームワークが流行る可能性があるとGoogleがクローラを進化させるのが先か。
等面俺は普通にDOM使うかな～
165:デフォルトの名無しさん
20/11/08 18:47:40.39 qWxYWVGv.net
JSON LD
166:デフォルトの名無しさん
20/11/08 18:51:35.75 0eCVrRMZ.net
クローラーがcanvasの文字列に対応するには、(OCRみたいな)画像からの文字認識が必要。
167:デフォルトの名無しさん
20/11/08 18:53:52.25 0eCVrRMZ.net
ややこしいのは、HTMLだとテキストを全部、HTML要素の中に書いておいて
見えない領域は必要に応じてスクロールするようになっているが、
nativeとのマルチプラットフォームライブラリのWasmの場合だと独自に
スクロールして必要な部分しか画面には出さないので、文字認識しても
クローラーは見えない部分には対応しにくい。
168:デフォルトの名無しさん
20/11/08 20:33:25.42 JilxLgos.net
SEOとかLanding Pageだけ対応しとけばあとは割とどうでもいいんじゃないの？
169:デフォルトの名無しさん
20/11/08 21:32:11.88 Xo0sFQ6l.net
なんでSEOせにゃならん要件でWasm使うのかい？
もしかして某板の基地外？
170:デフォルトの名無しさん
20/11/09 15:47:31.41 FX8TY8PI.net
いや俺はSEO対策には詳しくないが、海外のサイトでWasmでcanvasで文字を
描画した場合に問題になることが議論されていたから、それに影響された。
もし、問題にならないと思うんなら別にそれでいい。
171:デフォルトの名無しさん
20/11/09 17:17:14.74 VFcbnqG0.net
> なんでSEOせにゃならん要件でWasm使うのかい？
これを読んで、SEOに悪影響はないという主張だと理解したわけ？
外国の方ですか？ｗ
172:デフォルトの名無しさん
20/11/09 19:02:52.34 FX8TY8PI.net
>>167 は >>165
へのコメントのつもりだった。
173:デフォルトの名無しさん
20/11/09 20:59:08.82 kTDxgGid.net
これすごくない？
ブラウザ上で動画生成や変換ができるWebAssembly版FFmpeg「ffmpeg.wasm」レビュー
URLﾘﾝｸ(gigazine.net)
174:デフォルトの名無しさん
20/11/09 21:02:21.41 Pd2sIgMn.net
いよいよJSもオワコンか
長い暗黒時代だった
175:デフォルトの名無しさん
20/11/09 21:21:29.85 TdfpQ1ub.net
reactでhooksが主流の今、reduxを学習する意味は大きいだろうか？
176:デフォルトの名無しさん
20/11/09 21:26:32.07 IuElySO5.net
安心しろ
どうせhooksもすぐ消える
177:デフォルトの名無しさん
20/11/09 22:03:01.37 fNXcH97V.net
確かに
178:デフォルトの名無しさん
20/11/10 07:06:06.27 vuF+5ADy.net
setXXXってネーミング、いまいちだよな
179:デフォルトの名無しさん
20/11/10 23:46:01.54 fk8fv8d/.net
Vueって本当に簡単なんですか？
言うことを聞いてくれなくて時間の浪費が半端ないです。
これを乗り越えた先にパラダイスはあるのか
180:デフォルトの名無しさん
20/11/11 01:36:23.59 a7EdH0Sq.net
ないよ
今、JavaScriptやjQueryで苦労してる人 が
使うものであって、苦労していなければ Vue を使っても
使いづらくなるだけ
使う目的が違ってる。Vue に適したことじゃないと
Vue を使うのはデメリットしかない
181:デフォルトの名無しさん
20/11/11 10:25:16.82 tAzuyT8U.net
イベントループでcpu100%ですね判ります
182:デフォルトの名無しさん
20/11/11 16:18:28.96 I+IsX3ig.net
ReactやVueは最初が辛いですが、一度覚えてしまえば一生使える技術ですので。
183:デフォルトの名無しさん
20/11/11 16:24:54.56 3P5nZf65.net
>>179
なわけ
184:デフォルトの名無しさん
20/11/11 16:46:28.44 7b/Ck3VW.net
>>176
一応真面目に答えると天地の差でパラダイスになるけど、、
言う事を聞かないってのが何を指してるのか分からんとなんとも
185:デフォルトの名無しさん
20/11/11 16:56:32.16 uSbtgdeR.net
>>181
どんなときにパラダイスになりましたか？
具体例を聞かせてください
186:デフォルトの名無しさん
20/11/11 17:51:10.78 YsOPtgNE.net
何がどう難しいのかさっぱりわからん
フレームワークって単にその仕様を覚えるかマニュアルみて調べるだけじゃん
もしマニュアルみてもわからないならお前の能力がゴミなだけ
187:デフォルトの名無しさん
20/11/11 18:17:26.74 5hZ83BHh.net
マニュアルに、こういう場合はこうするって
全てのパターンが網羅されてるなら、そのとおりだろうね（笑）
難しいところがない＝考えることがなにもないってことだから馬鹿でもできるね
188:デフォルトの名無しさん
20/11/11 18:42:59.24 nXqLBwtd.net
ややこしいルール増えるだけでほんま役に立つんかと思いながらReact始めたけど、途中から目に見えて楽になったのを感じたし、それ以来リアクティブじゃないのは辛いなと思うようになるぐらいは変わった。
Reactが生き残るかどうかはわからないけど、Webの最新技術に触れようと思うと当然のようにReact要素が出てくるので、ある種の基盤になってるのかなと思う。
189:デフォルトの名無しさん
20/11/11 18:55:30.05 fgDzPNCB.net
ソースコード解析できないならフレームワークは使わないほうがいい
190:デフォルトの名無しさん
20/11/11 22:03:08.65 7b/Ck3VW.net
>>182
答えたいんだけど範囲が広すぎるよ
まず何を作ろうとしてるのか。何の期待してvue使おうと考えたのか。今困っている事(言う事を聞かない？)を具体的に。
この3つが分かるといいんだけどな。
もしかしてvue単独で既存のwebに組み込んで使おうとしてる？
191:デフォルトの名無しさん
20/11/12 20:33:37.13 Sh5uqHmw.net
Reactに近い考え方でもっと薄いライブラリねーかな
分厚いフレームワークあるあるの変な挙動に1日悩まされて結局バグだったみたいなことを避けたい
192:デフォルトの名無しさん
20/11/12 20:54:30.33 mC/HDmh/.net
jsxが欲しいのかリアクティブが欲しいのか
193:デフォルトの名無しさん
20/11/14 12:12:58.68 GBy4XzSZ.net
フレームワーク単体じゃなくてVSCodeとかwebStormとかのIDE、hotReload、cliでプロジェクト始めてビルドからdeployまで一貫させるとかgitとかtypescriptとかnpmとか諸々全部含めた上でのフレームワークだし。
194:デフォルトの名無しさん
20/11/14 18:59:52.77 DnZAmAgg.net
Angularだけは本当に誰も話題にしないな。
Angular 11リリースされたのに…
信者もアンチも居ない。
ただ誰も興味がない…
195:デフォルトの名無しさん
20/11/14 19:39:32.08 0tsO4jDn.net
海外だとAngularも人気あると思う
Reactが一番人気なのは間違いないけど
Vueは日本ではなぜか人気あると感じる
196:デフォルトの名無しさん
20/11/14 20:30:03.20 xpC3aUYM.net
後ろ盾の差でもう勝負ついてる
WebAssemblyが成熟するまでは間違いなくReactの一強
197:デフォルトの名無しさん
20/11/14 20:39:01.51 RVlgiIfZ.net
後ろ盾で言うとマイクロソフトが最高だね
198:デフォルトの名無しさん
20/11/14 20:42:50.63 rQXll7XK.net
Silverlightはどうなりましたか？
199:デフォルトの名無しさん
20/11/14 20:44:10.62 RVlgiIfZ.net
シルバーライトは時代を先取りしすぎてたな
そろそろ世間が追いついてくるかもしれん
200:デフォルトの名無しさん
20/11/14 20:56:10.64 0tsO4jDn.net
MVVMとかSilverlightからなんだよな
201:デフォルトの名無しさん
20/11/14 21:07:49.82 lpnmdlKx.net
つまりTSさいつよ
202:デフォルトの名無しさん
20/11/15 14:17:52.80 1NoBqfO6.net
アプデされてもすぐに飛びつく気にはならない
203:デフォルトの名無しさん
20/11/22 18:15:13.92 LBpBJ7Cn.net
Blazor and ASP.NET Core Get Faster in .NET 5 -- Visual Studio Magazine
URLﾘﾝｸ(visualstudiomagazine.com)
204:デフォルトの名無しさん
20/11/22 19:38:35.43 bLh5qcao.net
Angular はリリースのペースが早すぎてなぁ
一年に一回で三年ぐらいメンテならまだわかるけど
半年に一回メジャーはなぁ
205:デフォルトの名無しさん
20/11/25 11:51:59.83 qHSWN3Iy.net
サイトとアプリは分けるべき
URLﾘﾝｸ(www.swyx.io)
これホントその通りやと思った
206:デフォルトの名無しさん
20/11/25 13:02:40.07 76EvKzfL.net
Svelte側の意見なので、そらそういう話になるよね。
でも確かに普通のサイトをSSGするならReactはオーバースペックだなぁ
207:デフォルトの名無しさん
20/11/25 17:15:48.68 z9WVjUI8.net
もしかしてそれわかってない人が居るのか
208:デフォルトの名無しさん
20/11/26 01:20:18.60 4tpBk6Dz.net
>>204
歴代このスレでそう言うヤツが何回も暴れてたぞ
209:デフォルトの名無しさん
20/11/26 13:20:36.57 BChkjCh/.net
>>204
脱jQueryとか言ってた奴らは多かったよ
なんのために脱jQueryするのか理由がなかった
脱jQueryが目的となってた
そして生産性を落とした
210:デフォルトの名無しさん
20/11/26 13:24:55.51 BChkjCh/.net
>>203
> でも確かに普通のサイトをSSGするならReactはオーバースペックだなぁ
オーバースペックと言うか用途にあっていない
沢山人を運ぶのに、バスじゃなくてトレーラーを使うようなもの
運べる人数の数なら、トレーラのほうが多いから
オーバースペックに見えるかもしれんが、そうじゃない
快適さが重要
211:デフォルトの名無しさん
20/11/26 17:29:45.49 9V4+FLts.net
ちょっと待て
>202 はReactが不要という話じゃなくてjQueryも含めた何でもできるライブラリは（場合によって）要らんという話でしょ。
Svelteは必要十分な機能で2kBのフットプリントと覚える事が少ないってのが売り。使った事ないから良く知らんけど
212:デフォルトの名無しさん
20/11/26 17:56:42.76 G38Bo7Tb.net
何でもできるのは別にいいんじゃないの？
駄目なのは使ってないコードまで転送してしまうこと
Wasmならビルド時に不要なコードを除外できる
213:デフォルトの名無しさん
20/11/26 18:29:22.37 Qr7Z7FCB.net
「wasmなら」は関係なかったな
「ビルドプロセスを挟めば」だ
214:デフォルトの名無しさん
20/11/26 19:12:47.40 9V4+FLts.net
ビルドプロセスでTree Sharking 使っても大きいライブラリはやっぱりフットプリント大きいよ。
それと覚える事の大きさ、も考えると小さい方が良いってニュアンスみたい。
大は小を兼ねる、一個覚えて全部やるって発想ももちろんありだとは思うけどね。
215:デフォルトの名無しさん
20/11/26 19:24:55.45 hByK+2ee.net
>>210
いやwasmなら、であってる
スクリプトじゃビルドしても効率的にコード削除できない
216:デフォルトの名無しさん
20/11/26 19:37:54.99 X8IHc9pp.net
>>208
ReactユーザーからするとSvelteがコンポーネント化する作りには到底向いてるようには思えない
217:デフォルトの名無しさん
20/11/26 19:55:14.45 Qr7Z7FCB.net
>>212
wasmバイナリ自分で書いたことある？
いくらでも非効率にできるよ。
ビルドツールの問題。
218:デフォルトの名無しさん
20/11/26 20:17:37.03 9V4+FLts.net
既存の関数をwatのSIMDで書いた事あるけど、あれは面白かったな。慣れてないから速度は倍まで行かなかったし、無駄にメモリ食うようになっちゃったから止めたけど。
>>213
なるほど。そういうもんか
219:デフォルトの名無しさん
20/11/26 20:18:49.84 /zfTjyfU.net
わざわざCSSで動的なUIパーツ組む奴が理解できない
「CSSでも動的な動きができる」
は？出来るから何？
変数もifもforも関数も定義できない
console.logで出力してデバッグもできない
欠陥言語じゃん
マジで頼むからCSSで余計なことすんな
aタグとかいうゴミみたいなタグを安易に使うな
擬似クラスとかいうゴミに頼るな
buttonやspanにイベントリスナ仕掛ければ事足りること
イベントリスナも知らないくせにフロントエンド弄るな
JavaScriptで親タグの中身抹消したり
DOM要素を動的に作れる事も
DOM操作で丸々入れ替えられる事も
画面幅や座標の制御をできることも知らない癖に
DOM要素を隠したり詳しくもないくせに
displayやpositionやz-indexを安易に
いじるようなゴミみたいなCSSを書くな
220:デフォルトの名無しさん
20/11/26 20:41:02.28 4tpBk6Dz.net
>>216
もはや宗教的な理由でJavaScript使えないのかなって思う
221:デフォルトの名無しさん
20/11/26 20:54:19.82 iMILCtJS.net
＞ aタグとかいうゴミみたいなタグ
？？？
222:デフォルトの名無しさん
20/11/26 21:20:26.61 g5cj98vc.net
宗教的な理由というか、jsっていまいちな言語だとおもうよ
極力触りたくない。
tsが出てやっとこさまともに使える代物になったんじゃないのかな。
みんなそれぞれ習得した言語があると思うけど
jsしか習得してない人とそうでない人でこの辺意見分かれるところなんだろうね。
223:デフォルトの名無しさん
20/11/26 22:00:12.15 +6srE4/I.net
言うてPHPとかPythonよりええんちゃう？
224:デフォルトの名無しさん
20/11/26 22:46:23.54 4tpBk6Dz.net
宗教上の理由でjs使えないヤツってパターンビルド済みのoutputのjsも含まれるから当然tsも含まれるだろ
225:デフォルトの名無しさん
20/11/26 23:03:09.46 78SpiBmi.net
jsは特別優れた言語じゃないけど悪くもない
ブラウザ間の互換性のなさが最悪だっただけ
今でもあの時の印象を引きずって苦手意識を持ってる人が多い
226:デフォルトの名無しさん
20/11/26 23:15:00.61 12STscif.net
>>219
JavaScriptがイマイチなのは同感だけどCSSと比べたらどうよって事じゃないの？
CSSで複雑な事するよりはJavaScriptの方がデバッグ含め扱いやすいよねっていう
227:デフォルトの名無しさん
20/11/26 23:46:51.84 lXuD47Zd.net
何と比べてってのにもよるが。
php,python,rubyあたりと比べてってんなら鼻で笑うわｗ
228:デフォルトの名無しさん
20/11/27 00:51:48.53 eTtvQYiv.net
環境構築がめんどくさい
パッチワークみたい組合わさってて、常に何かがDeprecatedになって破壊的変更のアップデートされてるので、止まったら死ぬみたいな現実がある
229:デフォルトの名無しさん
20/11/27 01:03:02.30 lOUpIwv2.net
テレビ東京で、Amazon Killer のShopify を、取り上げていた
Amazonでは、売上の7～15%取られるけど、
Shopifyなら無料だから、日本でもブレイクする
益子の陶器市では、数千万円掛かるシステム構築運用費用が、
Shopifyで、月2万円ほどで出来たとか
JavaScript のクソみたいなフレームワークで時間を取られている間に、
また、Ruby on Rails から巨大企業が誕生するぞ！
230:デフォルトの名無しさん
20/11/27 01:25:44.09 eTtvQYiv.net
Shopify、確かに流行ってるね
SEOとか集客考えるとスクラッチで作るとかデメリット多すぎる
またjQueryの時代になるかもね
231:デフォルトの名無しさん
20/11/27 01:57:11.00 w5Az7J0d.net
だからjQueryが使われていた分野では
jQueryが一番適しているって言ってるだろう
232:デフォルトの名無しさん
20/11/27 03:00:11.25 qWxV0X/O.net
ただ、ShopifyがAmazonキラーかというとちょっと違うと思う
Amazonとか楽天よりも、BaseとかStorejpだね強豪は
この辺は根こそぎ持っていかれる気がする
233:デフォルトの名無しさん
20/11/27 03:20:10.49 W+zDVYCR.net
>>226
ShopifyはフロントエンドでJS用Shopify API読んで構築するんじゃん。バックエンド構築必要なし。
捨てられた数千万円掛かるシステム構築とやらがRailsだろｗｗｗ
234:デフォルトの名無しさん
20/11/27 11:01:06.84 A3ky2fOw.net
アマゾンは欲しいものリストが優秀で積み本の管理できるし
Kindle書籍も大分買ったしな
235:デフォルトの名無しさん
20/11/27 12:17:44.61 8PzTM5c0.net
aタグはゴミだよ
JavaScriptのイベントリスナで捕捉できない
隠れ画面イベントがこいつのせいで発生してしまう
spanにイベントリスナ仕掛けてれば
追加の処理を割り込ませることができるが
aタグでbefore afterとか使われるとJavaScriptを割込ませるのが
難しくなる
236:デフォルトの名無しさん
20/11/27 14:16:27.69 W+zDVYCR.net
？？？
いっこも難しくないが…
具体的に何が難しいの？
いくらなんでもザコ過ぎでは？ｗｗ
237:デフォルトの名無しさん
20/11/27 14:46:49.59 w5Az7J0d.net
>>232
aタグは単に他の要素とリンクしてると言うだけでしかない
aタグを使わないでどうやって他の要素とリンクしているという状態を
静的に定義するというのだ？ HTMLの基礎を勉強したほうがいい
238:デフォルトの名無しさん
20/11/27 20:12:40.59 8PzTM5c0.net
>>234
idか自作属性を両方に振るだけなんだよなぁ
239:デフォルトの名無しさん
20/11/27 20:30:17.42 49qWfbc9.net
> aタグでbefore afterとか使われるとJavaScriptを割込ませるのが難しくなる
なるほど言いたいことはわかった
でも結論が a タグはゴミになるのが全く理解できない
240:デフォルトの名無しさん
20/11/27 21:38:55.34 W+zDVYCR.net
全然言いたいこと分からん
なんで難しくなるんだ？
241:デフォルトの名無しさん
20/11/27 21:42:16.67 sCut4Zkr.net
SPAでaタグ使う話？
ちょっと話の前提が欲しいな
242:デフォルトの名無しさん
20/11/27 21:58:33.95 w5Az7J0d.net
>>235
> idか自作属性を両方に振るだけなんだよなぁ
意味不明。 今言ってるのは静的な情報の話だぞ
文書があって、この文書はどこそこへリンクしている
という静的な情報をどうやって作るんだ？
静的の意味がわかってないのか？
243:デフォルトの名無しさん
20/11/27 22:06:24.71 flyjSd/U.net
>>239
全く意味がわからん
静的な情報とはなんだ
244:デフォルトの名無しさん
20/11/27 22:17:22.45 w5Az7J0d.net
>>240
定義されて変わらないってことだ
状態が変わらなければ、テストする必要がなくなる
constといえばわかるか？
関数型を勉強したほうがいいぞ
245:デフォルトの名無しさん
20/11/27 23:04:45.76 W+zDVYCR.net
それは不変では？
英語わからないおじさん？
static
dynamic
variable
constant
それぞれ英語に訳してみよう！(1 x 4 点)
246:デフォルトの名無しさん
20/11/27 23:07:18.33 W+zDVYCR.net
英語を、だったｗ
247:デフォルトの名無しさん
20/11/27 23:09:40.00 0Fqhj3Tv.net
JavaScriptにconst以外で静的なものってあるの？
248:デフォルトの名無しさん
20/11/27 23:17:45.58 W+zDVYCR.net
>>244
class構文にstaticってあるけど、
staticって、英語なんて訳す？
constはconstantの略だけど
constantってなんて訳す？
はい、レスして！
コピペ用↓
static→
constant→
249:デフォルトの名無しさん
20/11/28 06:23:01.14 nnMl4yOq.net
>>244
constに近いもの(immutable)なら
Object.freeze()
Object.create() の第2引数による指定
文字列
等がある
でも静的と言えばstaticかな
jsのstaticは実態がprototype付いてないだけのメンバだから言うほどstaticか？ みたいな気持ちになるけど
250:デフォルトの名無しさん
20/11/28 09:13:05.32 9//L8RlG.net
constだって言うほどconstantじゃないからおあいこ
251:デフォルトの名無しさん
20/11/28 10:43:41.96 nnMl4yOq.net
その点TSのas constってすげぇよな、最後までreadonlyたっぷりだもん
252:デフォルトの名無しさん
20/11/29 15:32:08.47 kn6Xy7Za.net
AppleのM1にはJavaScript専用命令が搭載されているらしい
253:デフォルトの名無しさん
20/11/29 15:57:23.85 sEIsLTyR.net
だからSafariだけ異常に速いんか
254:デフォルトの名無しさん
20/11/29 16:03:05.54 GqfPsnzc.net
Safariが遅いっていうよりも他のブラウザがめっちゃ高速化を励んでる中Safariだけ着いて行けなかったって感じじゃね？
255:デフォルトの名無しさん
20/11/29 16:40:38.32 +p4clpep.net
なぜJavaScript専用にするのか？
256:デフォルトの名無しさん
20/11/29 16:56:57.73 sOEBQUsx.net
Web見ないやつなんていないから。
用途が約束されてるのでメーカーにとって投資する価値がある。
googleなんかV8にいくらの金と時間かけたと思ってるんだ。
これら投資あってのスクリプト言語最速の地位よ。
257:デフォルトの名無しさん
20/11/29 17:13:31.04 GqfPsnzc.net
最近はそんなに聞かんけど
一時期MozilaもGoogleも新バージョンでJavaScriptの実行速度が2倍にとかよく言ってたもんな
258:デフォルトの名無しさん
20/11/29 17:21:54.90 +p4clpep.net
ふむ。ならばそのGoogleが作ったものを
利用すれば低コストで最高のものが手に入るな（笑）
259:デフォルトの名無しさん
20/11/29 17:24:12.79 GqfPsnzc.net
WebKitの時代はそうだったけどなんで喧嘩別れしたんだっけ？
260:デフォルトの名無しさん
20/11/29 17:33:36.17 kn6Xy7Za.net
非コンパイル言語としては規格外に速いもんなぁ
261:デフォルトの名無しさん
20/11/29 19:41:07.41 YNdyjjvH.net
人類規模で投資の仕方間違ったよな
スクリプトの高速化なんてやってないで、wasmに早期から取り組むべきだった
262:デフォルトの名無しさん
20/11/29 19:46:27.00 sOEBQUsx.net
wasmのブートストラップコードはjsなんだからjsが遅かったらwasmまで遅くなるじゃんバカなの
263:デフォルトの名無しさん
20/11/29 20:06:24.90 YNdyjjvH.net
バカには理解するのが難しいかもしれ
投資してればその無駄なブートストラップのJSが消えるだけ
264:デフォルトの名無しさん
20/11/29 20:16:31.99 TbmbElJ8.net
wasmが影も形も無かった頃、静的型付けでコンパイル言語でバイナリが実行ファイルで、サーバからクライアント、あらゆるマシンやブラウザ上で動く、しかもITの巨人たちがこぞって投資した。そんな凄い言語があったんです。
そんな言語でもJavaScriptの牙城は崩せませんでした
265:デフォルトの名無しさん
20/11/29 20:24:28.83 bza0LWNC.net
>>261
まだ投資が足りなかった
普及してれば人類のステージはもう何歩か先に進んでたのに惜しいことをしたな
この遅れが後々の宇宙人との戦争に響いてくる
266:デフォルトの名無しさん
20/11/29 20:57:40.64 MsV4ej8L.net
appletのこと？
267:デフォルトの名無しさん
20/11/29 22:03:16.18 8NXwxGIx.net
時系列おかしくね
268:デフォルトの名無しさん
20/11/29 22:09:24.49 +p4clpep.net
投資とかじゃなくてwasmが重かっただけの話
当時のブラウザじゃろくに動かない
ソフトウェアの世界は重いものより軽量のものが好まれる
269:デフォルトの名無しさん
20/11/29 22:41:32.13 Rb8oT144.net
そもそも、jsの置き換え用途として
wasmが用意された訳ではない。
270:デフォルトの名無しさん
20/11/29 22:46:49.01 sEIsLTyR.net
docker作ったやつが「wasmを知ってたらdocker作らんでも良かった」って言ってwasmのことを褒めてた記事を前見た
言ってる意味はよくわからなかったけど将来性あるんだろうなあって感じた
271:デフォルトの名無しさん
20/11/29 22:50:34.02 AbKwwhG3.net
webエンジニア全員でAppleボイコットすべきだろ
縮尺違うデバイス乱発しやがるし
safariとかいうゴミブラウザはまともに動作出来ないしよ
272:デフォルトの名無しさん
20/11/29 23:10:43.09 kn6Xy7Za.net
Safariは糞なんだけどなんだかんだ全盛期のIEよりはマシ。でもMacやiOS以外でテストできないのはホントやめて欲しい
273:デフォルトの名無しさん
20/11/29 23:12:09.34 HZy5s6KS.net
>>267
wasmのサーバーサイド向けのまともな処理系があれば確かにdockerいらないんだけどな
いかんせんwasmは仕様が貧弱すぎて
274:デフォルトの名無しさん
20/11/29 23:13:05.16 Z/yAEGW+.net
>>267
K8Sでwasm動かすオプション、マイクロソフトが作ってた気がする
外部コマンドとかに依存してないピュアなプログラムなら、wasmに乗せればどこでも動くからDocker要らん
275:デフォルトの名無しさん
20/11/29 23:37:25.38 Rb8oT144.net
サンドボックスから出れませんよ。
デスクトップネイティブの変わりにはなりません。
276:デフォルトの名無しさん
20/11/30 01:18:36.39 rn09M8ye.net
>>271
その「どこでも」にサーバーサイドは含まれていますか？
277:デフォルトの名無しさん
20/11/30 01:30:06.52 owcTZSsV.net
>>273
当たり前だろ…今誰がクライアントサイドの話をしてるんだよ…
クライアント側技術のwasmが、docker代わりにサーバで使えるかもね、どうだろうね、とそういう話だろうに。
278:デフォルトの名無しさん
20/11/30 01:31:07.01 iUHy/DDO.net
>>266
え？
もともと、EmscriptenがC/C++をasm.jsに変換していたのが、asm.jsがWasmに
進化したのだと思っていたが。
279:デフォルトの名無しさん
20/11/30 01:39:36.58 owcTZSsV.net
何の反駁にもなってない。jsの置き換え用途として
asm.jsが用意された訳ではない。
280:デフォルトの名無しさん
20/11/30 01:41:23.94 owcTZSsV.net
>>271
Krustletかな？
URLﾘﾝｸ(www.publickey1.jp)
281:デフォルトの名無しさん
20/11/30 03:09:11.88 m2msM8IC.net
えーこれJavaVMの再開発なんじゃ
282:デフォルトの名無しさん
20/11/30 07:16:39.65 +FPoUGVQ.net
wasmは
C++等の色んな言語の資産を活かせる。
JavaVMほどの起動時の遅さやフットプリントは必要ない。
GCが無い。
純粋なwasmではIOができない（データの永続化ができない）
のでJavaVMとは色々異なってて、サーバサイドではどちらかというとDockerぽいと感じるかな
283:デフォルトの名無しさん
20/11/30 09:05:29.99 FUbWMdS/.net
>>274
かもねじゃなくもうK8Sで使える
284:デフォルトの名無しさん
20/11/30 09:08:34.72 FUbWMdS/.net
いずれにせよJSは近いうちに終わる
COBOLやJavaみたいなレガシーの扱いになる
285:デフォルトの名無しさん
20/11/30 09:58:33.10 +FPoUGVQ.net
近いうちと言っても少なくともまだ5年ぐらいは無さそう。完全に置き換わるまでには10年くらい。全然置き変わらない可能性もある。
ま、無くなったって新しいの覚えるだけだ。言語が変わっても思想的に地続きなフレームワークが出るだろうし、何も無駄にはならないな
286:デフォルトの名無しさん
20/11/30 10:13:49.58 y87+I7Qr.net
JS終わってほしいけど数十年は終わらないと思う
287:デフォルトの名無しさん
20/11/30 10:28:21.64 +FPoUGVQ.net
何れにしてもポストJSを考えるには時期尚早感が強い。言語ベンダーとかフレームワーク屋ならともかく
288:デフォルトの名無しさん
20/11/30 10:38:55.43 rn09M8ye.net
>>281
> COBOLやJavaみたいなレガシーの扱いになる
それは終わるとは言わないｗ
お前はいちばん重要なことを忘れてるな
JavaScriptが一番少ない記述量・作業量で目的を達成できるのだから
wasmに取って代わることはない
289:デフォルトの名無しさん
20/11/30 10:43:07.99 bmm0MTRM.net
選挙でもそうだが政局なんてそう簡単にはひっくり返らんよ
290:デフォルトの名無しさん
20/11/30 10:43:56.07 rn09M8ye.net
世の中で本当に終わったといえる言語には特徴がある
1. 1ベンダーによる開発
2. その開発会社が終息を宣言、もしくはそれ相当の自体になった
これにギリギリ当てはまるのは
VB6とDelphiぐらいだろ
JavaScriptは多数の実装があるのでどうあっても終わらない
291:デフォルトの名無しさん
20/11/30 10:46:18.62 rn09M8ye.net
D言語やPerl5/6なんかもあったな
PHPも開発会社が終息を宣言すれば終わる可能性もある
Rubyは幾つか実装があるみたいだが
やっぱり本家が終われば終わる可能性もある
GoもGoogleだけかな
で、JavaScriptはこれらとは程遠い
292:デフォルトの名無しさん
20/11/30 10:46:30.21 bmm0MTRM.net
Delphiとエンバカデロってどうにかなったのか？
293:デフォルトの名無しさん
20/11/30 10:50:16.45 rn09M8ye.net
>>289
もう誰も気にしてないということ
294:デフォルトの名無しさん
20/11/30 12:33:18.66 0Mqgtux2.net
>>281
JSからネイティブコードが
呼び出せるようになるだろ。
295:デフォルトの名無しさん
20/11/30 12:37:42.55 PALovYd2.net
jsは終わらないけど
jsを使ったフレームワークやAltJSの類はどんどん移り変わるから大変だなあとは思う
バージョンアップしたときとかみんな着いていけてるのか？
296:デフォルトの名無しさん
20/11/30 12:58:24.94 +FPoUGVQ.net
フレームワーク作る側も変化が激しくて習得が負担になりうる事を意識してか、ルールが独特過ぎたり複雑過ぎ�
297:驍ﾌは最新減ってきたように思う
298:デフォルトの名無しさん
20/11/30 13:31:15.73 owcTZSsV.net
Pythonの高速ライブラリはCで書かれたネイティブモジュールだけどPythonはなくなりましたか。
え？なくなってない？じゃあなんでwasmでjsがなくなるのｗｗｗ
Pythonよりさらに状況悪くて、クライアントサイドではwasmはjs経由でしかロードもできないのにｗｗｗｗ
299:デフォルトの名無しさん
20/11/30 13:52:09.05 FUbWMdS/.net
何言ってんだこいつ
pythonのライブラリがCで書かれてるからと言ってクライアントまでCにする理由はない
なぜならCよりもpythonのほうが簡単だから
これはpythonと「pythonより速いが難しい言語」との比較だ
JSとwasmの関係はpythonとCの関係とは全く状況が異なる
wasmは今のところC#が有力だが将来的には言語を選ばなくなるはず
ということはJSと「JSより簡単で安全で高速な他の言語」との対立という構図になる
結末は目に見えているね
300:デフォルトの名無しさん
20/11/30 13:58:03.77 owcTZSsV.net
> C#が有力
どこが？ｗｗｗ
wasmはGCサポートしてないから.net中間コード逐次実行するランタイムをwasmでロードするという、クソみてーなことしてるGCクソ言語じゃんｗｗｗｗ
RustやCみたいにwasm用にAoTコンパイルできるようになってからほざけカスｗｗｗｗ
やーいインタプリタ言語ｗｗｗｗｗｗ
301:デフォルトの名無しさん
20/11/30 14:17:09.83 +FPoUGVQ.net
>>296
嘘だろと思って調べてみたらマジで草
オーバーヘッド半端ないな
302:デフォルトの名無しさん
20/11/30 14:19:02.43 IuzD2K3l.net
>>296
corertちゃん…
303:デフォルトの名無しさん
20/11/30 14:26:46.20 5LwFg3Ca.net
>>296
blazor wasmがガッカリ低速なのもこれが主原因なんだよね。
ランタイムDLのオーバーヘッド、
中間言語からの実行時(JIT)コンパイルのオーバーヘッド…
他のザコアイテムの改善を行ってはいるが、本丸のAoT対応はできてないw
304:デフォルトの名無しさん
20/11/30 14:51:20.63 0Mqgtux2.net
>>299
Blazorは純粋なwasmじゃないですよ。
Domの処理はガッツりjsです。だから遅い。
305:デフォルトの名無しさん
20/11/30 14:59:27.04 FUbWMdS/.net
>>296
そんなものは時間が解決するに決まってるだろ
少しは考えてからレスしたほうがいいよ
306:デフォルトの名無しさん
20/11/30 15:27:21.70 +FPoUGVQ.net
wasmにGCが乗り、さらに予定すらされていないDOMを直接触る機能が付き、それが全てのブラウザに搭載され、仕様が安定し、それにC#が対応し、フレームワークが完成し、そのフレームワークが流行り……いつになったらJSはレガシーになるんですか？
307:デフォルトの名無しさん
20/11/30 15:31:51.34 5LwFg3Ca.net
>>300
そんなのはRustもCも一緒です。
DOM APIはJS用しか存在しないんだから。
言い訳にもならない。
308:デフォルトの名無しさん
20/11/30 15:32:59.39 rn09M8ye.net
>>291
alert("hoge")
alertの先はネイティブコード
昔からJavaScriptはネイティブコードを呼び出している
309:デフォルトの名無しさん
20/11/30 15:41:53.35 mKaKPR0T.net
.net vmのcdnを予めダウンロードしとくみたいなことできんの？
310:デフォルトの名無しさん
20/11/30 15:42:29.51 rn09M8ye.net
>>303
昔からDOM APIはJavaScript専用じゃない
呼び出そうと思えば、どんな言語からでも呼び出せる
VB6（VBScriptじゃなくて）とかDelphiにIEコンポーネントを埋め込んで
VB6やDelphiからDOM APIを呼び出すなんてのは昔からできた
DOM APIの先はネイティブコードなのでJavaScriptから呼び出しても
wasmから呼び出してもパフォーマンスは変わらない
DOM APIの機能が強化されるたびに、JavaScriptのパフォーマンスは上がってきた
JavaScriptからwasmに変換することもできるということを考えると
話は昔かあるインタプリタ vs コンパイラでしかなくなる
事前コンパイルした方が確かに速いが、インタプリタは事前に
コンパイルする必要がなく気軽に開発できるという点で広く使われている
これが覆ることなんて今後も考えられないだろ
Javascriptのメリットはインタプリタからコンパイラへの変更がシームレスであるということ
開発の初期段階はブラウザで直接動くから素早く開発でき
そして速度が重要な部分だけwasmで変換すれば良くなる
パフォーマンスと開発効率のバランスが優れてるいいとこ取りの言語なんだよ
311:デフォルトの名無しさん
20/11/30 16:08:05.54 XP0NOCLu.net
>>303
domに頼ってるようじゃお終いですな
312:デフォルトの名無しさん
20/11/30 16:11:06.34 tpJ2df0N.net
>>305
一回落とせばキャッシュされるよ
313:デフォルトの名無しさん
20/11/30 16:12:17.98 5LwFg3Ca.net
DOM APIはJavaScript専用です。
wasmからJS経由せずにDOMを触る方法はありません。
これはCだろうがRustだろうがC#だろうが変わりません。
DOMの実装はC++ですが、上記の状況とはまったく関係のない話です。
C++だろうがwasmからJS経由せずにDOMは触れません。
嘘を千回繰り返しても本当にはなりません。
314:デフォルトの名無しさん
20/11/30 16:15:02.59 0Mqgtux2.net
まったく困ったもんだ。
315:デフォルトの名無しさん
20/11/30 17:18:04.07 tr0Vj++C.net
Mozillaのwasmのリファレンスに、「wasmから直でDOMいじれるようにする計画もあるよ！」みたいなことが書いてあったような記憶がある
316:デフォルトの名無しさん
20/11/30 17:46:49.41 0Mqgtux2.net
>>311
Mozillaにはね...Mozillaだから
317:デフォルトの名無しさん
20/11/30 18:37:42.91 8OT0vtYb.net
>>309
じゃあDOMの実装をJSにしたら良いのでは？
318:デフォルトの名無しさん
20/11/30 18:55:08.36 FUbWMdS/.net
>>302
数年以内だろうな
C#に限らず各言語で出揃う
319:デフォルトの名無しさん
20/11/30 18:56:44.46 owcTZSsV.net
>>313
じゃあ、とは？
C++で実装されたネイティブDOM API (JS専用。wasmからはC++だろうがJS経由しないと呼び出せない)が整備されてるのになぜその必要が？
誤魔化してるつもりかな？ｗ
C++で実装されたネイティブDOMの、WASMネイティブのインターフェースを作ってもらいなよ。お前らが。GCクソ言語なんちゃってコンパイル言語中間言語逐次wasm翻訳実質インタプリタクソ言語爆遅ハッタリ嘘つきクソ言語のC#ユーザーがｗｗｗｗ
320:デフォルトの名無しさん
20/11/30 19:02:17.29 FUbWMdS/.net
>>315
君が足踏みしてる間に世界では誰かがより良い世界を作ろうとしてる
もちろんwasmもすぐに良くなる
321:デフォルトの名無しさん
20/11/30 19:06:51.00 owcTZSsV.net
やっぱりウソ吐いて誤魔化そうとしてたね。
あいも変わらず卑怯な奴らだよ。
そんなだから信用されないんだ。
呆れた。
322:デフォルトの名無しさん
20/11/30 19:15:06.85 PALovYd2.net
この二人の論争はなんというか宗教、政党、プロ野球みたいな感じ
どっちも一長一短、適材適所があるでしょうに。
興奮しすぎだわ。
323:デフォルトの名無しさん
20/11/30 19:17:46.73 0Mqgtux2.net
wasmのスレ立てれば？
デバック面倒くさすぎて
使う気にはなれんけど。
324:デフォルトの名無しさん
20/11/30 19:17:53.53 qWFwWuIl.net
何はともあれC#おじさんがスレ違いなのは確か
325:デフォルトの名無しさん
20/11/30 19:20:18.75 owcTZSsV.net
単なる事実対妄想だが。
クソ言語C#バカが妄想な。
blazer開発者ですらJSに速度では勝てない勝とうとしてない狙いは別のところにあると言ってるのに速度でも勝てると勝手に妄想、嘘んこをスレ違いに喚き散らして宣伝して回るクソゴミカスどもだからお灸を据えてやったほうがいい。
326:デフォルトの名無しさん
20/11/30 19:23:31.24 VwdmTk5m.net
速度で勝てないのは現時点での話
当然将来的には最適化が容易なwasmが勝つ
当たり前のことなんだけど理解できないのはかわいそうに
327:デフォルトの名無しさん
20/11/30 19:25:41.44 owcTZSsV.net
そういうのを妄想つうんだよC#チョン
328:デフォルトの名無しさん
20/11/30 19:30:22.31 +FPoUGVQ.net
そりゃwasmは速いよ。でも今のC#そのままブラウザに持ってきただけのblazerが早いわけじゃない
329:デフォルトの名無しさん
20/11/30 19:31:45.17 VwdmTk5m.net
>>323
当たり前に予想できることを妄想とは言わない
コーラを飲んだらゲップが出るのと同じように確実なこと
330:デフォルトの名無しさん
20/11/30 19:33:08.20 VwdmTk5m.net
>>324
まだ慌てる時間じゃない
ゆったりと高みの見物を決め込んでればいつの間にか逆転してるだろう
331:デフォルトの名無しさん
20/11/30 19:34:15.46 owcTZSsV.net
とにかくとっととAoTコンパイル対応してRustやCと同じ土俵乗ってから偉そうにほざけカスって感じ
332:デフォルトの名無しさん
20/11/30 19:36:06.47 FUbWMdS/.net
はいはい世界の何処かで進行中ですよ
333:デフォルトの名無しさん
20/11/30 19:39:02.85 FUbWMdS/.net
Googleとマイクロソフトがこんな誰でも分かるようなあからさまボトルネックを延々と放置するわけねえじゃんって幼稚園児でもわかりそうなもんだがねえ
いったい何を根拠にしたら黎明期の遅いままでずっと推移するなどという荒唐無稽な妄想を信じられるのだろう
334:デフォルトの名無しさん
20/11/30 19:39:28.44 owcTZSsV.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)
335:デフォルトの名無しさん
20/11/30 19:41:55.90 l+bF0jjh.net
>>322
現実を教えてあげよう
誰も実行速度で困ってないんだ
そしてみんなが持ってるコンピューターは
年々実行速度が速くなっていってるんだ
買い替えによってね
336:デフォルトの名無しさん
20/11/30 19:42:04.28 +FPoUGVQ.net
ID:owcTZSsV
こいつ口は悪いけどたしかに嘘や希望的観測は言わないな
337:デフォルトの名無しさん
20/11/30 19:48:50.54 l+bF0jjh.net
ソフトウェアの発展というのは
実行速度が技術に置き換えられてきたといっても
過言じゃないだろう
昔の話をするならアセンブラからC言語へ
C言語からC++へ、C++からJavaへ
ネイティブアプリからブラウザアプリへ
実行速度はどんどん遅くなってるんだよ
それが成り立ってるのはハードウェアがそれをカバーし
338:てるからで そうする理由は開発速度を上げるため wasmの目的は実行速度ではない 既存のものをブラウザ上に移植するのを容易にするためだ その必要がないならネイティブアプリにしたほうが実行速度は速いだろう
339:デフォルトの名無しさん
20/11/30 19:49:05.87 l+bF0jjh.net
実行速度が遅い技術に置き換えられてきたといっても
340:デフォルトの名無しさん
20/11/30 19:51:05.88 c2JpZQqd.net
>>290
俺が愛用してるエディタはDelphi製だけどな
341:デフォルトの名無しさん
20/11/30 19:55:18.02 owcTZSsV.net
C#バカの汚いやり口はいつも同じ。
最初は速いと嘘を吐き騙そうとし、
ウソがバレたら今度は速度なんて重要じゃないという。
前にも言ったが、blazer開発者は最初から速度でJSには勝てないと言ってるんだが？
最後に開き直るなら、最初から飾らねばよい。
342:デフォルトの名無しさん
20/11/30 20:00:02.01 XPC113Og.net
C#奴はずっと詭弁しか言ってない
343:デフォルトの名無しさん
20/11/30 21:34:39.47 FUbWMdS/.net
>>332
過去にすがってるだけ
先が見えてない
344:デフォルトの名無しさん
20/11/30 21:36:11.09 FUbWMdS/.net
>>336
最初は勝てないのは妥当な判断だ
最適化なんてほとんどしてない黎明期だからな
逆に言うと改善の余地が有り余ってる
345:デフォルトの名無しさん
20/11/30 21:39:39.44 0Mqgtux2.net
blazorさんはスレ違だから
退散した方がいいよ。
そもそもwasmも同じくスレ違だから。
無かったら別スレ立てて移動してね。
346:デフォルトの名無しさん
20/11/30 21:43:55.23 FUbWMdS/.net
勝てないとわかったら追い出し作戦か
ワンパターンだねー
347:デフォルトの名無しさん
20/11/30 21:47:06.14 owcTZSsV.net
エッ！一年前から遅い遅い指摘されてたのに、まだAoT実現できてないの？
このプロジェクト大丈夫？？
URLﾘﾝｸ(www.reddit.com)
> No. Blazor is currently interpreted. That makes it very slow compared to JS.
> It will at some point be AOT, which should yield a massive performance boost,
> but we're not there yet.
いいえ。Blazorは現在インタプリタ動作です。
そのためJSに比べて非常に遅くなります。ある時点でAOTになり、
パフォーマンスが大幅に向上するはずですが、
まだ実現していません。
↑これが一年前。さーてそろそろAoT実現してるかな～
AOT support in Blazor WASM will be postponed and not show up in .NET 5.
Blazor WASMでのAOTサポートは延期され、.NET 5には含まれません。
＿＿＿＿＿
ゝ／ ＼ /
/ ＿＿＿＿＿＿＿ヽ
| | : : : : : :＼_人ノ: : :| ／
| | : : / ⌒ ヽ: :/ ⌒ ヽ
/＾v─ i | |
（（ |:ｄ: :♯| ((・|・)) ! 「延期！」
ヽ: : /＾ヽ､ ＿ ノっ ＿ ﾉ－､
|: :| ＼_／＾＼／＾＼_:ノ
|: :| ＼
/⌒＼ヽ （⌒ヽ⌒） ））
| ＼＼_／＾＼_／ﾉ ＿＿＿＿＿
| ＼─┬─ ´ | |_
|. ＼. ＼ | ＼ | 延期 （＿）
| ＼ ＼.／￣￣） （＿)
＼ / ￣) |
348:デフォルトの名無しさん
20/11/30 21:54:51.87 +FPoUGVQ.net
>>338
現在が見えてないC#おじさんの妄想より、現状と開発者の言葉を信じるけどね。普通は
349:デフォルトの名無しさん
20/11/30 22:35:18.91 ae11hT0U.net
C#おじさんのせいでC#が巻き添え食って嫌われるのは心外
350:デフォルトの名無しさん
20/11/30 22:45:16.43 S1EYu7ha.net
C#は良い言語だったと思うよ2000年代中盤から2010年代前半くらいまではね
351:デフォルトの名無しさん
20/11/30 22:56:00.59 ae11hT0U.net
そうか…
2016年に何かがあったんだな…
352:デフォルトの名無しさん
20/11/30 22:58:32.01 gI3b/R7k.net
なんだよこの流れ……jQueryが入る余地ねぇじゃん……
353:デフォルトの名無しさん
20/11/30 22:59:48.74 RrZktX1W.net
SSGの波に乗りおくれるな！
354:デフォルトの名無しさん
20/11/30 23:18:34.74 l+bF0jjh.net
>>347
呼んだかい？ｗ
結局の所wasmは使われず、JavaScriptを使う
そしてDOMと相性がいいのはjQueryって話なんだが
355:デフォルトの名無しさん
20/12/01 01:07:19.73 soycDTan.net
typescriptの生産性を越えない限り、他の言語に出番なんて来ない
356:デフォルトの名無しさん
20/12/01 01:25:58.49 XcHTxxjN.net
jQueryはDOM操作ライブラリだけど
本来ウェブサイトにおいてDOMはガシガシと操作するもんじゃないんだわ
これはjQueryに限った話じゃなくてJavaScript一般の話
jQuery（JavaScript）でやるのは要素の属性の変更
主にclassを変更する。そしてCSSによって見た目を変える
DOMを変更して見た目を変えるんじゃなくて
DOMはそのままでCSSで見た目を変える
これでやりたいことの8割は実現できる
できないのはグリッドテーブルの行数を増やすとかそういうもの程度
そうやって見た目をCSSで変えるだけにすると
JavaScriptの処理は少なくなって、CSSによる宣言的な記述で実装できるようになる。
これはバグが減ってCSSはブラウザによってネイティブで処理されるからもっとも高速になる
あとはこれをJavaScriptでやるからjQueryでやるかだが
jQueryを使うとJavaScriptのコードも宣言的に書けるようになる
正しいウェブサイトプログラミング手法を知ってると
JavaScriptでやる処理が減るから、JavaScriptが遅いことがデメリットにならないんだよ
多少遅くなってもボトルネックにはならないから、そのぶんjQueryを使って楽にやりましょうと
もとより大したことはしないのに、それをwasmに置き換えてなにかメリットあると思う？
ウェブサイトにwasmが入る余地はないんだよ。wasmはデスクトップアプリの移植用
357:デフォルトの名無しさん
20/12/01 01:34:30.18 XcHTxxjN.net
もちろんこの手法にも問題はあってJavaScriptは
シンプルになるが、代わりにHTMLとCSSが複雑になる
この問題はCSSに関してはSASS（SCSS）で解決できる
ウェブプログラマはCSSとその周辺技術に詳しくならないといけないんだが
なぜかCSSわかりません。みたいなことを恥ずかしげもなく言ってしまう
ポインタわかりませんみたいなレベルだからなこれ
HTMLが複雑化する問題は将来的にはWebComponentで解決するだろうし
今現在はテンプレートエンジンを使えば、簡単な記述で生成できる
358:デフォルトの名無しさん
20/12/01 01:44:32.83 BITrO4cB.net
随分スレチな流れだが、wasmは置いといてそこでjQuery推すのはやめてくれ。さらにスレチが加速して収集つかなくなる。jQueryが優秀なのは知ってるから。
359:デフォルトの名無しさん
20/12/01 05:22:26.97 IH0+Yar+.net
>>348
Next.jsとGatsbyどっちがオススメ？
360:デフォルトの名無しさん
20/12/01 06:58:41.70 IH0+Yar+.net
>>249
Armv8.3のFJCVTZS命令が件のJS専用命令で、JS特有の整数変換を高速化できるとのこと。
URLﾘﾝｸ(qiita.com)
M1のみならずArmCPUなら高速化するってわけだ。x86も追従するかもね。
361:デフォルトの名無しさん
20/12/01 09:22:33.54 Iz940o1z.net
別にサイト作成にjQuery使うことは否定してないからさっさと成仏してくれ
362:デフォルトの名無しさん
20/12/01 12:27:40.74 CDzfjJOf.net
マシン語(アセンブリ言語)があらゆる言語を動かし得るのと同様、Wasm(WebAssembly)
もあらゆる言語を動かし得るのだから、Wasm自体に限界は余り無い。
限界があるのは、
・ローカルファイルシステムへ自由な読み書きが出来ないこと。
・グラフィックが遅いこと。特にせっかくOpenGL相当のWebGLがあるのに
同じマシンのnativeのOpenGLの数十倍遅いことが多いのが残念。
363:デフォルトの名無しさん
20/12/01 12:29:51.34 KHJEiCI/.net
>>351
アホ？
jQueryは命令的、Reactとかが宣言的っていうんだよ
命令的だから当然複雑になると手に負えなくなる
364:デフォルトの名無しさん
20/12/01 16:05:00.77 CDzfjJOf.net
>>331
その話は一理あるが、ダウンロード時間に関しては果たしてどうか。
意外と通信費は安くならないし。
それと速度が関係ないというならデスクトップもC#で十分なはずなのに
C++も依然としてかなり人気があるし、新しい言語ならC#より速度が速い
とされるRustも一番人気とも言われている。
人気に関しては色々と議論の余地があるが。
365:デフォルトの名無しさん
20/12/01 16:08:33.20 CDzfjJOf.net
>>359
補足するとPCの速度は、シングルスレッド性能は余り上がらないがコア数はどんどん
増えているので、マルチスレッド化できるような処理の場合にはその時点での
速度の遅さは余り問題にならないかも知れない。
ところが通信に関しては安く済まそうと思うと、とたんに事情が違ってくる。
366:デフォルトの名無しさん
20/12/01 16:14:14.50 CDzfjJOf.net
一戸建ての固定回線の場合、光ファイバーにするには月々4,500円くらいが最低価格。
一戸建ての三年以後の価格で、光ファイバーでそれ以上安いプランは存在し無い事が
多いから。それだと年間、5万4,000円かかる。
それより安くしようと思うとADSLになるが、ADSLは基地局から遠いと極端に遅く
なり、光ファイバーの100～1000分の1位しかでない事が少なくない。
その場合、Blazor Wasmの初回起動はダウンロードに一分以上待たされる。
また、さっきネットで、ダウンロード後の起動にも15秒程度かかる場合があるというテスト
結果をちらっと見た。