TGViewer
Настя Котова // Frontend & Node.js Настя Котова // Frontend & Node.js @startpoint_dev · 1.41K subscribers
Post #232 1.24K
В JavaScript регулярно появляются новые возможности, и не про все из них мы вообще узнаём. Так, недавно я познакомилась с using и await using. Мне не довелось их применять на практике, но выглядит это интересно.

Смысл в том, чтобы привязать освобождение ресурса к границам блока. Обычно, если мы открыли файл или установили какое-то соединение, то обязаны не забыть всё это закрыть. Сейчас такой код пишется через try/finally, и выглядит примерно так:


const file = await open('data.txt');
try {
const data = await file.read();
} finally {
await file.close();
}


Здесь важно, что open стоит до try. Если убрать его внутрь блока, переменную придётся объявлять снаружи через let, а в finally добавлять ?., потому что при падении open значения там ещё нет. С await using всё это пропадает:


await using file = await open('data.txt');
const data = await file.read();


Файл закроется при любом выходе из блока: при нормальном завершении, исключении, return, break или continue. Разница здесь не столько в количестве строк, сколько в том, что исчезает целый класс возможностей ошибиться.

Работает это с любым объектом, у которого есть метод Symbol.dispose для using или Symbol.asyncDispose для await using. Стандарт описывает только этот протокол, всё остальное остаётся на рантаймах. При этом переменная, объявленная через using, ведёт себя как const, то есть переприсвоить её нельзя.

С поддержкой ситуация уже вполне боевая. Предложение вошло в стандарт ES2026. Node.js поддерживает синтаксис нативно с 24-й версии, TypeScript — с 5.2. В последних версиях браузеров тоже всё работает.

Но дальше начинаются нюансы, из-за которых этот синтаксис так редко встречается в реальном коде. Самая главная причина в том, что встроенных объектов, реализующих протокол, пока очень немного. В Node есть FileHandle из fs/promises, так что тот самый пример выше работает нативно. Однако несмотря на то, что постепенно появляются новые disposable-объекты, список всё ещё короткий.

В браузерных API встроенных disposable-объектов практически нет. Поэтому на клиенте using — это инструмент для своих объектов, а не для чужих, например:


function observe(el, cb) {
const ro = new ResizeObserver(cb);
ro.observe(el);
return { [Symbol.dispose]: () => ro.disconnect() };
}


Второй нюанс касается сборки. TypeScript понимает синтаксис давно, но при target ниже ES2022 он требует, чтобы Symbol.dispose существовал в рантайме или чтобы использовался полифил.

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

Поэтому лично мой вывод: вещь полезная, но не универсальная. Её стоит держать в голове, но области применения пока ограничены.
  • 👍 30
  • 🔥 3
  • ❤ 2
  • 💅 2
More from @startpoint_dev
  1. Sep 21, 2026Я к вам с новым анонсом. Этот год я заканчиваю выступлением на HolyJS! Конференция пройдёт…
  2. Sep 14, 2026В прошлый раз разбирали, зачем нужны using и await using и где они работают. Теперь посмот…
  3. Aug 31, 2026В цикле про рендеринг мы разбирали конвейер: стили, лейаут, отрисовка, композитинг. Всё эт…
  4. Aug 24, 2026Весной мы обсуждали работу с сырыми данными: ArrayBuffer, Buffer в Node.js, SharedArrayBuf…
  5. Aug 17, 2026Когда я готовила материал для цикла про Next.js, то неожиданно для себя узнала, что в нём…
  6. Aug 10, 2026Заключительная часть цикла про Next.js наконец-то здесь! Обобщим всё, о чём говорили до эт…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →