Deno v1.0: Безопасная среда выполнения для JavaScript и TypeScript. Обзор возможностей

[dark_ruby]

очень напрягают импорты прям из интернетов

[justboris]

Ну почему ни одна статья про Deno не обходится без набросов на Node.js, причем необоснованных:

В Node.js es модули появились только в конце 2019 года, с версией 13.2.0, но даже тогда, поддержка осталась незрелая и она по-прежнему включена спорным расширением .mjs.

Незрелая – все познается в сравнении. Поддержку модулей уже вывели из-под флага даже для 12.x версии. Прогресс очевидно идет

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

[justboris]

Вся аргументация про нестабильность очень странная. Сегодня в NodeJS warning есть, поэтому едем на Deno, а через месяц warning уберут, поедем обратно?

[deril]

Все библиотеки, что работают с Node.js, могут так же работать с Deno, я правильно понимаю? Например, могу ли я запустить проeкт который разработан с использованием express.js на Deno или нужно всё писать с нуля, так как API не совместимы?

[jamak]

Если библиотека не завязана на стандартную библиотеку NodeJs, то конечно да.
В случае с expressjs то нет, потому как она как раз использует http и прочее.

Но, Deno все таки сделает поддержку стандартной библиотеки NodeJs, но только на ранней стадии.
Список совместимости, и то что уже реализовали тут:
github.com/denoland/deno/tree/master/std/node

[HawkeyePierce89]

В теории да, на практике вы будете получать кучу головной боли с тем, чтобы найти как вам заимпортить вашу любимую библиотеку из вашего любимого npm (постоянно искать альтернативный вариант подключения — киллер-фича, стреляющая в ногу), а если и найдёте, то готовьтесь получать ошибки при импорте.

API мало того что почти никак не совместимы, Deno из коробки ещё и не предоставляет API, которое в NodeJS есть из коробки.

[Stronger_myself]

Как успел уже заметить Ryan Dahl, не использование расширений при require, было ошибкой N1 при проектировании Node.js.

а индекс файлы? разрешено ли это:
import { assert } from "https://deno.land/std/testing"
где в "https://deno.land/std/testing" лежит "index.ts"

[jamak]

Нет, это было ошибкой N2 по его мнению

[justboris]

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

reverse=a=>a.sort(n=>1)
reverse([1,2,3])

• node (10.13.0): [3,2,1]
• deno (0.4.0) [1,2,3]
• chrome (74.0) [1,2,3]
• other browsers: [1,2,3]

На самом деле тут дело в движке V8 в котором поправили сортировку. Изменение конечно же попало в более новые версии NodeJS v11 и v12.

V8 пользуется и в Deno, и в Node. Непонятно в чем здесь именно заслуга Deno.

[mayorovp]

Открытым остаётся вопрос какой вообще смысл в вызове метода .sort с параметром n => 1

[justboris]

Чтобы показать какой node.js не очень, очевидно же.

А если серьезно, грабли обычно возникают, когда в массиве встречаются null и undefined, и приведение типов приводит к неожиданным результатам:

[null, 1, undefined].sort((a,b) => a < b)
// node 10.20.1
[1, null, undefined]
// node 12.16.3
[null, 1, undefined]

[monochromer]

Больше нет package.json, теперь принято использовать deps.ts

Но ведь и в package.json для Node.js можно написать пути до git-репозиториев с указанием ветки/теги/коммита, а не название пакета в централизованном хранилище.