5 претензий к Deno

Предисловие

Я не часть команды deno. Я не его фанат. Я не слежу за ним. Я даже не очень-то в него верю. Но видя негативную реакцию сообщества просто не могу не вступится. В этой статье я бы хотел рассмотреть самые частые претензии в адрес Deno и предложить альтернативную точку зрения.

Deno — убийца NodeJs

Это не так. Таким его продвигают только «свидетели deno», безумные фанаты, либо жаждущие хайпа переводчики. Насколько мне известно, даже сам Раян Дал (автор Deno) не позиционирует свою разработку как замену или альтернативу NodeJs. Это скорее его видение «каким может быть тот же NodeJs в будущем». Концепт, если хотите (мы же не ругаем концепты авто или смартфонов за их непрактичность в современных реалиях). С точки зрения Раяна в NodeJs есть определенные проблемы. И он показал сообществу некое представление о том, как бы эти проблемы можно было бы решить. И вы можете в этом участвовать. Прямо сейчас приходите на GitHub ^[1], и описывайте те архитектурные проблемы которые вы видите. Обсуждайте их. Придумывайте решения.

Я не думаю, что Deno когда-либо заменит NodeJs. Но он может стать для него тем же чем стал TypeScript для JavaScript.

Импорт по URL

Многие смотрят на это немного не под тем углом. Идея в том, чтобы отказаться от глобального списка зависимостей на весь проект. Чтобы вместо одного большого package.json у вас в каждом вашем модуле/файле был свой, независимый список зависимостей. Я вижу в этом несколько плюсов.

• Если вам нужно написать какую-то фичу, вы не обязаны смотреть какие зависимости уже используются в проекте. Вы не ограничены ими. Вы используете то, что вам нужно.
• Вы можете добавлять функционал без оглядки на legacy. В новых модулях будут свои зависимости, а в старых — свои.
• Во время миграции большого проекта на новую версию какой-то зависимости, вы можете изменять кодовую базу и выкатывать эти изменения по частям.

Но для такого подхода нужна возможность описывать зависимости для каждого модуля. Название, версию и откуда эту зависимость взять. Как следствие — import с указанием URL. И это даже не придумка Deno. Это часть стандарта. Просто все привыкли работать так как привыкли. Но это не единственный путь.

Но как мне теперь работать без интернета?

Точно так же как бы вы работали с NodeJs. Что Deno, что NodeJs скачивают зависимости в отдельную директорию. Только в NodeJs для этого вы запускаете npm install, а Deno делает это автоматически при первом запуске.

Звучит интересно, но я отказываюсь!

Не проблема. Есть такой пропозал — import maps ^[2]. И Deno его поддерживает ^[3], хоть и не в полной мере. Таким образом вы можете описать синонимы для всех зависимостей придя к аналогу package.json. Но вы не будете ограничены этим:

• Отдельные модули всё ещё могут использовать собственные версии зависимостей, по необходимости, игнорируя import map.
• Спецификация import maps ^[2] предполагает возможность указать несколько источников для загрузки. Сейчас Deno это не поддерживает. Но технически это возможно. Вы могли бы указывать несколько источников и в случае если один не доступен — зависимость будет скачано из другого.

  {
     "imports": {
        "moment/": [
           "https://deno.land/x/moment/",
           "https://raw.githubusercontent.com/lisniuse/deno_moment/master/"
        ]
     }
  }
  

Без npm я не могу поставить консольную утилиту глобально!

Ну, вообще можете ^[4]. deno install это аналог npm install --global. Deno скачает, скомпилирует требуемую библиотеку в бинарник и сохранит глобально. Отличие в том, что вы обязаны выдать библиотеке какие-то разрешения. То есть, установленный глобально пакет не получит доступа к сети, или к файлам, или ещё куда без вашего согласия.

Странное чувство дежавю

И оно не без основательно. Deno это тот же NodeJs. Я вижу лишь несколько отличий:

• Автор Deno отбросил обратную совместимость. Что позволило ему реализовать те же вещи, с использованием не собственного велосипеда, а велосипеда описанного в спецификации языка. Уверен, если бы вышел какой-то «Node-next» без обратной совместимости, мы бы получили примерно то же самое, что предлагает Deno. И NodeJs постепенно двигается в этом направлении: все новые фишки ES (как то ES-модули, top-level-await, и т.п.) постепенно внедряются в NodeJs.
• Отказ от общего списка зависимостей. Это может быть как плюсом так и минусом. Зависит от конкретных случаев. Но нельзя отрицать, что такая архитектура имеет право на существование.
• Идея запрещать скрипту доступ к системе без явного разрешения.

Вот и все отличия на мой взгляд. Так что не вижу причин ненавидеть Deno. Разве что его агрессивных пиарщиков :)

Автор: Kozack

Источник ^[5]