Dev News от Максима Соснова

How we made claude.ai 3x faster in two weeks Пользователи жаловались на проблемы с перформансом claude.ai и десктопного приложения Claude. Anthropic за две недели ускорили оба продукта примерно в три раза. Результаты двухнедельной работы (цифры — p75): - время до возможности печатать при свежей загрузке сайта: 3.1 с → 0.55 с - новая сессия Claude Code: 0.8 с → 0.3 с - загрузка облачной сессии Cowork: 2.6 с → 0.73 с Как и что они делали. Во-первых, взяли 4 основных пользовательских сценария, скорость которых оптимизировали: - Открыть приложение - Начать чат - Открыть старый чат - Отправить сообщение Сам процесс оптимизации примерно следующий: - В Slack создаётся тред с агентом, где разработчик ставит задачу по оптимизации - Агент исследует, находит проблемы, приносит решения. Человек их смотрит - Все проблемы и решения сначала подтверждаются локально: сначала формируется перформанс-бенчмарк, который красный на текущем коде, а после фикса должен стать зелёным - Если чего-то не хватает — агент дополнительно инструментирует код - Рискованные изменения раскатываются не сразу на всех пользователей, а поэтапно Сами оптимизации и исследование достаточно сложные. Я бы сказал, что ни я, ни кто-то из моих коллег так глубоко бы не копал, чтобы ускорить сайт. Чтобы понять, почему я так считаю, достаточно взглянуть на то, что сделано в рамках исследования проблем. Замер обычного времени выполнения и отрисовки плавает в зависимости от нагрузки CPU, сети, GC и других факторов. Поэтому анализ делался на следующих метриках: - Количество инструкций CPU, которые понадобились для прохождения сценария - Количество вызовов функций JS - Коммиты React - Пересчёт стилей - Мутации DOM Чтобы сделать тесты на инструкции CPU детерминированными, гоняли Node с флагом --predictable: одно и то же выполнение даёт одинаковое расписание GC и компиляции, поэтому число инструкций стабильно от прогона к прогону. Также обычных метрик кое-где не хватило. Например, CLS не ловил дёрганье сайдбара, поэтому добавили свои события через Layout Instability API. Отдельно собрали стенд Chrome на 120 Hz, чтобы убедиться, что отрисовка стрима длинного ответа не проседает ниже 120 fps. Что сделано в рамках улучшения перформанса: - Пока React не инициализировался, поле ввода уже доступно как статический HTML. Затем React рендерит приложение поверх без миганий, потери ввода и сдвигов лейаута (отдельными тестами проверяют, что нет сдвига ни на пиксель) - Нашли селектор :root:has(), из-за которого каждое изменение DOM вело к лишним 24 мс пересчёта стилей - Удалили забытый location.reload() — он давал около полумиллиона скрытых перезагрузок в день, которые обычные load-метрики не видели - Подсветка кода зависала примерно на секунду из-за em dash: любой non-Latin-1 символ клал всю строку в UTF-16, и regex шли по медленному двухбайтовому пути. Фикс на 20 строк — скопировать блок кода в однобайтовую строку до подсветки - Зашили code cache V8 в десктопное приложение, чтобы приложик сразу работал с байткодом, а не компилировал JS каждый раз при открытии - После ускорения обнаружили кейс с пререндером. Когда в адресной строке вводишь сайт, Chrome уже рендерит страницу в фоне, но может сделать это не с той высотой (на корпоративных устройствах часть высоты пустого таба забирает плашка «браузер управляется политиками компании»). До ускорения рендера этого не замечали, после ускорения — пришлось фиксить Чтобы не было деградации, перформанс-бенчмарки повесили в CI — так меньше шансов потом уронить скорость. Как итоги: - Ускорение в 3 раза - 3000 мерджей - 200 изменений в день - 150 тредов с агентом Ну, а в целом итог такой: - Раньше ускорение сайта это была работа на недели, а то и месяцы и с результатом можно было идти с докладом на конференцию - Теперь достаточно оплатить подписку для любого агента и он за короткий срок сделает тот же результат, что делает человек за месяц работы https://claude.dev/blog/how-we-made-claude-ai-faster #development #performance #claude #ai #frontend #observability

