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», щоб не пропустити нові технічні статті

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Основна проблема таких технологій полягає в тому, що вони намагаються запропонувати те, що вже існує на ринку та має мільйонну аудиторію. Проте їм важко залучити користувачів, оскільки вони не пропонують справді революційних інновацій. Це дуже схоже на ситуацію з Ubuntu Mobile, Firefox OS та іншими подібними проєктами, які не змогли зайняти місце через відсутність цінності для користувачів

десь так і є, Deno пропонує хіба трошки зручності... не більше

За Node — по суті стоїть Google і маркетингові можливості корпорації. Усі про це знають, власне тому це і перше успішне використання технології на серверах. Netscape (нині Mozilla) намагались використовувати JavaScript для бакенду, ще в 90-ті. Та технологія програла ринок Java та головному виробникові достатньо потужних серверних комп’ютерів тих часів — Sun Microsystems в корпоративному сегменті, і домінуючої бекенд технології Internet усіх часів під PC сервери — LAMP (Linux Apache MySQL PHP).
З поглинанням Sun — Oracle, тренди дещо змінились, .NET та Node відняли у Java велику долю корпоративного ринку. По суті головними столпами серверної Java — зараз є : Amazon, IBM/RedHat та частково ті же Google які сумісно із JetBrains просовуть Kotlin. J2EE (Jakarta EE) по суті замінили на дуже близьке по усіх смислах SpringBoot та мікросервіси під хмарну інфраструктуру Amazon 6, і слід за AWS це скопіювали : GCP, Azure та інші, не обов’язково з Java в якості бекенду, часто Node щоби мати в штаті Full stack розробників і усебічно економити.
Тепер питання — яку ще Deno 3 треба випустити, для того щоб лиця які приймають рішення — обрали Deno замість Node ? Тому що один інженер, який власне усе це започаткував вирішив порефакторити у власному форці, бо корпорація забюрокротизувала розвиток проекту, який став комерційною технлогією до стану неможливості реалізувати те що би йому кортіло ?
В цілому воно звісно стало виглядати як бізнес модель RedHat та Linux. З RHEL, JBoss — як стабільні протестовані версії — за які можна брати гроші за спорт. І відповідно Ferdora / Wildfly — комьюніті версії, по суті баг баунті программа під новітні розробки.

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

Дякую за гарну статтю!

Як на мене Deno зробили дуже правильні кроки з цією версією, але особисто я сумніваюся, що колись Deno чи Bun доженуть Node.js, от нема у них кіллер фіч поки + Node.js переймає їх фічі як от permission management (хоча як на мене користь від цієї фічі сумнівна), але конкуренція це дуже добре, вони змусили мейнтейнерів Node.js зарухатися і зайнятися питанням перформансу, наприклад, а також іншими фічами.

От мене завжди цікавило, чому всі так часто говорять про той std? При тому що набір нативних Node.js модулів фактично має весь функціонал, що декларується в тому ж std, наприклад node:test, node:assert, node:utils і т.д. іноді складається враження, що блог/патч ноути Node.js люди не читають на відміну від Deno та Bun. Те саме питання до нативної підтримки Typescript, це ж більше мінус, а ніж плюс, бо з певною версією рантайму буде вшита певна версія Typescript і це не можна буде менеджети окремо, якщо вже хочеться, щоб типи перевіряла лише IDE і щоб апка стартувала максимально швидко, то можна просто компілювати Typescript через SWC.

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

Одного не зрозуміло — чому вони не роблять перевід усього в WebASM, принаймні при старті як .NET чи Android Runtime. На сервері нема таких проблем як в браузері. Там від початку усе можна робити байткодом, а краще і взагалі без інтерпретації як такої.
Те що зараз бачимо — працюють в напрямку максимального спрощення розробки. Але в реальності така проблема не стоїть, з досвіду розробка станом на зараз часто буксує зовсім не через технічні інструменти — більшість проблем в процесах, зокрема експериментальному програмуванні як підході. Ті самі архітектурні проблеми — неможливо вирішити тулами типу VisualBasic і частими ітераціями, з деплоями на продакшн кожні сутки. Наприклад одна з колючових проблем які я років 7 стикаюсь мало не для усіх клієнтів — користувача використовує більше ніж один дивайс одночасно для користування системою. Як і передрікав Джобс — сучасний користувач має більше одного пристрою одночасно, як мінімум два — а то і чотири : дескоп, лептоп, смартфон та планшет, ще може бути консоль. І як часто не деплой, якщо в системі не радянізовані ті самі розподілені транзакції — не допоможе усе одно.
Те що бачимо — просувається саме підход ляп-ляп і в продакшн. AI до купи, який усеодно пишуть на Python і т.д. Тоді як реальні проблеми — це perofrmance, scalability та maintainability.

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

Чесно кажучи це більше схоже, що Google йде в бізнес модель RedHat (нині підрозділ IBM). Лінус Торвальдс — ніколи офіційно не був співробітником ні RedHat не в ключових партнерах Intel (там пів коду ядра з їх копірайтами), ні іншими тепер вже власниками — IBM, і Google (які стали використовувати PC стойки блейд серверів від початку, тоді як для цього зазвичай в ті часи використовували мейнфрейми Sun, Dec та IBM). Тим не менше по суті він завжди був тіньовим мало не CTO, отримав опціон відверто товаришував і товаришує із CEO до рівня коли вони разом приймали участь в IPO.
Ну от тут — форк, з якого однозначно будуть тягнути відпрацьовані ідеї в комерційний продукт, Node.

Мене от завжди цікавило, хто цим розробникам нових мов платить?

Зараз то вже всякі інвестори включаються. В Випадку Deno наприклад — techcrunch.com/...​y-managed-runtime-service

Підписатись на коментарі