Atomic CSS и Tailwind: отличный стек для масштабируемой вёрстки | Валентин Ульянов #37

Привет, друзья!

С вами Кирилл Макевнин, ведущий подкаст «Организованное программирование».

Сегодняшняя тема нашего, хотел сказать, занятия – CSS.

И мы обсудим эту тему вместе с Валентином Ульяновым, разработчиком онлайновых редакторов а-ля Excel, Word и тому подобного.

Я подозреваю, что даже многие из вас пользовались продуктами той компании, в которой работает Валентин.

Но, может быть, мы немножко об этом тоже поговорим.

Привет!

Привет!

Да, всем привет, ребята.

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

Наверное, первый вопрос, с которого я начну, в принципе, знаешь, о чем рассказать.

Что вообще происходит в мире CSS?

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

И вообще, я даже не удивлюсь, если CSS сейчас является тюринг-полным.

Ну, фактически языком программирования.

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

Как-то более-менее, но из-за старых браузеров многие вещи нельзя было внедрять.

А уже несколько лет назад, как вот EA умер, это все стало сильно получше.

То есть некоторые вещи уже спокойно можно было использовать.

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

Сбылась, когда у нас сейчас вечно зеленый браузер.

Вот это первое.

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

И что?

То есть оно сейчас и быстро развивается, и достаточно кросс-браузер.

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

А я, кстати, хотел тебя сразу спросить, а какой сейчас браузер?

Вот долгое время действительно E6 был.

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

Потом он действительно ушел, Chrome все запланил, сейчас немножко это меняется расклад.

Короче, есть сейчас аутсайдер, который всех тянет на дно.

Дай угадаю Safari.

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

из всех команд, по сути, основных, вот, Chrome, Edge, Safari, они собираются, то есть выбирают предложения, над которыми будут работать, то есть сначала выбирают, потом все это согласовывают, и на протяжении года они, то есть какие-то темы, какие-то фичи, над которыми они будут работать, и вот на протяжении года они всем этим занимаются, да, и вот как раз, отвечая на вопрос, в

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

Но так, да, там баги какие-то отдельные есть.

То есть сейчас уже так, значит, даже не скажешь.

То есть нет такого, что прям под кого-то надо все время там страдать?

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

Вот прям жесткого аутсайдера сейчас не выделишь.

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

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

Слышал что-нибудь?

Media queries, понятно.

А контейнер queries?

Контейнер queries, да, это похожая немного вещь, но уже она позволяет тебе в зависимости от размера контейнера как-то менять стили.

То есть, ну, там специальное вот, типа, пишешь как add media, то есть, пишешь add container, и там тоже, например, если там ширина, то есть, ширина, высота, например, какие-то aspect ratio, там ограниченное количество свойств у контейнера, они, ну, в какой-то условии задаешь размеру,

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

А может, я сразу уточню, перед тем, как мы дальше пойдем, просто чтобы реальные юзкейсы.

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

Правильно ведь в этом цель?

Да-да-да.

То есть у тебя получается, что у тебя адаптивность теперь не на весь, не на всю страничку, а на прям блоки отдельные.

Это очень серьезная штука ведь.

Она должна была бы решить какую-то фундаментальную проблему, так ведь?

То есть какие юзкейсы, где вот прям без этого никак?

Ну вот, да, какой-то типичный use case, когда у нас есть, например, без демонстрации сложно, конечно, объяснять, но постараюсь.

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

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

И как раз мы можем поставить, ну, и при этом на разных разрешениях, допустим, этот сайт-бар может выезжать.

То есть медиа-ворожение, мы этого не разрешим и без JavaScript.

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

И вот, пожалуйста.

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

И в этом конкретном случае действительно улучшает.

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

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

Не думаешь так?

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

И плюс в том, что он на другие элементы влиять не будет, он только это все на себе и вот.

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

Короче, ну ладно, это такие вещи уже более инженерно-процессные, чем сама фича, но понятно.

Вообще прикольно.

Кстати, интересно, в таком случае ее обобщили до того, чтобы заменить Media Queries для этого, или у тебя будет два механизма и то, и то?

Это оно отдельно.

Оно совсем отдельно.

Там медиа, потому что медиа, оно на самом деле не только у тебя про ширину, длину.

Там куча, ну, то есть там еще куча фич можно проверять в медиа вложениях.

Там, допустим, наличие курсора у тебя можно проверять.

То есть как у тебя, это можно проверять в медиа вот этих директиве, как у тебя запущено приложение.

Допустим, оно так, ну, в серии как PWA, например, запущено.

Или там, по-моему, даже скоро наличие включенного JavaScript проверять.

Ну, то есть там куча, куча фич.

То есть это совершенно отдельные вещи и, то есть...

Как раз наоборот, ну это отдельный год.

Даже, например, у контейнер queries там будет скоро продолжение, как такие style queries, ну как-то так они называются, что можно будет, то есть сейчас ограничено достаточно количество свойств, от которых ты можешь проверять, ну из серии, вот сейчас ты можешь проверить, что если у родительского контейнера, допустим, ширина, там такая-то или высота, буквально штук 5 свойств,

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

Капец, короче, я понял, да.

Но это все причем декларативно, то есть там такие описания всякие.

Ну да, это как обычно CSS, как обычно CSS, поэтому...

Жестко, но прикольно.

Окей, хорошо, давай дальше.

Это классная история.

Что еще?

Из того, что еще сейчас прямо в браузерах есть, это вот селектор хэс появился.

Ну, как псевдоселектор, правильнее сказать.

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

То есть чтобы у нас правило работало только вот, допустим, класс только при ховере работал, вот.

То есть хэс, это как тоже такой псевдоселектор, но он с аргументами.

И там ты можешь у него указывать, то есть с помощью него ты можешь определить тоже...

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

Вот правило с has, оно будет применено, если хотя бы один из селекторов, переданных в аргумент в has, да, выберет хотя бы один элемент.

То есть если у тебя, например, попробуй сейчас на форме, вот какой бы, да, сейчас примерчик бы привести,

Допустим, вот у нас есть форма, и мы хотим, чтобы поле какое-то, если невалидное там значение, оно там красная водка какой-то обвелось.

И, соответственно, мы что можем поставить?

Что мы можем на это поле конкретное, на input, добавить правило с селектором has и в нем прописать в скобочках все селекторы user invalid.

То есть это будет соответствовать, что невалидное.

Если сложно немного объяснять, получается, ну ладно.

Мы же обычно форму, мы когда форму верстаем,

Мы ее в лейблы заворачиваем.

То есть лейбл, в нем, например, подпись и в нем input.

Знаешь же такое, да?

Конечно.

Ну вот, соответственно, тут цель такая.

И вот нам надо, чтобы у нас вот на этом обводка появилась на всем лейбле.

Вот на всем там лейбле, который вокруг подписи и input.

И как раз мы можем повешать, что...

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

И, соответственно, если мы input, в input у нас будет невалидное значение, например, какой-то email невалидный, то у нас это все прокинется, точнее, у нас форма станет юзер инвалид, это все прокинется на лейбл и в итоге отработает правило, на которое мы навесили хэс.

То есть посмотреть, грубо говоря, он позволяет хестам посмотреть, какие псевдоклассы или вообще какие-то селекторы есть на родителей.

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

То есть у тебя невалидная форма не говорит, что все поля должны подсвечиваться.

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

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

Я надеюсь, словами получилось донести.

Ну, это такая фича, скажем, локальная.

А вот я имею в виду глобально.

То есть, например, те же самые переменные.

То есть, я думаю, что далеко не все знают, хотя, наверное, сколько они уже существуют, и вот то, что идет в эту сторону.

Про переменные?

Не, ну просто... Ну, контейнеры, да, переменные.

То есть, это же прям сильно изменяет.

Или я знаю, что про анимацию то же самое.

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

Только вниз можем смотреть.

Да, тут у нас способ заглянуть, то есть а что у нас сверху, то есть на отношении применить что-то в зависимости от того, есть ли у нас что-то сверху, это все-таки класс.

То есть это на самом деле, описание может оно не супер крутое получилось, но на самом деле тоже фича, которая влияет в целом на верстку.

Ну да, да, да.

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

Даже, наверное, до сих пор мало кто еще понимает, как это можно использовать.

Да, я вот об этом хотел сказать, что, ну вот, ключевое, что оно позволяет заглянуть вверх.

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

То есть, что, ну, ведь с годами это все оптимизировали, улучшали, как вот HTMLSS рендерится в браузерах.

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

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

Я, конечно, в шоке от уровня сложности, который сейчас там появляется.

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

Хорошо.

Ну, мне кажется, нет, так это только разминка.

Это мы еще сейчас, ну, не все.

Это только мы только начали, да.

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

То есть, ну, может, слышал, там это правило «леер».

Про это что-нибудь слышал?

Про LR нет.

Расскажи.

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

В чем смысл?

Что такое каскад в CSS?

Это возможность применять несколько правил на какой-то один элемент.

Да, причем

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

