Чего мне не хватает в зоде, так это какого-то “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?

Programmers Aren't Productive Anymore.

Очень странно слышать такую не объективную оценку. Конечно тулинг решает две задачи: предоставляет готовые решения и убирает легкую возможность сделать плохо.

A library is used by your code, a framework using your code.

Если вы не понимаете что success path / fail path соотносяться, в среднем, по тому самому закону Пареттор, то попробуйте сделать свой продукт.

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

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

И это нормально. Нужно дело делать, а не в фантазиях летать. Всем мечтателям - вам двери не закрывают, рынок очень открытый. Расскажите соседу с завода или фармы про культуру OSS, он у виска пальцем покрутит. А у нас работает.

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

Но если кому-то не хватает мотивации, можете, как я, на рабочий стол поставить:

https://excalidraw.com/#json=_62towD6HyCqoeDUok1CC,U5SbaYW8G-dIc7tver5B3A
(рамка подогнана под соотношение макбука, перед экспортом сделайте ее прозрачной)

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

В HTTP есть такой метод PRI (используются, если мне не изменяет память, чтобы проверить возможность HTTP/2 подключения). Нас интересует что запросы этого метода имеют cимвол * в пути, вместо привычного /.

PRI * HTTP/1.1.

Далее, все http-парcеры работают по разному, у nodejs он немного особенный, и url вида http://example.com:3456*@127.0.0.1:8080 будет разобран как:
hostname: 127.0.0.1,
port: 8080,
auth: example.com:3456*,
А самое важное тут то, что http-парсер nodejs считает валидными запросы вида:

GET *@127.0.0.1/ HTTP/1.1
Host: somehost

А знаете кто еще так делает - haproxy!

Ну и последнее: код который формирует url для проксирования внутрь nextjs выглядит так:

const targetUrl = `http://${
  targetHost === 'localhost' ? '127.0.0.1' : targetHost
}:${routerPort}${pathname}`

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

GET *@127.0.0.1:11211 HTTP/1.1
Host: some

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

Уязвимые версии:
>= 13.3.0 | <=13.4.12
фича проксирования включена по умолчанию, она так же включается если установлен флаг appDir: true в конфигурации experimental.


Из интересного: vercel отказал в CVE, так как не считает что это уязвимость (на момент репорта уязвимость воспроизводилась в последних версиях). Однако с версии 13.4.13 изменили код. Теперь в части внутренних запросов используется fetch. Что дает некоторую защиту, т.к. fetch не принимает запросы содержащие авторизацию.

>

10 лет :)

Ого какая новость пролетела мимо:
Vue опять нехило импрувнули перф реактивности (в этот раз поменяли структуры данных используемые внутри системы реактивности на манер сигналов Preact)

Это дало перф:
- на ~56% уменьшено потребление памяти системой реактивности 🤯
- случай когда 1 реф вызыввает несколько эффектов (+118%-185% прирост производительности)
- чтение множества invalidated computed-ов (+176%+244% прирост производительности)

Дополнительно:
- Обнова обещает никак не афектить поведение и вся реализация прячется лишь в @vue/reactivity
- Закрывает некоторые специфичные баги/корнер-кейсы для системы реактивности
- Компьютеды стали гораздо дешевле и теперь еще более ленивые
- теперь если компьютед не имеет подписчиков на него то он сбрасывает все свои зависимости
- компьютед теперь в целом не может иметь зависимостей если от него никто не зависит
- Противный варнинг из 3.4.19 о грязных компьютедах удален!
- Обещают что сборка мусора в режиме SSR будет работать лучше (как это будет аффектить в реальности пока неизвестно)

Для любителей копаться в тонкостях:
- Больше никакого ручного счедуллинга:
- pauseScheduling, pauseTracking, resetScheduling больше недоступны (впрочем они и не были задокументированной возможностью)
- теперь зависимости в deps это не Map/Set а самостоятельная структура Dep с версионированием и на базе двусвязанного списка
- код стал читаться как-то проще :D
- еще не копался на в Dev режиме включили какой-то трекинг по типу действия сигнала и как его трекают

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