Vue vs React vs Svelte Part.6

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
垢版 |
2020/10/27(火) 13:09:05.31ID:5aYZ+KyB
実際どうなん？
※Angularは残念ながら全く話題にならなかったのでSvelteに差し替えました
Vue
https://jp.vuejs.org/
React
https://reactjs.org/
Svelte
https://svelte.dev/
※前スレ
Vue vs React vs Angular Part.5
https://mevius.5ch.net/test/read.cgi/tech/1596029929/

★ここではjQuery, Ruby, C#, Blazorの話題は禁止です
★jQuery, Ruby, C#, Blazorｷﾁｶﾞｲが書き込んでも無視してください
Angular, Next, Nuxt, Sapper, Gatsby, VuePress, RedWoodなどはおｋ。
2020/11/29(日) 19:41:07.41ID:YNdyjjvH
人類規模で投資の仕方間違ったよな
スクリプトの高速化なんてやってないで、wasmに早期から取り組むべきだった
2020/11/29(日) 19:46:27.00ID:sOEBQUsx
wasmのブートストラップコードはjsなんだからjsが遅かったらwasmまで遅くなるじゃんバカなの
2020/11/29(日) 20:06:24.90ID:YNdyjjvH
バカには理解するのが難しいかもしれ
投資してればその無駄なブートストラップのJSが消えるだけ
2020/11/29(日) 20:16:31.99ID:TbmbElJ8
wasmが影も形も無かった頃、静的型付けでコンパイル言語でバイナリが実行ファイルで、サーバからクライアント、あらゆるマシンやブラウザ上で動く、しかもITの巨人たちがこぞって投資した。そんな凄い言語があったんです。
そんな言語でもJavaScriptの牙城は崩せませんでした
2020/11/29(日) 20:24:28.83ID:bza0LWNC
>>261
まだ投資が足りなかった
普及してれば人類のステージはもう何歩か先に進んでたのに惜しいことをしたな
この遅れが後々の宇宙人との戦争に響いてくる
2020/11/29(日) 20:57:40.64ID:MsV4ej8L
appletのこと？
2020/11/29(日) 22:03:16.18ID:8NXwxGIx
時系列おかしくね
2020/11/29(日) 22:09:24.49ID:+p4clpep
投資とかじゃなくてwasmが重かっただけの話
当時のブラウザじゃろくに動かない
ソフトウェアの世界は重いものより軽量のものが好まれる
2020/11/29(日) 22:41:32.13ID:Rb8oT144
そもそも、jsの置き換え用途として
wasmが用意された訳ではない。
2020/11/29(日) 22:46:49.01ID:sEIsLTyR
docker作ったやつが「wasmを知ってたらdocker作らんでも良かった」って言ってwasmのことを褒めてた記事を前見た
言ってる意味はよくわからなかったけど将来性あるんだろうなあって感じた
268デフォルトの名無しさん
垢版 |
2020/11/29(日) 22:50:34.02ID:AbKwwhG3
webエンジニア全員でAppleボイコットすべきだろ
縮尺違うデバイス乱発しやがるし
safariとかいうゴミブラウザはまともに動作出来ないしよ
2020/11/29(日) 23:10:43.09ID:kn6Xy7Za
Safariは糞なんだけどなんだかんだ全盛期のIEよりはマシ。でもMacやiOS以外でテストできないのはホントやめて欲しい
2020/11/29(日) 23:12:09.34ID:HZy5s6KS
>>267
wasmのサーバーサイド向けのまともな処理系があれば確かにdockerいらないんだけどな
いかんせんwasmは仕様が貧弱すぎて
2020/11/29(日) 23:13:05.16ID:Z/yAEGW+
>>267
K8Sでwasm動かすオプション、マイクロソフトが作ってた気がする
外部コマンドとかに依存してないピュアなプログラムなら、wasmに乗せればどこでも動くからDocker要らん
2020/11/29(日) 23:37:25.38ID:Rb8oT144
サンドボックスから出れませんよ。
デスクトップネイティブの変わりにはなりません。
2020/11/30(月) 01:18:36.39ID:rn09M8ye
>>271
その「どこでも」にサーバーサイドは含まれていますか？
2020/11/30(月) 01:30:06.52ID:owcTZSsV
>>273
当たり前だろ…今誰がクライアントサイドの話をしてるんだよ…
クライアント側技術のwasmが、docker代わりにサーバで使えるかもね、どうだろうね、とそういう話だろうに。
2020/11/30(月) 01:31:07.01ID:iUHy/DDO
>>266
え？
もともと、EmscriptenがC/C++をasm.jsに変換していたのが、asm.jsがWasmに
進化したのだと思っていたが。
2020/11/30(月) 01:39:36.58ID:owcTZSsV
何の反駁にもなってない。jsの置き換え用途として
asm.jsが用意された訳ではない。
2020/11/30(月) 01:41:23.94ID:owcTZSsV
>>271
Krustletかな？
https://www.publickey1.jp/blog/20/kuberneteswebasssemblykrustlet.html
2020/11/30(月) 03:09:11.88ID:m2msM8IC
えーこれJavaVMの再開発なんじゃ
2020/11/30(月) 07:16:39.65ID:+FPoUGVQ
wasmは
C++等の色んな言語の資産を活かせる。
JavaVMほどの起動時の遅さやフットプリントは必要ない。
GCが無い。
純粋なwasmではIOができない（データの永続化ができない）

