[Youtube] Next.js 15.3: A Huge Change for Vercel

출처 : Theo - t3․gg

번역

여러분과 진지하게 대화하고 싶어요. 지난 2년 동안 Next.js를 방어하는 것은 꽤 어려웠습니다. 제가 좋아하는 것이 많지만, 당연히 사람들이 화를 내는 것도 많았습니다. 개인적으로 매우 화가 나는 것도 몇 가지 있습니다. 터보팩에 대해 시작하게 하지 마세요. 정말 많았어요. 그렇긴 하지만 지난 몇 달 동안 상당한 코스 수정이 있었고, 최신 버전인 Next 15.3에서 실제로 출시되기 시작했습니다. Next 15.3 릴리스 자체와 사물 내부 모두에서 유용한 변화가 많이 있습니다...

이 모든 것이 이야기할 가치가 있고 더 잘 이해할 수 있습니다. 따라서 XJS 개발자 여부와 관계없이 시장이 어디로 향하고 있는지, Vercel이 어떻게 코스를 수정하고 있는지 더 잘 이해하는 데 유용할 것이라고 생각합니다. 만약 당신이 XJS 개발자라면, 이것은 정말 필수적인 시계가 될 것입니다. 하지만 여러분도 아시다시피, 베르셀은 더 이상 저에게 돈을 주지 않고 꽤 오랫동안 돈을 주지 않았습니다. 그래서 누군가가 청구서를 처리해야 해요. 스폰서 휴식 후 바로 돌아와서 바로 들어갈게요. 일반적으로 새로운 프로젝트를 시작할 때는 대략적으로 제가 원하는 것이 무엇인지 잘 알고 있어요. 그리고 CLI를 사용해서 그렇게 하는 것은 아마도 저에게 그다지 도움이 되지 않을 것입니다

빨리. 오늘의 스폰서인 Bolt.new가 정말 잘 이해했어요. 그들은 AI가 생성한 앱을 만드는 이상한 신생 스타트업이 아닙니다. 이 회사는 브라우저에서 유일하게 좋은 편집기를 만들고 브라우저에서 전체 노드 환경을 실행할 수 있는 웹 컨테이너를 발명한 StackBlitz 회사입니다. 그래서 볼트는 정말 대단해요. 그들은 당신이 생성한 후에 기계에서 모든 코드를 실행하는 유일한 AI 앱 플랫폼입니다. 따라서 개발 환경에서 모든 것을 훨씬 더 빠르고 안정적으로 만들어 줍니다. 그리고 그것은 진정한 개발 환경입니다. 믿지 않으시면, 그냥 보여드릴게요.

Next.js를 사용하여 코기 애호가들을 위한 팬 사이트를 구축하세요. 보시다시피, 이미 실제 편집기에서 실제 코드를 생성하고 있을 뿐만 아니라 실제 노드 명령을 실행할 수 있는 실제 터미널도 생성하고 있는데, 정말 말도 안 돼요. 모든 작업이 완료되면 결과에 만족하면 말 그대로 클릭 한 번으로 배포할 수 있습니다. 처음으로 CEO이자 좋은 친구인 에릭에게서 이 데모를 받았을 때가 기억납니다. 그는 단지 대화를 나누고 싶어서 와서 나에게 이걸 보여줬어요. 그리고 그게 어떻게 작동하는지 이해하지 못했어요. 그리고 그것은 많은 의미가 있습니다

몇 달 후, 그들은 그것을 죽이고 있고, 모두가 볼트를 사용하여 사이트를 시작하고 있습니다. 아주 맛있어요. 무엇이 기다리니? 좋아요, 사이트들은 보통 꽤 괜찮지만, 이건 정말 짜증나게 하네요? 뭐라고? 심지어 코기의 좋은 이미지도 발견했습니다. 코기가 아닌 것도 있지만, 이게 얼마나 잘 나왔는지 생각하면 그건 문제가 되지 않아요. 그리고 그것은 진짜 Next.js 코드입니다. 이것은 실제 Next.js 앱 라우터 코드 베이스입니다. 페이지를 보면 여기 있는 모든 것을 볼 수 있고, 심지어 Shad를 사용하고 있습니다...

CN. ShadCN UI를 좋아하신다면, 여기 있습니다. 모두 내장되어 있습니다. 다른 옵션들이 이것을 가지고 있지 않다는 게 아직도 믿기지 않아요. 채팅 숨기기 버튼이 있어요. 그래서 우리 중 많은 사람들이 실제로 프로젝트의 코드를 보고 사용하고 싶어하는 실제 엔지니어들이기 때문에 그냥 코드 속에서 살 수 있습니다. 그렇기 때문에 StackBlitz에서 한 번 클릭하여 열거나 코드를 ZIP로 다운로드할 수 있는 내보내기 버튼이 있는 것입니다. 이는 실제 인스턴스이기 때문에 모든 코드가 브라우저에 존재하기 때문입니다. 점점 더, 개발자로서 우리가 필요로 하는 것을 이해하는 AI 앱 빌더는 볼트가 유일한 것처럼 느껴집니다. 그리고 저는 그것을 굳게 믿습니다. 왜냐하면...

