Deno

1. 개요[편집]

---

Node.js의 창립자인 라이언 달이 만든 자바스크립트 및 타입스크립트 런타임이다.
JS Fest 2019 Spring 컨퍼런스에서 공식 발표했으며, 2020년 5월 13일 버전 1.0이 출시되었다.#

2. 이름[편집]

---

Node.js의 node의 애너그램이다. 음절 단위로 앞뒤를 바꾼 것. 처음으로 공식 소개되었던 JS Fest 2019 Spring 에선 [데노]라고 발음하였으나, 이후 많은 사람들이 [디노]라고 읽기를 더 선호하며, 로고에 공룡으로 보이는 동물이 있는 점 등을 고려해서 디노로 발음하기로 잠정적으로 합의되는 것으로 보인다.

3. Node.js와의 차이점[편집]

---

Node.js와 비교되는 Deno의 주요 특징은 JSConf EU 영상에서 확인할 수 있다. 번역된 내용

3.1. Promise[편집]

---

Node.js에 내장된 여러 비동기 로직은, 모던 자바스크립트에서 지원하는 비동기 API인 Promise를 사용하지 않고 옛날 방식인 콜백 패턴으로 작동한다. 이로 인해 Node.js 어플리케이션을 작성하려면 콜백 지옥 형태의 코드를 짜거나, 아니면 주요 비동기 로직들을 적절히 감싸서 사용해야 한다.
반면 Deno는 기본적으로 내장된 비동기 로직들이 모두 Promise로 만들어졌다.

3.2. 보안 문제[편집]

---

Node.js에서 자바스크립트 엔진으로 사용되는 V8은 크롬에서 사용되는 엔진과 동일하며, 그 자체로 훌륭한 샌드박스 모델을 가지고 있다. 하지만 Node.js는 이걸 제대로 사용하지 않고 있고, 파일 입출력이나 네트워크 같이 애플리케이션 외부에 액세스하는 데 별다른 제한을 두지 않는다. 개발자가 모든 코드를 작성한다면 그럭저럭 큰 문제는 아닐 수도 있겠지만, 외부 라이브러리를 사용하게 된다면 해당 라이브러리가 애플리케이션 개발자 모르게 머신의 파일 시스템에 접근하거나 네트워크 자원을 사용할 우려가 있다. (그리고 실제로 그런 사례가 발생하기도 했다)
Deno는 라이브러리별로 특정 디렉토리에 대한 읽기/쓰기 권한, 네트워크 접근 권한 등을 설정할 수 있도록 만들어졌다.

3.3. 빌드 시스템[편집]

---

처음 Node.js를 만들 때는, 크롬 브라우저가 GYP라는 메타 빌드 시스템을 사용하다가 GN으로 업그레이드했었는데, Node.js는 그 사이에 발전한 Node.js 생태계에 대한 호환성 등의 이유 때문에 GN으로 변경하지 못했다. 참고로 구글의 GN을 소개하는 시스템에서는 20배 정도 빠르게 빌드가 된다고 한다. (메타 빌드 시스템은 여러 플랫폼―윈도우, Mac, Linux―에서 소스 코드를 빌드하기 위해서 사용되는 빌드 시스템이다.)

3.4. 모듈 시스템[편집]

---

Node.js는 모듈 시스템을 가지고 있다. 최근에는 이 모듈 시스템을 관리하는 프로그램은 서드 파티 프로젝트로 떼어 놓는 것이 일반적인데, 노드는 npm이라는 패키지 매니저가 관리하는 package.json 파일을 main 함수에서 찾도록 함으로써 생태계가 npm에 의존하도록 발전했다. package.json과 node_modules에 기대는 모듈 시스템은 필요 이상으로 복잡하고 어렵고 무거워졌다.
Deno는 외부 라이브러리의 리포지토리 url을 임포트하는 방식으로 사용한다.

npm의 라이브러리를 안정적으로 다운로드 할 수 있는 레지스트리 역할을 대신해, 현재 재단에서 deno.land/x 라는 deno 호환 라이브러리들에 대한 레지스트리를 운영하고 있다.

3.5. 모듈 로딩 시스템[편집]

---

