Ende의 시작, 커뮤니티가 이어가는 Deno 포크

AI 요약

Deno 런타임 개발이 1년 뒤 중단될 예정이라는 발표에 반발한 P. Webb가 커뮤니티 포크 Ende를 시작한다고 밝혔습니다. 글쓴이는 Deno 팀이 Cloudflare로 옮기고 런타임 개발을 멈춘다고 설명합니다. Ryan Dahl은 Deno가 Node.js 호환성에 끌려가면서 Node.js와 똑같이 동작하게 됐고, 성능이나 사용성, 보안의 점진적 개선만으로는 Node.js를 다시 구현할 이유가 부족하다고 말했습니다. Deno는 앞으로 1년간 매달 릴리스를 내며 MIT 라이선스를 유지할 예정입니다.

글쓴이는 과거 Gel 프로젝트도 팀이 떠난 뒤 커뮤니티에 맡겨졌지만, 승인된 포크에는 2년간 업데이트가 없었다고 지적합니다. 그는 이번에는 직접 Deno를 포크해 Ende라는 이름을 붙이고, Node.js 호환성과 Deploy, KV, Jupyter를 비롯한 부가 제품을 제거하겠다고 합니다. 로드맵에는 모듈별 권한 설정, 비신뢰 코드용 샌드박스, Web Crypto의 양자내성 암호, 개선된 바이너리 출력이 포함됩니다. 12월 소프트 론치를 목표로 하며, 별도 코드 포지 EOL도 개발 중이라고 밝혔습니다. SemVer 대신 ChronVer를 쓰겠다는 계획도 덧붙였습니다.

Lobsters 반응

• @abbe — "Ende는 Deno의 애너그램"이라는데, 어떻게 애너그램인가요?
  • @hjvt — "strawberry"의 r 개수도 못 세면 그 정도면 충분히 비슷하겠죠?
  • @lilac — 더 답답한 건 oden이라는 이름이 바로 있다는 점입니다.
  • @briankung — oden도 맛있지만 odeng이 더 맛있습니다.
• @wink — 글의 권리 주장하는 듯한 말투가 정말 마음에 들지 않습니다. 곧 공식 지원이 끝나는 건 안타깝지만, 떠나는 사람들을 탓하는 건 옳지 않습니다. 그래도 잘되길 바랍니다. Node 호환성을 추가하고 제가 좋다고 생각했던 방향에서 벗어날 때 이미 흥미를 잃었는지도 모르겠습니다. 저는 많이 쓰지 않고, deno.land에서 주당 수십 건 요청을 처리하는 프로젝트를 호스팅할 수 있는 동안은 남아 있겠습니다. 아니면 다시 옮기는 편이 나을 수도 있습니다.
  • @ar-nelson — 직접 불만만 말하는 게 아니라 개발을 맡겠다는 사람을 권리만 주장한다고 부르기는 어렵습니다. Deno를 이어갈 사람이 생겨 반갑지만, 채택이 어려웠던 상황에서 포크와 Node 호환성 제거가 겹치면 호환 라이브러리를 찾기는 더 힘들 겁니다. 저는 최근 Bun의 불안정성과 Anthropic 인수 때문에 진행 중인 프로젝트 몇 개를 Deno로 옮길까 했는데, 이제 Node로 옮길 것 같습니다. Node는 경쟁자의 장점을 흡수하는 보그가 됐습니다. io.js를 기억하시나요?
  • @wink — "개발을 맡겠다"가 아니라 "맡을 것이다"라고 썼다면 동의했을 겁니다. 어쩌면 권리 의식이 강하다는 표현은 조금 어긋났을 수 있습니다. 하지만 자유 소프트웨어이고 사람들은 흥미를 잃거나 인수된 뒤에도 원하는 만큼 작업할 수 있습니다. 제게는 그게 크게 중요하지 않습니다.
  • @taskyliz — Deno Deploy도 6개월 안에 단계적으로 종료한다고 들었습니다. 그러니 아쉽지만 이전해야 할 겁니다.
  • @wink — "가능한 한 오래"라고 했어야 더 정확했겠네요.
  • @hawski — 글에서 EOL은 글쓴이의 새 프로젝트를 가리키는 말입니다. 코드 포지 같은 것이라고 생각하지만, 알아보려고 10% 정도 노력했는데도 정확히 무엇인지는 모르겠습니다. 댓글에서 쓴 EOL이 틀린 건 아니지만, 글에 나온 같은 단어를 보고 머릿속에서 의미가 섞인 건 아닌지 궁금합니다.