저는 그 팀을 정말 잘 알아요. 그리고 이들은 제가 아는 웹 세계에서 가장 똑똑하고 열심히 일하는 오픈 소스 사람들 중 일부입니다. 따라서 다음 프로젝트를 시작할 수 있는 좋은 방법을 원한다면 오늘 soydev.link 슬래시 볼트에서 bolt.new를 확인하세요. 그렇다면 Next 15.3은 무엇이 그렇게 특별할까요? 무엇보다도, 이제 터보팩이 알파 빌드를 지원하기 때문에 빌드 측면이 중요합니다. 즉, 아직 이걸 생산에 사용해서는 안 된다는 뜻입니다. 하지만 그들은 이미 Vercel에서 그것을 생산에 사용하고 있는데, 정말 정말 보기 좋네요. 그들은

아래에 몇 가지 숫자를 공유하세요. 우선, Next 15의 개발 세션 중 절반 이상이 이미 터보팩을 사용하고 있습니다. 그래서 그들은 한동안 개발도상국에서 지원을 받아왔습니다. 제가 일하는 모든 프로젝트는 개발자용 터보팩을 사용합니다. 그것은 엄청난 차이입니다. 개발 환경이 최대 몇 초까지 회전할 때까지 대기하는 시간이 몇 분에서 몇 초로 줄어듭니다. 그리고 핫 리로딩에 대한 업데이트는 말 그대로 거의 즉시 이루어지며, 대부분의 경우 100밀리초 미만입니다. 훨씬 나아졌어요. 그리고 터보팩 없이는 T3Chat 크기의 프로젝트를 진행할 수 없었습니다. 정말 비참할 거예요. 대안은 v2일 것입니다.

Vite 생태계에서는 속도가 비슷하지만, 웹팩과 터보팩이 현재 허용하는 서버 및 클라이언트 사이드 동작과 같은 것들을 반드시 수행할 필요는 없습니다. 서버와 클라이언트 측면 모두에서 구현이 완벽하게 느껴지는 전체 스택 Vite 프레임워크를 여전히 찾아야 합니다. 그렇기 때문에 내장된 물건들을 많이 버리고 있어도 Next에 있는 저 자신을 발견하게 됩니다. 서버와 클라이언트 모두의 명확한 분할과 경로, 그리고 그들 간의 관계는 여전히 매우 편리합니다. 와쿠는 아직 멀었어요. 정말 웃기지만, 언급해 주셔서 감사합니다.

와쿠는 서버 구성 요소 데모로서 정말 멋져요. 풀스택 백엔드와 프론트엔드, 원코드 기반의 제품으로는 멋지지 않습니다. 그리고 Nuxt는 멋지지만, 가깝지도 않아요. 어쨌거나. Vercel은 한동안 이 페이지를 유지해 왔습니다. 이전에는 개발 환경이 웹팩 대신 터보팩을 사용하여 NextDev에서 제대로 작동하기 위해 필요한 일련의 테스트를 수행하는 Development로 기본 설정되었습니다. 그리고 여기에 무작위 오류가 하나 남아 있습니다. 나머지는 모두 처리되었습니다. 이제 사이트는 기본적으로 프로덕션으로 설정됩니다.

8,095개의 테스트를 통과해야 하기 때문에 아직 충분하지 않습니다. 하지만 그들은 매우, 매우 가깝습니다. 그들은 57개가 남아 있으며, 대부분의 프로젝트는 최소한 이것을 사용하여 건설할 수 있어야 합니다. 정말, 정말 멋져요. 그리고 결과적으로 빌드 시간이 훨씬 더 나아질 것입니다. TurboPack은 Rust로 작성되었으며, 이러한 스레드를 사용하고 프로세서를 더 잘 사용하기 위해 4코어로 작성되었기 때문에 멀티코어, 멀티스레드를 더 많이 활용할 수 있으므로 속도가 28% 향상될 것입니다. 16개의 코어가 60%를 볼 수 있습니다. 그리고 30코어의 데스크탑 컴퓨터에서는 아마도

클라우드에 배치하지만 일부 작업자는 빌드 속도가 83% 더 빠릅니다. 정말 크네요. 마지막으로, 우리의 스레드를 확장하는 것은 Next.js 프로젝트를 구축할 때 터보팩을 사용할 때 기대해야 할 빌드 성능을 근본적으로 변화시킵니다. 하지만 이것만이 유일한 변화는 아닙니다. 역사적으로 빌드 도구는 Next.js의 일부에 불과했습니다. Next.js가 나온 주요 이유 중 하나는 웹팩 구성에 대한 소란을 멈춰야 하기 때문입니다. 정말 좋았어요. 하지만 이제 웹팩의 또 다른 대안은 RSPack입니다. 그리고 이 릴리스를 기준으로 현재...

