Для тех, кто не совсем в теме, Deno — это детище Райана Даля, ставшего известным благодаря созданию Node.js, который вам, наверняка, знаком. Значит ли это, что Deno автоматически и безоговорочно становится замещением Node, а нам стоит готовиться к глобальному рефакторингу? Коротко говоря — нет. Но если вам интересно подробнее узнать о чём вообще вся эта история, читайте далее.
Начнём с начала
В 2018 Райан выступил с речью, в которой он поведал о 10 вещах, которые с его точки зрения были ошибочными в Node.js. В этом же своём выступлении он как раз поведал о разработке Deno, являвшимся на тот момент всего лишь небольшим проектом, который можно было бы назвать Node.js v2 — улучшенный и более безопасный вариант изначальной версии.
Здесь можно посмотреть видеозапись той презентации.
Два года спустя была назначена дата официального релиза Deno: 13 мая. Он является совершенно новой средой выполнения для бэкенд и написан уже не на C++, как оригинал, а на Rust, основанном на платформе Tokio (предоставляет асинхронную среду выполнения, необходимую JavaScript). Но при этом работает Deno всё так же на движке Google V8.
Что ещё нового?
Мы говорим не просто о новой среде выполнения JavaScript, полностью совместимой с текущим Node.js. Райан намеренно привнёс в Deno те самые детали, которых недоставало в его первом творении.
Добавлена безопасность
По умолчанию Node.js даёт доступ к чему угодно, т.е. вы можете выполнять чтение файловой системы и производить в неё запись, совершать исходящие запросы, обращаться к переменным среды и т.д. Несмотря на то, что для разработчика наличие такой свободы доступа является своего рода преимуществом, оно также подвергает риску безопасность, если не быть достаточно осторожным в написании кода.
В связи с этим в Deno реализовано использование аргументов командной строки для предоставления или ограничения доступа к различным элементам безопасности. Например, если вам нужно, чтобы сценарий имел доступ к каталогу /etc, то вы можете сделать следующее:
deno --allow-read=/etc myscript.ts
Такая команда позволит коду выполнять считывание из каталога, в то время как все остальные действия вызовут появление исключения безопасности. Такой подход аналогичен реализации безопасности другими платформами. Если вы используете Android, то однозначно уже получали вопросы от разных приложений о предоставлении им доступа к различным системам внутри телефона (например, к контактам, вызовам, папкам и т.д.). В случае с Deno может быть применён тот же принцип. Используя флаги в командной строке, выполняющей ваш сценарий, вы можете предоставить необходимые коду разрешения.
Дополненная стандартная библиотека
JavaScript улучшил свою стандартную библиотеку с момента появления первых версий Node, но ему до сих пор ещё предстоит сделать многое по сравнению с другими языками. Deno также был проработан в этом направлении и, со слов его создателя, предлагает обширную стандартную библиотеку, позволяющую разработчикам использовать официальные инструменты для выполнения основных задач, требуя привлечения внешних библиотек (вроде NPM) только для сложных.
Не менее важно, что прямо “из коробки” Deno содержит инструменты для добавления цвета в текст терминала, работы с внешними структурами данных (вроде csv, yaml и др.), генерации UUID и даже написания веб-сокетов. Помимо этого доступны и более простые модули, такие как обращения к файловой системе, вспомогательные функции для работы с датами, http-функции и другие.
Интегрирован Typescript
Если вы поклонник TypeScript, то Deno изначально имеет то, что вам нужно, и дополнительные внешние инструменты не потребуются. По умолчанию транспиляция в JavaScript выполняется внутренне, поэтому переживать об этом не придётся.
Стоит также отметить, что хоть Deno и берёт на себя львиную долю забот, вы можете перенастроить конфигурацию, используя свой собственный файл tsconfig.json:
deno run -c tsconfig.json [your-script.ts]
Настройки по умолчанию подразумевают использование режима strict (строгий), поэтому любой непродуманный код будет вызывать предупреждения об ошибках.
Больше никакого NPM или каталога node_modules
Как молодые, так и бывалые могут сказать на эту тему немало по опыту прошлого. Не слишком ли он громоздкий? Точно ли это правильный способ распространять зависимости? Это однозначно один из самых спорных аспектов Node, от которого в Deno было решено избавиться, причём полностью.
Тогда как же Deno обрабатывает зависимости? На сегодняшний день он просто позволяет вам запросить модули откуда угодно. Т.е. вы можете просто сделать так:
import * as log from "https://deno.land/std/log/mod.ts";
Больше нет нужды содержать свой собственный централизованный репозиторий, но тем не менее с этим подходом тоже нужна осторожность, поскольку импорт модулей со сторонних неконтролируемых ресурсов подвергает вас некоторым рискам.
По факту теперь также отсутствует и наш старый приятель package.json, а управление зависимостями упрощено до наличия списка модулей и соответствующих им URL в файле под названием deps.ts. Уже слышу ваш вопрос: “А как же управление версиями?” Что ж, вы можете указать версию пакета в URL. Это будет не очень красиво, но сработает.
Обычный файл deps.ts может выглядеть так:
export { assert } from "https://deno.land/[email protected]/testing/asserts.ts";
export { green, bold } from "https://deno.land/[email protected]/fmt/colors.ts";Такой вариант повторно экспортирует модули, и если вам нужно изменить их версию, просто скорректируйте соответствующим образом URL.
Кстати говоря, импортированный код кэшируется с момента первого выполнения сценария и до его повторного запуска с флагом — -reload.
Что-нибудь ещё?
В Deno был добавлен и другой функционал. Например, изначально увеличенный набор инструментов с такими элементами, как исполнитель тестов, отладчик, наблюдатель файлов и др. Но опять же некоторые из них — это просто предоставляемые языком API, и для их использования вам нужно прописывать собственные инструменты.
Возьмём пример API наблюдателя файлов, предоставляемый Deno.watchFs. Если вы ищете схожее решение для nodemon, тогда вам придётся создать его самому. Вот как выглядит сценарий из 23 строк, решающий аналогичную задачу:
Пользователь Caesar2011 опубликовал его, как часть одного из своих репозиториев. Полную версию кода вы можете найти здесь.
Заменит ли Deno в ближайшем времени Node.js?
Честно говоря, навряд ли. Заголовок в данном случае скорее служит приманкой для читателя. Некоторые из нас начали пользоваться Node.js ещё в далёком прошлом, когда его версия была 0.10, причём мы использовали его в продакшене, т.к. альтернативы не имелось. Ни PHP, ни даже Python и Ruby (не говоря уже о Java или .NET) не могли сравниться с одновременным наличием JavaScript и асинхронной модели I/O в бэкенд. И спустя все эти годы Node (и JavaScript) развился до уровня соответствия требованиям индустрии. Идеален ли он? Конечно, нет. Но как мы знаем, ничто в жизни не идеально, особенно когда речь заходит о языках программирования.
И Deno в этом смысле ничем не отличается просто потому, что на данный момент он представляет из себя не более, чем кульминацию двухлетней работы над идеей. Этот инструмент ещё не был опробован и протестирован в системах продакшена. Он не проходил ревью и не испытывался в странных и непредсказуемых сценариях использования для выявления его поведения в пограничных случаях. И пока весь этот путь не будет им пройден, он так и останется игрушкой для начинающих пользователей. Может быть через год мы и начнём слышать от компаний их первые отзывы об использовании Deno и истории о том, как они расправились с обнаруженными в нём дырами, и в конце концов стоящее за ним сообщество подтянет его до той точки, в которой этот инструмент станет действительно эффективным. Заменит ли он тогда Node? Кто знает! Поживём — увидим.
Читайте также:
- Веб-сервер с нуля в TypeScript и Node
- Фильтруем баги. Как реализовать тестовое покрытие в TypeScript под Node.js с помощью Jest
- Потоки и буферы в Node.js
Перевод статьи Fernando Doglio: What is Deno and will it Replace NodeJS?.
