The wall of configuration

For years I worked in Python and dreamed in Haskell on weekends. When I needed a script, Python. When I wanted the type system to hold me accountable, Haskell. Somewhere between the two sat TypeScript, and I knew it. Practical where Haskell is austere, typed where Python isn't. But I kept my distance. tsconfig.json, .eslintrc, .prettierrc, babel.config.js. Files you have to create before you've written a single line of actual code. Every time I thought about trying it, I looked at the list and gave up. The JavaScript ecosystem always felt to me like an amusement park where you have to wait in a long queue just to get inside.

Deno dissolved that queue. No configuration files, no node_modules, no agonizing over which package manager to use. Just deno run main.ts. The first time I actually wrote TypeScript properly, I couldn't understand why I'd put it off so long. What I'd been avoiding wasn't TypeScript. It was the ritual surrounding TypeScript.

What hooked me

At first I couldn't point to one killer feature. The appeal was that everything seemed to be pulling in the same direction. The fetch() I used in browsers worked the same way on the server. Web Crypto API was just there. MDN effectively became Deno's documentation. Instead of installing packages, you imported ESM by URL, thinking about dependencies in an entirely different way.

Having deno fmt, deno lint, deno test, deno bench, and deno check all in a single binary was part of the same logic. No installing ESLint, no wiring up Prettier, no untangling configuration conflicts between the two. That convenience had an attitude behind it.

The pattern was obvious enough: build on web standards, then ship the boring tools yourself.

Chasing Node.js

Today's Deno feels like it's drifting away from that.

npm: specifier support, node_modules back in play, node:* module compatibility. Then in Deno 2.8, deno add without a specifier now adds an npm package by default. JSR was introduced as an answer to npm's stagnation, as the future of JavaScript packaging. These decisions make that announcement look distant. I can understand each one in isolation. Put them together, though, and the shape is hard to ignore: Deno is spending more and more of its energy catching up to Node.js.

The OS/2 story comes to mind. IBM expected that building Windows compatibility into OS/2 would pull Windows users across. What actually happened was the opposite: developers realized they could target Windows and have it run on both platforms, so there was no reason to learn the OS/2 API separately. Deno pushing further toward Node.js compatibility has the same dynamic. The more compatible Deno becomes, the less reason library authors have to think about it specifically.

Meanwhile, Node.js has been walking toward Deno. TypeScript runs without flags as of v22. A permission model arrived in v20. fetch() and Web Crypto API are both there now. node:test and node:assert/strict have quietly become the best cross-runtime test harness for projects targeting Deno, Node.js, and Bun alike. The two runtimes are converging, but Deno seems to be doing more of the reaching.

Early Deno set the agenda. Web standards, the permission model, URL imports, JSR: Deno put these down and the ecosystem responded. What Deno is doing now runs in the opposite direction, catching up to what the ecosystem already has.

On the defensive

There's a more specific frustration here. Deno had a fight it could have led rather than chased.

What drove me away from the JavaScript ecosystem wasn't Node.js itself. It was the full combination: Node.js + npm + TypeScript + Vite + ESLint + Prettier + Vitest. That stack was the problem, and Deno was already doing well against it. deno fmt, deno lint, deno test, deno bench, deno check, and in 2.4, deno bundle came back. It had been deprecated once and then restored; that round trip is its own admission that the direction was right.

The most visible gap that remains is the dev server: HMR, live reload, an asset pipeline, and the plugin ecosystem that accumulates on top of all that. Fresh 2.0, Deno's own framework, chose not to fill that gap from within Deno and adopted Vite instead. That disappointed me. Making Vite run well on Deno and making Deno a self-sufficient development environment are two entirely different directions. Once your own framework makes that choice, you can't expect the wider ecosystem to go the other way.

But vertical integration alone might not have been enough. Individual component quality matters too. If deno lint and deno fmt were clearly better than ESLint and Prettier, developers would reach for them even in Node.js projects. That could have been the Trojan horse. Once enough projects are using Deno's tools without using the Deno runtime, the next question follows naturally. ESLint and Prettier seemed unmovable, and yet Biome and the Ox series (Oxlint, Oxfmt) are finding their footing. The market was always there. Better tools just weren't. Deno could have gotten there first.

The clock I keep thinking about

Why didn't Deno hold the course? This is speculation, but here's my read.

