Мне станет страшно ни когда мы начнем вместо кода хранить промпт, а когда таким образом переписанный претиер станет выдавать такие фиксы:

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

Нашел у нас в коде функцию форматирования отображения большого числа, подумал, повспоминал, есть же Intl.NumberFormat!

MDN мне с ним не особо помог, но в гугле сразу нашлась статья с нужным примером. Что бы попробовать разные варианты использования и сразу увидеть наглядный результат решил вспомнить вот что: https://observablehq.com/d/d0d9dc332f8842c6

Толку от этого SSR, если проблема в головах… Форма регистрации на https://practicum.yandex.ru/promo/events/b2b_motivation подгружается секунд 5, без какого-либо плейсхолдера или лоадера я просто смотрел в серый квадрат.

Как я хочу писать красивости на CSS и как приходится…

Чего мне не хватает в зоде, так это какого-то “parseExtends”
https://tsplay.dev/w6eMGW

Как же круто что ТС умеет выводить тип массива на основе push в цикле. Особенно удобно, когда нужно промапить что-то с условием, а использовать flatMap или доп filter с тайпгардом из-за перфа не хочется.

Зачем реатом во vue?

У нас там апдейты подъехали, стоит рассказать о мотивации.

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

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

- За счет первого пункта реатом можно использовать как ядро микрофронтовой системы, у нас уже есть адаптеры для vue, react, solid, svelte, и в разработке адаптеры для lit и angular.

- У реатома есть очень мощные примитивы для описания асинхронной логики, собравшие все самое лучшее с rxjs, redux-saga и TanStack Query. Тут впринципе альтернатив, вроде, нет.

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

Если стало интересно, вот видосики по реатому: https://www.youtube.com/playlist?list=PLXObawgXpIfxERCN8Lqd89wdsXeUHm9XU

Реакт и DOM на столько тяжелые, что биндиться к ним обсерваблами ничего не стоит: https://xn--r1a.website/reatom_ru_news/261

Интересно как это скажется на перфе vscode.

Подсветка кода на странице при помощи Custom Highlight API

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

Брамус показывает, как можно применять современный Custom Highlight API, чтобы не создавать span для стилизации в принципе. Это такая апишка, которая уже работает в Chrome 105 и Safari 17.2. И она позволяет при помощи JavaScript разбивать текстовые узлы на набор параметризированных токенов. Как это делать в JS, лучше смотреть в самой статье. Но зато в CSS всё становится сильно приятнее:

::highlight(important) {
    color: red;
    font-weight: bold;
}

::highlight(attr) {
    color: violet;
}

Имена хайлайтов как раз задаются в JS.

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

https://www.bram.us/2024/02/18/custom-highlight-api-for-syntax-highlighting/

Моя очередная попытка натянуть опыт МДС на подкаст про ИТ.

Просто напоминаю ^

А ведь тут много людей, которые даже не знают о @uderjs_announcce... Года не важны, рекомендую к прослушиванию все!

QuickJS?

AWS тут релизнул LLRT (Low Latency Runtime), который быстрый за счет использования QuickJS в качестве интерпретатора JavaScript. Но что это за движок и почему он такой быстрый? За этим стоит набор интересных историй!

Начинается все с Фабриса Беллара, невероятно продуктивного разработчика. Крайне рекомендую почитать небольшую заметку о нем: Фабрис Беллар: портрет сверхпродуктивного программиста. Кратко, это автор QEMU и FFmpeg. Если вы не знаете о первом, то хотя бы узнайте о втором, это самая популярная в мире тула для процессинга видео.

И вот, в 2019 Фабрис релизит QuickJS - микроскопический движок ЖСа для… встроенный систем. Ну там микроконтроллеры всякие. Так как же он оказался в лямбдах крупнейшего хостинга планеты? Дело в его фичах, а точнее функциональных особенностях и характеристиках.

По производительности он раз в 50 медленнее v8, но это если сравнивать с JIT режимом V8, которому еще нужно разогнаться, а так же аллоцировать памяти в столько же раз больше. Иными словами, QuickJS может запуститься и начать процессить код заметно быстрее, “up to over 10x faster startup”, в конечном продукте (среде исполнения), как заявляют в ридми LLRT. Учитывая, что лямбды часто содержат код простой логики фетчинга и проверки данных, большего и не нужно.

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

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

Но множество апишек там, конечно, не реализовано и не планируется, в силу нацеленности движка на минимализм. В LLRT пилятся свои биндинги и вот мне интересно, на сколько это профитнее bun.sh?