Transcript

00:00:00(musik yang ceria) - Halo, semua orang.
00:00:06Saya Lydia.
00:00:07Jabatan saya sebenarnya adalah Head of Propaganda di BUN.
00:00:11Dan jika kalian mengenal saya sedikit,
00:00:13kalian tahu bahwa saya suka membicarakan JavaScript runtime dan performance.
00:00:17Sebelumnya,
00:00:18saya bekerja di Vercel selama beberapa tahun untuk mengajarkan pengembang Next cara membangun aplikasi lebih cepat.
00:00:24Jadi saya sangat antusias hari ini untuk menunjukkan betapa baiknya hasilnya ketika kita menggabungkan Next Framework Performance dengan BUN's runtime performance.
00:00:35Tapi sebelum saya membahas BUN sendiri,
00:00:38saya ingin mundur sebentar dan menunjukkan apa yang membuat framework seperti Next.js begitu istimewa.
00:00:45Karena mereka benar-benar mendefinisikan ulang cara kita melihat performance di web.
00:00:49Ini bukan hanya membuat website lebih cepat.
00:00:52Ini menyederhanakan setiap bagian dari prosesnya.
00:00:55Kami mendapat bundling yang lebih cerdas dengan Webpack dan sekarang dengan Turbo Pack.
00:00:59Kami mendapat image dan font optimization yang built-in.
00:01:02Kami mendapat server-side rendering yang efisien,
00:01:05static-side rendering,
00:01:06dan sekarang kami punya ISR dan sekarang RSC untuk membawa data fetching ke dalam komponen itu sendiri.
00:01:12Dan semua perbaikan ini mendorong apa yang dapat dioptimalkan framework,
00:01:18tapi hanya sampai titik tertentu.
00:01:21Selalu ada satu layer fundamental yang belum bisa dioptimalkan oleh Next.js.
00:01:26Dan ini bukan karena kekurangan engineering effort atau capability,
00:01:31tapi hanya di luar scope Next.
00:01:34Dan itu adalah runtime itu sendiri.
00:01:37Normalnya ketika kamu menjalankan Next dev atau deploy ke Vercel,
00:01:40aplikasi Next kamu berjalan di atas Node.
00:01:42Ini berarti bahwa Node's runtime mengeksekusi JavaScript kamu.
00:01:45Ini mengelola event loop, file IO, semuanya.
00:01:49Dan ini bridge kode JavaScript kamu ke operating system.
00:01:53Dan ini masuk akal karena Node sudah menjadi default runtime selama sekitar 15 tahun terakhir.
00:01:59Sudah teruji dalam pertempuran,
00:02:01dapat diandalkan,
00:02:03tapi di 2025,
00:02:04ini juga menjadi bottleneck.
00:02:06Jangan salah paham, Node fantastis.
00:02:09Ini memungkinkan kita untuk menjalankan JavaScript di server.
00:02:13Sebelumnya,
00:02:14seperti sebelum Node diperkenalkan pada 2009,
00:02:17JavaScript hanya untuk browser.
00:02:20Node mengubah itu dengan memberikan kita runtime dengan JavaScript engine,
00:02:24event loop,
00:02:24async IO,
00:02:25dan APIs untuk melakukan semua hal yang browser tidak bisa lakukan.
00:02:29Seperti membaca file dari disk, memory, semua itu.
00:02:33Sekarang under the hood,
00:02:35Node menggunakan V8 JavaScript engine.
00:02:37Ini adalah fast Chrome engine dari Google,
00:02:39yang bagus untuk long running tasks,
00:02:42seperti tab di browser Chrome kamu.
00:02:44Tapi tentu saja, V8 hanya sebuah engine.
00:02:46Ini hanya tahu cara mengeksekusi JavaScript.
00:02:49Ini tidak bisa membuka file,
00:02:51membuat TCP connections,
00:02:53dan semua hal seperti itu.
00:02:54Jadi di situlah Node's built-in APIs masuk.
00:02:57Seperti FS, HTTP, NET, dan sebagainya.
00:03:01Jadi APIs ini seperti bridge antara kode JavaScript kita dan operating system.
00:03:07Dan APIs ini sendiri bergantung pada C library yang disebut libuv.
00:03:13Ini tidak dibangun untuk JavaScript itu sendiri.
00:03:16Ini lebih seperti abstraction generik yang Node gunakan untuk bisa melakukan hal seperti file IO,
00:03:23networking,
00:03:23dan semacamnya di semua operating system yang berbeda ini.
00:03:27Jadi ketika kita memanggil sesuatu seperti fs.read file di kode JavaScript kita,
00:03:31kita benar-benar hanya meminta komputer,
00:03:33seperti,
00:03:34saya ingin membaca file ini dari disk.
00:03:36Tapi sebelum kita bisa sampai di sana,
00:03:38pertama itu harus melalui V8,
00:03:40atau seperti dari kode JavaScript ke V8.
00:03:42Kemudian itu melewatinya ke Node C++ binding.
00:03:46Ini kemudian memanggil libuv,
00:03:47dan ini bahkan tidak menyebutkan thread work dan semua overhead seperti itu.
00:03:52Dan hanya kemudian libuv benar-benar membuat system call ke kernel kita untuk benar-benar mendapatkan file ini dari disk.
00:03:58Dan sementara semua itu terjadi,
00:04:00kami memiliki event loop yang digunakan libuv sehingga sisa kode JavaScript kita masih bisa mengeksekusi dan sebagainya.
00:04:06Dan model ini bekerja dengan baik.
00:04:08Kami masih menggunakan Node, tapi ini tidak optimal.
00:04:13Jadi kembali ke 2009,
00:04:14jadi lagi ketika Node diperkenalkan,
00:04:17hardware kita terlihat sangat berbeda.
00:04:19Server mungkin hanya punya empat core,
00:04:22memory terbatas,
00:04:23dan storage cukup lambat.
00:04:25Thread juga mahal,
00:04:27jadi membuat thread baru untuk setiap koneksi tidak benar-benar scale dengan baik.
00:04:32Jadi model Node bagus untuk era itu karena kita bisa menggunakan satu thread untuk menangani ribuan koneksi dengan sangat efisien.
00:04:40Tapi fast forward ke 2025,
00:04:41hardware kita terlihat sangat berbeda.
00:04:44Kita sekarang punya ratusan CPU cores,
00:04:47terabyte memory,
00:04:48dan storage sekitar 50 kali lebih cepat.
00:04:51Tapi kita masih menggunakan model Node berdasarkan 2009.
00:04:55Ini masih mendorong semuanya melalui event loop yang sama.
00:04:59Dan lagi, ini baik-baik saja.
00:05:00Seperti arsitektur Node baik-baik saja ketika server berjalan selama berhari-hari.
00:05:04Tapi di era modern,
00:05:05kita sering punya serverless functions atau kita punya dev servers.
00:05:09Semua ini lebih seperti short burst scripts yang harus startup cepat dan berjalan untuk waktu yang jauh lebih singkat.
00:05:16Jadi di environment ini,
00:05:18setiap millisecond dari startup dan setiap data layer penting di sini karena mereka semua menambah latency.
00:05:24Sekarang lagi,
00:05:26ketika kamu menjalankan aplikasi next kamu,
00:05:30kamu menjalankannya di atas Node.
00:05:34Jadi ini berarti bahwa semuanya yang aplikasi kamu lakukan,
00:05:37seperti rendering pages,
00:05:38serving assets,
00:05:39streaming responses,
00:05:40mereka semua melalui semua layer yang kita lihat.
00:05:43Jadi dari JavaScript ke VA ke Node, semua hal seperti itu.
00:05:46Dan Next telah melakukan pekerjaan yang luar biasa dalam menekan setiap bit dari performance terlepas dari kenyataan bahwa Node runtime masih memblokir hal-hal tertentu.
00:05:57Karena pada akhir hari,
00:05:58semua perbaikan ini masih berjalan di atas Node.
00:06:01Jadi ketika kamu spin up seperti dev server atau rebuild files,
00:06:05hot reloading,
00:06:06kamu masih hit those runtime limits.
00:06:09Jadi jika kita benar-benar ingin lebih cepat,
00:06:11kita harus melihat beyond the framework.
00:06:13Kita harus go a level deeper.
00:06:15Kita harus rethink the runtime itu sendiri.
00:06:18Jadi di sinilah BUN masuk.
00:06:20BUN bukan hanya seperti layer lain yang dibangun di atas Node.
00:06:24Ini adalah brand new runtime yang dibangun dari nol untuk hardware yang kita punya di 2025.
00:06:33Jadi alih-alih ditulis di C++ di atas LibUV seperti yang kamu lihat dengan Node,
00:06:38BUN dibangun di Zig.
00:06:40Dan ini adalah modern systems language yang berjalan jauh lebih dekat ke metal.
00:06:45Jadi untuk JavaScript engine,
00:06:47BUN menggunakan JavaScript core engine dari Apple yang sangat cepat.
00:06:51Dan ini spin up benar-benar cepat,
00:06:53terutama karena ini bisa defer beberapa initialization optimizations yang engine seperti V8 lakukan.
00:06:59Dan ini juga hanya berjalan dengan sangat cepat,
00:07:02yang,
00:07:02lagi,
00:07:03sempurna untuk modern tasks yang kita gunakan sekarang dengan dev servers,
00:07:07serverless environments,
00:07:09dan short build scripts ini.
00:07:10Core runtime itu sendiri ditulis di Zig.
00:07:13Jadi BUN APIs dan semua bagian yang handle async I/O.
00:07:17Jadi di mana Node menggunakan LibUV untuk semua async operations ini,
00:07:22seperti reading files,
00:07:24network requests,
00:07:25dan sebagainya,
00:07:26BUN bisa implement ini sebagai direct system calls ke operating system karena ditulis di Zig.
00:07:33Sekarang untuk network requests,
00:07:35kita menggunakan useSockets,
00:07:36jadi ini sedikit berbeda.
00:07:37Tapi kita menghapus begitu banyak layers dari abstraction dengan menggunakan Zig daripada LibUV.
00:07:44Jadi sekarang jika kamu ingin membaca file dengan BUN runtime,
00:07:47ini masih goes,
00:07:48tentu saja,
00:07:48dari kode JavaScript kamu.
00:07:49Ini sekarang goes ke JSC engine ke Zig,
00:07:52yang bisa kemudian membuat direct system call.
00:07:55Jadi lagi,
00:07:56fewer layers antara kode JavaScript kita dan actual operating system.
00:08:01Dan hasilnya di sini adalah bahwa semuanya terasa jauh lebih cepat dari startup ke file access,
00:08:07HTTP servers,
00:08:08dan sebagainya.
00:08:09Tapi BUN bukan hanya tentang performance.
00:08:12Kita juga aim untuk 100% Node compatible.
00:08:15Jadi kita ingin make sure bahwa semua Node's own APIs bekerja.
00:08:19Tapi kemudian ini juga ships dengan tons dari additional built-in APIs,
00:08:23seperti S3,
00:08:24SQL,
00:08:24atau Squeel,
00:08:25atau apapun yang kamu inginkan.
00:08:27Redis, hashing, shell, banyak sekali hal.
00:08:30Dan jika kamu pernah menggunakan programming languages lain,
00:08:33seperti Go atau Python,
00:08:35pendekatan batteries-included seperti ini sangat familiar untuk kamu.
00:08:39Tapi sebagai JavaScript developers,
00:08:41kita baru saja terbiasa install dependencies untuk hampir semuanya.
00:08:45Saya menggunakan password hashing di hampir semua aplikasi saya.
00:08:48Tapi saya masih harus install dependency setiap kali saya menggunakannya.
00:08:52Jadi BUN mengubah itu.
00:08:54Barang yang kamu gunakan hampir sepanjang waktu hanya built right into the runtime itu sendiri.
00:08:59Ini hanya built on the global.
00:09:01Dan lagi,
00:09:01ini bukan hanya seperti surface-level wrappers di atas NPM dependency.
00:09:06Mereka benar-benar built in Zig.
00:09:08Jadi mereka optimized untuk performance untuk modern hardware.
00:09:12Jadi misalnya, BUN punya built-in SQL client.
00:09:16Jadi kamu bisa connect langsung ke Postgres,
00:09:20MySQL,
00:09:20dan SQLite menggunakan single API.
00:09:23Kamu tidak perlu install apapun dependencies tambahan.
00:09:26Dan lagi, ini bukan hanya calling beberapa NPM package.
00:09:30Ini benar-benar semua BUN yang berbicara langsung ke system.
00:09:35Dan ini bukan hanya convenience yang kita punya ini built in.
00:09:38BUN's options biasanya juga jauh lebih cepat daripada Node dan NPM alternatives.
00:09:44Jadi misalnya di sini,
00:09:45BUN.SQL up to 11 kali lebih cepat daripada MySQL 2 di Node,
00:09:50yang benar-benar bagus.
00:09:51Atau kamu bisa gunakan seperti BUN's S3 clients.
00:09:54Dan ini bekerja out dari the box dengan apapun S3-compatible storage.
00:09:58Jadi Amazon S3,
00:09:59Super Base Storage,
00:10:01Cloudflare R2,
00:10:02kamu tahu deh.
00:10:03Dan lagi, juga API ini incredibly fast.
00:10:06Jadi di sini,
00:10:07kita bisa lihat bahwa ini up to seperti enam kali lebih cepat daripada AWS S3 SDK di Node.
00:10:12Sekarang tentu saja,
00:10:13kamu masih bisa gunakan dependencies normal kamu dengan BUN runtime juga.
00:10:17Kamu tidak perlu gunakan APIs built-in ini.
00:10:20Tapi mereka benar-benar kurangi bundle size kamu,
00:10:23karena kita tidak lagi adding dependencies ini.
00:10:25Dan ini membantu dengan NPM vulnerabilities yang kita lihat seperti bulan lalu,
00:10:30karena kamu tidak perlu install mereka.
00:10:32Ada tons lebih APIs.
00:10:33Saya sangat recommend bahwa kamu check out the docs juga.
00:10:37Tapi BUN comes dengan way lebih dari hanya runtime.
00:10:40Ini juga ships dengan really fast package manager yang up to 17 kali lebih cepat daripada YARN,
00:10:46tujuh kali lebih cepat daripada NPM,
00:10:48dan empat kali lebih cepat daripada PNPM.
00:10:51Dan good thing-nya,
00:10:52kamu tidak perlu gunakan BUN runtime untuk gunakan BUN install.
00:10:55Dan ini hanya-- kamu bisa gunakan BUN install dengan Node.
00:10:58Ini akan hanya bekerja.
00:10:59Jadi kamu tidak perlu ubah apapun tentang project kamu.
00:11:03Ini juga punya really fast built-in bundler dan transpiler.
00:11:06Jadi kamu bisa serve dan build files kamu instantly.
00:11:09Jadi kamu tidak butuh Webpack, ESBuild, no extra setup.
00:11:12Dan nice thing-nya adalah ini juga supports TypeScript dan JSX right out dari the box.
00:11:18Ini juga punya really fast test runner yang up to 14 kali lebih cepat daripada vTest dan 23 kali lebih cepat daripada jest ketika kita SSR'd seperti 1,
00:11:25000 React tests.
00:11:26Jadi lagi, kamu dapat really fast tests.
00:11:29Kamu tidak perlu install apapun.
00:11:31Jadi semua ini sounds hebat,
00:11:33tapi bagaimana kita bisa gunakan BUN runtime?
00:11:35Dan next, honestly, ini benar-benar simple.
00:11:38Setelah install BUN,
00:11:39kamu hanya perlu update start command kamu atau dev command kamu dan add bun run --bun.
00:11:45Itu saja.
00:11:46Kamu sekarang running the BUN runtime.
00:11:48Sekarang kamu might be wondering,
00:11:50kenapa saya perlu --bun itu?
00:11:51Seperti, saya sudah saying bun run.
00:11:54Itu,
00:11:54lagi,
00:11:55karena BUN really cares tentang node compatibility.
00:11:57Jadi normalnya,
00:11:59jika kita hanya gunakan bun run next dev,
00:12:02BUN akan detect bahwa next CLI uses bahwa node shebang.
00:12:07Dan dalam hal itu,
00:12:07BUN akan seperti,
00:12:08OK,
00:12:09saya mengerti bahwa saya harus gunakan node.
00:12:11Jadi kemudian itu akan hanya default back ke node,
00:12:14walaupun kita said bun run.
00:12:15Tapi dengan --bun flag,
00:12:16kita seperti forcing bahwa itu untuk skip the shebang dan say,
00:12:19OK,
00:12:20kita hanya gunakan the bun runtime.
00:12:21Jadi hanya sebagai kind dari extra explanation.
00:12:25Jadi sekarang dengan command ini,
00:12:27bun start your next dev server.
00:12:29The bundler itu sendiri masih next.
00:12:31Jadi itu masih, kamu tahu, Turbo Pack.
00:12:33Saya guess Web Pack, Turbo Pack, sekarang itu the default.
00:12:35Tapi sekarang the runtime underneath semua itu,
00:12:38jadi the thing yang mengeksekusi JavaScript kamu,
00:12:40reading files,
00:12:41serving responses,
00:12:42dan sebagainya,
00:12:43itu semua bun.
00:12:44Dan karena bun adalah designed untuk be node compatible,
00:12:47kamu shouldn't harus ubah apapun tentang kode kamu.
00:12:50Atau packages kamu atau middleware kamu.
00:12:51Semuanya should masih be working.
00:12:53Jika tidak, itu juga considered a bug di bun.
00:12:57Ini harus 100% node compatible.
00:12:59Jadi jika kamu trying ini,
00:13:00kamu run into issues,
00:13:02let us know.
00:13:02Tapi kamu shouldn't harus rewrite apapun.
00:13:05Dan sekarang bahwa aplikasi kamu runs di atas bun,
00:13:07kamu dapat access ke semua bun's built-in APIs.
00:13:10Jadi misalnya,
00:13:10kita bisa hanya gunakan the S3 client,
00:13:12kan,
00:13:13dalam seperti server function,
00:13:14dalam React server untuk component,
00:13:16dan sebagainya.
00:13:16Jadi kita tidak perlu install apapun dependencies.
00:13:18Jadi hanya untuk compare apa yang normalnya akan terlihat seperti ini dengan ini dengan node,
00:13:22kamu bisa lihat bahwa dengan bun,
00:13:24kita punya a lot lebih sedikit kode.
00:13:25Kita punya fewer dependencies.
00:13:27Dan ini instantly compatible dengan all the other S3 providers juga.
00:13:32Jadi jika kamu ingin ubah dari Amazon S3 ke seperti Cloudflare R2,
00:13:36super base storage,
00:13:37semua providers lainnya,
00:13:39itu super simple.
00:13:40Atau a lebih seperti complete one,
00:13:42kita bisa gunakan S3,
00:13:43the bun shell,
00:13:44dan SQL langsung dalam a React server component.
00:13:47Jadi pertama,
00:13:48kita seperti query the database dengan SQL untuk fetch a blog post,
00:13:52generate a presign S3 URL untuk the image,
00:13:54gunakan the bun shell untuk count the words.
00:13:57Lagi,
00:13:57tidak ada extra seperti API layer atau third party tools yang bun adalah calling.
00:14:02Bun handles the runtime,
00:14:03the database connections,
00:14:05dan the shell semua natively dalam SIG,
00:14:08jadi close ke the metal.
00:14:10Dan lagi, tentu saja, itu bukan hanya S3 SQL.
00:14:12Kita dapat access ke semua bun's APIs oleh hanya adding bun run --bun di depan next dev.
00:14:20Tapi tentu saja,
00:14:21sekarang kamu might be thinking,
00:14:22OK,
00:14:23saya tidak using Postgres.
00:14:24Saya tidak using S3.
00:14:25Saya tidak using apapun crazy dependencies,
00:14:27jadi kenapa saya should care?
00:14:28The thing yang got saya into bun sebelum saya joined adalah honestly hanya the incredible DX.
00:14:34Kamu bisa hanya run apapun JS,
00:14:36TS,
00:14:37TSX,
00:14:37JSX,
00:14:38tidak matters file tanpa apapun configuration.
00:14:41Itu hanya works.
00:14:41Kamu tidak perlu think tentang TSNode,
00:14:44Babel,
00:14:45SWC,
00:14:45dan sebagainya.
00:14:46Jadi bahkan jika kamu tidak using next,
00:14:48bahkan jika kamu hanya sedang developing,
00:14:50kamu ingin a quick build script,
00:14:52hanya gunakan bun run,
00:14:53hanya try itu,
00:14:54itu makes your life begitu much lebih baik karena kamu tidak need apapun configuration.
00:14:59Bun juga comes dengan bun x.
00:15:01Dan ini adalah bun's kind dari equivalent ke NPX.
00:15:04Lagi, kamu tidak perlu ubah apapun.
00:15:06Kamu tidak perlu gunakan the bun runtime untuk ini.
00:15:08Kamu bisa hanya ubah NPX dengan bun x.
00:15:11Dan kamu lihat instant startup improvements.
00:15:13Jadi misalnya,
00:15:14menggunakan bun x create next step adalah seperti lima kali lebih cepat daripada NPX create next step.
00:15:20Dan lagi,
00:15:21kamu tidak perlu gunakan the bun runtime untuk ini.
00:15:23Itu hanya a lot lebih cepat.
00:15:25Tapi tentu saja,
00:15:26ada juga bun install,
00:15:27yang lagi,
00:15:28tidak require kamu untuk ubah the runtime.
00:15:31Itu hanya makes your installs begitu much lebih cepat,
00:15:34juga di basic next projects.
00:15:36Sekarang obviously, running bun locally adalah one thing.
00:15:39Tapi bagaimana kita deploy apps yang run di atas bun?
00:15:42Karena ini adalah, tentu saja, a whole new runtime.
00:15:46Sekarang kamu sudah bisa gunakan Next.js di bun di beberapa platforms seperti render,
00:15:51railway,
00:15:51atau containerize aplikasi kamu dengan Docker.
00:15:54Tapi kita semua adalah Next.js developers.
00:15:56Idealnya, kita juga ingin bisa deploy ke Vercel.
00:16:00Jadi naturally,
00:16:01kita tweeted Guillermo,
00:16:03kindly asking him untuk native bun support di Vercel.
00:16:07Dan kita dengan cepat got a pretty promising response.
00:16:10Dan kemudian a couple weeks later,
00:16:12bun support telah achieved at least internally.
00:16:15Jadi saya sangat excited bahwa native bun support akan datang ke Vercel very,
00:16:20very soon.
00:16:20Dan ini means bahwa kamu'll be able-- [APPLAUSE] Ya.
00:16:25Applause goes ke the great engineers di Vercel yang made this possible.
00:16:29Tapi ini adalah very exciting karena ini means bahwa kita sekarang dapat run bun apps just sebagai easy sebagai any other Next project di Vercel.
00:16:37Jadi juga hanya a real world example.
00:16:39Saya tidak sure jika kamu bisa lihat itu di the screen.
00:16:41Tapi running a HONO API dengan bun sudah saw a 30% drop atau a CPU drop oleh hanya running bun di Vercel.
00:16:49Ini adalah, tentu saja, a different framework.
00:16:50Ini adalah HONO API.
00:16:52Tapi itu adalah the same runtime benefits bahwa kamu akan dapat jika ini adalah seperti a server function,
00:16:56RSC,
00:16:57dan sebagainya.
00:16:57Karena bun saves a lot dalam CPU dan memory usage.
00:17:02Sekarang kita,
00:17:02tentu saja,
00:17:03tidak perlu wait untuk native bun support ke start using itu dalam aplikasi kita.
00:17:06The simplest way adalah kind dari ke start using itu atau untuk adopt itu incrementally.
00:17:11Jadi pertama, saya recommend hanya switch ke bun install.
00:17:14Changes nothing dalam kode kamu basis.
00:17:16Ini hanya menggunakan bun's really fast package manager.
00:17:19Juga,
00:17:19jika kamu interested dalam knowing kenapa bun install adalah begitu much lebih cepat,
00:17:22saya wrote an article di ini tidak terlalu lama yang lalu.
00:17:24Saya highly recommend kamu check itu out.
00:17:26Itu hanya explains-- kamu tahu,
00:17:27kita tidak hanya skipping steps.
00:17:29Kita sedang doing whatever.
00:17:29Itu kind dari explains the systems engineering di balik itu yang makes itu begitu much lebih cepat.
00:17:35Sekarang setelah menggunakan bun install,
00:17:37kemudian try ke gunakan the bun runtime.
00:17:39Kamu bisa hanya gunakan itu locally dengan bun run --bun.
00:17:42Test aplikasi kamu.
00:17:42Lihat jika semuanya works.
00:17:44Itu should.
00:17:45Jika tidak, let us know.
00:17:47Dan kemudian lastly,
00:17:48kamu bisa kind dari incrementally pindah ke bun's native APIs di mana itu makes sense.
00:17:53Kamu bisa,
00:17:53tentu saja,
00:17:54masih mix dan match ini NPM dependencies.
00:17:57Tapi the best part adalah juga bahwa each step di sini adalah reversible.
00:18:00Jadi jika kamu did gunakan salah satu bun's native APIs dan itu tidak bekerja,
00:18:04kamu bisa always hanya switch back ke node.
00:18:06Tapi itu adalah definitely worth checking out.
00:18:08Sekarang sebelum saya end ini talk,
00:18:10saya hanya ingin say a really big thank you ke the amazing team dari engineers di bun.
00:18:17Kebanyakan orang mungkin tahu Jared,
00:18:19tapi ada an entire team di balik bun yang bekerja begitu keras every day untuk make bun even faster,
00:18:24lebih stable,
00:18:25dan begitu much lebih fun untuk use.
00:18:27Mereka truly pushing the limits dari apa yang mungkin dengan JavaScript.
00:18:32Jadi next,
00:18:33re-imagined bagaimana kita build untuk the web,
00:18:35tapi bun re-imagines apa yang powers itu.
00:18:38Thank you begitu much untuk coming ke my talk,
00:18:40dan saya so excited untuk lihat apa yang kamu'll be building dengan bun dan Next.