The integrated toolchain path required patience. Getting developers to feel the pain of configuration complexity, making Deno the place they move to, waiting for the ecosystem to grow comfortable with Deno's way of doing things. All of that takes time. Node.js is a community project under the OpenJS Foundation. There's no investor clock pushing it, and the project doesn't wobble if the ecosystem moves slowly.

Deno Land Inc. is different. A VC-backed company has a clock. How long that clock allows for a patient fight is not the same as what a community project can afford. Expanding Node.js compatibility produces visible results faster than the slow alternative. From the outside, I can't tell when I'm seeing a product decision and when I'm seeing a runway decision. What I can say is that the urgency Deno has been showing doesn't sit well with the direction it originally chose.

Even so

For all my griping, I still build most of my own libraries Deno-first. I publish to JSR even when I also publish to npm. I try to depend only on web standard APIs, and I use Deno's built-in tools for linting and formatting. I'm still rooting for Deno.

But even I have retreated in places. I now rely on node:test and node:assert/strict for testing, because it's the easiest way to run the same tests across Deno, Node.js, and Bun without any special dependencies. JSR was launched as an answer to npm's stagnation, and I've started to feel JSR stagnating too. I often catch myself wondering whether to drop it. I got excited about Deno KV and now I just use node:sqlite, which runs fine on Deno anyway.

If someone like me is already making these retreats, I wonder what Deno looks like to someone with no attachment to it at all. That worries me, because I still want Deno to win some version of this fight. I'm just less sure lately that Deno wants to win the same fight I signed up for.

자동 번역 · 원문 읽기

번역의 최신 여부를 확인할 수 없습니다.
이 번역이 원문의 최신 내용을 반영하는지 알 수 없습니다.

설정의 장벽

나는 수년간 Python으로 작업하고 주말에는 Haskell을 꿈꾸었다. 스크립트가 필요할 때는 Python. 타입 시스템이 나를 단속해 주길 바랄 때는 Haskell. 그 둘 사이 어딘가에 TypeScript가 있다는 걸 나는 알고 있었다. Haskell이 엄격한 곳에서 실용적이고, Python이 그렇지 못한 곳에서 타입을 갖춘. 그러나 나는 거리를 두었다. tsconfig.json, .eslintrc, .prettierrc, babel.config.js. 실제 코드를 한 줄도 작성하기 전에 만들어야 하는 파일들. 한번 써볼까 생각할 때마다 그 목록을 보고는 포기했다. JavaScript 생태계는 내게 항상 안으로 들어가려면 긴 줄을 서서 기다려야 하는 놀이공원처럼 느껴졌다.

Deno는 그 대기줄을 없애 버렸다. 설정 파일도, node_modules도, 어떤 패키지 매니저를 써야 할지 고민할 필요도 없었다. 그냥 deno run main.ts만 하면 됐다. 처음으로 TypeScript를 제대로 작성했을 때, 왜 이렇게 오래 미뤄왔는지 이해할 수 없었다. 내가 피하고 있었던 건 TypeScript가 아니었다. TypeScript를 둘러싼 의례(儀禮)였다.

나를 사로잡은 것

처음에는 단 하나의 킬러 피처를 꼽을 수 없었다. 매력은 모든 것이 같은 방향을 향해 나아가는 것처럼 보인다는 점이었다. 브라우저에서 사용하던 fetch()가 서버에서도 똑같이 동작했다. Web Crypto API는 그냥 거기 있었다. MDN이 사실상 Deno의 문서가 되었다. 패키지를 설치하는 대신 URL로 ESM을 임포트하여, 의존성에 대해 전혀 다른 방식으로 생각할 수 있었다.

deno fmt, deno lint, deno test, deno bench, deno check가 단일 바이너리 안에 모두 포함된 것도 같은 논리의 일부였다. ESLint를 설치할 필요도, Prettier를 연결할 필요도, 둘 사이의 설정 충돌을 해결하느라 씨름할 필요도 없었다. 그 편리함 뒤에는 하나의 태도가 있었다.

패턴은 충분히 명확했다: 웹 표준 위에 구축하고, 지루한 도구들은 직접 제공한다.

Node.js를 쫓아가며

오늘날의 Deno는 그 방향에서 멀어지고 있는 것처럼 느껴진다.

