Pelajaran dari 5 Tahun dan 5 Juta Dolar: Membuat Bahasa Pemrograman Baru untuk Pengembangan Web Adalah Kesalahan | Wasp

• Wasp, framework web full-stack lulusan Y Combinator, mengungkap keputusan untuk menghentikan upaya 5 tahun mengembangkan bahasa berbasis DSL internal mereka dan beralih ke TypeScript
• Berawal dengan visi sebagai "Rails/Laravel versi JS", Wasp dibangun di atas React·Node.js·Prisma dengan struktur yang memungkinkan spesifikasi aplikasi ditulis secara deklaratif, dan berhasil menghimpun investasi lebih dari 5 juta dolar
• Sufiks "lang" membuatnya disalahpahami sebagai bahasa pengganti JavaScript, dan beban membangun dukungan IDE serta ekosistem alat ternyata jauh lebih besar dari perkiraan
• Nilai inti yang sebenarnya bukanlah bahasa baru itu sendiri, melainkan kemampuan mempertahankan spesifikasi tingkat tinggi untuk seluruh aplikasi full-stack pada saat compile-time
• Ke depan, melalui Launch Week, Wasp akan merilis resmi TypeScript SDK sebagai antarmuka default, sementara cara kerja internalnya tetap dipertahankan

---

Latar belakang: mengapa ingin membuat bahasa baru

• Wasp didirikan pada 2021 oleh dua saudara kembar, lolos Y Combinator, dan total menghimpun investasi lebih dari 5 juta dolar
• Gagasan awalnya adalah menjadi "framework serbaguna" yang bisa bekerja dengan stack apa pun, dan untuk itu mereka menilai perlu ada bahasa baru
• Seperti Terraform untuk infrastruktur cloud, tujuannya adalah menyediakan abstraksi yang sama untuk stack aplikasi web

Kelelahan karena pergantian stack dan kompleksitas insidental

• Dulu, memilih salah satu dari Spring Boot, Django, atau Rails berarti autentikasi, routing, dan state management bisa langsung terselesaikan
• Sekarang, React, Redux, Webpack, Express, Passport, Sequelize, dan lainnya harus dirangkai serta dihubungkan sendiri
• Akibatnya, lebih banyak waktu habis untuk mengelola stack daripada logika bisnis, yang mereka sebut sebagai "kompleksitas insidental (accidental complexity)"

Merancang struktur "cukup deklarasikan sekali"

• Mereka membayangkan cara untuk mengekspresikan kebutuhan seperti "ingin memakai autentikasi Google·GitHub", "route /profile hanya bisa diakses pengguna yang sudah login", atau "jalankan cron job setiap hari pukul 5 sore" sebagai spesifikasi (specification) yang tidak bergantung pada implementasi
• Contoh bentuknya
  • auth: Google, GitHub
  • page Profile -> /profile, authRequired: true
  • job updateStats: run function doSomeCalc from stats.js every day at 5pm
• Bukan menggantikan stack yang ada, melainkan membiarkan logika tetap berada di React·Node.js sambil memisahkan tulang punggung utamanya
• Wawasan utamanya: domain aplikasi web (halaman, route, API, model data) hampir tidak berubah, tetapi teknik implementasinya berubah sangat cepat

Mengapa memilih bahasa baru, bukan bahasa yang sudah ada

• Ada dua alasan mereka merancang bahasa baru dari nol
  • Kontrol penuh atas sintaks, sehingga boilerplate bisa diminimalkan
  • Berorientasi pada alat yang agnostik terhadap runtime (runtime-agnostic) — misalnya sebagian logika berjalan di Node.js, sementara bagian intensif data berjalan di Python
• Sempat ada masukan awal untuk memakai embedded DSL berbasis TypeScript, tetapi saat itu ditolak karena terasa seperti mengkhianati visi awal
• Mereka menilai meluncurkan Wasp sebagai bahasa independen akan memberi pesan pembeda yang lebih kuat dibanding framework yang bergantung pada bahasa seperti Rails atau Django
• Para pendirinya juga jujur mengakui bahwa mereka penggemar Haskell, dan pembuatan bahasa serta compiler itu sendiri adalah pekerjaan yang sangat menarik bagi mereka

Respons pasar: idenya disukai, tetapi bahasanya harus ditanggung

• Sekitar 1 tahun setelah rilis alpha, mulai terbentuk basis pengguna awal, lalu Wasp diterima di Y Combinator dan mendapatkan pendanaan pre-seed
• Setelah beta, tingkat adopsi meningkat nyata, didorong oleh kelelahan terhadap boilerplate dan repotnya merangkai stack
• Pada periode yang mirip, framework seperti RedwoodJS dan BlitzJS yang disebut sebagai "Rails versi JS" juga mulai bermunculan
• Namun RedwoodJS terlalu terikat pada GraphQL, sementara BlitzJS sangat bergantung pada Next.js; Wasp bertahan karena tidak terkunci pada teknologi tertentu

• Apakah "wasp-lang" menggantikan JavaScript?

  • Karena sufiks "lang", developer otomatis menganggapnya sebagai bahasa serbaguna seperti Rust atau Java
  • Padahal dalam praktiknya, 90% kode tetap ditulis dengan React·Node.js, tetapi positioning-nya sendiri memicu salah paham
  • Akibatnya, Wasp masuk ke kategori persepsi "terlihat keren, tapi terlalu dini untuk dipakai"

• Apakah kompatibel dengan IDE dan alat yang sudah ada

  • Pertanyaan seperti "apakah mereka juga harus membangun ekosistemnya sendiri" pun muncul secara alami
  • Developer sudah sangat paham betapa mahalnya biaya membuat standar baru dan menumbuhkan ekosistem

• Respons "saya tidak ingin belajar Haskell"

  • Compiler internal memang ditulis dalam Haskell, tetapi pengguna akhir hanya memakai TypeScript
    • Strukturnya sama seperti Prisma core yang ditulis dengan Rust, atau Terraform HCL yang ditulis dengan Go
  • Pemasaran ke komunitas Haskell terlalu berhasil, sehingga Wasp keliru melekat sebagai "bahasa berbasis Haskell"
  • Bar "Languages" di repositori GitHub yang menampilkan "Haskell: 90%" juga memperkuat positioning yang salah

• Masalah packaging

  • Developer yang benar-benar mencobanya umumnya puas, dan bisa melihat bahwa mereka tetap memakai React·Node.js sambil merilis lebih cepat
  • Namun tahap tersulit adalah membawa orang dari "saya tidak paham ini apa" ke "saya mau coba sekali"
  • Untuk menurunkan hambatan masuk, mereka membangun produk lapisan atas di atas Wasp seperti starter SaaS boilerplate open-source dan produk tingkat awal mirip Lovable
    • Ini efektif untuk mendatangkan pengguna, tetapi masalah intinya tetap ada

• Penentu akhirnya: sulitnya mewujudkan dukungan IDE

• Batasannya bukan muncul pada pengguna, melainkan dalam proses pengembangan internal
• Di ekosistem JS, standar pengalaman IDE yang dibutuhkan sangat tinggi, dan batas antara IDE dengan compiler makin kabur
• Seluruh ekosistem alat dibangun di atas framework JS·TS standar, sehingga bahasa lain langsung menemui batas
• Mereka sempat mengembangkan language server sendiri dan ekstensi VS Code, tetapi karena harus digabung dengan Prisma DSL serta referensi file React·Node.js, hasilnya hanya mencapai sekitar 80% dari target

Berpisah dengan bahasa sendiri, beralih ke TypeScript

• Adopsi terus meningkat, tetapi pertanyaan "mengapa harus bahasa sendiri" tidak pernah hilang, dianalogikan seperti "mengemudi sambil menarik rem tangan"
• Pada akhirnya, keunggulan sintaks dari bahasa itu ternyata tidak sedeterminatif yang dibayangkan, dan developer bersedia menerima TypeScript yang sudah akrab meski harus menambah beberapa kurung

• Parit pertahanan (moat) yang sebenarnya bukan bahasa, melainkan pemahaman aplikasi secara menyeluruh pada compile-time

  • Di awal pendirian, mereka menganggap "language" dan "specification" sebagai sinonim, tetapi yang benar-benar disukai pengguna adalah kemampuan memahami seluruh aplikasi lewat spesifikasi tingkat tinggi (main.wasp, kini main.wasp.ts)
  • Dengan perintah wasp studio, struktur aplikasi sebagaimana dikenali Wasp saat compile-time bisa divisualisasikan
  • Seiring makin banyaknya alat AI dan pembuatan kode otomatis, nilai dukungan struktural seperti ini makin besar bagi generasi "vibe-coders" dari latar belakang nonteknis
  • Dalam transisi ini, yang diganti hanya "frontend" compiler (cara mendefinisikan spesifikasi), sedangkan cara kerja internal tetap sama

• TypeScript SDK — dari eksperimen menjadi produk resmi

  • TypeScript SDK yang diperkenalkan sebagai preview eksperimental langsung diadopsi banyak pengguna baru, bahkan ada yang belum pernah memakai bahasa Wasp sama sekali
  • Contoh kode
    • app.page, app.route untuk mendefinisikan halaman dan route
    • app.query untuk mendefinisikan query, dengan kemungkinan menentukan entities
    • app.job untuk mendefinisikan job asinkron, mendukung executor PgBoss dan opsi retry
  • Manfaat praktis dari transisi ini
    • Bekerja di semua editor tanpa pengaturan tambahan
    • Bisa memakai conditional, loop, dan import — misalnya untuk membuat file-based routing sendiri
    • Lebih mudah membagi spesifikasi ke beberapa file
    • Menjadi fondasi bagi fitur lanjutan seperti Full Stack Modules

Kilas balik tentang DSL

• Mereka mengakui bahwa tanpa pendekatan DSL, Wasp sendiri mungkin tidak akan pernah ada
• Pendekatan DSL memaksa mereka tetap setia pada visi "pemisahan spesifikasi dan implementasi"
• Minat terhadap kemungkinan mendukung bahasa dan runtime lain seperti Python atau Rust, serta diversifikasi dan optimisasi arsitektur dengan memanfaatkan pemahaman seluruh aplikasi pada compile-time, tetap dipertahankan

Kecocokan dengan agen AI

• Saat AI mengambil porsi lebih besar dalam penulisan kode, developer makin cenderung menyukai alat dengan struktur dan opini yang jelas
• Wasp, yang mencakup seluruh full-stack dan selalu menjaga konsistensi, cocok dengan arus ini
• Ini sejalan dengan fenomena framework monolitik "jadul" seperti Django, Rails, dan Laravel yang kembali mendapat perhatian; Wasp ingin menghadirkan hal serupa di ekosistem JS
• Ada pula kasus nyata developer yang memilih Wasp setelah mencoba 10 stack berbeda

Pengumuman peluncuran Wasp yang mengutamakan TypeScript

• Dalam beberapa minggu ke depan, melalui Launch Week, Wasp akan merilis resmi TypeScript SDK sebagai cara default menggunakan Wasp
• Pengguna baru nantinya bisa memanfaatkan seluruh fitur Wasp hanya dengan TypeScript, tanpa perlu mempelajari bahasa baru