Хекслет и все его сайд-проекты: 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
Больше про бизнес и разработку я пишу в своем телеграм канале Организованное прогрммирование
Комментарии (23)
ALapinskas
07.10.2024 13:50+2bootstrap был удобен когда не было flex и все делалось блоками. А сегодня гриды и разметка намного удобнее делаются нативно с помощью css. Bootstrap может пригодится разве как boilerplate для форм, модалок, слайдшоу и тп.
toxicmt Автор
07.10.2024 13:50И получится рукопашная css, со всеми вытекающими. Плюс с "намного удобнее" не соглашусь. Людям, которые этим пользуются (а не создают), удобнее когда есть стандартизированная верстка, а не своя кастомная, которую, кстати, если обобщать, получится что-то типа своего бутстрапа
Spaceoddity
07.10.2024 13:50+1Да прекратите уже... Что такое "стандартизированная верстка"?
Бутстрап - это рак отрасли)) Он пригоден только для быстрого запуска функционала с дефолтным дизайном. И вот именно для этих целей он вполне себе был бы неплох... Если бы не превратился в очередной комбайн - по объёму матчасти уже наверное сопоставим с освоением css. Ну и любая попытка кастомизации выливается в такое болото... И главная проблема как раз в том, что большинство тех кто его используют, не понимают вот этой основной парадигмы - "вначале запустим по быстрому на бустрапе, а потом дизайн нормальный допилим"... А вот фигушки!))
toxicmt Автор
07.10.2024 13:50+2Не ну можно конечно отрицать все это, но я как предприниматель и разработчик доволен тем, как бутстрап помогает мне решать ряд проблем, ради которых статью и написал.
Spaceoddity
07.10.2024 13:50Да нет. Бутстрап как раз и возник примерно в то же самое время и как раз на основе флексбоксов.
toxicmt Автор
07.10.2024 13:50+1Ну все же он возник сильно раньше, но как только флексы появились, то да, они быстро их туда вобрали
Spaceoddity
07.10.2024 13:50Bootstrap (фреймворк)
Первый выпуск 19 августа 2011
CSS Flexible Box Layout
Year started 23 July 2009
toxicmt Автор
07.10.2024 13:50А ну если формально то да) я больше про возможность реального применения
Spaceoddity
07.10.2024 13:50Ну так из тех же времён в нём, небось, до сих пор осталась поддержка префиксов?
Я уже не помню как работали его первые версии, но чертоги моей памяти подсказывают что там было что-то вроде сугубо служебных блоков
clear: both;чтобы постоянно чистить поток. Получается что в то время, как браузеры уже вовсю поддерживали флексбоксы (пусть и с префиксами), они ещё долгое время юзали float... Ну это же форменная дичь! Жаль он ещё раньше не появился, а то бы табличную вёрстку во всей красе увидели)))Вот это в нём всегда раздражало больше всего - чтобы произвести какие-то манипуляции со стилями, надо было трогать html-разметку... А она, благодаря всем этим служебным блокам, была перегружена и абсолютно нечитаемая...
toxicmt Автор
07.10.2024 13:50+1Это ушло очень много лет назад с выходом bootstrap 4, а щас уже пятерка
dom1n1k
07.10.2024 13:50+4Ну нет. Первые несколько лет флексбокс существовал чисто формально. Во-первых, разные несовместимые друг с другом синтаксисы. Во-вторых, слабая (и местами глючная) браузерная поддержка. А ведь это не скругленные уголки, его не затащишь в прод как "прогрессивное улучшение".
Я отлично помню, что реально в прод флексбокс начал проникать в 2015-2016 году, а закрепился как дефолтный метод верстки не ранее 2018.
Spaceoddity
07.10.2024 13:50Почему вы всё время употребляете "прод"? Типа на тесте всё работало?))
1. ну камон)) ну префиксы же, препроцессоры их до сих прописывают, наверное. плюс хаки - помните такую тему? ;)2. поддержка - полноценно это можно было использовать начиная с IE10, т.е. 2012. В принципе можно было и без поддержки ИЕ - "браузерную войну" они к тому времени слили уже вчистую. Ну или надо было в любом случае определяться с версией ИЕ, которую будем поддерживать. А после релиза ИЕ10 наконец-то можно было не ковыряться с inline-block (глючило не меньше, к слову) или постоянно возиться с float - "а не забыли ли мы поток почистить?". Тут логика была проста - если пользователь не обновляет свой браузер, значит он уже привык к "graceful degradation".
Другое дело, что эта техника в то время действительно была не особо распространена, плюс переучиваться было сложновато - когда привык лэйауты в голове строить на основе float (с инлайн-блоков концептуально переходить было проще, разумеется). Это обычная инерция мышления - с табличной вёрстки тоже далеко не сразу слезли))dom1n1k
07.10.2024 13:50+2Абстрактно это занимательная дискуссия, но в контексте исходной темы – словоблудие.
Библиотека, претендующая на роль индустриального стандарта, не могла себе позволить пренебречь парой-тройкой десятков процентов пользователей с "неправильными" браузерами. Она была обязана использовать пусть не самые передовые, но железно работающие механизмы. Потому что в этом и заключается её смысл:
а) обеспечить максимальную поддержку (UX);
б) упрятать под капот технологические штуки типа clearfix-а, дабы рядовой разработчик о них не думал (DX).P.S. Лично я считаю, что Бутстрап уже несколько лет как неакутален, но блин как же странно и нелепо читать претензии, что он не использовал flex в каких-то лохматых годах! Это точно не входит в топ минусов.
Spaceoddity
07.10.2024 13:50Как вы изящно соскочили с темы - вначале продолжили набрасывать, а теперь это оказывается "словоблудие"))
Какой ещё нафиг "индустриальный стандарт"? В индустрии Бутстрап всегда был синонимом некомпетентности))
Смысл был бы в том, чтобы юзать современные техники компоновки блоков, а для браузеров без поддержки использовать какое-то старое решение. В итоге, как раз в середине 2010-х и сложилась ситуация, когда весь Бутстрап с успехом заменялся одним правилом для флексбоксов. Но это же сложно, да? Проще погрузиться в талмуды документации, чем прочитать про
display:flex... И это именно что главный и жирнющий минус."Лохматые годы" - это "10 лет назад"? Ну ок))
"Технологические штуки" - это чистка потока? Действительно, зачем "рядовому разработчику" о них знать... Пущай потом вся вёрстка начнёт разваливаться на проде, будем в инспекторе протыкивать каждый блок и искать где же там что потерялось...Это не для "рядовых разработчиков", а для случайных людей. Как Тильда (или ещё какое поделие) какое-то время назад...
dom1n1k
07.10.2024 13:50Проблемных браузеров было намного больше: Opera Presto, ранние версии iOS, дохромовый Android... Да даже и в Хроме тогдашнем иногда что-то всплывало.
Помню историю ~2017 года (казалось бы, всё уже наладилось) – заказчик пользовался старым Айфоном, и там флексбокс ломался.
Spaceoddity
07.10.2024 13:50А что не так с Оперой было?))
Ранние версии iOS - это тот же ВебКит что и Хром))Но это всё лирика, я вот к чему веду - и что сейчас с кроссбраузерностью флексбоксов? А если какой-нибудь заказчик до сих пор сидит на ИЕ? Что же делать? А нужно искать здравый компромисс в вопросах кроссбраузерности.
dom1n1k
07.10.2024 13:50Да многое было с Оперой не так. Никакого флексбокса там, естественно, не было. Но главное – непредсказуемые мелкие глюки. В абсолютном количестве их, наверное, было поменьше чем у IE, но у того баги были хорошо исследованы и для большинства известны воркэраунды. Для Оперы ни черта такого не было, дебаг был шаманством чистой воды.
Что касается "здравых компромиссов", то я устал объяснять очевидное — это нормальный подход в рамках конкретного проекта. Там можно ориентироваться на аудиторию, соотносить затраты и профит. Но не в популярной библиотеке – она должна нормально покрывать 99%, потому что иначе она мало кому нужна, если результат как у велосипеда.
den_rad
07.10.2024 13:50+2Бутстрап позволяет мне, как человеку далекому от фронта, сделать какую-то простую страничку, не сильно уходить в CSS.
supercat1337
07.10.2024 13:50В статьях о бутстрапе не хватает разжевывания как создать свою тему (а это есть). Не хватает мнения и опыта дизайнеров и верстальщиков, которые максимально пытались кастомизировать бутстрап под свой дизайн.
Не хватает критики о большой сцепленности внутренних модулей, из-за чего js-бандл получается не маленький, о том, как с этим борются. Не говорят о нюансах при подключении их js-компонентов к своим проектам (например, если не знать определенных правил, то можно несколько раз включить js-код компонентов их либы в свой бандл).
ganqqwerty
Есть важное дополнение - дизайнеры и неравнодушные к внешнему виду члены команды должны осознать, что теперь у нас бутстрап и если в бутстрапе что-то есть, то использовать будем его, а не ваше уникальное.
gun_dose
Это очень распространённое заблуждение. Во-первых, любой компонент бутстрапа очень легко кастомизируется правкой переменных. Во-вторых, совсем не обязательно использовать все компоненты бутстрапа - ненужное там легко отключить. В-третьих, то, что вы написали в большей степени относится к другим фреймворкам, например Material UI или Ant Design, нежели к бутстрап.
Есть конечно дизайнеры, которые нарисуют на сайт 100 кнопок, среди которых не будет даже двух одинаковых, но тут, как говорится, наши полномочия всё.