공식적으로 RSPAC에 대한 커뮤니티 지원을 제공합니다. 따라서 Vercel 생태계에 완전히 포함되지 않은 다른 옵션을 사용하고 싶다면 지금 바로 사용할 수 있습니다. 이거 정말 커요. Next.js가 Webpack과 이제 TurboPack과 깊은 관계를 맺는 날을 보게 될 줄은 상상도 못했어요... 다른 옵션을 허용하기 위해 아예 고장이 날 것입니다. 하지만 Vercel은 실제로 RSPAC 팀에 직접 연락했고, 저는 이 문제에 대해 한동안 그들과 연락을 주고받았습니다. 아무도 예상하지 못했기 때문에 그들은 너무 흥분했습니다. 그것은 정말로 철학의 변화를 보여줍니다

다음 팀에서. 필요하면 사용하고 필요하지 않으면 버리는 올인원 세트가 아니라, 주어진 부품이 Vercel이 제공하는 것이나 다른 사람이 제공하는 것을 사용할 수 있는 모듈화되고 있기 때문에 배포 어댑터 API를 사용한 다른 공지가 큰 문제입니다. 이것은 기술적으로 15.3 릴리스의 일부는 아니지만, 분명히 이와 일치하도록 의도되었습니다. 배포 어댑터 API의 목표는 서버리스 플랫폼을 포함한 모든 곳에 Next를 배포할 수 있도록 하는 것입니다.

이것은 중요한 차이점입니다. 왜냐하면 현재로서는 이러한 변경 사항 없이 Next.js를 원하는 곳에 배포할 수 있기 때문입니다. 문제는 노드 애플리케이션을 실행하는 방식이기 때문에 실제로는 Docker 컨테이너에만 배포할 수 있다는 것입니다. Vercel은 Next의 여러 부분을 서로 다른 환경으로 분할할 수 있는 매우 강력한 인프라를 구축했습니다. 그래서 그것은 단순히 도커 컨테이너에서 실행되는 것이 아닙니다. API 호출과 페이지 세대를 위해 한 곳에서 컴퓨팅을 실행하고 있습니다. 정적 자산을 실행할 수 있도록 다른 곳에서 CDN을 실행하고 있습니다

요청을 리디렉션하는 미들웨어용 엣지 컴퓨팅. 그 분리는 스스로 만드는 것이 재미없고, 베르셀에 깊이 구워져서 다음이 베르셀에게 좋은 이유입니다. 다른 곳에 배치하는 것을 어렵게 해서가 아닙니다. Next가 Vercel에서 제공하는 수준의 통합을 제공하는 다른 장소에 배포할 수 있는 다른 프레임워크는 없습니다. 그것은 그들이 그런 식으로 일하기 위해 Next를 만들었기 때문이 아닙니다. 베르셀이 허락하기 때문이에요. 그리고 현재 베르셀에서 구축된 스벨테와 같은 다른 프레임워크도 있습니다. 하지만 Solid와 같은 프레임워크도...

다른 장소를 배치한 경험이 좋지 않고, 특히 정적 콘텐츠, 반정적 콘텐츠, CDN 캐시, 동적 콘텐츠의 혼합 등 기능이 그다지 깊이 구워지지 않았습니다. 특히 컴퓨팅이 항상 전용 서버로만 실행되지 않을 때는 통합이 정말, 정말 어렵습니다. 따라서 전용 서버에서 Next를 문제 없이 실행할 수 있음에도 불구하고 최신 Next.js에서는 많은 멋진 기능을 제공합니다... 증분 정적 재검증, 캐싱, 미들웨어 재작성 등과 같은 것들

서버가 없는 환경에서 구현하기에 다른 유용한 요소들은 사소하지 않았습니다. 배포 어댑터 API의 목표는 Netlify와 같은 다른 플랫폼이 사용자 지정 요구 사항으로 인해 Next.js 배포를 더 쉽게 지원할 수 있도록 하는 것입니다. 그것은 큰 변화입니다. 또한 주목할 만한 점은 이것이 RFC라는 것입니다. 의견 요청입니다. Vercel 팀, 특히 Lee는 커뮤니티의 의견을 듣고 싶어합니다. 그들이 이 일을 제대로 해낼 수 있는지 확인하기 위해서입니다. 그들은 OpenNext와 같은 프로젝트에서 교훈을 얻어 Next.js가

어느 환경에 배포하든 상관없이 잘 배포되어야 하며, 덱스와 환경 간의 통합에는 제한이 없을 것입니다. 환경 자체의 제한 사항이 될 것입니다. 또한, 기존 빌드 출력 API가 vercel로 배송하고 이 모든 인프라를 활용하기 위해 구축된다는 점도 주목할 필요가 있습니다 이미 열려 있으며 누구나 통합을 구축할 수 있는 기능입니다. 제가 이해하는 한, Netlifify와 같은 곳에서 Vercel 빌드 출력 형식을 실행할 수 있도록 포팅하는 것이 완전히 가능할 것입니다.

