gram news
SuperOleg dev notes channel avatar

SuperOleg dev notes

@super_oleg_dev

Обзоры новостей и статей из мира frontend, интересные кейсы, исследования и мысли вслух https://github.com/SuperOleg39 https://twitter.com/ODrapeza @SuperOleg39

ProjectsRUProgramming

1,740subscribers

Open the Channel

Latest posts

  • SuperOleg dev notes

    10 Sept, 16:29

    Посмотреть на работу анимаций и скролла можно в нашей демке, основанной на примере Remix фреймворка - https://github.com/tramvaijs/tramvai/blob/main/examples%2Fview-transitions%2Fsrc%2Findex.ts
    165video1Open in Telegram
  • SuperOleg dev notes

    10 Sept, 16:25

    Далее, про скролл.В принципе для SPA-приложений это база, если при переходах на разные страницы мы не хотим оставаться в одной позиции скролла, нам нужно самостоятельно скроллить вверх страницы.Кажется есть функционал во всех роутерах и мета-фреймворках, и как отдельные либы.В Tramvai был старый модуль, который умел вызвать scroll top или к якорю, с логикой что бы срабатывал строго один раз после перехода.Из коробки проблема опять таки при браузерных back/forward, в этих случаях мы хотим восстановить позицию скролла, а не сбросить ее наверх.И конечно кейсы с виртуальными списками / пагинацией, но это уже немного out of scope, кажется тут лучше якорей ничего нет.Но мы словили ещё интересную проблему: - у страницы очень тяжёлый рендер - браузер детектит soft navigation до отрисовки и делает восстановление скролла - наш автоскролл не попадает в этот paint и у пользователя
    GitHubtramvai/packages/modules/autoscroll/src/components/ScrollRestoration.tsx at main · tramvaijs/tramvaiA modular framework for universal JS applications. Contribute to tramvaijs/tramvai development by creating an account on GitHub.
  • SuperOleg dev notes

    10 Sept, 16:05

    Раз уж меня прорвало, вспомню ещё один интересный кейс.Решали примерно в одно время две проблемы: - кастомизация view transitions - восстановление скролла при переходах с VTС view transitions кастомизацией основная трудность была в back/forward переходах через браузерные кнопки и жесты, которые роутер видит по факту события popstate.Соответственно тут разработчик не может задать конкретный view transition type для перехода назад или вперёд, добавляются только встроенные в Tramvai types.Но, допустим мы листаем галерею, каждый элемент это роут. Тогда нам нужна анимация слева-направо как при прямых переходах на предыдущий слайд так и при back переходах с последующих слайдов (то есть зеркальная).В итоге получилось достаточно изящно решить проблему: - добавлен отдельный tapable хук который возвращает VT types для текущей навигации - возвращаемое значение разработчик может
    tramvai.devView Transitions | tramvaiOverview
  • SuperOleg dev notes

    10 Sept, 13:32edited

    Вместо тысячи слов, пример работы и сразу разметка, которая долетает в HTML - и наш механизм, и React досылает разметку suspended компонентов
    400video54Open in Telegram
  • SuperOleg dev notes

    10 Sept, 13:11edited

    Когда-то давно рассказывал про интеграцию стриминга и deferred загрузки данных в Tramvai - https://t.me/super_oleg_dev/136У этого механизма была проблема:Все пользователи обычно заводят сторы для данных, и обновляют их в Actions после загрузки данных.Но, если экшен больше не блокирует ответ пользователю, значит initial state мы уже отправили на клиент, и dispatch(event) после завершения запроса к API работает впустую.При переходе на Deferred Actions пользователям приходилось рефакторить экшены, делать дополнительные client-only экшены с синхронизацией стейта с deferred данными из стрима.Выглядит страшно - https://tramvai.dev/docs/features/data-fetching/streaming-data/#manual-synchronization-alternativeИ наконец-то мы развили эту идею!Я называю это следуя моде state-over-the-wire 😂Принцип работы очень простой: - если экшен deferred - и первый ответ пользователю уже ушел -
    TelegramSuperOleg dev notesПривет! Релизнули экспериментальный функционал с Deferred экшенами. Сделал темплейт где можно потыкать результат - https://codesandbox.io/p/sandbox/tramvai-deferred-actions-s95q62 Экшен выполняется 1 секунду, время рендера компонента который зависит от…
  • SuperOleg dev notes

    7 Sept, 13:54edited

    TIL, небольшой, но интересный кейс!Делал кастомный анализ бандла через Claude, пишет мне слишком большой размер пакетов по сравнению с bundle-analyzer и Statoscope.Набор пакетов общий по смыслу, речь идёт о 50+kb gzip кода.Попросил копнуть глубже, и явно выделить дубликаты - показывает дубли каждого пакета!Но: - в локфайле все ок, пакеты по одному экземпляру - в Statoscope все аналогично хорошоИ только потом я замечаю, что пакет один, но в бандл попали и CJS и ESM версии модулей 😭Оказывается, один промежуточный пакет поставляется только в CJS, и затягивает поддерево CJS модулей тех пакетов, что вообще-то корректно поставляются и попадают в бандл в ESM версиях.Вот такой вот dual package hazard, пишите в тред если знаете тулзы как такое быстро находить.
    674133Open in Telegram
  • SuperOleg dev notes

    17 Mar, 21:37

    Нет ничего интереснее на ночь глядя чем почелленджить новые SSR бенчмарки!https://x.com/i/status/2034017554994225595
    X (formerly Twitter)Matteo Collina (@matteocollina) on XI’ve found a discrepancy between the tests, where Tanstack had compression disabled, while the others had it enabled. Me and the few people that reviewed it all missed it 🙈😰. I’ll rerun and upd…
    1,82033Open in Telegram
  • SuperOleg dev notes

    12 Mar, 22:00

    Ещё из интересного, в ближайшем будущем будет поставлена точка в спорах вокруг масштабируемости подхода Vite с загрузкой модулей приложения в режиме разработки без бандлинга.В принципе то что загрузка тысяч модулей в браузере на старте плохо масштабируется, это факт, даже при использовании HTTP/2, это было наглядно ещё при живом Snowpack.Но в issues/тредах по теме позиция мейнтейнеров Vite зачастую в стиле - у нас все нормально, обновитесь стало ещё быстрее.Теперь же rolldown открывает возможности бандлинга зависимостей в development режиме (как все эти наши pack'и), что уже показывает лучший перф и в будущем это станет дефолтом - https://v7.vite.dev/guide/rolldown#why-introducing-a-full-bundle-mode
    vitejsRolldown IntegrationNext Generation Frontend Tooling
    2,18091Open in Telegram
  • SuperOleg dev notes

    12 Mar, 21:51edited

    Не самая свежая новость, но релиз Vite напомнил про крутой эксперимент в Oxc как ускорить работу JS плагинов и не терять профит от Rust тулинга, как я понимаю идею в нескольких предложенях: - вместо сериализации AST как json, гоняем между rust и js напрямую ссылки на участки памяти - на стороне js работаем с Buffer - пишем десериализатор этого AST на js который работает очень быстро так как простой и мономорфныйНюансов конечно много, и для меня фронтендера звучит как чернокнижная магия, в любом случае очень рекомендую к прочтению - https://github.com/oxc-project/oxc/issues/2409Также напомнило подобный подход в Deno - https://marvinh.dev/blog/speeding-up-javascript-ecosystem-part-11/
    GitHubFaster passing ASTs from Rust to JS · Issue #2409 · oxc-project/oxcCurrently OXC's parser is extremely fast, but using it from NodeJS is not. The primary cause is the overhead of the JS/Rust boundary - specifically serializing/deserializing large AST structure...
    1,69012Open in Telegram
  • SuperOleg dev notes

    29 Dec 2025, 18:14edited

    Забыл еще про один небольшой кейс в этом наборе оптимизаций.На старте cli проверяем текущую версию yarn, а уже для v1 и для berry у нас разные обертки для работы с зависимостями.Проверка сделана через child_process.execSync, вызываемая команда - yarn -vЗанимает этот вызов в итоге 300-600ms у v4 yarn, асинхронный exec ситуацию не исправил и как будто бы даже замедлил в сумме.В качестве воркэраунда добавил сначала проверку на наличие поля packageManager в package.json приложения - должно быть в любом проекте с corepack.Вроде бы все низковисящие фрукты собрал.
    1,89053Open in Telegram
  • SuperOleg dev notes

    29 Dec 2025, 17:48edited

    Занимался сейчас оптимизацией времени старта @tramvai/cli, и самый популярный паттерн такой: - снять CPU profile - найти самые тяжелые CJS require вызовы - если импортируемые пакеты не используются, заменить обычный import в начале файла на require(lib) по месту вызоваБуквально несколько тяжелых импортов зря занимали 500-1000ms на старте скрипта, очень эффективная и простая оптимизация, хоть и требует ручной работы + смешивать CJS + ESM.Есть классный пропозал с defer import - https://github.com/tc39/proposal-defer-import-evalНо проблема та же, что вручную надо определить, что нам требуется не сразу.Плюс запустить это можно только на собранном через бандлер коде на данный момент - https://webpack.js.org/configuration/experiments/#experimentsdeferimportЕще одна приятная оптимизация - замена require('date-fns') на require('date-fns/format'), минус 350ms - кажется бесполезный
    Image from a post by SuperOleg dev notesImage from a post by SuperOleg dev notes
    1,650145Open in Telegram
  • SuperOleg dev notes

    27 Dec 2025, 19:04

    forwarded from @iamakulov_channel

    Что ещё 😑 Потратил на это выходные, поэтому сэкономлю их вам:Оказывается, когда вы открываете девтулзы в Chrome, таймеры (и любые другие нативные функции — fetch, requestAnimationFrame и т.д.) становятся в 5-100 раз медленнее. Это происходит вне зависимости от того, делаете ли вы что-то в девтулзах или нет — достаточно того, чтобы они были открыты.Это проблема! Перформанс обычно измеряется с открытыми девтулзами. Из-за того, что таймеры в этом режиме кажутся дорогими, TanStack Query, например, имплементировал целое API, чтобы менеджить таймеры, а Сергей Гарин ушёл даже дальше и почти переписал таймер-менеджмент целиком.Мини-тред с исследованием (где в конце приходит Пол Айриш из Google и говорит, что все мы делали всё это зря): раз, два, три
    1,1401142Open in Telegram
  • SuperOleg dev notes

    27 Dec 2025, 19:04edited

    Встречал на практике кейс с десятками запросов на старте, где каждый fetch занимал 2-4 синхронных миллисекунды, и в сумме это казалось прям катастрофой. А оказывается это может быть лишь оверхэд на девтулзы...
    1,420943Open in Telegram
  • SuperOleg dev notes

    22 Dec 2025, 14:53

    Интересный драфт появился в Undici (современный встроенный в Node.js клиент для запросов) - реализация паттерна Circuit Breaker - https://github.com/nodejs/undici/pull/4700/По сути, сейчас Undici закрывает практически все кейсы, которые мы хотим видеть для эффективных серверных запросов: - кэширование запросов - дедупликация запросов - ретрай запросов - проксирование и поддержка переменных окружения http_proxy/no_proxy - переиспользование tcp сокетов (из коробки, а с http.request для этого нужно прокидывать явно Agent с keepAlive: true) - dns кэширование - circuit breaker - мониторинг/логирование через diagnostics_channelМы как раз активно мигрируем на undici.fetch в Tramvai на замену node-fetch, и это уже вылилось в несколько небольших доработок в undici: - мониторинг кэша - https://github.com/nodejs/undici/pull/4589 - мониторинг прокси - https://github.com/nodejs/undici/pull/4659 -
    GitHubfeat: add circuit breaker interceptor by mcollina · Pull Request #4700 · nodejs/undiciSummary Adds a per-host/route circuit breaker interceptor for resilient HTTP client behavior. Features Three circuit states: CLOSED (normal operation), OPEN (fast-fail), HALF_OPEN (testing recover...
    1,6701383Open in Telegram
  • SuperOleg dev notes

    11 Dec 2025, 22:01

    Обновляем React ещё разок если проекты в зоне риска - https://react.dev/blog/2025/12/11/denial-of-service-and-source-code-exposure-in-react-server-components
    react.devDenial of Service and Source Code Exposure in React Server Components – ReactThe library for web and native user interfaces
    2,120153Open in Telegram
  • SuperOleg dev notes

    4 Aug 2025, 14:34

    Привет!Достаточно давно делился статьей где описывал различные механизмы и подходы которые мы применяем для SSR приложений на Tramvai (сейчас доступна на хабре).Один из механизмов - Request Limiter, модуль который ограничивает количество параллельно обрабатываемых запросов при перегруженном Event Loop приложения, для возможности стабильно отдавать 2xx ответы и рендерить странички даже под большими нагрузками.Работает по похожим принципам с https://github.com/fastify/under-pressure, только не отбрасывает все запросы при нагрузке, а держит еще LIFO очередь что бы обеспечить большее количество успешных ответов без сильной деградации времени ответа.Когда переводили наши интеграционные тесты на 20 версию Node.js, начали падать нагрузочные тесты Request Limiter. Основная проблема - перестали быстро отвечать health-чеки приложения (а отзывчивые health-чеки и метрики очень важны и что
    2,79016127Open in Telegram
  • SuperOleg dev notes

    28 May 2025, 15:23

    Одна из классных идей в новой CLI - кастомные трейсы в формате Trace Event FormatИдея взята у Parcel, Rspack и Next.js, примеры: - https://parceljs.org/features/profiling/#tracing - https://github.com/parcel-bundler/parcel/blob/v2/packages/core/profiler/src/Tracer.js - https://rspack.dev/contribute/development/tracingНаписал кастомный трейсер поверх либы chrome-trace-event, пример API:const tracer = new Tracer();tracer.wrap({ event: 'event' }, async () => { await doSomethingAsync(); });Во вложении пример визуализации кастомного трейса на сборку и несколько ребилдов, в интерфейсе https://ui.perfetto.dev/. Очень удобно смотреть сколько времени занимают основные операции, какие блокируют друг друга, где произошла ошибка (трейсы пишутся на диск не в конце а все время жизни скрипта)В идеале - еще собирать более подробные трейсы по сборке через хуки бандлера.
    Image from a post by SuperOleg dev notesImage from a post by SuperOleg dev notesImage from a post by SuperOleg dev notes
    2,57010Open in Telegram
  • SuperOleg dev notes

    28 May 2025, 14:46

    И раз уж зашел разговор о CLI, поделюсь одной из актуальных задач - разработка обновленной @tramvai/cli (уже писал про это короткий пост)Во вложении - дизайн новой CLI, он уже претерпел ряд изменений, но основные концепции остались.Какие основные цели для новой CLI: - решить базовые проблемы с перформансом - основная, webpack MultiCompiler запускает все сборки в одном процессе, серверная и клиентская конкурируют между собой - реализовать удобную систему плагинов (и первым же новым плагином интегрировать rspack) - полностью разделить JS API и CLI API - сделать общий набор тест-кейсов, который будет удобно запустить с разными плагинами - вебпак+бабель, вебпак+swc, rspack - избавиться от легаси, улучшить отладку, упростить структуруИтак, основная техническая задачка тут - ускорение двух параллельных вебпак сборок.Тут очевидное решение - вынести их в worker_threads, что из коробки
    Image from a post by SuperOleg dev notesImage from a post by SuperOleg dev notes
    1,76063Open in Telegram
  • SuperOleg dev notes

    28 May 2025, 13:52edited

    Часто в интернетах пишут про NODE_COMPILE_CACHE и ускорение скриптов.Но добавляю к скрипту который запускает webpack сборку небольшого example приложения (соответственно считывает просто кучу модулей по пути, в том числе babel, его плагины и тд), и вижу либо отсутствие изменений либо ухудшение (штраф за формирование этого кэша).При отладке через NODE_DEBUG_NATIVE=COMPILE_CACHE, логи показывают успешное переиспользование кэша.У кого-нибудь есть успешный опыт интеграции NODE_COMPILE_CACHE?Также, пока писал пост понял что при сборе CPU profile в Node.js не вижу сколько эта компиляция в принципе занимает времени, в отличие от обычной performance вкладки в девтулзах клиентских приложений, где есть время Compile code / Compile script. Можно ли это собрать для Node.js скрипта?
    nodejs.orgNode.js — Node.js 22.1.0 (Current)Node.js® is a free, open-source, cross-platform JavaScript runtime environment that lets developers create servers, web apps, command line tools and scripts.
  • SuperOleg dev notes

    7 May 2025, 10:55

    А вот из снэпшота с продакшена, такой трейс что не сразу было понятно что его вообще можно раскрыть до конца и найти виновника.
    Image from a post by SuperOleg dev notesImage from a post by SuperOleg dev notes