JavaScript і Node.js: мова, рушії, середовища виконання

Що ховається за словом «JavaScript»: мова, стандарт чи середовище?

Насправді це три різні шари, які зручно плутати одним словом. Мова — це синтаксис і правила, якими ти пишеш код. Стандарт (ECMAScript, ECMA-262) — текстовий документ, що ці правила описує, але сам нічого не виконує. Рушій (engine) — реальна програма, яка бере твій код і перетворює його на дії процесора. А поверх усього — середовище (браузер чи Node.js), яке додає власні можливості типу DOM або файлової системи. Половина «незрозумілих» помилок новачка в автоматизації — це наслідок того, що людина не бачить межі між цими шарами.

Яка різниця між JavaScript і ECMAScript?

ECMAScript — це стандарт мови (ECMA-262), а JavaScript — конкретна мова, що його реалізує. Стандарт розробляє комітет TC39 і щороку випускає нову редакцію: ES2015 (він же ES6) приніс let, const, класи й стрілочні функції, ES2017 — async/await. Сам стандарт — це текст із правилами, він нічого не запускає. У побуті обидва слова вживають як синоніми, але на співбесіді питання «що таке ECMAScript» перевіряє саме розрізнення: специфікація проти реалізації. Коли кажуть «нова фіча JS», зазвичай мають на увазі свіжу редакцію ECMAScript.

Що таке рушій JavaScript і які основні існують?

Рушій — це програма, яка парсить твій текст коду, компілює його й запускає. У кожного великого вендора свій: V8 у Google (Chrome, Node.js), SpiderMonkey у Mozilla (Firefox), JavaScriptCore в Apple (Safari). Усі вони реалізують один стандарт ECMAScript, тому чистий мовний код на кшталт [1, 2, 3].map(x => x * 2) дає в них однаковий результат. Різниця не в мові, а в тому, які додаткові API навколо рушія додає середовище. Тому «баг тільки в Safari» майже завжди означає різницю рушія чи Web API, а не «інший JavaScript».

Яка різниця між JavaScript і Node.js?

JavaScript — це мова, Node.js — середовище виконання (runtime), яке дозволяє запускати цю мову поза браузером. Node не є ні мовою, ні «діалектом JS»: це програма, що вбудовує рушій V8 і додає до нього доступ до файлової системи, мережі, процесів і змінних оточення. На співбесіді це питання-фільтр — інтерв'юер слухає, чи не назве кандидат Node мовою, бо така відповідь одразу видає нерозуміння картини. Для нас практично важливо, що саме Node запускає тестові ранери: npx playwright test під капотом — це Node, який виконує файли з твоїми тестами.

Що таке V8 і як він повʼязаний одночасно з Chrome і Node.js?

V8 — рушій від Google, написаний на C++, який компілює JavaScript у машинний код під час виконання (JIT, just-in-time), тому працює швидко. Ключове: сам V8 уміє лише виконувати мову — він знає Array і Math, але поняття не має, що таке «клік по кнопці» чи «файл на диску». І Chrome, і Node.js вбудовують один і той самий V8, а відрізняються тим, що додають навколо нього: Chrome дає йому сторінку й DOM, Node — файли й процеси. Тобто один двигун живе у двох різних «будинках».

Чому один і той самий сайт по-різному поводиться в різних браузерах?

Тому що сама мова в Chrome, Firefox і Safari однакова — розходяться реалізації Web API і рушії. Базові конструкції ECMAScript працюють скрізь ідентично, але браузерні можливості (DOM, окремі API) кожен вендор реалізує самостійно, і саме тут виникають розбіжності. Отже, причину «дивної поведінки лише в одному браузері» треба шукати в середовищі, а не в «іншому JavaScript». Для AQA це орієнтир: крос-браузерний баг — це майже завжди різниця Web API чи рушія, а не мови.

Навіщо AQA знати саме JavaScript і TypeScript, а не Python чи Java?

Здебільшого мову диктує екосистема інструментів, а не смак. Провідні тулзи для e2e-тестування вебу — Playwright, Cypress, WebdriverIO, CodeceptJS — написані на JS і TS, і твої тести пишуться тією ж мовою. Узявши іншу мову, ти втрачаєш частину екосистеми: приклади з документації, плагіни, готові відповіді, спільну мову з фронтендерами. Другий аргумент — сам продукт: фронтенд сучасного вебу це JavaScript, тож AQA, який читає код сторінки, заводить точніші баги й швидше добирається до першопричини.