그런 다음 다음 다음 Vercel 방식으로 빌드하여 물건에 배포하면 됩니다. 하지만 서비스마다 기대하는 바가 다릅니다. 그리고 만약 그들이 빌드 출력 API와 완벽하게 일치하지 않으면, 그들은 망하게 됩니다. 그래서 그들은 경쟁사들이 다음 앱을 더 쉽게 호스팅할 수 있도록 빌드 출력 구조를 변경할 것을 제안하고 있습니다. 그건 좀 말도 안 돼. 잠시 생각해 보세요. 물류적으로 말하자면, Vercel은 이러한 평판 손상을 해결하기 위해 많은 돈과 노력, 시간과 공간을 투자하고 있습니다

스마트한 사람들의 에너지는 주요 프레임워크의 빌드 출력을 Vercel 내부에서 유지 관리하기 어렵게 만들 뿐만 아니라 일반적으로 배포하기 훨씬 더 쉽습니다. 사람들이 오랫동안 이 문제로 괴롭혀왔기 때문에 경쟁자들의 삶을 더 쉽게 만들기 위한 대규모 프로젝트입니다. 저는 여전히 Vercel이 지원 측면에서 잘못한 것이 없다는 것을 잘 알고 있습니다

다른 플랫폼. 하지만 그들이 도입한 기능들은 매우 멋지고 매력적이었지만, 특정 인프라 구현과 너무 밀접하게 연관되어 있어서 시각적으로 보기에는 좋지 않아 보였고, 이러한 멋진 새로운 기능들은 다른 호스팅 플랫폼에서 실행하기 어렵거나 실행 가능하지도 않았습니다. 또한 앞으로 이러한 획기적인 인프라 기능이 점점 더 줄어들 것으로 예상됩니다. 그래서 지금이 이 컷을 만들기에 좋은 시기입니다. 왜냐하면 나는

다음 번에는 또 다른 서버 구성 요소 순간이 없을 것 같아요. 다음 번에는 또 다른 앱 라우터 순간이 없을 것 같아요. 가장 가까운 것은 터보 팩 순간인데, 실제로 준비가 된 것 같아요. 가브리엘의 질문은 이것이 다음 번의 혁신 속도를 늦출 수 있을까요

현재 속도를 유지하려는 의도였다면, 네, 물론이죠. 하지만 Next.js 내에서 혁신하는 속도가 본질적으로 느려진 것은 커뮤니티의 항의, 대신 AI에 집중하는 것, 이러한 것들을 통합하는 어려움, 대신 Vercel에서 새로운 인프라 프리미티브를 직접 만드는 것 등 여러 가지 이유 때문이라고 생각합니다. 이 모든 것들은 Next.js 프레임워크 내에서 직접적으로 훨씬 적은 혁신이 있을 것이라고 기대한다는 것을 의미합니다

즉, 순전히 경쟁을 돕기 위해 API를 변경하여 반복하는 능력에 타격을 입어도 괜찮습니다. ChatGPT는 현재 Vercel 가입의 10%를 차지하고 있으며, 이는 가속화되고 있습니다.

그들이 어디로 가는지 보세요. 그리고 Next.js에 점점 더 많은 기능을 추가하는 것은 더 이상 다음 팀과 Vercel을 위한 전략이 아닙니다. 미래는 Next의 더 많은 기능이 아닙니다. 미래는 새로운 유형의 앱과 새로운 유형의 개발자를 더 잘 지원하기 위한 인프라입니다. 다음은 확실히 더 개방적입니다. 제가 생각하는 방식이 이상해요. 그래서 제가 다 쓰고 싶어요. 오랫동안 새로운 기술을 시도하는 가장 좋아하는 방법은 Vercel이었습니다.

정말 믿을 만했어요. 서버 프리미티브와 함께 할 수 있는 멋진 일들은 정말, 정말 치명적이었어요. 저는 그 이야기를 몇 번이나 했지만, 과거에 많은 지원을 해왔던 프론트엔드 개발자로 Vercel에 합류하게 되었습니다. 하지만 주로 프론트엔드로 이동했는데, 이는 작은 스타트업에서 일하며 정말 형편없는 백엔드 팀과 함께 일하고 있었습니다. 그것이 나를 끊임없이 막고 있었다. 그리고 사용자가 필요로 하는 데이터를 얻기 위해 특정 API 키를 가진 엔드포인트에 도달할 수 있는 몇 가지 엔드포인트가 필요했습니다. 그리고 정말 멋진 것을 발견했어요.

API 디렉토리를 슬래시합니다.