И вот это как раз такие встроенные разные слои каскада.

А это правило layer, оно нам позволяет свои собственные слои объявлять в рамках нашего всего CSS.

То есть мы можем прописать layer и там, допустим, какие-нибудь базовые стили.

И там что-то себе прописать и на теге что-то накинуть.

Следом, допустим, добавить стиль типа...

components, да, и вот просто стандартные наши все какие-то там компоненты, аккордеоны и так далее, для них накидать в стиле.

Понятно.

Правильно я понимаю, что фактически это обобщение и замена правил important или все-таки нет?

Ну, important это скорее как такой костыль, который нам позволяет, ну, перебить что-то.

Да, вот тут про специфические... Но вот оно не связано ли, да?

Ну, оно не совсем.

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

В том плане, что мы... Истерия, что сейчас мы можем, допустим, подключаем Bootstrap, мы можем Bootstrap подключить на отдельный слой, и тогда он точно никак не будет...

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

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

То есть это вот скорее такая штука.

Как будто бы есть какое-то пересечение с Shadow DOM немножко.

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

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

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

Ну да, мы до этого идем.

Когда вот ты руками пишешь CSS, это вот как раз одна из вещей, которые помогают архитектурно его как-то вот по-нормальному организовать.

Хорошо, а гриды?

Я вот, например, их ждал.

Помнишь, был хайп?

Гриды, гриды все-таки ждали, что в Flex, конечно, хорошо, но надо же еще layout задавать.

кто-то даже где-то начал использовать, где-то внедрили, но я так и не понял, в итоге гриды пошли или не пошли.

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

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

Там часто базы?

Нет, нет, гридов там нет.

Я просто, поскольку активный пользователь Bootstrap, там все равно раскладка пока... Ну, опять же, это по разным причинам.

Они же все-таки должны поддерживать какие-то и старые истории, и так вот ломать сходу нет.

Поэтому гриды в этом плане не то, чтобы прям ух, юзаются.

Я просто как будто бы слышал, что...

Их вроде бы сделали, но они не пошли в какую-то там то ли стадию аппрувала, то ли еще что-то, или я не прав, и они вот прям все.

Нет, ты скорее немножко, да, ты скорее с чем-то перепутал, потому что они уже много лет, особенно когда отвалился EA, они, ну, просто как, ну, это база.

Ну, флекс, да, а вот гриды все-таки, помню, что были эти issues, где они об этом писали, что типа рановато немножко с гридами.

Конкретно сейчас по индустрии, да, даже вот тот же Tailwind, который сейчас практически там не сильно уступает популярности Bootstrap, там гриды, там раскладки на гридах чисто в нем делаются.

Знаешь, наверное, последнюю какую штуку про фичи хотел сказать, а то сейчас мы с тобой этот changelog такой будем за 5 лет перечислять.

Меня, знаешь, что поражает?

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

Ну там разные вещи.

И вот я правильно понимаю, что все это в сторону каких-то элементов программирования и анимации?

Вот можешь пояснить?

Потому что как будто бы такие чуваки говорят, я игру сделаю.

Ну, как можно игру сделать?

У тебя есть состояние, да, у тебя есть... Ну, короче, тебе программировать надо.

Как это на CSS получается?

Ну вот сейчас, да, вот CSS вообще в какую-то сторону движется.

Там действительно очень много фич появляется, которые в том числе и как будто бы как уже программировать скоро можно будет, потому что то, что мы не дошли до changelog, там дальше игры еще и функции, уже есть черновики функции, что вот функции на CSS, да-да-да, и if, да-да, то есть там уже все, вот я к чему.

Стой, if серьезно?

Ну да, что-то типа, ну if имеется в виду сейчас, как функция if, ну вот в SAS есть функция if, например, которая...

не это правило if, а функция.

То есть, ну... Ну, понятно.

Вот, да.

Типа как чернорный оператор.

Аналогия.

Вот.

Что-то такое, там уже, ну, вроде как оно есть, вот, есть прям черновик уже этого спеки.

Да, я к тому, что, ну, да, применять, вопрос применения, оно действительно много чего.

Ну, то есть, я бы вообще, я это как вижу, что эти вещи нам

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

Ну, то есть сейчас многие вещи, которые раньше тянули библиотеки на 5-10 килобайт, можно сделать одну строчку из CSS, грубо говоря, или тремя строчками.

И вот это одно из хороших назначений, где вот это все может помочь.

Ну и плюс, опять же, где этой серии применять?

Например, помимо вот такого, допустим, какие-то демки, да, красиво это все можно делать.

И плюс еще вот про, опять же,

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

Вот эти вот фичи делают, на мой взгляд.

Ну вот, кстати, да, мы с тобой подобрались к препро и постпроцессорам.

И здесь что получается?

То есть, с одной стороны, я, наверное, насколько вижу, браузеры внедряют сейчас все довольно оперативно.

Внедряют почти синхронно.

То есть, у тебя как будто что-то появляется, и тут же есть возможность это использовать везде.

Ну, опять же, это происходит очень быстро.

И правильно я понимаю, что фактически многие же идеи пришли как раз из пре- и постпроцессоров, которые они, о, классные фичи, давайте внедрять.

Ну, то есть, потому что видно прямо, что перетягивание идет, да, у тебя туда все это заводится.

Приведет это или не приведет вообще к их убиранию, исчезновению или еще что-нибудь в этом духе?

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

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

Ну, во-первых, опять же, про процессоры, какая там ситуация.

Раньше их было несколько, каких-то более-менее используемых, типа там был LES, там Stylus, ну и SAS, да, как он самый первый появился.

Сейчас, по большей части, релевантен только SAS, потому что, в отличие от всех остальных, он прям развивается, то есть у него там куча скачиваний на NPM до сих пор больше, чем у Tailwind'а.

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

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

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

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

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

То есть там вот такая штука полезна достаточно в этом плане.

И еще, то есть это второй был искейс, большая какая-то кодовая база.

И третий – это вот как раз для чего-то прям сложного и нестандартного на…

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

Вот, то есть для такого они все еще подходят.

То есть резюмируя, что, да, где-то CSS выясняет, вытесняет, актуальность немножко потеряла, но они живые, по крайней мере, SAS живой, развивается, и use cases они все еще есть.

Ну, давай пару прям примеров.

То есть автопрефиксера, например, применять все равно нужно так.

Ты к CSS его не применишь, а он нужен.

Ну, автопрефиксер, это скорее сейчас, это немножко разная вещь.

Это процессинг.

Один вопрос, это процессинг CSS, а второй вопрос, это, ну, припроцессоры, которые, ну, какие-то вот...

языковые, добавлять языковые фичи условно.

Да, да, да.

Просто это все-таки разные вещи, я бы это разделял.

Я имел в виду, например, знаешь, что вот у меня в Bootstrap в пятом очень классная фишка есть.

Я думаю, что она там много где есть.

Это генерация своих утилит.

То есть, когда, например, у тебя есть прозрачность, да, ну вот сейчас в Bootstrap это внедрено, у тебя есть прозрачность и там 0, 25, 50, 75 процентов и так далее.

То же самое высота и так далее.

Но того же не было, по-моему, для высоты.

И они сделали очень классную штуку.

Вместо того, чтобы просто добавлять... Ну, ты понимаешь, на любую опцию можешь добавлять почти 75%, 50%, 100% и так далее.

И они сделали очень классную вещь.

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

Там у тебя появляются вот эти точки, ты пишешь там 25, 50, тра-та-та.

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

И он тебе генерит, соответственно...

в очень небольшом описании, например, там, высота defis 25, высота defis 50, и, соответственно, правильный стиль.

И все это описывается очень одной компактной конструкцией.

Честно, для меня это просто вообще фантастика.

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

Вот на CSS такое не сделать, да, ведь пока?

То есть там прям надо функции программирования поставить.

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

Там у тебя есть и часть как от Atomic CSS подхода, и есть часть, ну, обычные просто компоненты, вот.

И часть, которая Atomic, но она находится, я бы сказал, на таком...

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

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

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

Короче, будем еще жить со всеми этими делами довольно долго.

Еще один был вопрос по поводу вариантов создания CSS сейчас.

Да, давай, вот это прямо перед фреймворками важно.

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

Ну, потому что, давай так, для нас CSS это штука, которая не должна нас отвлекать от основной работы.

Вот.

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

И...

Мне вот интересно в этом плане, как вообще сейчас, в принципе, люди к этому подходят.

Я знаю, что, ну, это любое, берем направление, все такие, там, фреймворки зло, пишу сам.

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

И там немножко это безумие.

А вот в CSS-е такого было много, что я все буду там с нуля писать сам.

Вот насколько вот это вот ушло?

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

Ну да, здесь тоже могу немножко ситуацию пояснить.

Основные способы сейчас у нас какие?

Первое – это написание CSS.

Первое – это стандартный рукописный, когда мы, например, по BEM, чаще всего по BEM пишем, соответственно, просто как-то сами руками правила, как-то это все разбиваем на какие-то каталоги и так далее, да.

