автор:Павильон принца LeanCloud
DenoBorn with a halo — это было опубликовано в докладе основателя Node.js Райана Даля «Design Mistakes in Node(слайд-шоу)», в то время некоторые люди говорили, что Node.js будет крутым, но я так не думал.
Родной TypeScript
Фактически, в настоящее время мы используем TypeScript в «пользовательском режиме» движка без каких-либо проблем, и это дает пользователям большую гибкость. Учитывая, что TypeScript не может покинуть экосистему JavaScript — ведь движок всегда поддерживает JavaScript, плюс TypeScript имеет разные версии и разные ключи компиляции, использование TypeScript в пользовательском режиме можно назвать лучшим решением. TypeScirpt рано или поздно станет историческим багажом Deno.
С точки зрения производительности V8 уже много работал над JavaScript до того, как появился TypeScript.Магическая оптимизацияСейчас можно сказать, что код из JIT не намного хуже, чем из других статически типизированных языков, и нет возможности повысить производительность просто через TypeScript. Кроме того, как упоминалось ранее, движок всегда должен поддерживать JavaScript, а семантика времени выполнения TypeScript по-прежнему остается JavaScript (TypeScript не гарантирует, что фактический тип объекта не будет изменен во время выполнения), поэтому движок не может переключиться с волшебная оптимизация JavaScript в типы на основе TypeScript для оптимизации.
менеджер пакетов
Я всегда считал NPM одним из лучших менеджеров пакетов, и это включает в себя сохранение зависимостей в каталоге проекта — настройка зависимостей одного проекта, не беспокоясь о влиянии на другие проекты; каждый пакет может указывать свою собственную версию зависимостей, что позволяет использовать несколько версий. сосуществовать — при обновлении зависимостей пакета, не затрагивая другие пакеты, каждый пакет может использовать новую версию или продолжать использовать старую версию; NPM отвечает за поиск и установку пакетов, в то время как Node.js Используя эти пакеты с относительно простыми протоколами, они могут развиваться независимо друг от друга.
Видно, что NPM в конечном итоге значительно облегчает умственную нагрузку разработчиков, при правильном использовании вы редко будете сталкиваться с проблемами, связанными с управлением зависимостями в других языках. Дено, с другой стороны, делает обратное. Хотя Deno также предоставляет некоторые связанные функции (deno cache), но вы обнаружите, что первоначальное намерение Deno по-прежнему не заключалось в «управлении зависимостями».
Включение URL-адресов в код — очень плохая практика (в том числе и на Golang), Deno называет это децентрализацией, но это просто повторно связывает код, использующий пакет, с исходным кодом пакета (теперь Deno предоставляетофициальный агент, но чем это отличается от центрального репозитория NPM). Механизм кэширования также вносит значительную неопределенность:package-lock.jsonЭто может гарантировать, что зависимости каждой установки будут точно такими же, и Deno'slock.jsonМожет только проверить, изменились ли зависимости (и отказаться от запуска, если они есть). Это затрудняет разработчикам контроль времени обновления зависимостей,Deno рекомендует помещать кеш зависимостей в Git.
Встроенная система разрешений
Общие языки программирования никогда не вводили контроль разрешений на уровне языка, но это правда, что сообщество открытого исходного кода сообщало о многих случаях вредоносного кода, но механизм разрешений Deno довольно грубый — контроль разрешений может выполняться только на уровне процесса. , я могу смело предсказать, что нам нужен --allow-all почти во всех сценариях, мало что делает для безопасности.
Нам нужно учитывать, являются ли пользователи Deno разработчиками или пользователями: для пользователей сценариев Deno, конечно, основное внимание уделяется разрешениям на уровне процесса; я думаю, что разработчиков больше беспокоят разрешения сторонних пакетов и система разрешений должна принимать пакет как единое целое (однако в Deno нет понятия пакета), в Node также есть модуль vm, который может в определенной степени добиться песочницы (но его действительно очень сложно контролировать).
Более того, теперь у нас есть полная изоляция и механизм контроля разрешений, такой как Docker (или более широкая концепция контейнеров), и в отрасли нет большого спроса на язык программирования для введения набора контроля разрешений.
изолированная экология
Можно сказать, что экология JavaScript исходит из полной конкуренции библиотек классов пользовательского режима, а Deno предоставляет стандартную библиотеку (похожую на Runtime API).golang.org/x), предоставляет полный набор цепочек инструментов разработки (fmt, test, doc, lint, bundle), пытаясь обеспечить нестандартный опыт, он также ослабляет стороннюю экосистему.
Поскольку Node.js и NPM уже стали частью стандарта де-факто для JavaScript, Deno могла бы начать очень хорошо, будучи совместимой с Node.js или NPM. Но Deno решил провести линию от Node.js и вместо этого совместим с некоторыми API-интерфейсами среды браузера (такими как приглашение или загрузка).
Собственное заявление Deno состоит в том, чтобы избегать изобретения новых вещей, чтобы следовать существующим веб-стандартам, но на самом деле эти веб-стандарты не разрабатываются с достаточным учетом среды выполнения вне браузера, и Deno фактически не может избежать изобретения новых вещей (эти новые вещи помещаются в пространство имен Deno).
резюме
Deno — это такая среда выполнения JavaScript с очень четкими личными предпочтениями.Он пытается исправить некоторые «ошибки проектирования» Node.js, надеется предоставить «лучшую практику JavaScript» и надеется обеспечить высокое качество и нестандартность. Стандарты коробок Библиотеки и наборы инструментов. Всегда будут люди, которым нравятся или не нравятся эти предпочтения, но помимо этого в Deno действительно не хватает убийственной функции, которая заставила бы «рационального» разработчика Node.js (например, компанию) переключиться на Deno.
С однофайловым распространением и контролем разрешений на уровне процесса Deno будет более подходящим для разработки инструментов командной строки, но сомнительно, сможет ли он конкурировать с Golang, который широко используется в инструментах командной строки.
Как разработчик Node.js, я не думаю, что Deno сможет заменить Node в качестве моего основного инструмента разработки в будущем.Deno больше похож на вторжение философии дизайна Golang в JavaScript.
Оригинальный адрес:Нам не нужен Дено