• @refi64 — "내가 직접 Node를 다시 구현해놓고 이제 지루해졌다고요?" 이 말은 지루해졌다기보다, 일반적인 시각을 받아들이는 단계에 도달했다는 뜻인 것 같습니다.
• @dsh — 누군가 이런 일을 하리라고 예상했습니다. Deno에는 좋은 아이디어가 많아서 다른 런타임보다 개발자에게 더 인기 있을 줄 알았는데 틀렸습니다. 직장에서도 Node.js 호환성이 있고 TypeScript 빌드 단계를 설정할 필요가 없다는 이유로 Bun을 쓰기 시작했습니다. Ende가 잘되길 바랍니다. 저도 Deno를 로컬이나 개인 프로젝트에서 썼던 것처럼 Ende를 쓸 것 같습니다.
• @andrewrk — 자유 소프트웨어 운동의 힘을 잘 보여주는 사례입니다. 회사가 프로젝트를 팔아넘겨도 소프트웨어가 가치를 제공한다면 이용자 커뮤니티가 포크해 유지할 수 있습니다. 다만 이 경우에는 그럴 이유를 잘 모르겠습니다. 저는 Node.js가 훌륭한 프로젝트라고 생각해왔고, URL에서 가져오기처럼 Deno가 차별화하려던 설계는 오히려 나쁜 선택이라고 봤습니다. 솔직히 Node.js를 다시 배우는 데 현실적으로 얼마나 걸리겠습니까? 10분인가요?
• @skykanin — Node 호환성을 없애는 게 맞다고 봅니다. Ryan이 Deno에 그걸 넣은 이유를 이해하지 못하겠습니다. 결국 Node를 다시 구현하게 됐다고 본인도 말했습니다. 채택을 늘리려는 VC의 압박이 있었을 거라고 추측합니다.
  • @moltonel — 쉽지 않은 선택입니다. Node 생태계는 큰 장점이라 호환성을 없애면 Ende의 매력이 줄어듭니다. 패키지들이 함께 테스트할 공통 API 명세가 필요할지도 모르지만, 성과 없이 끝날 수 있는 고된 작업입니다.
  • @bakkot — WinterTC 명세가 있지만 웹에도 있는 기능만 다룹니다. fetch, AbortController, setTimeout 같은 기능입니다. Deno도 명세를 만드는 데 크게 기여했습니다. 하지만 node:fs나 node:http는 포함하지 않습니다. Node가 워낙 널리 쓰여서 명세가 있더라도 많은 패키지는 Node만 대상으로 삼을 겁니다. 예전 IE와 비슷한 문제입니다. 서버 측 JavaScript를 Node 외 환경에서도 테스트해야 한다는 공감대는 브라우저 생태계보다 약합니다.
  • @zem — 프로젝트의 목표가 채택률을 높이는 것인지 더 나은 생태계를 만드는 것인지에 따라 다릅니다. Node 호환성을 깨는 원칙이 Deno의 동기였다면 채택률과 상관없이 계속 개발할 이유가 있습니다. LLM이 Deno 호환 라이브러리의 빈자리를 채울 수도 있습니다. 저는 자유 소프트웨어에서 경쟁 제품이 더 잘 맞으면 쓰면 된다고 생각합니다. 이전이 다른 이용자에게 큰 불편을 주지 않는다면 제 소프트웨어에 이전을 돕는 기능도 추가하겠습니다.
  • @lilac — 저는 전환 당시 직원이었습니다. 투자자보다는 Bun이 주목을 빼앗은 일이 전환의 더 큰 이유였습니다.
• @chenghiz — Deno를 써본 적은 없지만 VC 투자를 받은 프로젝트라 사용하지 않았습니다. 이 일이 생겨 반갑습니다. 다른 JavaScript 런타임에도 계속 영감을 주길 바랍니다. 유지보수가 이어진다면 저도 써볼 수 있습니다. 계획에 나온 모듈별 권한과 비신뢰 코드 샌드박스는 npm 생태계의 보안 문제를 고려할 때 큰 사용 이유가 될 수 있습니다.
• @ale — Deno를 즐겨 썼지만 런타임 자체에 왜 집착하는지 모르겠습니다. 서버를 직접 운영한다면 작동하는 바이너리 버전을 고정하고 계속 실행하면 됩니다. Deploy를 온전히 사용하던 개발자들이 실제로 가장 큰 손해를 봅니다.

원문: P. Webb / 번역·요약: Trawling