▲

Deno 2.8

 (deno.com)
1P by GN⁺ 4시간전 | ★ favorite | 댓글 1개
  • deno add와 deno install 이 CLI에서 접두사 없는 패키지 이름을 기본적으로 npm: 패키지로 처리해, 기존 Node 프로젝트에서 npm install·yarn·pnpm install 대신 쓰기 쉬워짐
  • deno audit fix가 npm 의존성 취약 패키지를 버전 제약을 만족하는 가장 가까운 패치 버전으로 자동 업그레이드하며, 메이저 버전 변경이 필요한 항목은 별도로 보여줌
  • 새 하위 명령으로 deno ci, deno pack, deno transpile, deno why, deno bump-version가 추가되어 재현 가능한 설치, npm 배포용 tarball 생성, TS→JS 변환, 의존성 경로 추적, 워크스페이스 버전 갱신을 지원함
  • Node.js API 호환성이 Node 자체 테스트 스위트 기준 Deno 2.7의 약 42%에서 Deno 2.8의 76.4%(3,405/4,457)로 상승했고, 많은 node: 모듈이 지연 로드되어 해당 모듈을 쓰지 않는 프로그램의 시작이 빨라짐
  • 성능은 Deno 2.7.1 대비 콜드 npm 설치가 3,319ms에서 906ms로 3.66배 빨라졌고, node:buffer base64는 3.07배, node:http 처리량은 2.21배, node:crypto scrypt는 2.12배 개선됨
  • 호환성 변경으로 전역 setTimeout과 setInterval이 숫자 대신 Node의 Timeout 객체를 반환하며, 반환값을 number로 저장하거나 타입 검사·산술에 사용하던 코드는 NodeJS.Timeout 등으로 수정해야 함
  • TypeScript 6.0.3이 내장되고 deno check, LSP가 기본적으로 lib.node를 포함해 NodeJS.*, Buffer, process 같은 Node 타입을 별도 설정 없이 해석함
  • 디버깅에서 Chrome DevTools Network 탭이 Deno의 fetch(), node:http/node:https, WebSocket 트래픽을 표시하고, --cpu-prof, --cpu-prof-flamegraph, --cpu-prof-md로 V8 프로파일·SVG 플레임그래프·Markdown 리포트를 생성할 수 있음
  • 패키지·워크스페이스 관리에 catalog: 프로토콜, deno install --os --arch, --prod, nodeModulesLinker: "hoisted", .npmrc의 min-release-age, --package-json이 추가되어 모노레포 버전 통일, 크로스플랫폼 설치, 프로덕션 설치, 기존 Node 프로젝트 이전을 보완함
  • deno compile 은 Next.js, Astro, Fresh, Remix, SvelteKit, Nuxt, SolidStart, TanStack Start, Vite SSR 프로젝트를 감지해 deno task build를 실행하고 적절한 진입점을 생성하며, 대형 npm 의존성 트리 처리 중 진행 상황도 표시함
  • 테스트와 Web API에서는 Deno.test()의 sanitizeOps·sanitizeResources 기본값이 false로 바뀌고 per-test timeout과 함수 단위 coverage가 추가됐으며, OffscreenCanvas, 전송 가능한 Headers·Request·Response·Streams, SHA3 digest, P-521 Web Crypto 지원이 들어감
  • 업그레이드와 런타임 기반은 deno upgrade가 가능한 경우 delta 업데이트로 다운로드를 약 48MB에서 3~6MB로 줄이고, deno upgrade pr <number>로 PR 빌드를 설치할 수 있으며, V8은 14.6에서 14.9로 올라감

함께 보면 좋은 글 β

