Deno помер, хай живе Deno 2

Я планував почати цю статтю зовсім інакше, бо коли сів за її написання, офіційної версії Deno 2 ще не було. Але тепер є, і я хочу, щоб і ви побачили цю чудову презентацію Deno 2 від Ryahn Dahl на Youtube ;)

Деякі мої думки можуть повторюватись або відрізнятись від того, що озвучили автори Deno 2, але на то вони й думки. Практичних кейсів майже не буде, але я готую їх для публікації в наступних статтях цього циклу.

Трішки історії

У 2018 році на конференції JSConf Ryahn Dahl виступив зі своєю відомою доповіддю «10 Things I regret about Node.js» у якій пройшовся по головних проблемах Node.js і представив альтернативне середовище виконання JavaScript — Deno.

Не дивлячись на критику та появу все більшої кількості альтернативних середовищ, Node.js залишається незмінним лідером серед технологій, що дозволяють використовувати JavaScript на сервері.

Та впродовж усього цього часу Deno також не стояв на місці, а стрімко розвивався. Він не просто обріс новим функціоналом, а й разом із Deno Deploy сформував цілу хмарну платформу для розгортання serverless-архітектури.

Проте цікавість до Deno, на жаль, росте не прямо пропорційно до розвитку цієї технології. Якщо дивитись на опитування State of JavaScript, у 2021 році його використовували лише 5.6% респондентів, а у 2023 ця кількість виросла до 15%. Тут важливо зробити поправку на загальну кількість респондентів, яка може значно відрізнятись з року в рік.

І ось 9 жовтня 2024 року світ побачила нова версія Deno 2. Чи зможе вона якось кардинально вплинути на популярність Deno і перетягнути на себе ще більшу частку розробників, що використовують JavaScript на сервері?

Усвідомлення помилок

Deno із самого початку задумувався як Node.js, але зроблений правильно. Є ще люди, які навіть не в курсі каламбурчика із назвою NoDe — DeNo. Проте, як це часто буває, ідеальне — це ворог хорошого. Не хочу сказати, що Deno ідеальний, зовсім ні. Але у намаганні зробити щось ідеальне і якнайдалі відійти від Node.js, розробники Deno відмовились навіть від підтримки npm, що було пострілом собі у ногу, який майже призвів до смерті.

На щастя, команда вчасно зорієнтувалась (коли Bun постукав у двері) і перейшла від цілковитого заперечення Node.js-екосистеми до усвідомлення, що не вийде просто взяти й змусити всіх перейти на щось нове. Людям потрібна поступова, плавна міграція, при якій без зворотної підтримки не обійтись не тільки Node.js, а й npm.

Водночас команда Deno, розробляючи повністю нове середовище, мала можливість запропонувати дійсно нові рішення до наявних у серверному JavaScript проблем. Саме тому разом із Deno ми зараз маємо JSR, Deno Standard Library, компіляцію під різні OS тощо. Deno 2 — це свого роду checkpoint, який закріплює усвідомлення попередніх помилок та стабілізацію вектора розвитку середовища.

Повернення в рідну гавань

Тож чи не найголовнішою частиною нового релізу є покращена сумісність із Node.js та npm. Наприклад, раніше, щоб запустити ось такий код, потрібно було переписати require на import. А також явно вказати, що http та fs частина Node.js, використовуючи префікс node.

У другій версії продовжують курс на покращення сумісності із Node.js. Зокрема, команда Deno, схоже, прийняла: CommonJS не вимре так швидко, як хотілось. Це все ще величезна частина Node.js-екосистеми.

Саме тому підтримка CommonJS-модулів виглядає тепер значно краще. Якщо у файлі, описаному вище, розширення js замінити на cjs, тоді все запуститься без жодних додаткових змін. Крім цього, require можна використовувати й для ESM.

Є ще величезна кількість різних нативних для Node.JS API, підтримку яких покращено (node:crypto, node:ssh2, node:events тощо). Це своєю чергою значно розширює кількість пакетів, з якими у Deno буде зворотна сумісність.

У презентації Deno 2 використаний приклад з Next.js — дуже простий. Я заради експерименту спробував запустити свій пет-проєкт на t3-стеку. Запустився він без особливих проблем, проте от drizzle-studio впав з досить беззмістовною помилкою. Тому, як завжди — все не так ідеально, як на демці :)

Deno @std

Останнім часом я почав частіше зіштовхуватись із тим, що розробники з різних причин переходять зі своєї поточної технології Ruby, PHP тощо на Node.js. Одна з перших речей, що усіх дратує і дивує водночас — це відсутність стандартизованого підходу для розв’язання типових проблем. Те, що для JavaScript-розробника вже звичне явище, зовсім дика річ для більшості представників інших мов програмування. Принаймні для тих, з ким я спілкувався.