npm: 지정자 지원, 다시 등장한 node_modules, node:* 모듈 호환성. 그리고 Deno 2.8에서는 지정자 없이 deno add를 실행하면 이제 기본적으로 npm 패키지를 추가한다. JSR은 npm의 정체에 대한 답으로, JavaScript 패키징의 미래로서 도입되었다. 이러한 결정들은 그 발표를 아득하게 느껴지게 만든다. 각각의 결정은 개별적으로는 이해할 수 있다. 하지만 모두 합쳐 놓으면 그 윤곽을 외면하기 어렵다: Deno는 점점 더 많은 에너지를 Node.js를 따라잡는 데 쏟고 있다.

OS/2의 사례가 떠오른다. IBM은 OS/2에 Windows 호환성을 탑재하면 Windows 사용자들을 끌어올 수 있을 거라 기대했다. 실제로 일어난 일은 정반대였다: 개발자들은 Windows를 타깃으로 삼으면 두 플랫폼 모두에서 실행할 수 있다는 사실을 깨달았고, OS/2 API를 별도로 익힐 이유가 없어졌다. Deno가 Node.js 호환성을 더욱 강화할수록 동일한 역학이 작용한다. Deno가 호환될수록, 라이브러리 작성자들이 Deno를 특별히 고려해야 할 이유는 줄어든다.

한편, Node.js는 Deno를 향해 걸어오고 있다. TypeScript는 v22부터 플래그 없이 실행된다. 권한 모델은 v20에서 도입되었다. fetch()와 Web Crypto API도 이제 모두 지원된다. node:test와 node:assert/strict는 Deno, Node.js, Bun을 동시에 타깃으로 하는 프로젝트를 위한 최고의 크로스 런타임 테스트 하네스로 조용히 자리잡았다. 두 런타임은 수렴하고 있지만, Deno가 더 많이 손을 뻗고 있는 것처럼 보인다.

초기 Deno는 의제를 설정했다. 웹 표준, 권한 모델, URL 임포트, JSR: Deno가 이것들을 내놓았고 생태계가 반응했다. 지금 Deno가 하는 일은 정반대 방향으로, 생태계가 이미 갖추고 있는 것을 따라잡는 쪽으로 향하고 있다.

수세에 몰리며

여기에는 보다 구체적인 불만이 있다. Deno는 쫓아가는 대신 주도할 수 있었던 싸움이 있었다.

나를 JavaScript 생태계에서 멀어지게 만든 건 Node.js 자체가 아니었다. Node.js + npm + TypeScript + Vite + ESLint + Prettier + Vitest, 이 모든 것의 조합이 문제였다. 그 스택이 문제였고, Deno는 그에 맞서 이미 잘 싸우고 있었다. deno fmt, deno lint, deno test, deno bench, deno check, 그리고 2.4에서는 deno bundle이 돌아왔다. 한번 deprecated되었다가 복원되었는데, 그 우여곡절 자체가 그 방향이 옳았다는 자인이다.

아직 남아 있는 가장 눈에 띄는 공백은 개발 서버다: HMR, 라이브 리로드, 에셋 파이프라인, 그리고 그 위에 쌓이는 플러그인 생태계. Deno 자체 프레임워크인 Fresh 2.0은 Deno 내부에서 그 공백을 채우는 대신 Vite를 채택하는 쪽을 택했다. 이 결정은 실망스러웠다. Vite가 Deno 위에서 잘 동작하도록 만드는 것과, Deno를 자급자족하는 개발 환경으로 만드는 것은 완전히 다른 방향이다. 자체 프레임워크가 그런 선택을 내린 이상, 더 넓은 생태계가 반대 방향으로 가길 기대할 수는 없다.

하지만 수직 통합만으로는 충분하지 않았을 수도 있다. 개별 구성 요소의 품질도 중요하다. deno lint와 deno fmt가 ESLint와 Prettier보다 명확하게 뛰어났다면, 개발자들은 Node.js 프로젝트에서도 그것들을 선택했을 것이다. 그것이 트로이 목마가 될 수 있었다. 충분히 많은 프로젝트가 Deno 런타임은 쓰지 않으면서 Deno의 도구를 사용하게 되면, 다음 질문은 자연스럽게 따라온다. ESLint와 Prettier는 난공불락처럼 보였지만, 그럼에도 Biome과 Ox 시리즈(Oxlint, Oxfmt)는 자리를 잡아가고 있다. 시장은 항상 있었다. 더 나은 도구가 없었을 뿐이다. Deno가 먼저 거기에 도달할 수 있었다.

내가 계속 떠올리는 시계