Это стандартный.

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

Третий.

Некоторые его относят к CSS и JS, но я бы его выделил отдельно.

Это так называемый scoped решение, то есть CSS-модули, например.

Тоже сейчас одно из самых популярных, наверное.

И также эти механизмы, они есть, например, в некоторых фреймворках встроенные, типа по Vue, в Svelte, то есть изоляция стилей.

В чем суть этих решений?

В том, что ты пишешь CSS...

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

Вот, то есть это такой можно третий способ выделить, вот, скопт решения.

Четвертый — это Atomic CSS, вот популярный сейчас Tailwind, и еще другие библиотеки есть для этого.

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

Основные способы сейчас такие, я бы назвал.

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

Ну, да, в том числе, в принципе.

Ага.

А вот давай начнем прям с первого.

Насколько вообще это популярно?

То есть это вообще считается... Мне кажется, зашквар уже сейчас с нуля писать.

Ну потому что... Ну это же безумие вообще.

Ну, есть такой взгляд.

Сейчас я во многом согласен, что да, сейчас вот...

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

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

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

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

И вот не зря же в свое время был целый BEM стек Яндекс сделал.

Там все не ограничилось нижними подчеркиваниями и дефисами в названиях классов.

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

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

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

Такой момент.

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

Но CSS и JS это же как бы по сути же то же самое.

То есть ты сам пишешь, но типа в JS, правильно?

То есть там все равно tooling какой-то нужен.

Или я неправильно понимаю?

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

У тебя там, например, не нужно думать над названием сущностей, ну в большинстве случаев.

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

Тебе над этим тоже думать не нужно, скорее всего, там структура экологов тоже тебе не нужно думать.

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

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

Следующее это то, что оно не для каждого стека подходит, потому что, ну да, если у тебя там стандартные спаны реакции, там понятно, это просто, ну вот если у тебя там Ruby какой-нибудь тот же самый, да, вот, ну, back and first какой-то проект, или экзотика, типа там Elma, там Clojure скрипта условно, ну, ты тут уже особо не вставишь CSS NGS, да, и плюс...

У них из минусов есть, тоже как к минусу можно отнести, что есть рантайм решения, которые прямо в рантайме у тебя это все собирают.

Соответственно, размер бандла у тебя из-за этого тоже возрастает, да.

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

Но, опять же, это не все.

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

То есть и...

Резюмирую, если.

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

То есть DX более-менее, но свои подводные камни есть.

Ну и плюс много готового кода есть, которое вот эти библиотеки, то, что ты упомянул, они как раз многие с CSS и JS работают, интегрированы как-то.

Поэтому тут еще вот такой момент, что там и библиотека готового кода какого-то много.

В этом подходе.

Ну и по сути мы пришли к тому, что все-таки, пожалуй, подтверди это или опровергни, основной все-таки способ написания это Atomic CSS.

Ну провод основной, это опять же, основной это спорный вопрос.

Спорный.

Сейчас я бы сказал, оно скорее на два лагеря.

То есть самый популярный это вот либо CSS NGS и Scoped решение, CSS модуль.

Ну потому что CSS модули очень часто используются.

То есть я там, не знаю, чуть ли не каждый третий.

То есть скорее основных я бы таких выделил три.

CSS, NGS, Scoped и Atomic.

И они по процентному соотношению так даже и сходу не скажешь.

А я что-то пропустил, я забыл про Scoped.

Вот эта вот штука, это же по сути глобально то же самое.

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

Но это не фреймворки.

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

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

Но также да, там из минусов, что опять же не в каждом стеке,

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

Но при этом он очень популярен.

Все засмотрели сейчас.

Я единственное еще такой вопрос задам.

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

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

То есть какой подход в такой случае?

Опять же, используют часто готовые какие-то, ну, готовые библиотеки много используют.

Я к тому, что...

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

Вот я к чему.

Что чаще, да, используют какие-то вот UI-киты, там типа вот этот Material, End Design, да, вот самые сейчас популярные.

И с одним из этих подходов используют UI-киты, да.

И там уже... Manatee, он, по-моему, называется вот как-то так, или Mantine, я не помню название его, там тоже какой-то популярный.

Его просто на Reddit все постоянно упоминают, я его видел.

Ну ладно, короче, есть еще.

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

Как правило, вот в стандартном проекте берут какой-то UI-кит, то есть либо берут UI-кит и просто его напильником подпиливают, либо еще хороший вариант – это Headless UI-кит берут, то есть без стилей, где у тебя просто прописана вся вот логика компонентов в серии, там всякие аккордеоны разворачиваться должны, как, например…

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

Понятно, что у нас базовый идет Bootstrap, но не чистый, а React Bootstrap, потому что сейчас там много где фронт-энда уже на React.

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

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

И я нашел, знаешь, что я нашел?

Prime React.

Он, в принципе, старенький, но он достаточно неплохо развивается.

И мне что понравилось как раз то, что он только существует в режиме не CSS-фреймворка, а конкретно компонентов на React.

Это там полезно с точки зрения развития, что им не надо там две вещи поддерживать.

А во-вторых, у них есть режим Headless и с темами под конкретные штуки.

То есть я что, получается, сделал?

Я его к себе добавил в Bootstrap.

подключил тему.

Там, правда, тема для четвертого Bootstrap, но я посмотрел, он выглядит нормально.

То есть жить можно.

Мне просто самое главное было, что я ничего писать сам не буду.

И все.

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

То есть React Bootstrap плюс Prime React.

И, конечно, количество возможностей там с точки зрения... Ну, есть базовые Bootstrap-овские, понятно, утилиты.

И у тебя бесконечное количество просто компонентов, которые просто... Ну, типа, знаешь, в Prime React есть грид.

Ты прям вставляешь, да, передал ему данные, и у тебя там...

Все, короче, прямо вот все само.

Это очень-очень прикольно для людей, кому нужно вот в таком режиме работать.

Но это сильно больше, чем и CSS, конечно.

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

Ну да, и там об этом и речь, что это вот как то, что ты писал, примерно стандартный способ сейчас, как пишут, что просто берут вот либо прям готовый UI-кит, либо Headless, и его уже...

там как-то.

Просто с Headless тут как раз прикол, что разные есть возможности.

Ну, опять же, в связи с инструментом есть разные возможности.

То есть ты Headless UI Kit можешь хоть и рукописным CSS-ом стилизовать, можешь хоть атомарным, хоть там и где-то CSS-ом.

Да, какой момент.

Так что тут тоже надо понимать.

Люди, использовавшие 15 лет назад XJS, смеются сейчас нам с тобой в лицо.

Да, так.

Типа у нас все это было уже.

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

Да, есть такое.

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

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

То есть они немножко абстракцию по-другому пересобрали.

То есть раньше это была в первую очередь история в себе,

Вот, я знаю, что молд в эту же сторону идет и, в смысле, так устроен.

А вот Prime React тот же самый, да, он такой открыт к тому, чтобы с чем-то коннектиться.

Ну, и понятно, что рукопашки больше тут, очевидно.

Но это уже совершенно другого уровня решение, да, которое тебе просто вот приложение раз и готово.

И, в общем-то, почти ничего делать не надо.

Хорошо.

Давай вот мы с тобой хотели больше поговорить про Atomic CSS.

Это как бы твоя тема, да, то, что ты хотел.

Вот много.

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

Значит, Tilewind, он сейчас number one в этом смысле.

У него там куча классных фич.

Он безумно красивый.

Я из него, кстати, тырю все дизайны, чтобы было понятно.

У него там классная библиотека компонентов.

Что, взял, чат GPT забросил, говоришь, перепиши мне на Bootstrap.

Он тебе переписывает, и ты радостно пошел, короче, вставлять это к себе в проект.

Вот.

Давай про него поговорим.

Какую проблему он решил и какую не решил?

Потому что вообще-то сообщество разделено.

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

И появилась, да, видите, обратная волна.

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

Короче, много видишь тут всего.

Давай врываться в тему Atomic.

Ну да, вот про ключевые, если вопрос ку-проблемы решает, ключевые его преимущества по сравнению с разными подходами.

Во-первых, это то, что мы тратим меньше Маслитополева здесь.

То есть нам не нужно, опять же, здесь думать про названия сущностей, уникальные названия классов, структуру каталогов не надо продумывать.

Второе, это то, что у нас меньше CSS в итоге попадает на клиент.

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

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

И четвертый такой неочевидный плюс, про который редко кто-то говорит, это что эта история, она такая стек-агностик, то есть ты не зависишь, ты хоть можешь стандартом там React'овском SPA использовать атомарный подход, хоть там...

На PHP у тебя там с шаблонизатором с каким-нибудь входит, даже вот в Elm, да, в уже упомянутом.

То есть от сека оно не зависит.

Ну да, это именно потому, что это все-таки CSS-фреймворк, а не, опять же, там, какой-то Prime React тот же самый.

Это чисто реактовская штука, ты ее не заюзаешь вне React, это правда, да.

