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.