Дайджест за 2026-09-07 - 2026-09-09 Playwright v1.62.0 Вышел релиз Playwright 1.62. Обычно я не пишу про релизы Playwright, но тут важное событие — допилили component testing. Текущее решение чем-то похоже на описание компонентов для Storybook. Mobile View — see your site on desktop & mobile at once Расширение для Chrome от подписчика — Mobile View. Позволяет легко посмотреть, как сайт выглядит на мобильном устройстве, в разных ориентациях, со снятием скриншотов, видео и прочими фичами. Можно запустить сразу 5 эмуляций в рамках одной сессии. Попробовал сам — выглядит действительно супер удобно и прям красиво. —————————————— Спасибо что читаете, ставите реакции, отмечаетесь в комментариях и рассказываете о канале друзьям и коллегам.

Mobile View — see your site on desktop & mobile at once Расширение для Chrome от подписчика — Mobile View. Позволяет легко посмотреть, как сайт выглядит на мобильном устройстве, в разных ориентациях, со снятием скриншотов, видео и прочими фичами. Можно запустить сразу 5 эмуляций в рамках одной сессии. Попробовал сам — выглядит действительно супер удобно и прям красиво. Это, конечно, не полноценный симулятор, но решение очень хорошее как для тестирования, так и для демонстрации. Строго рекомендую хотя бы ознакомиться. https://mobileview.app/ #development #chrome #tools #responsive #frontend

Playwright v1.62.0 Вышел релиз Playwright 1.62. Обычно я не пишу про релизы Playwright, но тут важное событие — допилили component testing. Текущее решение чем-то похоже на описание компонентов для Storybook. Забавно, что инструкция по установке начинается с «запустите LLM». Буквально. > Step 1: Point your coding agent at the skill

npx playwright init-skills

Set up component testing using the playwright-component-testing skill.

Затем надо немного сконфигурировать конфиг Playwright. Затем создать давно знакомые нам stories-файлы src/components/Button.story.tsx

import { Button } from './Button';

export const Primary = () => <Button title='Submit' />;

export const Disabled = () => <Button title='Submit' disabled />;

Т.е. по сути один в один истории Storybook. Интересно, не будет ли конфликтов? Пока выглядит, что Playwright-сборка должна будет уметь обрабатывать и исполнять все плагины и декораторы Storybook, либо придётся как-то делить истории Storybook и истории Playwright. Затем пишем тесты

import { test, expect } from '@playwright/test';

test('renders primary button', async ({ mount }) => {
  const component = await mount('components/Button/Primary');
  await expect(component.getByRole('button')).toHaveText('Submit');
});

test('disabled button is disabled', async ({ mount }) => {
  const component = await mount('components/Button/Disabled');
  await expect(component.getByRole('button')).toBeDisabled();
});

Затем запускаем

npx playwright test --project=components

В доке также описаны ещё основные паттерны для тестирования. На них останавливаться не буду. Надо будет попробовать в своём пет-проекте. https://github.com/microsoft/playwright/releases/tag/v1.62.0 #development #playwright #testing #component-testing #releaseNotes

Дайджест за 2026-08-31 - 2026-09-04 How to find a Next.js memory leak in production Очень хорошая и практичная статья про утечки памяти в Next.js. Чел рассмотрел 3 утечки (которые уже исправлены — поэтому обновляйтесь) и то, как их правильно диагностировать. Canvas UI Canvas UI — open-source библиотека готовых компонентов для создания красивых эффектов на основе технологии html-in-canvas, которая пока что включена только в Chrome и там за флагом. Эффект стекла, жидкости, VHS и другие готовые эффекты, оформленные как компонент, в который можно обернуть ваш HTML. Measuring soft navigations Web Vitals стали основным мерилом скорости работы сайтов. Но при этом Web Vitals плохо покрывают сценарии с SPA-переходами. Из-за этого почти никто не следил за скоростью работы сайтов при SPA-переходах. Но Google придумали методику для замеров SPA-переходов, и в новом Chrome за флагом доступны метрики Soft Navigations. —————————————— Спасибо что читаете, ставите реакции, отмечаетесь в комментариях и рассказываете о канале друзьям и коллегам.

Measuring soft navigations Web Vitals стали основным мерилом скорости работы сайтов. Но при этом Web Vitals плохо покрывают сценарии с SPA-переходами. Из-за этого почти никто не следил за скоростью работы сайтов при SPA-переходах. Но Google придумали методику для замеров SPA-переходов, и в новом Chrome за флагом доступны метрики Soft Navigations. Что определяется как soft navigation: 1. Действие перехода инициировал пользователь 2. Пользователь видит изменение URL 3. Есть видимое изменение (paint) Спека пока обсуждается, поэтому могут быть изменения. На странице очень подробно описано, какие изменения будут у записей в Performance API (новые типы Entry + navigationId для идентификации метрик каждой отдельной страницы), как их включить, обрабатывать и мониторить. Очень большой и подробный гайд. Ждём стабилизации. https://developer.chrome.com/docs/web-platform/soft-navigations #development #chrome #performance #web-vitals #spa #browser

