Я был там, когда Райан Даль объявил Deno на JSConf EU 2018. Публика кипела. Снова вернулся почти через 10 лет, объявив об ошибках, которые он сделал с Node, и о том, как он их исправил. Объявляется анаграмма Node: Deno! TypeScript по умолчанию, безопасность по умолчанию, без npm, без привлекательности ради привлекательности. Мы любим новые блестящие вещи, которые могут заменить старые блестящие вещи, и это не было исключением. Сначала я не особо об этом думал. Мне не особо нравятся люди, дискредитирующие чужую работу (да, Райан Даль основал Node и очень талантлив, но не сделал Node тем, чем он является сегодня), и я не думаю, что он, считая их ошибками, обязательно делает их ошибки. Так что я как бы забыл о Дено. До выхода Deno 1.0.

Я сделал эпизод подкаста по этому поводу, поэтому мне пришлось вникнуть в него глубже. Оказывается, это очень интересно и очень хорошо. За два года своего существования он добился большого прогресса, и многие люди собрались вместе, чтобы создать несколько действительно изящных концепций. Это быстро, мне нравится интеграция TypeScript и то, как CLI создает определения типов, которые вы можете зарегистрировать в своем репозитории. Мне нравится стандартная библиотека, мне нравится Deno-global, и что она написана на Rust с возможностью создавать плагины для самой платформы. Мне также нравится простота URL-адресов как внешнего кода без необходимости использования централизованного репозитория. Мне очень нравится Дено. Но мне нравится то, что это не замена Node.

Почему бы не заменить Node?

Node - это платформа для написания приложений. Он начинался как способ написания сценариев и запуска сценариев локально, но с годами превратился в платформу для написания приложений. Мы делаем Node on the Cloud ™ и делаем Node на аппаратных модулях. Мы делаем Node везде. Архитектурные принципы Node позволяют нам масштабироваться от малого до большого уровня.

Deno - это переделка платформы для написания скриптов (что, на мой взгляд, она делает блестяще). Он решает проблемную область небольших наборов инструкций для выполнения одной конкретной задачи (и решает ее очень хорошо). Это частично совпадает с проблемной областью Node. Это впечатление также подтверждается руководством Deno:

Помимо прочего, Deno - отличная замена служебным скриптам, которые исторически могли быть написаны с помощью bash или python.

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

Я приведу вам один пример ограничения, который иллюстрирует отсутствие поддержки крупномасштабных реализаций приложений. Дело не в отсутствии инструментов сообщества, таких как PostCSS / SASS / Less или OpenID / OAuth (* возможно, они существуют, но их нет в базе данных Deno). Это неотъемлемая природа выбора, сделанного Deno: модули не загружаются локально, а называются URL-адресами, разрешаются во время установки / выполнения и кэшируются локально. Это невероятно удобно при написании сценариев, но является серьезным ограничением при создании более крупных модулей или приложений. Почему? Потому что это означает, что вы не можете взаимодействовать с файловой системой таким же образом, когда модуль опубликован. И, как оказалось, файловые системы очень удобны.

А при локальном запуске Deno упрощает копирование файлов, чтение файлов, запись файлов и взаимодействие с файловой системой. И все было на одном дыхании, поскольку я создавал инструмент командной строки для создания статического сайта из файлов Markdown. Я хотел скопировать папку со статическими активами из моего интерфейса командной строки в текущий рабочий каталог потребителя. Похоже, это сработало, как и ожидалось. Пока я не опубликовал модуль и не протестировал его как инструмент. При публикации модуля Deno вы размещаете файлы сценариев на статическом файловом сервере. Вы переходите от работы с локальной файловой системой (при разработке) к использованию HTTP (при публикации). Так что мое копирование больше не работало. И думать об этом имеет смысл. При разрешении модулей в удаленном месте вы не можете использовать файловую систему, поскольку протокол был изменен. Вместо открытия файлов вы теперь внутренне выполняете HTTP-запрос (выборку).

Для моей конкретной проблемы есть несколько способов справиться с этим, как я это вижу. Я мог бы использовать zip-файл. Но это потребует больше работы при локальном запуске и будет менее удобным для разработчиков. Или я мог бы проверить import.meta.url, используете ли вы файловую систему или нет.

const isModule = !import.meta.url.startsWith("file://");
async function getFileContents(name: string) {
  if (!isModule) {
    const decoder = new TextDecoder("utf-8");
    return decoder.decode(await Deno.readFile(src(name)));
  } else {
    const url = href(name);
    const data = await fetch(url);
    return data.text();
  }
}

Но это не работает с каталогами без ведения внутреннего реестра всех файлов. Еще один большой недостаток этого примера заключается в том, что вы в конечном итоге запускаете другой код при разработке и производстве. Это означает, что у вас гораздо больше шансов получить ошибки, не обнаружив их до развертывания кода (как это сделал я).

Deno оптимизирован для работы с отдельными файлами. При импорте следующего файла вы делаете только это: импортируете следующий файл. Этот файл может импортировать другой файл и так далее. Deno переместил модуль, разрешающий распространение через HTTP-запросы. Это идеально подходит для создания пользовательских скриптов. С другой стороны, Node работает от пакета к пакету. Он передает целые каталоги в виде tar-файлов для локального размещения в вашей файловой системе, а затем локально обрабатывает разрешение модуля. Это ключевое различие, поскольку Deno работает с файлами, а Node - с пакетами.

Это всего лишь один пример, но для меня он представляет собой большую архитектурную и философскую разницу. Deno не предназначен для работы таким образом. Он оптимизирован для работы локально, а не для наличия пакетов. Это соответствует платформе сценариев, а не платформе приложений.

Эти ограничения могут измениться. Это всего лишь технические препятствия, которые можно исправить. Но я не думаю, что это изменится, поскольку философская цель Deno - не быть платформой для приложений. Как и в случае с Node.js вначале, он пытается быть более чистым языком сценариев, чем платформой приложений. Таким образом, он не заменит Node и не намерен заменять его. Он может и во многих случаях должен заменить bash (обсуждение в другой раз). Имейте в виду, что у меня ограниченный опыт работы с Deno, и у меня нет прямой связи с командой Deno, чтобы узнать их философские убеждения. Я могу ошибаться. Но я так не думаю.

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

Ты думаешь иначе? Не стесняйтесь присылать мне твит на @mikaelbrevik или в ответ на этот пост.