Hacker News 의견들

• 업계가 “빌드는 원래 오래 걸리는 것”이라며 아무 의심 없이 써온 비효율적인 툴들에 얼마나 많은 컴퓨팅 자원을 낭비했는지 새삼 생각하게 됨
  우리는 그 느린 빌드에 맞춰 일정을 짜고, 휴식 시간을 농담처럼 만들고, 캐시 레이어까지 구축했음
  Vite 유지보수자들에게 찬사를 보냄

  • 느린 JS 번들로 낭비된 자원보다, 비효율적인 런타임과 추상화로 낭비된 비용이 훨씬 큼
    대부분의 프로덕션 소프트웨어는 필요한 것보다 수십 배 느림
    Electron 앱들이 수 GB의 RAM을 쓰면서도 40년 전 소프트웨어보다 더 버벅이는 현실이 그 증거임
  • 나도 같은 생각을 함. ESLint나 Prettier 같은 툴도 Oxc를 알고 나니 비슷한 낭비처럼 느껴짐
  • 앞으로 행렬 곱셈에서도 이런 낭비를 되돌아보게 될 날이 올 것 같음
  • 빌드 성능은 오래전부터 내 관심사였음
    14년 전, 빌드 기다리며 낭비되는 시간을 깨닫고 특히 Java 생태계에서 이 문제가 심각하다고 느낌
    예전에 Ruby 프로젝트에서 통합 테스트가 매번 DB를 새로 만드는 데 10분씩 걸렸음
    Kotlin/Spring Boot도 컴파일이 느리고, Rust 컴파일러도 빠르진 않음
    하지만 테스트는 우리가 통제할 수 있음. 단위 테스트는 밀리초 단위로 끝나야 하고, 통합 테스트는 병렬화와 데이터 랜덤화를 통해 큰 개선이 가능함
    나는 MacBook Pro에서 Redis, DB, Elasticsearch를 포함한 수백 개의 스프링 통합 테스트를 40초 안에 돌림
    이런 세팅을 한 번 해두면 빠른 피드백 루프가 생기고, 개발의 즐거움이 돌아옴

• 내가 Vite 8에 기여한 부분은 Wasm SSR 지원이었음
  .wasm?init 임포트가 SSR 환경에서도 작동하도록 확장했음
  과정은 느렸지만, 팀이 세세하게 도와주고 문서까지 추가해준 점이 인상 깊었음

  • 이런 비하인드 스토리를 들으니 더 흥미로움
    Vite 팀이 단순히 툴을 만드는 게 아니라 기여자 교육과 협업에도 진심이라는 게 느껴짐

• Electron 시대에 이런 성능 향상을 보게 되어 정말 반가움
  내가 오래 유지해온 프로젝트(React hooks 이전부터 시작됨)는 예전엔 Webpack 기반 react-scripts로 빌드에 2분이 걸렸음
  지금은 Vite 8로 1초 만에 끝남. 우리가 얼마나 많은 리소스를 낭비해왔는지 보여주는 사례임

  • 이제는 AI 모델 위에 기계가 쓸 수 있는 인터페이스를 억지로 붙이는 새로운 악몽이 시작된 듯함
  • 아이러니하게도 Vite 홈페이지가 A55나 S23FE에서도 렉이 걸림
  • 사실 JS는 원래 빌드 과정이 필요 없는 언어였음
    브라우저가 그대로 실행할 수 있어야 하고, TypeScript도 타입만 제거하면 바로 실행되도록 설계됐음
    이런 빌드 툴의 존재 자체가 잘못된 방향 같음

• 우리 팀은 Vite 8 도입 후 빌드 시간이 4분에서 30초로 줄었음
  거의 드롭인 교체 수준이었고, Vite 팀에게 감사함

  • 우리도 10초에서 1초로 줄었음. 핵심은 Rolldown 덕분임
    Vite에 통합되기 전부터 써왔는데 정말 훌륭함
  • 4분이라니, 앱 규모가 얼마나 큰지 궁금함
    Next보다 빠르다고들 하는데, 그 정도면 엄청난 규모일 듯함
  • 우리 프로젝트 중 하나는 12분에서 2분으로 줄었음. 정말 놀라운 변화임