のでJavaVMとは色々異なってて、サーバサイドではどちらかというとDockerぽいと感じるかな
2020/11/30(月) 09:05:29.99ID:FUbWMdS/
>>274
かもねじゃなくもうK8Sで使える
2020/11/30(月) 09:08:34.72ID:FUbWMdS/
いずれにせよJSは近いうちに終わる
COBOLやJavaみたいなレガシーの扱いになる
2020/11/30(月) 09:58:33.10ID:+FPoUGVQ
近いうちと言っても少なくともまだ5年ぐらいは無さそう。完全に置き換わるまでには10年くらい。全然置き変わらない可能性もある。
ま、無くなったって新しいの覚えるだけだ。言語が変わっても思想的に地続きなフレームワークが出るだろうし、何も無駄にはならないな
2020/11/30(月) 10:13:49.58ID:y87+I7Qr
JS終わってほしいけど数十年は終わらないと思う
2020/11/30(月) 10:28:21.64ID:+FPoUGVQ
何れにしてもポストJSを考えるには時期尚早感が強い。言語ベンダーとかフレームワーク屋ならともかく
2020/11/30(月) 10:38:55.43ID:rn09M8ye
>>281
> COBOLやJavaみたいなレガシーの扱いになる
それは終わるとは言わないｗ

お前はいちばん重要なことを忘れてるな
JavaScriptが一番少ない記述量・作業量で目的を達成できるのだから
wasmに取って代わることはない
2020/11/30(月) 10:43:07.99ID:bmm0MTRM
選挙でもそうだが政局なんてそう簡単にはひっくり返らんよ
2020/11/30(月) 10:43:56.07ID:rn09M8ye
世の中で本当に終わったといえる言語には特徴がある

1. 1ベンダーによる開発
2. その開発会社が終息を宣言、もしくはそれ相当の自体になった

これにギリギリ当てはまるのは
VB6とDelphiぐらいだろ

JavaScriptは多数の実装があるのでどうあっても終わらない
2020/11/30(月) 10:46:18.62ID:rn09M8ye
D言語やPerl5/6なんかもあったな
PHPも開発会社が終息を宣言すれば終わる可能性もある
Rubyは幾つか実装があるみたいだが
やっぱり本家が終われば終わる可能性もある
GoもGoogleだけかな

で、JavaScriptはこれらとは程遠い
2020/11/30(月) 10:46:30.21ID:bmm0MTRM
Delphiとエンバカデロってどうにかなったのか？
2020/11/30(月) 10:50:16.45ID:rn09M8ye
>>289
もう誰も気にしてないということ
2020/11/30(月) 12:33:18.66ID:0Mqgtux2
>>281
JSからネイティブコードが
呼び出せるようになるだろ。
2020/11/30(月) 12:37:42.55ID:PALovYd2
jsは終わらないけど
jsを使ったフレームワークやAltJSの類はどんどん移り変わるから大変だなあとは思う
バージョンアップしたときとかみんな着いていけてるのか？
2020/11/30(月) 12:58:24.94ID:+FPoUGVQ
フレームワーク作る側も変化が激しくて習得が負担になりうる事を意識してか、ルールが独特過ぎたり複雑過ぎるのは最新減ってきたように思う
2020/11/30(月) 13:31:15.73ID:owcTZSsV
Pythonの高速ライブラリはCで書かれたネイティブモジュールだけどPythonはなくなりましたか。
え？なくなってない？じゃあなんでwasmでjsがなくなるのｗｗｗ
Pythonよりさらに状況悪くて、クライアントサイドではwasmはjs経由でしかロードもできないのにｗｗｗｗ
2020/11/30(月) 13:52:09.05ID:FUbWMdS/
何言ってんだこいつ

