5 yıl ve 5 milyon dolarlık ders: Web geliştirme için yeni bir programlama dili yaratmak bir hataydı | Wasp

• Y Combinator çıkışlı full-stack web framework’ü Wasp, 5 yıl boyunca kendi DSL tabanlı dilini geliştirmeyi denedikten sonra bundan vazgeçip TypeScript’e geçme kararını açıkladı
• "JS dünyasının Rails/Laravel’i" olmayı hedefleyerek React·Node.js·Prisma üzerinde uygulama spesifikasyonunu bildirimsel olarak tanımlayan bir yapıyla yola çıktı ve toplam 5 milyon doların üzerinde yatırım aldı
• "lang" son eki yüzünden JavaScript’in yerine geçen bir dil olarak algılandı; IDE desteği ve araç ekosistemi kurma yükü de beklenenden çok daha büyük çıktı
• Asıl temel değerin yeni dilin kendisi değil, derleme zamanında tüm full-stack uygulama için yüksek seviyeli bir spesifikasyonu korumak olduğu ortaya çıktı
• Yaklaşan Launch Week ile TypeScript SDK’nın varsayılan arayüz olarak resmi çıkışı planlanıyor; iç çalışma biçimi ise aynı kalacak

---

Arka plan: Neden yeni bir dil yapmak istediler?

• Wasp, 2021’de ikiz kardeşler tarafından kuruldu; Y Combinator sürecinden geçerek toplam 5 milyon doların üzerinde yatırım aldı
• İlk fikir, herhangi bir stack ile çalışabilen "genel amaçlı bir framework" oluşturmaktı ve bunun için yeni bir dil gerektiğine karar verildi
• Amaç, bulut altyapısı için Terraform’un yaptığına benzer şekilde web uygulaması stack’i için aynı soyutlamayı sağlamaktı

Stack değiştirme yorgunluğu ve tesadüfi karmaşıklık

• Eskiden Spring Boot, Django veya Rails’ten biri seçildiğinde kimlik doğrulama, routing ve state management topluca çözülüyordu
• Bugün ise React, Redux, Webpack, Express, Passport, Sequelize gibi parçaları elle birleştirip bağlamak gerekiyor
• Bunun sonucunda iş mantığından çok stack yönetimine zaman harcanıyor; bunu da "tesadüfi karmaşıklık (accidental complexity)" olarak tanımlıyorlar

"Bir kez deklarasyon yeter" yapısı fikri

• "Google·GitHub ile giriş kullanmak istiyorum", "/profile route’una yalnızca doğrulanmış kullanıcılar erişebilsin", "Her gün saat 17:00’de cron job çalışsın" gibi gereksinimleri uygulamadan bağımsız bir spesifikasyon olarak ifade etme fikri geliştirildi
• Örnek biçim
  • auth: Google, GitHub
  • page Profile -> /profile, authRequired: true
  • job updateStats: run function doSomeCalc from stats.js every day at 5pm
• Buradaki amaç mevcut stack’in yerini almak değil, mantığı React·Node.js içinde bırakıp merkezi omurgayı ayrı tutmaktı
• Temel içgörü şuydu: Web uygulaması alanı (sayfalar, route’lar, API’ler, veri modelleri) neredeyse değişmezken uygulama teknikleri hızla değişiyor

Neden mevcut bir dil yerine yeni bir dil seçildi?

• Sıfırdan yeni bir dil tasarlamalarının iki nedeni vardı
  • Sözdizimi üzerinde tam kontrol ve minimum boilerplate
  • Runtime’dan bağımsız (runtime-agnostic) araç yaklaşımı — örneğin bazı mantık Node.js’te, veri yoğun kısımlar Python’da olabilir
• Başlangıçta TypeScript tabanlı embedded DSL kullanmaları yönünde geri bildirim gelmişti, ancak o dönemde bunun vizyona ihanet gibi hissettirdiğini söylüyorlar
• Wasp’ı bağımsız bir dil olarak çıkarmanın, Rails·Django gibi dile bağımlı framework’lerden ayrışmak için daha güçlü bir mesaj vereceğini düşündüler
• Kurucuların Haskell tutkunu olduklarını ve dil/derleyici geliştirmenin başlı başına çekici bir iş olduğunu da açıkça kabul ediyorlar