당시 앱은 스노우팩으로 충분히 재미있게 만들어진 리액트 앱이었는데, 나중에 좋아지면 Vite로 포팅했습니다. 이 회사를 떠나기 전에 마지막으로 한 일입니다. 하지만 Vercel을 사용하면 API라는 디렉토리를 추가하고 무작위 TypeScript 함수를 넣을 수 있으며, 갑자기 서버리스 노드 환경에 자동으로 배포되어 앱에서 실행할 수 있게 됩니다. 정말 마법 같았어요. 정말 대단했어요, 젠장, 제가 어떤 순간을 위해 할 수 있을까요. 비록 이것이 이 팀을 위해 프론트 엔드를 운영했지만, 특정한 것을 빠르게 제거할 수 있었습니다

특정 항목에 대한 백엔드 함수. 이것이 제가 프런트엔드 패턴의 백엔드에 대해 소개한 것이었고, 제 뇌를 완전히 다시 연결해 주었습니다. T3 스택이 존재하게 된 저에게 큰, 큰 순간은 이 디렉토리의 발견이었습니다. 다음 기능이 아니라 Vercel에서 직접 사용할 수 있습니다. 앞서 말했듯이, 저는 Next.js에 들어가기 훨씬 전에 Vercel에 들어갔습니다. 웹팩 구성 방법을 이미 알고 있었기 때문에 불필요한 추상화라고 생각했고, 그 시점에 Vite로 이사했습니다. API 디렉토리와 Vercel 함수를 몇 가지 작성하여 배포하는 기능은 다음과 같습니다

TypeScript나 Python 같은 것들 때문에 제 뇌가 완전히 망가졌어요. 이것이 결국 Vercel이 제가 선택한 플랫폼이 된 이유였습니다. 새로운 프레임워크를 시도했을 때, 새로운 버전의 Remix, Solid Start, Svelte 등의 업데이트를 시도했을 때, Vercel이 바로 그 프레임워크를 배포했습니다. 저는 Vercel의 인프라를 잘 알고 있었기 때문에 그것이 무엇을 가능하게 하는지 잘 알고 있었고, 이러한 도구와 기술의 차이점을 빠르게 파악할 수 있는 가장 쉬운 방법이었습니다. 저는 Astro와 Svelte 같은 도구에서 다양한 벤치마크를 정기적으로 게시하곤 했습니다

그리고 저는 그것들을 모두 Vercel에 배치할 것입니다. 왜냐하면 그것이 가장 쉬운 테스트 방법이었기 때문입니다. 사실, 엣지에서 다음을 실행할 수 없었던 적이 있었습니다. 그래서 Vercel의 Edge 네트워크를 테스트하기 위해 Astro를 배포하고 있었습니다. 왜냐하면 다시 말해, Vercel은 제가 새로운 도구나 기술을 가지고 놀 수 있는 최고의 기본 요소들이었기 때문입니다. 그리고 저는 항상 그런 식으로 그것들을 사용하고 있다는 것을 알게 되었습니다. 다른 플랫폼들도 의미 있는 방식으로 따라잡고 있습니다. 넷리파이는 요즘 특히 줄을 서는 쪽에서도 정말 멋진 콘텐츠를 선보이고 있습니다. 저쪽에서 죽이고 있어요. 하지만 저는 여전히 Vercel이 익숙하기 때문에 Vercel에게 다가가고 있습니다

그리고 나는 그들의 기본 요소들 간의 관계를 정말 잘 이해하고 있다. 그래서 제 생각에는 이것이 조금 바뀔 것 같아요. Vercel을 사용하는 것을 좋아하지 않을 것 같지만, 거의 그 반대입니다. 저는 새로운 프레임워크를 테스트하기 위해 Vercel을 사용합니다. 새로운 프레임워크가 나오면 가장 먼저 Vercel에 배포하려고 합니다. 어떻게 되는지 알겠어요. 이제 Next.js를 사용하여 새로운 제공업체를 테스트할 수 있기를 바랍니다

Vercel을 사용하여 새로운 Svelte 버전을 시도해보면 몇 가지가 보입니다

Next.js를 사용하여 새로운 Cloudflare 작업자를 시도합니다. 저에게는 정말, 정말 신날 것 같아요. 이는 다양한 공급업체의 성능 특성, 비용 이점, 그리고 비즈니스 결정을 내릴 때 특정 공급업체에 대해 알아야 할 모든 사항을 테스트할 수 있는 매우 흥미로운 기회가 될 것입니다. 제가 이야기하고 싶은 모든 것들, 상담하고 싶은 것들, 다른 비즈니스를 돕고 싶은 것들, 여러분 모두가 저에게서 배우기 위해 여기 있는 것들... 테스트하는 것이 훨씬 쉬워질 것입니다

Cloudflare의 배송 주간에 새로 배송된 제품들은 기존의 개방형 표준을 사용하여 매우 안정적으로 Next를 배포할 수 있다면 어떨까요. 저는 Vercel을 사용하여 프레임워크를 테스트하는 것과 같은 방식으로 Next를 사용하여 다른 경쟁사를 테스트할 수 있는 매우 흥미로운 미래를 보고 있습니다. 그리고 제 추측으로는 그들도 이 미래를 보고 있는 것 같아요. 그들은 자신들의 인프라, 특히 유체 컴퓨팅과 같은 것들이 충분히 앞서 있다는 것을 알고 있기 때문에 Next의 모든 기능을 다른 곳에 배포할 수 있다면 Vercel에서 더 나은 경험을 할 수 있을 것입니다. 제 생각에는 그렇게 될 것 같아요