Що TypeScript додає поверх JavaScript і навіщо це в тестах?

TypeScript — це надбудова над JavaScript зі статичною типізацією (static typing), тобто перевіркою типів до запуску. Для тестового коду це страховка: редактор підкаже, що в об'єкта сторінки немає такого методу, ще коли ти друкуєш рядок, а не через годину, коли тест червоніє в CI. Важливо, що TS — не окрема мова, а той самий JavaScript плюс анотації типів. Рушій його напряму не виконує: TypeScript спершу перетворюється на JavaScript.

Де виконується код твого Playwright-тесту — у браузері чи ні?

У Node.js, а не в браузері. Node запускає файл із тестом, а той уже керує окремим браузером через протокол — тобто код тесту й код сторінки живуть у різних середовищах. Саме тому в тілі тесту немає document чи window: ці об'єкти існують лише всередині сторінки. Щоб дотягнутися до браузерних API, тест мусить переслати код на виконання в браузер — у Playwright це page.evaluate. Це класичне питання на розуміння архітектури, а не синтаксису.

Чому в тесті працює require('fs'), але падає звернення до document?

Бо тест виконується в Node, а Node і браузер дають різні набори глобальних об'єктів. Node додає доступ до файлової системи (fs), шляхів (path), процесу (process), але не має жодної сторінки, тому document там просто не існує. Браузер навпаки: у нього є DOM і localStorage, але немає прямого доступу до диска. Помилка document is not defined у тесті — це не баг і не проблема синтаксису, а сигнал, що ти звернувся до браузерного API з Node-частини коду.

Що таке page.evaluate і коли він потрібен?

Це спосіб виконати шматок коду не в Node, а всередині сторінки в браузері. Playwright бере функцію, яку ти передав у page.evaluate, і пересилає її в браузерний контекст, де вже доступні document, window, localStorage. Наприклад, дістати токен із localStorage можна лише так — з тіла тесту він недосяжний. Типова помилка новачка — намагатися звернутися до браузерних API прямо в тесті й не розуміти, чому вони «не визначені».

Як передати в тест базовий URL чи токен, не зашиваючи їх у код?

Через змінні оточення — process.env. Це Node-механізм, тому він доступний прямо в тілі тесту: process.env.BASE_URL чи process.env.TOKEN підставляються ззовні (з CI, файлу .env, команди запуску), і той самий код працює проти різних середовищ без правок. Важливо не плутати межу: process.env живе в Node-частині, а localStorage — усередині сторінки, тож дістати його можна лише через page.evaluate. Ця пара — наочний приклад того, який код у якому світі виконується.

Що таке REPL і чим він корисний для AQA?

REPL (read-eval-print loop, «читай, обчисли, надрукуй, повтори») — інтерактивна консоль Node: запускаєш node без аргументів, вводиш вираз і одразу бачиш результат. Це зручно, щоб швидко перевірити поведінку методу, не створюючи файл: чи sort мутує масив, що поверне parseInt('08'), як поводиться якийсь метод рядка. По суті це серверний аналог консолі DevTools, тільки навколо тебе не браузерне середовище з document, а Node з process і fs. Виходять із нього командою .exit або подвійним Ctrl+C.

Чому node file.ts не завжди запускається і що робити з TypeScript?

Бо рушій виконує JavaScript, а не TypeScript — типи треба спершу прибрати. Історично .ts напряму не запускався: його компілювали в JS або брали завантажувач типу tsx чи ts-node. Свіжі версії Node (24 LTS) вже вміють запускати .ts, просто відкидаючи анотації типів, але без перевірки цих типів — її, як і раніше, робить окремий інструмент. У реальному проєкті тестовий ранер бере трансформацію на себе, тому ти пишеш .ts, а Node під капотом отримує вже чистий JavaScript.

Чим window відрізняється від global і що таке globalThis?

Це глобальний об'єкт середовища, і зветься він по-різному: у браузері — window, у Node — global. Щоб не писати код окремо під кожне середовище, стандарт додав globalThis — єдине ім'я, яке вказує на глобальний об'єкт скрізь. Для AQA це практично: код, який має працювати і в тесті, і всередині сторінки, безпечніше писати через globalThis. Різні імена глобального об'єкта — ще один прояв того, що середовища різні, хоч мова одна.