왜 Deno는 그 방향을 고수하지 않았을까? 이것은 추측이지만, 내 나름의 해석이다.

통합 툴체인 경로는 인내를 요구했다. 개발자들이 설정 복잡성의 고통을 체감하게 하고, Deno를 그들이 이동할 장소로 만들고, 생태계가 Deno의 방식에 익숙해지기를 기다리는 것. 이 모든 것은 시간이 걸린다. Node.js는 OpenJS Foundation 산하의 커뮤니티 프로젝트다. 투자자의 시계가 그것을 밀어붙이지 않으며, 생태계가 느리게 움직인다고 해서 프로젝트가 흔들리지도 않는다.

Deno Land Inc.는 다르다. VC의 투자를 받은 회사에는 시계가 있다. 그 시계가 인내심 있는 싸움을 얼마나 허용하는지는, 커뮤니티 프로젝트가 감당할 수 있는 것과 같지 않다. Node.js 호환성을 확장하면 느린 대안보다 더 빠르게 가시적인 결과를 낳는다. 외부에서는 내가 보고 있는 것이 제품 결정인지, 런웨이 결정인지 구분할 수 없다. 분명히 말할 수 있는 것은, Deno가 보여 온 긴박감이 그것이 원래 선택했던 방향과 잘 어울리지 않는다는 것이다.

그럼에도

불만을 늘어놓았지만, 나는 여전히 내 라이브러리 대부분을 Deno 우선으로 개발한다. npm에도 배포할 때조차 JSR에도 배포한다. 웹 표준 API에만 의존하려 노력하고, 린팅과 포매팅에는 Deno의 내장 도구를 사용한다. 나는 여전히 Deno를 응원하고 있다.

하지만 나조차 일부 영역에서는 후퇴했다. 이제 테스트에는 node:test와 node:assert/strict를 사용한다. 특별한 의존성 없이 Deno, Node.js, Bun 모두에서 동일한 테스트를 실행할 수 있는 가장 쉬운 방법이기 때문이다. JSR은 npm의 정체에 대한 답으로 출시되었는데, 나는 JSR마저 정체되고 있다는 느낌을 받기 시작했다. 그것을 버려야 할지 자문하는 나 자신을 자주 발견한다. Deno KV에 흥분했던 나는 이제 그냥 node:sqlite를 사용한다. 어차피 Deno에서도 잘 동작한다.

나 같은 사람도 이미 이런 후퇴를 하고 있다면, Deno에 아무런 애착이 없는 사람에게 Deno가 어떻게 보일지 궁금하다. 나는 여전히 Deno가 이 싸움의 어떤 형태로든 승리하길 바라기 때문에, 그것이 걱정된다. 다만 최근에는 Deno가 내가 합류했던 그 싸움에서 이기길 원하는지, 그것이 덜 확실하게 느껴진다.

자동 번역 · 원문 읽기

번역의 최신 여부를 확인할 수 없습니다.
이 번역이 원문의 최신 내용을 반영하는지 알 수 없습니다.

Deno가 자신이 가장 잘하는 것을 계속해 나가길 바란다

설정의 장벽

나는 수년간 Python으로 작업하고, 주말에는 Haskell을 꿈꾸며 지냈다. 스크립트가 필요할 때는 Python을, 타입 시스템이 나를 책임지게 만들고 싶을 때는 Haskell을 썼다. TypeScript는 그 둘 사이 어딘가에 위치한다는 것을 알고 있었다. Haskell이 엄격한 곳에서 실용적이고, Python이 그렇지 못한 곳에서 타입을 갖춘. 하지만 나는 거리를 뒀다. tsconfig.json, .eslintrc, .prettierrc, babel.config.js. 단 한 줄의 실제 코드를 작성하기도 전에 생성해야 하는 파일들. TypeScript를 시도해 보려 할 때마다 그 목록을 보고 포기하고 말았다. JavaScript 생태계는 내게 항상 입장하기 위해 긴 줄을 서야 하는 놀이공원처럼 느껴졌다.

Deno는 그 줄을 없애 버렸다. 설정 파일도, node_modules도, 어떤 패키지 매니저를 써야 할지 고민할 필요도 없었다. 그저 deno run main.ts만 있으면 됐다. 처음으로 TypeScript를 제대로 작성해 봤을 때, 왜 그토록 오래 미뤄왔는지 이해할 수가 없었다. 내가 피하고 있던 것은 TypeScript가 아니었다. 그것은 TypeScript를 둘러싼 의례(儀禮)였다.

