◆ 速度で問題でてるわけでもないのに わかりづらくなるようなことしてまで速度速めてどうするの
◆ それなら最初からフレームワーク使なければいいのに

フレームワーク関係の記事を見ていると変にチューニングを頑張ってるのをたまに見ます

例えば React の useCallback などを使って毎回リスナの関数が変わらないようにしてるのもその一つです
私も似たようなことをしてたりしますが 結局その辺ってほぼ自己満足なんですよね

それで変わるほんの僅かな時間が問題になってるならやるべきでしょうけどそれが問題になるケースはほぼ無いです
ベンチマークのために何千回や何万回も呼び出した結果 100 ms だったのが 5 ms になったとか言われてもすごいけど無駄な努力だよねとしか思えないわけです
ユーザが一瞬の間に何千回や何万回もその処理が起きるような操作をするなんてまずないです

仮に 100ms かかってもボタンを押したときの処理なら多くの場合許容範囲内だと思います
スクロールみたいなものだとちょっと頻度を下げたほうがいいと思いますけど


その速度のためにやってることが 意味のない for 文を回してるとか 副作用のない純粋関数なのに返り値を受け取らず捨ててるとか 使ってない変数がいっぱい宣言されてるとか 絶対 true になる if 文とか そういうムダかつコード的にも長くなりわかりづらくなるのであれば積極的に無くして良いと思います

しかし フレームワークのチューニングなんて呼ばれるものは コード的には長くなって読みづらくなるようなものがほとんどに思います
余計なことしなければスッキリしていて見やすくわかりづらいものだったのに 価値のない速度を求めた結果わかりづらくなってるならやらないほうがマシですよね
わかりづらくしてまでほんの少しの速度を求めるのならフレームワークなんて使わず直接実装すればいいんです
仮想 DOM などで差分を見つけて……とかするよりも 起きたイベントに応じて必要最低限の場所だけを直接 DOM 操作で書き換えのほうが圧倒的に速いです

このブログでもムダな速度比較とかしてるのであまり人のこと言えませんが 初心者の人はそういうのをみても真似しないほうがいいです
プログラミング関係の名言?にもあった気がしますが 最初から余計なことは考えず必要になってからすれば十分です