모듈을 가져오는 코드에서 .js 확장자가 생략 가능해지고, 특정 폴더의 index.js 파일은 폴더까지만 경로명을 쓰면 생략이 가능한 기능이 있는데, 이는 .ts와 같은 .js가 아닌 확장자를 쓰는 것과 같은 상황에서 모듈 로더가 사용자의 의도를 파악하기 위해 경로 내 파일을 스캔하는 것과 같은 많은 연산을 필요로 한다.
Deno에서는 이러한 자잘한 경로 생략 기능이 사라져 모듈의 경로명과 실제 해당 모듈의 위치의 상관관계가 더 명확해졌다.

3.6. 사용되는 언어[편집]

---

Node.js는 C++로 작성되어 있으며, 자바스크립트만을 실행할 수 있다. 타입스크립트와 같은 자바스크립트의 방언은 직접 실행하지 못하고 Babel과 같은 트랜스파일러에 의해 번역된 뒤 실행된다. 인터프리터 언어임에도 불구하고 타입스크립트를 사용할 땐 사실상 컴파일 언어처럼 작동하게 되는 것이다. 반면 Deno는 Rust로 작성되었으며, 자바스크립트 외에 타입스크립트도 네이티브처럼 실행이 가능하도록 하는 것을 목표로 삼고 있다. 내부적으로는 자바스크립트로 트랜스파일링되어 되어 V8엔진으로 돌아가는 것은 노드와 같지만, 각종 최적화를 거쳐서 퍼포먼스도 훨씬 좋고 별도로 타입스크립트 컴파일 세팅을 할 필요도 없다. 또한 여기에 공식 타입스크립트 컴파일러인 tsc 대신 Rust로 작성된 컴파일러인 SWC를 이용하여 퍼포먼스를 더욱 끌어올리려는 시도를 하고 있는 중이다. # 본래 타입스크립트만 지원되도록 할 예정이었으나, 시스템 바인딩 과정에서 자바스크립트가 반드시 필요한 부분이 있어서 완전히 자바스크립트 파트를 없애지는 못했다.

4. Fresh[편집]

---

홈페이지
Deno 에서 공식적으로 추진 중인 풀스택 웹 프레임워크. 프론트엔드는 React 와 비슷하면서 가벼운 Preact를 기본적으로 사용하며, 백엔드는 자체적으로 개발한 프레임워크다. 기존의 프론트엔드 SSR 프레임워크인 Next.js 및 Nuxt.js 포지션과 비슷하지만, 기술적인 유사성에 대해서는 Blazor Server 에 가까울 수 있다.
제공하는 특징은 다음과 같다.

• 빌드가 필요 없다.
• 설정이 없어도 동작할 수 있다.
• JIT 방식의 렌더링. 사용자는 그저 최종 결과물인 HTML, CSS, 최종 JS 결과물만 받고 브라우저에서 렌더링 한다.
• 작고 빠르다. 즉, 별도의 종속성이 없다.
• 개별 컴포넌트에서 클라이언트 단 상태관리(client side hydration)도 가능하도록 지원.
• 기본 브라우저 기능을 사용하여 점진적인 향상을 꾀하는 높은 복원력
• Deno 답게 TypeScript 기본 지원
• Next.js 같은 파일 방식의 라우팅 지원

Next.js 가 Vercel Deploy 를 지원하고 이를 위해 만들어졌듯, Fresh 또한 Deno Deploy를 지원하고 이를 위해 만들어졌다. 일종의 경쟁 관계인 셈.

5. 발전상황[편집]

---

2021년 3월 29일, Deno 프로젝트 관리를 맡는 기업인 Deno Company가 창립되었다. Deno의 창시자인 라이언 달이 회사 창립 멤버에 포함되어있으며, Deno의 라이선스는 MIT를 유지하겠다고 한다.

2021년 6월, 타입스크립트, JSX, Deno 기반 서버사이드 풀스택 SaaS 서비스인 Deno Deploy 가 베타 오픈되었다. 오픈소스인 Deno의 개발비용을 안정적으로 수급하기 위해 만든 비즈니스 모델로 보인다.

2021년 8월, MDN (모질라 개발자 네트워크) 자바스크립트 API문서의 호환성 테이블에 Deno가 추가되었다.

2021년 12월, Deno Company가 ECMA International 와 산하 소속인 TC39위원회의 회원이 되었다. 자바스크립트 표준스펙을 작성하는 위원회에서 약간의 발언권을 가지게 된 것이다.