Почему я не доверяю CSS Frameworks Перевод

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

Нечитаемый код и длинные HTML-теги

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

Нежелательные эффекты

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

Ограниченная настройка

Использование CSS-фреймворков может значительно упростить создание пользовательского интерфейса. Однако, когда дело доходит до индивидуального дизайна, все может оказаться немного сложнее. Настройка, хотя и желательна, может стать проблемой, особенно для младших разработчиков интерфейса, где могут потребоваться некоторые действия (как в случае с Bootstrap).

Имена классов, которые нужно запомнить

Изучение имен классов, специфичных для платформы, может быть утомительным (хотя имена классов часто тесно связаны со свойствами CSS). Вместо того чтобы программировать интуитивно, вы часто обращаетесь к документации, чтобы вспомнить, какой шрифт — «жирный» или «fw-жирный»…

Зависимость от платформы

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

Назад к простоте

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

Конечно, я не могу игнорировать преимущества CSS-фреймворков. Они могут значительно ускорить разработку, обеспечить согласованность и упростить управление обновлениями. Но вот в чем загвоздка: удобство непосредственности не должно заставлять нас упускать из виду ценность настройки и глубокого понимания нашего собственного кода.

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

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

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

https://dev.to/winifyer/why-do-i-distrust-css-frameworks-and-why-should-you-sometimes-347o