フロントエンドJavaScriptフレームワーク総合
>>297
どれの話?そうやってありもしないことを言って満足してるの? 「バナナが欲しかったが、バナナを持ったゴリラを手に入れた」
ゴリラ=クラス
元ネタはErlang作者であるJoe Armstrongの、
「オブジェクト指向言語の問題は、オブジェクト指向言語が持ち歩く暗黙の環境をすべて持っていることです。あなたはバナナが欲しかったのですが、あなたが手に入れたのはバナナを持ったゴリラが生活しているジャングル全体でした」
クラスがあるからクロージャは不要というのは、
バナナを簡単に食べられるという話に
ジャングルでも同じことができるから不要と言ってるに過ぎない >>299
たとえがアホすぎだね
ジャングル全体があるからバナナが収穫できる
バナナしかなければ食べたらおしまい
静的言語のが実行速度も速いし生産性も高い
大規模開発もできる
つまり上位互換 バナナを食べるだけなのにジャングルの整備・バナナの収穫までその場で考えなければならない。
ゴリラの飼育、お嫁さんどうするかも考えないとw 何故この文脈で静的言語云々が出てくるのか。
静的言語って言いたいだけか JSに限らず動的言語は必要な機能が揃ってないからだ クロージャの話にどうして静的言語云々が出てるんですかねぇ 初期のJavaは酷かった。
イベントハンドラ登録するだけなのにイベントリスナーのクラス作らないといけなかった。
「む、無名クラスでインラインでも書けるから!」とか。アホかと。
今ではみんなラムダ関数使ってまーすw
だーれもクラス使ってないでーすwww >>307
JavaとJavaScriptの区別もつかない無能 確かに以前のJavaはクロージャどころか関数ポインタ(的なもの)すら無くて辛い言語だったなぁ。
個人的にはJS|TSでクラス使う場面って、
・状態を持つオブジェクトを扱う時
・継承を使う時(WebComponents等)
くらいだと思ってる。 >>307
まああのシンプルさが勉強には良かったけどね。
仕事で使いたくはないけど。
なぜクロージャーが便利なのかということも身を持って知れるし。 Javaに失望したらC#にいけばいいのに
なぜさらに不便なJSなのか webの開発では圧倒的にクロージャーを使うことが多いよ。
あるリストがあって、その中の一つの要素をクリック時に削除するなどの処理を書く場合は自然とクロージャー使うしね elm.AddEventListener(function() { ・・・}) を使うな
function handler() { ・・・}
elm.AddEventListener(handler) を使え派は
どこ行ったんだろうねw
前者はクロージャーだから循環参照を引き起こして
メモリリークのバグになる可能性があるから
後者を使えっていうのが昔は多かったんだが
もっともjQueryは後者の書き方をしても循環参照にならない
仕組みなので問題なかったんだが
(要素に直接イベントハンドラ関数を割り当てるのではなくjQueryの内部的な
イベントハンドラを管理するオブジェクト経由で間接的に参照するので
循環参照にならない仕組みでブラウザのメモリ管理のバグを回避していた) クロージャ使い倒してるけど循環参照してメモリリークなんて一度もなった事無いから、普段全く意識してないなぁ。
TS使ってて他に劣ってるとは全然思わない。あ、ジェネリック周りが複雑過ぎるとは時々思うw next.jsって本がないのが辛い。Gatsbyですらあるのに。どこ見て勉強するとええんやろ。公式をGoogle翻訳? 英語できない人がそんなマイナーフレームワーク使ってはいけない
翻訳なんてつかうからいつまでたっても英語が上達しない
本は情報が常に古い
英語のドキュメントとソースコードでしょ
あとはYouTubeの英語 >>313
俺は世代的にこの問題を意識したことないけど、eventをちゃんとremoveすれば良いって話だよね? >>317
ブラウザバックや進む、リロード時に
eventをremoveするように作らないといかんわけや
とうぜんブラウザバック時にイベントなんて起きないでw そう言えば、jQuery では、DOM の削除時にも、イベントも削除してくれるのだっけ? リロードしてもリソース開放されんってそんな時代あったんか…… Chromeだとリロードボタンの右クリックにキャッシュを飛ばしてリロードするかどうかの選択あるけどね >>319
削除される。もちろんjQueryの命令を使って削除しないといけないけど >>322
キャッシュの話wwwww
で?w
リスナーの登録は?www 自作ソフトをWeb Componentsで作り直そうかと思ってるが
特にメリットがないし、二の足を踏んでいる。 web components は spaとかを作るには向いてないけどある程度静的なものを作るなら向いてると思うで。
templateとかにlit htmlとか使うの前提だけどね lit-html知らなかったわ。面白いなこれ。
ガチンコなアプリでは物足りない感じだけど、既存のものにもさくっと差し込めそう 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 のマーケットシェアが1位って記事があったから載せてみるね
ネット上のマーケットシェアのサイトってソース載ってないのも
どうやって調べてるかわからないものも多いよね 上の方で、ページリロードでリスナーが解放されるかって話
バカにせずに真面目に考えてみます
基本的に、ページリロードで VM のヒープもスタックも全部リセットされるので
普通に考えればメモリリークなんてものはない
Chrome とかはVMどころかページ毎にプロセスまるごと作り直しみたいな話になるので、
メモリリークの可能性は低い
キャッシュというのは、JS/HTML/CSS のソースコードのキャッシュをメモリ上とか
データベースに保存してるってことよね、メモリ解放の話とは関係ない
JIT コンパイラのコードキャッシュとかに関しては、プロセス間で共有してるのかは知らない
まぁでも、これもリスナーのメモリ解放の話とは関係ない
Ref :
https://stackoverflow.com/questions/28896028/do-javascript-memory-leaks-matter-after-a-page-refresh-why は?一生懸命書いたのに、くっそ昔のスレじゃん
泣きたい 泣かないで。
きっとこれからこのスレを読む誰かの為になるよ >>47
Pythonは言語仕様に問題が有り過ぎてwasmへの変換は不可能と決着済
仕方ないのでPythonインタプリタをwasmへ変換して動かしてる
結果JavaScriptより数十倍も遅いため使い物になっていない フロントエンド改修するのにReactかVue3で迷ってる
世の流れ的にいくならReactにしない理由はないと思うんだけどなんか好きになれんのよな
Vueはテンプレートの構文がわかりやすくて好きなんだけど、結局typescriptとの親和性の観点でtsxで書く流れになってきてるから、tsx使うならReactでよくねとも思う
Reactだと依存配列書き忘れとかも以外とやりがちで、Vueはcomputedがその辺全部いい感じにやってくれるから自分的な差はそこくらいかなあ
なんかここで選べみたいなのあります? は?一生懸命書いたのに、くっそ昔のスレじゃん
泣きたい Reactを使いたけど、jsの言語仕様が変態すぎて辛い
jsはチュートリアルさらりと読んだら、理解が曖昧でも
そのままフレームワークの使い方を覚える段階に進んだ方がいいのかな?
言語仕様がぐちゃぐちゃでベストプラクティスを想像できない >>338
webprog、web制作あたりと合体したらいいかも さらに Rect へSvelte とvue をまぶしたようなSolid.jsなるものまであるな
https://www.solidjs.com/ ベンダーじゃなくて発注側なんやけど、Javaができて便利なことある?
例えばベンダー側で実際Javaのプログラム書いたり開発した経験が無くても、発注側で極簡単な改修なら自前でできたり、改修や開発の設計書を読めるようになるぐらいならできるもん? >>344
Javaとスレタイは違うものなのでスレ違い 色々変な仕様くっつきすぎてとっつきにくくなり、素のJSに戻ることになるでしょう フロントエンドをスレタイに入れなければもっと伸びたはず