Canvas UI Canvas UI — open-source библиотека готовых компонентов для создания красивых эффектов на основе технологии html-in-canvas, которая пока что включена только в Chrome и там за флагом. Эффект стекла, жидкости, VHS и другие готовые эффекты, оформленные как компонент, в который можно обернуть ваш HTML. Вместо тысячи слов лучше пройти по ссылке и посмотреть, как это выглядит. А выглядит это прям бомбически. Также в библиотеке предусмотрено graceful degradation для браузеров, где не включен html-in-canvas, но результат может быть хуже. https://canvasui.dev/ #development #webgl #canvas #ui #react #frontend

How to find a Next.js memory leak in production Очень хорошая и практичная статья про утечки памяти в Next.js. Чел рассмотрел 3 утечки (которые уже исправлены — поэтому обновляйтесь) и то, как их правильно диагностировать. Если ваше приложение использует Next.js версии между 15.5 и 16.2, то в них есть 3 задокументированных утечки памяти. Вот как их диагностировать: 1. Если утечка медленная и коррелирует с количеством уникальных урлов, которые обслужило приложение, то это утечка Router LRU-кеша 2. Если утечка пропорциональна трафику, то вполне вероятно это утечка дерева рендеринга 3. Если утечка не плавная, а ступеньками, а запросы обрабатываются через middleware, то это утечка айдишников таймаутов Немного подробнее про каждую утечку. №1: У роутера в Next.js есть LRU-кеш, и его размер ограничен одним мегабайтом. Но размер определяется некорректно. Собственно сами урлы и не учитываются, что даёт возможность для утечки на сотни мегабайт. Банально любой бот, который перебирает урлы, вызовет эту утечку. Если не можете обновиться — отфильтровывайте урлы до их обработки роутером Next.js. №2: Дерево RSC-рендера не освобождается, если клиент разорвал соединение. Утечка может достигать 2 МБ на 1 отменённый запрос (что вообще-то нехило). №3: У middleware отдельный TimeoutsManager, который хранит id таймаутов. id отпускается только если явно вызвать clearTimeout. А дальше интересный личный кейс автора. У него приложение крутилось как serverless на Vercel, поэтому вместо OOM он получал 504 FUNCTION_INVOCATION_TIMEOUT на tag-страницах блога. Автор провёл расследование. Сначала подозревал рендер MDX, но оказалось, что он достаточно быстрый — до 100 мс. Оказалось, что причина в функции, которая резолвила slug для страницы. Чтобы зарезолвить один единственный slug, функция грузила и парсила все посты для каждого слага, что давало квадратичную сложность и выливалось в 18 тысяч чтений с диска и 30 секунд на рендер. Фикс простой: вместо парсинга всех постов на каждый запрос — распарсить единожды и сложить в кеш на инстанс. Скорость работы после исправления: - next build: ~17.5 мин → 34 сек - prerender поста: ~32 сек → ~1.6 сек - on-demand tag page: 504 → ~134 мс Для поиска утечек автор собрал CLI `next-leak`, который автоматизирует диагностику. Также отдельно отмечу, что у автора очень красиво задизайнен блог. Не знаю, готовая ли это тема или он сам собрал — но выглядит очень красиво. https://xabierlameiro.com/blog/nextjs/nextjs-memory-leak-in-production #development #nextjs #memory #performance #debugging

Дайджест за 2026-08-24 - 2026-08-28 Check out the New Node.js API Documentation Preview Команда Node.js готовит новый сайт с докой. Контент не изменился, изменилась оболочка. Посмотреть можно тут: beta.docs.nodejs.org. When and what should I be logging? Sentry написали гайд «когда и что логировать». Гайд не прям чтобы открывал глаза на какие-то новые концепции, но как интро вполне норм. We Stopped Using RSC on TanStack.com История о том, почему на tanstack.com отказались от RSC. Сначала перешли на RSC и стало лучше, а потом поняли, что можно было оптимизировать изначальное решение — и тогда бы RSC не понадобился. —————————————— Спасибо что читаете, ставите реакции, отмечаетесь в комментариях и рассказываете о канале друзьям и коллегам. —————————————— Я работаю в Т-Банке и у нас идет активный найм. Если вам интересна работа в Т-Банке - переходите по ссылке и пишите в личку - отвечу на любые вопросы