Но тут, знаешь, что хочется добавить, точнее, договорить.

Вот все-таки Atomic, в чем он проявляется?

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

Потом комбинации просто уже в самом HTML, опять же, упрощенно, мы можем...

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

Или мысль немножко другая?

Ну, основа у него простая.

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

Смысл именно в их утилитарности, что одно какое-то простое действие.

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

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

Но что вот изменилось?

Вот чуваки начали его внедрять, да.

Он идет с дефолтной, кстати, темой, довольно симпатичной.

И что такие говорят?

«Фух, мы смогли уволить половину команды фронтенда».

Или как они говорят?

То есть бизнес какую в этом тоже пользу видит?

Или они такие говорят, ой, да нам просто, не знаю, проще там, гибче, что они говорят?

Потому что гибче, чем CSS, где полная свобода, конечно, не придумаешь, все равно какие-то ограничения появляются.

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

раза в два, грубо говоря, оно там уменьшилось.

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

Второе, это вот то, что выросло скорость разработки проекта.

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

Сначала, допустим, в рукописном сессии его написать, потом то же самое с нуля в Тамарном.

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

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

Ну, соответственно, переключиться, пойти написать стили для этого, да, когда придумал.

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

Оно как бы, ну, оно у тебя сработало.

Да, вот в базовом варианте.

Да, давай я тут начну накидывать как противник этой части.

Ну, во-первых, ты говоришь, уменьшается размер CSS.

Это правда.

Но с другой стороны, у тебя растет размер HTML.

Причем это же критичнее, потому что у тебя CSS-то загрузится потом.

А с точки зрения того, что поисковик, например, по SEO загрузит или там просто браузер вот в целом грузит и PageSpeed и все, у тебя HTML насколько увеличивается?

То есть насколько тут замедление происходит?

Или оно не критичное?

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

Во-вторых, оно там, Yahoo, вот у них как основоположники атомарного подхода, они как-то даже проводили эксперимент про вот замеры.

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

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

То есть, ну, опять же, с оговоркой, когда мы используем короткие названия утилит, потому что вот, например, в Tailwind... ПМ.

Типа того, да, вот если использовать короткие названия, да, вот как там в моем инструменте, как в атомайзере от Yahoo как раз-таки, там это достаточно хорошо, то есть HTML не сильно отраздувается.

Это, опять же, тут, видишь, очень важный пункт, потому что фактически мы сейчас переходим к штуке, которая очень controversial, да, как говорят.

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

Может быть, я даже думаю, больше.

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

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

Про него могу потом сказать, но то есть он спроектирован, скажем так, по заветам Вовки из Тридевятого царства.

И там вот эти, ну, нейминг там никакой, да, то есть совершенно без, скажем так, неконсистентный.

И плюс он длинный.

А когда мы используем короткие названия классов, там оно, то есть эта проблема, она меньше.

То есть она меньше, но у тебя очевидно.

Вот эти поменьше все-таки как бы классными становятся, во-первых.

То, что, да, когда ты первый раз это видишь, вот эти вот заклинания, да, аббревиатуры, ну, понятно, делать непривычно.

Вот, и оно, да, имеет порог вхождения, оно имеет порог вхождения, и кому-то чисто эти эстетически оно не подойдет.

Я здесь согласен, ну, окей, не подойдет, так не подойдет, да, то есть на рынке разные есть инструменты, да, спокойно к этому можно отнестись.

Вот, но в чем смысл?

Если один раз разобраться, тем более, вот, например, если говорить про МЛАТ, да, про мой инструмент,

Там сокращения вот эти, они составлены по четкому алгоритму.

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

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

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

Поэтому... Ну вот я все равно про концептуально.

То есть я понял твою идею с сокращениями, но это, скажем так, это просто оптимизация по, скажем, визуальному какому-то состоянию.

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

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

Ну, потому что у тебя чуть ли не один класс на одно свойство, на полтора свойства, окей, но все равно это очень-очень сильная детализация.

И у тебя все равно, когда ты сидишь это проектируешь, тебе надо применить там, не знаю, 15, 20, 30, причем не на одном уровне, а нескольких, если там что-то ты пытаешься сделать.

И вот эта вот штука, я честно скажу, я до сих пор ее не принял как концепцию того, что так надо.

То есть я могу выбирать, мне это не нужно, вот этот уровень кастомизации, мне наоборот, то же самое Bootstrap.

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

Мне это устраивает, мне больше не надо, да.

И каждый раз, когда я смотрю то же самое на Tailwind, или то, что поверх него сделано, вот классный пример, это Sheridan, да, он называется, я правильно произношу?

Наборы компонентов вокруг Tailwind, это очень популярная штука, просто про нее все сейчас...

которые про нее сейчас все говорят, но там фишка в чем?

Кажется, что-то слышал, что библиотека какая-то.

Что-то слышал.

Так прикол, знаешь, в чем?

Все такие, вот, классно, там замена.

Я такой, дай-ка посмотрю.

А там, знаешь, какой... Я такой думаю, а как ее установить?

Как вообще эти компоненты пользоваться?

А там написано, как это не так работает.

Ты просто копируешь к себе этот исходник.

То есть у тебя там есть, конечно, компонент а-ля навбар.

Ну, там, не знаю, аккордеон, еще что-то.

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

Но ты эти классы, ты как бы к себе это копируешь, и потом тебе с этим жить.

А, например, обновление, понятное дело.

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

Ребята, давайте вернемся к нормальному CSS.

То есть не создает ли это проблемы на каких-то больших объемах?

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

Мне как будто кажется, что нет.

Здесь могут еще помочь, ну, какие-то хорошие практики и паттерны, да, вот как с этим всем работать, да, потому что, ну, тут...

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

То есть в чем она заключается?

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

И, соответственно, для… То есть ты их начинаешь объединять.

Ну да, да.

Для использования каких-то вещей из серии, там, не знаю, для кнопки какой-то.

Вот как раз это для…

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

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

Но я здесь могу сразу сказать, что...

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

Потому что, ну, как правило, оно в билд-тайме.

То есть в итоге у тебя в HTML будут просто вот эти утилиты останутся.

То есть тебе не надо дописывать, вот как в случае с CSS-правилами, тебе не надо что-то дописывать, да, именно что у тебя в коде попадет.

Вот это первое.

Второе.

Их будет, как правило, меньше, чем обычных CSS-правил.

Ну, если бы мы описали несколько писем в CSS.

Их будет сильно меньше, поэтому у тебя с неймингом вряд ли будут проблемы среди вот этих вот алиасов.

Ну, и там, как правило, они, скорее всего, у тебя в одном файлике вместятся.

Потому что, ну, у меня там на среднем объеме проекта так получалось.

И третье, то что, то есть одна из киллер фич, это вот по сравнению с CSS правилами обычными, что ты можешь это редактировать, эти алиасы in place через, ну, поскольку это просто строка, да, ты можешь, например, если у тебя в 20 местах там у кнопки такая-то жирность шрифта, а в 21 у тебя, например, она другая отличается, ты можешь просто как заменой одну утилиту, заменой в строке в этом алиасе заменить в конкретном месте одно на другое, и все, оно у тебя заменится без, ну, без там создания нового существа, например, да, или, ну, так.

вот так как бы тоже фича вот и этот как раз вода

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

По поводу рантайма все понятно, оптимизации.

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

Ну да, да, да.

Я думаю, что это можно даже реализовать в реальности хотя бы для 90% случаев.

Поэтому это как бы я не считаю, знаешь, таким мегапреимуществом, потому что это все-таки оптимизационная вещь.

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

А вот в чем плюс?

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

А вот если ты вокруг этого, типа, давайте сначала соберем свой Bootstrap упрощенно,

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

И, соответственно, дальше мы это добро используем.

И при этом у нас есть возможность всегда вставить конкретные стили, там, не знаю, сеточку какую-то.

Ну, да-да-да, тут об этом как раз и речь, да, что вот если использовать хорошие практики и паттерны вот в этом анонсе CSS, они...

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

уникальное какое-то место стилизовать просто, ты можешь прямо накидать в конкретном месте их, и все.

Ну, то есть, да, мысль верная, что...

А в Tailwind'е алиасы — это встроенная фишка самого фреймворка?

Нет, в Tailwind'е это вообще нет.

Это вот алиасы конкретно, это вот, ну, я это называю паттерном, да, или таким best practice'ом Atomic CSS, что это не привязано к фреймворку, это именно вот такой паттерн, как ты можешь, то есть это вот то, что я сказал, ты можешь, опять же, хоть... В SASE, например?

Не-не-не, это на уровне шаблонизатора делается, как правило.

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

А, я понял, ты имеешь в виду, все, я понял.

Я думал, ты имеешь в виду, что есть прям конкретная имплементация.

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

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

И все делают очень по-разному.

Нет ли такой проблемы, что у всех там просто кто в лес, кто по дрова?

И знаешь, как часто бывает?

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

Или нет?

Или вот крупные проекты, которые долго на Tailwind, такие, да нет, у нас все хорошо, мы все помним, понимаем.

