Hacker News 의견

• 나는 next.js를 사용하다가 페이지 라우터에서 앱 라우터로 전환했을 때 프로젝트를 포기했음. 앱 라우터 경험이 너무 나빴고 그 이후로 next.js를 다시 사용하고 싶지 않았음
  • Vercel은 오픈 소스인 척하지만 사용자들을 그들의 호스팅 플랫폼에 가두려는 벽을 쌓고 있음
• Vercel에 대해 항상 약간 불안했음. VPS에 Next.js를 자체 호스팅하려고 할 때 그들이 설정한 작은 함정들에 걸렸음
  • 그들이 이 취약점을 처리하는 방식이 나를 더욱 불안하게 만들었음
  • Vercel의 방화벽이 고객을 "적극적으로 보호했다"고 주장하는 초기 설명은 나쁜 인상을 남겼음
  • 다른 플랫폼에 알리는 데 지연이 있었고, 이는 Vercel이 Next.js에 취약점이 도입되는 것을 방지할 동기가 적다는 것을 보여줌
• 나는 모두에게 next.js를 피하라고 경고함. V0가 채택을 크게 증가시킬 가능성이 있음
  • 많은 새로운 개발자들이 배포 및 시스템 관리에 대해 생각하고 싶어하지 않음
  • React만 알고 있다면 SSR을 배우지 않고도 얻을 수 있는 것이 장점임
• 내가 next.js를 포기한 이유는 작은 프로젝트에서 변경 사항이 브라우저에 나타나는 데 6-7초가 걸렸기 때문임
  • 이제 React SPA와 Vite를 사용함
• 우리는 작년에 Next.js에서 Vike로 이전했음. 개발자 경험이 크게 개선되었음
  • 대부분의 필요는 페이지를 사전 렌더링하는 것으로 충족됨
• Next.js에 대해 혼합된 감정을 가지고 있음. 한편으로는 투자자와 함께 프레임워크를 구축하는 회사임
  • MIT 라이선스이므로 Netlify나 다른 회사가 포크하여 더 나은 대안을 제공할 수 있음
  • Vercel의 투자자라면 경쟁을 돕는 것이 투자 위험을 증가시킬 이유가 없음
  • Vercel은 오픈 소스를 지지하면서도 그들의 호스팅 플랫폼을 최선의 선택으로 만들기 위한 마찰을 유지하려고 함
• 내가 일하는 회사의 React 스택을 선택하는 과정에 있음. Next.js를 대안보다 선택할 이유를 상상할 수 없음
  • Remix나 React Router v7, TanStack이 SSR을 원한다면 더 합리적인 선택임
• 서버리스 접근 방식이 좋은 기본값이라고 확신하지 않음. 불필요한 복잡성을 추가함
  • 백엔드에서 자바스크립트를 사용하는 것을 좋아하지 않음
  • 서버 컴포넌트와 Next.js에 대한 집중이 나에게는 터널 비전처럼 느껴졌음
  • 서버리스 접근 방식이 HTTP 헤더를 사용한 특권 통신의 이유였을 가능성이 높음
• 최악의 개발 빌드 시간이 있으며, 수년간 많은 불만이 있었지만 해결되지 않음
• Vercel과 NextJS는 존재하지 말아야 함
  • Next를 한 번 시도했을 때 프로덕션에서 많은 하이드레이션 오류를 만났음
  • 프레임워크가 서버에서 렌더링하는 잠재적 이득을 위해 모든 것을 복잡하게 만듦
  • 전체 프레임워크가 그들의 비싼 클라우드 서비스를 판매하기 위한 좋은 외관으로 만들어졌음