Deno가 JavaScript의 미래인가?

대략 지난 1년 동안 새로운 자바스크립트가 실행되었을 때 사람들의 관심을 끌었다.Deno는 JavaScript가 실행될 때, 많은 면에서 NodeJS보다 호환성이 높습니다.이 화제에 관한 많은 글이 있지만, 이것은 나 개인의 미래에 대한 견해가 될 것이다.

호환성
노드의 한 가지 문제는 이전 호환 기능, 예를 들어 최초RequireJS에 만들어진 require 및 기타 작은 문제들이다. 이것은 브라우저에서 호환되지 않을 뿐만 아니라 (전단과 후단 개발에 사용) ECMAScript 규범을 심각하게 위반했기 때문이다.
내가 보기에, 이것은 데노가 성공한 분야 중의 하나이다.Deno는 require와 같은 것을 사용하지 않는다. 이것은 ECMAScript 규범 중의 것, 예를 들어 import을 사용한다. 그러나 뿐만 아니라 Deno의 목표는 규범을 매우 엄격하게 준수하는 것이다. 내가 알기로는 기능 요청을 거절하기도 한다. 왜냐하면 그들은 이전에 규범을 위반했기 때문이다.비록 이것은 어떤 경우에 제한을 받을 수 있지만, 이것은 그것이 어떤 것들과 매우 호환된다는 것을 의미한다. 왜냐하면 이것은 규범을 따르기 때문이다. 이외에, Deno는 브라우저에서 그것들을 포함하지 않고 호환하기 위한 것이다. builtin APIs

작은 발자국
Node의 특징 중 하나는 많은 파일이 설치되어 있다는 것이다. 이것은 완전히 정상적인 것이다.나는 결코 노드를 미워하지 않는다.그러나 이 점 때문에 제가 보기에 차지하는 공간이 필요한 범위를 넘어서 어떤 경우 공간을 절약할 수 있습니다. 저는 여기서 까다롭게 생각하지 않습니다. 왜냐하면 저는 C++ 개발과 라이브러리에 익숙하지 않고 NodeJS 코드 라이브러리에 익숙하지 않기 때문입니다. 저는 그저 그것을 사용할 뿐입니다.
디노에 대해서 말하자면, 이 일은 나로 하여금 개인적으로 놀라게 했다. 왜냐하면 나는 이 프로젝트를 듣기 전에 이미 여러 해 동안 노드를 사용했기 때문이다.Deno는 실행 파일일 뿐입니다.명령을 통해 프로그램을 설치하거나, GitHub에서 최신 버전을 다운로드할 때, 이것은 사실상 실행 가능한 파일일 뿐이다.이것은 어느 정도에 이 프로젝트가 Rust로 제작되었기 때문에 다른 좋은 점이 있지만, 우리는 본문 뒤에서 토론할 것이다.

