settingsの置換を図るページの置換を図るページに対する感想等
実験的に採用してみますbsahd.icon
感想はここに書いてください
速度に関する意見
ここでの読み込みの遅さの原因ってHTTPリクエストの数が増えたことによると思うので、通信速度が遅い端末でパフォーマンス調査をした方が良いと思うMijinko_SD.icon
僕はPCでしか井戸端を開かないので、そこまで変わった気がしない
bundle後のコードを送信するとSettingsを自動で上書きするUserScriptとかあればメンテナンス性が上がるのでは
基素.icon変更の意図がわからなかった
パフォーマンス計測したい
importやめてbundleした時には遅くなったからそうなったと記憶しているが、どう言う環境の人がどれぐらい遅くなったのか知らないな...
+1seibe.icon
パフォーマンスに関するpros/consが真なのか、真の場合どれくらいの量なのか評価したい
（計測が終わったらできる議論）
読込の速さとDXが天秤があると思う
さほど手順の煩雑さは変わらない
なら貧弱な回線でも読み込みが早い方が嬉しいように思う
現在、これがどれぐらい違うのか計測していないので不明
自分のPC環境では体感する差はないので、自分には実害は今のところない
yuyuko.icon正確に検証したわけではないけれど一例として報告
素朴な感想としては、元に戻してほしい
自分の環境だと読み込みが遅くなったので
環境:
通勤電車の中
iPhone（PWA）
普段の平日の混み具合だと、
日記ページを開くのに時間がかかることがある
たまにローディングのぐるぐるが出る
今朝は、日記ページが全く表示されなかった
全くという言い方はおかしいか
普段よりも長く待ったが、表示されそうになかったので諦めた
最初は意図がよくわからず、その後nishio.iconさんと同じような解釈に至ったのだけど、
「遅いから速くしよう」でバンドルしてあったものを「遅くなっても個別に別れてた方がいいと思うからそうしよう」と思って修正したということか
おふざけで
ふざけたのは名前だけです。bsahd.icon
そうでしたか、把握しましたyuyuko.icon
うまくいってしまった
自分も許可を求めるな、謝罪せよ的な行動であれば支持したいけれども、いいアイデアとおふざけだと全然話が違ってくるんじゃないだろうか 読み込み速度が変わっていないなら良いが、多少遅くなっているのであれば元に戻してほしい気持ちblu3mo.icon
富豪的プログラミングは、(1) インターフェースの設計において (2) 十分な資源がある ことを前提とした主張だという理解 今回については(1) (2)の前提が成り立っていないと思った
いいアイデアなら、とにかくやってしまいなさい。許可を得るより謝る方がずっと簡単よ。
seibe.iconパフォーマンスに関する感想
トップページの読み込みに時間がかかるようになったと思う
環境：PC（デスクトップ・Core i7）, 固定光回線
3秒弱かかっている
前はこんなにかかっていなかったような
比較していないため、バイアスが掛かった感想の可能性あり
上の方では回線速度が問題になっているようだけれども、クライアント端末の処理速度もボトルネックになっているのでは？
seibe.iconとしては、読み込みはもっと早いほうがいいです
富豪的にリソースが使えるということは富豪的にリソースを使っていいということとイコールでは無いのでは？per_terra.icon
十分なリソースが無い場合が考慮されていない
ユーザー体験の向上のためにリソースを富豪的に使うのは理解できる
増井氏のいう富豪的というのもこれだと理解している
（少しの手間で必要なリソースを大きく節約できるのに、わざわざ）リソースを無駄遣いしているように見える
その上ユーザー体験を悪くしているっぽい
開発中はbundleせずに読み込み、安定しているときはbundleされたコードを使う？bsahd.icon
これでいいと思ってるtakker.icon
あるCSSの開発中にその他全てもimportする必要はないと思うper_terra.icon
UserScriptをscrapboxで開発していた頃は、UserScriptが膨大になるにつれてリロード時の読み込み時間の増加が問題になったtakker.icon
新しいコードを試すたびに30秒くらいかかってた
スペルミス直す→30秒待つ→新しいスペルミスを見つけて直す→30秒待つ→……
私は開発者はリソースを消費することに対して謙虚であるべきだと思っているので、思想の違い？がありそう
メンテナンスをする人にとっては1か所の修正ですべて自動的に直るのはユーザー体験の向上では？bsahd.icon
ProjectCSSを自ら変更する「ユーザー」というのはこのプロジェクト全体から見れば圧倒的に（？）少数だと思うper_terra.icon
25％ほどは何かしら触ってそうbsahd.icon
メンテナーの都合はエンドユーザーは知ったことでは無いので
開発者(=自分)の都合を「ユーザ体験の向上」と主張するのはいくら何でも酷すぎるnishio.icon
しかも他の開発者が本当にユーザ体験の向上のために実装した機能を壊した上でその主張をしているのでさらに酷い
読み込みは若干遅くなったような気がするけど、比較実験できていないのでなんとも言えないbiwa.icon
流れを読めてなかったら申し訳ないんだけれども、settingsの置換を図るページの置換を図る目的とかって聞いてもよいでしょうかyuyuko.icon
めちゃいい質問inajob.icon基素.icon
なにかの問題を解消するため？
現在のsettingsの置換を図るページはimportを減らして高速化しようとしていますが、masui.iconの富豪化思想をusercssに入れてみましたbsahd.icon 実際あまり重くありませんbsahd.icon
たぶんfirefoxだと劇遅になるtakker.icon
まあfirefoxで見てる人なんていないか……
この方はFireFox使いでは？per_terra.icon
あれ、そうでしたかtakker.icon
上見たら6.3秒とあった。さすがに遅い
あれは3g相当の環境で読み込んだ場合の計算なので実際はそこまでいかないはず
以前UserScriptをbundleせずimportして使っていたら、ロードに30秒かかっていたことがある
Scriptのimportだけは危険(訂正:他人のプロジェクトからの)だからやめろbsahd.icon
importを増やしまくってどのくらいimportしたら重いのかを調べてみただけかも
良い通信環境で0.02秒が0.04秒になっても気づかないが、悪い環境で0.2秒が0.4秒になると辛い、みたいな非対称性がありそうblu3mo.icon masui.iconの富豪化思想をusercssに入れる、その目的を聞こうとしていたyuyuko.icon
masui.iconさんの富豪化思想をusercssに入れることに何かのメリットがあるという解釈でいいのかなyuyuko.icon
メリットがあるかはともかく、とりあえず試してみるのは悪くないと思うtakker.iconper_terra.icon
なるほど！ 確かにそうかyuyuko.icon
自分もなんとなくstreamのフォントを突然変えたりしたことがある
カオス（関わってないのにこんな言い方して申し訳ないですが）になってしまっていたコードをper_terra.iconさんが精査し、最適化してくれたと認識してたので、「あれ？変えちゃうの？」という素朴な疑問があるyuyuko.iconblu3mo.icon
とスマホからちまちま書き込んでいたら↓のper_terra.iconさんの内容とちょっとかぶってしまっていた……
もとのsettingsに戻している作業のように見えるper_terra.icontakker.icon +1yuyuko.icon
CSSを学ぶのに良い題材だと思ったので
数が多いimport元のページを全部書き換えていく勇気はなかった
ただの新入りだったので
元のCSSを直接更新しなかった理由はそういうことだったんですねtakker.icon
明日以降に変更反映させてもいいですか？
やってくれるんですか？！ぜひお願いしますper_terra.icon
はーいtakker.icon
結果としてimportを使わない運用のほうがメンテナンス性が高いように感じている
書式の統一やデバッグと言った点で利点がある
ただし各ページとの不整合が生じているのは問題であると思っている
+1bsahd.iconなのでこれを作った
「各ページに反映させる」がどういうものか想像ついていないのですが、各ページにsettingsの置換を図るページの行リンクを貼ればメンテする箇所は1箇所で済んで良さそう？seibe.icon まあそうですねper_terra.icon
暗に他のプロジェクトでimportする場合を想定していた
が、これはそもそも非推奨であるので考慮しないのも手
cssは非推奨ではなかった気がします
UserScriptほどではないにしろ安全性を理解しておくのは重要wogikaze.icon
（seibe.icon追記）これ競合がない場合は行リンク貼り付けて、あるばあいは行リンク＋単独で動作するコードを貼ればいいだけだなと思った
importを使うこと自体は問題ない、バンドルすればロード時間の問題は消えるので
バンドルする必要もないと考えているのならそれはちょっと…
特に多段importはクライアントサイドでやるべきではないと思っている
サーバーサイドでSSGとかCSSプリプロセッサー使うとかならともかく
単にリクエスト数が増えるだけでなく明らかに遅延する
必ずバンドルするという手順を踏むことの有意性も感じている
特に大規模プロジェクトにおいて、あらゆる変更が即座に反映されるのは微妙
不完全な状態のCSSを読み込んでしまう人がいる可能性がある
settingsに変更を加えない限り安全であるべき
settingsから参照されていることはそれほど自明ではない
最初期のsettingsの変遷経緯を踏むような感じがしている点でふーむと思っているtakker.icon
それはそれとして許可を(ry
新入りなので昔話は知らなかったbsahd.icon
現時点で動作に不具合は見受けられませんseibe.icon
井戸端だと、車輪の再実装は何度でもいいぞもっとやれな感じはする tsuzumik.iconの使い方だと今の状態でも特に不便なさそうです
日記に感想を書いてと書いてあったが、最初に思った感想は「意図がわからない」だったnishio.icon
上のログを読んで「遅いから速くしよう」でバンドルしてあったものを「遅くなっても個別に別れてた方がいいと思うからそうしよう」と思って修正したということか
速度とメンテナンス性はトレードオフになりがち
「速度が遅くなると困る人がいるかもしれない」は「いないかもしれない」と相殺するので、具体的に「自分はこういう環境で使ってて、この変更でこれくらい遅くなる」的な話が出てくるといいな
おそらくずっと家にいる人よりも電波の悪いところに移動する人が影響を受ける
これ基素.icon
言葉を選ばずに言えば、ではなぜそれをProjectCSSに反映する必要があるのか、という疑問があるper_terra.icon
遅くなったと訴える人がいる以上まあそんなに上手くいってないわけで、これをそのまま採用し続けることには問題があると考えています
選択肢がいくつかあって
per_terra.iconさんの変更を反映し次第、bundle&minifyしたコードに戻す予定ですtakker.icon
このままにしてほしい方がいらっしゃればコメントください
簡単に戻せるので大して手間かかりません
戻してもらって大丈夫ですseibe.iconbsahd.icon
2024-05-04 13:02:00 戻しましたtakker.icon
思いつきで追加した機能もあるので、Settingsのほうに変更内容書いておきます
per_terra.iconさんの変更を反映はまだです