- Tren belakangan untuk menulis ulang tool Node.js ke bahasa yang lebih cepat seperti Rust, Zig, dan Go terasa mengkhawatirkan, dan berikut rangkuman sejumlah kekhawatiran yang objektif
[Performa]
- Masih ada banyak potensi yang belum digali untuk meningkatkan kecepatan tool JavaScript
- Ada banyak bagian yang bisa diperbaiki dengan mudah di ESLint, Tailwind, dan lainnya
- Di browser, JavaScript sudah "cukup cepat" untuk sebagian besar beban kerja
- Jadi mengapa pada tool CLI orang ingin meninggalkan JavaScript?
Penulisan ulang besar-besaran
- Selama ini ekosistem tool JavaScript berfokus pada "membuatnya berjalan"
- Kini API sebagian besar sudah stabil, sehingga semua orang menginginkan "hal yang sama, tetapi lebih cepat"
- Tool baru bisa menjadi lebih cepat karena ditulis dari awal dengan mempertimbangkan performa, dan waktu pengembangan bisa dihemat karena API-nya sudah ditentukan
- Jika sesuatu ditulis ulang dari A ke B lalu menjadi lebih cepat, mudah untuk mengklaim bahwa B lebih cepat daripada A
- Namun bisa jadi penulisan ulang itu sendiri yang membuatnya lebih cepat (karena pada percobaan kedua kita sudah lebih tahu dan lebih memerhatikan performa)
Bytecode dan JIT
- Di browser hal ini dianggap biasa, tetapi kita mendapat manfaat dari cache bytecode dan JIT (Just-In-Time compiler)
- Jika JavaScript di-cache dengan benar, browser tidak perlu mem-parse dan mengompilasi source code menjadi bytecode
- Fungsi yang sering dijalankan akan dioptimalkan lebih lanjut menjadi machine code (JIT)
- Pada skrip Node.js, manfaat cache bytecode selama ini sama sekali tidak didapatkan
- Namun sekarang di Node pun kita bisa menggunakan compile cache (dengan mengatur environment variable
NODE_COMPILE_CACHE)
- JIT perlu menjalankan fungsi beberapa kali agar menjadi "panas", jadi pada skrip sekali jalan sulit mendapatkan manfaatnya
- Di Pinafore, pernah dicoba mengganti library blurhash berbasis JavaScript dengan versi Rust (Wasm), tetapi pada iterasi ke-5 perbedaan performanya hilang
- Bisa juga mempertimbangkan AOT compile untuk skrip Node dengan tool seperti Porffor
- Menggunakan Wasm tetap memiliki penalti performa dibanding tool native murni
[Kontribusi dan kemudahan debugging]
- Inilah skeptisisme utama terhadap gerakan "menulis ulang semuanya menjadi native"
- JavaScript adalah bahasa yang populer karena typing-nya longgar, mudah dipelajari, dan didukung browser
- Sudah lama dalam ekosistem JavaScript, baik pembuat library maupun penggunanya sama-sama memakai JavaScript
- Ini membantu menurunkan hambatan untuk berkontribusi
- Namun jika pembuat library JavaScript memakai bahasa lain, keunggulan ini hilang
- Selain itu, memodifikasi dependency JavaScript secara lokal juga sederhana (langsung mengubahnya di
node_modules)
- Sebaliknya, bila ditulis dalam bahasa native, source code harus di-checkout dan dikompilasi sendiri
- Saat melakukan debugging library JavaScript, kita bisa memakai browser developer tools yang sudah familiar atau debugger Node.js
- Di Wasm debugging bukan mustahil, tetapi membutuhkan set keterampilan yang berbeda
[Kesimpulan]
- Munculnya generasi baru tool untuk ekosistem JavaScript adalah hal yang baik
- Tool yang ada sekarang tampak sangat lambat, dan kemungkinan akan mendapat manfaat dari persaingan
- Namun bukan berarti JavaScript itu sendiri secara inheren lambat atau tidak punya ruang untuk ditingkatkan
- Melihat perbaikan terbaru pada developer tools Chromium, terasa bahwa masih banyak yang bisa dilakukan
- Ada kekhawatiran tentang dunia yang menjadi semacam wilayah eksklusif bagi pengembang Rust dan Zig
- Pengembang JavaScript rata-rata bisa merasa tidak berdaya saat menghadapi bug pada build tool
- Ini bisa saja mengajarkan rasa tidak berdaya yang dipelajari kepada para pengembang web muda
- Ini adalah jalan yang belum dikenal, dan bisa menimbulkan konsekuensi yang tidak disengaja
- Di sisi lain, ada jalan lain yang lebih sedikit risikonya sambil tetap bisa memperoleh hasil yang hampir sama
- Namun arus saat ini tampaknya belum menunjukkan tanda-tanda melambat
Pendapat GN⁺
- Menulis ulang ke Rust, Zig, dan sebagainya belum tentu selalu pilihan terbaik. Masih tampak ada ruang perbaikan di JavaScript seperti compile cache
- Patut dipertanyakan apakah baik bagi pengembang pemula untuk berhadapan dengan masalah rumit seperti segfault; jangan-jangan yang diajarkan justru rasa tidak berdaya
- Perlu dipikirkan apakah meningkatkan kecepatan dengan mengorbankan kelebihan ekosistem yang dibangun lama dengan JavaScript (modifikasi bebas antar-library, lingkungan debugging yang familiar, dan sebagainya) benar-benar arah yang tepat
- Upaya memperbaiki library JavaScript yang ada juga tampaknya harus terus berlanjut. Potensi JavaScript sendiri masih belum sepenuhnya digali
- Meski tren besarnya tampak sulit dibendung, komunitas tetap perlu berdiskusi dan memikirkan arah ini secara serius
15 komentar
Cara operasional toko kecil dan toko besar tentu bisa agak berbeda. Menurut saya, alih-alih bersikap kritis terhadap perubahan itu sendiri, lebih sehat jika kita memikirkan makna dari fenomena ini.
Perubahan itu mungkin tampak didorong oleh selera atau tren, tetapi perusahaan biasanya tidak mengambil keputusan seperti itu, bukan?
Apakah Python atau JavaScript sendiri lambat? Mungkin tidak bisa dibilang begitu.
Namun, apakah tool yang sering digunakan dan dibuat dengan Python atau JavaScript lambat? Menurut saya, ya.
Saya menggunakan beberapa perangkat berdaya rendah, dan benar-benar banyak tool yang lambatnya bikin frustrasi..
Di komunitas Python pun, pembahasan dengan pola yang nyaris sama terus berulang.
JavaScript tidak ditulis dengan JavaScript, tetapi sebagian besar pengembang JavaScript tidak peduli soal itu. Bagi "pengembang pemula" dan "pengembang web muda", fakta bahwa JavaScript tidak ditulis dengan JavaScript bukanlah masalah, tetapi menganggap alat pengembangan JavaScript menjadi masalah jika tidak ditulis dengan JavaScript adalah argumen yang terasa kurang konsisten. Justru, pengembang yang benar-benar mempermasalahkan hal seperti itu hanyalah sebagian kecil dari kedua kelompok tersebut.
Bahkan tanpa menyangkal bahwa dengan optimasi yang cukup hasilnya bisa mencapai kecepatan yang hampir sama, apakah itu benar-benar sepadan?
Ini hanyalah transisi dari masa ketika menulis alat pengembangan dengan JavaScript alih-alih C++ menjadi lebih ekonomis, menuju masa ketika menulisnya dengan Rust menjadi lebih ekonomis daripada dengan JavaScript.
Cara untuk membalik arus ini bukanlah dengan menggelontorkan biaya lebih besar untuk menggalakkan gerakan optimasi di JavaScript, melainkan dengan menciptakan lingkungan yang memungkinkan pengembangan alat JavaScript yang efisien dengan biaya pengembangan yang lebih rendah. (Sekilas mungkin terdengar mirip, tetapi perbedaannya ada pada ke mana upaya itu diarahkan)
Saya setuju. Saya rasa kita perlu mendefinisikan ulang efisiensi ekonomi dengan berpusat pada pengguna alat.
Selama ini, efisiensi ekonomi tampaknya lebih merupakan metrik yang mempertimbangkan pengembang alat daripada pengguna alat. Terasa seperti inefisiensi dan masalah performa yang harus dialami para pengguna alat relatif didorong ke prioritas yang lebih belakang. Secara pribadi saya cukup sering memakai uv dan vite, dan kalau memungkinkan saya ingin menghindari alat seperti pip atau create-react-app.
Saya sulit setuju karena saya pikir alat CLI seharusnya bisa berjalan tanpa runtime.
Kalau ditanya bukannya bisa membuat berkas eksekusi mandiri WASM, seperti juga disebutkan di artikel, akan ada penurunan performa.
Sama seperti menulis CLI dengan Java bukan hal yang umum, saya rasa JavaScript juga sama.
Penulis tampaknya keliru mengira bahwa karena JavaScript digunakan baik untuk SPA maupun pengembangan tool JavaScript, kemampuan pendukung lain yang dibutuhkan juga sama. Menurut saya, tool JavaScript memerlukan kompetensi di bidang pemrograman sistem dan compiler.
> Selama ini, dalam ekosistem JavaScript, baik penulis library maupun penggunanya sama-sama menggunakan JavaScript
> Ini membantu menurunkan hambatan untuk berkontribusi
> Namun jika penulis library JavaScript menggunakan bahasa lain, hal ini menjadi rusak
Meski bahasanya sama, lingkungan eksekusinya berbeda antara browser dan NodeJS, jadi hanya orang yang bisa menjembatani kesenjangan itu yang akan bisa berkontribusi pada tool JavaScript. Karena lingkungan eksekusinya berbeda, bukankah lebih tepat melihatnya sebagai ekosistem yang berbeda?
> Developer JavaScript rata-rata bisa merasa tidak berdaya saat menghadapi bug di build tool
> Ini bisa berujung pada mengajarkan ketidakberdayaan yang dipelajari kepada para developer web muda
Menurut saya, ini juga sama-sama merupakan titik di mana jumlah orang yang bisa melampaui batas antara pengembangan SPA dan pengembangan tool JavaScript dinilai terlalu tinggi. Tidak realistis menuntut developer frontend memiliki pengetahuan setara pemrograman sistem. Bukankah pengguna tool pada akhirnya hanya bisa memahami pesan error di permukaan atau gejalanya saja? Saya rasa ini bukan masalah yang bisa diselesaikan hanya dengan mengetahui bahasanya.
Sepertinya alat dan library sedang dibicarakan secara campur aduk. Untuk library, saya bisa cukup memahami sampai batas tertentu, tapi untuk alat, entahlah..
Pengembang bahasa lain juga pasti sudah terbiasa karena alat mereka ditulis secara native.
Secara pribadi, baik itu tool maupun library, jika ditulis dalam JavaScript maka para pengembang yang terbiasa dengan JavaScript bisa men-debug-nya dan, bila perlu, ikut berkontribusi. Namun, jika sudah ditulis ulang ke Rust, kontribusi open source pada akhirnya hanya bisa dilakukan oleh para pengembang Rust. Karena jumlah pengembang JavaScript jauh lebih besar dibandingkan Rust, bisa jadi dalam ekosistem open source akan lebih menguntungkan jika tool maupun library ditulis dengan JavaScript.
JavaScript memiliki lingkungan eksekusi yang terfragmentasi antara browser dan NodeJS, sehingga saya rasa perbandingan sederhana jumlah pengguna bahasa ini memiliki keterbatasan sebagai argumen. Pengembang backend Spring dan pengembang JDK, serta pengembang React/Angular/Vue dan pengembang alat JavaScript, memiliki minat dan posisi yang berbeda, dan hubungannya adalah antara konsumen dan produsen
Secara pribadi, saya melihat bahwa jika tujuannya adalah meningkatkan performa dan kegunaan alat JavaScript, maka mengganti bahasa implementasi sebagai sarana juga merupakan salah satu opsi yang layak dipilih.
Saya rasa sulit untuk membedakan secara tegas antara konsumen dan produsen alat pengembangan. Ketika sebuah perusahaan makin besar, sering kali mereka menyesuaikan toolchain atau membuat plugin tambahan agar sesuai dengan aturan yang mereka inginkan, dan dalam kasus seperti ini, menurut saya hanya dengan menggunakan bahasa yang sama saja sudah menjadi keuntungan besar.
Ada juga banyak kasus ketika pengguna alat tertarik pada peningkatan atau implementasi alat itu sendiri dan secara alami akhirnya ikut berkontribusi.
Saya pikir orang yang tertarik pada kustomisasi toolchain atau yang mengerjakan tugas itu menjalankan peran bukan sekadar sebagai konsumen, melainkan sebagai prosumer atau bahkan produsen. Dalam kasus plugin, saya melihatnya bergerak di dalam kontrak plugin antara produsen dan konsumen. Dalam situasi seperti itu, saya juga setuju bahwa menggunakan bahasa yang sama lebih membantu, baik secara teknis maupun dari segi biaya komunikasi, dibanding menyediakan format file konfigurasi atau extension point terpisah.
Namun, saya tidak menganggap masalah performa alat JavaScript atau masalah latensi JIT pada NodeJS berada dalam cakupan pengambilan keputusan konsumen. Itu karena pihak yang merancang arsitektur dan spesifikasi perilaku tersebut adalah para pembuat tool dan pengembang runtime.
Saya ragu bahwa hanya karena porsi JavaScript besar, otomatis akan ada lebih banyak pengembang yang bisa berkontribusi pada codebase compiler/transpiler. Menurut saya, framework library dan alat dasar adalah ranah yang sama sekali berbeda.
Namun, penulisan ulang itu sendiri mungkin menjadi alasan mengapa hasilnya lebih cepat -> kalau dipikir-pikir lagi, ini memang benar sekali...
Saya setuju dengan pendapat orang ini karena sangat selektif.
Namun, di sisi lain, menurut saya keberadaan berbagai solusi selain JS juga merupakan elemen yang sangat penting dari sudut pandang kemajuan teknologi, jadi situasi sebaliknya pun patut dihormati!
Komentar Hacker News
Ada pendapat bahwa JavaScript pada dasarnya lambat. Banyak engineer telah berupaya membuatnya lebih cepat, tetapi tetap lebih lambat daripada bahasa bertipe statis. Untuk program berskala besar, bahasa dengan tipe yang jelas lebih cocok
JavaScript tidak mudah dipelajari, serta memiliki sistem prototipe dan tipe yang kompleks. TypeScript membantu menutup kekurangan ini, tetapi tetap kompleks
Hanya dengan mengganti bahasa saja, performa dapat meningkat secara signifikan. Ada pengalaman meningkatkan performa 8-10 kali lipat saat sistem yang ada diubah dari JS dan PHP ke Go
Pentingnya pemrosesan paralel sering diabaikan. Rust cocok untuk menulis kode paralel, sedangkan JS tidak cocok untuk itu
JavaScript kini memiliki kecepatan yang mirip dengan Java, tetapi 2-4 kali lebih lambat daripada C++. Untuk meningkatkan performa, perlu keluar dari zona nyaman
Program Rust, Zig, dan Go mudah diperiksa source code-nya dan mudah dikompilasi. Mempelajari bahasa baru memengaruhi cara menyelesaikan masalah
Kemungkinan untuk meningkatkan performa tool JavaScript belum sepenuhnya habis. Namun, membangun di atas fondasi yang lebih baik lebih efisien
Rspack adalah versi penulisan ulang Webpack yang kompatibel dan ditulis dalam Rust, dengan peningkatan performa 5-10 kali lipat. Webpack dapat diganti dengan mudah
Memodifikasi dependency JavaScript secara lokal itu mudah, tetapi Rust memiliki lebih sedikit bug sehingga kebutuhan untuk memodifikasinya lebih kecil. Rust memang sulit dipelajari, tetapi lewat itu seseorang bisa menjadi programmer yang lebih baik juga dalam bahasa lain