Шейдеры на css, позволяют наглядно сравнить все каком браузере самый производительный рендер css. (Мобильный Chrome у меня вылетает через 3 минуты), тыц

Соус с описанием зачем это вообще понадобилось делать

Пару недель назад сталкивался с проблемой что сервис упорно не хочет общаться с curl не смотря на то что я повторяю запрос в том виде в котором это делает браузер (используя copy as curl). Думаю теперь я знаю почему! Разница есть в TLS хендшейке

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

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

А знаете ли вы что есть такая такая спека - WebAuthn,
и она уже поддерживается на 93% устройств?

Если очень коротко - она позволяет логиниться вместо пароля с помощью:
- сканера отпечатка пальца
- nfc ключа
- usb ключа

Как вам? Заинтересовал?
Вот тут можете побаловаться,
а вот тут почитать как это работает и как добавить себе такое

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

Одна из таких фич - shadow-parts (поддерживается в 92.15% браузеров на данный момент).

Что-бы понять что это такое и зачем нужно - давайте представим что у нас есть ui-kit.

Обычно в ui-kit-aх есть проблема - можно стилизовать тему, но отдельные элементы - проблематично.
В лучшем случае приходиться добавлять свой css поверх китового, чтобы переопределить те или иные стили.

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

Чтобы такой проблемы не было - нужен контракт, который ограничит что менять можно, а что нельзя.

Когда дело доходит до реализации - такой контракт обычно выглядит как много опциональных параметров для каждого компонента. Из них в рантайме генерируется стиль, благо css-in-js позволяет.
Заплатить за это приходиться а) перфом и б) раздутой апи компонента.
Вариант по-лучше (имхо) - дать пользователю возможность передать свои классы для важных частей компонента.

Но, если у вас кит из вэбкомпонентов - появляется еще одна опция - разработчик кита может описать какие части можно стилизовать, обозначив их и дав названиe c помощью атрибута part,

<div part="some-part">

а пользователь - стилизовть их прямо из css - никаких доп свойств передавать больше не нужно!

kit-component::part(some-part) {
  color: red;
}

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

Сделал вам демку:
https://jsfiddle.net/akiyamka/a5L4xezb/54/

Есть такой проект verdaccio - ваш собственый npm репозиторий. Причем он zero-config и как вариант - поставляется завернутым в докер - т.е. установил - и работает.
Конечно же он умеет работать как прокси к другим репам (включая npmjs.org).

Зачем оно надо?
Вот пару кейсов:
- ни разу не публиковали пакет в нмп, а хочется на чем-то потренероваться
- в вашей организации трудно получить доступ наружу, а хотя-бы свои пакеты хочется юзать между проектами безпрепятственно
- плохой интернет, или npm падает в неподходящее время - как кэширующий слой npm (и хотя счас у кажого пакетного менеджера есть свой кэш, они не умеют им делиться)
- сделали временный форк пакета, а из гитхаба вы его поставить не можете потому что он билдитися при паблише
- как единая точка входа. Например у вас пакеты из github packages постепенно переносятся в npm, или наоборот (миграция), чтобы не менять в каждом проекте что откуда брать каждый раз

Ниже пару демок

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

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

Впрочем, количество легаси в коде браузервов тоже проблема.
Много лет в них пытаются сделать <select> поддающийся стилизации (казалось бы, что может быть проще) - но идет очень туго - из 36 найденых блокирующих issue осталось еще 16

Когогенерацией реакт компонентов из фигмы сегодня никого не удивишь.
А что если не только реакт компонентов. А для любого фреймворка? А что если можно будет попросить использовать определенную UI либу, например tailwind?
И наконец, что если можно будет генерировать код с учётом правил и утилит которые уже есть в вашем репозитории?
Вот это уже совсем другой разговор, и кажется это наконец сделали (по крайней мере в рекламном ролике)