Що таке host-середовище і чому DOM немає в стандарті ECMAScript?

Host-середовище (host environment) — це програма, яка вбудовує рушій і додає до мови власні можливості: браузер або Node.js. Рушій знає тільки мову — Array, Promise, Math; усе інше дає хост. DOM, window, document описані не в ECMAScript, а в окремих специфікаціях (DOM, Web APIs), які реалізує браузер; так само fs і process — це API Node, а не мови. Тому та сама мова в різних хостах отримує зовсім різний «інвентар», і розуміння цієї межі рятує від плутанини, де який код виконується.

Три ситуації, де плутанина «мова / рушій / середовище» вирішує, зелений тест чи згаяна година: класична помилка document is not defined та її правильне лікування, таблиця рішень «який код у якому світі виконується», і REPL як інструмент швидкої перевірки поведінки JS перед тим, як писати асерт. Скрізь — що робити й чому.

Кейс 1. document is not defined: тест виконується не там, де ти думаєш

Новачок пише перший тест, копіює звичний браузерний код і запускає його. Ось типовий зламаний варіант:

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

test('на дашборді показано токен', async ({ page }) => {
  await page.goto('/dashboard');
  // document живе в браузері, а цей рядок виконує Node
  const token = document.querySelector('#token')?.textContent;
  expect(token).toBeTruthy();
});

Запуск падає ще до будь-якого асерту:

ReferenceError: document is not defined

Спокуса — вирішити, що «зламалась мова» або «сторінка не завантажилась». Насправді причина інша: тіло тесту виконує Node, а document існує лише всередині сторінки в браузері. Node керує браузером окремо, тому браузерних об'єктів у нього під рукою немає. Правильний спосіб — переслати саме цей шматок коду в браузер через page.evaluate:

test('на дашборді показано токен', async ({ page }) => {
  await page.goto('/dashboard');
  // колбек Playwright пересилає в браузер — там document існує
  const token = await page.evaluate(() => {
    return document.querySelector('#token')?.textContent ?? null;
  });
  expect(token).toBeTruthy();
});

Що дивитися і чому:

• ReferenceError: document is not defined — це не баг Node і не синтаксис. Це сигнал, що ти звернувся до браузерного API з Node-частини коду. Лікування завжди одне: винести звернення в контекст сторінки, а не в тіло тесту.
• Асерт лишається в Node. expect(...) — частина тестового ранера, він працює саме в Node; у браузер їде тільки колбек page.evaluate, який повертає у Node вже готове значення (рядок або null).
• У браузер можна передавати лише серіалізовані дані. Функція в page.evaluate не бачить змінних із тіла тесту напряму — їх передають окремим аргументом. Це прямий наслідок того, що це два різні середовища, а не одна програма.

Кейс 2. Таблиця рішень: який код у якому світі

Коли не впевнений, чому щось «не визначено», спершу визнач середовище. Тіло тесту — це Node; усе, що всередині page.evaluate (чи page.$eval, locator.evaluate), — браузер. Ось найчастіші об'єкти й де вони реально живуть:

Найпоширеніша пара, де новачок спотикається, — process.env і localStorage в одному тесті. Перше читається в Node, друге — тільки в браузері:

test('токен збережено в localStorage після логіну', async ({ page }) => {
  // process.env — Node-механізм, працює прямо тут
  await page.goto(process.env.BASE_URL + '/dashboard');

  // а localStorage доступний лише всередині сторінки
  const token = await page.evaluate(() => localStorage.getItem('authToken'));
  expect(token).not.toBeNull();
});

Що дивитися і чому:

• Базовий URL і токени передавай через process.env, не хардкодь. Це Node-частина, тому змінна доступна прямо в тілі тесту, і той самий код працює проти локалі, стейджа й прода без правок.
• globalThis — безпечний спосіб не думати про ім'я глобального об'єкта. У Node він указує на global, у браузері — на window; якщо код має жити в обох світах, звертайся через globalThis.
• Помилка «X is not defined» майже завжди про середовище. Перш ніж чіпати код застосунку, спитай себе: цей рядок — Node чи браузер? Половина «магічних» падінь зникає на цьому питанні.

Кейс 3. REPL і node file.js: перевір поведінку до того, як писати асерт