Pazar tepkisi: Fikir sevildi ama dil yük oldu

• Alpha sürümden yaklaşık 1 yıl sonra ilk kullanıcı kitlesi oluştu; Y Combinator kabulü ve pre-seed yatırım da geldi
• Beta sonrasında benimsenme ciddi şekilde arttı; bunda boilerplate yorgunluğu ve stack parçalarını birleştirme yükü etkili oldu
• Benzer dönemde RedwoodJS, BlitzJS gibi "JS dünyasının Rails’i" sayılabilecek framework’ler de ortaya çıktı
• Ancak RedwoodJS’nin GraphQL’e, BlitzJS’nin ise Next.js’e güçlü biçimde bağlı olması sınırlayıcı oldu; Wasp’ın belirli bir teknolojiye bağımlı olmaması ayakta kalma nedenlerinden biri oldu

• "wasp-lang" JavaScript’in yerini mi alıyor?

  • "lang" son eki yüzünden geliştiriciler bunu otomatik olarak Rust ya da Java gibi genel amaçlı bir dil olarak algıladı
  • Gerçekte kodun %90’ı hâlâ React·Node.js ile yazılıyor, ancak konumlandırmanın kendisi yanlış anlaşılmaya yol açtı
  • Sonuç olarak "havalı görünüyor ama zamanı gelmemiş" kategorisine itildi

• Mevcut IDE ve araçlarla uyumlu mu?

  • Doğal olarak "Kendi ekosistemini de kurmak zorunda mı?" sorusu geldi
  • Geliştiriciler yeni bir standart yaratmanın ve etrafında ekosistem büyütmenin maliyetini çok iyi biliyor

• "Haskell öğrenmek istemiyorum" tepkisi

  • Derleyicinin içi Haskell ile yazılmış olsa da son kullanıcı yalnızca TypeScript kullanıyor
    • Bu yapı, Prisma core’un Rust, Terraform HCL’nin ise Go ile yazılmış olmasıyla aynı mantığa sahip
  • Haskell topluluğuna yönelik pazarlamanın fazla iyi işlemesi, Wasp’ın "Haskell tabanlı bir dil" olarak yanlış yerleşmesine neden oldu
  • GitHub deposundaki "Languages" çubuğunda "Haskell: 90%" görünmesi de bu yanlış konumlandırmayı güçlendirdi

• Paketleme sorunu

  • Ürünü gerçekten deneyen geliştiricilerin çoğu memnun kaldı; React·Node.js’i korurken hızlı çıkış yapılabildiğini gördüler
  • Ancak en zor aşama, insanları "Bu ne?" noktasından "Bir deneyeyim" noktasına getirmekti
  • Giriş bariyerini düşürmek için Wasp üzerinde açık kaynak SaaS boilerplate starter’ları ve Lovable benzeri erken dönem üst ürünler inşa ettiler
    • Bu kullanıcı çekmede etkili oldu, ancak temel sorun devam etti

• Son darbeyi vuran: IDE desteğini hayata geçirmenin zorluğu

• Sınır, kullanıcı tarafında değil iç geliştirme sürecinde görüldü
• JS ekosisteminde beklenen IDE deneyimi seviyesi çok yüksek ve IDE ile derleyici arasındaki çizgi giderek silikleşiyor
• Tüm araç ekosistemi standart JS·TS framework’leri etrafında kurulduğu için bunun dışındaki diller hemen sınıra çarpıyor
• Kendi language server’larını ve VS Code eklentilerini geliştirdiler, ancak Prisma DSL ile React·Node.js dosya referanslarını birleştirme ihtiyacı nedeniyle hedeflerinin ancak %80’ine ulaşabildiler

Kendi diliyle vedalaşma, TypeScript’e geçiş