그들에게는 많은 의미가 있습니다. 이번 릴리스 클라이언트 계측에는 몇 가지 중요한 사항이 더 있습니다. 정말 멋진 변화입니다. 이제 고객을 위해 기기를 도입할 수 있는 특정한 단일 지점이 있습니다. 그래서 세기나 하이라이트 같은 것들은 일반적인 오류 처리와 같은 것들을 추적하는 것을 그 어느 때보다 쉽게 추가할 수 있습니다. 정말 보기 좋네요. 그들은 이미 서버 측에도 이것을 가지고 있었지만, 클라이언트 측에도 있었습니다. 아주 시원합니다. 또한 이제 그 어느 때보다 센트리와 같은 제품에 대한 최소한의 대안을 제시할 수 있는 기회가 생겼다고 생각합니다.

또한 매우 인공지능적으로 통합되어 즉시 처치할 수 있습니다. 그래서 만약 당신이 그것을 만들고 있고 채팅에 관심이 있다면, 제 DM은 트위터에 열려 있습니다. 더 많은 이야기를 듣고 싶습니다. 미래는 지금이고 준비는 지금입니다. 저는 최소 세기의 대안을 위해 약 5년 동안 준비해왔습니다. 그러니 누군가 그것을 실현해 주세요. 아, 이거 못 봤어요. Next 15.3에서 클라이언트 측 라우팅 기능을 향상시키기 위한 새로운 내비게이션 훅. 따라서 로컬 로딩 상태를 개발하고 내비게이션 취소와 같은 복잡한 제어를 구현할 수 있습니다. 항해 중에,

링크 구성 요소에 매우 유용한 추가 요소입니다.

useLinkStatusCle라이언트컴포넌트 훅은 탐색이 진행 중인지 여부를 나타내는 보류 중인 부울을 반환합니다.

정말 좋아요. 정말 좋아요. 맞춤형 로드 단계가 100배 더 좋아졌습니다. 기대돼요. 다음은 이론적으로 T3 채팅을 위해 React 라우터에서 실제로 이동할 수 있도록 하는 변경 사항입니다. 제가 하지는 않겠지만, 이전보다 훨씬 더 실행 가능해졌습니다. 그들은 TypeScript의 플러그인을 훨씬 더 좋게 만들었습니다. 멋지네요. 거의 사용하지 않아요. 저는 항상 잊어버려요. 그리고 더 이상 저에게 매우 유용한 다음 내부 자료들을 충분히 사용하지 않고 있습니다.

하지만 이 빌드 속도 변화를 정말로 테스트해보고 싶어요. T3 채팅을 얼마나 빨리 구축할 수 있는지 살펴봅시다. 최신 상태로 당겨라. 내 개발자 환경을 죽여라. 다음 버전이 조금 밀렸으니 용서해 주세요. 우리는 이것을 기반으로 실행 빌드를 할 것입니다. 현재 사용 중인 15.1.6에서 얼마나 걸리는지 확인해 보세요. 웹팩 오류로 인해 빌드에 실패했습니다. 조이, 내가 뭘 잊어버렸지? 두 번 시도해 보세요.

그래서 최대한의 M2 Pro를 바탕으로...

약 50초 정도 걸립니다. 알게 되어 좋네요. 총 28개입니다. 이 숫자들이 나뉘는 게 정말 싫지만, 50초처럼 느껴졌어요. 분명히 말하자면, 이것은 터보팩이 없는 빌드입니다. 최신 버전으로 또 다른 빌드를 진행 중입니다. 글쎄요, 터보팩을 사용하지 않고도 거의 똑같은 시간을 보냈습니다.

이제 진실의 순간을 위해 터보 팩을 제작합니다.

11초. 그게 정말 더 빨리 느껴졌어요. 알고 보니 이 숫자가 중요하네요. 지금이 CPU 시간이야, 젠장, 그게 훨씬 더 좋았거든. 하지만 제가 정말로 보고 싶은 것은 이것이 실제로 건물을 짓는 것처럼 Vercel의 인프라에서 얼마나 더 빠른지입니다. 테오, 다음 터보 버전 범프. 또한, 재미있는 점은, 이걸 만들고 싶은 사람이 있다면...

제가 있는 위치에 대해 풀 요청을 생성하는 좋은 명령은 없습니다. GHPR 창작물이 멍청하다는 것처럼.