Key Takeaway

Bun adalah runtime JavaScript revolusioner yang dibangun dengan Zig untuk menggantikan keterbatasan Node.js pada hardware modern, menawarkan performa drastis lebih cepat dan integrasi seamless dengan Next.js.

Highlights

Bun adalah runtime JavaScript baru yang dibangun dari nol menggunakan bahasa Zig untuk hardware modern 2025, bukan hanya layer di atas Node.js

Bun menggunakan JavaScript Core engine dari Apple yang jauh lebih cepat untuk startup, cocok untuk serverless functions dan dev servers yang membutuhkan burst cepat

Runtime Bun menghilangkan banyak abstraction layer dengan membuat direct system calls ke kernel, dibandingkan Node yang melalui V8, C++ bindings, dan libuv

Bun menyediakan built-in APIs seperti SQL, S3, shell, hashing tanpa perlu menginstall dependencies, dengan performa hingga 11x lebih cepat dari alternatif Node

Integrasi dengan Next.js sangat mudah cukup dengan menambahkan flag --bun, dan Vercel segera akan memberikan native support untuk menjalankan aplikasi Bun

Bun's package manager 17x lebih cepat dari YARN, bundler/transpiler built-in mendukung TypeScript dan JSX tanpa setup, dan test runner 23x lebih cepat dari Jest

