Про неповоротливость ты не прав, потеря на инициализацию всего 10-20%. Зато почти двухкратный прирост по скорости рендеринга. Так что неповоротливый тут голый CSS =)
Мое портфолио убеждает меня что с версткой у меня проблем все таки нет. Без проблем верстаю и однодневные лендинги и десятилетние энтерпрайзы. И пиксель перфект и все экраны. А ты умеешь в пиксель перфект? Или на глазок верстаешь ? ))
Tailwind - это новый бутстрап. Мусор который сейчас генерируется тоннами. Пройдет всего пару лет и от него все будут шарахаться как от бутстрапа в 2019-ом.
Пример с кнопками взят из MUI. Кстати он написан на аналоге SC, библиотеке emotion. В той кнопке цвета меняются местами в зависимости от варианта кнопки. А это строго переменные CSS или JS.
Надо понимать что SC распространен только в мире React. Angular и Vue разработчикам он не доступен. Да и в мире React он распространен только на 25% примерно. У многих он вызывает религиозную неприязнь, что ожидаемо сказалось на карме статьи.
А от рантайме уходить очень не удобно, потому что динамические стили часто сильно упрощают работу.
Только механизм чуть более хитрый. В дом ничего лишнего не генерирует. Но картинку запрашиваем в зависимости от размера экрана. В итоге выигрыш до 10 раз доходит по размеру картинок на странице.
Этот инструмент сильно упрощает написание стилей. Судя по вашим словам ваша задача лежит за пределами написания стилей.
А ваша задача решается двумя способами. Либо компонент в пропсах принимает какие то кастомные элементы, которые подменяют дефолтные. За пример можно посмотреть MUI. Либо делать две независимые библиотеки.
BEM приведен для примера как самый популярный подход написания компонентных стилей в CSS.
Но как же вы решаете проблемы удаления мертвых стилей, простой переход к CSS селектору, поиск используемых стилей при рефакторинге, изоляции стилей и остального без использования SC?
>> В каком окружении, на каком устройстве, в каком браузере?
Это был тест. 1000 рандомно сгенерированных стилей и 1000 элементов на странице. Браузер Chrome. Процессор Ryzen 5800X.
>> Как решить задачу в случае styled components без пересборки бандла компонента?
На самом деле крайне странно слышать про пересборку SC с учетом того что это фактически JS и он полностью динамический в отличии от CSS.
Для решения задачи есть два варианта:
SC не лишает вас ничего из того что у вас есть в CSS. Поэтому можно использовать все те же CSS переменные =)
Но почему конкретно я не использую CSS переменные во встраиваемых модулях. Есть такой антипаттерн - Глобальные переменные. Фронты уже поняли что в JS его использовать плохо, но почему то не поняли что в CSS переменных его использовать все так же плохо. А CSS переменные это глобальные переменные.
В комментариях выше уже писал пример как я уже ловил багу из-за конфликта CSS переменных. Как эту проблему помогает решить SC? Значения в CSS назначаются через изолированные JS переменные.
Был кейс когда в проект встраивались два микрофронтеда с использованием одной и той же UI библиотеки на CSS переменных. В одной библиотеке эти переменные были переопределены и что привело к конфликту CSS переменных со вторым микрофрондендом. Пришлось тратить время что бы выкрутиться из конфликта. В Styled Components такая ситуация невозможна в принципе.
Пример с кнопкой наверное слишком простой, но и с CSS переменными вы там на мучаетесь. У меня есть компонент Grid. Что бы он соответствовал сетке из Figma пришлось писать логику. В Figma сетка на десткопах имеет 12 колонок, планшетах 8 колонок, на мобилках 2 колонки. А еще 6 брекпойнтов по размеру экрана. А еще есть сетки вложенные в сетки. Например сетка с колонками 3 и 9, в 9 вложена сетка еще на 9 колонок. А еще в дефолтном положении она имеет 12 колонок. И в таком кейсе вам никакие CSS переменные не помогут. Styled Components справился с задачей идеально, на все расчеты уходит 1 наносекунда.
Сейчас прям полноценного мониторинга нету. С клиентов метрики собираем через гугл аналитику, включая WebVitals. Контейнеры с nextjs и nestjs метрики собираем через prometheus.
Собираемся сделать полноценный мониторинг клиентов через WebPrometheus. Как выведем в опенсорс напишу подробную статью про наш мониторинг клиентов.
Конкретно на этом проекте бекенд не мой, а фронтендовые микросервисы совсем не общаются между собой. На проектах где бекенд мой, микросервисы общаются через rabitmq.
Экземпляров можно запускать сколько угодно. Конкретно у нас запущено по 3 штуки для обеспечения высокодоступности.
Деплой настроен автоматический. При заливании в дев микросервис деплоется на внутренний дев стенд, при заливании в мастер деплоится в продакшен.
Паплайны разделены на две части. Первая это сборка контейнера и доставка в приватный репозиторий. Как правило их делают разработчики, но может сделать и девопс. Вторая это раскатка конфига по контуру. Здесь используется концепция GitOps, когда конфигурация прописана в гите и раскатывается по контурам из гита. За эту часть отвечает девопс.
Инфраструктурой в МТС занимается отдельная большая команда. Они отвечают и за надежность, мониторинг, уязвимости и остальное.
Да. Любые изменения в коде проходят через регресс. После разработки задача попадает тестировщику. Только сейчас тестировщик прибегает к помощи разработчиков для тестовой рассылки, а перейдем к процессу когда тестировщик сможет протестировать без участия разработчика.
У меня тоже есть небольшие проекты на стеке NextJS + ORM, и стек отрабатывает на все 100% даже в энтерпрайзе. Вот только рекомендую использовать не Prisma а TypeORM. Тем самым избавите себя от необходимости написания лишней абстракции. В TypeORM вы сразу описываете модель с логикой, по ней генерируется база и миграции. Так же из коробки получается репозиторий для сущности.
Native AOT шикарная тема если сравнивать с Go. У Go было преимущество маленький размер приложений, что удобно в утилитах. В шарпе приходилось качать весь рантайм, в т.ч. в контейнер. Теперь в C# приложения такие же маленькие как и в Go, и контейнеры станут много легче. Go можно выкидывать.
Вы не видите этот текст. * промазал
А там альтернатив то и нету.
Жду статьи =)
Про неповоротливость ты не прав, потеря на инициализацию всего 10-20%. Зато почти двухкратный прирост по скорости рендеринга. Так что неповоротливый тут голый CSS =)
Мое портфолио убеждает меня что с версткой у меня проблем все таки нет. Без проблем верстаю и однодневные лендинги и десятилетние энтерпрайзы. И пиксель перфект и все экраны. А ты умеешь в пиксель перфект? Или на глазок верстаешь ? ))
Tailwind - это новый бутстрап. Мусор который сейчас генерируется тоннами. Пройдет всего пару лет и от него все будут шарахаться как от бутстрапа в 2019-ом.
Пример с кнопками взят из MUI. Кстати он написан на аналоге SC, библиотеке emotion. В той кнопке цвета меняются местами в зависимости от варианта кнопки. А это строго переменные CSS или JS.
Что бы уйти от SC надо к нему с начало прийти =)
Надо понимать что SC распространен только в мире React. Angular и Vue разработчикам он не доступен. Да и в мире React он распространен только на 25% примерно. У многих он вызывает религиозную неприязнь, что ожидаемо сказалось на карме статьи.
А от рантайме уходить очень не удобно, потому что динамические стили часто сильно упрощают работу.
Кстати вспомнил. В статье целый раздел забыл =)
Бывают стили написанные следующим образом:
SC тут сильно выручает, в нем достаточно написать стиль один раз, а значения расставлять уже в верстке на элементы пропсами.
Я думаю они научаться без проблем работать вместе.
Мы то же оптимизируем.
https://habr.com/ru/company/ru_mts/blog/645305/
Только механизм чуть более хитрый. В дом ничего лишнего не генерирует. Но картинку запрашиваем в зависимости от размера экрана. В итоге выигрыш до 10 раз доходит по размеру картинок на странице.
Этот инструмент сильно упрощает написание стилей. Судя по вашим словам ваша задача лежит за пределами написания стилей.
А ваша задача решается двумя способами. Либо компонент в пропсах принимает какие то кастомные элементы, которые подменяют дефолтные. За пример можно посмотреть MUI. Либо делать две независимые библиотеки.
BEM приведен для примера как самый популярный подход написания компонентных стилей в CSS.
Но как же вы решаете проблемы удаления мертвых стилей, простой переход к CSS селектору, поиск используемых стилей при рефакторинге, изоляции стилей и остального без использования SC?
>> В каком окружении, на каком устройстве, в каком браузере?
Это был тест. 1000 рандомно сгенерированных стилей и 1000 элементов на странице. Браузер Chrome. Процессор Ryzen 5800X.
>> Как решить задачу в случае styled components без пересборки бандла компонента?
На самом деле крайне странно слышать про пересборку SC с учетом того что это фактически JS и он полностью динамический в отличии от CSS.
Для решения задачи есть два варианта:
SC не лишает вас ничего из того что у вас есть в CSS. Поэтому можно использовать все те же CSS переменные =)
Но почему конкретно я не использую CSS переменные во встраиваемых модулях. Есть такой антипаттерн - Глобальные переменные. Фронты уже поняли что в JS его использовать плохо, но почему то не поняли что в CSS переменных его использовать все так же плохо. А CSS переменные это глобальные переменные.
В комментариях выше уже писал пример как я уже ловил багу из-за конфликта CSS переменных. Как эту проблему помогает решить SC? Значения в CSS назначаются через изолированные JS переменные.
Компонент пишется следующим образом:
А кастомизируется на стороне клиента следующим образом:
Это упрощенный пример, но передает суть. При таком раскладе нету ни малейшего шанса на конфликт переменных.
Отчасти да. Но...
Был кейс когда в проект встраивались два микрофронтеда с использованием одной и той же UI библиотеки на CSS переменных. В одной библиотеке эти переменные были переопределены и что привело к конфликту CSS переменных со вторым микрофрондендом. Пришлось тратить время что бы выкрутиться из конфликта. В Styled Components такая ситуация невозможна в принципе.
Пример с кнопкой наверное слишком простой, но и с CSS переменными вы там на мучаетесь. У меня есть компонент Grid. Что бы он соответствовал сетке из Figma пришлось писать логику. В Figma сетка на десткопах имеет 12 колонок, планшетах 8 колонок, на мобилках 2 колонки. А еще 6 брекпойнтов по размеру экрана. А еще есть сетки вложенные в сетки. Например сетка с колонками 3 и 9, в 9 вложена сетка еще на 9 колонок. А еще в дефолтном положении она имеет 12 колонок. И в таком кейсе вам никакие CSS переменные не помогут. Styled Components справился с задачей идеально, на все расчеты уходит 1 наносекунда.
Сейчас прям полноценного мониторинга нету. С клиентов метрики собираем через гугл аналитику, включая WebVitals. Контейнеры с nextjs и nestjs метрики собираем через prometheus.
Собираемся сделать полноценный мониторинг клиентов через WebPrometheus. Как выведем в опенсорс напишу подробную статью про наш мониторинг клиентов.
Конкретно на этом проекте бекенд не мой, а фронтендовые микросервисы совсем не общаются между собой. На проектах где бекенд мой, микросервисы общаются через rabitmq.
Экземпляров можно запускать сколько угодно. Конкретно у нас запущено по 3 штуки для обеспечения высокодоступности.
Деплой настроен автоматический. При заливании в дев микросервис деплоется на внутренний дев стенд, при заливании в мастер деплоится в продакшен.
Паплайны разделены на две части. Первая это сборка контейнера и доставка в приватный репозиторий. Как правило их делают разработчики, но может сделать и девопс. Вторая это раскатка конфига по контуру. Здесь используется концепция GitOps, когда конфигурация прописана в гите и раскатывается по контурам из гита. За эту часть отвечает девопс.
Инфраструктурой в МТС занимается отдельная большая команда. Они отвечают и за надежность, мониторинг, уязвимости и остальное.
Если говорить о тех кто программирует, то это 4.5 фронтендера и 3 бекендера.
Постараюсь в первом квартале сделать статью про микрофронтенды =)
Да. Любые изменения в коде проходят через регресс. После разработки задача попадает тестировщику. Только сейчас тестировщик прибегает к помощи разработчиков для тестовой рассылки, а перейдем к процессу когда тестировщик сможет протестировать без участия разработчика.
А чем SSR: universal лучше чем то что предлагает next?
У меня тоже есть небольшие проекты на стеке NextJS + ORM, и стек отрабатывает на все 100% даже в энтерпрайзе. Вот только рекомендую использовать не Prisma а TypeORM. Тем самым избавите себя от необходимости написания лишней абстракции. В TypeORM вы сразу описываете модель с логикой, по ней генерируется база и миграции. Так же из коробки получается репозиторий для сущности.
Native AOT шикарная тема если сравнивать с Go. У Go было преимущество маленький размер приложений, что удобно в утилитах. В шарпе приходилось качать весь рантайм, в т.ч. в контейнер. Теперь в C# приложения такие же маленькие как и в Go, и контейнеры станут много легче. Go можно выкидывать.