フロントエンドJavaScriptフレームワーク総合

**デフォルトの名無しさん** · 2020/06/11(木) 13:11:59.44

どうぞ

**デフォルトの名無しさん** · 2020/11/07(土) 12:42:22.96

何故この文脈で静的言語云々が出てくるのか。
静的言語って言いたいだけか

**デフォルトの名無しさん** · 2020/11/07(土) 13:25:25.47

JSに限らず動的言語は必要な機能が揃ってないからだ

**デフォルトの名無しさん** · 2020/11/07(土) 13:57:57.00

例えばevalすらできない

**デフォルトの名無しさん** · 2020/11/07(土) 14:21:37.60

クロージャの話にどうして静的言語云々が出てるんですかねぇ

**デフォルトの名無しさん** · 2020/11/07(土) 14:26:51.28

初期のJavaは酷かった。
イベントハンドラ登録するだけなのにイベントリスナーのクラス作らないといけなかった。
「む、無名クラスでインラインでも書けるから！」とか。アホかと。
今ではみんなラムダ関数使ってまーすｗ
だーれもクラス使ってないでーすｗｗｗ

**デフォルトの名無しさん** · 2020/11/07(土) 15:56:43.14

>>307
JavaとJavaScriptの区別もつかない無能

**デフォルトの名無しさん** · 2020/11/07(土) 17:07:33.91

確かに以前のJavaはクロージャどころか関数ポインタ（的なもの）すら無くて辛い言語だったなぁ。

個人的にはJS|TSでクラス使う場面って、
・状態を持つオブジェクトを扱う時
・継承を使う時（WebComponents等）
くらいだと思ってる。

**デフォルトの名無しさん** · 2020/11/07(土) 18:01:35.46

>>307
まああのシンプルさが勉強には良かったけどね。
仕事で使いたくはないけど。
なぜクロージャーが便利なのかということも身を持って知れるし。

**デフォルトの名無しさん** · 2020/11/09(月) 18:11:35.27

Javaに失望したらC#にいけばいいのに
なぜさらに不便なJSなのか

**デフォルトの名無しさん** · 2020/11/09(月) 19:45:26.78

webの開発では圧倒的にクロージャーを使うことが多いよ。

あるリストがあって、その中の一つの要素をクリック時に削除するなどの処理を書く場合は自然とクロージャー使うしね

**デフォルトの名無しさん** · 2020/11/09(月) 20:10:47.53

elm.AddEventListener(function() { ・・・}) を使うな

function handler() { ・・・}
elm.AddEventListener(handler) を使え派は
どこ行ったんだろうねｗ

前者はクロージャーだから循環参照を引き起こして
メモリリークのバグになる可能性があるから
後者を使えっていうのが昔は多かったんだが

もっともjQueryは後者の書き方をしても循環参照にならない
仕組みなので問題なかったんだが
（要素に直接イベントハンドラ関数を割り当てるのではなくjQueryの内部的な
イベントハンドラを管理するオブジェクト経由で間接的に参照するので
循環参照にならない仕組みでブラウザのメモリ管理のバグを回避していた）

**デフォルトの名無しさん** · 2020/11/09(月) 20:31:46.56

クロージャ使い倒してるけど循環参照してメモリリークなんて一度もなった事無いから、普段全く意識してないなぁ。
TS使ってて他に劣ってるとは全然思わない。あ、ジェネリック周りが複雑過ぎるとは時々思うw

**デフォルトの名無しさん** · 2020/11/09(月) 22:50:02.10

next.jsって本がないのが辛い。Gatsbyですらあるのに。どこ見て勉強するとええんやろ。公式をGoogle翻訳？

**デフォルトの名無しさん** · 2020/11/09(月) 22:57:02.16

英語できない人がそんなマイナーフレームワーク使ってはいけない
翻訳なんてつかうからいつまでたっても英語が上達しない
本は情報が常に古い
英語のドキュメントとソースコードでしょ
あとはYouTubeの英語

**デフォルトの名無しさん** · 2020/11/10(火) 01:20:11.62

>>313
俺は世代的にこの問題を意識したことないけど、eventをちゃんとremoveすれば良いって話だよね？

**デフォルトの名無しさん** · 2020/11/10(火) 02:21:05.26

>>317
ブラウザバックや進む、リロード時に
eventをremoveするように作らないといかんわけや
とうぜんブラウザバック時にイベントなんて起きないでｗ

**デフォルトの名無しさん** · 2020/11/10(火) 02:35:39.06

そう言えば、jQuery では、DOM の削除時にも、イベントも削除してくれるのだっけ？

**デフォルトの名無しさん** · 2020/11/10(火) 04:48:41.91

リロードしてもリソース開放されんってそんな時代あったんか……

**デフォルトの名無しさん** · 2020/11/10(火) 06:15:05.66

リロードワロタｗｗｗ
お里が知れるなｗｗｗｗ

**デフォルトの名無しさん** · 2020/11/10(火) 10:54:11.86

Chromeだとリロードボタンの右クリックにキャッシュを飛ばしてリロードするかどうかの選択あるけどね

**デフォルトの名無しさん** · 2020/11/10(火) 11:27:57.67

>>319
削除される。もちろんjQueryの命令を使って削除しないといけないけど

**デフォルトの名無しさん** · 2020/11/10(火) 16:18:55.13

>>322
キャッシュの話ｗｗｗｗｗ
で？ｗ
リスナーの登録は？ｗｗｗ

**デフォルトの名無しさん** · 2020/11/12(木) 10:31:14.40

web component流行ってくれ

**デフォルトの名無しさん** · 2020/11/12(木) 13:42:28.98

自作ソフトをWeb Componentsで作り直そうかと思ってるが
特にメリットがないし、二の足を踏んでいる。