Deno пробують подолати цю проблему створенням Deno Standard Library. За суттю це стандартизований набір інструментів для розв’язання типових задач, що значно спрощує поріг входу для тих, хто не знайомий з усім різноманіттям JavaScript-екосистеми. З тим, що входить у @std, ви можете ознайомитись тут. В чомусь це повторює нативний API Node.js, а десь трішки переосмислює звичні інструменти, що ми використовуємо у повсякденній розробці. Як-от testing чи dotenv.

@std можна використовувати в Node.js, а Deno вам для того зовсім не потрібний. Єдиний момент, який важливо знати — @std немає в npm. Натомість необхідно буде використовувати JSR, щоб дістатись відповідної бібліотеки. Проте це не так страшно, як може виглядати на перший погляд.

Наприклад, щоб додати в проєкт @std/dotenv, достатньо лише виконати наступну команду:

npx jsr add @std/dotenv

JSR

Про JSR вже колись згадували на DOU. З одного боку, це ще один крок у бік схожості з Node.js, з іншого — спроба через JSR трішки переманити розробників.

Однією з головних причин успіху Node.js був npm та легкість і зручність, з якою можна створювати свої пакети та використовувати вже наявний. Проте Deno у своїх ранніх версіях відмовились від вже звичного для усіх підходу із node_modules, а придумали свій з імпортом залежностей через URL та їх кешуванням на глобальному рівні.

Напевно, на це були свої якісь причини, проте зараз можна чітко бачити: у версії Deno 2 (навіть трішки раніше) частково переглянули цей підхід.

Тепер deno.json став ще більше схожим на package.json зі списком залежностей і додались команди для керування пакетами deno add, deno install, deno remove. Деееесь я таке вже бачив ;)

Чітко видно курс на активний промоушин власної альтернативи npm — JSR.

Від себе додам, що сама поява JSR і те, що пакети звідти можна використовувати в Node.js — логічний та цікавий крок. Особливо з огляду на усякі цікаві фічі з підтримки TypeScript, документації тощо. NPM потрошки застаріває і не завжди може ефективно протистояти сучасним викликам. Саме про це свідчить ріст звітів про різного роду атаки? які використовують слабкі місця NPM. Маю сумнів? що JSR повністю замінить NPM. Але конкуренція — це завжди потенційне джерело покращень.

Один в полі не воїн

Однією з головних проблем Deno з моменту його появи є спільнота. Наразі Node.js підтримується OpenJS, має величезну спільноту індивідуальних колабраторів, а також великі enterprise-компанії. Які або використовують Node.js, або дають можливість своїм працівникам контрібьютати в Node.js-екосистему, а зазвичай це й те й інше.

У Deno такої спільноти немає. Є зірковий Ryahn Dahl, є окремі use case використання великими гравцями, але за Deno по суті стоїть лише команда Deno. Та компанія, яка пробує монетизувати Deno коштом хостингу.

Deno 2 закладає гарний початок для покращення цієї ситуації. У подкасті на StackOverflow та в офіційній презентації Ryahn Dahl дав зрозуміти, що вони тісно співпрацюють з enterprise-клієнтами, враховують їх побажання і намагаються цю співпрацю розширити.

На мою думку, саме через enterprise-клієнтів команда Deno почала так активно покращувати сумісність з Node.js на різних рівнях. Саме тому багато чого стає все більше схожим на Node.js (API, CLI, deno.json). Додатково, як озвучив автор, приватні реєстри пакетів та підтримка monorepo, де можна працювати і з package.json і з deno.json — це все про намагання поступово перетягувати великих гравців на свою платформу.

Мені особисто цей реліз надзвичайно подобається. Це не просто реліз кількох нових фіч, це підсумок багаторічної роботи не лише над кодом, а й над помилками. Чи буде це кардинально впливати на серверний JavaScript? Думаю, що ні. Проєкти, написані на Node.js не будуть мігрувати на Deno без явної на це причини, проте нові проєкти, можливо, трішки частіше обиратимуть саме динозаврика.

У цьому релізі головне — конкуренція. Багато з того, що ще недавно важко було уявити в Node.js (як-от підтримка TypeScript з коробки), стає реальністю саме через конкуренцію.

Deno 2, схоже, впевнено закріплюється на другому місці, але після Node.js. Чи зможе обігнати його на якомусь з поворотів, покаже тільки час.

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті