- Seorang insinyur Google mempresentasikan proposal kepada komite standardisasi resmi untuk memecah JavaScript menjadi dua bahasa
- Diusulkan untuk membaginya menjadi inti yang diimplementasikan di mesin runtime dan varian dengan lebih banyak fitur yang bergantung pada alat yang mengompilasinya
- Presentasi dilakukan awal bulan ini pada rapat Ecma TC39
- TC39 adalah komite Ecma International yang mengembangkan spesifikasi JavaScript (secara resmi ECMAScript)
- Presentasi dibawakan oleh Shu-yu Guo dari Google, dan slide disusun bersama rekan penulis dari Mozilla, Apple, Moddable, dan Sony
- Shu-yu adalah ahli JIT, VM, compiler, dan standardisasi
- Argumen para penulis
- Fitur baru dalam bahasa hampir selalu memperburuk keamanan, serta berdampak netral atau negatif pada performa
- Stabilitas kadang juga memburuk, dan fungsionalitas aplikasi hanya meningkat jika pengembang benar-benar menggunakan fitur baru
- VM JavaScript (mesin virtual) sudah menjadi sangat kompleks karena tekanan terhadap kecepatan, dan ini mengorbankan keamanan. Ini juga tampak makin buruk terutama ketika fitur baru tidak diadopsi
- Cacat keamanan dan 'biaya kompleksitas' runtime memengaruhi miliaran penggunaan, sedangkan manfaatnya pada praktiknya terbatas pada pengembang dan aplikasi yang benar-benar memanfaatkan kompleksitas tersebut, sehingga teknologi dasar JavaScript seharusnya tetap sederhana
- Meskipun melibatkan beberapa organisasi, inisiatif ini tampaknya sampai tingkat tertentu dipimpin oleh Google
- Salah satu slide memuat disclaimer bahwa "solusi yang memungkinkan ini adalah solusi yang disukai Google dan belum tentu solusi para implementer lain"
- Solusi yang diusulkan
- Bukan memutar balik fitur yang sudah ada, melainkan mengubah pendekatan ke depan sehingga sebagian besar fitur baru diimplementasikan di alat, bukan di engine
- Bahasa yang diimplementasikan di engine disebut "JS0", dan bahasa yang diimplementasikan di alat disebut "JSSugar"
- Ini dianggap ide yang sangat cocok untuk JavaScript karena banyak pengembang pada praktiknya menulis kode dalam TypeScript dan bergantung pada compiler seperti Babel, Webpack, dan compiler TypeScript
- Jika diadopsi, fitur sintaks masa depan akan masuk ke JSSugar, sedangkan hanya API dan fitur fungsional yang masuk ke JS0
- Engine yang kompatibel cukup mendukung JS0 saja
- Beban tersebut akan dialihkan ke implementer alat untuk mendukung JSSugar
- Sebagai efek samping, implementer alat perlu lebih terlibat dalam proses standardisasi dan mungkin perlu membentuk kelompok teknis baru
- Proposal ini sudah menimbulkan kontroversi
- Ada pengembang yang meminta agar alat JavaScript tidak diberi status resmi, dan banyak pengembang JavaScript ingin lebih sedikit bergantung pada alat-alat tersebut
- Ada kesepakatan luas untuk memprioritaskan keamanan, performa, dan stabilitas, tetapi gagasan menjadikan JavaScript bergantung pada alat perantara tidak populer
- Seorang pengembang bahkan berkata, "RIP Vanilla JS"
Opini GN⁺
- Proposal ini dapat membawa perubahan besar pada ekosistem pengembangan JavaScript. Ada kekhawatiran karena pengembang harus lebih bergantung pada compiler untuk menggunakan fitur sintaks baru
- Namun, tujuan untuk mengurangi kompleksitas engine runtime serta meningkatkan keamanan dan performa itu sendiri bersifat positif. Dalam jangka panjang, ini bisa membantu perkembangan JavaScript
- Bahasa lain yang mengambil pendekatan serupa adalah Dart. Dart menyediakan sintaks yang ramah pengembang sambil tetap dikompilasi ke JavaScript untuk dijalankan di browser
- Saat mempertimbangkan adopsi proposal ini, berbagai faktor seperti kompatibilitas dengan kode lama, pengalaman pengembang, dan dukungan alat perlu dipertimbangkan dengan saksama. Selain itu, proses yang cukup untuk menyerap pendapat komunitas juga akan diperlukan
- Karena JavaScript adalah bahasa fondasi pengembangan web, diskusi dan perkembangan aktif kemungkinan akan terus berlanjut
4 komentar
Sepertinya mereka ingin menambahkan satu lapisan lagi, lalu menambahkan hal-hal yang membantu DX di lapisan tersebut.
Bahkan JSX sendiri sejak awal membangun ekosistem yang mengharuskan transpiling, jadi menurut saya ini pendapat yang tidak realistis. Sepertinya mereka menganggap NodeJS adalah segalanya.
Saya tidak yakin apakah saya memahaminya dengan tepat, tetapi di C++ ada yang namanya BOOST, dan rasanya mirip seperti itu. Jika usulan Google disetujui dan pustaka-pustaka yang sudah ada diintegrasikan ke JSSugar, apa yang akan masuk? Babel?
Opini Hacker News
Hotspot VM milik Java telah membawa kesuksesan besar bagi bahasa-bahasa lain. Masuk akal jika JavaScript juga menargetkan bahasa inti dengan cara serupa, lalu melakukan pra-kompilasi untuk
syntactic sugarLebih baik fokus pada WebAssembly. JavaScript seharusnya digunakan untuk scripting, sedangkan bahasa lain dipakai untuk aplikasi yang lebih besar
Sebagai orang yang lebih menyukai VanillaJS, ada ketidakpuasan terhadap fitur bahasa yang berubah secara paksa. Fokus seharusnya pada perbaikan API agar web app bisa setara dengan aplikasi native
Tidak setuju dengan klaim bahwa tidak ada use case untuk BigInt. Meski developer frontend Google mungkin tidak menggunakannya, developer JS lain tetap memakainya. Fokus seharusnya pada perkembangan bahasa
JavaScript dan Wasm seharusnya dipisahkan. Sebaliknya, Wasm justru dijadikan warga kelas dua yang tidak bisa mengakses web API
Solusi yang diusulkan tidak menyelesaikan masalah mendasar, dan malah membuat orang bergantung pada tool. JavaScript seharusnya beralih ke bahasa baru untuk mengurangi masalah performa dan kompleksitas
Masalah muncul karena ada jarak antara TC39 dan komunitas developer. Tool TypeScript tidak distandardisasi, dan juga tidak ada rencana untuk mem-port-nya ke Rust
Perubahan pada JavaScript diusulkan karena masalah pemeliharaan engine V8 milik Google. Masalah keamanan dan biaya kompleksitas berdampak pada pengguna. Perlu mencoba bahasa lain selain C++