Pull to refresh

Comments 25

Есть важное дополнение - дизайнеры и неравнодушные к внешнему виду члены команды должны осознать, что теперь у нас бутстрап и если в бутстрапе что-то есть, то использовать будем его, а не ваше уникальное.

Это очень распространённое заблуждение. Во-первых, любой компонент бутстрапа очень легко кастомизируется правкой переменных. Во-вторых, совсем не обязательно использовать все компоненты бутстрапа - ненужное там легко отключить. В-третьих, то, что вы написали в большей степени относится к другим фреймворкам, например Material UI или Ant Design, нежели к бутстрап.

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

bootstrap был удобен когда не было flex и все делалось блоками. А сегодня гриды и разметка намного удобнее делаются нативно с помощью css. Bootstrap может пригодится разве как boilerplate для форм, модалок, слайдшоу и тп.

И получится рукопашная css, со всеми вытекающими. Плюс с "намного удобнее" не соглашусь. Людям, которые этим пользуются (а не создают), удобнее когда есть стандартизированная верстка, а не своя кастомная, которую, кстати, если обобщать, получится что-то типа своего бутстрапа

Да прекратите уже... Что такое "стандартизированная верстка"?

Бутстрап - это рак отрасли)) Он пригоден только для быстрого запуска функционала с дефолтным дизайном. И вот именно для этих целей он вполне себе был бы неплох... Если бы не превратился в очередной комбайн - по объёму матчасти уже наверное сопоставим с освоением css. Ну и любая попытка кастомизации выливается в такое болото... И главная проблема как раз в том, что большинство тех кто его используют, не понимают вот этой основной парадигмы - "вначале запустим по быстрому на бустрапе, а потом дизайн нормальный допилим"... А вот фигушки!))

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

Да нет. Бутстрап как раз и возник примерно в то же самое время и как раз на основе флексбоксов.

Ну все же он возник сильно раньше, но как только флексы появились, то да, они быстро их туда вобрали

А ну если формально то да) я больше про возможность реального применения

Ну так из тех же времён в нём, небось, до сих пор осталась поддержка префиксов?

Я уже не помню как работали его первые версии, но чертоги моей памяти подсказывают что там было что-то вроде сугубо служебных блоков clear: both; чтобы постоянно чистить поток. Получается что в то время, как браузеры уже вовсю поддерживали флексбоксы (пусть и с префиксами), они ещё долгое время юзали float... Ну это же форменная дичь! Жаль он ещё раньше не появился, а то бы табличную вёрстку во всей красе увидели)))

Вот это в нём всегда раздражало больше всего - чтобы произвести какие-то манипуляции со стилями, надо было трогать html-разметку... А она, благодаря всем этим служебным блокам, была перегружена и абсолютно нечитаемая...

Это ушло очень много лет назад с выходом bootstrap 4, а щас уже пятерка

Ну нет. Первые несколько лет флексбокс существовал чисто формально. Во-первых, разные несовместимые друг с другом синтаксисы. Во-вторых, слабая (и местами глючная) браузерная поддержка. А ведь это не скругленные уголки, его не затащишь в прод как "прогрессивное улучшение".

Я отлично помню, что реально в прод флексбокс начал проникать в 2015-2016 году, а закрепился как дефолтный метод верстки не ранее 2018.

Почему вы всё время употребляете "прод"? Типа на тесте всё работало?))
1. ну камон)) ну префиксы же, препроцессоры их до сих прописывают, наверное. плюс хаки - помните такую тему? ;)

2. поддержка - полноценно это можно было использовать начиная с IE10, т.е. 2012. В принципе можно было и без поддержки ИЕ - "браузерную войну" они к тому времени слили уже вчистую. Ну или надо было в любом случае определяться с версией ИЕ, которую будем поддерживать. А после релиза ИЕ10 наконец-то можно было не ковыряться с inline-block (глючило не меньше, к слову) или постоянно возиться с float - "а не забыли ли мы поток почистить?". Тут логика была проста - если пользователь не обновляет свой браузер, значит он уже привык к "graceful degradation".
Другое дело, что эта техника в то время действительно была не особо распространена, плюс переучиваться было сложновато - когда привык лэйауты в голове строить на основе float (с инлайн-блоков концептуально переходить было проще, разумеется). Это обычная инерция мышления - с табличной вёрстки тоже далеко не сразу слезли))

Абстрактно это занимательная дискуссия, но в контексте исходной темы – словоблудие.

