Комментарии 81
Лично я рад появлению этой технологии, а что думаете вы?
В мусорку такое. Даже близко не лучше чем SCSS + CSS Modules.
Думаю, данное решение будет полезно на больших проектах, при построении сложных дизайн-систем, которыми пользуются множество команд.
И чем же это лучше чем классика в виде SCSS + CSS Modules?
А чем ваша "классика" лучше ванильного CSS?))
Вложенными селекторами.
Ну кто-то ещё циклы фигачит, но это баловство.
Остальное нафиг не нужно, ага. Но то что в статье - лютая дичь какая-то :)
Вложенными селекторами.
https://developer.mozilla.org/ru/docs/Web/CSS/Descendant_combinator
Для меня SCSS начисто умер после того, как столкнулся с таким (довольно распространённым) стилем написания кода:
.class{
.some-class{
...
div{
span{
a
}
}
}
}А мне понадобилось поменять цветовую схему. И оказалось, что в scss в принципе нет способа не копипастить вот эту лесенку))
Ну это же дичь дикая! И повсеместно встречаемая...
Цветовые темы меняются через CSS переменные, а не дубляжом всего кода
Ну и вы всегда можете написать в одну строчку доступ к самому внутреннему селектору.
Цветовые темы меняются через CSS переменные, а не дубляжом всего кода
Спасибо, я в курсе что и как делать. Я вам рассказываю про данность - надо поменять отдельные свойства. Копаться с рефакторингом подобного говнокода с выносом в переменные - без меня пожалуйста))
Самое главное - где быстрый доступ к длинному контекстному селектору? А нету его!
//
Конкретно здесь хз зачем так сделано. Вообще это делает примерно так:
.item {
.title {}
.body {}
.date {}
.another {
.child1 {}
.child2 {}
}
}Получается гораздо удобнее. У вас как бы один элемент и вы его стилизуете, включая потомков. Не нужно каждый раз переписывать цепочку .item .another .child1 {}
Извините, мы в разной парадигме мыслим)) БЭМ мне всё-таки зашёл, поэтому:
.item{}
.item__title{}
.item-body{}
.item__date{}
.item-another{}
.item-another__child{}
.item-anoter__child_1{}
.item-anoter__child_2{}Как-то так... Многие свойства (и даже правила), разумеется, можно опустить, поскольку наследование.
У вас видимо в коде все селекторы внутри пустые, добавить по 4-5 строчек в каждые скобки и от красоты не останется следа
Причём здесь красота? Дело в удобстве))
А удобство извините меня в чем? Дублирование названий класса? Отсутствие иерархии? Назовите преимущества этого подхода
Ну тут как бы вся соль в сути именования классов)) Где надо - там дублируется. Где не надо - нет))
Иерархия тут не просто есть, а очень мощная на самом деле ;) Можно привязываться как к структуре, там и к универсальным классам, глобальным.
Ну и вы как-то абстрактно набрасываете - приведите контрпример.
.item {
&__title {}
&__date {}
}
.item-body {}
.item-another {
&__child {}
&__child_1 {}
&__child_2 {}
}А вот такое чем вас не устраивает? и БЭМ, и вложенность, и прочие плюшки
Что в свою очередь разворачивается в:
.item {
&__title {}
&-body {}
&__date {}
&-another {
&__child {
&_1 {}
&_2 {}
}
}
}Зачем разворачивается?
Зачем мне вот эта лишняя привязка к структуре кода?)) Бритва Оккама, знаете ли. А ещё обычно как пойдёт ряд псевдоклассов и псевдоэлементов - в этой лапше не так-то и просто с ходу разобраться будет.
Думаю это дело привычки. Ориентироваться в иерархии в любом случае в варианте от SCSS попроще будет.
Всё это с лихвой перекрывают такие "сюрпризы", как:
И да, я знаю как это фиксить, но с "ванильным CSS" у вас подобные проблемы в принципе не всплывут!
Чем это проще???
Вы типа префикс заменяете переменной? Я не машина - мне комфортнее сразу видеть полное именование (в моём коде обычно единственного) класса. Я сразу могу сопоставить это именование с html-кодом (не структурой!). У меня вся необходимая иерархия сразу прописана в именовании класса. А "лесенки из табов" я точно так же могу фигачить - только как-то потребности не возникало до сих пор. Это первый шажок к потере "независимости и переиспользования".
У меня есть ощущение, что HTML и CSS считаются слишком сложными, поэтому вместо них имеем JSX и множество CSS библиотек. В этой статье как плюс, например, преподносится отсутствие каскадности: не нужно учить приоритеты селекторов.
Для тех, кто знает HTML+CSS все эти поделки выглядят как попытка решить проблему, которой нет.
Напомни пожалуйста, какой стейт менеджер самый лучший?)
И не мог бы ещё написать хоть одно достоинство scss перед современным css?
Напомни пожалуйста, какой стейт менеджер самый лучший?)
Из тех что написано кем-то, то MobX разумеется. А я щас использую самописный аналог, по сути тот же MobX, но только computed реализован полноценно.
И не мог бы ещё написать хоть одно достоинство scss перед современным css?
Ну например из того что прям используется на постоянной оcнове:
1) Вложенность, всё что относится к классу находится внутри описания класса. Более читаемо и логично.
.test {
color: #eee;
display: flex;
@include respond-to-mobile {
flex-direction: column;
}
&:hover {
color: #fff;
}
&:active {
color: red;
}
.nested {
font-size: 20px;
}
}против
.test {
color: #eee;
display: flex;
}
@media all and (max-width: 767px) {
flex-direction: column;
}
.test:hover {
color: #fff;
}
.test:active {
color: #fff;
}
.test .nested {
color: #eee;
}2) Миксины, меньше рутины, код чище и приятнее.
.test {
@include typography('Heading/Heading 3', 'Primary/purple'); // Скопировать из Figma
}
/* превращается в */
.test {
font-family: Roboto, sans-serif;
font-size: 20px;
font-style: normal;
font-weight: 700;
line-height: 28px;
color: #741CFD;
}
.test {
@include text-ellipsis();
}
/* превращается в */
.test {
white-space: nowrap;
overflow: hidden;
text-overflow: ellipsis;
max-width: 100%;
}
Из тех что написано кем-то, то MobX разумеется. А я щас использую самописный аналог, по сути тот же MobX, но только computed реализован полноценно.
Очень интересно глянуть пример чем он существенно отличается от MobX
Более читаемо и логично.
Нет. Ну или по крайней мере дело вкуса.
Смотрите - на примере вашего кода:
лично я все медиазапросы группирую и отправляю в отдельную секцию. вёрстка под десктоп и мобилы - это все-таки 2 разных задачи. вначале пишешь под одно, потом добавляешь стили под другое. и рыскать по портянке кода в поисках конкретного медиазапроса - ну совсем не оптимально.
отмените-ка мне ховер для мобилки (он там без нужды зачастую) - хоп, и вот вы начали плодить медиазапросы...
вложенные классы - ну совсем уж зло! потом приспичит поменять .nested, а специфичность не позволяет - переписывай всю портянку селекторов))
миксины - я-то и кол-во переменных стараюсь минимизировать, иначе их просто не удержишь в голове - в итоге или надо постоянно открытым держать файл с их определением или дублировать код)) для таких вещей проще глобальный класс text-ellipsis прописать))
И как это называть?
Мало того, что мы под гнётом бесконечных звёздочек, пропихивает ещё одно усложнение жизни в виде непонятно зачем появившегося фреймворка, который в очередной раз заменит СSS (нет), там мы ещё делаем это в виде статьи, которая читается за две минуты.
Это примерно как подойти к автомобилисту и сказать:
Вы водите автомашин. Но говорить с вами я буду о 2020 Bimota Tesi H2. Это такой новый дизайн байков. У них передняя вилка не крепится напрямую к рулю. Ну так вот, такой подход - это круто. Покупайте 2020 Bimota Tesi H2.
Причём, вы не даёте никаких вводных данных. Автомобилист туго разбирается в мотоциклах. И знает только Харлей и Ямаху, и то, только потому что ему парочка подворачивалась в виде тонко размазаного паштета на дороге. Он вообще знать не знает об экслюзивных итальянских Бимотах, которые строятся на заказ.
Может быть ему и было бы интересно посмотреть на эту Бимоту. Но проблема в том, что вы вообще нифига о них не рассказываете.
Зачем мне нужно перегружать уже перегретый Webpack ещё одним плагином? Он и так уже тужится по пять минут, уминая в кучу весь тот ужас последних лет разработки. Мы сначала используем BeautifyJS для разработки, для того, чтобы запихнуть его в UglifyJS для ещё какой-то доработки, прежде чем это всё попадёт по конвееру на ещё какой-то парсер. Люди уже не помнят, как писать CSS, потому что везде есть SASS. Но и этого им мало, давайте запихнём то, что изначально было отдельным компонентом по определённым причинам в код.
Нахрена? Ну, как же! Нам не надо будет бояться клэша названий классов. У нас же этих классов - миллион с хвостиком, их наплодило какое-то самообразование кода в пятьсот пятой строчке конфигурации вэбпака. Или реакта. Или CRA. Никто уже не помнит, но почему-то у нас на каждую кнопку вешается по 16 стилей. А давайте ещё сверху поставим компонент, который разработала компания с одним из самых сложных и запутанных программных продуктов в мире, которая пытается хоть как-то уладить ужасы абсолютно несовместимых интерфейсов и фреймворков, которые они-же сами наплодили.
А давайте теперь поговорим о дебаге всего этого и того, как мы улаживаем очередную source-map. Что? Вас уже тошнит от того, что последний элемент в гриде на этом размере экрана для андроида вылезает за пределы бокса? Вы не можете ничего изменить, без полного ре-билда кода? Ну что же, мы тут не занимаемся анти-рвотными вещами. Мы как раз наоборот.
Господи. Вы - не Фейсбук. У вас нет миллиона программистов, которые выдают на гора мегабайты кода каждый день. Вам не надо поддерживать уникальную инфраструктуру кода и приложений. Вам не надо выдумывать как обходить легальные ограничения разных стран. Вам не надо бороться с тем, что к вам заливают фотки терабайтами. Вам не нужны инструменты, которые были разработаны для обслуживания монстров!
Большинство современных программных продуктов можно поддерживать с помощью двух CSS файлов. Самых обычных CSS файлов. Без надстроек и плагинов. Их можно даже подключать через HTML head. И можно даже не умереть без минификации всего этого.
Самое прикольное - во всё это отлично и просто средствами самого CSS вставляется самая простая, но тем не менее отлично работающая система, поддерживающая разрые темы, в зависимости от настроек браузера. (То, что в Бутстрапе реашется только извращениями). А если вам лень написать простейший CSS-reset, то можно заставить ГПТ это сделать. Если уж слишком вам не жить без grid-layout то можно просто скачать один из пяти тысяч пятикилобайтных фреймворков, которые позволяют вам писать стили.
Дизайнеры всё-равно будут переписывать стили вашего приложения. Вам не нужна вся база Бутстрапа.
Господи, да откройте вы просто блокнот и напишите в нём
body {
padding: 0px;
margin: 0px;
}Зацените, не надо ни то, что компилировать, даже минифицировать не надо.
Да сходите же, наконец-то на давно забытый https://csszengarden.com/pages/alldesigns/. Там всё ещё показывают как CSS работает без всех этих надстроек.
Которые, конечно же влекут за собой дикие усложнения тестирования и дебага. Но об этом мы поговорим в другой раз. Потому что мы щас пока пишем фреймворк для фреймворка, чтобы он нам всё дебажил.
Кстати. Ещё одна вещь.
Ваша статья без большого куска скопипащщенго кода.
Мой коммент к вашей статье:
Просто банально показать, что вы даже пальцем не повели, чтобы постраться написать что-то. Более того, приглашение подареное НЛО, и купленный аккантв с одной только полу-дохлой публикацией.
Как говорилось в старом недобром анекдоте:
Вась, мы работаем в приличной компании, у нас толчки на каждом этаже. Нафига ты это пихаешь в сорц-контроль?
О господи, адекватный человек на фронтэнде. Ловите его!
Просто снимаю шляпу перед автором этого комментария
Полностью с вами согласен! Более того, css сам по себе прекрасно развивается, если бы нативно ещё разрешили писать через вложеные селекторы как в препроцессорах. То можно и от них было бы отказаться. Ещё лет 5 назад сколько нн пытался использовать функционал того же scss, в результате он только перегружал и мешал быстрому погружению. А православный БЭМ уже давно решил все проблемы с дальнейшим саппортом.
Или вот если взять тот же тейлвинд, попался мне уже готовый проект, и разбираюсь в коде хотелось волосы рвать на голове. Я сделал вывод, что ребята придумаышие тейлвинд, решили переизобрести атрибут style на стероидах от которого все старались отказаться в начале 10х годов, и считалось дурным тоном его использование. А теперь ФБ решил выкатить вот это недоразумение.
Предсказуемость – приоритизация селекторов в StyleX очень проста – всегда побеждает последний заданный стиль. Это значит, что можно забыть про каскадность.
Почему писатели подобных либ постоянно норовят откреститься от одной из главных "фишек" CSS - каскада? Они реально не понимают как это работает?))
Почему в цитируемом абзаце понятие "каскада" путается со "специфичностью"?
Идём дальше:
При навигации по сайту модули подгружались в разном порядке, что порождало различные казусы с приоритизацией стилей.
Могу себе в теории представить такую ситуацию (не смотря на дикую популярность изолированных стилей в последнее время). Но опять-таки, авторы не имеют понятия о специфичности в css? О том, как на ванильном CSS решить эту проблему одним щелчком пальцев?
И сравнивая этот тезис с первой цитатой:
всегда побеждает последний заданный стиль -> модули подгружались в разном порядке
Сдаётся мне, проблема только усугубилась))
Комбинируемость – объекты стилей можно экспортировать и передавать в компоненты. При этом стили всегда будут вести себя предсказуемо.
Какой-то высокопарный тезис, высосанный из пальца. А потенциально какую "непредсказуемость" можно ожидать? Модули будут подгружаться в разном порядке?))
Типизация – каждое css-свойство и переменная полностью типизированы, а мы можем использовать TypeScript или Flow, чтобы определить стили, передаваемые в компонент.
А в чём вообще нужда типизировать CSS-свойства? Браузер и так в курсе разрешенных значений для этих свойств))
Все в одном месте – библиотека поощряет определение стилей в том же файле, что и компонента.
"Поощряет" = данность?
Короче, понаплели, видать, там какой-то адовой лапши из CSS и JS и чтобы теперь разгрести эти авгиевы конюшни, пишут очередное "инвалидное кресло"...
Более того, в css тоже последний стиль иметь бОльший приоритет)
Не совсем так, ведь есть так называемая «специфичность», и обращение в css через 11 вложенных классов перебьет обращение по id.
Но это надо очень сильно постараться (читать как «наверти**ячить»), чтобы встретить такой кейс в реальной разработке.
Ну да, я имел в виду, при прочих равных
Не совсем так, ведь специфичность не работает по принципу десятичных разрядов))
UPD: Понимание этого аспекта, на самом деле, частенько имеет практическое применение - лишний класс всегда перебьёт сколько угодно длинную цепочку селекторов по тэгам.
Вы правы в том, что здесь не используется принцип десятичных разрядов. Однако другая разрядность всё же присутствует: https://habr.com/ru/articles/149791/
Никаких других "разрядностей" нет. Был баг в браузерной реализации, который исправлен. По оригинальной ссылке можно самостоятельно проверить https://codepen.io/chriscoyier/pen/DKKmWE
Ну это просто баг. Точно так же лично я столкнулся с ограничениями для order как int32 - мне однажды показалась изящной идея осуществлять сортировку элементов по дате на голом css, путём привязки order к unix time stamp))
Модули будут подгружаться в разном порядке?))
Именно так. На каждый компонент реакта, свой css файл. Когда запускается приложение, компонент вставляет свои стили в порядке исполнения дерева реакта. Получается, что если сначала открыть страницу а, а потом страницу б, то страница а может теоретически влиять на страницу б.
Да это именно понаделали, какой-то адовой лапши и страдают. Делают чтобы решить проблемы, что сделали где-то раньше.
Я плохо разбираюсь в реакте и давно на нем не писал, но у меня сильное ощущение что это уже было, стили я уже таким образом писал, и удовольствие было ниже среднего.
Фейсбуку очень надо как-то сделать ограничение области видимости (scope) CSS на один файл/компонент. Самые элегантное и эффективное решения для этого у Vue, через html атрибуты. Фейсбук не может взять это, ему надо придумать что-то свое, в итоге выходит вот это CSS-in-JS + HTML-in-JS.
Что может выйти из рук людей, который грузили десятки мегабайт CSS для своего сайта?
scoped в vue это не самое элегантное решение. Все вычисление переносится в рантайм, из-за чего увеличиваются html и css файлы
Самое лучшее решение без сайд-эффектов для рантайма это уникальные айдишники вместо читаемых классов. Но за это платится менее выразительным дебагом.
Всем привет, пишу на чистом css, просто разделяя css по страницам сайта и имея один файл общих стилей. Также отдельные файлы стилей плагинов. Ну и отдельный файл адаптива.
Пока верстка получается быстрее всех фреймворков..
Никак не могу отказаться от такой свободы. Пока люди думают, как изящно допилить очередной фреймворк, я думаю, как сверстать следующий макет =)
А еще я пишу на jQuery. И, что удивительно - все работает. Уверен, что модные фреймворки будут быстрее. Но я не пишу крипто биржы =(
Для каждой задачи свой инструмент. Для очень многих вещей до сих пор хватает jQuery и файла стилей. Но для сложных задач фреймворки на фронте (да и на бэке конечно же) сильно выручают. Простой пример, на прошлой работе я писал (в команде) календарь заказов-событий для сети автомастерских. Если бы обновлять эту ленту, отслеживать события и сотни элементов с помощью jQuery - это был бы ад. А Vue - вообще никаких проблем.
Иными словами далеко не всегда модные фреймворки - это лишняя сложность, при правильном применении они действительно облегчают разработку.
Приведу контрпример о вреде зоопарка фреймворков. Работал в министерстве. Собственные проекты делали на Symfony(PHP) + React и штат программистов нанимали под этот стек. Но в министерство часто приходили на доработку и сопровождение проекты с других ведомств. Чего там только не было - и node, и kotlin, и python - кто во что горазд. Даже если язык совпадал, то фреймворки всегда были разные. И всё это разнообразие часто доставалось мне.
Что делать в этом случае? Держать зоопарк программистов под каждый фреймворк? Изучать каждый раз новый фреймворк ради каждого нового проекта?
В последнем проекте (сайт федерального министерства) был самописный движок на основе экзотического Livestreet в беке и Vue во фронте. Бэк я освоил, потратив кучу времени. А под Vue так никого и не нашлось среди наших фронтов, которых нанимали на react. А самим изучать дополнительный фреймворк ради очередного проекта просто не было времени, и без того задач хватало.
Такое обилие фреймворков часто вредит. Программистам трудно найти работу под свой стек, а работодателям - программистов под свой.
Такое обилие фреймворков часто вредит.
Ваша история об этом не свидетельствует. Правительство должно было либо нанять компанию, либо своим отделом выбрать технологии, с которыми работать. Они же не покупают автомобили самых разных марок, у них есть общая линия, чтобы было проще с ремонтом. Не ставят самые разные операционные системы. Здесь также . Это их недоработка.
Их я не оправдываю, я оттуда и уволился не в последнюю очередь из-за повальной некомпетентности руководства.
У нас то в отделе как раз и был стандарт - Symfony+React. Но проекты к нам часто попадали из разных организаций, в том числе неподконтрольных министерству. Какой уж там единый стандарт.
Все таки отрасль крайне фрагментирована, огромное количество фреймворков и это часто вредит.
Если не нравится пример с министерством, то легко представить фрилансера, отказывающегося от проекта на чуждом стеке или соискателя, отказывающегося от вакансии с незнакомым фреймворком.
А как вы собираетесь регулировать количество фреймворков и кто из них выживет? Их ведь на том же фронте на самом деле во много раз больше известной "тройки". Вы хотите Реакт с диктующим все правила типа StyleХ Фейсбуком?
Пример с вашим фрилансером тоже не очень релевантен - с тем же успехом можно сказать, что строителю-отделочнику приходится отказываться от работ по электрике.
Да упаси боже что то регулировать. Я просто описываю ситуацию как она видится мне. На мой вкус уж слишком много развелось фреймворков. Каждый раз выпускают очередного "убийцу всего", а на деле получается просто еще один новый фреймворк, не лучше и не хуже других.
Строитель отделочник и электрик это разные профессии. А программист - одна. Вот предлагают мне проект со словами "ты ж программист, займись", при этом заказчик часто и слова такого - фреймворк - не знает. А там очередной новый фреймворк и передо мной выбор - или тратить время и деньги заказчика на изучение, или отказываться, оставляя себя без денег, а заказчика без выполненной работы. Никто не рад будет в такой ситуации, обе стороны получили проблемы.
Я не предлагаю, чтобы кто то один все диктовал и все было абсолютно единообразно. Но хотелось бы поменьше раздробленности, излишне узкой специализации. От такой ситуации страдают и исполнители, и заказчики.
Я вам привел конкретные примеры проблем, вызванных большим разнообразием фреймворков, стеков и технологий, из своей практики. Но вам они почему то не нравятся. Я их считаю релевантными, вы - нет. Так можно долго спорить, останемся тогда каждый при своем мнении.
Добро пожаловать на свободный рынок
Для меня минусы этой штуки и вообще CSS-in-JS вполне понятны:
Вместо понятного и распространенного CSS добавляется лишняя абстракция. Нужно дополнительно напрягать мозг при написании и чтении стилей. И глядя на какой-нибудь `p: 10` пытаться понять что это значит. Не знаю есть ли конкретно в StyleX такие сокращения, но зачем мне изучать ещё один язык, если я уже знаю CSS?
Изредка хочется использовать относительно сложные селекторы. В StyleX они видимо вообще не поддерживаются?
Информации по CSS просто на много-много порядков больше, чем по очередному CSS-in-JS. Когда находишь какой-нибудь CSS-рецепт каждый раз нужно его транслировать в StyleX или наоборот если у тебя проблемы со стилями, то чтобы задать вопрос их нужно сначала перевести на CSS.
Нельзя за 2 минуты создать HTML+CSS файлик в "блокноте" и по-быстрому отладить стили в браузере. Или поправить стиль в браузере и скопировать обратно
Это неизбежно приведет к появлению сложной логики в стилях - всякие переменные, вызовы функций так что в этих стилях потом сложно что-то понять
Эти фреймвоки бесконечно меняются и запаришься каждый раз мигрировать стили
Генерятся классы с рандомными названиями - их нельзя использовать для какой-нибудь логики на JS, для тестов
В чем вообще смысл всё запихивать в один большой файл? С двумя маленькими файлами проще работать чем с одним большим
Пытаюсь понять плюсы:
Возможно лет 15 назад, когда было много разных браузеров, CSS в них работал по-разному и вообще был очень ограниченный, был какой-то смысл в этих абстракциях, но сейчас зачем это
Решение проблем с наложением стилей, специфичностью. У меня обычно этих проблем не возникает, я просто придерживаюсь единой схемы описания стилей. Но ещё есть же всякие CSS layer, scope, shadow DOM. Они не решают эту проблему?
Людям сложно изучить CSS, а JS они уже знают. Непонятно что StyleX здесь упрощает, CSS всё равно придётся изучить, плюс добавится сложностей по постоянной трансляции стилей между CSS и StyleX в уме
Уменьшение суммарного размера CSS, ускорение загрузки и отрисовки за счет удаления неиспользуемых стилей при сборке, за счет динамической подгрузки стилей. Я в принципе не понимаю как можно написать стилей на десятки мегабайт, но для проекта масштаба фб наверное это возможно... Вообще конечно было бы интересно посмотреть что это за стили, почему их так много
Поддержка стилей не только в браузере, но и в нативных приложениях. В какой доле проектов это требуется?
В общем, к каким проблемам приведет StyleX я понимаю совершенно отчетливо, а преимущества как-то вообще не очевидны.
По минусам:
Любой нормальный frontend разработчик знает про плагин Emmet и для него должны быть понятны сокращения "p15, m15" и все остальные.
CodeSandbox? CodePen?
В целом согласен, но переменные - штука очень полезная, если грамотно пользоваться.
Спасибо за ссылку! Когда-то давно краем глаза видел, но я не фуллтайм фронтендер, поэтому не отложилось в памяти. При написании кода это клево, но читать тяжело. Особенно если на проекте много людей которые только иногда заглядывают во фронт. Я имел в виду такие сокращения https://mui.com/system/getting-started/the-sx-prop/#spacing типа pt (который есть в Emmet), my (которого нет в Emmet), ... А потом MUI перейдёт на StyleX и опять переделывать все стили...
Мне привычнее и проще это сделать в браузере. Для меня один из больших плюсов веб-разработки в том, что она практически ничего не требует кроме браузера и любого текстового редактора. Очень легко и просто делается минимальный пример, прямо в браузере можно его поправить, сразу виден результат. Для реальных проектов, наверное, да, без сложного тулинга не обойтись, но иногда ощущение что люди искусственно делают простые вещи сложными. А потом в какой-то момент начинают писать статьи, что мы тут подумали и решили отказаться от TypeScript. Я не удивлюсь если через какое-то время фб откажется от StyleX в пользу обычного CSS.
Обычные переменные в CSS да, но когда всё это замешивается с JavaScript-кодом, то люди начинают там реализовывать просто лютейшую логику с кучей функций разбросанных по всему проекту. А в CSS у них такой возможности нет, приходится напрягать мозг, чтобы описать стили проще. Если в CSS-in-JS писать простые стили с простыми переменными без JavaScript-кода наверное это норм, но чем это лучше обычного CSS с переменными?..
Пожалуйста :) На счёт переменных JS в CSS полностью согласен.
А на счёт CodeSandbox и CodePen не понял) Они же в браузере запускаются, как по мне это в разы быстрее и удобнее, чем в текстовом редакторе. Просто открыл сайт и пиши код, сразу всё работает. Хочешь Sass/SCSS/Less - тыкаешь настройки - добавляешь - работает)
1.Вы ещё на бутстрап сошлитесь)) Какие вообще точки пересечения у этих технологий? Эммет позволяет по быстрому html-структуру накидывать.
Ограничение на пустом месте. В браузере все равно не поправите.
Нет вопросов.
Причём тут bootstrap?
"И глядя на какой-нибудь
p: 10пытаться понять что это значит.", в своём ответе я сослался на плагин Emmet, который позволяет написатьp10, нажать tab и и получитьpadding: 10px;
Т.е. я имею ввиду то что frontend-разработчик, использующий этот плагин спокойно будет понимать все эти сокращения (ну почти все, экзотические mt, mx и т.д. придётся всё-таки доучивать).
О каких ограничениях речь? Я о возможностях написал)
1. Хотел ответить жёстче, но скажем так... Нет, я не считаю сколь-нибудь оправданным использованием Emmet для этих целей. Заучивать вот эту портянку? Спасибо нет, я не готов тратить ресурсы своего мозга на дублирование информации (я прекрасно ориентируюсь в синтаксисе "чистого CSS"). Я вообще css-код пишу в отдельном редакторе (js в vscode; html и css - в sublime, уж очень там годный автокомплит). Ну и я сходу вижу проблему в вашей интерпретации - px.
4. Ну какие уж тут "возможности" - необходимость в интернет-доступе и целых два сервиса, вместо "в любом текстовом редакторе"?
UPD: Какая жесть здесь "интеллектуальный markdown-редактор"
Emmet - это просто способ управлениея автокомплитом. Давайте еще в исходниках Ctrl+F писать вместо RegExp. Его ещё больше народу знает.
Как лихо некоторые бесполезные и, как минимум, спорные особенности представлены в статье как преимущества библиотеки.
Новая либа фигачит всё в единый файл? И теперь все ваши хот-релоады и FCP (First Contentful Paint) идут по одному месту? Это никакая не недоработка, как вы по неопытности могли подумать! Это перфоманс и решение проблем с рантаймом!
Либа применяет последние стили, словно к ним подписаны «!important»? И теперь цвета для ваших иконок вы обязаны передавать внутрь компонента иконок и возможности управления цветом из родителя у вас больше нет? Что за дичь, могли бы вы сказать! Но нет, это называется предсказуемость!
В общем дальше лень писать. Не буду говорить что либа отстой и полная фигня, но выглядит она так, будто создается строго под какой-то определенный воркфлоу и вряд ли будет давать хоть какую-то пользу тем, у кого он отличается.
Увидел только что на Youtube, просто оставлю этот билбоард здесь..
Интересно, сколько ФБ выделяет на инфлюенсеров?
Предсказуемость – приоритизация селекторов в StyleX очень проста – всегда побеждает последний заданный стиль. Это значит, что можно забыть про каскадность.
Все в одном месте – библиотека поощряет определение стилей в том же файле, что и компонента. При таком подходе StyleX удаляет неиспользуемые свойства из бандла и убирает дубликаты.
Перфоманс – библиотека на этапе компиляции с помощью Babel-плагина превращает JS в оптимизированный по размеру единый CSS файл, таким образом мы избегаем классических CSS-in-JS проблем с рантаймом.
Масштабируемость – гениальный Babel-плагин использует кэширование на уровне файлов и генерирует атомарные названия классов, за счет чего минимизируется размер бандла, а рост количества компонентов в приложении не сильно отражается на размере CSS файла.
Типизация – каждое css-свойство и переменная полностью типизированы, а мы можем использовать TypeScript или Flow, чтобы определить стили, передаваемые в компонент.
вроде очевидно, что скорее всего основное место применения SSR/Lazy loading.
Но css-in-js подход - ?
Я хочу писать стили нормально, хочу копировать их из девтулзов. А не описывать все объектами с camelCase названиями.
Решительно не нравится спред оператор.
1.Отвлекает и усложняет чтение кода.
2.Начинающих разработчиков вгоняет в ступор, ведь prop drilling и неявная передача пропсов - антипаттерн.
Публикации
Обзор на новую CSS-in-JS либу от Facebook* – StyleX