We Stopped Using RSC on TanStack.com История о том, почему на tanstack.com отказались от RSC. Сначала перешли на RSC и стало лучше, а потом поняли, что можно было оптимизировать изначальное решение — и тогда бы RSC не понадобился. Как было. Есть сайт с докой, в которой используются тяжёлые библиотеки для рендера markdown и подсветки синтаксиса. Суммарно эти библиотеки занимали 358 КБ. Как сделали. Включили RSC, тяжёлые библиотеки остались на сервере, на клиент идёт сразу готовый рендер. И перформанс-метрики сразу подскочили. Но позже оказалось, что RSC несёт свои проблемы и неудобства. Затем инженеры подумали, что переход на RSC — это, возможно, было неверное решение. Перенесли рендер на бэкенд вместо того, чтобы оптимизировать сами тяжёлые зависимости. Что переделали. Взяли более лёгкие библиотеки, допилили их и вернулись на обычный SSR. Получили заметное ускорение работы + упрощение архитектуры. Какой итог: - RSC хорош для решения проблемы с «тяжёлым» кодом - Но он даёт сложность. Если есть вариант обойтись без RSC — стоит рассмотреть этот вариант. https://tanstack.com/blog/we-stopped-using-rsc-on-tanstack-com #development #react #rsc #tanstack #performance #ssr

When and what should I be logging? Sentry написали гайд «когда и что логировать». Гайд не прям чтобы открывал глаза на какие-то новые концепции, но как интро вполне норм. Итак, что надо логировать: Runtime decisions. В коде часто есть ветвление по различным условиям — по условиям типа isMobile, по фичефлагам. Вот все эти условия нужно логировать, чтобы понимать, как работал код в каждом конкретном случае. Например, логировать конфигурацию фичетогглов. Шаги в многошаговых фичах. Например, есть какой-то последовательный долгий процесс. В этом случае лучше логировать каждый шаг и его результат. Аудит. Если пользователь или система делает какое-то действие, необходимо логировать, кто и что сделал. Любые создания, обновления и удаления сущностей. Контекст вокруг ошибок. Недостаточно просто залогировать ошибку. Нужно логировать весь контекст, в котором она произошла — какой это был ретрай, какой статус-код, какой URL и всё остальное, что может помочь при дебаге. Как писать логи: Используй структурированные логи. Не просто строка в логах, а структура. Например, JSON-объекты. В идеале логи должны содержать ответы на вопросы «что произошло?», «кто это сделал?» и «когда это произошло?». Наращивай контекст логов. Сначала пользователь может быть неавторизован, но когда он авторизовался — его данные (userId, например) должны попадать в контекст последующих логов. Отдельно полезно делать связь логов через трейсинг. Что не надо логировать Избыточное логирование. Не надо логировать вызов всех функций и всех строчек кода. Секреты и персональные данные. Тут в целом всё понятно. Большой объём данных без чёткой цели. Тут тоже, думаю, понятно. Хотя, если бы не было проблемы с хранением и обработкой больших данных, то думаю, этого пункта не было бы. https://blog.sentry.io/logging-best-practices/ #development #logging #observability #sentry #best-practices

Check out the New Node.js API Documentation Preview Команда Node.js готовит новый сайт с докой. Контент не изменился, изменилась оболочка. Посмотреть можно тут: beta.docs.nodejs.org. https://beta.docs.nodejs.org #development #nodejs #documentation #dx

Дайджест за 2026-08-17 - 2026-08-21 postmortem.io · the library of real postmortems postmortem.io — каталог публичных engineering postmortems. Каждая запись — краткая выжимка (скорее всего через LLM) + ссылка на оригинал для ознакомления. Если вы связаны с SRE в любом его проявлении — можете использовать как справочник проблем + примеров хороших постмортемов. The secure way to release an npm package in 2026 Огромная статья от Evil Martians про то, как в 2026 публиковать npm-пакеты, чтобы их было сложнее угнать. В статье в самом начале есть чеклист, что надо сделать, чтобы снизить вероятность кражи пакета. А после чеклиста — почему именно важен каждый шаг и как выстраивается система защиты. npm publish-time malware scanning and dual-use metadata npm включает автоматический скан на зловреды в момент публикации пакетов, до того как пакет станет доступен для установки. —————————————— Спасибо что читаете, ставите реакции, отмечаетесь в комментариях и рассказываете о канале друзьям и коллегам. —————————————— Я работаю в Т-Банке и у нас идет активный найм. Если вам интересна работа в Т-Банке - переходите по ссылке и пишите в личку - отвечу на любые вопросы