• Benimsenme artmaya devam etse de "Neden özel bir dil var?" sorusu hiç kaybolmadı; bunu "el freni çekiliyken araba kullanmak" hissine benzetiyorlar
• Sonunda dilin sunduğu sözdizimsel avantajların düşündükleri kadar belirleyici olmadığı, geliştiricilerin ise alışık oldukları TypeScript içinde birkaç ek parantezi memnuniyetle kabul ettiği görüldü

• Gerçek hendek (moat), dil değil derleme zamanında uygulamanın bütününü anlayabilmekti

  • Kuruluşun ilk döneminde "language" ile "specification" eş anlamlı görülüyordu, ama kullanıcıların gerçekten sevdiği şey yüksek seviyeli spesifikasyon (main.wasp, şimdi main.wasp.ts) üzerinden tüm uygulamayı kavrayabilmekti
  • wasp studio komutuyla, derleme zamanında Wasp’ın uygulama yapısını nasıl algıladığı görselleştirilebiliyor
  • Yapay zeka araçları ve kod üretimi arttıkça, teknik olmayan geçmişe sahip "vibe-coder" kuşağı için bu tür yapısal desteğin değeri daha da büyüyor
  • Bu geçişte yalnızca derleyicinin "frontend" kısmı, yani spesifikasyonun tanımlanma biçimi değişiyor; iç çalışma aynı kalıyor

• TypeScript SDK — deneyden resmi ürüne

  • Deneysel önizleme olarak sunulan TypeScript SDK, yeni kullanıcıların büyük kısmı tarafından hemen benimsendi; hatta Wasp dilini hiç kullanmamış kullanıcılar da oldu
  • Kod örnekleri
    • app.page, app.route ile sayfa ve route tanımı
    • app.query ile sorgu tanımı ve entity belirtme
    • app.job ile asenkron job tanımı; PgBoss executor ve retry seçenekleri desteği
  • Geçişin pratik faydaları
    • Tüm editörlerde ek yapılandırma olmadan çalışması
    • Koşullar, döngüler ve import kullanımı — örneğin kendi file-based routing yapını kurabilme
    • Spesifikasyonu birden fazla dosyaya bölmenin kolaylaşması
    • Full Stack Modules gibi gelişmiş özellikler için zemin hazırlaması

DSL üzerine geriye dönük değerlendirme

• DSL yaklaşımı olmasaydı Wasp’ın hiç var olmayacağını kabul ediyorlar
• DSL yaklaşımı, "spesifikasyon ile uygulamanın ayrılması" vizyonuna sadık kalmayı zorunlu kıldı
• Gelecekte Python, Rust gibi başka dil ve runtime’ları destekleme ve derleme zamanında tüm uygulamayı kavrama avantajını kullanarak mimari çeşitlilik ve optimizasyon sağlama ihtimaline olan ilgi sürüyor

Yapay zeka ajanlarıyla uyum

• Yapay zekanın kod yazımındaki payı arttıkça, geliştiriciler yapısı ve görüşü net araçlara daha fazla yöneliyor
• Full-stack’in tamamını kapsayan ve her zaman tutarlılık sağlayan Wasp, bu eğilime iyi uyuyor
• Django, Rails, Laravel gibi "eski usul" monolitik framework’lerin yeniden ilgi görmesiyle aynı bağlamda değerlendiriliyor; Wasp da bunu JS ekosistemine getirmeyi hedefliyor
• Gerçekten de 10 farklı stack denedikten sonra Wasp’ı seçen geliştirici örnekleri olduğu belirtiliyor

TypeScript-First Wasp çıkışı yolda

• Önümüzdeki birkaç hafta içinde düzenlenecek Launch Week ile TypeScript SDK, Wasp’ın varsayılan kullanım biçimi olarak resmi şekilde sunulacak
• Yeni kullanıcılar artık yeni bir dil öğrenmeden, yalnızca TypeScript ile Wasp’ın tüm özelliklerinden yararlanabilecek