Комментарии 5
Очень жизненно. Подписываюсь под всем.
На мой опыт — CSS вообще никогда не спасти, если только не было принято волевого и грамотного решения в самом начале проекта, о том, что CSS пишем модульный, scope-based, и все проблемы CSS принимаем близко к сердцу, а не «тьфу, это мелочи». Если этого не было, то даже на небольших проектах CSS не спасается, можно только переписать фактически полностью.
Всё потому, что CSS сам по себе имеет худшие черты монолитного кода (тот самый, который с go to и без подсистем) — потому что есть только global scope и нет никаких обособлений, и более того, еще даже и хуже монолита, потому что может быть составлен из множества частей, которые могут (и будут) влиять друг на друга непредсказуемым образом.
А модульный и scope-based CSS писать крайне непросто, потому что хороших инструментов нет. CSS-in-JS имеет проблемы с тормозами и с vendor lock, когда взяв какую-то либу, мы оказываемся полностью к ней привязанными, штуки типа CSS modules или Shadow DOM имеют проблему открытости — закрыть какой-то scope мы можем без проблем, а вот обеспечить возможность что-то нужное изменять с вышележащего уровня — можно только очень кровавым и плохо масштабируемым путем (через переменные, через особый билд-процесс, и т.д.). Когда браузеры запилят ::part и ::theme — теневым DOM скорее всего можно будет начать пользоваться, но всё равно не безоблачно, там всё так же есть проблемы с accessibility и вообще море всяких мелочей, вызванных изоляцией, которые будут продолжать отравлять жизнь.
HTML, если он пишется вне UI компонентов (неважно на каких технологиях) — тоже вообще никогда не спасти. Или компонентный подход, или каша и legacy.
На мой опыт — CSS вообще никогда не спасти, если только не было принято волевого и грамотного решения в самом начале проекта, о том, что CSS пишем модульный, scope-based, и все проблемы CSS принимаем близко к сердцу, а не «тьфу, это мелочи». Если этого не было, то даже на небольших проектах CSS не спасается, можно только переписать фактически полностью.
Всё потому, что CSS сам по себе имеет худшие черты монолитного кода (тот самый, который с go to и без подсистем) — потому что есть только global scope и нет никаких обособлений, и более того, еще даже и хуже монолита, потому что может быть составлен из множества частей, которые могут (и будут) влиять друг на друга непредсказуемым образом.
А модульный и scope-based CSS писать крайне непросто, потому что хороших инструментов нет. CSS-in-JS имеет проблемы с тормозами и с vendor lock, когда взяв какую-то либу, мы оказываемся полностью к ней привязанными, штуки типа CSS modules или Shadow DOM имеют проблему открытости — закрыть какой-то scope мы можем без проблем, а вот обеспечить возможность что-то нужное изменять с вышележащего уровня — можно только очень кровавым и плохо масштабируемым путем (через переменные, через особый билд-процесс, и т.д.). Когда браузеры запилят ::part и ::theme — теневым DOM скорее всего можно будет начать пользоваться, но всё равно не безоблачно, там всё так же есть проблемы с accessibility и вообще море всяких мелочей, вызванных изоляцией, которые будут продолжать отравлять жизнь.
HTML, если он пишется вне UI компонентов (неважно на каких технологиях) — тоже вообще никогда не спасти. Или компонентный подход, или каша и legacy.
штуки типа CSS modules
Не совсем понял какие проблемы с css-модулями. Был бы благодарен за примеры.
Да всё те же — собирая, скажем, библиотеку компонентов с css, завёрнутым в модули, вы теряете возможность простым способом (т.е. подключив еще один css) перекрывать стили снаружи. Есть варианты, но ни один из них не особо простой.
вы теряете возможность простым способом (т.е. подключив еще один css) перекрывать стили
так это ж фича) компонент защищён, чтоб снаружи его какой-то внезапно подключённый бутстрап/виджет чата не поламал.
А если нужно как-то кастомизировать компонент снаружи, добавляем пропс типа externalClass, и его подмешиваем в className последним (после классов из css-модуля этого компонента). Отлично всё перекрывается.
Кроме того есть же composes.
так это ж фича)
Это не фича, потому что полностью перечеркивает первую букву в CSS.
Разумеется, это плохо, что в CSS можно перекрыть что угодно и откуда угодно. Но абсолютно прекрасно, что в CSS вообще можно перекрывать. Всё, что тут нужно — это добавить перекрытию упорядоченности, а не убивать его совсем.
А если нужно как-то кастомизировать компонент снаружи, добавляем пропс типа externalClass
Это один из более сложных и немасштабируемых способов, да. Теперь чтоб стилизовать компонент — вам нужно что-то писать в код (это уже очень плохо, потому что то, что раньше было просто CSS, теперь еще «утекает» в код). А если у вас либа сложных компонентов поверх либы простых компонентов — написать в код в двух местах. И так далее.
Кроме того есть же composes.
Он-то как поможет?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Методы борьбы с legacy-кодом на примере GitLab