npm publish-time malware scanning and dual-use metadata npm включает автоматический скан на зловреды в момент публикации пакетов, до того как пакет станет доступен для установки. Как это работает: - Вы публикуете пакет - npm сканирует его. Сканирование может идти до 15 минут для больших пакетов - Если всё ок — пакет будет доступен для скачивания - Если не ок — то либо будет ручное ревью, либо блокировка публикации - В случае блокировки пришлют уведомление. В худшем случае могут потребоваться действия с аккаунтом. https://github.blog/changelog/2026-07-28-npm-publish-time-malware-scanning-and-dual-use-metadata/ #development #javascript #npm #security #supply-chain #github

The secure way to release an npm package in 2026 Огромная статья от Evil Martians про то, как в 2026 публиковать npm-пакеты, чтобы их было сложнее угнать. В статье в самом начале есть чеклист, что надо сделать, чтобы снизить вероятность кражи пакета. А после чеклиста — почему именно важен каждый шаг и как выстраивается система защиты. В целом чеклист следует завету «не доверяй никому, кроме себя». Чеклист: 1. Trusted Publisher: укажите конкретный воркфлоу, с которого можно только публиковать staged-версии библиотек 2. Запретить публикацию через токены 3. Включить 2FA для всех 4. Дать возможность создавать теги в GitHub только админам 5. Зафиксировать версии GitHub Actions, которые вы используете 6. Добавьте автоматический линт безопасности 7. Установите 3 дня кулдауна на новые версии зависимостей 8. Используйте npm 12 или другой пакетный менеджер, который не исполняет postinstall-скрипты 9. Создайте workflow для публикации, как в статье Это не гарантия безопасности, но очень снижает риски того, что ваш пакет украдут. От каких конкретно рисков защита: 1. Trusted Publisher — разрешаем публикацию только конкретному воркфлоу 2. Запрещаем публикацию напрямую (без стейджинга) и через токены. Если токен украдут — опубликовать не смогут. Сам стейджинг гарантирует ручной апрув 3. 2FA требует подтверждения через второе устройство 4. Т.к. публикация только по тегам, то разрешаем создавать теги только админам 5. Фиксация версий GitHub Actions позволяет не попасться на взлом CI Actions 6. Линт безопасности автоматически проведёт основные проверки безопасности 7. Кулдаун 3 дня на новые зависимости даёт время обнаружить malware до того, как вы его подтянете 8. Запрет postinstall-скриптов убирает целый кластер атак 9. Аккуратный publish-workflow (без лишних deps в critical job) сужает поверхность атаки при релизе И, конечно же, в статье есть скилл для агента, который настроит всё за вас. https://evilmartians.com/chronicles/the-secure-way-to-release-an-npm-package #development #javascript #npm #security #ci #supply-chain #evilMartians

postmortem.io · the library of real postmortems postmortem.io — каталог публичных engineering postmortems. Каждая запись — краткая выжимка (скорее всего через LLM) + ссылка на оригинал для ознакомления. Если вы связаны с SRE в любом его проявлении — можете использовать как справочник проблем + примеров хороших постмортемов. https://postmortem.io/ #development #sre #devops #postmortem #reliability

Дайджест за 2026-08-10 - 2026-08-14 Announcing TypeScript 7.0 Вышел TypeScript 7.0 — нативный порт компилятора на Go. Ждали, и наконец дождались. TanStack Charts TanStack опубликовали ещё одну библиотеку — Charts. По названию понятно, что это библиотека для графиков. Investigating three real-world incidents in our cybersecurity evaluations Возможно, вы не слышали, но недавно модель OpenAI смогла выбраться из sandbox во время тестирования и взломать сервера Hugging Face. После этого инцидента Anthropic решили посмотреть, не было ли случайно у них таких кейсов. И оказалось, что были, но не такие мощные. —————————————— Спасибо что читаете, ставите реакции, отмечаетесь в комментариях и рассказываете о канале друзьям и коллегам. —————————————— Я работаю в Т-Банке и у нас идет активный найм. Если вам интересна работа в Т-Банке - переходите по ссылке и пишите в личку - отвечу на любые вопросы