**デフォルトの名無しさん** · 2020/11/12(木) 17:43:51.94

web components は spaとかを作るには向いてないけどある程度静的なものを作るなら向いてると思うで。

templateとかにlit htmlとか使うの前提だけどね

**デフォルトの名無しさん** · 2020/11/12(木) 20:08:20.88

lit-html知らなかったわ。面白いなこれ。
ガチンコなアプリでは物足りない感じだけど、既存のものにもさくっと差し込めそう

**デフォルトの名無しさん** · 2020/11/13(金) 16:19:13.65

おもろいで
　
lit elementもおもろいで

**デフォルトの名無しさん** · 2021/03/05(金) 12:09:53.39

https://www.statista.com/statistics/1124699/worldwide-developer-survey-most-used-frameworks-web/

https://trends.google.com/trends/explore?geo=US&;q=%2Fm%2F012l1vxv,%2Fm%2F02_qnn,%2Fm%2F06y_qx,%2Fg%2F11c6w0ddw9,%2Fm%2F0dhx5b

上の方に ASP.NET のマーケットシェアが１位って記事があったから載せてみるね
ネット上のマーケットシェアのサイトってソース載ってないのも
どうやって調べてるかわからないものも多いよね

**デフォルトの名無しさん** · 2021/03/05(金) 12:54:16.30

上の方で、ページリロードでリスナーが解放されるかって話

バカにせずに真面目に考えてみます

基本的に、ページリロードで VM のヒープもスタックも全部リセットされるので
普通に考えればメモリリークなんてものはない

Chrome とかはVMどころかページ毎にプロセスまるごと作り直しみたいな話になるので、
メモリリークの可能性は低い

キャッシュというのは、JS/HTML/CSS のソースコードのキャッシュをメモリ上とか
データベースに保存してるってことよね、メモリ解放の話とは関係ない

JIT コンパイラのコードキャッシュとかに関しては、プロセス間で共有してるのかは知らない
まぁでも、これもリスナーのメモリ解放の話とは関係ない

Ref :
https://stackoverflow.com/questions/28896028/do-javascript-memory-leaks-matter-after-a-page-refresh-why

**デフォルトの名無しさん** · 2021/03/05(金) 12:55:03.20

は？一生懸命書いたのに、くっそ昔のスレじゃん
泣きたい

**デフォルトの名無しさん** · 2021/03/05(金) 15:29:02.03

泣かないで。
きっとこれからこのスレを読む誰かの為になるよ

**デフォルトの名無しさん** · 2021/03/15(月) 10:31:43.74

>>47
Pythonは言語仕様に問題が有り過ぎてwasmへの変換は不可能と決着済
仕方ないのでPythonインタプリタをwasmへ変換して動かしてる
結果JavaScriptより数十倍も遅いため使い物になっていない

**デフォルトの名無しさん** · 2022/02/16(水) 02:36:12.18

フロントエンド改修するのにReactかVue3で迷ってる
世の流れ的にいくならReactにしない理由はないと思うんだけどなんか好きになれんのよな

Vueはテンプレートの構文がわかりやすくて好きなんだけど、結局typescriptとの親和性の観点でtsxで書く流れになってきてるから、tsx使うならReactでよくねとも思う
Reactだと依存配列書き忘れとかも以外とやりがちで、Vueはcomputedがその辺全部いい感じにやってくれるから自分的な差はそこくらいかなあ

なんかここで選べみたいなのあります？

**デフォルトの名無しさん** · 2022/02/16(水) 02:36:54.47

は？一生懸命書いたのに、くっそ昔のスレじゃん
泣きたい

**デフォルトの名無しさん** · 2022/02/16(水) 21:54:15.68

泣いてもええんやで

**デフォルトの名無しさん** · 2022/03/27(日) 20:25:30.49

板がわかれすぎて全然人いないよね

**デフォルトの名無しさん** · 2022/03/31(木) 00:15:00.32

>>336
運の悪いときはあるもの

**デフォルトの名無しさん** · 2022/04/05(火) 10:34:11.05

Reactを使いたけど、jsの言語仕様が変態すぎて辛い
jsはチュートリアルさらりと読んだら、理解が曖昧でも
そのままフレームワークの使い方を覚える段階に進んだ方がいいのかな？
言語仕様がぐちゃぐちゃでベストプラクティスを想像できない

**デフォルトの名無しさん** · 2022/04/09(土) 07:34:19.26

>>338
webprog、web制作あたりと合体したらいいかも

**デフォルトの名無しさん** · 2022/04/11(月) 12:16:01.69

>>340
Reactスレあるよ

**デフォルトの名無しさん** · 2022/05/28(土) 13:39:42.60

さらに Rect へSvelte とvue をまぶしたようなSolid.jsなるものまであるな
https://www.solidjs.com/

**デフォルトの名無しさん** · 2022/05/28(土) 20:24:35.77

ベンダーじゃなくて発注側なんやけど、Javaができて便利なことある？
例えばベンダー側で実際Javaのプログラム書いたり開発した経験が無くても、発注側で極簡単な改修なら自前でできたり、改修や開発の設計書を読めるようになるぐらいならできるもん？

**デフォルトの名無しさん** · 2022/05/29(日) 07:33:04.81

>>344
Javaとスレタイは違うものなのでスレ違い

**デフォルトの名無しさん** · 2022/06/07(火) 23:44:35.62

色々変な仕様くっつきすぎてとっつきにくくなり、素のJSに戻ることになるでしょう

**デフォルトの名無しさん** · 2022/12/18(日) 11:23:26.30

フロントエンドをスレタイに入れなければもっと伸びたはず

**デフォルトの名無しさん** · 2023/03/03(金) 13:31:06.42

viteへの移行がくそめんどすぎるのですが