Deno

Deno 개발 환경과 Deno 자체는 아직 미숙하며, 프로덕션 환경에 사용해서는 안 됩니다.

Deno의 개발 기간을 고려했을 때, 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

잦은 멈춤, LSP에서 CPU 급증 · Issue #943 · denoland/vscode_deno

조금 규모가 있는 Deno 프로젝트는 LSP의 응답 속도를 느리게 하여, Deno를 사용하려는 개발자들을 쉽게 이탈시킵니다.

이에 비해, Node.js 및 TypeScript 기반 프로젝트는 유사한 문제가 전혀 없습니다.

Deno의 LSP 기본 설정은 상당히 보수적입니다. 예를 들어, =documentPreloadLimit=의 기본값은 1000이며, 실제 개발에서는 쉽게 초과될 수 있습니다.

WHATWG 스트림 모델의 설계는 상당히 조악하며, Node.js의 스트림에 훨씬 미치지 못합니다.

예를 들어, 사용자는 스트림이 닫혔는지, 언제 닫혔는지조차 알 수 없습니다.

모듈은 가져오는 방식에 따라 프로토콜이 결정됩니다.
모듈이 로컬 모듈로 가져와질 때, 모듈의 =import.meta.url=은 file 프로토콜을 가집니다.
모듈이 원격 모듈로 가져와질 때, 해당 =import.meta.url=은 http/https 프로토콜을 가집니다.

문제는 상당수의 API가 한 가지 프로토콜만 지원한다는 것입니다. 예를 들어 =Deno.readFile=은 file 프로토콜만 지원하며, http/https 프로토콜은 지원하지 않습니다.
이러한 상황은 개발자가 =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 확장자입니다.
따라서, Node.js 모듈을 위해 설계된 TypeScript 프로젝트의 코드는 Deno에서 실행될 수 없습니다.

TypeScript 5부터 allowImportingTsExtensions 설정 항목을 지원하여 프로젝트에서 .ts 확장자를 사용할 수 있게 되었지만,
이 설정 항목은 noEmit 또는 emitDeclarationOnly로 설정된 경우에만 사용하도록 제한됩니다.
이는 .ts 확장자를 사용하면서 Node.js에서 사용할 수 있는 코드를 생성할 수 없다는 것을 의미합니다.

Deno 공식이 추진하는 JavaScript 패키지 레지스트리입니다.
JSR은 현대적인 JavaScript 패키지 레지스트리임을 표방하지만, 여전히 Deno 버전의 npm에 불과합니다.
JSR은 TypeScript가 JavaScript의 상위 집합이 아니듯이, npm의 상위 집합이 아닙니다.

이 레지스트리는 Deno에 존재하는 의존성 관리 문제(Ryan Dahl이 2018년에 던진 부메랑이 마침내 자신에게 돌아옴)를 해결하기 위해 크게 만들어졌습니다.
다른 모듈은 서로 다른 레지스트리에서 의존성을 가져오거나, SemVer 부족으로 인해 동일한 레지스트리 의존성의 다른 하위 버전을 가져옵니다.
이것은 프로젝트의 볼륨 팽창(LSP 부하 증가)을 야기하고, 가져온 의존성 간의 참조 동등성 부족을 초래합니다.

Deno 공식은 기존 패키지 레지스트리인 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는 CDN을 통해 JSDOM을 가져올 수 있습니다.

import { JSDOM } from 'https://esm.sh/jsdom@22.1.0'

https://github.com/b-fuze/deno-dom

이 프로젝트는 Rust의 html5ever 패키지의 바인딩입니다.

Deno FFI를 사용하는 SQLite.

장점:

인터페이스가 better-sqlite3와 거의 동일합니다.
고성능입니다.

WASM으로 컴파일된 SQLite.

장점:

최소 권한.
크로스 플랫폼.

단점:

Deno 파일 시스템 API의 제약을 받습니다.
기본적으로 활성화된 컴파일 옵션이 매우 적어, 직접 컴파일해야 할 가능성이 큽니다.

Deno 1.21부터 표준 라이브러리는 상당한 테스트 기능을 제공하여,
대부분의 경우 서드파티 라이브러리를 사용하지 않고도 테스트를 완료할 수 있습니다.
Deno의 이러한 기술 선택은 Node.js 테스트의 벤더 종속성 문제를 효과적으로 피했습니다.

현재 표준 라이브러리는 BDD 스타일, mock/stub, 스냅샷 매칭, 타이머 시뮬레이션을 이미 지원합니다:
https://deno.land/std@0.181.0/testing

https://github.com/denoland/deno_std/issues/1779

Deno는 프로젝트를 단일 스크립트 파일로 번들링하는 내장 명령 =deno bundle=을 제공합니다.

Ryan Dahl은 한때 이 명령을 삭제할 것을 제안했지만, 이 아이디어는 나중에 철회되었습니다.
그러나 v1.31에서는 이 명령이 커뮤니티 논의 없이 갑자기 사용 중단으로 분류되었고, 공식 매뉴얼에서는 esbuild 사용을 권장했습니다.

v2.4에서 deno bundle은 알 수 없는 이유로 복귀했으며, 그 내부적으로는 esbuild를 사용합니다.
v2.5에서는 HTML 파일을 번들링의 진입점으로 지원합니다.

deno run 명령으로 스크립트를 실행할 때, TypeScript 타입 검사기가 로드되어 deno 프로세스가 더 많은 메모리를 사용하게 됩니다.
=deno compile=을 통해 먼저 컴파일한 후 실행하면, 스크립트의 메모리 사용량이 현저히 개선됩니다.