Investigating three real-world incidents in our cybersecurity evaluations Возможно, вы не слышали, но недавно модель OpenAI смогла выбраться из sandbox во время тестирования и взломать сервера Hugging Face. После этого инцидента Anthropic решили посмотреть, не было ли случайно у них таких кейсов. И оказалось, что были, но не такие мощные. Anthropic проводят исследование возможностей моделей, ставя им задачу в стиле CTF: флаг спрятан на другой машине, найди и достань. Модели говорилось, что она работает в симуляции и интернета нет. Однако из-за мискоммуникации с партнёром (видимо, тем, кто давал инфру) интернет всё-таки был (и эти люди будут нас учить секьюрити). Поэтому из 141 000 запусков в трёх из них модель вышла в интернет и сделала что-то плохое. Кейс №1 В задании агенту дали название фиктивной фирмы и сказали, что флаг у неё. Однако, как говорилось выше, был доступ к интернету. А в интернете был вебсайт у одноимённой компании, который Claude и взломал — получил креды и доступ до продовой БД. Кейс №2 В задании агент нашёл док для онбординга, в котором сказано, что сотруднику надо ставить определённый пакет с PyPI. Claude решил опубликовать этот пакет в PyPI, завернув туда зловред. Зловред скачали, он украл креды, Claude ими воспользовался. Отдельно интересно, что Mythos сказал: если бы это был реальный мир — это НЕ ОК, но т.к. это симуляция, то ничего страшного. Кейс №3 Модель не нашла фейковую цель и пошла искать её в интернете. Просканировала 9000 хостов и взломала одно приложение, но поняла, что вышла за рамки задачи, и остановилась. https://www.anthropic.com/news/investigating-incidents-cybersecurity-evals #development #ai #anthropic #security #claude

TanStack Charts TanStack опубликовали ещё одну библиотеку — Charts. По названию понятно, что это библиотека для графиков. Что обещают из коробки: - Строгий TypeScript - Framework-agnostic ядро + адаптеры: React, Vue, Solid, Svelte, Angular, Preact и другие - SVG по умолчанию, Canvas опционально - Отдельно делают скиллы или инструкции для ИИ. Прямо на главной в общем-то можно скопировать какой-то промпт для агента, чтобы он собрал демо-график. https://tanstack.com/charts/latest #development #typescript #javascript #charts #tanstack #react

Announcing TypeScript 7.0 Вышел TypeScript 7.0 — нативный порт компилятора на Go. Ждали, и наконец дождались. Конечно же сразу идём смотреть цифры. По скорости тайпчека крупные проекты стали проверяться в 7–12 раз быстрее (TS 6 → TS 7): - vscode: 125.7s → 10.6s (11.9x) - sentry: 139.8s → 15.7s (8.9x) - bluesky: 24.3s → 2.8s (8.7x) - playwright: 12.8s → 1.47s (8.7x) - tldraw: 11.2s → 1.46s (7.7x) А если увеличить количество воркеров — можно выйти примерно на 16x. По памяти также есть улучшение, хотя и не такое заметное. Потребление памяти в этих же проектах падает на 5%-25%. Также и все фишки typescript стали работать быстрее — проверка конкретного файла, go to definition и другие. Отдельно радует фидбек разработчиков крупных компаний. Он одновременно хвалебный и показывает, какой же, извините, мрак у некоторых на проектах: - Slack: typecheck в CI с ~7.5 мин до ~1.25 мин, merge queue быстрее на 40% - Microsoft News Services: экономия 400 часов в месяц на ожидании CI - Canva: first error в редакторе с ~58 сек до ~4.8 сек В любом случае, проделана огромная работа, которая ускоряет один из важнейших инструментов для современной фронтенд-разработки. Это, конечно же, очень круто. Что ещё интересного в релизе: Я уже выше упоминал воркеров. Так вот, процесс тайпчека теперь идёт параллельно в 4 воркера по умолчанию, но можно сделать больше. Воркеры частично повторяют работу друг друга, т.к. у них изолированная память, но для разных целей может потребоваться работать с одними и теми же объектами. Поэтому для окружений, где нужно оптимизировать использование ОЗУ, можно оставить одного воркера. Для работы watch-режима сделали порт @parcel/watcher, который отлично себя показывает в vscode, на Go. Для кейсов, где важна совместимость с TS6, оставили отдельный бинарь с реализацией ts6. В частности, совместимость нужна тем, кто использует typescript через API, т.к. у ts7 его ещё нет (ждём в 7.1). Кто-то уже поставил себе? https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/ #development #typescript #javascript #tsgo #performance #releaseNotes