매우, 매우 코믹하게 느립니다. 제가 찾을 수 있었던 가장 가까운 방법은 게으른 git을 사용하고, 세 번 누른 다음 O를 눌러 당기기 요청을 할 수 있는 탭을 여는 것입니다. URL을 하드코딩하기 때문에 가장 빠릅니다. 그리고 사용자 지정 명령을 작성할 수 없었습니다. 왜냐하면 게으른 git은 인수를 필요로 하지 않고 트리거를 하지 않기 때문입니다. 그래서 누군가 아주 간단한 한 줄짜리 물건처럼 만들 수 있도록 하기 위해서입니다. 그래서 매번 게으른 git을 열고 싶을 뿐입니다. 왜냐하면 지금은 본능과도 같기 때문입니다. lg30 가장 빠른 방법이기 때문입니다

하기에는 멀고 짜증나요. 어느 시점에서 트롤링을 하고 있는지 알 수가 없어요, 개발자님. GitHub MCP 서버를 추가하고 Cursor가 하도록 하세요. 문제는 지연 시간입니다. 왕복 3~10회를 추가한다고 해서 더 나아지는 것은 아닙니다. 제가 원하는 것은 지점을 누르면 적절한 것들로 URL을 자동으로 여는 것뿐입니다. 이건 빠르지 않아요. 이 명령은 매우 느립니다. 이것이 제가 하고 싶었던 일이지만, GHPR 제작은 실제로 생성하기 전에 네 번 왕복하는 것과 같습니다. 그리고 더 좋은 것은, 만약 당신이

설명이 너무 커서 커밋이 충분하면 자동으로 발생합니다.

재미로 말하자면, 완전히 망가졌다는 뜻이에요. 오, 빌드가 이미 완료되었네요. 좋아요, 그에 대한 배포 속도를 확인해 봅시다.

별로 나아지지 않았어요.

제가 안 했나요? 터보 교체를 제가 저질렀죠, 그렇죠? 상태를 확인하세요. 했다. 오, 좋은 판정이네요. 몰랐어요. 터보팩은 현재 항상 브라우저용 프로덕션 소스 맵을 구축하고 있습니다. 여기에는 프로덕션에 배포될 경우 프로젝트 소스 코드가 포함됩니다. 귀하의 번들 크기가 웹팩을 사용한 다음 빌드와 다를 수 있음을 확인했습니다. 이것은 우리가 안정성을 위해 노력함에 따라 개선될 것입니다. 이 빌드는 디스크 캐싱이 없습니다. 디스크 캐싱이 가능해지면 후속 빌드가 더 빨라질 것입니다.

출력을 웹팩 빌드와 비교할 때, 먼저 .next 디렉토리를 삭제하여 next.js 캐시를 지워야 합니다. 알았어요. 하지만 왜 더 빠르지 않았을까요?

우리는 이미 그것보다 더 빠른 빌드를 가지고 있습니다. 쓸모없는 변화를 일으키면...

404를 바꿀게요.

이 빌드가 얼마나 걸리는지 한번 봅시다.

채팅은 패키지 잠금을 변경했기 때문에 모든 패키지를 다시 다운로드해야 했기 때문에 속도가 느리다고 의심하고 있습니다. 이제 그 부분이 적어도 이론적으로 캐시되어야 하므로 어떻게 작동하는지 살펴보겠습니다.

네, 우리는 이미 우리의 가장 짧은 빌드가 정상적으로 어떻게 생겼는지 이미 넘어섰습니다. 네, 그곳의 편집 단계는 여전히 1분 넘게 걸렸어요.

3253이 시작되었을 때처럼 최적화된 프로덕션 빌드를 만들기 위해 다시 스크롤합니다.

몇 가지 경고를 줬더니 3340이 되어서 거의 1분 동안 컴파일만 하면 46초라고 나와요

롤다운 퍼포먼스 이론적 승리를 과시하려고 했을 때와 마찬가지로 웃기지만, 별로 눈에 띄지 않습니다. 새 VDAP를 배포하면 빌드 시간은 약 15초 정도 되지만, 적당한 크기의 다음 앱은 여전히 1.5분에서 2분 정도입니다. 하지만 프로덕션 빌드와 마찬가지로 마지막 빌드도 누락된 아이콘을 추가하는 것이었습니다. 57초.

여기서는 별로 빠르지 않아요.

제 생각에는 빌드에서 실행되는 박스들이 단일 코어인 것 같아요. 왜냐하면 역사적으로 멀티 코어가 빌드 성능에 도움이 되지 않았기 때문이에요. 그리고 저는 그들이 이 변화와 함께 빌드 박스를 강화하거나 여러 개의 코어를 제공하기를 바랍니다. 그래도 더 많은 것을 기대하고 있었어요. 그래도 미리보기 빌드가 작동하는지 한번 봅시다.

이 URL에 대한 설정이 없기 때문에 캡처가 실패할 가능성이 높습니다.

네, 알고 있었어요. 하지만 빌드에서는 모든 것이 작동합니다. 정말 멋지네요. 제작 준비가 된 것 같지만, 더 큰 완벽한 승리를 기대하고 있었어요. 자체 빌드 파이프라인을 운영한다면 엄청난 규모가 될 수 있습니다.

