CSS-фреймворки? К черту! Я сам всё напишу!

На днях с бывшим коллегой разгорелась горячая дискуссия, нужны ли вообще CSS-фреймворки или ну их, обойдемся.

Он почитал пару статей на хабре, поделился со мной. Ну и тут понеслось 😆.

Изначально фреймворки (не только css) создавались, чтобы облегчить жизнь разработчикам. Однако, что-то пошло не так...Основным аргументом противников css-фреймворков является следующий тезис:
“Очень много классов - я не хочу тратить время на их изучение”.

Ребята топят за то что приходится изучать специфику, документацию каждого фрейма, который они юзают, и их многочисленные классы.А ведь действительно, есть фреймы, которые далеко ушли от простого помощника, накидать структуру шаблона, кнопок и инпутов. Например: Semantic UI и Uikit.

Эти товарищи предлагают и анимацию, и параллаксы, и комментарии, и еще много другого. Из чего складывается впечатление, что ты должен верстать именно по их гайдлайну. И в результате мы имеем весьма похожие дизайны, твердят противники фреймворков. К счастью они ошибаются 🙂.

Мы подобрались ко второму аргументу, который звучит так:
“Все дизайны на css-фреймворках одинаковы”.

В итоге все сводится к тому что “да ну нафиг это, напишу-ка я все сам!”.

CSS-фреймворки? К черту! Я сам всё напишу!

Что же, давайте попытаемся раскрыть все положительные стороны фреймов и опровергнуть доводы противников.

Предлагаю сразу отмести громоздкие фреймворки такие, как Semantic UI и Uikit. Сюда бы я кстати отнес и Materialize. Этот фрейм, как и следует из названия, предлагает компоненты в стиле Material, который так активно пропагандирует Google.

Брать эту троицу, выкидывать из них всё и верстать под свой дизайн пожалуй глупо. Разумнее поставить их в группу фреймворков для админки, как какой-нибудь системный функционал, интерфейс которого не играет серьезной роли, “быстро что-то накидать”.

Существует на рынке еще семейство мини-фреймворков, такие, как: Pure, Picnic CSS, Chota. Честно говоря, никогда не пользовался ими 🙂.

Pure и Chota не имеют исходников в виде SASS/SCSS в отличие от Picnic CSS.

Возможно есть смысл взять Picnic CSS за основу вашей будущей темы.

Минус в использовании таких фреймворков заключается в том, что вы впустую потратите время на их изучение, так как вряд ли встретите их в последующей работе.

Ну и наконец, на арену выходят такие силачи как: Bootstrap, Bulma, Foundation.

Foundation я пробовал использовать несколько лет назад, тогда он мне показался каким то слишком “инженерным”.По cути, эти фреймворки смогли найти баланс между нагроможденностью и пустотой, но говорить мы будем про Bootstrap. Кстати, я его терпеть не мог до определенного времени, как и всё хайповое.

Итак, почему же противники фреймворков ошибаются когда утверждают об их ненадобности?Bootstrap — самый популярный css-фреймворк. Я не могу говорить о точном процентном соотношении, но уверен, что 80% тем написаны на Bootstrap. Для любого JS-фреймворка есть библиотеки Bootstrap, и не одна.

Таким образом, потратив чутка времени на изучение основных компонентов Bootstrap, вы в будущем сэкономите немало времени на понимание чужого кода и написания своего. При чем тут свой код? Ответ прост. При каждом запуске проекта, при каждой верстке мы начинаем именовать стили по-разному. Это неизбежно, так как мы постоянно учимся, и так же меняются наши вкусы. И вот у нас набирается десять проектов, и в каждом из них разное именование классов кнопок, форм, колонок и т.д.

Фреймворк (каркас) - держит нас в определенных рамках, и это хорошо!

Следующий, немаловажный аргумент в пользу фреймворков, это что они миллион раз протестированы во всех браузерах. А что всплывает, то фиксится, пока мы спим.

Также нельзя забывать и работе в команде. Когда на проекте один человек, классы можно называть как душе угодно, но когда людей десять, двадцать, все может превратиться в не пойми что. Придется писать спецификацию о том как можно делать, а как нельзя.

И наконец, про то что все дизайны одинаковые по причине использования css-фреймворков.

Да, если фреймворк подключить через CDN или просто полный, со всеми потрохами css файл и потом пытаться стилизовать, может быть и так. И то, любой стиль можно переопределить.А если их использовать как положено, через препроцессоры, брать только те компоненты которые реально нужны, переопределить переменные, мы можем добиться любого дизайна согласно макетам.

На сегодня все! Хорошего тебе дня!

Ну и по традиции моя телега

⬇⬇⬇

77
6 комментариев

Я отказался от использования таких движков, ибо заметил, что работы становится больше, гибкости меньше.
1) Тонна избыточного неиспользуемого кода.
2) Далеко не все дизайнерские изыски можно реализовать стандартными (в рамках движка) средствами.
3) Дизайн действительно становится узнаваемым, шаблонным, и замена цветов не поможет.
4) Нарушение принципа отделения оформления от семантики содержимого: по сути оформление осуществляется через атрибуты HTML тэгов.
5) Подключать эти библиотеки надо в начале кода страницы. А зачастую полезно разделить загрузку стилей - часть сразу грузить синхронно, а остальное - в конце или асинхронно.
6) Сложности с нестандартными динамическими элементами оформления.

Для себя сделал вывод: если требуемое оформление полностью покрывается функционалом фреймворка, то можно его рассмотреть, в остальных случаях не стоит оно того. Но и в простых стандартных случаях я бы не стал фреймворки использовать, ибо для простых случаев проще написать простой легкий код, не обременяя его ничем лишним.

2
1

Спасибо за развернутый комментарий!

Есть такие типы проектов, где дизайн как таковой вообще не нужен. Типа личных кабинетов, самописных CRM, конструкторов коммерческих предложений и т.д. Короче все, что сделано не для рекламы, а для внутренней работы.
Так вот такие интерфейсы проще всего клепать теми же бутстрапами, потому что это быстро и легко масштабируемо. Завтра в самописной CRM появится еще один, 181-й раздел с простой таблицей и формой из трех полей. Скомпоновал его из компонентов и выгрузил за час. Удобно.

1

желание писать все с нуля не от большого ума, скорее наоборот.

ну часто это амбиции, эго. Разработчикам их не занимать :)