Bootstrap или свое решение

Хекслет и все его сайд-проекты: code-basics.com, codebattle.hexlet.io, guides.hexlet.io реализованы с помощью Bootstrap. Причем, в основном, это стандартный бутстрап, иногда расширенный с помощью его встроенных механизмов (theming).

Почему мы это делаем?

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

Это особенно важно, учитывая, что для современных it-бизнесов наиболее критичная метрика — time to market, то есть скорость, с которой изменения доставляются до пользователей. Быстрые и частые релизы позволяют не тратить время на ненужные вещи и делать только то, что пользователям нужно по-настоящему.

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

С плюсами понятно, а что насчет минусов? Ведь сайт выглядит не “круто”.

Как показывает практика, влияние дизайна на успешность продукта нередко переоценивается. Более того, на Хекслете происходит ровно наоборот. Сейчас дизайн более стандартный для Bootstrap, чем был в начале 2018 года (у нас была попытка сделать что-то совсем своё), и мы получаем много положительных отзывов:

Хороший материал, интересные задачи, приятный интерфейс — мне нравится

Но еще большему числу людей это вообще не важно:

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

Наличие контента и его качества решают

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

Я знаю, что на этом моменте многие могут взгрустнуть, потому что есть “заказчики”, которым часто финтифлюшки важнее, чем, собственно, сам бизнес. К счастью, Хекслет — наш проект, и мы вольны принимать любые решения, которые нам кажутся эффективными.

Bootstrap мешает, если нужно кастомизировать

Так действительно было до версии Bootstrap 4, в которой большая часть системы конфигурируется через SASS. И дело не только в наличии сотен переменных для всего подряд, но и в настоящем расширении поведения за счет механизма миксинов. Подробнее тут https://getbootstrap.com/docs/4.3/getting-started/theming/.

Проще и быстрее написать свое

Проще ли написать свое? Конечно! Если у вас стоит задача прямо здесь и сейчас заверстать какой-то кусок, который решает конкретную задачу, то намного проще накидать пару-тройку своих классов и радостно перейти к следующей задаче.

Но у любого решения есть своя цена. В первом приближении все выглядит хорошо, но что если глянуть глубже и дальше?

Проекты редко делаются одним человеком, да еще и frontend-разработчиком. В команде всегда есть хотя бы один-два бекенд-разработчика. Они вполне могут верстать, но вряд ли это любят и обладают экспертными знаниями в верстке.

Как только в проекте появляется своя верстка, то все, кто не принимают участие в ее создании, будут вынуждены ждать тех, кто ее пишет. То есть замедляется time to market. Чем больше верстка заточена под конкретные ситуации, тем меньше возможностей для маневра.

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

• Bootstrap создается тысячами разработчиков, внутри него решены все распространенные проблемы, причем наиболее универсальным способом. Все это благодаря огромному коммьюнити.

• У Bootstrap очень подробная документация. Разобравшись с ним один раз, это будет помогать всю последующую жизнь, так же как и владение git. Своя документация никогда не дойдет до такого уровня.

• Стоимость создания общего решения во много раз дороже создания частного решения. Обычно программисты недооценивают, во что им выльется сделать нечто универсальное. В итоге время будет тратиться на обкатку этого решения, а не на выполнение задач проекта.

• Bootstrap настолько популярен, что для него существуют библиотеки под каждый фронтенд-фреймворк и темы под все популярные виджеты. Еще минус куча работы.

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

Итого

Bootstrap — отличный инструмент, который позволяет резко сократить time to market. Наибольший эффект от его использования возникает там, где выполнятся перечисленные ниже условия:

• Для вас критично быстро выкатывать новую функциональность

• Дизайн не определяет успешность вашего проекта с точки зрения бизнеса

• Вы сами принимаете решения по внешнему виду продукта

• Вы готовы ограничивать свою фантазию доступными возможностями для минимизации time to market

Больше про бизнес и разработку я пишу в своем телеграм канале Организованное прогрммирование