00:00:00(밝은 음악) - 안녕하세요.
00:00:06저는 리디아입니다.
00:00:07저는 BUN의 대변인입니다.
00:00:11저를 알고 계신 분들이라면 JavaScript 런타임과 성능에 대해 이야기하는 것을 좋아한다는 걸 아실 거예요.
00:00:17사실 BUN에 합류하기 전에는 Vercel에서 몇 년간 근무했고 개발자들이 더 빠르게 앱을 만드는 방법을 가르쳤습니다.
00:00:24그래서 오늘 Next 프레임워크의 성능과 BUN 런타임의 성능을 결합하면 얼마나 더 좋아질 수 있는지 보여줄 수 있어서 정말 흥분됩니다.
00:00:35하지만 BUN 자체에 대해 얘기하기 전에,
00:00:38처음에 Next.js 같은 프레임워크를 정말 특별하게 만드는 게 뭔지 보여주고 싶습니다.
00:00:45왜냐하면 이들은 우리가 웹 성능을 보는 방식을 완전히 재정의했거든요.
00:00:49단순히 웹사이트를 빠르게 만든 게 아닙니다.
00:00:52전체 과정을 간소화했습니다.
00:00:55Webpack으로 똑똑한 번들링을 구현했고, 지금은 Turbo Pack이 있습니다.
00:00:59기본 제공되는 이미지와 폰트 최적화가 있습니다.
00:01:02효율적인 서버 사이드 렌더링,
00:01:05정적 렌더링이 있고,
00:01:06이제 ISR과 RSC를 사용해 데이터 페칭을 컴포넌트 자체에 넣었습니다.
00:01:12이러한 모든 개선사항들이 프레임워크가 최적화할 수 있는 것을 확장시켰지만, 정말로는 일정 수준까지만입니다.
00:01:21Next.js가 아직 최적화하지 못한 하나의 기본적인 레이어가 항상 있었습니다.
00:01:26이것은 엔지니어링 노력이나 역량 부족 때문이 아니라, 단순히 Next의 범위를 벗어나는 것입니다.
00:01:34그것은 바로 런타임입니다.
00:01:37일반적으로 Next dev를 실행하거나 Vercel에 배포할 때, Next 앱은 Node에서 실행됩니다.
00:01:42이는 Node의 런타임이 JavaScript를 실행한다는 뜻입니다.
00:01:45이벤트 루프, 파일 IO, 모든 것을 관리합니다.
00:01:49그리고 JavaScript 코드를 운영체제에 연결합니다.
00:01:53이는 Node가 지난 약 15년 동안 기본 런타임이었기 때문에 당연합니다.
00:01:59검증되었고 안정적이지만, 2025년에는 약간의 병목이 되었습니다.
00:02:06오해하지 마세요, Node는 환상적입니다.
00:02:09서버에서 JavaScript를 실행할 수 있게 만들었습니다.
00:02:13그 전에, 2009년에 Node가 소개되기 전까지 JavaScript는 정말 브라우저에만 존재했습니다.
00:02:20Node는 JavaScript 엔진,
00:02:22이벤트 루프,
00:02:22비동기 IO,
00:02:23브라우저가 할 수 없는 모든 것을 하는 API를 갖춘 런타임을 제공함으로써 그것을 바꿨습니다.
00:02:29파일을 디스크에서 읽기, 메모리 등 모든 것 말입니다.
00:02:33내부적으로 Node는 V8 JavaScript 엔진을 사용합니다.
00:02:37이는 Google의 빠른 Chrome 엔진으로,
00:02:40Chrome 브라우저의 탭처럼 오래 실행되는 작업에는 좋습니다.
00:02:44하지만 물론 V8은 엔진일 뿐입니다.
00:02:46이것은 JavaScript를 실행하는 것만 알고 있습니다.
00:02:49파일을 열거나 TCP 연결을 만들고, 이런 종류의 것들을 할 수 없습니다.
00:02:54그래서 여기서 Node의 기본 제공 API가 나옵니다.
00:02:57FS, HTTP, NET 등이 있습니다.
00:03:01이 API들은 JavaScript 코드와 운영체제 사이의 다리 역할을 합니다.
00:03:07그리고 이 API들 자체는 libuv라는 C 라이브러리에 의존합니다.
00:03:13이것은 JavaScript 자체를 위해 만들어진 게 아닙니다.
00:03:16더 많은 Node가 파일 IO,
00:03:19네트워킹 등을 다양한 운영체제에서 할 수 있게 하는 일반적인 추상화 같은 것입니다.
00:03:27그래서 JavaScript 코드에서 fs.readFile 같은 것을 호출할 때,
00:03:32우리는 정말 단순히 컴퓨터에 이 파일을 디스크에서 읽고 싶다고 말하는 것입니다.
00:03:36하지만 거기에 도착하기 전에, 먼저 V8을 거쳐야 합니다. JavaScript 코드에서 V8로요.
00:03:42그러면 Node C++ 바인딩으로 전달됩니다.
00:03:46이것은 libuv를 호출하며, 이것은 스레드 작업과 모든 종류의 오버헤드를 언급하지도 않습니다.
00:03:52그리고 그 다음에야 libuv는 실제로 커널에 시스템 호출을 해서 이 파일을 디스크에서 가져옵니다.
00:03:58그리고 그 모든 일이 일어나는 동안,
00:04:00libuv가 사용하는 이벤트 루프가 있어서 우리의 나머지 JavaScript 코드가 여전히 실행될 수 있고 등등입니다.
00:04:06그리고 이 모델은 잘 작동합니다.
00:04:08우리는 여전히 Node를 사용하고 있지만, 최적은 아닙니다.
00:04:13그래서 2009년으로 돌아가면, Node가 소개되었을 때, 우리의 하드웨어는 매우 달랐습니다.
00:04:19서버는 아마도 4개 정도의 코어, 제한된 메모리, 그리고 저장소는 꽤 느렸습니다.
00:04:25스레드도 비용이 많이 들었기 때문에,
00:04:28모든 연결마다 새로운 스레드를 만드는 것은 정말 잘 확장되지 않았습니다.
00:04:32그래서 Node의 모델은 그 시대에 훌륭했습니다.
00:04:35우리는 하나의 스레드로 수천 개의 연결을 정말 효율적으로 처리할 수 있었거든요..
00:04:40하지만 2025년으로 빨리 감기하면, 우리의 하드웨어는 매우 다릅니다.
00:04:44이제 수백 개의 CPU 코어, 테라바이트의 메모리, 그리고 저장소는 약 50배 빨라졌습니다.
00:04:51하지만 우리는 여전히 2009년 기반의 Node 모델을 사용하고 있습니다.
00:04:55여전히 모든 것을 같은 이벤트 루프를 통해 밀어내고 있습니다.
00:04:59그리고 다시, 이것은 괜찮습니다.
00:05:00Node의 아키텍처는 서버가 며칠 동안 실행될 때는 괜찮습니다.
00:05:04하지만 현대에는, 우리는 종종 서버리스 함수를 갖거나 개발 서버를 갖습니다.
00:05:09이 모든 더 짧은 버스트 스크립트는 빠르게 시작하고 훨씬 더 짧은 시간 동안 실행해야 합니다.
00:05:16그래서 이런 환경에서는, 시작의 모든 밀리초와 모든 데이터 레이어가 중요합니다.
00:05:21왜냐하면 이들이 모두 지연시간에 추가되기 때문입니다..
00:05:24이제 다시, Next 앱을 실행할 때, 당신은 Node에서 실행하고 있습니다.
00:05:34이는 당신의 앱이 하는 모든 것,
00:05:36페이지 렌더링,
00:05:37자산 제공,
00:05:38응답 스트리밍이 우리가 방금 본 모든 레이어를 거친다는 뜻입니다.
00:05:43JavaScript에서 V8로, Node로, 모든 그런 종류의 것들입니다.
00:05:46그리고 Next는 여전히 Node 런타임이 특정 것들을 차단하고 있음에도 불구하고 성능의 모든 비트를 짜내는 놀라운 일을 해냈습니다.
00:05:57왜냐하면 결국, 이 모든 개선사항들은 여전히 Node 위에서 실행되기 때문입니다.
00:06:01그래서 개발 서버를 시작하거나 파일을 다시 빌드하고,
00:06:05핫 리로딩할 때,
00:06:06당신은 여전히 그 런타임 제한에 부딪힙니다.
00:06:09그래서 정말로 더 빨라지려면, 프레임워크를 넘어서 봐야 합니다.
00:06:13더 깊이 가야 합니다.
00:06:15런타임 자체를 다시 생각해야 합니다.
00:06:18그래서 BUN이 나오는 이유입니다.
00:06:20BUN은 단순히 Node 위에 또 다른 레이어를 만든 것이 아닙니다.
00:06:242025년에 우리가 실제로 갖고 있는 하드웨어를 위해 처음부터 새로 만들어진 런타임입니다.
00:06:33Node처럼 C++ 위에서 LibUV로 작성되는 대신, BUN은 Zig에서 빌드됩니다.
00:06:40그리고 이는 현대적 시스템 언어로, 하드웨어에 훨씬 더 가깝게 실행됩니다.
00:06:45JavaScript 엔진의 경우,
00:06:47BUN은 Apple의 정말 빠른 JavaScriptCore 엔진을 사용합니다.
00:06:51그리고 이것은 정말 빠르게 시작하는데,
00:06:54주로 V8 같은 엔진이 하는 일부 초기화 최적화를 미룰 수 있기 때문입니다.
00:06:59그리고 이것도 정말 빠르게 실행되며,
00:07:02다시,
00:07:02이는 최신 개발 서버,
00:07:04서버리스 환경,
00:07:05그리고 이 더 짧은 빌드 스크립트로 하는 최신 작업에 완벽합니다.
00:07:10핵심 런타임 자체는 Zig로 작성됩니다.
00:07:13그래서 BUN API와 비동기 I/O를 처리하는 모든 부분들입니다.
00:07:17Node가 이 모든 비동기 작업,
00:07:20파일 읽기,
00:07:21네트워크 요청 등에 LibUV를 사용하는 곳에서,
00:07:25BUN은 Zig로 작성되었기 때문에 이것들을 운영체제에 대한 직접 시스템 호출로 구현할 수 있습니다.
00:07:33이제 네트워크 요청의 경우, 우리는 uSockets를 사용하므로, 약간 다릅니다.
00:07:37하지만 우리는 LibUV 대신 Zig를 사용함으로써 많은 추상화 레이어를 제거합니다.
00:07:44그래서 이제 BUN 런타임으로 파일을 읽으려면, 물론 당신의 JavaScript 코드에서 시작합니다.
00:07:49이제 JSC 엔진으로 가고, Zig로 가서 직접 시스템 호출을 할 수 있습니다.
00:07:55그래서 다시, JavaScript 코드와 실제 운영체제 사이의 더 적은 레이어들입니다.
00:08:01그리고 결과는 시작부터 파일 접근, HTTP 서버 등 모든 것이 훨씬 더 빠르게 느껴진다는 것입니다.
00:08:09하지만 BUN은 성능에만 관한 것이 아닙니다.
00:08:12우리는 또한 100% Node 호환이 되는 것을 목표로 합니다.
00:08:15그래서 우리는 모든 Node의 API가 작동하도록 하고 싶습니다.
00:08:19하지만 S3,
00:08:20SQL,
00:08:20또는 Squeal,
00:08:21아무튼 원하는 것들 같은 엄청나게 많은 추가 기본 제공 API를 포함하고 있습니다.
00:08:27Redis, 해싱, 셀, 그 외 많은 것들입니다.
00:08:30그리고 Go나 Python 같은 다른 프로그래밍 언어를 사용해 본 적이 있다면,
00:08:35이 배터리 포함 접근 방식은 당신에게 매우 익숙할 것입니다.
00:08:39하지만 JavaScript 개발자로서,
00:08:41우리는 거의 모든 것에 대해 의존성을 설치하는 것에 너무 익숙해져 있습니다.
00:08:45저는 거의 모든 제 앱에서 비밀번호 해싱을 사용합니다.
00:08:48하지만 저는 여전히 매번 이것을 사용할 때마다 의존성을 설치해야 합니다.
00:08:52그래서 BUN이 이것을 바꿉니다.
00:08:54당신이 거의 항상 사용하는 것들은 런타임 자체에 바로 내장되어 있습니다.
00:08:59그것은 전역에 바로 내장되어 있습니다.
00:09:01그리고 다시, 이들은 단순히 NPM 의존성 위의 표면적 래퍼가 아닙니다.
00:09:06그들은 정말 Zig에 내장되어 있습니다.
00:09:08그래서 현대 하드웨어를 위해 성능에 최적화되어 있습니다.
00:09:12예를 들어, BUN은 내장 SQL 클라이언트가 있습니다.
00:09:16그래서 당신은 단일 API를 사용하여 Postgres, MySQL, SQLite에 직접 연결할 수 있습니다.
00:09:23당신은 추가 의존성을 설치할 필요가 없습니다.
00:09:26그리고 다시, 이것은 단순히 NPM 패키지를 호출하는 것이 아닙니다.
00:09:30이것은 정말 BUN이 시스템과 직접 대화하는 것입니다.
00:09:35그리고 우리가 이들을 내장한 것은 단순히 편의성만이 아닙니다.
00:09:38BUN의 옵션들은 보통 Node와 NPM 대안보다도 훨씬 빠릅니다.
00:09:44예를 들어, BUN.SQL은 Node의 MySQL 2보다 최대 11배 빠르며, 이것은 정말 좋습니다.
00:09:51또는 BUN의 S3 클라이언트를 사용할 수 있습니다.
00:09:54그리고 이것은 S3 호환 저장소와 기본으로 작동합니다.
00:09:58Amazon S3,
00:09:59Supabase Storage,
00:10:00Cloudflare R2,
00:10:01당신이 말할 수 있는 것들이 있습니다.
00:10:03그리고 다시, 이 API도 믿을 수 없을 정도로 빠릅니다.
00:10:06그래서 여기서, 우리는 Node의 AWS S3 SDK보다 최대 6배 빠른 것을 볼 수 있습니다.
00:10:12물론, 당신은 여전히 BUN 런타임과 함께 일반 의존성을 사용할 수 있습니다.
00:10:17당신은 이 기본 제공 API를 사용할 필요가 없습니다.
00:10:20하지만 그들은 당신의 번들 크기를 많이 줄입니다.
00:10:22왜냐하면 우리는 더 이상 이 의존성들을 추가하지 않기 때문입니다..
00:10:25그리고 이것은 우리가 지난달처럼 본 NPM 취약점들을 돕습니다.
00:10:29왜냐하면 당신은 그들을 설치할 필요가 없기 때문입니다..
00:10:32훨씬 더 많은 API가 있습니다.
00:10:33저는 당신이 또한 문서를 확인하기를 강력히 권장합니다.
00:10:37하지만 BUN은 런타임 이상을 포함합니다.
00:10:40이것은 또한 YARN보다 최대 17배 빠르고,
00:10:44NPM보다 7배 빠르고,
00:10:46PNPM보다 4배 빠른 정말 빠른 패키지 관리자를 포함합니다.
00:10:51그리고 좋은 점은, 당신은 BUN 런타임을 사용할 필요가 없다는 것입니다.
00:10:54BUN install을 사용하려면요..
00:10:55그리고 이것은 단지 -- 당신은 Node와 함께 BUN install을 사용할 수 있습니다.
00:10:58이것은 그냥 작동할 것입니다.
00:10:59그래서 당신은 당신의 프로젝트에 대해 뭔가 변경할 필요가 없습니다.
00:11:03이것은 또한 정말 빠른 기본 제공 번들러와 트랜스파일러가 있습니다.
00:11:06그래서 당신은 당신의 파일을 즉시 제공하고 빌드할 수 있습니다.
00:11:09그래서 당신은 Webpack, ESBuild, 추가 설정이 필요하지 않습니다.
00:11:12그리고 좋은 점은 이것도 기본적으로 TypeScript와 JSX를 지원한다는 것입니다.
00:11:18이것은 또한 vTest보다 최대 14배 빠르고 우리가 1,
00:11:21000개의 React 테스트를 SSR했을 때 jest보다 23배 빠른 정말 빠른 테스트 러너가 있습니다.
00:11:26그래서 다시, 당신은 정말 빠른 테스트를 얻습니다.
00:11:29당신은 뭔가 설치할 필요가 없습니다.
00:11:31이 모든 것이 훌륭하게 들리지만, 우리는 BUN 런타임을 어떻게 사용할 수 있을까요?
00:11:35그리고 Next에서, 솔직히 정말 간단합니다.
00:11:38BUN을 설치한 후,
00:11:39당신은 단지 당신의 시작 명령 또는 당신의 개발 명령을 업데이트하고 bun run --bun을 추가해야 합니다.
00:11:45그게 다입니다.
00:11:46당신은 이제 BUN 런타임을 실행하고 있습니다.
00:11:48이제 당신은 궁금해할 수 있습니다. 왜 나는 --bun이 필요합니까?
00:11:51좋아, 저는 이미 bun run이라고 말하고 있습니다.
00:11:54그것은 다시, BUN이 진짜 node 호환성을 신경 쓴다는 것 때문입니다.
00:11:57그래서 보통,
00:11:58만약 우리가 단지 bun run next dev를 사용하면,
00:12:01BUN은 next CLI가 그 node shebang을 사용한다는 것을 감지할 것입니다.
00:12:07그리고 그 경우, BUN은 좋아, 나는 내가 node를 사용해야 한다는 것을 이해한다고 말할 것입니다.
00:12:11그래서 그러면 그것은 그냥 node로 기본으로 돌아갈 것입니다. 비록 우리가 bun run이라고 말했어도요.
00:12:15하지만 --bun 플래그로,
00:12:16우리는 그 shebang을 건너뛰도록 강요하고 좋아,
00:12:19우리는 단지 bun 런타임을 사용하고 있다고 말합니다.
00:12:21그래서 그냥 추가 설명으로서입니다.
00:12:25그래서 이제 이 명령으로, bun이 당신의 next 개발 서버를 시작합니다.
00:12:29번들러 자체는 여전히 next입니다.
00:12:31그래서 그것은 여전히, 당신이 알다시피, Turbo Pack입니다.
00:12:33내 생각에는 Web Pack, Turbo Pack, 이제 기본값입니다.
00:12:35하지만 이제 그 모든 것 아래 런타임은,
00:12:38JavaScript를 실행하는 것,
00:12:40파일을 읽는 것,
00:12:41응답을 제공하는 것 등,
00:12:42그것이 모두 bun입니다.
00:12:44그리고 bun이 node 호환이 되도록 설계되었기 때문에,
00:12:47당신은 당신의 코드에 대해 뭔가 변경할 필요가 없습니다.
00:12:50또는 당신의 패키지 또는 당신의 미들웨어.
00:12:51모든 것이 여전히 작동해야 합니다.
00:12:53만약 그렇지 않다면, 그것도 bun의 버그로 간주됩니다.
00:12:57그것은 100% node 호환이어야 합니다.
00:12:59그래서 당신이 이것을 시도하고 있고 문제가 발생하면, 우리에게 알려주세요.
00:13:02하지만 당신은 뭔가를 다시 쓸 필요가 없습니다.
00:13:05그리고 이제 당신의 앱이 bun 위에서 실행되므로,
00:13:07당신은 bun의 모든 기본 제공 API에 접근할 수 있습니다.
00:13:10예를 들어,
00:13:10우리는 단지 S3 클라이언트를 사용할 수 있습니다,
00:13:13맞죠,
00:13:14서버 함수 같은,
00:13:14React 서버 컴포넌트,
00:13:16등에서.
00:13:16그래서 우리는 어떤 의존성도 설치할 필요가 없습니다.
00:13:18그래서 이것이 일반적으로 node와 같이 어떻게 보였을 것인지와 비교하려면,
00:13:23bun으로,
00:13:23우리는 훨씬 적은 코드를 갖습니다.
00:13:25우리는 더 적은 의존성을 갖습니다.
00:13:27그리고 이것은 즉시 모든 다른 S3 제공자와도 호환입니다.
00:13:32그래서 만약 당신이 Amazon S3에서 Cloudflare R2,
00:13:35Supabase Storage 같은 다른 제공자로 바꾸고 싶으면,
00:13:38이 모든 다른 제공자들,
00:13:39그것은 정말 간단합니다.
00:13:40또는 더 완전한 하나,
00:13:41우리는 S3,
00:13:42bun 셸,
00:13:43그리고 SQL을 React 서버 컴포넌트에서 직접 사용할 수 있습니다.
00:13:47그래서 먼저,
00:13:48우리는 SQL을 가진 데이터베이스를 쿼리 같은,
00:13:50블로그 포스트를 가져오려면,
00:13:52이미지에 대해 presign S3 URL을 생성,
00:13:55bun 셸을 사용해서 단어를 세기.
00:13:57다시, bun이 호출하고 있는 추가적인 API 레이어나 제3자 도구가 없습니다.
00:14:02Bun은 런타임, 데이터베이스 연결, 그리고 셸을 모두 SIG에서 기본적으로 처리합니다.
00:14:08하드웨어에 매우 가깝게..
00:14:10그리고 다시, 물론, S3 SQL만이 아닙니다.
00:14:12우리는 bun run --bun을 next dev 앞에 추가하는 것으로 bun의 모든 API에 접근할 수 있습니다.
00:14:20하지만 물론, 이제 당신은 생각하고 있을 수 있습니다.
00:14:22좋아, 나는 Postgres를 사용하지 않습니다..
00:14:24나는 S3를 사용하지 않습니다.
00:14:25나는 어떤 미친 의존성도 사용하지 않습니다. 그래서 내가 왜 신경을 써야 할까요?
00:14:28bun에 저를 이끈 것은 솔직히 그냥 믿을 수 없는 DX였습니다.
00:14:34당신은 단지 어떤 JS, TS, TSX, JSX, 상관없이 파일을 설정 없이 실행할 수 있습니다.
00:14:41그것은 그냥 작동합니다.
00:14:41당신은 TSNode, Babel, SWC, 등에 대해 생각할 필요가 없습니다.
00:14:46그래서 비록 당신이 next를 사용하지 않아도,
00:14:48비록 당신이 단지 개발하고 있어도,
00:14:50당신은 빠른 빌드 스크립트를 원합니다.
00:14:52그냥 bun run을 사용, 그냥 시도해봐요.
00:14:54이것은 당신의 삶을 그래서 훨씬 더 좋게 만듭니다.
00:14:56왜냐하면 당신은 어떤 설정을 필요로 하지 않기 때문입니다..
00:14:59Bun은 또한 bun x를 함께 합니다.
00:15:01그리고 이것은 NPX에 bun의 같은 종류의 것입니다.
00:15:04다시, 당신은 뭔가 변경할 필요가 없습니다.
00:15:06당신은 bun 런타임을 이것을 위해 사용할 필요가 없습니다.
00:15:08당신은 단지 NPX를 bun x로 바꿀 수 있습니다.
00:15:11그리고 당신은 즉시 시작 개선을 봅니다.
00:15:13예를 들어,
00:15:14bun x create next step를 사용하는 것은 NPX create next step보다 5배 빠릅니다.
00:15:20그리고 다시, 당신은 bun 런타임을 이것을 위해 사용할 필요가 없습니다.
00:15:23그것은 그냥 훨씬 빠릅니다.
00:15:25하지만 물론, bun install도 있으며, 다시, 런타임을 변경할 필요가 없습니다.
00:15:31기본 next 프로젝트에서도 설치를 훨씬 더 빠르게 만듭니다.
00:15:36이제 명백하게, bun을 로컬로 실행하는 것은 한 가지입니다.
00:15:39하지만 우리는 bun에서 실행되는 앱을 어떻게 배포합니까?
00:15:42왜냐하면 이것은 물론, 완전히 새로운 런타임입니다.
00:15:46당신은 이미 render,
00:15:47railway,
00:15:48또는 Docker로 당신의 앱을 컨테이너화 하는 것처럼 여러 플랫폼에서 bun에 Next.js를 사용할 수 있습니다.
00:15:54하지만 우리는 모두 Next.js 개발자입니다.
00:15:56이상적으로, 우리도 Vercel에 배포할 수 있기를 원합니다.
00:16:00그래서 자연스럽게,
00:16:01우리는 Guillermo를 트윗했고,
00:16:03Vercel에서 bun 지원에 대해 친절하게 요청했습니다.
00:16:07그리고 우리는 빠르게 꽤 좋은 응답을 얻었습니다.
00:16:10그리고 그 후 몇 주일, bun 지원은 적어도 내부적으로 달성되었습니다.
00:16:15그래서 저는 기본적 bun 지원이 Vercel에 매우 매우 곧 올 것이라는 것을 정말 흥분합니다.
00:16:20그리고 이것은 당신이 -- [박수] 예를 의미합니다.
00:16:25박수는 이것을 가능하게 한 Vercel의 훌륭한 엔지니어들을 위한 것입니다.
00:16:29하지만 이것은 정말 흥분되고 있습니다.
00:16:31왜냐하면 이것은 우리가 이제 bun 앱을 Vercel에서 다른 Next 프로젝트처럼 쉽게 실행할 수 있다는 뜻입니다..
00:16:37그래서 또한 그냥 실제 세계 예입니다.
00:16:39나는 당신이 화면에서 그것을 볼 수 있는지 확실하지 않습니다.
00:16:41하지만 bun을 가진 HONO API를 실행하는 것은 이미 30% 감소 또는 CPU 감소를 봤습니다.
00:16:46그냥 Vercel에서 bun을 실행하여..
00:16:49이것은 물론, 다른 프레임워크입니다.
00:16:50이것은 HONO API입니다.
00:16:52하지만 당신이 서버 함수, RSC, 등처럼 이것이 있었다면 얻을 것이 같은 런타임 장점입니다.
00:16:57왜냐하면 bun은 CPU와 메모리 사용에서 많이 절약하기 때문입니다.
00:17:02이제 우리는 물론, bun 지원에 대기할 필요가 없습니다. 우리의 앱에서 그것을 사용하여 시작합니다.
00:17:06가장 간단한 방법은 그것을 사용하거나 그것을 점진적으로 채택하는 것입니다.
00:17:11그래서 먼저, 저는 bun install로 전환하는 것을 권장합니다.
00:17:14당신의 코드베이스에서 아무것도 변경하지 않습니다.
00:17:16이것은 bun의 정말 빠른 패키지 관리자를 사용합니다.
00:17:19또한,
00:17:19당신이 bun install이 왜 그렇게 훨씬 더 빠른지 알고 싶어 하신다면,
00:17:22나는 불과 최근에 이 관련해서 글을 썼습니다.
00:17:24나는 당신이 그것을 확인하기를 강력히 권장합니다.
00:17:26그것은 단지 설명합니다 -- 당신이 알다시피, 우리는 단지 단계를 건너뛰지 않습니다.
00:17:29우리는 뭔가를 하고 있습니다.
00:17:29이것은 그것을 그래서 훨씬 더 빠르게 만드는 시스템 엔지니어링을 설명합니다.
00:17:35이제 bun install을 사용한 후, bun 런타임을 사용해 봅니다.
00:17:39당신은 bun run --bun로 로컬에서 그냥 그것을 사용할 수 있습니다.
00:17:42당신의 앱을 테스트합니다.
00:17:42모든 것이 작동하는지 봅니다.
00:17:44그럴 것 같습니다.
00:17:45그렇지 않으면, 우리에게 알려주세요.
00:17:47그리고 마지막으로, 당신은 그것이 이치에 맞는 곳에서 bun의 기본 API로 점진적으로 이동할 수 있습니다.
00:17:53당신은 물론, 여전히 이 NPM 의존성을 섞을 수 있습니다.
00:17:57하지만 최고의 부분은 또한 여기서 각 단계가 되돌릴 수 있다는 것입니다.
00:18:00그래서 만약 당신이 bun의 기본 API 중 하나를 사용했고 그것이 작동하지 않았다면,
00:18:04당신은 항상 그냥 node로 다시 전환할 수 있습니다.
00:18:06하지만 그것은 정말로 확인해보는 가치가 있습니다.
00:18:08이제 이 대화를 끝내기 전에, 나는 bun의 놀라운 엔지니어 팀에 정말 큰 감사를 하고 싶습니다.
00:18:17대부분 사람들은 Jared를 알 수 있지만,
00:18:19bun 뒤에는 매일 bun을 더 빠르게,
00:18:21더 안정적으로,
00:18:22그리고 훨씬 더 사용하기 재미있게 만들기 위해 정말 열심히 일하는 전체 팀이 있습니다.
00:18:27그들은 정말로 JavaScript로 가능한 것의 한계를 밀어내고 있습니다.
00:18:32그래서 Next,
00:18:33웹을 위해 어떻게 빌드하는지를 다시 상상했지만,
00:18:35bun은 그것을 무엇이 강화하는지를 다시 상상합니다.
00:18:38내 대화에 와주셔서 정말 감사합니다.
00:18:40그리고 당신이 bun과 Next로 무엇을 만들지 볼 수 있어서 정말 기대됩니다..