패키지 관리
노드에 관해서는 항상 나를 화나게 하는 것이 하나 있다. 바로 가방 관리가 얼마나 많은 공간을 사용했는가이다.NPM은 훌륭한 패키지 관리자라고 오해하지 마세요. 아주 잘해요.그러나 한 가지 잘못한 것은 저장 공간을 절약하는 것이다. 예를 들어 실, PNPM 등 다른 대체품이 있다. 그들은 공간을 절약할 수 있다. 왜냐하면 그들은 이전에 다운로드한 가방을 캐시하기 때문이다. 만약에 기호 링크를 사용하여 가능한 한 공간을 절약하면 PNPM도 도태될 것이다.
다른 한편, Deno의 패키지 관리는 모든 프로젝트 모듈/패키지 폴더, 예를 들어 노드node_modules 폴더, Deno 저장과 캐시DENO_DIR 디렉터리에서 사용하는 모든 모듈보다 나에게 더 재미있다.이외에 "stock"deno 프로젝트에는 원본 파일이 없고 프로젝트의 원본 코드만 있습니다. 패키지 등록표나 유사한 것을 사용할 필요가 없기 때문입니다. (그것들 third party module listings 을 제외하고는 원격 URL을 통해 모듈을 가져오면 됩니다.

import {} from "https://deno.land/[email protected]/log/mod.ts";

타자 원고
나는 TypeScript를 좋아한다. 내가 처음 발표했을 때 그것을 발견한 이래로, 나는 그것을 사용해 왔다. 왜냐하면 위조 유형 안전은 놀라운 기능이기 때문이다. 기본적으로 사용import과 다른 ECMA 기능을 사용하고, 때로는 일반 노드보다 더 일찍 새로운 언어 기능을 얻기도 한다.그러나, 내가 싫어하는 것은 가방이나 모듈을 설치해야만 사용할 수 있다는 것이다. 또한, typescript를 실행하는 노드를 지원하지 않는 노드로 사용하려면 매번 원본 코드를 수동으로 컴파일해야 한다.일부 항목은 어느 정도에 이런 상황을 완화시킬 수 있다. 예를 들어 TSNode 노드에 TypeScript REPL을 제공하지만, 당신은 그것과 TypeScript를 동시에 설치해야 한다.
내가 가장 좋아하는 Deno 기능 중 하나는 TypeScript는 상자를 열면 바로 사용할 수 있다는 것이다. TypeScript 컴파일러는 실행할 때 내장되어 있기 때문에 TypeScript 파일을 실행하는 것은 매우 간단하다.모듈이나 패키지를 설치할 필요가 없습니다. 모든 것이 간단합니다.가장 중요한 것은 Denostandard library도 TypeScript로 작성된 것이다. 이것은 모든 것이 적당한 유형과 문서가 있다는 것을 의미한다. 코드가 예상대로 작동하기를 원할 때, 특히 표준 라이브러리이기 때문에 좋다!

생태계
나는 개인적으로 Deno 세계에서 부족한 것이 생태계를 포장하는 것이라고 발견했다.물론 소프트웨어 패키지가 있지만 프로젝트가 개발 초기(적어도 Node와 비교)였기 때문에 NPM/Node의 소프트웨어 패키지에 비해 소프트웨어 패키지가 많지 않다.만약에 우리가 그들의 제3자 목록 페이지를 보면 이 1049개의 가방을 작성할 때까지this website에 따르면 NPM에는 약 1402796개의 가방이 있다.이것은 매우 큰 차이다.이것은 아마도 내가 현재 보고 있는 디노의 주요 단점일 것이다.

녹 vs C++
이 부분은 대부분보다 작을 것이다. 왜냐하면 나는 C++ 개발에 가장 정통한 사람이 아니기 때문이다.하지만, 나는 녹슨 것에 대해 약간의 경험이 있다.내가 Deno를 매우 좋아하는 점은 Rust로 만든 것이다. 왜냐하면 C 시리즈 언어에 비해 Rust는 기본적인 불변성, 라인, 메모리 보안 등 많은 장점이 있기 때문이다.그럼에도 불구하고, 이 모든 검사는 비용이 들 수 있지만, 내 경험에 따르면, 최종 운행은 여전히 매우 빠르기 때문에, 당신은 그들의 benchmarks 를 검사해서 더 많은 정보와 데이터를 얻을 수 있습니다.

이게 미래야?
비록 나는 Deno가 부상하고 유행하는 운행이 되고 있을 때를 확신할 수 있지만 Node를 사용하는 라이브러리와 기술의 수량은 매우 크다. 운행할 때 무엇이든지 운행을 전환할 때 대량의 작업이다. 그리고 이를 바탕으로 Deno의 노드 호환성층이 아직 완전히 완성되지 않았기 때문에 Node에서 전환하는 것은 더욱 번거롭다.결국 Deno는 여전히 매우 작아서 현재 대부분의 프로젝트가 Node를 계속 사용할 가능성이 높다.그래서 적어도 몇 년 안에 디노의 사용 빈도가 지금보다 높지 않을 것이라고 생각한다.