Перед тим як зафіксувати асерт, буває корисно швидко перевірити, як метод поводиться насправді — а не як здається. Класична пастка: Array.prototype.sort мутує оригінальний масив, тому наївний тест може «зіпсувати» дані, які перевіряє далі. Замість гадати — відкрий REPL (node без аргументів) і подивись:

$ node
> const a = [3, 1, 2];
> a.sort();
[ 1, 2, 3 ]
> a
[ 1, 2, 3 ]        // оригінал змінився: sort мутує масив на місці
> parseInt('08');
8
> .exit

За п'ять секунд ти дізнався дві речі, які легко переплутати з пам'яті: sort повертає той самий (уже відсортований) масив і мутує оригінал, а parseInt('08') дає 8, а не падає й не читає це як вісімкову систему. Тепер асерт можна писати свідомо. Якщо перевірка складніша за один рядок, той самий код кладуть у файл і запускають:

node check.js

Node прочитає файл, віддасть V8 на виконання й завершиться, коли код відпрацює. Це рівно те, що під капотом роблять тестові ранери: npx playwright test — по суті Node, який запускає файли з тестами.

Що дивитися і чому:

• REPL — це Node-середовище, не браузер. Тут є process і можна require('fs'), але немає document: перевіряти браузерну поведінку в ньому не вийде — для цього є консоль DevTools.
• Мутація методів — часте джерело прихованих багів у тестах. sort, reverse, splice змінюють масив на місці; якщо готуєш дані для кількох перевірок, спершу скопіюй масив, інакше другий асерт побачить уже зіпсований стан.
• REPL не замінює тест, а економить ітерацію. Він відповідає на питання «як це працює?» без збірки, запуску браузера й очікування CI — і саме тому пришвидшує написання надійних асертів.

Мова, специфікація і рушій

• Розрізняю три шари за словом «JavaScript»: мову, специфікацію (ECMAScript, ECMA-262) і рушій, що виконує код.
• Можу пояснити, чому ECMAScript — це стандарт (ECMA-262), а JavaScript — його реалізація, і що редакції щороку випускає комітет TC39: ES2015/ES6 (let, const, класи, стрілки), ES2017 (async/await).
• Знаю три основні рушії й хто їх робить: V8 (Google), SpiderMonkey (Mozilla), JavaScriptCore (Apple).
• Розумію, що рушій виконує лише мову, а всі «зовнішні» можливості (DOM, файли) додає середовище навколо нього.

Браузер і Node.js — два середовища

• Можу пояснити, що V8 — один і той самий рушій у Chrome і в Node.js, а відрізняється те, що навколо нього.
• Знаю, що браузер дає document, window, DOM, localStorage, а Node — fs, path, process, Buffer.
• Розумію, чому DOM немає в стандарті ECMAScript: це окремі Web API, які реалізує браузер.
• Можу пояснити різницю глобального об'єкта: window у браузері, global у Node, globalThis скрізь.
• Знаю, що Node — це середовище виконання, а не мова, і чому відповідь «Node — це мова» провальна на співбесіді.

Node.js зблизька

• Знаю, що Node створив Ryan Dahl (2009) і що він поєднує V8 з бібліотекою libuv (асинхронний I/O, event loop).
• Розумію, що частина API зближується (сучасний Node має вбудований fetch), але поділ «DOM проти файлової системи» лишається.
• Можу пояснити, що require/CommonJS та import/ES-модулі співіснують у Node, тоді як браузер працює лише з ES-модулями.

Запуск коду і TypeScript

• Знаю різницю між node file.js (запуск файлу) і node без аргументів (REPL).
• Можу пояснити, навіщо REPL AQA: швидко перевірити поведінку методу, не створюючи файл.
• Розумію, що рушій виконує JS, а не TS: .ts спершу компілюється в JS або йде через завантажувач (tsx, ts-node).
• Знаю, що свіжий Node (24 LTS) прибирає типи сам, але не перевіряє їх — це робить окремий інструмент.

Межа Node/браузер у тестах

• Розумію, що код Playwright-тесту виконується в Node, а браузером він керує окремо через протокол.
• Можу пояснити, чому document is not defined у тесті — це не баг, а звернення до браузерного API з Node-частини.
• Знаю, що до браузерних API (document, localStorage) з тесту дістаюся лише через page.evaluate.
• Можу пояснити, чому process.env працює прямо в тілі тесту, а localStorage — тільки всередині page.evaluate.