▲
GN⁺ 4시간전  [-]
Hacker News 의견들

  • Deno는 기본 권한 모델이 있어서 유용하고, Rust로 작성됐으며, TypeScript를 네이티브로 지원함
    웹 개발/Node/Bun 생태계에 깊진 않지만 몇 년간 작은 서비스에 Deno를 만족스럽게 써왔음. Bun이 빠르게 성장하는 것처럼 보이는 이유가 궁금함. 주로 번들러로 쓰이고 JavaScript 런타임으로는 덜 쓰이는 건지 모르겠음
    권한 시스템 하나만으로도 Deno가 매력적인데, Node에서 Bun으로 옮기면서 Deno로 가지 않는 이유가 잘 이해되지 않음

    • Deno와 Bun은 출시 당시 초점이 꽤 달랐음. Deno는 Node의 원 제작자인 Ryan이 Node에서 잘못됐다고 본 많은 부분을 고치려 했고, Bun은 처음부터 Node 호환성과 Next.js 같은 인기 프레임워크 실행에 집중했음
      오랫동안 많은 의존성과 프레임워크가 Deno에서 제대로 동작하지 않았고, 초기에는 npm에서 의존성을 설치하는 기능조차 없었음. npm 공급망 공격들을 돌아보면 Ryan의 판단이 맞았을 수도 있음
      그래서 Bun은 설정이 훨씬 적게 필요하면서 바로 동작하는, 편의 기능이 많은 더 나은 Node처럼 보였음. Deno 팀도 성공하려면 Node 호환성이 필요하다는 걸 깨닫고 지난 몇 년간 거기에 집중한 듯함. 지금은 Deno가 Bun보다 Node와 더 호환된다고 봄
    • 작은 TypeScript 사이드 프로젝트를 시작할 때 npm/yarn/berry/pnpm/bubble/vite/webpack/rollup/rolldown/rollout/swc/esbuild/teatime 같은 바다에 빠지는 대신 Bun 하나만 쓰면 됨
      참고로 저 중 일부만 Pokémon 기술이고, 나머지는 실제 JS/TS 생태계 도구임
    • 둘 다 쓰고 좋아함. Bun은 Node의 드롭인 대체재에 가까움
      테스트 설정, tsconfig, ES 모듈 같은 걸 건드리고 싶지 않을 때 그냥 동작하는 편임. Deno는 표준 라이브러리가 좋고 CLI 지원도 훌륭하며, 예전에는 deno deploy도 좋아했지만 요즘은 꽤 번거로워졌음
    • 주로 백엔드 개발자지만 개인 프로젝트에서 프론트엔드를 조금 만질 때는 Deno가 가장 합리적인 선택처럼 보임
      작업하기 정말 좋고, JS 쪽 사람들 사이에서 더 크게 퍼지지 않은 게 아쉬움
    • Deno를 1년쯤 썼고 앞서 말한 장점들 때문에 마음에 들었지만, Astro, Prisma, Vite 같은 패키지와의 호환성 문제가 너무 많았음
      그래서 Bun으로 옮겼고 훨씬 매끄러워졌음

  • Deno가 요즘 어떤 상태인지 궁금함
    Node는 안정적인 해법이고 앞으로도 계속 남을 것임. 이제 TypeScript도 쓸 수 있고, 곧 네이티브 의존성까지 포함해 앱을 단일 실행 파일로 빌드할 수 있게 될 듯함
    Bun은 혼란스럽지만 빠르고, 표준 라이브러리에 모든 걸 포함하는 접근이 흥미로움. 게다가 Anthropic에 인수됐음
    Deno는 샌드박스와 서드파티 의존성 가져오기의 쉬움이라는 멋진 이야기가 있었지만, 샌드박스는 이제 꽤 범용화된 느낌이고 import 방식도 결국 npm add보다 그리 훨씬 좋았는지는 모르겠음

    • Deno는 약 2개월 전에 회사의 절반 정도를 해고했음: https://news.ycombinator.com/item?id=47467746
    • Anthropic에 인수된 걸 누가 긍정적으로 보나?
    • 생태계가 정체되지 않게 하려면 선택지가 여러 개 있는 게 좋음
    • 이미 단일 실행 파일 배포는 가능함. 내 제품의 CLI는 Node 단일 실행 파일 애플리케이션임
    • 네이티브 의존성까지 포함한 단일 실행 파일 빌드가 가능해진다니 몰랐음. 그건 강력한 기능임

  • Deno는 훌륭함. 작은 웹 서비스와 중간 규모 웹 서비스를 Deno로 작성하고 있음
    스위스 시계처럼 잘 돌아가고, 프로젝트 철학도 Unix 정신과 잘 맞음
    개인적으로 Deno 만든 사람들이 조금 겸손하다고 봄. 감사한 사용자들이 프로젝트에 기부를 제안해도 정중히 거절함. 이유는 이해하지만 장기적으로 프로젝트에 불필요한 금전 압박을 만들 수도 있음
    프로젝트의 장기 성공에 의존하는 사용자를 위한 “제발 돈 좀 받으세요”식 월간 구독은 꽤 잘 맞을 수 있음

    • 정말 쓰는 즐거움이 큼. 거의 JavaScript와 Go의 혼합처럼 느껴짐
      빠르고 유연하며, 다른 JS/TS 대안보다 더 강력한 기능을 가진 조금 더 제정신인 패키지 관리, 더 나은 보안 모델, 더 나은 표준 라이브러리를 제공함. 그리고 아주 빠름

  • Deno라는 이름이 익숙하지 않은 사람들을 위해 말하면, Deno는 JavaScript와 TypeScript 런타임임
    Deno 2.6을 경쟁자인 Bun 1.3, Node.js 25와 비교한 리뷰가 있음: https://www.devtoolreviews.com/reviews/bun-vs-node-vs-deno-2...

    • Bun이 웹 요청 처리에서 그렇게 훨씬 빠르다는 게 놀라움. 글에서는 Zig를 요인으로 들지만, 메모리 세밀 관리만으로 Node 대비 2배 이상 이득을 얻는 건지 궁금함
      비슷하게, 명확히 말하진 않았지만 Bun은 따뜻한 패키지 캐시 상태로 실행한 것처럼 보임. 다른 런타임들도 캐시가 있었는지 궁금함

  • Deno의 꾸준한 릴리스 주기는 인상적임. 이번 버전에 어떤 성능 개선이 들어갔는지 기대됨

  • 새 deno pack 명령은 안전하고 단순한 패키징을 위한 좋은 추가 기능임
    Node.js를 쓰는 경우 비슷한 단일 명령은 https://www.npmjs.com/package/ts-node-pack로 가능함
    이제 Node.js가 .ts 모듈 가져오기를 지원하므로, 더 많은 저장소가 빌드 단계나 체크아웃에 빌드 산출물을 넣지 않고도 이를 사용할 수 있음

    • 이 블로그 글을 보며 바로 고민하게 됨. deno pack이 내 오픈소스 패키지의 기존 npm publish 흐름을 대체하고, 작업을 Deno 우선/Deno 중심으로 계속 옮기는 데 좋을 수도 있음
      반대로 Node의 TypeScript 지원이 커지고 있으니 TypeScript 전용 npm 패키지로 바꾸는 것도 생태계에 보내는 아주 작은 메시지가 될 수 있다고 봄
      그래도 JSR이 비교적 더 깔끔한 생태계로 존재하는 건 반가움
    • 오래전부터 있던 DNT(https://github.com/denoland/dnt)와 꽤 비슷하게 들림
      다만 Deno CLI 안에 들어오면 가시성이 크게 올라감

  • Deno가 초기 가치를 조금만 더 오래 붙잡고 있었다면, Node 호환성 압박은 AI 에이전트가 어느 정도 메워줬을 것 같음
    그 압박의 상당 부분은 숙련도 문제에서 나오기 때문임. express.js로만 설정하는 법을 안다면, 이후의 어떤 도구나 런타임도 “매끄러운” 전환을 위해 비슷한 추상화를 제공해야 한다고 느끼게 됨. 첫 해법이 애초에 얼마나 나빴는지와는 무관함
    요즘은 제품과 함께 필요한 기술 묶음을 전달하면서 개발자에게 새 기술을 소개할 수 있고, 이게 실제로 문서를 대체하기도 하며 더 나은 대안 접근을 보여주는 데 꽤 좋을 때도 있음

    • SaaS 업체에서 받은 JS/TS SDK가 수정 없이 Deno에서 동작하지 않으면, 그걸 고치려고 1초도 쓰지 않을 것임

  • 여러 취미 프로젝트에서 Deno를 써본 입장에서, Deno가 JS 생태계가 향해야 할 방향이라고 확신함
    다만 업무에서 특정하고 대부분 범위가 좁은 사용 사례 밖에 추천하기는 복잡함. 어느 순간 프로젝트가 사업적 이유로 방향을 바꾸면 결국 Node가 필요해짐

  • Edge.js [1] 출시 이후 Deno가 Node.js 호환성을 더 진지하게 다루기 시작한 게 보기 좋음
    약 2개월 만에 40%대에서 75% 정도로 올라갔으니 우연이든 아니든 올바른 방향으로 가는 분명한 단계임
    Deno 팀 모두 수고했음
    [1] https://edgejs.org/

    • 자기 홍보가 지겹지도 않나?

  • 대부분의 Node식 관용을 감싸고 Deno를 런타임으로 씀. 잘 동작함
    프로젝트가 순수 TypeScript라면 그냥 Deno로 실행함. 보안을 위한 추가 옵션도 좋고 설치 스크립트가 기본으로 비활성화되는 점도 좋음
    Node를 직접 쓰고 있다면 그만두길 바람. 최소한 Bun은 쓰는 게 낫다고 봄
    에이전트 기반 작업에서는 Rust와 TypeScript 외의 것을 쓸 이유가 거의 없음. 이견은 가능하지만 타입 안전성, 메모리 안전성, 방대한 작업 말뭉치가 중요함. 에이전트는 까다로운 오류와 내장된 패턴이 있어야 쉽게 탐색함. UI에는 디자인 예제가 워낙 많기 때문에 TypeScript가 가장 타당함

답변달기