나를 사로잡은 것

처음에는 단 하나의 핵심 기능을 꼽을 수가 없었다. 매력은 모든 것이 같은 방향으로 수렴하는 것처럼 보인다는 점이었다. 브라우저에서 사용하던 fetch()가 서버에서도 동일하게 작동했다. Web Crypto API는 그냥 거기 있었다. MDN은 사실상 Deno의 문서가 되었다. 패키지를 설치하는 대신, URL로 ESM을 임포트했고, 의존성에 대해 완전히 다른 방식으로 생각하게 되었다.

deno fmt, deno lint, deno test, deno bench, deno check가 모두 단일 바이너리 안에 포함되어 있다는 점도 같은 논리의 일부였다. ESLint를 설치할 필요도, Prettier를 연결할 필요도, 둘 사이의 설정 충돌을 해결하느라 씨름할 필요도 없었다. 그 편의성 뒤에는 하나의 철학이 있었다.

패턴은 충분히 명확했다. 웹 표준을 기반으로 구축하고, 그다음 지루한 도구들은 직접 제공한다는 것.

Node.js 따라가기

오늘날의 Deno는 그 방향에서 멀어지고 있는 것처럼 느껴진다.

npm: 지정자 지원, 다시 등장한 node_modules, node:* 모듈 호환성. 그리고 Deno 2.8에서는 지정자 없이 사용하는 deno add가 이제 기본적으로 npm 패키지를 추가한다. JSR은 npm의 침체에 대한 답으로, JavaScript 패키징의 미래로서 소개되었다. 이러한 결정들은 그 발표를 이미 먼 과거처럼 보이게 만든다. 각각의 결정은 개별적으로 이해할 수 있다. 하지만 이를 종합해 보면, 그 윤곽을 외면하기 어렵다. Deno가 Node.js를 따라잡는 데 점점 더 많은 에너지를 쏟고 있다는 것이다.

OS/2의 사례가 떠오른다. IBM은 OS/2에 Windows 호환성을 내장하면 Windows 사용자들을 끌어올 수 있을 것이라 기대했다. 실제로 일어난 일은 정반대였다. 개발자들은 Windows를 타깃으로 하면 두 플랫폼 모두에서 실행할 수 있다는 것을 깨닫고, OS/2 API를 별도로 익힐 이유가 없어졌다. Deno가 Node.js 호환성을 향해 더욱 나아갈수록 동일한 역학이 작동한다. Deno가 호환될수록, 라이브러리 작성자들이 Deno를 특별히 고려할 이유는 줄어든다.

한편, Node.js는 Deno를 향해 걸어오고 있다. v22부터는 플래그 없이 TypeScript가 실행된다. 권한 모델은 v20에서 도입되었다. fetch()와 Web Crypto API도 이제 모두 지원된다. node:test와 node:assert/strict는 Deno, Node.js, Bun 모두를 타깃으로 하는 프로젝트를 위한 크로스 런타임 테스트 하네스로서 조용히 최선의 선택이 되어 있다. 두 런타임은 수렴하고 있지만, Deno가 더 많은 부분에서 먼저 손을 뻗고 있는 것으로 보인다.

초기 Deno는 의제를 제시했다. 웹 표준, 권한 모델, URL 임포트, JSR. Deno가 이것들을 내놓으면 생태계가 반응했다. Deno가 지금 하고 있는 일은 반대 방향으로 흐른다. 이미 생태계가 갖추고 있는 것을 따라잡는 것이다.

방어적 자세

여기에는 좀 더 구체적인 불만이 있다. Deno에는 뒤쫓는 대신 주도할 수 있었던 싸움이 있었다.

나를 JavaScript 생태계에서 멀어지게 한 것은 Node.js 그 자체가 아니었다. Node.js + npm + TypeScript + Vite + ESLint + Prettier + Vitest라는 조합 전체가 문제였고, Deno는 그에 맞서 이미 선전하고 있었다. deno fmt, deno lint, deno test, deno bench, deno check, 그리고 2.4에서는 deno bundle까지 돌아왔다. 한 번 deprecated된 후 복원된 것인데, 그 우여곡절 자체가 방향이 옳았다는 고백이나 다름없다.