Adopsi Bun bisa dilakukan secara incremental mulai dari bun install, testing runtime locally, hingga migrasi ke native APIs Bun tanpa mengubah kode yang ada

Timeline

Pengenalan dan Latar Belakang Pembicara

Lydia, Head of Propaganda di Bun yang sebelumnya bekerja di Vercel untuk mengoptimalkan Next.js, memulai dengan penjelasan mengapa framework seperti Next.js istimewa dalam mendefinisikan ulang performa web. Dia menjelaskan bahwa Next.js telah memberikan bundling cerdas dengan Webpack dan Turbo Pack, optimasi image dan font, server-side rendering, static rendering, ISR, dan RSC untuk membawa data fetching ke dalam komponen. Pembicara menekankan bahwa meskipun Next.js telah melakukan optimasi luar biasa, masih ada satu layer fundamental yang belum bisa dioptimalkan yaitu runtime itu sendiri yang berada di luar scope Next.js. Ini menjadi motivasi untuk membahas bagaimana Bun sebagai runtime baru dapat melengkapi performa framework Next.js yang sudah optimal.

Evolusi dari Node.js dan Keterbatasannya di Era Modern

Pembicara menjelaskan arsitektur Node.js yang dibangun di atas V8 engine dari Google dan libuv, sebuah C library yang menjadi bridge antara kode JavaScript dan operating system. Ketika kode JavaScript memanggil operasi seperti fs.readFile, request harus melewati V8, C++ bindings, libuv, dan baru kemudian ke kernel, menciptakan banyak layer abstraction. Di tahun 2009 ketika Node.js diperkenalkan, model single-threaded ini sangat efisien untuk server long-running dengan ribuan koneksi, tetapi di 2025, hardware sudah berubah drastis dengan ratusan CPU cores, terabyte memory, dan storage 50x lebih cepat. Namun masih menggunakan model 2009 yang mendorong semuanya melalui single event loop, yang masih baik untuk long-running servers tetapi suboptimal untuk serverless functions dan dev servers yang membutuhkan startup cepat dan eksekusi burst singkat. Setiap millisecond dari startup time menjadi kritis dalam environment modern, membuat perlu rethinking runtime itu sendiri untuk mencapai performa maksimal.