Да, в инструментах этой штуки нет.

Но, опять же, про это и, ну, так скажем, это здесь к тому, что Atomic CSS – это, опять же, методология, которая тоже есть там свои какие-то, то есть свои плюсы и минусы, свои какие-то best practices и там антипаттеры, условно, да.

Ну, что и серия про антипаттеры, кстати, например, череменно исполненная Apply, помнишь же, вот Tailwind такой, вот это как раз антипаттер.

Да, потому что ты, по сути, ну, оно превращается как в рукописный CSS, только немножко по-другому.

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

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

Оберток над Tailwind.

И они как раз решают эту проблему.

Потому что это то же самое, как React Bootstrap.

У тебя не просто это обертки над компонентами, но часто они добавляют какие-то вещи, которых изначально в React нет.

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

Потому что у тебя будет конкретно аккордеон, у тебя будет конкретно кнопка, у тебя будет конкретно ссылка.

А там внутри уже хоть 500 тысяч классов.

Тебе не важно, это обновляется само.

Соответственно, я вот недавно исследовал, я нашел как минимум несколько таких штук над Tailwind.

Она, кстати, называлась что-то на «не», как-то она называлась, а потом переименовали, причем буквально недавно.

И, по-моему, сам разработчики Tailwind выпустили, причем за какие-то деньги такие, типа 200 баксов, да, там у них появилась, короче, фигня, которую ты можешь купить, и это как раз вроде обертка над... Короче, это уже набор готовых компонентов.

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

Ну, это по идее, это скорее Tailwind UI, имеется в виду.

Ты про него говоришь, но он... UI-кит это называется, вот, у них это... Tailwind UI.

А, у них, ну, они, потому что раньше он вроде бы назывался Tailwind UI, а сейчас он, кажется, ну, переименовалось.

Он вроде бы как-то каталист как-то.

Да-да-да.

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

И в этом смысле, кстати, довольно забавно получается.

То есть это такой уровень абстракции, когда в принципе ты уже можешь, даже не важно, что там Atomic у тебя под капотом, но ты эту штуку можешь прям с Bootstrap сравнивать и выбирать.

Ну или я имею в виду с системами аналогичным Bootstrap, где у тебя тот же самый Prime React, где у тебя просто готовые компоненты.

Просто плюсом к этому у тебя идет возможность юзать, собственно, Tailwind.

Ну да, да, это скорее про вопрос, который упоминали, что как сейчас уже обычно используют, пишут CSS или пишут стили, да, что просто берут какую-то headless библиотеку и на нее уже наворачивают.

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

Возможно, скорее всего, опять же, я не пробовал, скорее всего, есть какие-то удобные вещи для именно вот кастомизации с помощью Tailwind.

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

Вот, и ты можешь, то есть там, видимо, и в этом еще тебе помогает каталист этот, что вот...

Ну, то есть... Я, кстати, только что посмотрел, ну, наверное, мы глубоко копать не будем, тут написано, что Tailwind UI is now Tailwind Plus, и Catalyst это отдельная штука, то есть получается, что какая-то там немножко другая связь.

Я думаю, что нам в комментарии накидают это, нас с помидорами, что мы ничего не поняли, и учите им отчасти.

Ну, расскажите, да, ребята, если кто-то следит и сечет, потому что это прикольно.

Я посмотрю, то есть мне вот эта вот уже штука нравится, но не нравится, что она платная, вот, я поэтому подожду еще немножко.

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

Да, это интересная штука.

Короче, их много развивается, но с ними всегда проблема есть.

Я вот скажу тебе, когда еще только вот Bootstrap появлялся, вот эта его активность пошла.

Там же на фоне очень было всяких много вещей.

Там был Foundation, как-то он назывался.

Да-да-да.

Он исчез, где он?

Никто про него не говорит.

Потом на основе самого Bootstrap было полно оберток.

Хотя, кстати, вот он плохо под это подходит, потому что он сам готовый UI-кит уже, да?

То есть это не Atomic CSS, с которого можно классно собирать.

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

А так в основном ты не можешь на них рассчитывать.

Слишком уж много их умерло за последние десятки лет.

Ну да, и именно вот то, чтобы брать прям готовый UI-кит целиком и вот на него завязываться...

Ну, на нем называется, да, это достаточно опасно.

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

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

Опять же, вот эти решения, то, что мы там рассказывали про XDGS, MOLA и так далее.

Кстати, вот я небольшое такое замечание вспомнил про способы написания CSS.

Вот в MOLA там есть штука типа CSS NGS, но она более продвинутая.

То есть она еще более продвинутая в том, что там называется это немного CSS NTS.

То есть там типизированные стили, что ты, короче, если в CSS, ну, в свойстве какую-то допустим ошибку, тебе TypeScript это подсветит, что ты не то свойство написал, да, например.

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

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

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

Такое дефолтное решение, да, потому что ты и сам можешь там накидать и вот взять какие-то решения, типа как Headless, и туда стилизовать, да, например.

А если вот, допустим, какой-то, ну, там, условный второй Яндекс хочешь сделать, то там, ну...

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

Ну, TypeScript, да, да.

То есть TypeScript типизация в этом плане действительно интересная.

Это надо будет смотреть, как это будет развиваться и двигаться в эту сторону.

Я уверен, что это будет.

Но тут надо не забывать, что у того же Tailwind уже LSP есть.

Я поскольку им не пользуюсь, поэтому я не могу сказать, как он работает.

Но раз он есть, для меня это уже показатель того, что они в эту сторону идут, и у тебя там какие-то вещи, ну, прям...

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

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

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

анализа выбрасывания, что у тебя ничего лишнего нет?

Или это не выбрасывание происходит?

Короче, как эта штука работает?

А, ну да-да-да, поясню.

Это вот сейчас... Вообще как, в старые времена, когда вот только Atomic CSS начинался, первое поколение инструментов было такое, что вот...

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

Раньше был, который на этапе сборки просматривает ту разметку и лишнее выкидывает, да?

Вот так было раньше.

Ну, и кто-то даже там не стеснялся, просто вот был Legacy такой...

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

Там она небольшая, там килобайт, наверное, 14 CSS или 15, ну, кзипованного, имеется в виду, сжатого.

Некоторые просто подключали, вот, в лоб подключали и все, и верстали.

Вроде как на том же, по-моему, npm так и был долгое время сверстан, вроде бы.

Но современное уже поколение инструментов, оно работает вот по принципу, ну, так называемый JIT-мод, да, или там в основном который JIT-движок.

То есть, ну, это такое JIT, это JIT-компиляция не имеет отношения, это такое немножко маркетинговое название, которое Tailwind придумал в свое время, да.

Хотя, что интересный факт тоже, что вот немножко отступлю.

То, что саму эту концепцию первыми придумали и реализовали еще Yahoo чуть ли не в году в 16-м, наверное.

Да, это вот как раз один из первых инструментов вообще реализации этого миксера.

Это Atomizer.

И вот как раз у них там уже в 16-м году это было.

То есть то, что Tailwind продает как эволюцию, ну, продавал, да, или там что, вот они там изобрели.

Это было еще в Atomizer в 16-м году.

Вот.

И как он работает?

Что просто ты запускаешь...

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

Это как раз G-движок так работает.

Ты в современных автоматических инструментах, в Tailwind, в Unac, в Malati, оно есть, вот этот G-движок.

У меня есть сразу замечание, я вижу две проблемы здесь.

Первое, все те, кто пишет классический серверный бэкэнд с генерацией HTML в шаблонизаторах, они идут лесом, потому что, естественно, он не может анализировать какие-нибудь там Blade в Laravel, ERB, ну, понимаешь, да, все эти темплейт-движки бэкэндовые.

То есть эта штука работает только с фронтендом, правильно?

Нет, вообще бы не сказал как раз.

Это уже зависит от реализации движка, потому что, ну, вот, например, там, ну, то есть Tailwind сейчас...

Большая аудитория Tailwind это как раз рубисты, которые пишут вот классический такой, ну, классический бэкэнд.

Нет, то, что они его используют, вопросов нет.

Я имею в виду, как ты, ну, прикинь, ты вот пишешь в рельсе, у нас, например, Hummel или Slim.

Ну, у тебя этот движок обязан понимать и Hummel, и Slim, чтобы это писать, иначе, а это свой синтаксис, это свой язык, как он замены сделает.

Вот смотрю отметку.

А ты видел, как Slim выглядит или Hummel?

Ну да, я с шаблонизаторами.

Ну, например, Blade я вот использовал.

Не, посмотри Hummel.

Давай посмотрим.

Просто вот сейчас открой, потратим немножко время, потому что это полезно.

Просто вот ты глянь и скажи мне.

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

Можно Slim скорее даже посмотреть, потому что это более его продвинутая версия.

Аналог — это пак в ноде, это копипаста этого.

То есть он выглядит прям настолько не так.

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

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

А, ну типа, что он как паг?

А, ну да, что типа... Паг — это копипаста Хамла.

