Node.js는 자바스크립트로 서버 측 코드를 작성할 수 있는 장기 실행 프레임워크입니다. 2009년에 처음 출시된 이 프레임워크는 최근 몇 년 동안 상당한 성장과 함께 사용량이 폭발적으로 증가했습니다.
Deno는 서식 스타일, 가져오기 구문 및 패키지 관리에서 차이가 있지만 동일한 엔지니어가 동일한 엔진에서 이러한 경쟁 프레임워크를 구축했습니다.
오늘날 Deno는 많은 개발자의 스택에 자리 잡을 만큼 오랫동안 존재해 왔습니다. 새로운 자바스크립트 프로젝트를 시작하려는 경우 어떤 것이 올바른 선택인지 궁금할 수 있습니다.
Node와 Deno의 특징
Node가 출시된 지 거의 9년이 지난 지금, 개발자인 Ryan Dahl은 새로운 프로젝트를 발표했습니다: Deno입니다. 한때 서버 측 자바스크립트를 위한 유일한 옵션이었던 Node에 대한 대안으로 Deno가 등장했습니다.
Node.js와 Deno는 여러 면에서 매우 유사합니다. 둘 사이의 차이점은 대부분 내부에서 발생합니다. Node가 V8 JavaScript 엔진에서 실행되는 반면, Deno는 성능에 중점을 두고 Rust로 구축된 맞춤형 엔진 위에서 실행됩니다.
둘 사이의 주요 차이점은 대부분 각 언어가 지원하는 기능에 기반합니다. 모듈, 린팅, 타입스크립트 및 패키지 관리는 모두 두 언어 간에 상당히 다르게 처리됩니다.
모듈 임포트: CommonJS 대 ES
Node.js는 기본적으로 require() 구문과 함께 CommonJS 모듈을 사용합니다. 하지만 사용자가 원할 경우 구성 파일을 변경하여 import() 구문으로 ECMAScript 모듈을 사용하도록 변경할 수 있습니다.
// This Is A Valid CommonJS Module Import In Node.js
var _ = require("lodash");
// This Is A Valid ECMAScript Module Import In Node.js
import _ from 'lodash';
두 가지 유형의 ES 모듈 로딩 간에는 상호 운용성이 일부 제한되어 있으며 일부 ECMAScript 모듈은 require() 구문을 사용하여 포함할 수 있습니다. 각 가져오기 유형은 모듈을 약간 다르게 처리하지만 대부분의 경우 두 유형 모두 작동합니다.
프로젝트를 만들 때 외부 모듈을 포함하기 위해 선호하는 방법을 선택할 수 있습니다.
Deno는 프로젝트에 외부 모듈을 포함할 때 다른 접근 방식을 취합니다. Deno는 모든 모듈에 include() 구문을 사용하지만, Node의 임포트와 달리 Deno에서 임포트한 모듈은 모든 위치에서 가져올 수 있습니다. 이러한 위치에는 원격 콘텐츠 전송 네트워크(CDN)도 포함될 수 있습니다.
// This Is A Valid Import Statement In Deno
import "https://deno.land/x/[email protected]/dist/lodash.js";
이렇게 하면 로컬이든 원격이든 모든 위치에서 종속성을 가져올 수 있으므로 훨씬 더 유연하게 사용할 수 있습니다. Node.js의 기존 require 구문으로 작업하는 것을 선호하는 경우, 해결 방법으로 Deno에서 자체 폴리필 require 함수를 작성할 수 있습니다.
타입스크립트 코드 지원
타입스크립트는 지난 몇 년 동안 그 인기가 점점 높아지고 있으며, 조만간 그 인기가 둔화될 조짐은 보이지 않습니다. 자바스크립트에 타입 안전 코드 다이내믹스를 도입하는 것은 매우 성공적인 시도임이 입증되었습니다.
오늘날 새 TypeScript 프로젝트를 설정하거나 기존 Node.js 프로젝트를 TypeScript로 변환하는 것은 다소 시간이 걸리기는 하지만 간단합니다.
TypeScript 지원 추가는 이제 대부분의 최신 프레임워크가 어떤 형태로든 TypeScript를 지원할 만큼 대중화되었습니다. Angular는 즉시 사용 가능한 TypeScript 지원으로 그 길을 선도했습니다. 오늘날에는 React에도 TypeScript 지원을 설정하는 메서드가 있습니다.
Deno는 생산성 향상을 위해 TypeScript 지원이 포함되어 설계되었습니다. 즉시 사용 가능한 타입스크립트 지원으로 Deno는 타입스크립트 코드를 개발하는 데 필요한 최소한의 설정도 필요하지 않습니다.
TypeScript를 좋아한다면 Deno의 지원으로 빠르고 쉽게 시작할 수 있지만 표준 Node.js 라이브러리 중 일부가 누락되어 있을 수 있습니다. Deno는 더 빠른 설정을 제공하지만, 에코시스템이 개발되지 않아 빌드 프로세스에 방해가 될 수 있습니다.
깔끔한 코드 생성을 위한 린팅
Node.js에는 선택할 수 있는 다양한 린터가 있습니다. 빠르고 쉽게 설치 및 구성할 수 있는 잘 개발된 옵션이 많이 있습니다. 그러나 TypeScript의 경우와 마찬가지로 원하는 린터를 시작하려면 약간의 노력이 필요합니다.
Deno는 코드 포맷에서 약간 다른 경로를 택하여 .js, .ts 및 .md 파일에 대한 자체 내장 린팅 솔루션이 함께 제공됩니다. “deno fmt” 명령을 실행하면 현재 작업 디렉터리에 있는 모든 파일이 자동으로 포맷됩니다.
기본 린터가 마음에 들지 않는다면 Node에서와 마찬가지로 원하는 포맷 시스템을 설치하여 실행할 수 있는 옵션이 있습니다. Deno의 린터는 기본 빌드 파이프라인의 일부가 아닌 외부 명령을 통해 실행되므로 시스템 전환은 간단합니다.
Deno의 린터를 새로운 시스템으로 교체하려는 경우, 잠재적인 호환성 문제를 인지하고 이를 염두에 두어야 합니다. 대부분의 자바스크립트 린터는 포맷 중인 프로젝트가 실행 중인 시스템이 아니더라도 실행하려면 Node를 설치해야 합니다.
패키지 관리
Node 패키지 관리자(npm)는 최신 개발자들 사이에서 매우 잘 알려져 있습니다. Python의 Pip과 Ruby의 RubyGems와 같은 유사한 시스템의 성공을 기반으로 npm은 빠르게 인기를 얻었습니다.
계속되는 우려로 인해 pNPm 및 Yarn과 같은 경쟁 관리자가 개발되었습니다. 심지어 Node와 함께 여러 패키지 관리자를 설치하여 사용하는 경우도 있습니다.
오늘날 Node.js로 개발하기로 선택했다면 패키지 관리와 관련하여 선택의 폭이 다소 좁아졌습니다. Node는 다양한 패키지 설치 옵션을 갖춘 번성하는 에코시스템을 자랑합니다. 현재 메인 npm 레지스트리에는 130만 개가 넘는 패키지가 있습니다.
Npm을 사용하면 자신만의 패키지를 게시할 수 있어 엄청나게 큰 라이브러리를 구축할 수 있습니다.
Deno는 패키지 관리에 대해 완전히 다른 접근 방식을 취했습니다. 패키지 관리 시스템이 없거나 필요하지 않습니다. 대신 Deno는 개발자 시스템뿐만 아니라 HTTP 요청을 수락하는 모든 위치에서 외부 라이브러리를 직접 가져올 수 있습니다.
이를 통해 Deno의 리포지토리 또는 온라인 CDN의 코드베이스에서 직접 라이브러리를 가져올 수 있습니다.
Deno의 공식 패키지 레지스트리는 Node가 9년 가까이 먼저 시작한 덕분에 Node만큼 완벽하게 개발되지는 않았습니다. 어디서든 라이브러리를 가져올 수 있는 기능 덕분에 아직 완전한 규모로 성장하지 못한 생태계로 인해 발생하는 문제를 겪지 않아도 됩니다.
Node와 Deno에 대한 커뮤니티 참여
Ryan Dahl이 2009년에 처음 출시한 Node는 개발자 커뮤니티가 참여할 수 있는 충분한 시간을 가졌습니다. 많은 얼리 어답터와 공식 저장소에 저장된 상당한 규모의 패키지 라이브러리를 자유롭게 사용할 수 있기 때문에 대중은 Node.js의 성장에 대해 많은 발언권을 가졌습니다.
플랫폼 자체는 완전한 오픈 소스이며, OpenJS 재단과 많은 기여자가 유지 관리합니다.
Deno는 Node보다 거의 9년 뒤인 2018년에 출시되었습니다. 주로 Ryan Dahl이 Node를 구현하면서 느꼈던 우려와 아쉬움을 해결하기 위해 개발했습니다. 현재 Deno는 MIT 라이선스에 따라 오픈소스로도 제공되고 있습니다.
많은 기여자와 자체 리포지토리로 성장하고 있는 Deno는 커뮤니티의 많은 관심을 받고 있습니다.
두 프레임워크의 성능 문제
두 프레임워크의 상대적인 성능 차이에 관심이 있는 코더라면 두 프레임워크 간에는 거의 차이가 없습니다. Rust로 작성된 Deno의 커스텀 엔진은 여전히 V8 엔진인 핵심 프레임워크에 오버레이됩니다. 궁극적으로 Deno와 Node는 거의 모든 경우에서 성능 면에서 비슷합니다.
이는 결과 코드가 서버에서 실행되는지 클라이언트에서 실행되는지 여부에 관계없이 마찬가지인 것으로 보입니다. 성능 수율이 결정에 고려되지 않으므로 가장 편한 프레임워크를 자유롭게 선택할 수 있습니다.
두 프레임워크의 창시자인 Ryan Dahl은 Deno를 만든 다양한 이유를 제시했습니다. 그는 많은 API에서 프로미스를 제대로 통합하지 못한 것부터 선택한 빌드 시스템에 이르기까지 여러 가지 요인을 언급했지만, 성능은 그 과정의 일부가 아니었습니다.
노드 대 Deno: 어떤 것이 올바른 선택일까요?
내부를 들여다보면 Node.js와 Deno는 놀라울 정도로 유사한 프레임워크입니다. 둘 다 비슷한 성능과 기능을 갖춘 V8 엔진을 사용하여 JavaScript를 실행합니다. 구문, 패키지 관리 및 기본 제공 지원에는 약간의 차이가 있지만, 어느 것을 사용할지는 주로 사용자의 선호도에 따라 결정됩니다.
Node는 엄청나게 큰 에코시스템을 자랑하지만 Deno를 사용하면 모든 소스에서 종속성을 가져올 수 있습니다. 궁극적으로 자신의 개발 스타일을 면밀히 살펴보고 어떤 플랫폼이 더 적합한지 결정해야 합니다.