Pengenalan Bun sebagai Runtime JavaScript Modern

Bun diperkenalkan sebagai brand new runtime yang dibangun dari nol untuk hardware 2025, bukan hanya layer di atas Node.js. Dibangun menggunakan Zig, sebuah modern systems language yang berjalan lebih dekat ke metal, Bun menggunakan JavaScript Core engine dari Apple yang sangat cepat dan spin up dengan cepat karena bisa defer beberapa initialization optimizations yang tidak dilakukan V8. Keunggulan utama Bun adalah APIs dan async I/O diimplementasikan sebagai direct system calls ke operating system, menghilangkan layer abstraction libuv yang digunakan Node.js. Ketika membaca file dengan Bun, path hanya JavaScript ke JSC engine ke Zig dengan direct system call ke kernel, jauh lebih sedikit layer dibanding Node.js. Hasilnya, semuanya terasa jauh lebih cepat dari startup, file access, HTTP servers, dan berbagai operasi lainnya karena lebih dekat ke metal dan menghilangkan overhead yang tidak perlu.

Built-in APIs dan Fitur Komplementer Bun

Bun tidak hanya tentang performa runtime tetapi juga menawarkan 100% Node compatibility dengan tambahan built-in APIs seperti S3, SQL, Redis, hashing, dan shell tanpa perlu menginstall dependencies tambahan. Pendekatan batteries-included ini familiar bagi developers dari bahasa seperti Go atau Python, tetapi baru bagi JavaScript developers yang terbiasa install dependency untuk hampir semuanya. Built-in SQL client memungkinkan connect langsung ke Postgres, MySQL, dan SQLite menggunakan single API, dengan performa hingga 11x lebih cepat daripada MySQL2 di Node. Bun's S3 client bekerja out of the box dengan semua S3-compatible storage seperti Amazon S3, Supabase Storage, dan Cloudflare R2, dan mencapai performa hingga 6x lebih cepat dari AWS S3 SDK di Node. Selain runtime, Bun menyediakan package manager yang 17x lebih cepat dari YARN, 7x lebih cepat dari NPM, dan 4x lebih cepat dari PNPM, serta bundler/transpiler built-in yang mendukung TypeScript dan JSX tanpa setup, dan test runner yang 14x lebih cepat dari Vitest dan 23x lebih cepat dari Jest untuk 1000+ React tests.