Это совершенно другой синтаксис.

То есть у тебя инструмент, если не умеет конкретно с ним работать, он никогда в жизни не найдет никакие стили и не заметит.

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

Движок должен уметь вот это вот.

Я здесь согласен, да.

Но, опять же, например, ну, Blade, тот же самый, ну,

Это очень популярная вещь.

Спокойно.

Мне кажется, он не Блэйд понимает.

Мне кажется, он просто понимает любые движки, в которых интерполяция сделана в классическом HTML.

То есть он понимает HTML, а все остальное не трогает.

А вот если у тебя интерполяция сделана не в классическом HTML, он как бы не знает.

Для него это просто мусор какой-то.

Почему?

Он просто может строчки... То есть самый простой пример, вот, например, как Млад сделан, он просто смотрит строки.

Я об этом и говорю, он не пытается парсить правильно, он просто как регэкспами смотрит.

Да-да-да, то есть простой, да, опять же, тут зависит от реализации G-движка.

Опять же, например, в МЛАТе, да, у меня достаточно простая вещь, грубо говоря, на нескольких регулярах, когда, грубо говоря, 80% там HTML, шаблонизаторов таких похожих на HTML и JSX какой-нибудь, оно спокойно, стабильно работает, да.

Что-то менее сценарное, типа вот паг, хамл и так далее, например, мой инструмент, ну да, он скорее всего не осилит.

Как Tailwind с этим работает, там сможет ли он хамл съесть или вот что-то менее дефолтное, где у тебя не в кавычках, это да, вопрос.

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

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

Вопрос.

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

Это просто физически невозможно, это ограничение, это такое, мира.

Как вот с этим работает?

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

Или я неправильно себе это вижу?

В том числе.

В том числе это один из способов, как вопрос решать.

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

Тогда он поймет по названию вопроса.

Да-да-да, от базовых, то есть от такого базового рекомендации можно с такого начать.

И второе, да, что если вот статически проанализировать никак не получается, то можно, ну, в отдельном месте их где-то прописать.

И, например, вот в Tailend я там, скорее всего, где-то в конфиге должен быть, может быть, типа white-листа или как это, ну, что-то типа white-листа, что вот такие-то утилиты точно мне сделать, да.

Вот, а в MLAT, например, там есть AOT, то есть,

В отличие от большинства вот этих популярных инструментов, а вот режим, там он не удален.

То есть ты можешь, там есть, ну, ты в SAS конфиге можешь тоже прописать, типа, какие, типа, тоже в строчке, и какие тебе утилиты нагенерировать, да, то есть просто в строчке, и все, да, то есть в том числе.

Ну, и, то есть там еще есть как бы способы различной генерации утилит, ну, ahead of time, как вот в SAR-ом варианте, да, то есть это комбинировать можно.

Поэтому, то есть, тут, да, замечание хорошее.

А вот это вот другое, да.

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

Вот мы с тобой говорили, да, что у тебя, например, есть там прозрачность, а есть прозрачность 50%.

То есть, как это происходит в Tailwind?

Я просто пишу класс, он увидел его, распарсил, понял, что я хочу, и создал соответствующий класс в CSS.

А вот да, да, немного могу раскрыть.

Там есть, вот в Tailwind, например, есть специальные синтаксисы, ну из серии вот, и я, например, понял, имеешь в виду, что, допустим, прозрачный цвет, что у тебя есть из серии красный, а ты хочешь там красный прозрачностью на 50% по граунду сделать.

Да, 35-20.

Да-да-да, вот.

И что, например, в Tailwind есть специальные, то есть часто для этого либо используются специальные синтаксисы в этих утилитах, да, что, ну, там, из серии, типа, пишешь там 50%, допустим, там, слэш и, например, 0.5 прозрачность, да, то есть либо специальные синтаксисы есть для этого, либо, ну, в MyLite тоже что-то подобное есть для каких-то вещей, либо можно использовать CSS-ные функции.

CSS-функции какие-то, например, современные, ну, это тоже из современных фич, допустим, про...

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

Вот, и, например, то есть вот даже такие вещи в утилитах можно, ну, в какие-то сложные кейсы спокойно использовать.

Единственное, что прямо сейчас вот как раз-таки это, ну, так,

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

То есть просто как сырую функцию тоже можно прописать.

То есть способы этого тоже есть в том числе.

Мы просто к тому, что фактически то, что ты говоришь, это уже аналогично прописыванию стилей напрямую практически.

Когда ты уже даже не классы, а просто стайл пишешь.

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

Ну там сейчас, да, там вот важное замечание, что, например, вот в Tailwind часто такие вещи opinionated сделаны, да, и вот либо вообще какой-то фантазийный синтаксис, а в Mlata там все максимально опирается на CSS.

Там вот как раз большая часть вот таких синтаксических штук, когда ты сложные какие-то значения, сложные значения для аудита из серии там,

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

Вот, и что в комик-теллинде тебе, да, скорее всего, придется вот...

Сырое, как вот в онлайн стиле писать, сырое CSS, как в онлайн стиле.

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

То есть тут, опять же, еще зависит от инструмента.

Ну, я имел в виду немножко другое, опять же.

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

Я имею в виду, что, например, банально ты не получишь автокомплита, то есть банально ты не получишь никаких проверок.

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

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

И у тебя нигде подсветка не появится.

То есть, короче, это еще более низкий уровень.

То есть, по сути, это уровень какого-то, неважно, хорошего или нехорошего синтаксиса, но аналогичный тому, что ты стайл прописываешь.

Вот что я имею в виду.

Потому что в Bootstrap у тебя предгенерация.

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

Ну, то есть, это статически можно выводить такие вещи.

И поэтому у тебя, ну, как минимум в проекте есть просто договоренности, что, ну, вот, у тебя есть такая штука, и... А, да, даже смотри, пример.

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

И это, конечно, суперудобно.

То есть вот эта штука, она всего этого лишена.

То есть это просто вот рукопашный стиль внутри, даже если это красивый язык.

Вот что я имею в виду.

Кстати, да, да, это верное замечание.

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

Вот в Atomic CSS это скорее вот про это, да.

То есть замечание это верное, что как раз в Atomic CSS старой школы он больше про то, что был, что у тебя заготовленные значения из серии заготовленная шкала размеров, например, заготовленные там значения.

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

Истерия, что что-то сложное, продвинутое написать, тут, опять же, от задач уже зависит.

Знаешь, еще какой интересный момент есть?

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

Потому что у нас это важно, и мы это поддерживаем.

Что я имею в виду?

Значит, дело в том, что у нас вообще на Hexlet нет отдельных фронтендеров.

Нет, Ролан, вру, у нас есть один человек, но это скорее больше помогать, потому что много маркетинговых задач, там, лендинги или еще что-то.

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

Ну, то есть у нас такое немножко, скажем, фуллстеки в этом плане.

Но при этом мы исходим из того, что не надо думать про фронтенд.

Ты просто вот у тебя есть компонент, ты его просто используешь.

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

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

Я понимаю, что кто скажет, а у нас это и запрещено, туда кроме фронтендеров никто не лезет, но понимаешь, да, о чем я говорю, что ты зашел, тебе надо какую-то штуку сделать, ну, если ты не эксперт в ЦССРе,

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

Правильно ведь?

Ну да, да.

Это хорошее замечание, что вот в этих инструментах паровхождение есть.

И вот тоже, кстати, интересный момент.

Есть стереотип, что Atomic CSS это для тех, кто плохо знает CSS.

Ну тут как раз вот это...

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

Ну ладно.

Тут, да, посыл верный.

Основная мысль про то, что вот, ну да, CSS здесь особенно вот знать надо.

И у этого прохождения есть.

Кстати, знаешь, наверное, не могу не заметить эту штуку.

Я действительно из-за того, что ну, то есть у меня нет такого, что я там

пытаюсь следить за СССРом и развиваться внутри него и все такое.

То есть есть какое-то базовое понимание, да, и когда я работаю, например, опять же, с бустрапом или подобными штуками, я знаешь, что замечаю?

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

Короче, я замечаю, что я мыслю реально вот именно этими высокоуровневыми конструкциями.

То есть я не мыслю тем, что там на фоне, просто я понимаю, что вот эта штука решает такую-то концептуальную проблему.

Колонки, например, да, там, роллы и так далее.

И знаешь, сначала я этого немножко стеснялся, потом я это принял, а потом я понял, что, блин, я реально 90%, наверное, 95% задач без проблем решаю таким подходом.

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

Давай так, я могу себе это позволить в своей собственной компании.

И поэтому те места, где у меня реально что-то такое надо сделать, где там надо что-то применить, я могу воспользоваться просто помощью других.

Вот.

И это, конечно, очень классная штука.

То есть можно так жить.

И действительно, вот когда говорят, о, ты ЦССР не будешь знать.

Да, черт побери, я его знаю очень плохо, если мы говорим по сравнению с какими-то крутыми ребятами.

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

Вообще...

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

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

Мы не придем снова к разделению на верстальщиков?

