Vue vs React vs Svelte Part.6

Vue vs React vs Svelte Part.6 at TECH

[1からを表示]
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
マニュアルに、こういう場合はこうするって
全てのパターンが網羅されてるなら、そのとおりだろうね（笑）
難しいところがない＝考えることがなにもないってことだから馬鹿でもできるね