Tailwind CSS — это CSS-фреймворк с набором инструментов, подробно описанный во многих статьях в Интернете. Эта статья не является репетицией официального документа и не является перечислением преимуществ серии.Автор Жерар укажет на некоторые проблемы Tailwind CSS с другой точки зрения, исходя из фактического сценария разработки, исходя из того, что пытается оставаться цель. На самом деле, помимо упомянутого в статье, у Tailwind CSS еще много недостатков, таких как недостаточная поддержка высокой кастомизации и умственная нагрузка по запоминанию большого количества предопределенных имен классов.
Дружеское напоминание: вы не обязательно согласны с мнением этой статьи., в конце концов, на наши взгляды всегда будут влиять наши собственные познания и опыт, но более важным может быть отношение автора к появляющимся технологиям, в его оригинальных словах: "Когда все кричат, что это круто, обычно это хороший момент, чтобы посидеть вниз и хорошенько взгляните на него»
Начинается следующий текст.
- Оригинальный адрес:Tailwind CSS Is (Probably) Overhyped
- Оригинальный автор:Gerard van der Put
- Переводчик: Чор
введение
В течение последних двух лет,Tailwind CSS популярный(С 30 000 загрузок в неделю до 600 000 сегодня). Нет никаких сомнений в том, что этот популярный CSS-фреймворк, ориентированный на полезность, имеет много преимуществ. Скорее всего, вы уже слышали о том, насколько он удивительный и мощный, потому что именно так думают многие разработчики.
Но нам еще есть что сказать об этом фреймворке.
Что такое Tailwind CSS?
Если вы никогда не видели Tailwind в действии, посмотрите это:
<div class="bg-gray-100 rounded-xl p-8">Hello World</div>
Имя класса здесь отражает определение Tailwind: набор предопределенных классов (так называемых служебных классов). Вам не нужно писать базовые правила стиля CSS, просто применяйте предопределенные имена классов непосредственно в HTML.
Таких имен классов гораздо больше. В следующем списке показаны некоторые категории и соответствующие примеры:
-
задний план (
bg-gray-200,bg-gradient-to-bl) -
Гибкая компоновка (
flex-1,flex-row) -
Макет сетки (
grid-cols-1,col-span-4) -
набивка (
p-0,p-1) -
размер (
w-1,h-1)
Кто-то ранее сравнил этот набор предопределенных классов с «кирпичиками Lego», которые можно использовать в коде. Конечно, он во многом совпадает с традиционным CSS, но на этом не останавливается: он также включает предопределенные области видимости (bg-red-100, bg-red-200Ждать). Tailwind создан для того, чтобы сделать нашу разработку более эффективной, и в некотором смысле так оно и есть.
В то же время мне очень нравится название: Tailwind. Когда у меня будет свободное время, я выйду в море на лодке, и ветер — это хорошо.
грамматика
Как показано выше, мы записываем имя класса инструмента непосредственно в HTML. Мы быстро подумаем, что это очень похоже на встроенный CSS, что может объяснить, почему разработчики TailwindДокументацияЭта проблема упоминается в начале .
Хоть и пытаются объяснить, что у Tailwind есть свои недостатки (я не отрицаю, что у него много достоинств), я все равно не согласен с его синтаксисом. Я не хочу загрязнять каждый элемент в моей HTML-структуре кучей имен классов, и я не хочу каждый день сталкиваться с таким кодом:
Примечание. Приведенный выше код взят из документации Tailwind, и он отображает простую карту. На самом деле, он оказался настолько красивым, что даже стал отзывчивым. Но если посмотреть на нашу повседневную разработку, то ситуация быстро ухудшается: а вдруг я разрабатываю компонент посложнее карты? Что, если бы мне пришлось следовать определенному дизайнерскому стилю, предложенному дизайнером, и смириться с некоторыми его «причудами»?
Я попытался справиться с этой ситуацией, и получилось так, как и ожидалось — каждый элемент HTML был заполнен кучей имен классов инструментов Tailwind. Официальная документация и обучающие видео не расскажут вам об этом, но это реальный вопрос, который встает перед нами, когда мы начинаем разрабатывать масштабные приложения:
// 一大堆类名
<div class="sm:w-4 md:w-6 lg:w-10 xl:w-full sm:text-sm md:text-base lg:text-base xl:text-2xl flex-1 sm:flex-none bg-black sm:bg-white rounded-md sm:rounded-none">Hello World</div>
Это неизбежно и в реальном развитии.
Приведенный выше пример не является преувеличением, я бы даже сказал, что это максимально упрощенный пример — по крайней мере, для тех приложений с четкими требованиями и понятным стилем дизайна (отзывчивые изменения и корректировки стиля с учетом разных размеров экрана) он такой.
Так как же организовать эти имена классов? Может быть, мы собираемся создать и следовать какой-то сортировке, но это слишком сложно. Другой подход заключается в том, чтобы разрешить дизайнерам и разработчикам шаблонов использовать любой определенный порядок, но таким образом, чтобы найти имя целевого класса для изменения. Нам пришлось бы смотреть по горизонтали или даже прокручивать, чтобы увидеть код.
Я не хочу искать размер шрифта элемента, как я делал для Вилли.(Примечание переводчика: Вилли — персонаж детской книги «Где Вилли», читатели должны найти Вилли на картинке толпы людей)
Я хочу сказать, что некоторые элементы HTML используют много стилей, в этом случае вам следует рассмотреть возможность отделения стилей от тегов HTML и помещения их в отдельный файл. Таким образом, мы можем организовать стили и улучшить их читабельность. Вы не сможете втиснуть всю мощь CSS вclassВ этом атрибуте HTML-тега Tailwind тоже не может. Это только сделает структуру HTML более раздутой.
@apply
В ответ на упомянутые выше проблемы Tailwind позволяет нам использовать имена их классов в одном файле CSS:
.header {
@apply bg-red-200 w-4 text-gray-400 rounded-sm border-red-400 border-2;
}
Но я не вижу никаких преимуществ перед традиционным способом написания CSS (или других препроцессоров, таких как SASS). Вы могли бы сказать, что я «старомоден», но я предпочитаю следующий способ написания:
.header {
background-color: #FECACA;
width: 200px;
color: #444;
border-radius: 5px;
border: 2px solid #F87171;
}
Опять же, в реальной разработке к элементам может применяться множество стилей.
Я не уклоняюсь от преимуществ Tailwind, и некоторые из предоставляемых им инструментов должны быть более полезными для изучения. Но когда дело доходит до синтаксиса, я все еще хочу четкого разделения языка разметки (HTML) и правил стиля. Думаю, это субъективное мнение.
очистить мертвый код
После внедрения Tailwind в проект доступны все названия классов. Но при сборке и упаковке проекта нам, очевидно, не нужно использовать все имена классов. Поэтому Tailwind использует инструмент PurgeCSS:
Здесь в игру вступает PurgeCSS. PurgeCSS проанализирует ваш контент и файлы css, сначала сопоставит селекторы, используемые в файле css, с селекторами в файле содержимого, затем удалит неиспользуемые селекторы из css, в результате чего файл css станет меньше.
Кратко резюмируем: сначала вводим в проект большое количество имен классов инструментов, затем при подготовке к сборке и выпуску проекта используем инструмент для сканирования кода и поиска всех неиспользуемых имен классов, чтобы убедиться, что они не меняются с другим кодом. Упакуйте вместе. Его реализация основана на следующем регулярном выражении:
Внедрение и использование Tailwind добавит уровень сложности нашему проекту, а сложность сопряжена с определенным риском и создаст проблемы для нашей разработки. Например:
render(
myItems.map(item => (
<div className={`item level-${item.level}`}>
{item.text}
</div>
));
);
Невозможно динамически генерировать имена классов, подобные этому. Это означает, что Tailwind накладывает ограничения на наше развитие. об этом моменте,ДокументацияТакже упоминаются, но легко упускаются из виду разработчиками:
Операции конкатенации строк не допускаются.
Ограничения разработки — это одно, но есть и другая проблема: добавление уровня сложности к проекту часто создает риск для проекта.
В конечном итоге это становится вопросом суждения, делает ли Tailwind больше хорошего, чем плохого? У разных проектов разные ответы на этот вопрос, но мы должны хотя бы знать о его проблемах. Что касается ограничений, связанных с Tailwind, упомянутые выше проблемы — это лишь верхушка айсберга. Другим примером может быть добавление дополнительного (настраиваемого) CSS в проект Tailwind.не так просто.
альтернативы
После прочтения документации Tailwind и начала разработки в течение нескольких дней я не мог не думать: автор не понимает, что большинство из нас уже используют другие инструменты в нашей повседневной разработке для упрощения написания стилей.
В документации говорится, что одним из преимуществ использования Tailwind является отсутствие магических чисел. Действительно, это одно из его преимуществ: мы определяемbg-red-200Затем служебный класс color можно использовать везде в коде и изменять его фактическое значение в одном месте (файл конфигурации Tailwind). Он все еще довольно ароматный, и я уверен, что вы согласны с этим.
Но современные инструменты, такие какSASS(более 5 миллионов загрузок в неделю), служебные классы и переменные уже давно легко создавать и повторно использовать в коде. Даже нативный CSS уже поддерживает использование переменных.
Когда мы используем SASS или собственный CSS, нам не нужно сталкиваться с дополнительным уровнем сложности, а также нам не нужно менять устоявшиеся привычки и синтаксис при написании правил стиля CSS.
Использование Tailwind платно. Потратьте время и усилия на изучение синтаксиса и имен классов Tailwind, и вы постепенно забудете лежащий в его основе синтаксис: синтаксис родного CSS. Если мои разработчики будут использовать Tailwind в течение года в более крупном проекте, они постепенно забудут о нативном CSS. Действительно ли такое положение вещей оптимистично? Я не уверен.
пост-заказ
Tailwind популярен, и его привлекательность и количество подписчиков растет день ото дня. Я могу понять, почему, потому что его использование действительно может принести нам большую пользу. Я также признаю его преимущества, некоторые из его инструментов могут сыграть большую роль.
Моя цель в написании этой статьи — показать вам тот факт, что у истории всегда есть две стороны.
Некоторые люди выиграют от этого фреймворка, но некоторые люди будут ограничены, они продолжат обнаруживать эти ограничения в процессе разработки — или, что еще хуже, они обнаружили после разработки.
Пожалуйста, сохраняйте свою критичность, пока вы адаптируетесь к новой структуре. Когда «все» восклицают о своем удивлении, самое время сесть и присмотреться.
Спасибо, что нашли время прочитать эту статью!