Создает ли Sass плохой код?
- 18 октября, 2022
- 1:33 пп
- Нет комментариев
Время от времени я слышу от некоторых из знакомых разработчиков, что Sass это, мол, конечно хорошо и удобно, но в конечно счёте сгенерированный им код существенно захламляет файлы стилей лишними селекторами.
Давайте разберёмся, так ли это. Грозит ли использование Sass потерей контроля над файлами стилей и откуда появилось это мнение. Поехали.
Главным аргументом против использования Sass можно считать “плохой код”. Стили CSS, которые получаются после генерации, отличаются вложенностью селекторов. И это одно из основных преимуществ данного препроцессора (как, кстати, и большинства других).
Необдуманный стиль написания кода, незнание правил структуры проекта, хранение спрайтов внутри стилей, запутанные имена переменных, костыли и лишний код, злоупотребление значением !important и остальные “улучшения” в результате выдадут такой результат, который сможет гарантировать отрицательный ответ на любом собеседовании.
Причины плохого кода
Препроцессоры (в частности, Sass) придуманы для упрощения труда разработчика, увеличения скорости разработки и лёгкого управления проектами. Если у программиста возникают сложности с препроцессором, то скорее всего из-за неопытности. Отсюда получаем первую и главную причину плохого Sass-кода: молодой и неопытный организм за клавиатурой.
С опытом приходит понимание, как можно добиться того же результата значительно меньшим объёмом кода. Просто не опускайте руки :).
Вложенность увеличивает вес селекторов
Слишком большая вложенность таки да — увеличивает. В любом деле нужно знать меру, особенно в программировании. Если вы можете не добавлять излишней вложенности — не добавляйте. А ваши селекторы станут лёгкими и шелковистыми.
Вообще, написание селекторов и выбор имён для классов и идентификаторов — вопрос достаточно сложный, и запутаться новичку в нём проще, чем кажется.
Для начала запомните важное правило: не пытайтесь повторять структуру вашего html-файла в Sass. Вначале это может показаться логичным и удобным, но вы очень быстро об этом пожалеете. Например, если нужно использовать один и тот же класс в разных местах страницы.
Миксины (mixins) увеличивают код в разы
Некоторые считают, что обратная сторона миксинов — это раздутый до неуправляемости код, и причина тому — повторения. Опять же, это утверждение не лишено смысла: бездумное использование миксинов создаст вместо красавицы чудовище.
С которым вам потом жить.
Простой миксин из пяти строк, добавленный в десять селекторов, создаст 50 строк CSS-кода. В большинстве случаев это не тот результат, который вы хотели бы получить.
Если в миксине нет аргументов, вместо него можно обойтись дополнительным классом. Здесь всё просто: если код миксина не меняется в зависимости от передаваемых аргументов, то стоит задуматься, есть ли смысл в его использовании.
Директива extend создаёт нечитаемые селекторы
Для начала задайте себе вопрос: ваш CSS должен быть читаемым человеком или машиной? Если Sass создан для читаемости и удобства создателя, то CSS должен быть как можно более “удобным” для браузера.
Для браузера по большому счёту без разницы, как отформатирован код, поэтому минификация и удаление комментариев — must have для любого проекта.
Красивый код проигрывает быстрому коду по всем параметрам. Единственный случай, когда это правило не действует — если после генерации ваш CSS-код придётся править кому-то вручную. Но это вряд ли.
Sass не подходит к OOCSS и другим архитектурным подходам
Нет, подходит.
Для начала уточним, что такое OOCSS. Это означает объектно-ориентированный CSS (Object-Oriented CSS). В основе подхода лежат два правила:
- Разделение структуры и оформления
- Разделение контейнера и контента
Если вы хотите каждому элементу на странице назначить свой класс, Sass это позволяет сделать очень легко.
Теперь зайдём с тыла: если вам нужна вложенность элементов (так может быть удобнее следить за структурой страницы), Sass и это сможет. Вы можете назначить один класс родительскому блоку, а все вложенные элементы оформлять в зависимости от уровня вложенности и имени тега. Как несложно догадаться, на Sass это сделать будет намного проще, чем без него.
В конце концов вы даже можете взять готовый CSS-файл и переименовать его в SCSS, а дальше использовать только те функции, которые необходимы и допускаются вашим внутренним цензором.
Sass в данном случае нет никакого дела до вашего подхода к архитектуре страницы, он просто делает свою работу и помогает вам делать вашу.
Изучите, как работает компилятор
Если у вас есть опасения, что Sass-код будет обработан “как-то не так”, поиграйте в компилятор. Для этого откройте в одной вкладке редактора SCSS-файл, а в другой — скомпилированный CSS.
После этого заварите большую кружку зелёного чая и изучите, как то или иное правило было обработано и что получилось в результате.
Sass — это инструмент
Как мужчина в синем купальнике с буквой S не сможет летать, так и любой парень с ноутбуком и Sass-компилятором не сразу становится фронт-енд программистом. Sass — это всего лишь способ, средство для упрощения работы, которую всё равно нужно делать, с ним или без него.
Sass не сделает вас крутым, он вообще ничего не сделает, пока вы не скажете ему. Поэтому берите ответственность в свои руки и решайте сами, как вам удобнее верстать.
Похожие записи