하지만 안타깝게도 배포 파이프라인은 아직 의미 있는 변화를 보지 못하고 있습니다. 저는 그렇게 되기를 매우 바랐습니다. 하지만 제 기계에서는 실제로 사용할 수 있는 여러 개의 코어가 있는 곳이 더 빨리 작동합니다. 전체 프로젝트의 컴파일 단계는 6.3초로 매우 재미있습니다. 이전에는 빨리 풀면...

시간, ppm, 실행, 빌드.

그래서 여기서 빌드는 두 배의 긴 총합을 차지했지만, 흥미로운 숫자는 15초 만에 6초 만에 성공적으로 컴파일되었습니다. 6.3, 15.0. 그것은 큰 차이이며, 제가 매우 기대하고 있는 부분입니다. 하지만 이론적으로 개선할 수 있는 숫자는 그것뿐입니다. 또 다른 재미있는 점은 모두가 저에게 사용하라고 말하는 HTOP 대안이 무엇인지 궁금합니다? BTOP을 설치하지 않았습니다. 나도 그렇게 생각했어. 여러분, 감사합니다.

멋지네요. 터보팩을 사용하지 않고 다시 한 번 실행하면 여기서 제 활용도를 확인할 수 있습니다. 그리고 여기서 사용하는 컴퓨터에서 스트리밍하지 않는다는 점을 명심하세요. HDMI를 사용하는 별도의 Windows 장비가 있습니다. 여기서 사용되는 것은 제가 사용하는 모든 앱과 이 컴파일뿐입니다. 그리고 여기서 제 코어가 실제로 많이 활용되지 않는 것을 볼 수 있습니다. 대부분이 이 컴파일에서 사용되는 것보다 Thunderbolt 포트와 제 브라우저에서 더 많이 사용되고 있는 것 같아요.

그리고 만약 내가 .next를 죽이고 다시 실행한다면, 잊어버렸기 때문에,

제 코어 중 하나가 최대 60%까지 사용된 것을 확인하세요. 네, 그 핵심이 바로 이 기능을 실행하는 것입니다. 그리고 이제 이미 분할할 수 있는 경로에 대한 번들링을 수행하고 있습니다. 이제 다 된 것 같아요. 가까워졌다는 걸 알아요. 네. 하지만 대부분의 작업이 하나의 코어에서만 진행된다는 것을 매우 명확하게 알 수 있습니다. 이제 끝났으니, 그다지 빠르지 않았다는 것을 알 수 있습니다. 돌아가서 터보팩을 다시 켜면...

자, 여기 보시면, 네, 보이시죠? 그게 차이점이야. 제 모든 코어가 사용되고 있습니다. 아, 제 단말기가 충분히 넓지 않네요. 이런 망할.

얼굴을 숨길 수가 없어요. 이걸 그냥 옮길게요. 이미 끝났다. 시간을 pmp로 설정하고 빌드를 실행합시다. 멋져. 여기서 제 모든 코어가 망치질을 당하고 있는 것을 볼 수 있습니다. 그 6초 동안 내 시스템을 최대한 활용하고, 그 후에 완료됩니다. 그러면 모든 것이 느려집니다. 하지만 제가 Next.js JavaScript 빌드를 한 것은 이번이 처음이에요. 제 컴퓨터의 모든 코어를 사용해서요. 총 컴퓨팅 사용량이 아마 더 많을 것 같지만, 결과는 놀랍습니다.

훨씬 더 빠른 빌드, 정말 멋지네요.

네. 성능 특성과 이것이 어떻게 더 좋고 나쁨, 그리고 차이점이 무엇인지 이해하는 데 도움이 되기를 바랍니다. 이제 앱을 배포하고 싶은 모든 곳을 지원하는 플랫폼으로서 Next.js의 미래에 대해 제가 기대하는 이유도 이해하셨기를 바랍니다. 기대돼요. 이것은 Next.js에 대한 올바른 결정인 것 같고, 또한 제가 점점 더 밀어붙이고 있는 아이디어이기도 합니다. 왜냐하면 AI는 이미 우리가 사용하는 모든 것에 대해 훈련되었기 때문에 프레임워크의 미래가 무한한 새로운 기능과 구문 등 모든 것이 될 것 같지 않다는 것입니다. 그래서 제 추측으로는...

시간이 지남에 따라 새로운 API와 기능을 추가하는 데 중점을 두지 않고 기존 출력, 기존 코드, 기존 AI 도구 및 모델이 새로운 구문을 사용하지 않고도 모두 혜택을 받을 수 있도록 기존 API와 기능을 개선하는 데 중점을 둔 릴리스가 점점 더 많아지고 있습니다. 이번 출시 이후 넥스트에 대한 당신의 감정이 바뀌고 있나요? 댓글로 알려주세요. 그리고 다음 번까지는 평화 덕후들.