Так, не, самое смешное, что вроде как и есть, ну, вроде, ну, вроде как в каких-то компаниях оно даже есть.

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

То есть, во-первых, да, первое, что...

Частично это разделение уже есть.

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

Ну, это, опять же, для бизнеса это и хороший подход, это и норм, да, то есть, тут уже от сдачи зависит, вот, но если, там,

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

Поэтому и сильно проще сверстать, например, да, то есть там не брать готовый компонент.

То есть тут, опять же, сильно задача зависит, но в среднем для бизнеса далеко.

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

И сейчас это вполне рационально, это норм, ничего плохого нет.

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

Или не входит?

Я, кстати, до сих пор не понял.

Кстати, сейчас, ну, раз уже затронули, да, про них сказать стоит.

Вообще, ну, какая история?

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

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

создавать свои HTML-элементы с какой-то инкапсулированной логикой и стилями.

Все.

Вот.

И дальше, вот как уже ты это будешь использовать, уже зависит от твоей фантазии.

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

Вот такое.

То есть тут уже дальше от твоей фантазии идет.

Ну и поэтому сам по себе этот i5 достаточно низкоуровневый.

Там нету пока, не планируется, по крайней мере, условно, там, стейт-менеджмента какого-то на уровне спеки сделать или там роутинга.

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

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

Да, вот чтобы просто кастомные теги делать свои, и все.

А вот дальше уже как ты это будешь использовать –

от твоей фантазии побольше это зависит.

И при этом, с точки зрения, опять же, стилевого оформления, это полностью изолированная штука?

Или ты можешь ее снаружи, как в React, докидывать?

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

не такая-то фича, это вот набор спек, который, если как-то так называть, и вот Shadow DOM одна из основных там спецификаций.

Вот там есть с помощью, если применяем мы Shadow DOM, просто еще забыл момент, веб-компьютеры можно вообще без Shadow DOM применять, можно использовать только кастомные элементы, можно использовать.

Тут еще вот, да, момент, поскольку все низкоуровневое, и оно там как-то отдельно лежит, просто отдельные спеки, можно разных частей применять независимо, то есть

Просто я, например, в продакшене применял вот кастомные элементы не раз, и это нормально работает вообще без Shadow DOM.

Но если мы уже сюда начали говорить про такой каноничный способ с Shadow DOM, там есть несколько моментов.

Первый способ – это когда ты прям… То есть когда ты включаешь Shadow DOM, да, он изолированный.

по дефолту вот и уже как с таким изолированным стилем работать там можно либо у тебя прям в шаблоне прописать ну условно в этом в shadow доме прописать текст стайл и в нем накидать какие-то стили какие-то правила CSS ну и все оно будет работать для какого-то изолированного виджета если ты делаешь да его вставлять это хороший способ но для переиспользования там есть второй механизм он называется constructable style sheets где ты можешь как будто импортировать например CSS да вот но это

То есть сейчас это скорее больше как в CSS.js будет похоже.

Импортировать CSS откуда-то, да, его там подключить, там есть специальный метод, то есть в шедоу дома его подключить и, короче, использовать.

Вот, то есть там разные способы.

Плюс есть еще возможности внутрь вот этого шедоу дома влазить, допустим, с помощью CSS Custom Properties, там можно, то есть внутри у тебя, то есть внутренние Custom Properties можно снаружи, да, на них повлиять, его компонента.

И еще там кое-какие есть псевдоклассы, которыми тоже можно как-то,

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

в первую очередь, про особенности и что там отличается.

Потому что ты не раз упомянул, что это некая особая среда с особенными подходами и какими-то интересными, видимо, деталями, которые не встречаются в обычной такой типовой разработке.

Тут, на самом деле, было немножко заверено два вопроса.

Мой конкретный инструмент, ну, это просто инструмент для верстки с Ptumix CSS, то есть что-то похожее на Tailwind, да.

А то, что на работе я его не использую, оно... Не используешь?

Да-да-да-да.

Я думаю, просто это было результатом твоей работы, нет?

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

Давай про особенности сначала, вот именно разработки редакторов, то есть что там такого кардинально другого вот в твоем кейсе?

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

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

Текст и документ, собственно.

Так вот, во всех редакторах сейчас, каких-то более-менее серьезных, холстовая часть, она делается на Canvas.

Там же, как я привел пример того части мира, он тоже рассказал, что у них там на Canvas.

То есть часть, где вот какой-то особенно сложный UI, ну или rich UI еще это иногда называется, оно, как правило, делается на Canvas.

И там для этого, ну, соответственно, рендеринг там какой-то кастомный, как правило.

Поэтому там CSS там никакого нету.

Да, вот, а UI-ная часть, она небольшая, ее можно делать на чем угодно, в принципе.

Вот, там, ну, у нас, поскольку проект там со старых времен... Ты про панельки, которые... Да-да-да-да-да, я про панельки, вот.

UI-ную часть я называю именно вот эти панельки.

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

Поэтому тут не удивительно.

Джек Верри.

Бинго!

Да?

Да.

Ну вот, а то люди говорят, Джек Верри умер.

Ничего не умер, он во все поля.

Ну да, да.

Ну не только, опять же, а как бы это уже и детали.

То есть сейчас некоторые таких названий даже и не вспомнят.

Ну ладно.

Вот, например...

Из таких более современных примеров Photoshop веб-версия, там UI сделан на лите как раз-таки.

Это вот фреймворк на основе веб-комментов от Google.

У Adobe там потому что

Дизайн-система сделана как раз на основе ЛИТа.

Я, например, ЛИТ в продакшене использовал, делал программу лояльности для бренд-компаний, и мне тоже он зашел достаточно.

Поэтому зрителям тоже рекомендую, если есть возможность, на ЛИТ посмотреть, потому что это, по сути, такой стандартный фреймворк, похожий на стандартный веб-фреймворк, типа иконы TVU или React, да?

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

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

А про лид, особенно в русскоязычном сообществе, там три человека условно слышал.

А оказывается, он там... У меня есть скептическое отношение к скачиваниям в NPM.

Просто я не уверен, что это так.

Просто скажу.

Я знаю то, что эти системы... Там очень много CI, там очень много разных систем.

которые скачивают.

И ты просто знаешь, что делаешь?

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

И у тебя просто эти скачивания, там, счетчик начинает так наворачивать.

Я не уверен, что можно этой цифре доверять вот на 100%.

Ну, так, слово просто.

Я здесь согласен.

Я просто, что хотя бы приемный показатель, ну, согласись, что там, если 10 человек используют, у тебя... Это круто.

Да, да.

Я к тому, что вот, примерно хотя бы сравнимые какие-то цифры, как, ну, опять же, там, как у Свелта.

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

В Твиттере подписчиков и так далее, и так далее.

У Льда даже YouTube-канал есть.

Я просто к тому, что это не какая-то совсем маргинальная технология, а что… Опять же, это гугловский все-таки проект.

Что такое?

Вполне себе… Когда ты говоришь «гугловский», я знаю, что часть людей такие «ммм, серьезная компания», а вторая часть такая «ну это же Google, они его обязательно закопают».

Да-да-да.

Как они закопали веб-компоненты до этого.

Как он назывался?

Он так и назывался.

Полимер.

А, не, это, кстати…

Это развитие, это, ну так скажем, развитие Polymer, по сути, лид.

А что они ребрендинг сделали?

Видимо, уже все устали от него.

Нет, там скорее сейчас, там вроде бы была история, что Polymer был написан на первой версии спецификации, точнее, на нулевой версии спецификации веб-компонентов, и там ее задеприкейтили.

И, скорее всего, вот с этим еще и связано, что, ну вот, как бы такой супермажор.

Нет, ребрендинг нужен, да.

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

Это тоже такой прием.

Ну, может быть, да.

Может быть, да.

Ну, вот немножко ушли от вопроса про редакторы.

Ну, основное, вот, да, если поражать тему, основное, вот, особенность она такая, что...

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

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

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

Вот, и так, к слову, немножко, какой у нас фронт-энд.

Вот, как бы...

Вот такое вот, да, что, ну, это немножко поясню, потому что вот офисные документы вот эти, там, типа вот вородовские, экселевские, они основываются на спеке спецификации OOXML.

Ну, вот, и по сути внутри, если заглянуть вовнутрь, да, строение этого документа, это будет, грубо говоря, архив, где лежат несколько XML'ей,

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

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

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

У нас вообще как это, как у нас устроено?

Основной редактор у нас десктопный.

По сути, основная версия этого офиса у нас десктопная.

Это, кстати, тоже к слову про фронтенд, что как бы бэка там особо нет.

То есть десктопное просто приложение.

И что интересно, то что поскольку это все начиналось в десятых годах, электрона не было тогда еще.

Поэтому ребята, кто это начинал, они просто сделали...

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

Отдельная вкладка вот в этом вот Chromium, да, соответственно, вот такой момент.

И вот...

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

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

Да, вот что, ну, обычно киперссылку на текст вешаем, да, чтобы вот на картинку можно было в документе кликать, вот.