pythonのライブラリがCで書かれてるからと言ってクライアントまでCにする理由はない
なぜならCよりもpythonのほうが簡単だから
これはpythonと「pythonより速いが難しい言語」との比較だ

JSとwasmの関係はpythonとCの関係とは全く状況が異なる
wasmは今のところC#が有力だが将来的には言語を選ばなくなるはず
ということはJSと「JSより簡単で安全で高速な他の言語」との対立という構図になる
結末は目に見えているね
2020/11/30(月) 13:58:03.77ID:owcTZSsV
> C#が有力
どこが？ｗｗｗ
wasmはGCサポートしてないから.net中間コード逐次実行するランタイムをwasmでロードするという、クソみてーなことしてるGCクソ言語じゃんｗｗｗｗ
RustやCみたいにwasm用にAoTコンパイルできるようになってからほざけカスｗｗｗｗ
やーいインタプリタ言語ｗｗｗｗｗｗ
2020/11/30(月) 14:17:09.83ID:+FPoUGVQ
>>296
嘘だろと思って調べてみたらマジで草
オーバーヘッド半端ないな
2020/11/30(月) 14:19:02.43ID:IuzD2K3l
>>296
corertちゃん…
2020/11/30(月) 14:26:46.20ID:5LwFg3Ca
>>296
blazor wasmがガッカリ低速なのもこれが主原因なんだよね。
ランタイムDLのオーバーヘッド、
中間言語からの実行時(JIT)コンパイルのオーバーヘッド…
他のザコアイテムの改善を行ってはいるが、本丸のAoT対応はできてないw
2020/11/30(月) 14:51:20.63ID:0Mqgtux2
>>299
Blazorは純粋なwasmじゃないですよ。
Domの処理はガッツりjsです。だから遅い。
2020/11/30(月) 14:59:27.04ID:FUbWMdS/
>>296
そんなものは時間が解決するに決まってるだろ
少しは考えてからレスしたほうがいいよ
2020/11/30(月) 15:27:21.70ID:+FPoUGVQ
wasmにGCが乗り、さらに予定すらされていないDOMを直接触る機能が付き、それが全てのブラウザに搭載され、仕様が安定し、それにC#が対応し、フレームワークが完成し、そのフレームワークが流行り……いつになったらJSはレガシーになるんですか？
2020/11/30(月) 15:31:51.34ID:5LwFg3Ca
>>300
そんなのはRustもCも一緒です。
DOM APIはJS用しか存在しないんだから。
言い訳にもならない。
2020/11/30(月) 15:32:59.39ID:rn09M8ye
>>291
alert("hoge")

alertの先はネイティブコード
昔からJavaScriptはネイティブコードを呼び出している
2020/11/30(月) 15:41:53.35ID:mKaKPR0T
.net vmのcdnを予めダウンロードしとくみたいなことできんの？
2020/11/30(月) 15:42:29.51ID:rn09M8ye
>>303
昔からDOM APIはJavaScript専用じゃない
呼び出そうと思えば、どんな言語からでも呼び出せる
VB6（VBScriptじゃなくて）とかDelphiにIEコンポーネントを埋め込んで
VB6やDelphiからDOM APIを呼び出すなんてのは昔からできた

DOM APIの先はネイティブコードなのでJavaScriptから呼び出しても
wasmから呼び出してもパフォーマンスは変わらない
DOM APIの機能が強化されるたびに、JavaScriptのパフォーマンスは上がってきた

JavaScriptからwasmに変換することもできるということを考えると
話は昔かあるインタプリタ vs コンパイラでしかなくなる

事前コンパイルした方が確かに速いが、インタプリタは事前に
コンパイルする必要がなく気軽に開発できるという点で広く使われている
これが覆ることなんて今後も考えられないだろ