남아 있는 가장 눈에 띄는 공백은 개발 서버다. HMR, 라이브 리로드, 에셋 파이프라인, 그리고 그 위에 쌓이는 플러그인 생태계가 그것이다. Deno 자체 프레임워크인 Fresh 2.0은 그 공백을 Deno 내부에서 채우는 대신 Vite를 채택했다. 그 결정은 실망스러웠다. Vite를 Deno 위에서 잘 돌아가게 만드는 것과, Deno를 자급자족하는 개발 환경으로 만드는 것은 완전히 다른 두 방향이다. 자신의 프레임워크가 그런 선택을 하고 나면, 더 넓은 생태계가 반대 방향으로 가길 기대할 수는 없다.

하지만 수직적 통합만으로는 충분하지 않았을 수도 있다. 개별 구성 요소의 품질도 중요하다. deno lint와 deno fmt가 ESLint와 Prettier보다 명확히 더 낫다면, 개발자들은 Node.js 프로젝트에서도 그것들을 찾게 될 것이다. 그것이 트로이 목마가 될 수 있었다. 충분히 많은 프로젝트가 Deno 런타임 없이 Deno의 도구를 사용하게 되면, 다음 질문은 자연스럽게 따라온다. ESLint와 Prettier는 난공불락처럼 보였지만, Biome과 Ox 시리즈(Oxlint, Oxfmt)는 자신들의 입지를 다져가고 있다. 시장은 항상 있었다. 단지 더 나은 도구가 없었을 뿐이다. Deno가 먼저 그 자리에 이를 수 있었다.

내가 계속 생각하는 시계

왜 Deno는 그 노선을 유지하지 않았을까? 이것은 추측이지만, 나의 판단은 이렇다.

통합 툴체인의 길은 인내를 요구했다. 개발자들이 설정의 장벽이 주는 고통을 체감하게 하고, Deno를 그들이 이동하는 곳으로 만들고, 생태계가 Deno의 방식에 익숙해지길 기다리는 것. 이 모든 것에는 시간이 걸린다. Node.js는 OpenJS Foundation 산하의 커뮤니티 프로젝트다. 이를 밀어붙이는 투자자의 시계가 없고, 생태계가 천천히 움직이더라도 프로젝트가 흔들리지 않는다.

Deno Land Inc.는 다르다. VC의 투자를 받은 회사에는 시계가 있다. 그 시계가 인내심 있는 싸움을 얼마나 허용하느냐는, 커뮤니티 프로젝트가 감당할 수 있는 것과 같지 않다. Node.js 호환성을 확장하는 것은 느린 대안보다 빠르게 가시적인 결과를 만들어낸다. 외부에서 보면, 어떤 결정이 제품 결정인지, 어떤 결정이 런웨이(자금 소진) 결정인지 구분하기 어렵다. 내가 말할 수 있는 것은, Deno가 보여주고 있는 긴박감이 Deno가 처음에 선택한 방향과 잘 맞지 않는다는 것이다.

그럼에도 불구하고

이런저런 불만에도 불구하고, 나는 여전히 내 라이브러리 대부분을 Deno 우선으로 개발한다. npm에도 배포할 때조차 JSR에 먼저 배포한다. 웹 표준 API에만 의존하려 노력하고, 린팅과 포매팅에는 Deno의 내장 도구를 사용한다. 나는 여전히 Deno를 응원하고 있다.

하지만 나조차도 일부 영역에서는 후퇴하고 말았다. 테스트에는 이제 node:test와 node:assert/strict에 의존하는데, 이것이 별도의 의존성 없이 Deno, Node.js, Bun 전반에서 동일한 테스트를 실행하는 가장 쉬운 방법이기 때문이다. JSR은 npm의 침체에 대한 답으로 출시되었는데, 이제는 JSR도 침체되고 있다는 느낌이 들기 시작했다. 그것을 버려야 할지 자문하는 나 자신을 종종 발견한다. 한때 Deno KV에 흥분했지만, 이제는 그냥 node:sqlite를 사용하는데, 어차피 Deno에서도 잘 작동한다.

나 같은 사람조차 이미 이런 후퇴를 하고 있다면, Deno에 아무런 애착이 없는 사람에게 Deno가 어떻게 보일지 궁금해진다. Deno가 이 싸움의 어떤 형태로든 이기길 여전히 바라기 때문에, 그 점이 걱정된다. 다만 최근에는 Deno가 내가 참여한 것과 같은 싸움에서 이기길 원하는지, 그 확신이 점점 흐려지고 있다.