Попытаюсь ответить на общие и частные вопросы, и возможно развенчать некоторые мифы, потому как очень много авторов статей прыгнули на этот хайп трейн, и под копирку вышло очень много статей. А некоторые ответы, например Раяна , были вырваны из контекста.
В дино тс из коробки, а в ноде надо настраивать. Настраивается быстро и просто. Не считаю, полезной фичей
Не знаю из какой статьи эта фраза, но думаю тож вырвано из контекста. И все таки хочется дать какой то комментарии. Возможно тут упор идет на новичков, которым не приходилось ранее работать со всякими сборщиками и лоадерами. Не говоря уж о простом запуске tsc. Да, кому то действительно это не нужно, у многих давно есть свои инструменты CLI, которые это делают, и многие даже не задумываются что происходит под капотом. Кроме того дополню что команды Deno CLI включают многие вещи, которых действительно не было в экосистеме Node из коробки. Что я имею ввиду - когда я разрабатывал на .NET все было включено, так же из коробки, и не нужны были мне те же, например, линтеры, потому как было заранее решено что и как должно быть. Эта такая простая аналогия на deno fmt.
Нет центрального репозитория и не нужен package.json. При этом предлагается описывать importMap
Ну тут идет сравнение с не сравнимым. import-maps это не про центральный репозитории. https://github.com/WICG/import-maps это отдельная спека призванная контролировать поведение импорта. Эту задачу ранее решал тот же systemjs.
Про package.json Раян это описывал как мусорную и не нужную вещь, потому как там лишние описания и к тому же всякие скрипты. Но в среде разработчиков Deno сложилась практика, что зависимости обычно указывают в deps.ts
Пару слов про то что нет центрального репозитория. Для любителей таких репозиториев уже существует несколько приватных и публичных реп. Которые призваны контролировать ваш процесс.
Общий кэш скачанных модулей на всю систему При этом зависимости проекта предлагается хранить в репозитории. Явное протворечие
Это же из разряда, а что если завтра npm закроют. Тут каждый решает как ему вести разработку. Допустим из практики, при работе в секретной сети вам никто доступа наружу не даст, и своего снимка npm тоже не будет, поэтому чем ближе ваши зависимости, тем лучше будете себя чувствовать. Ну и как пример, того что было на самом деле у меня на работе, разрабатывали в сети интернет, скачали все зависимости, вроде ок. Перенесли на машину без интернета, ничего не работает. Как оказалось, один из пакетов, почему то требует дополнительные ресурсы. В случае с Deno думаю, этого бы просто удалось избежать.
В дино можно сразу использовать .ts, а в жс нужно много чего типизировать
Начнем с того, что в ноде много чего есть и его нужно только типизировать. Причем много нового сразу пишется на тс. На дино экосистема пока сильно меньше
Ну js код ты тоже можешь запустить в Deno. Никаких таких ограничений нет. И проблем использования кода с npm так же нет, если это ES модуль и не использует Node Standart API. А если эта зависимость не ES, то смело можно воспользоваться jspm, который налету преобразует тебе в ES module. Например так был сделан мной https://github.com/alosaur/handlebars только часть для работы с fs на Deno. Но тем не менее Deno хочет поддержать больше Node Standart API, тот же require там работает. Нпример так const require = createRequire(import.meta.url);
Полный список совместимости можно найти здесь: https://github.com/denoland/deno/tree/master/std/node
Подключение модулей по урл безопаснее, чем с центрального репо, который могут отключить Что будет если в момен деплоя дино приложения модуль по урл будет недоступен?
А что будет если npm будет не доступен в вашем регионе? А что если автор пакета решил удалить его из npm? А что если администрация npm решит передать ваш пакет в чужие руки по решению суда или же по письменному заявлению юриста? (это все реальные случаи) Это те самые вопросы на которые прежде всего вам нужно ответить вам самим, и как вы справляетесь в этих случаях. Скорее всего в текущих реалиях вы решаете это административным образом.
Компилятор тс зашит в дино Зачем? (Понимаю, что by design) А если на разных проектах нужна разная версия тс?
Если это необходимо, и так исторически сложилось, вам скорее всего нужна будет смена версии Deno, а там как раз и смена версии ts. Тут вопрос наверно больше про сторонний код который не обновлялся, и у него есть BREAKING CHANGES самой ts. Ждать обновлений этого кода, идти и говорить обновись. Не считаю это серьезной проблемой. Все будет как и везде, популярные проекты обновятся быстро.