Доброго времени суток! Часто приходится отвечать на вопросы о всевозможных инструментах для front-end разработки. Поэтому решил объединить ответы в данном материале. В данной статье речь пойдет об инструментах, призванных облегчить жизнь front-end разработчика. Постараюсь объяснить, почему в большинстве случаев следует хорошо обдумать все «за» и «против», прежде чем их использовать.
Bootstrap
Начнем с Bootstrap. В Joomla он появился с попытками унифицировать интерфейс (JUI). Одинаковые кнопки, одинаковые поля форм, вид таблиц и т.д. обеспечивают совместимость сторонних расширений с шаблоном. Верстка с использованием bootstrap является хорошим решением для back-end разработчиков и тех, кто хочет иметь аккуратный интерфейс, не прилагая к этому излишних усилий.
Также из плюсов Bootstrap несомненно стоит выделить его JavaScript составляющую. Очень хорошая вещь.
А теперь минусы.
- Все сайты, использующие Bootstrap, похожи друг на друга, т.е. отсутствует уникальность. Подобные сайты-близнецы попросту не запоминаются.
- Негибкость. Если нам нужен интерфейс Bootstrap, тогда никаких проблем. Если требуется что-либо более-менее отличное, то приходится с самых первых шагов бороться со стилями по умолчанию. На практике получается двойной труд:
- верстаем то, что требуется
- заставляем это работать поверх стилей Bootstrap.
- Избыточный код. То, что реально сделать двумя вложенными блоками, зачастую делается пятью. Любые изменения влекут за собой часы мучений.
- Ввиду своей кажущейся простоты, некоторые используют компоненты Bootstrap не по прямому назначению. Посмотрите форму авторизации стандартного шаблона beez2 :) Возникает вопрос: а нужна ли такая унификация?
Для большинства уникальных шаблонов Bootstrap противопоказан. Нужно его переделывать в шаблон, а не создавать шаблон при помощи этой библиотеки. Поначалу кажется, что все должно быть наоборот. На практике чаще всё оказывается совершенно иначе.
Можно долго перечислять все недостатки и достоинства Bootstrap, но смею надеяться, что Вы уже уловили суть: либо переделываем библиотеку под задачу, либо сталкиваемся со всем вышеперечисленным. Есть еще третий вариант — не используем вообще.
Templates Frameworks
Так называемые Templates Frameworks или «шаблонные фреймворки». Разрабатываются со смыслом облегчить жизнь верстальщикам клубов, которые их разрабатывают. Можно на этом и ограничиться в объяснениях :) Но все же поясню. Любая из этих громоздких надстроек создается с целью сокращения времени на изготовление шаблона. Клубные дизайнеры изначально рисуют макет с учетом реалий фреймворка. Своеобразное LEGO. Посмотрите на работы RocketThemes. До появления Gantry Framework, каждый их шаблон был уникален и оригинален. После - однообразие, отличаются только цветами.
Когда-то мне нравился Gantry Framework. Любовь прекратилась после того, как коллега попросил меня подкорректировать стили в уже готовом клубном шаблоне. Работа, которая в обычных условиях заняла бы от силы 1 час, заняла более 4х часов. И это учитывая, что на тот момент я неплохо ориентировался в Gantry.
После этого интерес к шаблонным фреймворкам угас полностью. Пришло понимание нерациональности использования их в частных проектах.
Если требуется сверстать один шаблон, то использовать что-либо подобное не имеет смысла. Вы в несколько раз увеличите время на разработку. Ваш шаблон будет работать медленнее, нежели без использования фреймворков. В конце концов, нужно сперва учить HTML, CSS, PHP, JavaScript. И только имея знания и опыт в этих дисциплинах, реально что-либо там сделать. Многие обманываются именно этим, считая, что оно само за них выполнит всю работу.
LESS & SASS
LESS, SASS - очень модные и актуальные препроцессоры. Просто обязаны сокращать и оптимизировать наш труд. Условия и миксины – то, что нужно! А теперь посмотрим сюда :) Все те же переменные. Есть в планах и вложенность, и прочее, что так отстаивают в препроцессорах их поклонники.
По поводу сокращения трудозатрат — вопрос сам по себе спорный. Препроцессоры скорее усложняют работу. Кода всегда получается больше, чем при работе обычными способами. Его больше, как в исходнике, так и в генерируемом css. И в этом коде всегда много лишнего. Например, для border-radius уже давно не нужны вендорные префиксы. Современные браузеры сами обновляются до актуальных версий, а старые браузеры не поддерживают CSS3 с любыми префиксами. Тем не менее, препроцессоры мило предоставляют возможность не дублировать свойства со всевозможными -moz- и -webkit-.
Форматирование генерируемого кода просто чудовищно. Очень трудно ориентироваться в том, что получается на выходе в файле с расширением .css. Быстрее и проще все сделать без использования препроцессора.
В любом случае, использование препроцессоров в верстке небольших примитивных шаблонов нерационально. А такова основная масса индивидуальных шаблонов для Joomla, которые люди создают для себя сами, или нанимают для этого фрилансеров.
Для саморазвития, конечно же, стоит поработать со всеми доступными инструментами. Я лишь стараюсь описать их недостатки и подводные камни.
Все вышеописанное является моим субъективным мнением, построенном на личном опыте. Нужно было хорошо освоить всё перечисленное (набить множество «шишек»), чтобы в конечном счете отказаться от их использования. Чем сложнее становились задачи, тем меньше эти инструменты годились к использованию.
Возможно, в будущем что-либо изменится к лучшему, тогда, возможно, я пересмотрю свои взгляды. Но на данный момент у меня нет для этого причин.
