Deno 안정 버전은 약 3~4년 전에 소개되었습니다. 당시 Node.js의 창시자인 Ryan Dahl이 바로 Deno의 후원자였기 때문에 상당한 주목을 받았습니다. 뭐! 당신은 그 말을 들었습니다. 왜 그는 자신의 '아이'와 경쟁하기 위해 새로운 도구를 만들었을까?
Ryan Dahl은 Node.js에 심각한 약점이 있음을 인정했습니다. 처음에 Node.js는 단순성과 유연성에 중점을 두고 설계되었습니다. 그러나 수년이 지나면서 모든 것이 통제할 수 없게 되었습니다. Node.js는 매우 강력하게 발전하여 더 많은 주목을 받았고 사람들이 이 떠오르는 별에 모든 것을 담으려고 할수록 필요 이상으로 복잡해졌습니다.
Deno는 Node.js의 약점을 보완하기 위해 탄생했습니다. 하지만 출시 당시에는 강점을 제대로 발휘하지 못했다. Node의 가장 큰 장점 중 하나인 npm 지원이 부족하다는 점은 말할 것도 없고 성능도 Node.js보다 열등했습니다. 이로 인해 상황이 점점 더 어려워졌습니다.
호기심이 많은 저는 Deno를 사용하여 몇 가지 코드 조각을 빠르게 실험해 보고 도서관 시스템과 관련된 불편함을 깨달았습니다. "와, 내가 좋아하는 라이브러리가 이 플랫폼에 등장하려면 시간이 오래 걸릴 것 같아요. 모든 것이 새롭고 낯설게 보입니다."라고 생각했습니다!
블로그를 "철폐하고 재구축"하기 시작하면서 모든 것이 바뀌었습니다. 기술 선택에 대해 여러 번 망설이고 고민한 끝에 Fresh라는 이름이 탄생했습니다. 그러나 Fresh에는 런타임 환경으로 Deno가 필요합니다. 이전 배포 경험이 없지만 "그냥 JavaScript 런타임 환경일 뿐이야!"라고 생각합니다. 나에게 더 많은 자신감을 주었다. 다음 이야기는 이 글입니다.
오늘은 데노와 작업하면서 느끼는 '좋아요' 포인트 5가지를 정리해보겠습니다.
Deno는 기본적으로 TypeScript를 지원합니다. 이는 다른 라이브러리가 일반적으로 수행하는 것처럼 .js로의 변환 단계를 거치지 않고 .ts 파일을 직접 실행할 수 있음을 의미합니다. 많은 사람들이 이것이 ts-node와 같은 TypeScript 코드를 실행하는 도구를 사용하는 것과 다른지 궁금해합니다. 대답은 확실히 '예'입니다. 왜냐하면 ts-node는 복잡한 경우에 작동하려면 TypeScript 구성 파일이 필요하지만 Deno는 그렇지 않기 때문입니다. TypeScript에 대한 기본 지원은 .ts 코드를 직접 실행하는 프로세스를 단순화합니다.
저는 종종 사소한 작업을 처리하기 위해 스크립트를 작성합니다. 새 스크립트를 만들 때마다 항상 .js와 .ts 중 하나를 선택해야 합니다. 그리고 Deno가 등장했을 때 .ts가 기본 선택이 되었습니다. Node 프로젝트에서도 빠른 작업을 수행하기 위해 스크립트를 작성해야 할 때 여전히 .ts를 선택하고 Deno를 사용하여 해당 코드를 실행하는 것을 선호합니다.
일반적인 JavaScript/TypeScript 프로젝트 또는 특히 Node.js에 더 많이 참여할수록 제가 항상 궁금하거나 심지어 짜증나는 점은... 구성 파일이 너무 많다는 것입니다. 각 프로젝트에는 이름이 다른 파일이 있습니다. package.json, package-lock.js 및 프로젝트에서 Typescript를 사용하는 경우 추가 tsconfig.js에서... webpack, vite, tailwind, postcss와 같은 몇 가지 항목을 더 구성해야 하는지는 말할 것도 없고... 이런 ! 처음에는 낯설어서 프로젝트에 등장하는 각 구성 파일의 의미와 사용법을 이해하기 위해 "도대체 어떻게 이렇게 수백 개의 구성 파일을 만들 수 있지?"라고 욕하면서 읽어야 했습니다.
Deno로 옮겼을 때 구성 파일이 전혀 없다는 사실에 놀랐습니다. 즉, 아무런 구성 없이도 프로젝트를 실행할 수 있다는 뜻입니다. 초현실적으로 들리죠? 있는 경우 이는 단일 deno.json 파일일 뿐입니다. Deno는 많은 복잡한 구성을 교묘하게 제거하거나 단일 json 파일에 배치했습니다. 또 이상한 이름이 나올 걱정 없이 프로젝트를 열 수 있어서 정말 다행이에요!
Deno는 Web API를 최대한 지원해왔고 지금도 노력하고 있습니다. 웹 API는 브라우저에서 사용할 수 있는 표준화된 API 세트입니다. Web API에 대한 우수한 지원을 통해 Deno에서 실행되는 프로그램을 한 번만 작성하면 어디서나 실행이라는 패러다임에 따라 브라우저에서도 실행할 수 있습니다. 이는 "유니버설" 라이브러리의 길을 열어줍니다.
Serverless, 특히 Cloudflare Workers로 작업해 본 적이 있다면 Workers가 Node.js와 완전히 호환되지 않으므로 노드별 라이브러리를 사용하는 것이 작동하지 않을 가능성이 높다는 것을 알고 계실 것입니다. 반면에 라이브러리가 웹 API를 사용하거나 웹 API와 호환되면 원활하게 실행됩니다. 이는 데노에도 적용됩니다.
Node API 지원을 통해 Deno는 npm에서 대부분의 "패키지"를 실행할 수 있습니다. 따라서 더 이상 호환성 걱정 없이 npm 패키지를 자유롭게 사용할 수 있습니다.
Node 프로젝트를 시작할 때 기본적으로 사용자의 모든 권한을 갖게 된다는 분명한 사실이 있다는 것이 꽤 이상합니다. 이는 프로그램이 사용자를 대신하여 시스템에서 자유롭게 파일에 액세스하거나 명령을 실행할 수 있음을 의미합니다. 꽤 위험하지 않나요? 실수로 다른 사람의 프로젝트를 먼저 확인하지 않고 "실행"하여 시스템의 모든 데이터를 스캔하고 일부 서버로 다시 보내거나 몸값을 받기 위해 모든 파일을 암호화한 다음 인생이 망가졌다고 생각한다고 상상해 보십시오. 수정했어요!
Deno는 애플리케이션을 실행할 때 권한을 요청하는 플래그를 추가하여 이 결함을 해결합니다. 권한에는 파일 액세스, 인터넷 액세스 등이 포함될 수 있습니다. 프로그램이 파일 시스템에 액세스하거나 인터넷에 연결하려면 최소한 권한을 요청해야 합니다. 예:
$ deno run --allow-read --allow-write --allow-net index.ts
"요청"해야 할 권한이 많이 있습니다. 자세한 내용은 보안 및 권한 | 데노 문서. 가장 빠른 방법은 -A 또는 --allow-all 플래그를 사용하여 모든 권한을 허용하는 것입니다.
방금 소개되었던 초기 시절이 기억납니다. Deno는 프로그램 성능 면에서 Node.js에 뒤처지는 것 같았습니다. 특히 벤치마크 테스트에서는 동일한 프로그램을 실행할 때 Deno와 Node의 차이가 나타났습니다. Deno는 항상 부족했습니다. 어느 순간 갑자기 bun.sh가 나타났습니다. Bun은 성능 측면에서 두 Node.js를 모두 능가했기 때문에 현상으로 나타났습니다. 이로 인해 데노가 더욱 무미건조해 보였습니다.
실제로 Bun을 사용하여 일부 Node 애플리케이션을 실행할 때 꽤 많은 문제와 심지어 버그가 발생했습니다. 롤빵은 "생산"할 준비가 되지 않은 것 같습니다. 그래서 당시 안정성을 좋아하는 사람들에게는 여전히 Node가 선택이라는 결론을 내렸습니다.
최근 Deno 2.0이 출시되면서 이 "검은 공룡"의 성능을 향상하고 프로그래밍 경험을 향상시키기 위해 많은 노력이 이루어졌습니다. 최근 공개한 문서에 따르면 Deno는 잘 알려진 Node, Bun과 비교했을 때 모든 면에서 단연 돋보이는 제품입니다.
이상은 제가 데노와 작업할 때 좋아하는 점들입니다. Deno Deploy를 무료로 제공하여 애플리케이션을 배포하는 등 몇 가지 추가 기능이 있습니다. 하지만 아직도 가끔 성능과 모듈 시스템, Node.js와의 낮은 호환성을 '비판'하는 기사를 접하게 됩니다. 이러한 제한 사항은 최신 2.0 버전에서 해결되었습니다. Deno를 처음 출시했을 때와 비교해서 제 관점이 달라졌는데, 앞으로 Deno가 커뮤니티에서 더 많은 관심을 받고 더 많은 발전을 이루길 바랍니다.
당신은 어떻습니까? 디노 써보셨나요? 이 JavaScript 런타임 환경에 대해 칭찬이나 비판이 있습니까? 아래에 의견을 남겨주세요!
위 내용은 내가 Deno를 좋아하는 이유의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