Javascriptのメリットはインタプリタからコンパイラへの変更がシームレスであるということ
開発の初期段階はブラウザで直接動くから素早く開発でき
そして速度が重要な部分だけwasmで変換すれば良くなる
パフォーマンスと開発効率のバランスが優れてるいいとこ取りの言語なんだよ
307デフォルトの名無しさん
垢版 |
2020/11/30(月) 16:08:05.54ID:XP0NOCLu
>>303
domに頼ってるようじゃお終いですな
2020/11/30(月) 16:11:06.34ID:tpJ2df0N
>>305
一回落とせばキャッシュされるよ
2020/11/30(月) 16:12:17.98ID:5LwFg3Ca
DOM APIはJavaScript専用です。
wasmからJS経由せずにDOMを触る方法はありません。
これはCだろうがRustだろうがC#だろうが変わりません。
DOMの実装はC++ですが、上記の状況とはまったく関係のない話です。
C++だろうがwasmからJS経由せずにDOMは触れません。
嘘を千回繰り返しても本当にはなりません。
2020/11/30(月) 16:15:02.59ID:0Mqgtux2
まったく困ったもんだ。
2020/11/30(月) 17:18:04.07ID:tr0Vj++C
Mozillaのwasmのリファレンスに、「wasmから直でDOMいじれるようにする計画もあるよ！」みたいなことが書いてあったような記憶がある
2020/11/30(月) 17:46:49.41ID:0Mqgtux2
>>311
Mozillaにはね...Mozillaだから
313デフォルトの名無しさん
垢版 |
2020/11/30(月) 18:37:42.91ID:8OT0vtYb
>>309
じゃあDOMの実装をJSにしたら良いのでは？
2020/11/30(月) 18:55:08.36ID:FUbWMdS/
>>302
数年以内だろうな
C#に限らず各言語で出揃う
2020/11/30(月) 18:56:44.46ID:owcTZSsV
>>313
じゃあ、とは？
C++で実装されたネイティブDOM API (JS専用。wasmからはC++だろうがJS経由しないと呼び出せない)が整備されてるのになぜその必要が？
誤魔化してるつもりかな？ｗ
C++で実装されたネイティブDOMの、WASMネイティブのインターフェースを作ってもらいなよ。お前らが。GCクソ言語なんちゃってコンパイル言語中間言語逐次wasm翻訳実質インタプリタクソ言語爆遅ハッタリ嘘つきクソ言語のC#ユーザーがｗｗｗｗ
2020/11/30(月) 19:02:17.29ID:FUbWMdS/
>>315
君が足踏みしてる間に世界では誰かがより良い世界を作ろうとしてる
もちろんwasmもすぐに良くなる
2020/11/30(月) 19:06:51.00ID:owcTZSsV
やっぱりウソ吐いて誤魔化そうとしてたね。
あいも変わらず卑怯な奴らだよ。
そんなだから信用されないんだ。
呆れた。
2020/11/30(月) 19:15:06.85ID:PALovYd2
この二人の論争はなんというか宗教、政党、プロ野球みたいな感じ
どっちも一長一短、適材適所があるでしょうに。
興奮しすぎだわ。
2020/11/30(月) 19:17:46.73ID:0Mqgtux2
wasmのスレ立てれば？
デバック面倒くさすぎて
使う気にはなれんけど。
2020/11/30(月) 19:17:53.53ID:qWFwWuIl
何はともあれC#おじさんがスレ違いなのは確か
2020/11/30(月) 19:20:18.75ID:owcTZSsV
単なる事実対妄想だが。
クソ言語C#バカが妄想な。
blazer開発者ですらJSに速度では勝てない勝とうとしてない狙いは別のところにあると言ってるのに速度でも勝てると勝手に妄想、嘘んこをスレ違いに喚き散らして宣伝して回るクソゴミカスどもだからお灸を据えてやったほうがいい。
2020/11/30(月) 19:23:31.24ID:VwdmTk5m
速度で勝てないのは現時点での話
当然将来的には最適化が容易なwasmが勝つ
当たり前のことなんだけど理解できないのはかわいそうに
2020/11/30(月) 19:25:41.44ID:owcTZSsV
そういうのを妄想つうんだよC#チョン
2020/11/30(月) 19:30:22.31ID:+FPoUGVQ
そりゃwasmは速いよ。でも今のC#そのままブラウザに持ってきただけのblazerが早いわけじゃない
2020/11/30(月) 19:31:45.17ID:VwdmTk5m
>>323
当たり前に予想できることを妄想とは言わない
コーラを飲んだらゲップが出るのと同じように確実なこと
2020/11/30(月) 19:33:08.20ID:VwdmTk5m
>>324
まだ慌てる時間じゃない
ゆったりと高みの見物を決め込んでればいつの間にか逆転してるだろう
2020/11/30(月) 19:34:15.46ID:owcTZSsV
とにかくとっととAoTコンパイル対応してRustやCと同じ土俵乗ってから偉そうにほざけカスって感じ
2020/11/30(月) 19:36:06.47ID:FUbWMdS/
はいはい世界の何処かで進行中ですよ
2020/11/30(月) 19:39:02.85ID:FUbWMdS/
Googleとマイクロソフトがこんな誰でも分かるようなあからさまボトルネックを延々と放置するわけねえじゃんって幼稚園児でもわかりそうなもんだがねえ
いったい何を根拠にしたら黎明期の遅いままでずっと推移するなどという荒唐無稽な妄想を信じられるのだろう
2020/11/30(月) 19:39:28.44ID:owcTZSsV
AOTサポートにより（JSに勝つことはないにせよ）性能向上が期待され、また宣伝し、信者も大いに期待していたが…

