Разработка
Danil Sabirov
219

Deno — получилось ли исправить ошибки Node.js?

В закладки

Чуть более месяца тому назад состоялся релиз проекта Deno, анонсированный двумя годами ранее Ryan Dahl, автором Node.js, на конференции JSConf 2018 года. Тот доклад Ryan'а назывался 10 вещей, о которых я сожалею в Node.js, где он поделился своим мнением о том, что не получилось сделать в Node.js и среди прочего, он выделил проблему безопасности среды выполнения, когда исполняемый код пользователя имеет доступ ко всему, что имеет пользователь.

Сейчас, спустя месяц после релиза, после того как в интернете уже появилось немало обзоров на Deno, можно сделать немного более детальное сравнение с Node.js и посмотреть что получилось у Deno и насколько хорошо это реализовано.

1. Поддержка Typescript из коробки

Наличие встроенного transplier'а для Typescript в 2020 году безусловно является приятным бонусом и по логике автора должно завлечь аудиторию разработчиков.

Однако в Deno у этого бонуса есть одна особенность: на данный момент конкретная версия Deno железно привязана к своей версии Typescript'а. И если у вас возникнет ситуация, когда вы захотите обновить Typescript отдельно от Deno, что вполне может на реальных проектах, то на данный момент в Deno это не получится.

2. Безопасная среда выполнения

Собственно это то, ради чего весь проект и затевался. По умолчанию скрипт Deno не имеет доступ к файловой системе, сети, environment'у и другим ресурсам системы. Для предоставления доступа необходимо явно указывать флаги при запуске программы:

  • --allow-env — доступ к environment
  • --allow-hrtime — доступ к более точному времени измерению исполнения кода
  • --allow-net=<allow-net> — доступ ко всей сети или определённым доменам
  • --allow-plugin — разрешить плагины
  • --allow-read=<allow-read> — доступ к чтению файловой системы
  • --allow-run — доступ к запуску подпроцессов
  • --allow-write=<allow-write> — доступ к записи в файловой системе
  • --allow-all — разрешить всё

Например, если вы хотите, чтобы ваш скрипт мог читать файлы и записывать, только из папки files, а так же имел бы доступ к ресурсу https://mysite.com, то код запуска будет выглядеть следующим образом:

deno run --allow-read=/files --allow-write=/files --allow-net=https://mysite.com script.ts

Поможет ли этот подход завоевать рынок разработки, пока не ясно.

Скепсис вызывает следующие факты: в реальных коммерческих проектах во флагах будет большое количество параметров, и работать в том виде как это сейчас будет точно не удобно. Хотелось бы видеть запуск скрипта через файл с конфигурационными данными.

Несмотря на то, что в Deno решён вопрос ограничения доступа ко всему исполняемому процессу, как правило основная тревога разработчиков при написании кода исходит от импортируемых модулях. Поэтому ограничение безопасности на уровне импортируемых модулей, на мой взгляд, могла бы стать более крутой "фичой" проекта.

3. Нет пакетного менеджера

В Deno нет npm и как следствие packages.json. Чтобы импортировать модуль, необходимо явно указывать его url:

import { assert } from "https://deno.land/std/testing/asserts.ts";

так же есть возможность указать специфичную версию модуля:

import { assert } from "https://deno.land/std@v0.53.0/testing/asserts.ts";

При этом есть соглашение: специфичные импорты хранить в файле deps.ts. Предполагаю, что на деле все внешние импорты придётся хранить в данном файле и, как следствие, контроль зависимостей полностью перейдёт в ручной режим.

Также нужно понимать, что в предложенном децентрализованном хранении "пакетов", вся ответственность за их доступность 24/7/365 теперь ляжет на плечи их авторов. Готовы ли они будут к этому? Только время покажет как будет решаться этот вопрос.

4. Остальные фичи

К остальным уникальным фичам Deno можно было бы отнести поддержку ES6 модулей, но Node.js с версии 14.0.0 тоже стал их поддерживать. Поэтому тут паритет.

Так же можно было бы отнести к фичам и top level await, но опять же в Node.js уже работают и над этим, это уже можно включить через экспериментальный флаг. Включение данной фичи в стабильную версию Node.js лишь вопрос времени.

Назвать встроенные браузерные api в Deno каким то прорывом тоже невозможно. Да в Deno можно сразу вызвать fetch, но в Node.js не составляет никаких проблем импортировать node-fetch и использовать тот же функционал.

Тоже самое можно сказать и про встроенные тесты. То, что есть встроенная возможность для тестирования это хорошо, но не более того.

Итоги

Чтобы подвести итоги, необходимо вернуться к изначальному вопросу: получилось ли у Deno исправить ошибки Node.js?

Во-первых, Deno задумывалась как более удобная среда поддерживающая современные стандарты по сравнению с Node.js. Но если посмотреть на ситуацию сейчас, то можно отметить что Node.js тоже не стоит на месте и активно стремится поддерживать современный ES и отрыв от Deno не такой уж и критичный.

Во-вторых, стоит опять отметить особенность децентрализованного подхода хранения пакетов. На мой взгляд, этот подход сам создаёт проблемы: прежде всего к более быстрому и широкому распространению пакетов по сравнению с централизованным хранилищем. По сути одна из сильных сторон Node.js в его экосистеме, в том же npm с его более чем 1,3 млн. пакетам. В Deno же вопрос экосистемы вызывает очень много вопросов.

Ну и, в-третьих, безопасность среды. Да, Deno, действительно, можно назвать безопасной средой. Я бы сказал, что именно эта фича в дальнейшем может заставить разработчиков останавливать свой выбор именно на Deno, а не на Node.js . Правда пока всё равно не совсем ясно под какие именно проекты в реальной жизни будет больше применяться Deno.

В любом случае, концепт Deno уникален и только время покажет насколько он будет востребован. На данный же момент Deno только что появившийся проект, который находится на этапе своего становления. Должно пройти немалое время, пока вокруг него не сформулируется сильное сообщество и экосистема, и он не станет привлекателен для использования в реальных проектах. Такой же путь проходил и Node.js одиннадцатью годами ранее и потребовалось несколько лет прежде чем, он смог закрепиться.

{ "author_name": "Danil Sabirov", "author_type": "self", "tags": [], "comments": 2, "likes": 1, "favorites": 5, "is_advertisement": false, "subsite_label": "dev", "id": 130753, "is_wide": true, "is_ugc": true, "date": "Thu, 25 Jun 2020 22:02:07 +0300", "is_special": false }
Объявление на vc.ru
0
2 комментария
Популярные
По порядку
1

Программирование на JavaScript — это не только программирование, но и архитектура, в ней нет ничего о которой вы пишите. У вас есть программа по адаптации технологий, что позволяет не тратиться на железо, а нанять системный администратор (инженер-программист-консультант). И так же если вам нужна помощь в настройке, то можно настроить что-то типа root, java, python и т.

Ответить

Комментарии