Integrasi Bun dengan Next.js dan Penggunaan Praktis

Mengintegrasikan Bun runtime dengan Next.js sangat sederhana, hanya perlu menambahkan flag --bun pada start atau dev command seperti bun run --bun next dev. Flag --bun diperlukan karena Bun peduli dengan Node compatibility, dan normalnya akan detect node shebang dari Next CLI dan default back ke Node, tetapi flag ini memaksa menggunakan Bun runtime. Dengan command ini, bundler masih Next.js (Turbo Pack) tetapi runtime yang mengeksekusi JavaScript, membaca file, dan serving responses adalah Bun, dan tidak perlu mengubah apapun tentang kode, packages, atau middleware karena Bun dirancang 100% Node compatible. Developer dapat mengakses semua built-in APIs Bun seperti S3 client langsung dalam server functions, React server components, tanpa install dependencies tambahan. Contoh praktis menunjukkan penggunaan S3, shell Bun, dan SQL langsung dalam React server component untuk query database, generate presigned S3 URL, dan count words, semua ditangani natively oleh Bun dalam Zig, close ke metal, tanpa extra API layer atau third-party tools.

Developer Experience dan Ekosistem Tools Bun

Developer experience Bun luar biasa karena bisa menjalankan apapun JavaScript, TypeScript, TSX, JSX tanpa perlu konfigurasi apapun, menghilangkan kebutuhan untuk TSNode, Babel, SWC, dan tools kompleks lainnya. Bahkan tanpa menggunakan Next.js atau Bun runtime, developer bisa memanfaatkan bun run untuk quick build scripts atau development tasks dengan instant startup improvements. Bun juga menyediakan bun x yang merupakan equivalent Bun dari NPX, dan tidak perlu mengubah apapun atau gunakan Bun runtime untuk ini, tetapi memberikan instant startup improvements, contohnya bun x create-next-app adalah 5x lebih cepat dari NPX create-next-app. Bun install juga menjadi opsi untuk mempercepat instalasi dependencies tanpa perlu mengubah runtime, membuat install process jauh lebih cepat bahkan untuk basic Next.js projects. Semua tools ini bekerja tanpa konfigurasi, memberikan developer experience yang seamless dan meningkatkan produktivitas secara signifikan dibanding workflow tradisional dengan Node ecosystem.

Deployment Strategi dan Roadmap untuk Vercel Integration

Aplikasi yang berjalan di atas Bun bisa di-deploy di beberapa platform seperti Render, Railway, atau containerize dengan Docker, tetapi untuk Next.js developers, deployment ke Vercel adalah ideal. Tim Bun merekomendasikan tweet ke Guillermo untuk native Bun support di Vercel, dan mendapat respons yang cukup menjanjikan, kemudian beberapa minggu kemudian Bun support telah tercapai minimal secara internal dengan rencanaan native Bun support datang ke Vercel sangat segera. Ini berarti developer akan bisa menjalankan Bun apps di Vercel semudah project Next.js lainnya, dan contoh dunia nyata menunjukkan HONO API dengan Bun sudah melihat 30% CPU drop hanya dengan menjalankan Bun di Vercel. Adopsi Bun bisa dilakukan secara incremental: pertama switch ke bun install, kemudian test runtime locally dengan bun run --bun, dan terakhir incrementally pindah ke native APIs Bun di mana masuk akal, sambil tetap bisa mix dan match NPM dependencies. Setiap step ini reversible, jadi jika ada issues, developer bisa switch back ke Node tanpa masalah, membuat Bun adoption menjadi low-risk dan sustainable.

Community Posts

View all posts