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