Deno
Среда разработки Deno и сам Deno достаточно «сырые» и не должны использоваться в производственной среде.
Учитывая время разработки Deno, команда Deno показала себя не лучшим образом,
настолько, что Node.js постепенно догоняет Deno по функциональности, а также появились конкуренты в той же нише, такие как Bun.
Трудно быть уверенным в будущем Deno.
настолько, что Node.js постепенно догоняет Deno по функциональности, а также появились конкуренты в той же нише, такие как Bun.
Трудно быть уверенным в будущем Deno.
- Разработан на Rust.
- API максимально совместим с веб-средой.
- Имеет предписывающие `deno fmt`, `deno lint`, `deno test`, `deno bench`.
- Безопасен по умолчанию, имеет гранулированную систему разрешений, поддерживает динамический запрос разрешений.
В настоящее время, из-за большого количества внутренних полей Deno, использование гранулированных разрешений может быть очень неудобным, и в итоге придется перейти на использование крупнозернистых разрешений. - Встроенная поддержка TypeScript, что становится все более важным, поскольку сообщество JavaScript переходит на TypeScript.
- Совместимость с Node.js.
Встроенные функции Deno, как правило, не проходят строгого тестирования, полагаясь на отзывы сообщества о выявлении ошибок.
Хотя срок LTS во всех проектах, похоже, сокращается, заявление Deno 2 о 6 месяцах как LTS при выпуске все еще вызывает смех.
Deno Land Inc. стремится разрабатывать клоны/альтернативы продуктов из других экосистем.
Эти продукты явно недостаточно продуманы, и их ремонтопригодность вызывает сомнения.
Эти продукты явно недостаточно продуманы, и их ремонтопригодность вызывает сомнения.
Эта тенденция также повлияла на сам Deno, например, совместимость с Node.js является типичным примером того, как маркетинговый ажиотаж преобладает над реальной реализацией:
https://docs.deno.com/runtime/reference/node_apis/#fully-supported-modules
https://docs.deno.com/runtime/reference/node_apis/#fully-supported-modules
Даже проекты Deno небольшого размера могут привести к замедлению отклика LSP, что легко отпугнет разработчиков, желающих использовать Deno.
Напротив, проекты, основанные на Node.js и TypeScript, полностью лишены подобных проблем.
Конфигурация LSP Deno по умолчанию довольно консервативна, например, значение по умолчанию для `documentPreloadLimit` равно 1000, что легко превышается в реальной разработке.
Модель потоков WHATWG имеет довольно упрощенный дизайн, значительно уступающий потокам Node.js.
Например, пользователь даже не может узнать, закрыт ли поток и когда он был закрыт.
Модуль определяет свой протокол в зависимости от того, как он был импортирован.
Когда модуль импортируется как локальный, `import.meta.url` модуля имеет протокол `file`.
Когда модуль импортируется как удаленный, его `import.meta.url` имеет протокол `http/https`.
Когда модуль импортируется как локальный, `import.meta.url` модуля имеет протокол `file`.
Когда модуль импортируется как удаленный, его `import.meta.url` имеет протокол `http/https`.
Проблема в том, что довольно многие API поддерживают только один протокол, например, `Deno.readFile` поддерживает только протокол `file` и не поддерживает `http/https`.
Эта ситуация создает дополнительную когнитивную нагрузку для разработчиков при использовании `import.meta.url`.
Основная проблема заключается в том, что Deno не раскрывает локальный путь импортированных модулей (кэша), хотя это проблема, которую можно решить на уровне дизайна.
Эта ситуация создает дополнительную когнитивную нагрузку для разработчиков при использовании `import.meta.url`.
Основная проблема заключается в том, что Deno не раскрывает локальный путь импортированных модулей (кэша), хотя это проблема, которую можно решить на уровне дизайна.
https://github.com/denoland/deno/issues/5987
Довольно печально, что Deno решает проблемы, связанные с чтением файлов, позволяя функции `fetch` поддерживать протокол `file`.
https://github.com/denoland/deno/issues/3196
TypeScript не поддерживает компиляцию путей модулей с расширением `.ts` в расширение `.js`,
в то время как пути модулей Deno обязательно имеют расширение `.ts`.
Следовательно, код проектов TypeScript, разработанных для модулей Node.js, не будет работать в Deno.
в то время как пути модулей Deno обязательно имеют расширение `.ts`.
Следовательно, код проектов TypeScript, разработанных для модулей Node.js, не будет работать в Deno.
TypeScript 5 начал поддерживать параметр конфигурации `allowImportingTsExtensions`, который позволяет использовать расширение `.ts` в проекте,
но этот параметр ограничен использованием только при конфигурации `noEmit` или `emitDeclarationOnly`,
что означает, что при использовании расширения `.ts` невозможно генерировать код, пригодный для Node.js.
но этот параметр ограничен использованием только при конфигурации `noEmit` или `emitDeclarationOnly`,
что означает, что при использовании расширения `.ts` невозможно генерировать код, пригодный для Node.js.
Официальный реестр пакетов JavaScript, продвигаемый Deno.
Хотя JSR позиционирует себя как современный реестр пакетов JavaScript, он по-прежнему является лишь версией npm для Deno.
JSR не является надмножеством npm, так же как TypeScript не является надмножеством JavaScript.
Хотя JSR позиционирует себя как современный реестр пакетов JavaScript, он по-прежнему является лишь версией npm для Deno.
JSR не является надмножеством npm, так же как TypeScript не является надмножеством JavaScript.
Этот реестр в значительной степени предназначен для решения проблем управления зависимостями, существующих в Deno (бумеранг, брошенный Райаном Далем в 2018 году, наконец, попал в него самого):
Различные модули импортируют зависимости из разных реестров, либо из-за отсутствия SemVer импортируют разные подверсии зависимостей из одного и того же реестра.
Это приводит к раздуванию размера проекта (увеличивая нагрузку на LSP) и отсутствию равенства ссылок между импортированными зависимостями.
Различные модули импортируют зависимости из разных реестров, либо из-за отсутствия SemVer импортируют разные подверсии зависимостей из одного и того же реестра.
Это приводит к раздуванию размера проекта (увеличивая нагрузку на LSP) и отсутствию равенства ссылок между импортированными зависимостями.
Deno официально заявляет, что старый реестр пакетов deno.land/x по-прежнему можно использовать,
но, учитывая, что официальная стандартная библиотека `std` в deno.land/x больше не обновляется, ожидать дальнейшей публикации пакетов в deno.land/x бессмысленно.
но, учитывая, что официальная стандартная библиотека `std` в deno.land/x больше не обновляется, ожидать дальнейшей публикации пакетов в deno.land/x бессмысленно.
Теперь можно (как было добавлено в Deno 1.28 для поддержки модулей npm) использовать специальный префикс `jsr:`, что упрощает URL.
https://github.com/oakserver/oak
https://fresh.deno.dev/
Полнофункциональный веб-фреймворк, выпущенный Deno официально в 2022 году, является аналогом Next.js.
Не рекомендуется использовать его, потому что:
- Почти ни одна библиотека React не тестируется на поддержку Deno.
- Внутри используется легковесный вариант React - Preact, что является бесперспективным технологическим направлением.
Deno может импортировать JSDOM через CDN.
import { JSDOM } from 'https://esm.sh/jsdom@22.1.0'https://github.com/b-fuze/deno-dom
Этот проект является привязкой пакета html5ever для Rust.
SQLite с использованием Deno FFI.
Преимущества:
- Интерфейс практически идентичен better-sqlite3.
- Высокая производительность.
SQLite, скомпилированный в WASM.
Преимущества:
- Минимальные разрешения.
- Кроссплатформенность.
Недостатки:
- Ограничено API файловой системы Deno.
- По умолчанию включено очень мало параметров компиляции, скорее всего, потребуется самостоятельная компиляция.
Начиная с Deno 1.21, стандартная библиотека предоставляет довольно много функций для тестирования,
что позволяет в большинстве случаев выполнять тестирование без использования сторонних библиотек.
Этот технический выбор Deno эффективно избегает проблемы привязки к поставщику в тестировании Node.js.
что позволяет в большинстве случаев выполнять тестирование без использования сторонних библиотек.
Этот технический выбор Deno эффективно избегает проблемы привязки к поставщику в тестировании Node.js.
Текущая стандартная библиотека уже поддерживает стиль BDD, mock/stub, сопоставление снимков, имитацию таймеров:
https://deno.land/std@0.181.0/testing
https://deno.land/std@0.181.0/testing
https://github.com/denoland/deno_std/issues/1779
Deno предоставляет встроенную команду `deno bundle` для упаковки проекта в один файл сценария.
Райан Даль предлагал удалить эту команду, но позже эта идея была отозвана.
Однако в v1.31 эта команда была помечена как устаревшая без обсуждения сообществом, а в официальном руководстве рекомендовано использовать esbuild.
Однако в v1.31 эта команда была помечена как устаревшая без обсуждения сообществом, а в официальном руководстве рекомендовано использовать esbuild.
В v2.4 deno bundle необъяснимо вернулся, используя esbuild в основе.
В v2.5 добавлена поддержка HTML-файлов в качестве точки входа для сборки.
В v2.5 добавлена поддержка HTML-файлов в качестве точки входа для сборки.
При запуске скрипта командой `deno run` загружается проверщик типов TypeScript, что приводит к увеличению потребления памяти процессом deno.
Если сначала скомпилировать с помощью `deno compile`, а затем запустить, потребление памяти скриптом значительно улучшится.
Если сначала скомпилировать с помощью `deno compile`, а затем запустить, потребление памяти скриптом значительно улучшится.