Библиотека, претендующая на роль индустриального стандарта, не могла себе позволить пренебречь парой-тройкой десятков процентов пользователей с "неправильными" браузерами. Она была обязана использовать пусть не самые передовые, но железно работающие механизмы. Потому что в этом и заключается её смысл:
а) обеспечить максимальную поддержку (UX);
б) упрятать под капот технологические штуки типа clearfix-а, дабы рядовой разработчик о них не думал (DX).

P.S. Лично я считаю, что Бутстрап уже несколько лет как неакутален, но блин как же странно и нелепо читать претензии, что он не использовал flex в каких-то лохматых годах! Это точно не входит в топ минусов.

Как вы изящно соскочили с темы - вначале продолжили набрасывать, а теперь это оказывается "словоблудие"))

Какой ещё нафиг "индустриальный стандарт"? В индустрии Бутстрап всегда был синонимом некомпетентности))

Смысл был бы в том, чтобы юзать современные техники компоновки блоков, а для браузеров без поддержки использовать какое-то старое решение. В итоге, как раз в середине 2010-х и сложилась ситуация, когда весь Бутстрап с успехом заменялся одним правилом для флексбоксов. Но это же сложно, да? Проще погрузиться в талмуды документации, чем прочитать про display:flex... И это именно что главный и жирнющий минус.

"Лохматые годы" - это "10 лет назад"? Ну ок))
"Технологические штуки" - это чистка потока? Действительно, зачем "рядовому разработчику" о них знать... Пущай потом вся вёрстка начнёт разваливаться на проде, будем в инспекторе протыкивать каждый блок и искать где же там что потерялось...

Это не для "рядовых разработчиков", а для случайных людей. Как Тильда (или ещё какое поделие) какое-то время назад...

То есть они должны были поддерживать 2 параллельные раскладки вместо одной? Учитывая дополнительно, что директива @supportsтогда ещё не работала. Отличный план.

Зато вполне успешно работали условные комментарии для ИЕ.

Проблемных браузеров было намного больше: Opera Presto, ранние версии iOS, дохромовый Android... Да даже и в Хроме тогдашнем иногда что-то всплывало.

Помню историю ~2017 года (казалось бы, всё уже наладилось) – заказчик пользовался старым Айфоном, и там флексбокс ломался.

А что не так с Оперой было?))
Ранние версии iOS - это тот же ВебКит что и Хром))

Но это всё лирика, я вот к чему веду - и что сейчас с кроссбраузерностью флексбоксов? А если какой-нибудь заказчик до сих пор сидит на ИЕ? Что же делать? А нужно искать здравый компромисс в вопросах кроссбраузерности.

Да многое было с Оперой не так. Никакого флексбокса там, естественно, не было. Но главное – непредсказуемые мелкие глюки. В абсолютном количестве их, наверное, было поменьше чем у IE, но у того баги были хорошо исследованы и для большинства известны воркэраунды. Для Оперы ни черта такого не было, дебаг был шаманством чистой воды.

Что касается "здравых компромиссов", то я устал объяснять очевидное — это нормальный подход в рамках конкретного проекта. Там можно ориентироваться на аудиторию, соотносить затраты и профит. Но не в популярной библиотеке – она должна нормально покрывать 99%, потому что иначе она мало кому нужна, если результат как у велосипеда.

Ясно-понятно)) Опера строже всех соблюдала стандарты спецификаций W3C. А ещё первая прошла Acid2 на сотню.

Просто напомню, что Престо например не умел в дробные проценты. То есть если написать width: 33.3%, он молча отбрасывал дробную часть. Но этот баг был хотя бы стабилен и известен. А сколько было нестабильных... После этого мне не особо интересно слушать про стандарты и асид.

Бутстрап позволяет мне, как человеку далекому от фронта, сделать какую-то простую страничку, не сильно уходить в CSS.

В статьях о бутстрапе не хватает разжевывания как создать свою тему (а это есть). Не хватает мнения и опыта дизайнеров и верстальщиков, которые максимально пытались кастомизировать бутстрап под свой дизайн.

Не хватает критики о большой сцепленности внутренних модулей, из-за чего js-бандл получается не маленький, о том, как с этим борются. Не говорят о нюансах при подключении их js-компонентов к своим проектам (например, если не знать определенных правил, то можно несколько раз включить js-код компонентов их либы в свой бандл).

Sign up to leave a comment.

Articles