Next 사용을 절대 추천하지 않음. 개발자 경험이 끔찍하고, 벤더 락인이 심하며, 문서화되지 않은 이상한 관례로 인해 CRUD 위주의 단순 B2B SaaS가 아니면 곳곳에 지뢰가 있는 느낌. 특히 Next <Image /> 태그가 같은 페이지의 webgl 씬 FPS를 2까지 떨어뜨린 사례 경험
Vercel이 어떻게 일반 React 사용자를 벤더 락인으로 천천히 끓였는지 의문. React는 Meta에서 오픈소스를 강조한 프로젝트였고, 오픈소스가 벤더 락인 방지 역할을 하길 바랐는데 실상은 그렇지 않다는 점에 실망
전적으로 동의. 최근 Next를 오랜만에 사용해봤는데 개발 경험이 매우 실망스러웠음. 문서가 모호하고 찾기 힘들었으며, 앱 자체가 기본적으로 느린 느낌. Docker로 AWS에 배포하려다 Vercel에서 제공하는 샘플 Dockerfile 때문에 수많은 어려움을 겪음
<Image /> 이슈를 직접 분석한 것인지 아니면 NextJs의 문제라고 추측하는 것인지 궁금. 나는 NextJs, <Image>, RTF 조합으로 일하지만 그런 문제를 겪은 적 없음
Next.js를 지난 3년간 업무에서 사용하며 정말 고통스럽다는 느낌. Vercel에 호스팅했고, 회사는 Vercel 서비스 거의 전부를 도입해서 본격적인 벤더 락인 경험. 예전에 Dan이 RSC 관련하여 HN에 올린 글에 나쁜 경험을 공유했는데, 그의 지적이 정확하다 느꼈음. "RSC 자체는 이제 꽤 탄탄하지만, Next.js 같은 프레임워크는 아직 좀 거칠다"는 말 처럼 전체적으로 React도 이제 평균 미만이고 Next.js는 오히려 안 좋은 평판을 가속화하는 느낌. 멀리하는 것이 상책
Vercel이 이번 버그를 수정하겠지만, 이제는 이런 자잘한 문제들이 쌓여 Next.js에 지침. 예로, 미들웨어에서 prefetch 식별법이 몇 주(혹은 몇 달)째 깨져 있음. 이런 자잘한 문제들이 계속 누적되는 상황이라 Next.js에 피로감 큼. 하지만 JS 생태계 자체는 여전히 애정
Next.js에서 벗어나 Astro로 이동. 기본으로 돌아가고 싶었지만, 직접 라우트/템플릿/정적 자산/빌드 설정하기가 귀찮았음. Astro는 이 모든 걸 처리하고, 기본적으로 SSR. React/Vue를 원래 의도한 대로 상호작용 계층으로 얹어 쓰는 느낌이라 JS 프레임워크가 실제로 얼마나 불필요한지 깨닫게 됨. Next는 점점 마법 같은 요소가 많아지고 서버 액션들이 어색하고, "NextJS 식" 구현이 너무 많았음
현재 업무 및 사이드 프로젝트에 Next.js를 쓰고 있지만, 예전에는 즐겁고 생산적이었던 도구였다가 pages에서 app 라우터로 전환한 뒤 방향이 아쉬움
15.1.8 버전 이후부터 일부 라이브러리1이 깨져서, 작성자가 언급한 취약한 버전으로 다운그레이드해야 하는 상황 발생
동감. 앞으로 Next.js는 정적 사이트나 사전 빌드 SPA에만 사용할 계획
Next가 농담거리가 될 지경. Remix가 이해할 수 없을 정도로 react-router로 변신하고 나니, 괜찮은 React 프레임워크가 극히 드물어진 느낌. 결국 plain vite와 tanstack router 조합으로 돌아감
이런 비판적인 글이 Hacker News에 남아있는 것이 놀라움. 예전에 Remix로 더 간단하게 구현됐다는 글을 올렸더니, Vercel 직원 여러 명에게 메시지가 와서 내리라고 하거나 미팅하자는 요청을 받았던 적 있음. 여러 SNS 계정으로 동시에 접촉함
브랜드 변경 이후 Remix를 더는 안 쓴다는 뜻인지, 아니면 프레임워크가 아니란 의미인지 궁금. RR7(React Router 7)도 프레임워크로 정상 작동1함. 15년차 백엔드였다가 최근 풀스택으로 전향하여 좋은 친구 추천으로 RR7 사용하는데 매일 감탄
새로운 프로젝트에서 TanStack Router를 써보고 너무 좋아서 TanStack Query, TanStack Form도 추가함
대안으로 무엇이 가장 좋은지, 그리고 Vite를 쓰는 이유가 궁금. 나는 소규모 프로젝트에 Next를 쓰는데, SEO가 가장 큰 장점이라고 들었음. 정적 파일만 생성해서 S3에 업로드하면 끝인데, 그게 더는 아니냐는 궁금증
Remix에서 react-router로 변한 게 구체적으로 뭐가 문제인지 궁금. 내가 보기엔 단지 리브랜딩인 듯함
Vercel 같은 데가 주도하는 React, Next, Svelte 등은 훨씬 더 신중히 접근해야 한다고 수년째 강조. 그들의 목표는 Heroku처럼 하지만, 훨씬 더 공격적으로 전체 스택(언어-런타임-머신)에서 완전 락인 유도. 다른 기업도 문제가 있음. 예를 들어 Cloudflare의 CLI 배포 툴은 macOS 13.5+만 지원(2년 조금 넘음), 왜 그런지 불분명. 2년 전에 나온 OS가 구형 취급받는 현실이 안타까움. 예전 버전 wrangler도 써볼 순 있지만, 문서와 기능이 불일치하고 어차피 더 악화될 듯함. 언젠가 호환성도 끊길 수 있음. 반면 다른 도구(vim, neovim, emacs 등)는 여전히 오래된 OS X에서 동작. 이런 오픈 도구는 락인 유인이 없기 때문이라 생각
Next와 RSC는 프론트엔드에서 다뤄본 것 중 가장 답답. 프론트엔드도 이미 충분히 골칫거리인데, 여기에 Next의 "마법"을 더해서 Vercel까지 벤더 락인. 팀에서는 이번 주에 tanstack router와 vite로 전환해서 평범한 CSA를 만들어 볼 예정이라 기대
RSC가 뭐가 그렇게 답답한지 궁금. 내 경험상 정말 잘 동작하고 아직 Next.js를 쓰는 이유도 오직 RSC 때문
모두가 Next.js 개발 모드에서 라우트 컴파일에 10초 걸리는 현상을 더 크게 다뤄야 함. Rust 컴파일러는 한켠에서 담배 피우고 있는 느낌
사용 불가능 수준. 내가 경험한 최악의 devx. 마지막으로 이 정도로 싫었던 스택은 Sharepoint 사이트 도와줄 때 한 번뿐
이제는 단순 스크립트 언어인 JS도 빌드/컴파일 단계를 몇 번씩 거치는데, 이제 C++ 컴파일러보다 오래 걸림. 클랭(Clang)이라도 브라우저에 넣으면 더 나은 경험이 될 지경. 참고로 회사에서는 PHP도 쓰는데 여기서도 같은 문제. 스크립트 언어라 간단할 줄 알았으나, PHP 자체 퍼포먼스 한계 때문에 코드 사전 생성 및 컴포저 빌드 단계를 따로 둬야 함. 그런데 PHP 개발자가 만든 이 빌드도 느림. GCC 제작자들이 만든 게 아니라 그런 듯
이상하게도 next dev —-turbo 옵션도 우리 회사 코드베이스에서는 더 빠르지 않음
Rust 컴파일러는 정말 컴파일 작업을 하는데 Next.js 컴파일러는 실제로 그 정도로 복잡한 작업을 하는지 의문
Next.js의 지금 모습이 안타까움. 여전히 사용하지만, 직접 포크해서 패치해서 써야 할 만큼. next.config.js는 기본 동작을 바꿀 수 있는 험난한 탈출구인데, 이런 옵션은 원래 확장 포인트로 제공하고 "feature flag" 뒤에 숨기지 말았어야 한다 생각. 지금은 완전 스파게티 코드에 가까운 D학점 프레임워크
NextJS가 아니라면 전체 스택 기준 추천 조합이 뭐냐는 질문. 나는 15년 경력의 백엔드 개발자이지만, 프론트는 AngularJS 이후 처음. 최근 사이드 프로젝트 때문에 전체 스택 앱을 만들어보려고 검색했더니 Gemini와 공식 문서에서도 모두 NextJS를 추천. 아직 초기라서 대안을 배우고 싶음. 모든 건 Docker로 VPS에 직접 운영할 계획이라 Vercel/Netlify는 피함
서버 렌더링 필요 없으면, 프레임워크 없는 React와 Vite1 조합 추천. 개발 중엔 Vite로 돌리고, 프로덕션 빌드는 HTML + JS 파일만 나와서 S3 같은 정적 호스팅에 올리면 끝. 10년 넘게 써왔고 문제 없음. 백엔드는 본인에게 편한 거 쓰고, 나는 요즘 PostgREST2 위주로 씀. 클라이언트에서 API 호출은 react-query3 추천
어떤 프로젝트를 개발 중인지 궁금. 나는 전형적인 SaaS 웹앱을 만들고 있는데 React/Refine.dev/Vite 조합이 아주 괜찮았음. Refine.dev 덕분에 CRUD 페이지 고민 없이 기능 개발에만 집중 가능
이번 이슈가 과장됐다 생각. React에서 스트리밍이 어떻게 동작하는지 아는 사람에게는, HTML을 한 줄씩 스트림처리할 수 없다는 건 상식. 메타데이터 때문에 첫 페인트(HTML, JS 아님)까지 막히면 안 됨. 이런 행동에서 일부 유저 에이전트를 예외 처리하는 건 합리적. 대다수 트래픽에선 최대한 빠른 표시가 중요하니까. 메타데이터 불러오는 데 오래 걸리는 사용자가 있을 경우, 어떻게 해결할지 궁금
Hacker News 의견
Next 사용을 절대 추천하지 않음. 개발자 경험이 끔찍하고, 벤더 락인이 심하며, 문서화되지 않은 이상한 관례로 인해 CRUD 위주의 단순 B2B SaaS가 아니면 곳곳에 지뢰가 있는 느낌. 특히 Next <Image /> 태그가 같은 페이지의 webgl 씬 FPS를 2까지 떨어뜨린 사례 경험
Vercel이 어떻게 일반 React 사용자를 벤더 락인으로 천천히 끓였는지 의문. React는 Meta에서 오픈소스를 강조한 프로젝트였고, 오픈소스가 벤더 락인 방지 역할을 하길 바랐는데 실상은 그렇지 않다는 점에 실망
전적으로 동의. 최근 Next를 오랜만에 사용해봤는데 개발 경험이 매우 실망스러웠음. 문서가 모호하고 찾기 힘들었으며, 앱 자체가 기본적으로 느린 느낌. Docker로 AWS에 배포하려다 Vercel에서 제공하는 샘플 Dockerfile 때문에 수많은 어려움을 겪음
<Image /> 이슈를 직접 분석한 것인지 아니면 NextJs의 문제라고 추측하는 것인지 궁금. 나는 NextJs, <Image>, RTF 조합으로 일하지만 그런 문제를 겪은 적 없음
Next.js를 지난 3년간 업무에서 사용하며 정말 고통스럽다는 느낌. Vercel에 호스팅했고, 회사는 Vercel 서비스 거의 전부를 도입해서 본격적인 벤더 락인 경험. 예전에 Dan이 RSC 관련하여 HN에 올린 글에 나쁜 경험을 공유했는데, 그의 지적이 정확하다 느꼈음. "RSC 자체는 이제 꽤 탄탄하지만, Next.js 같은 프레임워크는 아직 좀 거칠다"는 말 처럼 전체적으로 React도 이제 평균 미만이고 Next.js는 오히려 안 좋은 평판을 가속화하는 느낌. 멀리하는 것이 상책
Vercel이 이번 버그를 수정하겠지만, 이제는 이런 자잘한 문제들이 쌓여 Next.js에 지침. 예로, 미들웨어에서 prefetch 식별법이 몇 주(혹은 몇 달)째 깨져 있음. 이런 자잘한 문제들이 계속 누적되는 상황이라 Next.js에 피로감 큼. 하지만 JS 생태계 자체는 여전히 애정
Next.js에서 벗어나 Astro로 이동. 기본으로 돌아가고 싶었지만, 직접 라우트/템플릿/정적 자산/빌드 설정하기가 귀찮았음. Astro는 이 모든 걸 처리하고, 기본적으로 SSR. React/Vue를 원래 의도한 대로 상호작용 계층으로 얹어 쓰는 느낌이라 JS 프레임워크가 실제로 얼마나 불필요한지 깨닫게 됨. Next는 점점 마법 같은 요소가 많아지고 서버 액션들이 어색하고, "NextJS 식" 구현이 너무 많았음
현재 업무 및 사이드 프로젝트에 Next.js를 쓰고 있지만, 예전에는 즐겁고 생산적이었던 도구였다가 pages에서 app 라우터로 전환한 뒤 방향이 아쉬움
15.1.8 버전 이후부터 일부 라이브러리1이 깨져서, 작성자가 언급한 취약한 버전으로 다운그레이드해야 하는 상황 발생
동감. 앞으로 Next.js는 정적 사이트나 사전 빌드 SPA에만 사용할 계획
Next가 농담거리가 될 지경. Remix가 이해할 수 없을 정도로 react-router로 변신하고 나니, 괜찮은 React 프레임워크가 극히 드물어진 느낌. 결국 plain vite와 tanstack router 조합으로 돌아감
이런 비판적인 글이 Hacker News에 남아있는 것이 놀라움. 예전에 Remix로 더 간단하게 구현됐다는 글을 올렸더니, Vercel 직원 여러 명에게 메시지가 와서 내리라고 하거나 미팅하자는 요청을 받았던 적 있음. 여러 SNS 계정으로 동시에 접촉함
브랜드 변경 이후 Remix를 더는 안 쓴다는 뜻인지, 아니면 프레임워크가 아니란 의미인지 궁금. RR7(React Router 7)도 프레임워크로 정상 작동1함. 15년차 백엔드였다가 최근 풀스택으로 전향하여 좋은 친구 추천으로 RR7 사용하는데 매일 감탄
새로운 프로젝트에서 TanStack Router를 써보고 너무 좋아서 TanStack Query, TanStack Form도 추가함
대안으로 무엇이 가장 좋은지, 그리고 Vite를 쓰는 이유가 궁금. 나는 소규모 프로젝트에 Next를 쓰는데, SEO가 가장 큰 장점이라고 들었음. 정적 파일만 생성해서 S3에 업로드하면 끝인데, 그게 더는 아니냐는 궁금증
Remix에서 react-router로 변한 게 구체적으로 뭐가 문제인지 궁금. 내가 보기엔 단지 리브랜딩인 듯함
Vercel 같은 데가 주도하는 React, Next, Svelte 등은 훨씬 더 신중히 접근해야 한다고 수년째 강조. 그들의 목표는 Heroku처럼 하지만, 훨씬 더 공격적으로 전체 스택(언어-런타임-머신)에서 완전 락인 유도. 다른 기업도 문제가 있음. 예를 들어 Cloudflare의 CLI 배포 툴은 macOS 13.5+만 지원(2년 조금 넘음), 왜 그런지 불분명. 2년 전에 나온 OS가 구형 취급받는 현실이 안타까움. 예전 버전 wrangler도 써볼 순 있지만, 문서와 기능이 불일치하고 어차피 더 악화될 듯함. 언젠가 호환성도 끊길 수 있음. 반면 다른 도구(vim, neovim, emacs 등)는 여전히 오래된 OS X에서 동작. 이런 오픈 도구는 락인 유인이 없기 때문이라 생각
Next와 RSC는 프론트엔드에서 다뤄본 것 중 가장 답답. 프론트엔드도 이미 충분히 골칫거리인데, 여기에 Next의 "마법"을 더해서 Vercel까지 벤더 락인. 팀에서는 이번 주에 tanstack router와 vite로 전환해서 평범한 CSA를 만들어 볼 예정이라 기대
모두가 Next.js 개발 모드에서 라우트 컴파일에 10초 걸리는 현상을 더 크게 다뤄야 함. Rust 컴파일러는 한켠에서 담배 피우고 있는 느낌
사용 불가능 수준. 내가 경험한 최악의 devx. 마지막으로 이 정도로 싫었던 스택은 Sharepoint 사이트 도와줄 때 한 번뿐
이제는 단순 스크립트 언어인 JS도 빌드/컴파일 단계를 몇 번씩 거치는데, 이제 C++ 컴파일러보다 오래 걸림. 클랭(Clang)이라도 브라우저에 넣으면 더 나은 경험이 될 지경. 참고로 회사에서는 PHP도 쓰는데 여기서도 같은 문제. 스크립트 언어라 간단할 줄 알았으나, PHP 자체 퍼포먼스 한계 때문에 코드 사전 생성 및 컴포저 빌드 단계를 따로 둬야 함. 그런데 PHP 개발자가 만든 이 빌드도 느림. GCC 제작자들이 만든 게 아니라 그런 듯
이상하게도 next dev —-turbo 옵션도 우리 회사 코드베이스에서는 더 빠르지 않음
Rust 컴파일러는 정말 컴파일 작업을 하는데 Next.js 컴파일러는 실제로 그 정도로 복잡한 작업을 하는지 의문
Next.js의 지금 모습이 안타까움. 여전히 사용하지만, 직접 포크해서 패치해서 써야 할 만큼. next.config.js는 기본 동작을 바꿀 수 있는 험난한 탈출구인데, 이런 옵션은 원래 확장 포인트로 제공하고 "feature flag" 뒤에 숨기지 말았어야 한다 생각. 지금은 완전 스파게티 코드에 가까운 D학점 프레임워크
NextJS가 아니라면 전체 스택 기준 추천 조합이 뭐냐는 질문. 나는 15년 경력의 백엔드 개발자이지만, 프론트는 AngularJS 이후 처음. 최근 사이드 프로젝트 때문에 전체 스택 앱을 만들어보려고 검색했더니 Gemini와 공식 문서에서도 모두 NextJS를 추천. 아직 초기라서 대안을 배우고 싶음. 모든 건 Docker로 VPS에 직접 운영할 계획이라 Vercel/Netlify는 피함
서버 렌더링 필요 없으면, 프레임워크 없는 React와 Vite1 조합 추천. 개발 중엔 Vite로 돌리고, 프로덕션 빌드는 HTML + JS 파일만 나와서 S3 같은 정적 호스팅에 올리면 끝. 10년 넘게 써왔고 문제 없음. 백엔드는 본인에게 편한 거 쓰고, 나는 요즘 PostgREST2 위주로 씀. 클라이언트에서 API 호출은 react-query3 추천
어떤 프로젝트를 개발 중인지 궁금. 나는 전형적인 SaaS 웹앱을 만들고 있는데 React/Refine.dev/Vite 조합이 아주 괜찮았음. Refine.dev 덕분에 CRUD 페이지 고민 없이 기능 개발에만 집중 가능
이번 이슈가 과장됐다 생각. React에서 스트리밍이 어떻게 동작하는지 아는 사람에게는, HTML을 한 줄씩 스트림처리할 수 없다는 건 상식. 메타데이터 때문에 첫 페인트(HTML, JS 아님)까지 막히면 안 됨. 이런 행동에서 일부 유저 에이전트를 예외 처리하는 건 합리적. 대다수 트래픽에선 최대한 빠른 표시가 중요하니까. 메타데이터 불러오는 데 오래 걸리는 사용자가 있을 경우, 어떻게 해결할지 궁금