И как раз там вот не было десериализации вот тега определенного, да, то есть там раз другим тегом это делается, да, XML-ным, не так, как текст в киперссылке.

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

Вот.

Это как бы... Поэтому это был такой первый шаг.

Отлично.

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

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

Фиг ты там просто так что-то притащишь.

Ну да, тут я согласен, что у Legacy какие-то минусы есть.

Ну, это один из минусов, как бы, что текущее место работы у меня.

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

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

Поэтому, ну, тут, опять же, есть свои плюсы, есть свои минусы.

Да-да-да, это на самом деле интересно.

Вообще вот редакторы, всякие такие вещи, это прикольная штука.

У меня, конечно, не такой объем, но вот тот же самый редактор Hex, это я про него иногда говорю.

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

В общем, это довольно приятно.

Мне нравится этим заниматься тоже.

Но, слава богу, я могу себе позволить, знаешь, там этот, воткнуть любую новую штуку.

Если мне захотелось.

Да, ты уже несколько раз упоминал про свой инструмент.

Давай немножко про него поговорим.

Какую ты проблему хотел решить?

Потому что это очень классно связано с тем, что вот мы обсуждали.

Да, вот у тебя есть Atomic, у тебя есть Tailwind.

Все как бы на нем пишут.

И ты такой говоришь.

И, кстати, ты, наверное, не один такой говоришь.

Типа, хрень.

Или там, ну, не знаю, как ты это рассуждаешь.

Типа, напишу свое.

И еще 100 людей там говорят, напишу свое.

Давай чуть-чуть поясни, что за проблема.

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

Ну да, могу здесь ответить, что...

Вот поскольку я упоминал, начинал это все довольно давно, больше участвовал, скажем так, в стандартном фронт-эндом.

Я некоторое время назад занимался, то есть где-то три года карьеры я так достаточно много верстал.

И в году 2018, какая у меня была история, что я в то время, в какой-то момент, вот прям конкретно угорал по БЭМу.

Да, вот, ну, тогда еще это было все-таки чуть более актуально, да, вот такие рукописные вещи писать.

Я уграл по БЭМу, я там посмотрел все доклады, статьи, которые только были по этой теме, да, и вот, ну, все, мне оно заходило.

Вот, я вот как раз тоже, когда уже поплотнее с ним поработал, я вот начал задаваться продвинутыми какими-то вопросами, понял, что, то есть, чтобы что-то серьезное на БЭМе делать, нужен туль.

Да, и в какой-то момент...

Мне там случайно попал доклад про Atomic CSS.

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

Тут я просто беру, накидал вот утилит для связации, и все, и оно работает, все.

Я пошел дальше, мне не нужно больше думать об этом.

Я как-то реально ощутил эту самую легкость бытия в процессе верстки.

Мне оно как-то очень сильно зашло.

И я решил этой темой заинтересоваться, начал к тему копать.

Тогда еще, учитывая 2018 год, тогда Tailwind это была еще ноунейм-библиотека вообще.

Какая тогда была проблема?

Были тогда популярные инструменты, допустим, тахионы.

Вот я упоминал, библиотека...

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

Потом...

Вот в Tailwind там тоже самое.

Там в Tailwind тогда было очень мало фич.

И тоже проблем с неймингом было.

Вот был Atomizer от Yahoo как раз, в который уже тогда был JIT-движок.

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

И то есть вот этот синтаксис, да, он мне прям, ну, мне он как-то совсем не зашел, да, вот, ну и плюс...

Вот такой был момент, да.

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

Вот я как-то взялся, и плюс такая возможность была на работе, вот я как-то взялся просто как в этот проект, инструмент для вот верстки с Tomix, подходит у Tomix CSS.

взялся там внедрил в этом на работе с командой использовали да и как-то вот делал себе делал да немножко это все релиз выпускал какие-то фичи вот то есть просто это был под проект какое-то время да особо где-то он превосходил по фичам Tailwind где-то не особо но там ничем не отличался но в какой-то момент ну я поскольку у меня давно еще была такая идея что мне хотелось мечта вернее

стать open source разработчиком, да, вот что-то такое свое сделать, я в какой-то момент решил оформить в полноценный open source проект.

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

Соответственно, в 2021 году я как бы решил за него серьезно взяться.

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

И я, по сути, переписал свой инструмент за условные 7 месяцев.

То есть я переписал его так, что по многим фичам он стал тоже стерлинг превосходить.

Какая была цель?

Я делал инструмент, который мне был удобен, интересен.

И второе, это что я пытался решить проблемы, которые есть у текущих инструментов.

То есть я начинал как пэт-проект.

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

Вот проблема там нейминг.

Я тебе честно скажу, я ни разу ни от кого это не слышал.

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

То есть это все-таки твое личное восприятие или это как бы некое настроение в сообществе?

Вот прям про issues, опять же, я не скажу, но не раз, когда вот при набросах на тот же Tailwind, вот не одну статью читал про то XSS и про плюсы и минусы, да, вот когда изучал тему, там одно из один из пунктов был про то, что там как раз не константный нейминг, да, то есть из серии, ну, там какие-то примеры приводить, что там, допустим, flex, то есть...

Утилита для того, чтобы дисплей Flex задать, называется просто Flex, да, а вот утилита, чтобы задать там Flex, а есть просто свойство такое, кстати, Flex, сокращенное свойство, где-то можно для нескольких там FlexBases, FlexShink, еще что-то указать, да, вот, и указать свойство Flex там с каким-то значением, оно называется типа Flex1 или FlexAuto.

И таких примеров там много.

И вот я это сам увидел, и у тех, кто... То есть такие замечания не раз я слышал.

Про issues, опять же, не помню только issues, но от, скажем так, аргументы против Tailwind, такие я слышал не раз.

Я тебя понял.

Ну, честно скажу, конечно, все-таки такие... Мы с тобой говорили по поводу уровня популярности и всего остального.

Здесь, конечно, это имеет огромное значение.

Tailwind, все-таки за ним стоят люди, которые в том числе зарабатывают.

И у них есть возможность всем этим заниматься.

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

Я просто, мне интересно, есть ли pull-request или issues на эту тему?

Потому что они же все-таки развиваются, выпускают новые версии.

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

Потом, как часто делают, добавляют новое имя.

Потом какое-то время они оба работают.

Потом первое деприкейтят.

Потом, соответственно, еще и утилиту пишут, которая реплейсами все это заменяет.

То есть там...

Были вообще такие случаи изменения нейминга или нет?

Про нейминг как раз такого не было.

У них такого не было.

И подвижек я, ну, опять же, я не скажу, что я там многое еще прочитал в Tailwind, но подвижек в эту тему тоже нет.

Может, немножко сумбурно рассказывал, да, про историю, что вот одна из претензий у меня, например, к Tailwind, что вот, как я уже говорил, он спроектирован примерно никак.

То есть там...

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

То есть в Tailend изначально это никак вообще не было предусмотрено.

Когда появились джип-движки, появилась опция делать произвольные значения для утилит.

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

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

Это мы обсуждали.

Вот в Tailwind, соответственно, это никак не было действительно предусмотрено.

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

И там тебе нужно писать такой сырой CSS, который не связан с конвертируемыми, так называемыми, значениями.

То есть вот

Термин конвертация подразумевает, что когда сокращение из значения утилиты превращается в настоящий CSS.

То есть там конвертация в произведенных значениях ее нет.

И вот много таких вещей по тому, как связи с CSS, оно там никак вообще не предусмотрено.

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

Вот понадобилось нам вид, что ну окей, давайте вот сделаем как-то так.

Просто как ad-hoc, просто набор таких ad-hoc решений, как бы архитектурные вещи там принимались.

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

И вот такой пример приведу простой, что...

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

Как получилось?

В Tailwind ребятам пришлось придумать новый синтаксис, чтобы использовать контейнер queries, да, и написать там типа плагин на условных там 70-80 строчек, да.

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

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

И вот у меня как раз оно спроектировано так, чтобы органично развиваться вместе с CSS и по сути с ним дружить.

Такой ответ я бы сказал.

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

Общее восприятие вот этой проблематики.

Потому что я с ней не знаком, поскольку Tailwind я не пользуюсь.

Для меня в целом сам подход, я уже много раз про это говорил, он для определенных кейсов, в которые я не попадаю.

И поэтому я спокойно к этому отношусь.

Валентин, тебе большое спасибо, что ты пришел, поделился.

Взаимно.

Спасибо, что позвал.

Было приятно здесь находиться.

Здорово.

Тебе приятно находиться у тебя дома, мне приятно находиться у себя дома.

Да, вот как-то так мы и живем.

Ребят, если вам понравилось видео, поставьте лайк.

Обязательно поделитесь своим мнением по поводу того, что мы сейчас обсудили.

И не забывайте подписываться на мой канал в Телеграме «Организованное программирование», где я рассказываю про разработку, немножко бизнес и обучение программированию.

Всем спасибо, пока!