00:00:00- Jadi versi publik final dari V+ kemungkinan besar,
00:00:03akan terasa seperti sesuatu yang menyenangkan.
00:00:06- Ini adalah Evan Yu.
00:00:07- Evan Yu.
00:00:09- Evan Yu.
00:00:10- Evan Yu!
00:00:10- Saya membuat Vue, saya membuat Vite.
00:00:14Sekarang saya menjalankan perusahaan bernama Voice Zero.
00:00:16- Apa perbedaan Vite dengan Vite+?
00:00:19- Pengalaman pengembangan Anda akan sama persis
00:00:21seperti Vite saat ini.
00:00:22Tapi jika Anda ingin melangkah lebih jauh,
00:00:24ia akan selalu ada untuk mendukung Anda.
00:00:26- Bagaimana tim dan Anda sendiri menggunakan AI?
00:00:28- Kami mulai melakukan eksperimen gila
00:00:30seperti mem-porting compiler Angular ke Rust.
00:00:32- Apa pendapat Anda tentang React Server Components?
00:00:34- Saya sudah skeptis sejak hari pertama.
00:00:36- Biasanya saat memperkenalkan podcast,
00:00:39saya meminta tamu untuk memperkenalkan diri.
00:00:40Tapi menurut saya jika ada yang menonton ini
00:00:42dan tidak tahu siapa Anda, saya akan sangat terkejut.
00:00:44Saya rasa Anda sudah sangat terkenal.
00:00:46Tapi semua orang harus tahu,
00:00:48atau kebanyakan orang harus tahu siapa Anda.
00:00:49- Mereka setidaknya pasti pernah mendengar tentang Vite atau Vue.
00:00:53- Ya, jadi saya membuat Vue, saya membuat Vite.
00:00:57Sekarang saya menjalankan perusahaan bernama Voice Zero
00:00:59di mana kami mengerjakan lebih banyak proyek sumber terbuka.
00:01:03Ada Rodeo, Vtest, OXC.
00:01:07Dan ya, Vue dan Vite mungkin lebih populer,
00:01:11tapi beberapa hal yang kami kerjakan di Voice Zero
00:01:14juga cukup keren.
00:01:15Karena Rodeo adalah bundler berbasis Rust.
00:01:18OXC adalah toolchain Rust lengkap yang mencakup
00:01:22mulai dari parser hingga resolver, transformer,
00:01:25minifier, dan sebagainya.
00:01:28Dan di atas OXC, kami punya OX Lint dan OX Format,
00:01:32yang merupakan linter yang kompatibel dengan ESLint
00:01:35dan formatter yang kompatibel dengan Prettier.
00:01:37Dan masih banyak lagi yang sedang kami kerjakan, tapi ya.
00:01:41Jadi untuk saat ini kami ingin lebih banyak membahas sumber terbukanya.
00:01:45- Tentu.
00:01:45Karena Anda mengerjakan begitu banyak hal,
00:01:47bagaimana Anda membagi waktu?
00:01:50- Sebenarnya, saya tidak menulis kode sendiri
00:01:52untuk semua proyek ini.
00:01:53Malah, saya jauh lebih jarang menulis kode sekarang
00:01:56sejak saya mendirikan perusahaan.
00:01:58Di perusahaan, ada banyak insinyur
00:02:01yang jauh lebih jago Rust dibanding saya
00:02:03dan mereka sekarang sangat antusias dengan AI.
00:02:05Jadi pengerjaannya setengah oleh mereka dan setengah oleh Cloud Code atau Codex
00:02:10yang menjalankan banyak kode Rust.
00:02:12Dan tugas saya adalah memutuskan apa yang harus dilakukan
00:02:17pada banyak keputusan DX (pengalaman pengembang),
00:02:22memutuskan fokus kami selanjutnya.
00:02:25Dan tentu saja ada juga produk,
00:02:28tentang bagaimana mengubah ini menjadi produk
00:02:31yang bisa menghasilkan uang,
00:02:32yang masih terus kami upayakan.
00:02:34Ya, itu semua hal yang perlu dilakukan
00:02:39untuk menjalankan perusahaan saat ini.
00:02:41- Dari mana asal ide-ide
00:02:43untuk proyek sumber terbuka baru ini?
00:02:45Apakah sebagian besar dari kebutuhan internal
00:02:48yang Anda sadari bisa membantu
00:02:49menyelesaikan masalah orang lain juga?
00:02:53- Sebenarnya semua bermula dari Vite, kan?
00:02:56Saat membuat Vite, saya cuma iseng mengopreknya.
00:03:01Awalnya cuma sebagai prototipe
00:03:03dan kemudian saya pikir, kita butuh bundler.
00:03:07Kami mulai dengan dev server
00:03:10native ESM yang sama sekali tidak dibundel, kan?
00:03:13Ide itu berjalan lancar untuk kode sederhana,
00:03:16tapi kemudian kami mulai memasukkan dependensi besar
00:03:18dan menyadari, oke, ini tidak akan berskala baik
00:03:21jika memuat semua dependensi tanpa dibundel.
00:03:24Contohnya jika Anda memuat Lodash-es,
00:03:26yang isinya sekitar 700 file.
00:03:28Jadi kami pikir, oke,
00:03:30kita butuh sesuatu untuk membundel dependensi, kan?
00:03:34Dulu ada Rollup, esbuild, dan Webpack.
00:03:41Webpack tidak menghasilkan ESM, jadi tidak bisa dipakai.
00:03:47Saya mencoba Rollup dan Rollup itu cukup lambat.
00:03:50Sangat lambat dibandingkan esbuild, kan?
00:03:53Lebih cepat dari Webpack, tapi lambat dibanding esbuild.
00:03:56Jadi kami menggunakan esbuild untuk pre-bundle dependensi,
00:03:59yang kecepatannya luar biasa.
00:04:00Lalu kami menyajikan semua kode sumber sebagai ESM tanpa bundel
00:04:02dan itu bekerja dengan sangat baik.
00:04:04Lalu saat masuk ke tahap produksi,
00:04:06awalnya kami berpikir, oke,
00:04:08mari gunakan esbuild saja untuk membundel semuanya
00:04:10untuk produksi.
00:04:11Tapi kemudian kami menyadari esbuild punya kontrol sangat terbatas
00:04:14atas cara membagi chunk.
00:04:17Padahal itu kebutuhan umum jika membangun aplikasi besar
00:04:19karena Anda ingin punya kontrol,
00:04:21misalnya saya ingin menaruh dependensi library ini
00:04:24ke dalam vendor chunk, agar caching-nya lebih baik.
00:04:26Saya tidak ingin chunk ini berubah sama sekali, kan?
00:04:28Jadi punya hash yang konsisten.
00:04:32Sehingga meskipun saya mengubah kode sumber saya,
00:04:33hash chunk tersebut harus tetap sama.
00:04:35Jadi pengguna akan selalu mendapatkan chunk itu dari cache
00:04:38saat mengunjungi situs web.
00:04:39Ada banyak jenis optimasi seperti ini
00:04:41yang sama sekali tidak dimungkinkan oleh esbuild.
00:04:44Ia hanya punya satu perilaku pembagian chunk bawaan
00:04:47dan sudah, cuma itu saja.
00:04:49Sistem plugin-nya juga kurang fleksibel.
00:04:53Jika ada satu plugin yang memutuskan
00:04:56untuk memproses file ini, ya sudah.
00:04:59Plugin lain tidak bisa menyentuhnya lagi.
00:05:02Sementara kami sudah sering menggunakan Rollup,
00:05:05kami familiar dengan sistem plugin Rollup.
00:05:08Jadi akhirnya kami memutuskan, oke,
00:05:10kita gunakan Rollup untuk pembundelan produksi,
00:05:13tapi esbuild untuk pre-bundling saat pengembangan.
00:05:15Itu seperti membiarkan tiap alat melakukan
00:05:20yang terbaik dalam kombinasi ini.
00:05:23Bahkan hari ini Vite 7 masih berbasis
00:05:26pada kombinasi ini.
00:05:27Dan itu bekerja cukup baik bagi banyak orang, kan?
00:05:31Tapi tentu saja ada masalah karena esbuild
00:05:35ditulis dalam bahasa Go, Rollup dalam JavaScript,
00:05:40yang artinya build produksi
00:05:41sebenarnya masih cukup lambat dibandingkan
00:05:43bundler berbasis Rust penuh seperti RSPack.
00:05:47Untuk dev server, karena esbuild
00:05:52dan Rollup punya sistem plugin berbeda, kan?
00:05:55Kami tidak bisa menerapkan set plugin yang sama
00:05:57ke dependensi selama pengembangan,
00:05:59tapi plugin itu diterapkan ke dependensi
00:06:01selama build produksi.
00:06:03Lalu ada masalah interoperabilitas yang halus.
00:06:07Saat Anda punya grafik campuran ESM dan CJS,
00:06:10esbuild dan Rollup menanganinya sedikit berbeda.
00:06:13Ada perbedaan perilaku tree shaking.
00:06:15Meskipun keduanya bekerja dengan baik, ya?
00:06:18Kami juga menambal semua inkonsistensi perilaku
00:06:22dan semacamnya.
00:06:22Kami berhasil membuatnya bekerja, tapi di dalam hati kami tahu,
00:06:25ini cuma dua hal berbeda yang entah bagaimana
00:06:29kami gabungkan secara paksa, kan?
00:06:31Jadi agar A, membuat build produksi lebih cepat,
00:06:35dan B, membuat build pengembangan dan produksi lebih konsisten.
00:06:40Hal terbaik yang dilakukan adalah punya satu bundler
00:06:42yang menangani keduanya, kan?
00:06:44Tapi masalahnya esbuild itu cepat,
00:06:47tapi tidak sangat mudah diperluas.
00:06:50Basis kodenya semuanya bahasa Go.
00:06:54Evan Wallace adalah pembuat esbuild.
00:06:57Dia jelas seorang ilmuwan gila, dia jenius
00:06:59dan dia membuat esbuild sangat cepat,
00:07:02tapi itu tidak terlalu cocok bagi orang lain
00:07:05untuk memperluas atau mem-fork-nya
00:07:07atau mengelola lapisan di atasnya.
00:07:10Tidak mudah melakukan itu, kan?
00:07:12Dan juga sangat sulit meyakinkan Evan Wallace
00:07:15untuk melakukan hal yang tidak ingin dia lakukan
00:07:17karena dia tidak butuh uang dan dia tidak peduli.
00:07:21Jadi kami pikir, oke, lalu bagaimana dengan Rollup?
00:07:27Bisakah kita membuat Rollup lebih cepat, kan?
00:07:28Ada beberapa eksperimen,
00:07:30tapi secara fundamental Rollup ditulis dalam JavaScript
00:07:33dan JavaScript artinya single-threaded.
00:07:36Kami mencoba hal-hal seperti worker pool, plugin di worker.
00:07:41Pengelola Rollup mencoba memasukkan parser Rust,
00:07:47parser SWC ke dalam Rollup.
00:07:50Itu tidak meningkatkan performa secara nyata
00:07:54karena saat Anda punya sistem campuran Rust dan JS,
00:07:57selalu ada biaya transfer data.
00:07:59Anda mengirimkan string besar bolak-balik.
00:08:02Jika Anda sampai harus menduplikasi memori, itu jadi lebih lambat.
00:08:05Ternyata keuntungan performa murni dari Rust,
00:08:09saat Anda hanya punya parser Rust,
00:08:12tapi sisanya masih dalam JavaScript,
00:08:13keuntungan performanya terhapus oleh biaya transfer data.
00:08:16Jadi hasilnya hampir sama saja performanya, kan?
00:08:19Jadi kami pikir, secara drastis membuat Rollup lebih cepat
00:08:23itu secara teknis tidak mungkin.
00:08:26Jadi satu-satunya pilihan adalah menulis ulang hal ini,
00:08:30menulis bundler yang benar-benar dirancang
00:08:33khusus untuk Vite, dan harus sangat cepat, kan?
00:08:37Itu memulai semua pencarian seperti berpikir, oke,
00:08:40apa yang harus kita lakukan?
00:08:42Kami memutuskan untuk, pada dasarnya,
00:08:44ide awalnya adalah mem-fork Rollup dalam Rust.
00:08:48Bukan fork, mem-porting, ya?
00:08:49Kami ingin mem-porting Rollup ke Rust.
00:08:51Itulah kenapa proyeknya dinamai Rolldown.
00:08:53Jadi dari Rollup menjadi Rolldown.
00:08:54Awalnya dimulai sebagai porting langsung,
00:08:58tapi kami menyadari kode yang ditulis dalam JavaScript
00:09:02tidak sangat mudah di-porting langsung ke Rust
00:09:06karena JavaScript sangat dinamis.
00:09:08Itu bahasa yang dinamis, kan?
00:09:11Bahkan jika Anda menggunakan TypeScript,
00:09:13Anda masih bisa mengubah hal-hal sesuka hati.
00:09:16Sedangkan Rust sangat ketat soal memori.
00:09:19Ketat soal siklus hidup, kepemilikan, dan sebagainya.
00:09:23Jadi Anda harus menyusun struktur secara sangat berbeda
00:09:25dibandingkan JavaScript.
00:09:27Jadi tidak akan pernah mudah
00:09:29untuk sekadar mem-porting kode JavaScript yang ada
00:09:31ke bahasa seperti Rust.
00:09:33Ini praktis merupakan penulisan ulang.
00:09:35Dan akhirnya kami juga,
00:09:37kami ingin mendapatkan yang terbaik dari keduanya, kan?
00:09:42Rollup sendiri punya inti yang cukup ramping.
00:09:45Jadi jika Anda ingin mengubah Rollup
00:09:47menjadi preset yang siap untuk produksi,
00:09:49sebenarnya cukup rumit
00:09:51karena Anda butuh sesuatu seperti plugin node resolver,
00:09:54karena penyelesaian modul node bukanlah fitur bawaan.
00:09:56Itu perlu ditambahkan sebagai plugin Anda.
00:09:58Anda perlu menambah plugin CommonJS untuk mendukung modul CommonJS
00:10:03karena inti Rollup hanya mendukung ESM.
00:10:06Dan kemudian Anda harus menambah banyak plugin
00:10:10seperti define, inject, replace.
00:10:14Banyak fitur ini sudah bawaan di esbuild,
00:10:17tapi butuh plugin di Rollup.
00:10:20Dan parahnya kebanyakan plugin di dunia JavaScript ini,
00:10:25kami menerapkannya sebagai proses parsing AST, transformasi, dan pembuatan kode tambahan.
00:10:30Jadi setiap plugin sebenarnya melakukan proses lengkap,
00:10:33seperti mengambil kode dari plugin sebelumnya,
00:10:36mem-parsing-nya lagi, mentransformasinya,
00:10:38membuat kode baru, membuat source map baru.
00:10:41Lalu Anda harus menggabungkan semua source map itu.
00:10:43Itulah kenapa sistem build JavaScript jadi makin lama makin lambat
00:10:46karena setiap plugin terus mengulang proses ini.
00:10:49Jadi kami pikir, oke, kita butuh ini sebagai fitur bawaan juga.
00:10:53Jadi akhirnya kami punya cakupan fitur esbuild,
00:10:56tapi dengan bentuk API Rollup, itulah Rolldown, kan?
00:11:01Tapi untuk membangun Rolldown, kami pikir,
00:11:03kita butuh parser, kita butuh semua transformasinya, kan?
00:11:07Kita butuh minifier, kita butuh resolver.
00:11:10Lalu bagaimana kita mendapatkannya?
00:11:12Di situlah OXC berperan.
00:11:14OXC adalah kumpulan toolchain bahasa tingkat rendah
00:11:17yang memberikan Anda semua itu.
00:11:20Pembuat OXC dulu bekerja di ByteDance
00:11:25dan saya sudah lama mengawasi proyek itu.
00:11:28Borshin, dia pembuat OXC
00:11:30dan dia sekarang adalah VP of Engineering kami di Voice Zero.
00:11:33Dia tidak langsung bergabung saat saya mendirikan perusahaan.
00:11:36Saya mencoba mengajaknya bergabung, tapi dia sempat ragu,
00:11:38tapi kami tetap mulai membangun Rolldown di atas OXC.
00:11:39Kami pikir, wah, ini barang bagus.
00:11:44Saya yakin ini solusinya,
00:11:45karena saya sudah melihat semua pilihan yang ada, kan?
00:11:47Saya ingin sesuatu yang composable.
00:11:51Saya ingin sesuatu yang tiap bagian toolchain-nya
00:11:54bisa digunakan secara terpisah sebagai crate.
00:11:57Saya juga ingin itu sangat cepat, kan?
00:12:00Lalu kami membandingkan OXC dengan SWC.
00:12:03Parser OXC ini tiga kali lebih cepat
00:12:06dibanding parser SWC padahal keduanya ditulis dalam Rust,
00:12:09karena ada banyak keputusan desain
00:12:12dan detail teknis tingkat rendah
00:12:15yang menyebabkan perbedaan performa ini.
00:12:18Hal utamanya adalah Borshin sangat terobsesi
00:12:20soal performa parser dan performa linking
00:12:24sebelum dia bergabung ke perusahaan.
00:12:27Contohnya,
00:12:30OXC menggunakan sesuatu yang disebut arena allocator,
00:12:32yang menempatkan semua alokasi memori untuk AST
00:12:34dalam satu blok memori yang berurutan.
00:12:39Dia langsung mengalokasikan blok memori besar
00:12:41dan menaruh AST di dalamnya secara langsung.
00:12:43Jadi waktu untuk menghapus memorinya lebih cepat.
00:12:45Ini juga memungkinkan beberapa hal menarik yang kami lakukan
00:12:50yang membuat plugin JS di OXLint jadi cepat,
00:12:53karena memori yang konsisten memungkinkan kami
00:12:57untuk mengirimkan seluruh blok memori ke JavaScript
00:12:59tanpa menduplikasi, lalu men-deserialisasi di sisi JS.
00:13:01Jadi ada banyak manfaatnya,
00:13:05tapi waktu itu saya melihat proyeknya,
00:13:06saya sangat terkesan,
00:13:10dan kami memutuskan membangun Rolldown di atasnya
00:13:10dan akhirnya berhasil meyakinkan Borshin untuk bergabung.
00:13:13Sekarang cakupan perusahaan pada dasarnya menjadi
00:13:16kami punya tumpukan (stack) Rust vertikal
00:13:21yang dimulai dari sebuah parser.
00:13:24Ini mencakup segalanya mulai dari pembundelan hingga Vite,
00:13:26lalu kami punya Linter, Formatter, Test Runner, kan?
00:13:29Jadi kami punya satu toolchain utuh.
00:13:33Dan yang kami lakukan selanjutnya,
00:13:34sebenarnya sudah kami kerjakan sejak lama,
00:13:37adalah menyatukan semua ini ke dalam satu paket yang koheren
00:13:40sehingga Anda tidak perlu menginstal lima hal terpisah
00:13:43hanya untuk menjalankan aplikasi dasar, kan?
00:13:47Anda juga tidak perlu punya
00:13:50enam atau tujuh file konfigurasi yang berbeda.
00:13:51Kami masukkan semuanya dalam satu file konfigurasi,
00:13:55dan mereka dijamin akan bekerja sama dengan baik
00:13:57karena semuanya berbasis pada parser yang sama,
00:13:59pipeline transformasi yang sama, dan resolver yang sama.
00:14:02Jadi tidak akan ada kejutan.
00:14:05Misalnya, jika Anda menggunakan Webpack dan Jest,
00:14:07Anda harus mengonfigurasi logika resolusi mereka secara terpisah
00:14:10karena mereka tidak menggunakan alat yang sama.
00:14:14Visi kami sebenarnya adalah,
00:14:16mari bangun stack vertikal
00:14:19yang bekerja secara konsisten di mana-mana.
00:14:22Membuat alur pengembangan jadi sesederhana
00:14:25dan secepat mungkin, kan?
00:14:29Performa adalah hal yang sangat penting.
00:14:30Saya menganggapnya sebagai sesuatu yang mutlak,
00:14:32tapi Anda mungkin melihat cuitan tentang bagaimana Rolldown
00:14:3420 kali lebih cepat dibanding Rollup.
00:14:39OX Lint sekitar 50 hingga 100 kali lebih cepat dibanding ESLint.
00:14:43OX Format sekitar 30 sampai 40 kali lebih cepat dibanding Prettier.
00:14:47Jadi tujuan kami adalah membuatnya kompatibel
00:14:51sehingga Anda bisa bermigrasi tanpa melakukan refaktor besar,
00:14:57tapi Anda mendapatkan lonjakan performa yang besar ini
00:15:00dan sekarang siklus pengujian Anda, pemeriksaan linter,
00:15:04dan semuanya akan jauh lebih cepat dan lancar.
00:15:08Dan ya, itu akan memungkinkan orang-orang
00:15:12membangun lebih banyak aplikasi dengan lebih cepat.
00:15:15- Saya suka bagaimana perkembangannya begitu cepat
00:15:17dari sekadar butuh alat build untuk Vue menjadi,
00:15:20oh, saya ingin meningkatkan bagian itu juga.
00:15:22Lalu, oh, saya ingin meningkatkan bagian ini sekarang.
00:15:24Dan ya, seperti yang Anda katakan, Anda benar-benar menguasai
00:15:25seluruh stack vertikal itu.
00:15:27Sangat mengesankan dan memang sangat cepat.
00:15:29Saya tadi bercerita sebelum kita mulai,
00:15:32di salah satu pekerjaan lama saya,
00:15:33kami mengerjakan proyek warisan (legacy)
00:15:35dan menggunakan Webpack, butuh waktu 50 menit untuk mem-build.
00:15:37Saya tidak tahu apa yang terjadi,
00:15:40tapi hal pertama yang saya katakan ke mereka adalah,
00:15:42kita harus segera pindah ke Vite.
00:15:43Karena setiap mengubah CSS saja,
00:15:46Anda harus menunggu sekitar dua menit
00:15:47untuk build ulang dan sebagainya.
00:15:49Saya pikir, ini tidak bagus.
00:15:49Kita butuh fitur Hot Module Replacement.
00:15:52Saat saya menyimpan file, perubahannya harus langsung terlihat.
00:15:54Jadi, Vite benar-benar membantu dalam hal itu.
00:15:57Dan kemajuan serta tingkat adopsi
00:15:59Vite saat ini sangatlah luar biasa.
00:16:02Saya lihat sudah mencapai 200 juta unduhan NPM
00:16:05per bulan atau angka gila semacam itu.
00:16:07Itu-
00:16:09- Ya, kami baru saja menembus 50 juta unduhan per minggu belum lama ini.
00:16:10- Ya, itu luar biasa sekali.
00:16:13- Saya sempat terpikir soal 50 juta itu.
00:16:15Mungkin ada sedikit inflasi
00:16:19dari aplikasi-aplikasi buatan AI (vibe coded).
00:16:21Yang isinya cuma aplikasi kerangka yang sekali pakai.
00:16:23Tetap saja, itu menunjukkan banyak orang
00:16:26atau mungkin banyak agen AI yang menggunakannya.
00:16:29- Tim teknis kami
00:16:33di Betaslack adalah penggemar berat Vite.
00:16:34Mereka menggunakan Rails di backend dengan Vue di frontend.
00:16:36Dan mereka punya beberapa pertanyaan yang akan saya tanyakan
00:16:40sepanjang podcast ini tergantung arah pembicaraannya.
00:16:42Tapi Anda menyebutkan soal pembundelan,
00:16:46dan salah satu pertanyaan mereka adalah,
00:16:48karena mereka memakai import maps di Rails,
00:16:49bagaimana Anda melihat masa depan pembundelan?
00:16:52Karena tidak banyak yang perlu dibundel
00:16:54jika menggunakan import maps.
00:16:56Jadi, akan mengarah ke mana menurut Anda?
00:16:57- Sebenarnya saya punya satu halaman khusus
00:17:00di dokumentasi Rolldown,
00:17:02yang judulnya adalah,
00:17:04“Kenapa Kita Masih Butuh Bundler?”
00:17:07- Apakah Anda sering ditanya soal ini?
00:17:10- Ya, maksud saya DHH sangat vokal
00:17:13tentang konsep “no bundle, no build”.
00:17:16Jadi kami harus memperhatikan hal itu.
00:17:18Import maps memang bekerja sampai batas tertentu,
00:17:20tapi konsep tanpa bundel (unbundled) secara umum
00:17:24hanya bekerja hingga skala tertentu saja.
00:17:29Jika aplikasi Anda di bawah seribu modul,
00:17:35seluruh grafik modul Anda mungkin dimuat
00:17:39dalam beberapa ratus milidetik
00:17:41dan itu sangat bisa diterima.
00:17:43Dan jika Anda tahu Anda bekerja dalam batasan itu,
00:17:45itu sebenarnya sangat bagus.
00:17:48Secara bawaan sifatnya malas (lazy),
00:17:50artinya jika Anda punya aplikasi besar
00:17:53dan setiap halamannya terpisah,
00:17:56Anda punya grafik sub-modul ini,
00:17:58itu bekerja cukup baik.
00:18:00Itulah kenapa Vite bekerja sangat baik saat pengembangan.
00:18:01Tapi itu bukan solusi segalanya
00:18:05karena apa yang kami sadari dari Vite sendiri
00:18:07dan alasan kami sedang mengerjakan sesuatu
00:18:09bernama “full bundle mode” di Rolldown
00:18:12adalah karena mode unbundled punya keterbatasan,
00:18:15yaitu hambatan utamanya adalah jumlah modul.
00:18:18Ada banyak sekali aplikasi di mana
00:18:21mereka memuat ribuan dan ribuan modul
00:18:25selama pengembangan, kan?
00:18:29Anda bisa saja memuat 3000 modul
00:18:32dan itu akan membebani browser Anda.
00:18:33Hambatannya ada di tingkat jaringan
00:18:36karena dengan native ESM,
00:18:38Anda mengirim satu permintaan HTTP untuk setiap modul.
00:18:40Jika Anda punya grafik impor yang dalam,
00:18:44browser harus mengambil modul pertama dulu,
00:18:46baru menyadari, oke, saya butuh modul-modul tambahan ini
00:18:49lalu mengambilnya.
00:18:52Lalu mengambil yang berikutnya lagi,
00:18:53Anda harus menelusuri seluruh grafik secara bertahap
00:18:54sebelum bisa mengevaluasi modul impor pertama.
00:18:57Jadi jika koneksi internet Anda buruk,
00:19:00ada kemungkinan terjadi banyak putaran permintaan jaringan
00:19:04sebelum Anda bisa menampilkan apa pun.
00:19:06Dan jika Anda punya ribuan modul,
00:19:09situasinya makin parah karena masalah jaringan itu.
00:19:13Bahkan saat pengembangan lokal di dev server Vite,
00:19:17jika Anda punya lebih dari 3000 modul,
00:19:20bisa butuh satu atau dua detik untuk memuatnya secara lokal.
00:19:23Jadi bayangkan apa pengaruhnya di produksi
00:19:27melalui jaringan publik, kan?
00:19:29Anda tentu tidak mau itu terjadi, karena jika Anda membundelnya,
00:19:31mungkin cuma butuh 100 milidetik, kan?
00:19:35Jadi ini seperti optimasi gratis yang tersedia
00:19:38yang harus selalu Anda ambil
00:19:40saat melewati ambang batas tertentu.
00:19:41Saya rasa argumen utama untuk menghindari pembundelan
00:19:45dan alat build sama sekali adalah karena orang-orang sudah lelah
00:19:47mengonfigurasi alat tersebut, kan?
00:19:52Mereka mungkin sering menemui bug,
00:19:55menemui masalah konfigurasi yang sulit dipecahkan.
00:19:56Dan karena Webpack membuatnya sangat rumit,
00:20:01semua orang jadi merasa,
00:20:04saat berpikir harus mengonfigurasi bundler,
00:20:06itu bukan pekerjaan saya, saya tidak mau melakukannya, kan?
00:20:08Jadi saya rasa orang-orang punya kebencian ini
00:20:11saat mendengar ada langkah build (tahap kompilasi),
00:20:14mereka merasa itu buruk dan ingin menghindarinya, kan?
00:20:16Jadi, yang ingin kami lakukan dengan alat-alat ini
00:20:19adalah kami ingin membuat konsep ini sangat jelas.
00:20:22Memang tidak akan pernah sederhana
00:20:24untuk aplikasi besar yang kompleks, kan?
00:20:28Tapi kami ingin membuatnya cukup simpel untuk aplikasi baru
00:20:32sehingga Anda tidak perlu terlalu memikirkannya
00:20:34jika aplikasi Anda tidak sangat rumit, kan?
00:20:37Anda harusnya bisa langsung bilang, oke, jalankan aplikasi ini,
00:20:41aplikasi ini pakai Vite dan saya tahu segalanya akan lancar.
00:20:45Bahkan saya tahu ada komunitas yang membuat
00:20:48integrasi Ruby Vite, Vite Rails, atau semacamnya
00:20:50yang membuat Vite bekerja sangat baik di Rails.
00:20:55Saya rasa pengaturan tanpa build punya manfaat sendiri, kan?
00:20:59Itu membuat Anda merasa nyaman karena Anda tahu,
00:21:05Anda bisa menghindari banyak dependensi
00:21:12dan ketidakpastian yang mungkin membuat sistem rusak.
00:21:14Ada juga beberapa orang yang merasa kehilangan kepercayaan
00:21:17pada sistem build, karena selalu saja ada yang salah.
00:21:20Build-nya akan rusak saat saya memperbarui dependensi,
00:21:23mereka memang bisa menghindari itu semua, dan itu menggiurkan.
00:21:26Tapi pada akhirnya,
00:21:29jika teknologinya cukup bagus dan stabil, kan?
00:21:33Anda akan selalu menginginkan UX terbaik bagi pengguna Anda
00:21:36dan menggunakan unbundled sepenuhnya berarti Anda terjebak dalam
00:21:37batasan ukuran aplikasi yang sangat sempit.
00:21:41Anda juga harus memikirkan optimasi juga,
00:21:45karena Anda harus berpikir seperti,
00:21:48jangan-jangan saya tidak sengaja mengimpor terlalu banyak
00:21:52di halaman tertentu yang dikunjungi, kan?
00:21:54Bagaimana cara melakukan caching modul dengan cerdas?
00:21:57Saya yakin bahkan dengan unbundled Rails,
00:22:01Anda masih butuh semacam langkah pra-proses
00:22:03untuk menandai modul agar bisa masuk cache dengan benar.
00:22:06Jadi tak terelakkan Anda tetap harus memperhatikan
00:22:08soal optimasi agar semuanya berjalan lancar.
00:22:11Menurut saya itu memang bisa digunakan untuk
00:22:15banyak sekali kasus penggunaan, tapi itu bukan
00:22:18solusi yang akan mencakup semua kasus penggunaan.
00:22:21Dan beberapa orang membangun aplikasi yang sangat besar, kan?
00:22:24Yang punya banyak sekali fitur.
00:22:29Anda tidak bisa memaksa mereka pakai unbundled
00:22:31dan membiarkan mereka terjebak dalam
00:22:35situasi performa yang tidak bisa dioptimalkan.
00:22:37- Bagi mereka yang belum terlalu familiar,
00:22:39apa perbedaan antara Vite dengan Vite plus?
00:22:42Dan apa yang didapat orang-orang dari itu?
00:22:45- Jadi Vite plus, kami sedang melakukan sedikit
00:22:49pivot kecil mengenai apa sebenarnya tujuan Vite plus saat ini.
00:22:54Ide utamanya adalah jika Anda baru saja mulai belajar
00:22:57pengembangan JavaScript dari nol,
00:23:02seperti Anda baru dalam dunia JS,
00:23:06dan punya komputer baru yang belum terinstal apa pun.
00:23:11Bagaimana caranya dari nol bisa punya aplikasi yang berjalan
00:23:14dengan Hot Module Replacement, semua praktik terbaik,
00:23:17Linter, format kode, dan pengujian sudah beres untuk Anda, kan?
00:23:21Saat ini, ada banyak sekali yang harus dipelajari.
00:23:25Hal pertama yang harus Anda pelajari adalah,
00:23:28apa itu Node.js?
00:23:33Bagaimana cara menginstalnya?
00:23:36Apa itu Node Version Manager?
00:23:38Package manager mana yang harus saya pakai?
00:23:39Build tool mana yang harus saya pakai?
00:23:40Linter mana yang harus saya pakai?
00:23:42Anda harus menjawab semua pertanyaan itu.
00:23:44Kami ingin menghilangkan semua pertanyaan itu.
00:23:45Kami memberi Anda titik awal yang sudah terkonfigurasi
00:23:47dan bahkan Anda tidak perlu menginstal Node.js sendiri, kan?
00:23:49Kami sedang bereksperimen dengan cara baru ini
00:23:50dalam menggunakan V plus, seperti lewat perintah curl,
00:23:52seperti HTTPS vplus.dev install pipe bash.
00:23:54Lalu ada perintah VP dev, VP new, dan Anda punya proyek baru,
00:23:57lalu jalankan VP dev dan Anda punya
00:23:59rangkaian lengkap yang sudah disiapkan untuk Anda.
00:24:03Sudah ada linter, formatter,
00:24:08test runner, bundler, semuanya bahkan bisa dipakai
00:24:15untuk membuat struktur monorepo.
00:24:17Bisa untuk pembundelan library juga.
00:24:21Kami berencana menambah fitur bawaan seperti lint-staged,
00:24:25dan mengelola catatan perubahan (changelog) Anda.
00:24:28Jika Anda mengerjakan monorepo library yang besar,
00:24:31lalu ada juga fitur bernama VP run
00:24:32yang merupakan runner, mirip seperti pnpm run,
00:24:39tapi sedikit lebih canggih,
00:24:41mirip seperti NX yang bisa menentukan
00:24:44urutan yang tepat untuk menjalankan tugas-tugas Anda
00:24:49dan menyimpannya dalam cache dengan cerdas.
00:24:52Tapi ini bersifat opsional.
00:24:57Jadi ini semacam rangkaian fitur utuh yang,
00:24:59jika Anda tidak butuh hal-hal tambahan ini,
00:25:03Anda masih bisa menganggapnya seperti Vite biasa, kan?
00:25:04Pengalaman pengembangan Anda akan sama persis
00:25:07seperti apa yang ditawarkan Vite hari ini.
00:25:11Tapi jika Anda ingin melangkah lebih jauh,
00:25:13naik ke level monorepo siap produksi tingkat perusahaan,
00:25:17ia sudah siap mendukung Anda sepenuhnya.
00:25:18Dan juga, karena ini dibangun di atas
00:25:20teknologi-teknologi teruji
00:25:24yang sudah digunakan banyak orang dalam situasi tersebut.
00:25:27Itulah yang kami harap bisa kami hadirkan, kan?
00:25:31Kami sedang mengalihkan banyak pengguna yang ada
00:25:33ke penawaran sumber terbuka kami,
00:25:35di mana orang bermigrasi dari Webpack ke Vite,
00:25:39bermigrasi dari ESLint ke OXLint.
00:25:44Harapan kami V+ bisa menjawab,
00:25:47pertanyaan seperti, apa yang harus saya lakukan
00:25:48jika saya baru belajar JavaScript?
00:25:52Apa cara tercepat dan termudah untuk memulainya?
00:25:54Saya ingin menjawab pertanyaan itu
00:25:57dan juga membuatnya bekerja sangat baik dengan AI.
00:26:00- Jadi apa tujuan utama perusahaan ini?
00:26:02Banyak orang merasa takut saat mendengar
00:26:05ada perusahaan di balik proyek sumber terbuka
00:26:07karena mungkin Anda mulai mengenakan biaya untuk fitur tertentu,
00:26:11tapi apakah tujuannya seperti biasanya,
00:26:14bahwa kita selalu bisa melakukan apa yang V+ lakukan sendiri.
00:26:15Hanya saja butuh banyak konfigurasi,
00:26:17dan V+ hanyalah sebuah kemudahan
00:26:20yang mengemas semuanya jadi satu, seperti kata Anda.
00:26:23Jadi Anda tidak akan pernah membatasi fitur dengan biaya?
00:26:25- Ya, kami sempat memberi bocoran tentang
00:26:26lisensi di balik V+, kan?
00:26:29Kami bilang, oke, jika perusahaan Anda
00:26:31sudah mencapai ambang batas tertentu, Anda harus membayar.
00:26:34Pemikiran itu terus berkembang
00:26:37karena kami sudah bicara dengan banyak perusahaan yang berminat
00:26:39dan mencoba mencari titik keseimbangan yang baik
00:26:41untuk memberikannya ke lebih banyak orang
00:26:44dan menciptakan nilai, sekaligus memungkinkan kami mendapatkan keuntungan
00:26:46agar tetap berkelanjutan, kan?
00:26:50Saya rasa kami akan menaikkan ambang batas itu jauh lebih tinggi.
00:26:53Jadi hanya kategori perusahaan yang sangat kecil jumlahnya
00:26:56yang harus membayar.
00:27:00Mayoritas pengguna harusnya bisa menikmatinya
00:27:02secara gratis dan juga karena kami punya,
00:27:07beberapa ide yang lebih bersifat layanan
00:27:11daripada sekadar membayar untuk fitur, kan?
00:27:14Layanan yang berpasangan dengan V+
00:27:17yang meningkatkan kualitas kode
00:27:20dan memantau kualitas kode Anda
00:27:25serta memberi ide atau tip,
00:27:27seperti membantu Anda meningkatkan hal-hal tertentu.
00:27:31Karena ada banyak pengetahuan teknis
00:27:35yang sekarang bisa kami buat berskala melalui agen AI.
00:27:37Itulah arah yang sedang kami eksplorasi.
00:27:39- Oke, saya juga penasaran,
00:27:41mengingat V+ membuat semuanya jadi praktis,
00:27:44apakah menurut Anda AI bisa melakukan itu dengan solusi yang ada,
00:27:48atau apakah Anda punya pengalaman
00:27:51meminta AI untuk menyatukan format
00:27:53linter, build, dan semuanya,
00:27:56apakah ia akan mengandalkan teknologi lama
00:28:00karena data pelatihannya dan malah bikin berantakan?
00:28:02- Banyak aplikasi buatan AI
00:28:05yang masih menggunakan Vite 6, misalnya, kan?
00:28:07Satu masalah besar adalah saat kami merilis versi baru,
00:28:09saat kami merilis fitur baru, butuh waktu bagi model AI
00:28:13untuk mempelajari data tersebut, kan?
00:28:17Model AI akan selalu tertinggal dari berita
00:28:20dan teknologi terbaru, jadi itu bagian dari yang ingin kami lakukan,
00:28:26misalnya jika kami merilis versi baru V+,
00:28:29ia akan memberikan Anda,
00:28:31pertama-tama, ia akan menyertakan deskripsi agen dan kemampuannya sendiri.
00:28:34Jadi saat Anda memperbarui V+, ia akan otomatis
00:28:37menambal bagian yang relevan dalam deskripsi agen Anda
00:28:41dan menghubungkan ke kemampuan yang sedang diperbarui
00:28:44di dalam paket NPM Anda.
00:28:47Lalu ada juga,
00:28:50kami bisa memberi Anda instruksi (prompt) yang memberi tahu,
00:28:54jika ingin memperbarui dari versi ini ke versi ini,
00:28:58instruksi ini akan membantu agen Anda melakukannya dengan lebih lancar.
00:29:00Banyak hal seperti itu harus datang
00:29:05dari pembuat alatnya sendiri, kan?
00:29:08Karena begini, satu hal yang kami sadari
00:29:10adalah kami punya OXLint, OXFormat, dan Vtest,
00:29:13yang digunakan di proyek OpenClaw, kan?
00:29:17Dan OpenClaw itu basis kodenya gila.
00:29:19Ada sekitar 54.000 baris JavaScript
00:29:22dan bergerak dengan sangat cepat.
00:29:26Pembuatnya asal menggabungkan (merge) kode tanpa membacanya.
00:29:29Dan ada banyak hal
00:29:31yang sama sekali tidak masuk akal di sana.
00:29:34Kami melihat beberapa PR (Pull Request) yang memperbarui OXLint
00:29:36atau mulai mengadopsi OXLint.
00:29:40Isinya cuma opsi-opsi khayalan yang sebenarnya tidak ada.
00:29:43Kami kaget, tunggu, kami tidak punya opsi ini,
00:29:45kami harus mengaturnya.
00:29:46Lalu saat ia melakukan pemeriksaan tipe data (type checking),
00:29:51ia asal memperbaiki type checking-nya.
00:29:54Oke, saya matikan aturan (rule) ini saja.
00:29:57Supaya pemeriksaan tipenya lulus.
00:29:59Jadi AI akan mengambil jalan pintas
00:30:00jika Anda tidak memberinya batasan yang jelas, kan?
00:30:04Dan yang lebih penting, Peter,
00:30:06yang merupakan pembuat OpenClaw,
00:30:07dia bukan seorang pengembang TypeScript.
00:30:09Dia hanya memilih TypeScript untuk mengerjakannya.
00:30:12Dia bukan ahli perkakas kode (tooling expert).
00:30:15Dia tidak berpengalaman di bidang ini.
00:30:18AI membantunya melakukannya.
00:30:20Tapi sebagai pembuat alat yang digunakan oleh AI,
00:30:22kami menyadari di mana letak kekurangannya.
00:30:25Kami pikir, jika Anda terus melakukan ini
00:30:26tanpa kami beri tahu,
00:30:29kode Anda akan hancur dalam tiga bulan.
00:30:30Jadi, inilah nilai tambah
00:30:35yang menurut kami bisa diberikan di era AI ini,
00:30:38yaitu bagaimana memastikan Anda merilis fitur dengan cepat
00:30:41tanpa merusak sistem?
00:30:44Bagaimana agar tetap bisa merilis fitur cepat dengan AI?
00:30:46Karena kecepatan pengiriman kode
00:30:50meningkat drastis karena adanya agen AI, kan?
00:30:54Orang bisa merilis fitur jauh lebih cepat dari sebelumnya.
00:30:58Tapi apakah fitur-fitur ini ditinjau dengan benar?
00:30:59Apakah, saat Anda menggabungkan 20 PR sehari,
00:31:03basis kodenya masih terawat
00:31:06seperti yang seharusnya?
00:31:11Kesehatan kode jadi sangat tidak stabil.
00:31:14Jadi Anda harus meluangkan waktu dari waktu ke waktu
00:31:19seperti yang kami lakukan pada pengembangan oleh manusia, kan?
00:31:22Setelah merilis fitur untuk beberapa waktu,
00:31:25Anda harus berhenti sejenak dan berpikir,
00:31:26oke, kita perlu bersih-bersih.
00:31:30Kita perlu melunasi utang teknis (tech debt) yang menumpuk.
00:31:33Dengan agen AI, kita merilis kode jauh lebih cepat sekarang.
00:31:36Kita juga menumpuk tech debt jauh lebih cepat, kan?
00:31:37Jadi Anda perlu memanfaatkan AI untuk melunasi utang itu juga.
00:31:38Saya rasa ini adalah bagian
00:31:40yang diabaikan orang-orang
00:31:42dan sangat butuh solusi saat ini.
00:31:45- Ya, saya sempat melihat basis kode OpenClaw,
00:31:49seperti kata Anda, dan memang agak kacau.
00:31:53Itu benar-benar contoh nyata apa yang terjadi
00:31:56jika Anda membiarkan AI lepas kendali
00:31:57dan membiarkannya melakukan apa pun yang ia mau
00:32:00tanpa pengawasan sama sekali.
00:32:03Ya, itu jadi bahan obrolan menarik di internet
00:32:05selama beberapa minggu terakhir melihat apa saja yang dilakukannya.
00:32:07Tapi saya juga ingin bertanya soal peran AI,
00:32:09apakah Anda mengubah cara membangun formatter
00:32:11dan linter agar agen AI bisa menggunakannya dengan lebih baik?
00:32:13Apakah itu yang membentuk masa depannya
00:32:16atau menurut Anda cara Anda membangun formatter
00:32:19dan linter yang cepat itu secara alami sudah membantu di era AI?
00:32:22Karena jelas karena kecepatannya, agen AI bisa menggunakannya.
00:32:26- Itu pemikiran yang bagus
00:32:29karena kami mulai memikirkan masalah itu
00:32:31karena lingkup asli dari linter
00:32:34dan formatter ini sebenarnya sangat luas
00:32:38karena kami mencoba untuk kompatibel
00:32:40dengan sesuatu seperti ESLint dan Prettier,
00:32:45yang sudah dipakai di produksi selama bertahun-tahun, bahkan satu dekade,
00:32:48di mana orang-orang punya semua aturan khusus,
00:32:50kasus penggunaan lama,
00:32:53dan kami mencoba untuk 100% kompatibel dengannya.
00:32:54Itu pekerjaan yang sangat besar
00:32:56yang akhirnya berhasil kami capai, karena baru-baru ini kami mencapai
00:33:00100% kompatibilitas plugin ESLint.
00:33:03Kami lulus semua tes plugin ESLint
00:33:06dan kami juga mencapai 100% kesesuaian (conformance)
00:33:09dengan Prettier pada formatter kami, kan?
00:33:13Jadi dua pencapaian ini berarti,
00:33:17kami sekarang bisa dengan percaya diri merekomendasikan orang
00:33:21untuk beralih ke alat kami, lalu apa selanjutnya?
00:33:23Itu pertanyaan yang bagus.
00:33:25Bagaimana linting dan formatting ini,
00:33:28beradaptasi saat digunakan oleh agen AI, kan?
00:33:31Itu jelas pertanyaan yang sedang aktif kami kerjakan di sini.
00:33:34Ya.
00:33:38- Jadi jawabannya masih diproses, bisa dibilang begitu.
00:33:40Masih terus berkembang, ya.
00:33:44AI benar-benar mengubah banyak hal
00:33:49di dunia pemrograman, jadi menarik untuk diikuti.
00:33:53- Masih soal topik Vite+,
00:33:54Anda sempat menunjukkannya di ViteConf 2025
00:33:57dan Anda memamerkan fitur bernama Vite install.
00:33:59Pertanyaan saya, apakah fitur itu masih ada?
00:34:01Dan seberapa banyak kesamaan Vite+ nantinya
00:34:04dengan sesuatu seperti BUN?
00:34:06- Pertanyaan bagus, ya.
00:34:10Beberapa hal memang berubah sejak ViteConf.
00:34:14Bisa saya katakan versi finalnya,
00:34:17versi publik final dari Vite+ nantinya kemungkinan,
00:34:19akan terasa mirip seperti BUN dalam beberapa hal, kan?
00:34:21Pengalaman awal penggunanya (onboarding), seperti kata saya,
00:34:23jika Anda punya komputer baru,
00:34:27lalu ingin mulai membangun aplikasi web
00:34:30secepat mungkin.
00:34:33Anda tinggal jalankan skrip curl
00:34:38dan Anda mendapatkan biner global bernama VP, lalu Anda jalankan,
00:34:41saat Anda berada di dalam sebuah proyek, kan?
00:34:43Jika Anda punya file .node-version
00:34:45dan punya kolom package manager di package.json,
00:34:46yang biasa kita gunakan untuk menentukan hal-hal tersebut,
00:34:51lingkungan JS tempat Anda bekerja, kan?
00:34:56Vite+, jadi saat Anda mengetik VP run build,
00:35:02ia akan otomatis menggunakan,
00:35:04bahkan saat Anda cuma bilang VP build atau VP lint atau apa pun,
00:35:06apa pun yang melibatkan eksekusi JavaScript,
00:35:11ia akan otomatis memilih versi Node yang tepat
00:35:15dan package manager yang tepat untuk Anda.
00:35:20Jadi dalam proyek yang menggunakan Vite+,
00:35:22bahkan jika Anda tidak menggunakan Vite+ di proyek itu,
00:35:26selama Anda menggunakan
00:35:28sumber lingkungan (environment sources) yang konvensional ini,
00:35:31Anda bisa menggunakan Vite+ sebagai pengganti NVM.
00:35:36Anda bisa menggunakannya sebagai pengganti Corepack.
00:35:40Anda tinggal berhenti memikirkan soal versi.
00:35:44Idenya adalah, karena saat Anda menjalankan alur kerja,
00:35:45Anda melakukannya lewat, Anda juga berhenti pakai npm run.
00:35:48Anda pakai VP run.
00:35:52Idenya di sini adalah, saat Anda melakukan VP run,
00:35:55ia akan memakai versi Node yang tepat,
00:35:59ia akan memakai versi package manager yang tepat.
00:36:02Dan melakukan hal yang benar.
00:36:05Jadi fitur install artinya ia akan langsung,
00:36:06kami tidak punya package manager sendiri dulu, ya?
00:36:10Jadi ini lebih seperti padanan Corepack
00:36:14saya tidak tahu apakah Anda pernah pakai paket bernama NI,
00:36:16buatan Anthony Fu.
00:36:19NI pada dasarnya saat Anda menjalankan NI,
00:36:24ia akan otomatis mendeteksi package manager yang tepat untuk dipakai,
00:36:27apakah Anda ingin melakukan run, install, atau uninstall,
00:36:30apa pun itu, kan?
00:36:34Vite install pada dasarnya adalah itu,
00:36:36ditambah bagian manajemen package manager-nya.
00:36:41Itulah yang dilakukan Corepack, kan?
00:36:45Jadi meskipun Anda tidak punya apa pun yang terinstal,
00:36:48saat masuk ke proyek dan di file package.json
00:36:49tertulis pnpm pada versi tertentu.
00:36:51Anda jalankan Vite install, ia akan otomatis memeriksa
00:36:56apakah pnpm versi tersebut sudah terinstal.
00:36:58Jika belum, ia akan langsung menginstalnya
00:37:01dan menjalankan proses instalasi dengan pnpm install.
00:37:03Ya, jadi idenya kami ingin,
00:37:07menyelesaikan lebih dari sekadar masalah linting dan formatting.
00:37:08Ini soal seluruh hal umum yang Anda butuhkan
00:37:12dalam alur kerja JavaScript Anda, kan?
00:37:14Kami ingin menghilangkan masalah umum ini
00:37:16supaya pemula tidak perlu memikirkannya sama sekali, kan?
00:37:20Pertama kali Anda membuat kerangka proyek,
00:37:25kami akan menggunakan Node versi LTS terbaru dan kami merekomendasikan pnpm.
00:37:31Dan kami akan menuliskan informasi tersebut ke dalam proyek Anda.
00:37:34Jadi lain kali Anda masuk ke proyek ini,
00:37:36ia akan selalu menggunakan kombinasi yang tepat.
00:37:40- Kenapa Anda merekomendasikan pnpm kalau boleh tahu?
00:37:43- Karena ia punya keseimbangan yang pas antara fitur,
00:37:45ketepatan, efisiensi ruang penyimpanan, dan kecepatan
00:37:50serta dukungan workspace yang baik, seperti fitur catalog,
00:37:53saat kami membandingkan semua fitur workspace,
00:37:55kami merasa pnpm masih memberikan keseimbangan terbaik.
00:37:59Dan kami tahu BUN itu sangat cepat,
00:38:02tapi pnpm sudah cukup cepat bagi kebanyakan dari kami.
00:38:06Dan kami juga tidak menutup kemungkinan
00:38:10untuk mendukung BUN dalam manajemen versi runtime
00:38:15dan package manager kami, kan?
00:38:19Jadi Anda bisa bilang, saya ingin pakai BUN
00:38:21dan kami akan menjalankan semuanya dengan BUN.
00:38:25- Soal Vite 8, sepertinya Anda bilang akan rilis
00:38:29setelah Tahun Baru Imlek, kan?
00:38:33- Ya.
00:38:35- Apa beberapa hal dalam versi beta
00:38:37yang Anda fokuskan sebelum benar-benar meluncurkannya?
00:38:40- Semuanya soal stabilitas.
00:38:42Ecosystem CI,
00:38:44kami punya sistem CI ekosistem yang sangat masif
00:38:49di mana kami menjalankan Vite 8 di proyek-proyek hilir yang bergantung padanya.
00:38:52Salah satu hal yang baru saja kami lakukan adalah,
00:38:54semua tes SvelteKit sekarang lulus di Vite 8.
00:38:58Itu pencapaian besar bagi kami
00:39:00karena stabilitas adalah hal terpenting
00:39:04sebab jika Anda pikirkan,
00:39:06kami mengganti dua bundler lama
00:39:10dengan yang baru yang kami bangun dari nol.
00:39:15Ini seperti mengganti mesin pesawat yang sedang terbang
00:39:17dan berharap pesawatnya tetap terbang mulus setelahnya.
00:39:21Jadi kami harus ekstra hati-hati.
00:39:24- Tadi saya ingin bertanya, soal pilihan menggunakan Rust,
00:39:27apakah karena orang-orang di tim Anda
00:39:28sudah paham Rust?
00:39:30Karena saya lihat banyak orang di dunia TypeScript
00:39:33lebih suka Go karena menurut saya lebih mudah untuk memindahkannya
00:39:36dan itulah kenapa TypeScript bahkan beralih ke Go
00:39:40untuk compiler-nya.
00:39:43- Ya, saya rasa pilihan tim TypeScript
00:39:46untuk ditulis ulang ke Go adalah, seperti kata saya,
00:39:48Go adalah bahasa yang jauh lebih mudah untuk porting dari TypeScript, kan?
00:39:49Karena model mentalnya jauh lebih mirip.
00:39:51Satu alasan besar yang jadi penghalang bagi kami
00:39:55adalah Go punya dukungan WebAssembly yang kurang bagus.
00:39:57Ia menghasilkan biner WebAssembly yang sangat besar
00:39:58dan performanya, performa WebAssembly-nya
00:40:02tidak sebagus Rust.
00:40:04Sedangkan dengan Rust,
00:40:09ya, banyak pengaruh dari talenta yang tersedia,
00:40:13orang-orang yang sudah antusias
00:40:17dan berinvestasi di ekosistemnya.
00:40:21Misalnya, saat kami mencari
00:40:26fondasi untuk membangun sistem ini,
00:40:29tidak ada set parser atau toolchain
00:40:32yang diimplementasikan sebaik dan se-composable ini.
00:40:35OXC memang dibangun untuk menjadi fondasi bagi yang lain, kan?
00:40:39Berisi utilitas tingkat rendah.
00:40:41Kami tidak melihat ada yang setara di dunia Go.
00:40:44esbuild punya parser sendiri dan semuanya,
00:40:46tapi itu sistem monolitik yang besar.
00:40:48Anda tidak bisa asal ambil parser-nya saja untuk dipakai.
00:40:54Dan juga semua fitur di esbuild,
00:40:59seperti define, inject, transformasi, dan modifikasi.
00:41:04Untuk mendapatkan performa terbaik,
00:41:08ia diimplementasikan dalam tiga tahap AST (AST passes),
00:41:11artinya dalam satu tahap AST yang sama,
00:41:14Anda mungkin punya urusan yang campur aduk,
00:41:18ada transformasi di sini,
00:41:23ada fitur inject di sini,
00:41:25ada fitur modifikasi di sini.
00:41:30Itu membuatnya kurang ideal untuk sistem yang bisa diperluas
00:41:33di mana, misalnya,
00:41:36kami ingin bisa merilis lebih banyak transformasi
00:41:37dan membiarkan orang menyalakan atau mematikannya.
00:41:39Kami ingin orang bisa menulis transformasi mereka sendiri.
00:41:41Anda butuh sistem linter yang
00:41:42berlapis-lapis secara bersih
00:41:45supaya lebih banyak orang bisa mengerjakannya di saat bersamaan.
00:41:51Jadi ini banyak hubungannya dengan apa yang tersedia.
00:41:54Rust juga sangat berperforma.
00:41:57Memang agak sulit menulis transformasi yang bagus dengan Rust.
00:42:01Kami harus menghabiskan cukup banyak waktu
00:42:03mencari arsitektur yang bagus
00:42:07untuk alur visitor dan transformer,
00:42:09karena masalah kepemilikan memori,
00:42:13saat Anda menelusuri jauh ke dalam struktur pohon (tree)
00:42:16dan perlu mengubah pohon induknya,
00:42:22itu jadi sangat rumit, kan?
00:42:26Tapi kami berhasil menemukan solusinya.
00:42:28Jauh lebih mudah di Go, tapi saat dipikirkan lagi,
00:42:31kami ingin alat kami bisa dikompilasi
00:42:34ke WebAssembly dan dijalankan di browser.
00:42:37Rolldown bisa berjalan di browser
00:42:39dan berjalan dengan sangat cepat.
00:42:42Memang esbuild bisa jalan di browser,
00:42:44tapi WebAssembly dari Rust itu jauh lebih baik.
00:42:45- Pertanyaan lain yang ingin saya tanyakan
00:42:49berdasarkan pembangunan tim di Rust tadi,
00:42:51bagaimana tim dan Anda sendiri menggunakan AI?
00:42:53Tadi Anda bilang banyak orang
00:42:57di tim yang menggunakan AI.
00:42:59Apakah Anda merasa AI bagus dalam pekerjaan yang Anda lakukan?
00:43:01Karena saya rasa untuk pengembangan web dan bikin website,
00:43:05sudah ada banyak sekali contohnya di GitHub.
00:43:07Jadi AI terlatih dengan cukup baik.
00:43:09Tapi saya rasa yang Anda lakukan ini di tingkat yang lebih rendah
00:43:12secara teknis, atau setidaknya teknisitasnya tinggi.
00:43:14Jadi apakah AI membantu di sana atau Anda masih banyak
00:43:16menulis kode secara manual?
00:43:19- Jelas sangat membantu.
00:43:21Masalahnya bidang ini berubah sangat cepat.
00:43:23Tahun lalu di waktu yang sama, saya masih skeptis.
00:43:25Saya pikir, saya sudah coba dan tidak cocok buat saya
00:43:28karena pekerjaan saya terlalu low-level, kan.
00:43:30Lalu Borshin yang memimpin OXC,
00:43:32dia mungkin orang yang paling antusias dengan AI
00:43:34di perusahaan saat ini.
00:43:38Dia mulai melakukan eksperimen gila.
00:43:41Bulan lalu ada satu minggu
00:43:45dia merilis 60 PR dengan bantuan AI
00:43:49dan menjalankan agen AI secara paralel.
00:43:52Lalu kami mulai melakukan eksperimen gila
00:43:59seperti mem-porting compiler Angular ke Rust,
00:44:03kami berikan tugas itu ke AI dan lihat hasilnya.
00:44:04Dan ternyata berhasil.
00:44:07Jadi mungkin kami akan punya sesuatu di bidang itu di masa depan.
00:44:11Ya, saya rasa kami terus diperbarui
00:44:13dan persepsi kami soal batas kemampuan AI
00:44:16terus disegarkan setiap beberapa bulan
00:44:19dengan munculnya model-model baru,
00:44:24dengan sistem pendukung yang lebih baik
00:44:27dan praktik baru seperti menggunakan “plan mode”
00:44:29lalu menulis deskripsi agen Anda.
00:44:33Gunakan tips dan trik semacam ini.
00:44:39Saat Anda menerapkan hal-hal kecil itu, Anda sadar,
00:44:43bahwa AI memang jadi makin lama makin bagus.
00:44:46Tingkat adopsi dan penggunaannya masih bervariasi tiap orang, ya?
00:44:48Kami memacu semua orang di perusahaan
00:44:51untuk menggunakannya sejauh yang mereka rasa pas, kan?
00:44:55Kami beri mereka kredit bulanan
00:45:00supaya mereka bisa pakai Claude 3.5 Sonnet kalau mau.
00:45:03Beberapa orang sangat senang
00:45:06dan cukup vokal soal itu.
00:45:08Dan jelas mereka memberikan PR yang sangat bagus, kan?
00:45:13Saya rasa ini sangat tergantung pada seberapa baik Anda memakainya.
00:45:18Sebagian karena kemampuan murni model AI-nya.
00:45:22Sebagian karena sistem pendukung yang Anda pakai,
00:45:24tapi menurut saya lapisan sistem pendukung ini
00:45:27mirip seperti framework JavaScript di masa lalu.
00:45:33Semua orang membuat versi mereka sendiri.
00:45:36Dan melakukan hal yang kurang lebih sama.
00:45:40Mungkin yang satu punya trik yang berbeda sedikit,
00:45:45tapi beberapa bulan kemudian, semua orang melakukannya, kan?
00:45:49Jadi ini akan jadi bidang yang sangat kompetitif dan model AI pun sama.
00:45:52Setiap beberapa bulan,
00:45:54seperti Sonnet 3.5 yang baru saja rilis.
00:45:57Saya dengar DeepSeek juga akan merilis model baru.
00:46:00Semuanya akan jadi makin bagus.
00:46:03Dan sudah jelas bahwa AI sangat mampu
00:46:08jika diarahkan dengan benar,
00:46:11tapi bagian mengarahkan itu masih sangat penting.
00:46:13Anda tidak bisa berharap orang yang nol pengetahuan soal Rust
00:46:17bisa mengerjakan basis kode OXC, meskipun pakai AI.
00:46:18Dia bahkan mungkin tidak tahu cara memberi instruksinya, kan?
00:46:21Tapi seseorang yang sudah mahir di OXC
00:46:23sebagai insinyur Rust, dengan bantuan AI
00:46:26akan jadi jauh lebih produktif
00:46:32dan bisa merilis lebih banyak fitur dengan cepat.
00:46:34Itulah pandangan umum saya soal itu.
00:46:37Saya sendiri mungkin termasuk yang,
00:46:41jumlah kode yang saya hasilkan dengan AI sangat sedikit,
00:46:45minimal sekali dibanding insinyur lain di perusahaan.
00:46:50Saya lebih menggunakannya untuk riset dan teman diskusi.
00:46:54- Memang dunia pemrograman jadi aneh sekarang,
00:46:58arahnya ke sana
00:47:00dan saya merasa sulit mengikuti perkembangan
00:47:03berapa banyak sub-agen yang harus dipakai,
00:47:08agen paralel, atau file markdown apa yang harus ada
00:47:13di dalam repositori sekarang.
00:47:16Ya, semuanya berubah sepanjang waktu.
00:47:20Jadi saya penasaran akan berakhir seperti apa
00:47:25di masa depan nanti.
00:47:27- Kalau kita kembali bahas Vite sebentar.
00:47:29Di Vite 7, Anda merilis dukungan React Server Component.
00:47:32Dan menurut pendapat saya, React Server Components
00:47:34belum sesukses yang dipikirkan oleh tim pengembangnya.
00:47:37Maksud saya, ada beberapa meta framework yang tidak menerimanya,
00:47:38seperti TanStack.
00:47:40Dan saya rasa Remix malah mengambil arah yang benar-benar berbeda.
00:47:43Jadi apa pendapat Anda soal React Server Components
00:47:43dan menurut Anda kenapa ia belum sesukses yang diharapkan?
00:47:47- Ya, saya selalu sangat konservatif soal itu
00:47:52atau saya sudah skeptis sejak hari pertama.
00:47:54Itulah kenapa kami tidak pernah mempertimbangkan untuk menerapkan
00:47:57sesuatu yang serupa di Vue.
00:48:00Saya rasa ide fundamentalnya adalah masalah apa sebenarnya
00:48:01yang coba ia selesaikan?
00:48:04Dan saya rasa itu karena cara ia dipromosikan, ya?
00:48:07Dalam upaya menarik minat orang-orang,
00:48:10ia diiklankan seolah sebagai solusi segalanya.
00:48:14Bahwa ini akan jadi hal terbaik yang pernah ada.
00:48:17Yang akan membuat semua situs web Anda lebih cepat.
00:48:20Ternyata saat diluncurkan, orang-orang sadar,
00:48:23mungkin saya tidak perlu memakainya di semua kasus.
00:48:28Ia hanya cocok untuk tipe kasus tertentu
00:48:30di mana ia akan memberi manfaat.
00:48:35Sedangkan di kasus lain, isinya cuma sekumpulan pengorbanan (trade-offs).
00:48:38Karena bagian yang ada di server,
00:48:40semua interaksi sekarang harus melalui
00:48:42putaran permintaan jaringan.
00:48:44Dan itu sebenarnya cukup oke,
00:48:48tapi cukup buruk untuk pengalaman yang mengutamakan offline, menurut saya.
00:48:51Lalu Anda tidak bisa sepenuhnya menghindari biaya hidrasi,
00:48:54menurut pendapat saya.
00:48:56Dan Anda hanya memindahkan banyak biaya hidrasi sisi klien.
00:48:59Anda memindahkannya ke server, kan?
00:49:04Sekarang Anda menanggung biaya di setiap permintaan
00:49:06karena Anda melakukan lebih banyak pekerjaan di server.
00:49:08Banyak orang punya teori konspirasi,
00:49:10bahwa Vercel mendorong ini untuk menjual server compute mereka.
00:49:14Saya tidak merasa itu alasannya, ya?
00:49:20Tapi memang benar bahwa menggunakan RSC
00:49:21berarti beban server jadi lebih tinggi.
00:49:26Anda menjalankan lebih banyak hal di server,
00:49:29Anda menggunakan lebih banyak menit komputasi.
00:49:31Dan pada akhirnya ada manfaat lain seperti,
00:49:33jika menaruh sebagian sistem di server,
00:49:38Anda menghemat ukuran bundel.
00:49:44Tapi ada banyak cara lain untuk menyelesaikan masalah itu,
00:49:47yang tidak selalu melibatkan
00:49:51Anda harus menjalankan server Node.js, kan?
00:49:52Dan banyak dari ini hanyalah pendapat pribadi saya, ya?
00:49:54Di dunia frontend, kita cenderung bilang, oke,
00:49:56arsitektur itu sangat penting.
00:49:59Apakah Anda ingin pakai SPA?
00:50:01Apakah Anda butuh server-side rendering, kan?
00:50:02RSC itu bahkan lebih spesifik lagi.
00:50:06Pertanyaan apakah Anda butuh RSC adalah pertanyaan yang sangat penting
00:50:07dan sangat sulit untuk dijawab.
00:50:10Dan saat Anda bilang iya,
00:50:14Anda juga harus sadar akan biaya yang Anda bayar
00:50:17karena menurut saya salah satu alasan
00:50:19ia tidak diadopsi dengan baik adalah, pertama-tama,
00:50:21ia sangatlah rumit.
00:50:24Konsepnya sendiri sulit dijelaskan.
00:50:27Cara kerjanya sulit dijelaskan.
00:50:31Kami harus mempelajarinya sangat dalam
00:50:33karena ia sebenarnya butuh orkestrasi di tingkat build tool
00:50:35untuk membuat seluruh sistem bekerja, kan?
00:50:37Lalu, jadi sangat sedikit orang yang benar-benar paham
00:50:39bagaimana RSC murni bekerja.
00:50:43Kebanyakan orang tahu lewat implementasi
00:50:46di Next.js karena RSC murni adalah sesuatu yang pengguna biasa
00:50:48tidak akan bisa siapkan sendiri, kan?
00:50:50Anda harus benar-benar paham bagaimana semuanya saling terhubung
00:50:52untuk bisa membangun sesuatu dari nol
00:50:56dengan React murni dan Vite atau Webpack, kan?
00:50:58Itu bukan untuk pengembangan sehari-hari, kan?
00:51:02Jadi Anda ingin pakai framework.
00:51:04Itulah kegunaan framework.
00:51:07Tapi untuk memakai RSC dalam sebuah framework,
00:51:11framework tersebut harus mengambil keputusan desain
00:51:14mengenai bagaimana menyajikan RSC
00:51:17dengan cara yang memberikan DX yang layak?
00:51:20Dan menurut saya Next.js belum berhasil melakukannya, ya?
00:51:23grafik campuran di mana saat Anda membuat sesuatu jadi “use server”
00:51:27So you want to use a framework.
00:51:29beberapa hal lain jadi berhenti bekerja.
00:51:30Anda jadi terbatas hanya bisa pakai hal-hal ini
00:51:33dan saat Anda mengimpor sebuah dependensi
00:51:36ternyata dependensi itu tidak jalan di “use server”.
00:51:39Sekarang Anda harus balik pakai “use client” lagi, kan?
00:51:42Bolak-balik seperti ini,
00:51:47saya rasa banyak sekali ganjalan kecil
00:51:51dalam DX yang membuat orang berpikir, oke,
00:51:55untuk mendapatkan manfaat yang dijanjikan,
00:51:58sekarang saya juga harus menanggung ketidaknyamanan DX ini
00:52:01setiap saat, selamanya di masa depan.
00:52:03Apakah ini benar-benar sepadan, kan?
00:52:06Jadi ya, saya rasa wajar jika orang bertanya,
00:52:08apakah saya benar-benar ingin memakainya?
00:52:10Dan bahkan bagi pembuat framework juga, kan?
00:52:12Vercel punya hubungan yang sangat dekat dengan tim React
00:52:15sehingga mereka bisa berkolaborasi dan melakukan iterasi dengan cepat.
00:52:20Tapi bagi pihak ketiga, saya tidak akan bilang pihak ketiga
00:52:24karena secara teknis Vercel itu pihak ketiga, kan?
00:52:27Tapi bagi framework lain seperti Remix dan TanStack,
00:52:28tidak semudah itu bagi mereka untuk
00:52:35mengerjakan masalah ini karena banyak iterasi API
00:52:37dari tim React seolah memprioritaskan Next.js.
00:52:40Saya tidak benar-benar mengkritik mereka soal itu
00:52:42karena memang Vercel adalah mitra desain mereka.
00:52:45Mereka ingin bermitra dengan Vercel
00:52:49untuk menyempurnakan fitur ini dan meluncurkannya,
00:52:52yang mana itu masuk akal, kan?
00:52:57Tapi karena hal itu,
00:53:02Next.js pada dasarnya jadi satu-satunya cara nyata
00:53:06bagi orang-orang untuk menggunakan RSC.
00:53:08Dan pengalaman itu belum benar-benar luar biasa.
00:53:13Jadi itulah kenapa ia tidak berjalan sesuai harapan.
00:53:15Dan juga, menurut saya premis umumnya adalah
00:53:17bahkan di dunia ideal di mana RSC punya DX yang sempurna,
00:53:19saya tetap tidak merasa ia akan jadi solusi segalanya
00:53:21dalam semua kasus, kan?
00:53:25Anda perlu benar-benar paham
00:53:29di mana ia cocok digunakan dan di mana tidak.
00:53:31Terlalu banyak yang harus dikorbankan.
00:53:33- Saya asumsikan tidak ada semacam dorongan
00:53:38untuk menerapkan hal serupa di Vue
00:53:41karena jelas hubungannya kembali ke Vercel.
00:53:46Mereka membeli Nuxt Labs,
00:53:49yang merupakan meta framework di atas Vue
00:53:50untuk menyatukan semuanya.
00:53:52Bagaimana hubungan antara Nuxt dan Vue
00:53:54sekarang setelah Vercel memiliki mereka?
00:53:57- I assume there's been no sort of push
00:53:59- Sejujurnya, tidak banyak yang berubah.
00:54:01Saya rasa Vercel cukup membebaskan sejak akuisisi itu,
00:54:03jadi tim Nuxt senang-senang saja bisa
00:54:05terus melakukan apa yang mereka lakukan.
00:54:08Mungkin ada beberapa upaya untuk,
00:54:09membuat Nuxt berjalan lebih baik di Vercel,
00:54:13menjadikannya warga kelas satu.
00:54:14Tapi saya rasa Vercel sadar
00:54:18mengenai citra yang mereka punya di komunitas
00:54:21dan mereka akan sangat berhati-hati agar tidak merusaknya lebih jauh.
00:54:24Jadi setelah mengakuisisi Nuxt,
00:54:25hal terakhir yang ingin mereka lakukan
00:54:30adalah memaksa Nuxt melakukan hal yang tidak disukai orang-orang.
00:54:32- Sayangnya, Evan harus pergi lebih awal
00:54:34untuk menerima telepon penting,
00:54:38tapi kami sangat menghargai waktunya
00:54:43dan semua pendapatnya yang mendalam atas semua pertanyaan kami.
00:54:47Jika Anda punya usulan tamu untuk podcast ini,
00:54:50beri tahu kami di kolom komentar.
00:54:52Dan jika ada masukan secara umum,
00:54:54beri tahu kami juga.
00:54:56Kami ingin mendengarnya.
00:54:58Cari kami di mana pun Anda mendengarkan podcast
00:55:00seperti Spotify atau Apple Podcasts.
00:55:04Sampai jumpa lagi, sekian dari saya.
00:55:06- Sampai jumpa dari saya.
00:55:08- Sampai jumpa dari saya.
00:55:10- Senang sekali bisa bergabung, terima kasih semua.
00:55:11- Terima kasih banyak sudah bergabung bersama kami.
00:55:12Find us on anywhere you listen to podcasts
00:55:15like Spotify or Apple Podcasts.
00:55:17And until next time, it's a bye from me.
00:55:20- Bye from me.
00:55:21- Bye from me.
00:55:21- It's a pleasure, thank you all.
00:55:23- Thank you very much for joining us.