Функції Node.js 26, які тихо замінюють роки використання обхідних шляхів

1. Ми нарешті можемо припинити вдавати, що Date — це справжній API дат

Ось звичайний JavaScript:

const date = new Date("2026-09-08");
console.log(date);

Тепер спробуйте відповісти на трохи складніше запитання:

Яка місцева дата зустрічі, яка відбувається у Нью-Йорку?

Або:

Додайте три місяці до цієї дати виставлення рахунку.

Або:

У чому насправді різниця між календарною датою та точним моментом у часі?

Саме тут Date починає не функціонувати належним чином.

Саме тому Temporal є настільки важливим.

Node.js 26 за замовчуванням увімкнує API Temporal, нарешті надаючи JavaScript окремі концепції для моментів, календарних дат, тривалостей та часових зон.

Замість того, щоб писати:

const date = new Date();

тепер ви можете писати:

const today = Temporal.Now.plainDateISO();

const invoiceDate =
  Temporal.PlainDate.from("2026-09-08");
const dueDate =
  invoiceDate.add({ days: 30 });

А коли вам справді потрібна точна мить у часі, а не календарна дата:

const now = Temporal.Now.instant();

Ця різниця має більше значення, ніж здається.

Системі билінгу насправді не потрібен „об’єкт Date у JavaScript“.

Їй потрібна дата з календаря.

Розподіленому журналу подій не потрібна „дата з календаря“.

Йому потрібна мить.

Тип temporal змушує вас чітко вказувати, який саме тип часу ви маєте на увазі.

Для всього, що стосується оплат, підписок, бронювань, ринків чи користувачів, які знаходяться в різних часових поясах, це — не просто краща синтаксис.

Це усуває цілу категорію помилок, коли ви використовуєте неправильний тип значення часу.

2. Ваш файл .ts не обов’язково потребує кроку компіляції

Протягом багатьох років використання TypeScript у Node означало таку послідовність дій:

app.ts
   ↓
TypeScript
   ↓
app.js
   ↓
Node

Цей підхід досі залишається абсолютно дійсним.

Але тепер Node може безпосередньо виконувати файли TypeScript, за умови, що вони використовують лише синтаксис, який можна стерти.

Візьмемо цей файл:

interface User {
  id: number;
  name: string;
}

function greet(user: User) {
  return `Hello ${user.name}`;
}
console.log(
  greet({
    id: 1,
    name: "Priyanshu"
  })
);

Його можна виконати безпосередньо за допомогою:

node app.ts

Node просто видаляє анотації типів та виконує залишений звичайний JavaScript.

Є важлива умова, яку варто повторити: Node не перевіряє типи за вас.

Тож для великої бази коду у продакшені вам все одно знадобиться tsc або еквівалентний крок перевірки типів у вашому робочому процесі.

Але подумайте про менші випадки: внутрішній скрипт, швидкий інструмент CLI чи утиліта з одного файлу.

Старий підхід виглядав так:

script.ts
   ↓
configure compiler
   ↓
compile
   ↓
run

Тепер він може виглядати так:

script.ts
   ↓
node

Це незначна зміна.

Але це ще один приклад того, як Node тихо видаляє шар, який багато проектів насправді ніколи не потребували.

3. Ваш код кешу ось-ось стане зайво складним

Ви майже напевно писали цю структуру більше разів, ніж можете порахувати:

let user = cache.get(userId);

if (user === undefined) {
  user = await fetchUser(userId);
  cache.set(userId, user);
}

У цьому коді немає нічого поганого.

Але справжня мета залишається прихованою під технологіями перевірки, отримання та зберігання даних.

Насправді ви намагаєтесь сказати наступне:

Дайте мені це значення. Якщо його ще немає, створіть його.

Сучасний JavaScript починає дозволяти саме це формулювати.

V8 14.6, який входить до складу Node.js 26, додає:

Map.prototype.getOrInsert()
Map.prototype.getOrInsertComputed()

Завдяки цьому синхронний пошук у кеші можна спростити до чогось на кшталт:

const value = cache.getOrInsert(
  key,
  createValue()
);

А коли значення потрібно обчислювати лише за потреби, лінійно:

const value = cache.getOrInsertComputed(
  key,
  () => createValue()
);

Жодна з цих функцій сама по собі не є проривною.

Але розробка мови рідко просувається завдяки революційним функціям.

Вона просувається тоді, коли достатньо розробників постійно пишуть одні й ті самі п’ять рядків, поки мова зрештою не відповість:

"Гаразд. Вам більше не потрібно писати ці п’ять рядків."

Це саме той тип доповнень, який тихо вплітається у повсякденний код.

Через рік майже ніхто не буде про це говорити.

Вони просто будуть ним користуватися, не замислюючись.

4. Node.js тепер може досягати рівня нижче JavaScript

Ця наступна можливість має набагато більше значення.

Node.js 26 постачає експериментальний інтерфейс Foreign Function Interface:

node:ffi

FFI дозволяє JavaScript викликати функції, які безпосередньо надаються нативними бібліотеками.

Ось приблизний опис цього механізму:

JavaScript
     ↓
node:ffi
     ↓
Native library
     ↓
C / C++ / system APIs

double calculate(double value);

• спеціалізовані числові обчислення
• повторне використання існуючих нативних бібліотек
• глибша інтеграція з системою
• криптографія на рівні нативного коду
• обробка зображень та відео

„Час переписати кожен пакет npm на мові C.“

Краще розуміти це так:

„Node тепер пропонує набагато пряміший шлях у сферу нативних програм.“

Це два зовсім різні твердження.

5. Ваш Node CLI може не потребувати встановленого Node

Ось ще одне припущення, яке варто поставити під сумнів:

Якщо ви створюєте інструмент за допомогою Node, вашим користувачам також потрібно встановити Node.

Програми-одиниці виконання суперечать цьому припущенню.

Інструменти SEA від Node дозволяють пакувати програму як окремий бінарний файл.

Тож замість того, щоб надсилати:

npm install
node index.js

ви можете надсилати щось більш близьке до:

./my-cli

Розгляньте внутрішній інструмент, від якого щодня залежить ваша команда.

Це може бути CLI для розгортання:

deploy production

або інструмент для роботи з базами даних:

db-migrate

або інструмент для створення скелета проекту:

project init

Якщо ви розповсюджуєте єдиний виконуваний файл, користувачам не потрібно знати чи цікавитися тим, що під спудом працює JavaScript.

Це тонко змінює уявлення про Node.

Node починав своє існування як:

JavaScript, що працює поза браузером.

Зараз він все більше нагадує:

Багатофункціональний середовище виконання додатків, яке випадково підтримує JavaScript.

Це значно ширша теза.

6. Що робити, якщо ваш додаток більше не потребує всіх своїх дозволів?

Моделі безпеки зазвичай дотримуються такої схеми:

Application
     ↓
Gets permissions
     ↓
Keeps permissions
     ↓
Runs

Але що робити, якщо дозвіл потрібен лише на короткий час, під час запуску?

Візьмемо сервіс, який під час ініціалізації читає файл конфігурації та деякі сертифікати.

Як тільки він почне працювати, йому може зовсім не знадобитися доступ до файлової системи.

Модель дозволів Node рухається у напрямку того, щоб дозволяти додаткам активно скорочувати свої можливості під час роботи за допомогою API, таких як permission.drop().

Процес починає виглядати так:

Start
  ↓
Read configuration
  ↓
Initialize
  ↓
Drop unnecessary permissions
  ↓
Run

Це відображає корисний принцип безпеки:

Не лише запитуйте, що дозволено робити вашому додатку. Запитуйте, які дозволи йому насправді ще потрібні в майбутньому.

Зміни у інтерфейсі API є незначними.

Але зміна підходу до безпеки додатків — ні.

7. Node.js нарешті готовий видаляти елементи

Додавання API — це простий спосіб зробити середовище виконання привабливішим.

Їх видалення — це складна частина.

Node.js 26 продовжує видаляти старі API та застарілі внутрішні компоненти, які існують уже багато років.

Це має значення, ніж може здатися.

Кожен старий API рано чи пізно стає неминучою залежністю для когось.

Якщо його не контролювати, середовище виконання змушене тягати за собою десятиліття накопиченого історичного „багажу“:

old API
   +
new API
   +
replacement API
   +
deprecated API
   +
"don't use this anymore" API

Зріла платформа потребує готовності позбутися цього накопичення.

Node.js все більше демонструє саме таку готовність.

Це хороша новина, якщо ви не хочете запам’ятовувати кожен спосіб виконання однакових завдань з минулого.

Цікавою є не якась окрема функція

Temporal сам по собі не є привабливим інструментом.

Так само як і getOrInsert().

Так само як і виконання файлу .ts без кроку компіляції.

Так само як і пакування CLI у виконуваний файл.

Але якщо поставити їх поруч.

Node одночасно піднімається вгору у плані абстракції:

Temporal
Better collections
TypeScript
Modern JavaScript

водночас просуваючись вниз:

FFI
Native libraries
Permissions
Executable packaging

Ось справжня історія тут.

Node.js не просто стає кращим у виконанні JavaScript.

Він перетворюється на кращий середовище виконання для всього, що оточує ваше додатку.

Це змінює питання, яке варто поставити на початку нового проекту.

Замість того, щоб одразу переходити до:

"Який пакет npm мені потрібен для цього?"

все більше варто спочатку запитати:

"Чи може Node.js вже це зробити?"

Іноді чесною відповіддю все ще є «ні».

Але все частіше відповідь виявляється такою:

"Насправді... так."

Це, мабуть, найбільш вражаюча риса Node.js 26.

Середовище виконання вже рухається вперед.

Наші уявлення просто ще не встигли наздогнати його.