CSS-фреймворки или CSS-сетка: что мне использовать в моем проекте?

Среди вопросов, которые мне чаще всего задают, есть несколько вариантов вопроса: «Должен ли я использовать CSS Grid или Bootstrap?» В этой статье я рассмотрю этот вопрос. Вы обнаружите, что причины использования фреймворков различны, а не просто связаны с использованием системы сетки, содержащейся в этом фреймворке. Я надеюсь, что, раскрыв эти причины, я смогу помочь вам принять собственное решение с точки зрения того, что лучше всего подходит для сайтов и приложений, над которыми вы работаете, а также для команды, с которой вы работаете.

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

Почему стоит выбрать CSS Framework?

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

Вопрос: если вы решили использовать CSS-фреймворк (Bootstrap, Foundation и т. д.) для своего проекта, каковы были основные причины для этого?

— Рэйчел Эндрю (@rachelandrew) 16 октября 2018 г.

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

Фреймворк дает вашей команде готовую документацию

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

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

Интернет-сообщества: легкий доступ к помощи

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

Сеточная система

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

Скорость реализации проекта

когда уникальный дизайн и эффективный css были гораздо более низким приоритетом, чем срок

— CodingBlocks.net (@CodingBlocks) 16 октября 2018 г.

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

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

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

Я создаю свою собственную «структуру» CSS для всего, что является переделкой существующего крупномасштабного сайта/приложения.

— Бен Бодиен (@bbodien) 16 октября 2018 г.

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

Я не дизайнер!

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

Работа с ошибками CSS и проблемами совместимости браузеров

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

Чтобы помочь с адаптивным дизайном

Отзывчивость веб-страниц. Мне было трудно определить точки останова для веб-страниц.

— Фейсал Али (@f_a_akhtar) 18 октября 2018 г.

Это всплывало несколько раз; люди выбирали фреймворк именно из-за того, что он был адаптивным, или из-за того, что я принимал решения о точках останова за них. Мне показалось интересным, что именно это было чем-то, что было названо фактором при выборе использования фреймворка.

Почему бы не использовать фреймворк?

Среди положительных причин, по которым были выбраны фреймворки, были некоторые проблемы, с которыми люди столкнулись при таком выборе.

Сложность переопределения кода фреймворка

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

Все веб-сайты в конечном итоге выглядят одинаково

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

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

Наследование проблем CSS всего мира

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

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

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

Проблемы с производительностью

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

Увеличение технического долга

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

— Тим Ктулхуэгдон (@nefarioustim) 16 октября 2018 г.

Хотя фреймворк может быть отличным способом быстро запустить ваш стартап, и во время принятия этого решения вы уверены, что замените его, есть ли план, как это сделать?

Изучение фреймворка вместо изучения CSS

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

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

Выбор не учитывает конечных пользователей

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

В нашей гонке за то, чтобы наш сайт был создан быстро, в нашем желании сделать все как можно лучше для себя как дизайнеров и разработчиков сайта, забываем ли мы, для кого мы это делаем? Совпадают ли решения, принятые разработчиком фреймворка, с потребностями пользователей сайта, который вы создаете?

Можем ли мы заменить фреймворки «ванильным» CSS?

Если вы планируете заменить свою структуру или начать новый проект без нее, какие вещи вы могли бы рассмотреть, чтобы упростить этот процесс?

Поймите, какие части фреймворка вам нужны

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

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

Создайте документированную библиотеку узоров или руководство по стилю

Я большой поклонник работы с библиотеками шаблонов, и вы можете прочитать мой пост здесь, в Smashing Magazine, о нашем использовании Fractal. Библиотека шаблонов или руководство по стилю позволяют создавать документацию вместе со всеми вашими компонентами. Все свои проекты я начинаю с работы над CSS в библиотеке шаблонов.

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

Разработайте собственное руководство по коду CSS

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

Куда лучше обратиться за помощью

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

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

Руководства по стилю или отправные точки для недизайнеров

Я запутался в себе такими вопросами, как «Какие шрифты мне следует использовать?», «Насколько большими должны быть заголовки по отношению к основному тексту?», «Можно ли использовать тень?» Я могу легко написать CSS — если я знаю, что я пытаюсь сделать! Что мне действительно нужно, так это какие-то правила для создания неужасного дизайна, какая-то отправная точка типографики или набор основных рекомендаций, которые во многих случаях заменят возможность использовать стандартные настройки фреймворка.

Информирование людей о состоянии совместимости современных браузеров

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

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

Увидим ли мы новое поколение фреймворков?

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

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

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

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

Стоит ли использовать фреймворк?

Вы и ваша команда должны сами ответить на этот вопрос. И, несмотря на то, во что люди могут заставить вас поверить, универсального правильного или неправильного ответа не существует. Есть только то, что правильно или неправильно для вашего проекта. Я надеюсь, что эта статья и множество ответов на мой первоначальный вопрос могут дать вам некоторые темы для обсуждения, когда вы будете размышлять над этим вопросом.

Помните, что ответ будет меняться со временем. Полезным мысленным экспериментом может быть не только рассмотрение того, что вам нужно прямо сейчас, с точки зрения первоначальной разработки сайта, но и рассмотрение срока службы сайта. Вы ожидаете, что это все еще будет примерно через пять лет? Будет ли тогда ваш выбор положительным или отрицательным?

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

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