AOT support in Blazor WASM will be postponed and not show up in .NET 5.
Blazor WASMでのAOTサポートは延期され、.NET 5には含まれません。
https://twitter.com/christianweyer/status/1270602821688328192?s=20
延期されたｗｗｗｗ
一時ソースはGitHubのAoT compilation issueへのDaniel Rothの6/6のコメントとみられる。
他の改善アイテムで頑張るってよｗ
https://twitter.com/5chan_nel (5ch newer account)
2020/11/30(月) 19:41:55.90ID:l+bF0jjh
>>322
現実を教えてあげよう

誰も実行速度で困ってないんだ

そしてみんなが持ってるコンピューターは
年々実行速度が速くなっていってるんだ
買い替えによってね
2020/11/30(月) 19:42:04.28ID:+FPoUGVQ
ID:owcTZSsV
こいつ口は悪いけどたしかに嘘や希望的観測は言わないな
2020/11/30(月) 19:48:50.54ID:l+bF0jjh
ソフトウェアの発展というのは
実行速度が技術に置き換えられてきたといっても
過言じゃないだろう

昔の話をするならアセンブラからC言語へ
C言語からC++へ、C++からJavaへ
ネイティブアプリからブラウザアプリへ

実行速度はどんどん遅くなってるんだよ
それが成り立ってるのはハードウェアがそれをカバーしてるからで
そうする理由は開発速度を上げるため

wasmの目的は実行速度ではない
既存のものをブラウザ上に移植するのを容易にするためだ
その必要がないならネイティブアプリにしたほうが実行速度は速いだろう
2020/11/30(月) 19:49:05.87ID:l+bF0jjh
実行速度が遅い技術に置き換えられてきたといっても
2020/11/30(月) 19:51:05.88ID:c2JpZQqd
>>290
俺が愛用してるエディタはDelphi製だけどな
2020/11/30(月) 19:55:18.02ID:owcTZSsV
C#バカの汚いやり口はいつも同じ。
最初は速いと嘘を吐き騙そうとし、
ウソがバレたら今度は速度なんて重要じゃないという。
前にも言ったが、blazer開発者は最初から速度でJSには勝てないと言ってるんだが？
最後に開き直るなら、最初から飾らねばよい。
2020/11/30(月) 20:00:02.01ID:XPC113Og
C#奴はずっと詭弁しか言ってない
2020/11/30(月) 21:34:39.47ID:FUbWMdS/
>>332
過去にすがってるだけ
先が見えてない
2020/11/30(月) 21:36:11.09ID:FUbWMdS/
>>336
最初は勝てないのは妥当な判断だ
最適化なんてほとんどしてない黎明期だからな
逆に言うと改善の余地が有り余ってる
2020/11/30(月) 21:39:39.44ID:0Mqgtux2
blazorさんはスレ違だから
退散した方がいいよ。
そもそもwasmも同じくスレ違だから。
無かったら別スレ立てて移動してね。
2020/11/30(月) 21:43:55.23ID:FUbWMdS/
勝てないとわかったら追い出し作戦か
ワンパターンだねー
2020/11/30(月) 21:47:06.14ID:owcTZSsV
エッ！一年前から遅い遅い指摘されてたのに、まだAoT実現できてないの？
このプロジェクト大丈夫？？

