ProjectCSSの実装手法ごとのメリット・デメリット
明日話の整理のために、settingsの手法をいくつか分けておこうと思う
誤解はありそうなので修正希望
サンクス
いわゆるno bundleと言われる仕組みと同等
例
ほとんどのscrapbox projectのProjectCSS/UserCSS
井戸端の最初期のsettings
scrapbox-bundlerができるまではこの手法だった
➕️単純明快な仕組み
➕️bundle不要で即時反映される
CSSが即時変更されるため、デメリットとも言える？
➖️パフォーマンス上の問題がある。他2つと比べて遅い
➖️CSS間でコンフリクトが起きたとき、デバッグが大変
そうやってデバッグしたCSSは、個別で動くかはわからなくなる？
本質的には依存関係にあるものを独立関係にしたことで生じる問題のよう
CSSのデバッグはJSと比較してそれほど大変でないと思っている
dev toolでその場で書き換えながら試せる点が大きい
例
settingsの置換を図るページ以前の井戸端のProjectCSS
2024-05-04現在の/takker/Settings
たしかUserCSSをbundleするDeno scriptが登場してから使われるようになった手法なはず
➕️パフォーマンスが直接importよりもよい
➖️反映にはbundleさせる必要がある
そんなに手間ではない？ ちょっとよくわかっていない
ソースファイルをビルドするくらいの手間なのかな(スクリプト言語しか触ったことないのでわからない)
手順
1. リンクを押す
2. 出てきたコードをコピーする
バグ修正善処しますｻｰｾﾝ
3. 以前のコードに上書きする
そんなに手間ではないですね
置換もエディタ使えばすぐで、CSSの開発はエディタを使える環境（PC）を想定してよいだろう
➖️CSSコンフリクト時の問題は直接importを引き継ぐ
➕️1ページで管理するため、個別CSSのコンフリクトのデバッグが容易
➕️新たにCSSを追加するときの実装も容易
このメリットはよくわからない
(以下個々のCSSを直接importの項と同上)
➖️bundleさせるよりかはパフォーマンスが悪くなる？
ファイルサイズが大きくなる以外のperformance悪化要素はなさそう
➖️個別CSSと同一のコードにならなくなる。同一化可能な場合は、同一にする手間が生じる
etc.
結局整理しなかったや
リンクを作って各自が示しているものをある程度ラベリングしようと思ってた
リンク作成ありがとうございます
整理のためにさんの書いた注記を一部削除しました(情報量は減らしてません)
問題があればrevertします
無問題です ありがとうございます