• 특정 프레임워크에 묶이지 않은 오픈소스 번들링 솔루션을 만든 Vite 팀에게 감사함
  (살짝 기침하며 Turbopack 언급)

• 멋진 소식임. 하지만 Next.js는 이런 커뮤니티의 성과를 누리지 못할 것 같음
  Vercel의 NIH 증후군 때문임

  • Vercel은 항상 미완성 프리뷰를 몇 년간 운영하는 방식임
    Next 13에서 Turbopack 알파를 시작해 Next 16에서야 기본값으로 바꿈
    2022년에는 Vite와의 비교 벤치마크도 왜곡됐었음
    캐싱 문제, 느린 성능, RSC 보안 취약점, 혼란스러운 앱 라우터, Vercel 외 호스팅의 불편함 등
    Next.js 선택은 리스크임
    관련 링크: 비교 토론, 캐싱 히스토리, 성능 분석, 보안 CVE, OpenNext
  • 몇 년 만에 React로 돌아왔는데, Next의 존재 이유를 이해하기 어려움
    공식 문서에서도 Next를 기본으로 언급하는 게 이상함
    React를 비-SPA로 쓰는 이유가 뭔지 모르겠음
  • Next.js는 여러 엔터프라이즈 SaaS 파트너와의 통합 때문에 공식 SDK로 밀어주는 구조임
    예: Sitecore Cloud, Sanity, Contentful 등
  • 참고로 Cloudflare Vinext도 있음 (직접 써보진 않음)

• Vite+, Void Cloud, Void Framework 등으로
  이제 Vercel과 Void의 대결이 시작될 듯함
  특히 PRC(Server Functions) 데모가 흥미로움 — DB부터 UI까지 엔드투엔드 타입 안정성을 보여줌
  우리는 Telefunc(tRPC 대안)으로 RPC 설계를 연구 중이며, Void 팀과 협업을 기대함
  관련 링크: PRC 데모 영상, Telefunc, Vike

  • 흥미로운 점은 Vercel이 간접적으로 Void 투자자라는 소문이 있음
    Void Cloud는 Cloudflare Workers 위에 구축된 것으로 보이고, 현재 정보는 적음
    그래도 Vite+를 MIT 오픈소스로 공개한다는 건 매우 고무적임
    Bun이 Anthropic 지원에 집중하느라 OSS에 소홀해지면 경쟁 우위를 잃을 수도 있음
    참고: Void Cloud

• JS 생태계가 혼란스러워도 Vite는 꾸준히 뛰어난 DX와 프로덕션 품질을 보여줌
  통합된 Rolldown 번들러로 더 빠르고 유연한 기반이 될 것임
  1998년부터 웹 개발을 해온 입장에서 정말 팬임

• 장기 유지보수를 중시해서, 나는 esbuild를 직접 사용함
  Vite 같은 래퍼가 내부 변경으로 깨질 때마다 수정하는 게 싫음

  • 나도 같은 방식으로 esbuild + 간단한 RPC 레이어를 썼음
    Zod로 타입 검증을 처리하고, Postgres 타입만 코드 생성함
    다음엔 Kysely를 썼을 것 같음
  • esbuild는 몇 년이 지나도 깨지지 않은 유일한 JS 툴임
  • 다만 아직 코드 스플리팅이 부족함
  • Top-level await도 지원 안 하고, 라이브 리로딩이 HMR보다 훨씬 느림

• tsconfig paths 내장 지원은 정말 좋은 QoL 개선임
  설정 중복을 줄일 수 있음

  • 좋은 소식이지만, Node.js import alias도 시도해볼 만함
    프로젝트에 따라 더 단순할 수 있음