https://www.reddit.com/r/csharp/comments/c7qtwy/is_blazorwasm_faster_than_js_today/
> 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　　　 　 |　　　　|
（（ |:ｄ: :♯| 　 　 ((・|・))　　 !　　　　「延期！」
　　ヽ: : /＾ヽ､ ＿　ノっ ＿ ﾉ−､
　　　|: :|　　 ＼_／＾＼／＾＼_:ノ
　　　|: :|　　　　　　　　　　　　　　　＼
　/⌒＼ヽ　（⌒ヽ⌒）　　　））
　|　　　 ＼＼_／＾＼_／ﾉ　＿＿＿＿＿
　|　　　　　＼─┬─　´　|　　　　　　　　|_
　|.　 ＼.　　　＼ | 　 ＼　 |　 　延期　（＿）
　| 　 　 ＼ 　 　 ＼.／￣￣）　 　　 　 （＿)
　　　 　 　 ＼　　 /　 　 ￣)　　　　　　　 |
2020/11/30(月) 21:54:51.87ID:+FPoUGVQ
>>338
現在が見えてないC#おじさんの妄想より、現状と開発者の言葉を信じるけどね。普通は
2020/11/30(月) 22:35:18.91ID:ae11hT0U
C#おじさんのせいでC#が巻き添え食って嫌われるのは心外
2020/11/30(月) 22:45:16.43ID:S1EYu7ha
C#は良い言語だったと思うよ2000年代中盤から2010年代前半くらいまではね
2020/11/30(月) 22:56:00.59ID:ae11hT0U
そうか…
2016年に何かがあったんだな…
2020/11/30(月) 22:58:32.01ID:gI3b/R7k
なんだよこの流れ……jQueryが入る余地ねぇじゃん……
2020/11/30(月) 22:59:48.74ID:RrZktX1W
SSGの波に乗りおくれるな！
2020/11/30(月) 23:18:34.74ID:l+bF0jjh
>>347
呼んだかい？ｗ

結局の所wasmは使われず、JavaScriptを使う
そしてDOMと相性がいいのはjQueryって話なんだが
2020/12/01(火) 01:07:19.73ID:soycDTan
typescriptの生産性を越えない限り、他の言語に出番なんて来ない
2020/12/01(火) 01:25:58.49ID:XcHTxxjN
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はデスクトップアプリの移植用
2020/12/01(火) 01:34:30.18ID:XcHTxxjN
もちろんこの手法にも問題はあってJavaScriptは
シンプルになるが、代わりにHTMLとCSSが複雑になる

この問題はCSSに関してはSASS（SCSS）で解決できる
ウェブプログラマはCSSとその周辺技術に詳しくならないといけないんだが
なぜかCSSわかりません。みたいなことを恥ずかしげもなく言ってしまう
ポインタわかりませんみたいなレベルだからなこれ

HTMLが複雑化する問題は将来的にはWebComponentで解決するだろうし
今現在はテンプレートエンジンを使えば、簡単な記述で生成できる
353デフォルトの名無しさん
垢版 |
2020/12/01(火) 01:44:32.83ID:BITrO4cB
随分スレチな流れだが、wasmは置いといてそこでjQuery推すのはやめてくれ。さらにスレチが加速して収集つかなくなる。jQueryが優秀なのは知ってるから。
2020/12/01(火) 05:22:26.97ID:IH0+Yar+
>>348
Next.jsとGatsbyどっちがオススメ？
2020/12/01(火) 06:58:41.70ID:IH0+Yar+
>>249
Armv8.3のFJCVTZS命令が件のJS専用命令で、JS特有の整数変換を高速化できるとのこと。
https://qiita.com/mod_poppo/items/66663d9a05790579b5e4

M1のみならずArmCPUなら高速化するってわけだ。x86も追従するかもね。
2020/12/01(火) 09:22:33.54ID:Iz940o1z
別にサイト作成にjQuery使うことは否定してないからさっさと成仏してくれ
2020/12/01(火) 12:27:40.74ID:CDzfjJOf
マシン語(アセンブリ言語)があらゆる言語を動かし得るのと同様、Wasm(WebAssembly)
もあらゆる言語を動かし得るのだから、Wasm自体に限界は余り無い。
限界があるのは、
・ローカルファイルシステムへ自由な読み書きが出来ないこと。
・グラフィックが遅いこと。特にせっかくOpenGL相当のWebGLがあるのに
　同じマシンのnativeのOpenGLの数十倍遅いことが多いのが残念。
2020/12/01(火) 12:29:51.34ID:KHJEiCI/
>>351
アホ？
jQueryは命令的、Reactとかが宣言的っていうんだよ
命令的だから当然複雑になると手に負えなくなる
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況