5 साल और 50 लाख डॉलर से मिले सबक: वेब डेवलपमेंट के लिए नई programming language बनाना एक गलती थी | Wasp

• Y Combinator से निकले full-stack web framework Wasp ने 5 साल तक अपनी DSL-आधारित language विकसित करने की कोशिश के बाद इसे छोड़कर TypeScript पर जाने का फैसला सार्वजनिक किया
• "JS के लिए Rails/Laravel" बनने के लक्ष्य के साथ इसकी शुरुआत React·Node.js·Prisma के ऊपर app specification को declaratively लिखने वाली संरचना से हुई, और इसने कुल 50 लाख डॉलर से अधिक का निवेश जुटाया
• "lang" suffix की वजह से इसे JavaScript की जगह लेने वाली language समझा गया, और IDE support व tooling ecosystem बनाने का बोझ अनुमान से कहीं अधिक बड़ा निकला
• असली core value नई language में नहीं, बल्कि compile time पर पूरे full-stack app के लिए high-level specification बनाए रखने में थी
• आगे Launch Week के जरिए TypeScript SDK को default interface के रूप में औपचारिक रूप से जारी किया जाएगा, जबकि अंदरूनी कामकाज वही रहेगा

---

पृष्ठभूमि: नई language बनाने की कोशिश क्यों की गई

• Wasp की स्थापना 2021 में जुड़वां भाइयों ने की, Y Combinator से गुजरते हुए कुल 50 लाख डॉलर से अधिक निवेश जुटाया
• शुरुआती सोच एक ऐसा "general-purpose framework" बनाने की थी जो किसी भी stack के साथ काम कर सके, और इसके लिए नई language ज़रूरी मानी गई
• लक्ष्य यह था कि cloud infrastructure के लिए Terraform जैसा abstraction, web app stack के लिए भी दिया जाए

stack बदलने की थकान और accidental complexity

• पहले Spring Boot, Django, Rails में से एक चुनने पर authentication, routing, state management जैसी चीजें एक साथ हल हो जाती थीं
• अब React, Redux, Webpack, Express, Passport, Sequelize आदि को खुद जोड़ना और integrate करना पड़ता है
• इसकी वजह से business logic से अधिक समय stack management में जाता है, जिसे इसने "accidental complexity" कहा

"एक बार declare करो" वाली संरचना की कल्पना

• "Google·GitHub authentication चाहिए", "/profile route पर सिर्फ authenticated user जा सके", "हर दिन शाम 5 बजे cron job चले" जैसी जरूरतों को implementation-independent specification के रूप में व्यक्त करने का तरीका सोचा गया
• उदाहरण
  • auth: Google, GitHub
  • page Profile -> /profile, authRequired: true
  • job updateStats: run function doSomeCalc from stats.js every day at 5pm
• यह मौजूदा stack को replace करने के लिए नहीं, बल्कि logic को React·Node.js में रखते हुए central backbone को अलग रखने की संरचना थी
• मुख्य insight यह था कि web app domain (page, route, API, data model) लगभग नहीं बदलता, लेकिन implementation technique तेज़ी से बदलती है

मौजूदा language की जगह नई language क्यों चुनी गई

• शुरू से नई language design करने के दो कारण थे
  • syntax पर पूरा control, ताकि boilerplate कम से कम हो
  • runtime-agnostic tooling की दिशा — जैसे कुछ logic Node.js में, data-heavy हिस्सा Python में
• शुरुआती feedback में TypeScript-आधारित embedded DSL अपनाने का सुझाव भी था, लेकिन तब इसे अपनी vision से समझौता मानकर ठुकरा दिया गया
• Wasp को एक standalone language के रूप में जारी करना, Rails·Django जैसे language-bound frameworks से अलग पहचान देने के लिए अधिक मजबूत संदेश माना गया
• संस्थापकों ने ईमानदारी से माना कि वे Haskell के प्रशंसक थे, और language व compiler बनाना खुद में आकर्षक काम था

बाज़ार की प्रतिक्रिया: idea पसंद आया, लेकिन language का बोझ उठाना पड़ा

• alpha release के करीब 1 साल के भीतर शुरुआती user base बना, Y Combinator में चयन हुआ और pre-seed round भी मिला
• beta के बाद adoption तेज़ी से बढ़ा, जिसमें boilerplate fatigue और stack-composition fatigue बड़े कारण रहे
• इसी दौर में RedwoodJS, BlitzJS जैसे "JS के लिए Rails" framework भी सामने आए
• लेकिन RedwoodJS का GraphQL से और BlitzJS का Next.js से गहरा जुड़ाव उसकी सीमा बना, जबकि Wasp का किसी खास technology पर निर्भर न होना उसके टिके रहने का कारण बना

• क्या "wasp-lang" JavaScript को replace करता है?

  • "lang" suffix की वजह से developers इसे अपने-आप Rust·Java जैसी general-purpose language समझ लेते थे
  • जबकि वास्तविकता यह थी कि code का 90% अब भी React·Node.js में लिखा जाता था, लेकिन positioning ही गलतफहमी पैदा करती थी
  • नतीजा यह हुआ कि इसे "दिखने में cool, लेकिन अभी समय से पहले" वाली श्रेणी में डाल दिया गया

• क्या यह मौजूदा IDE और tools के साथ compatible है

  • इसके साथ स्वाभाविक रूप से यह सवाल आता था कि "क्या अब अपना ecosystem भी बनाना पड़ेगा?"
  • developers अच्छी तरह जानते हैं कि नया standard और ecosystem खड़ा करने की लागत कितनी बड़ी होती है

• "Haskell सीखना नहीं है" वाली प्रतिक्रिया

  • compiler का अंदरूनी हिस्सा Haskell में लिखा गया है, लेकिन अंतिम user सिर्फ TypeScript इस्तेमाल करता है
    • यह वैसा ही ढांचा है जैसे Prisma core Rust में और Terraform HCL Go में लिखा गया है
  • Haskell community को target करने वाली marketing इतनी सफल रही कि Wasp को "Haskell-आधारित language" मान लिया गया
  • GitHub repository की "Languages" bar में "Haskell: 90%" दिखना भी इस गलत positioning को और मजबूत करता था

• packaging की समस्या

  • जिन्होंने इसे सच में इस्तेमाल किया, वे ज़्यादातर संतुष्ट रहे और React·Node.js को बनाए रखते हुए तेज़ी से launch करना संभव पाया
  • लेकिन "यह आखिर है क्या" से "एक बार try करते हैं" तक ले जाना सबसे मुश्किल चरण था
  • entry barrier कम करने के लिए Wasp के ऊपर open source SaaS boilerplate starter और शुरुआती रूप के Lovable जैसे upper-layer products बनाए गए
    • इससे user acquisition में मदद मिली, लेकिन core समस्या बनी रही

• निर्णायक मोड़: IDE support लागू करने की कठिनाई

• सीमा users नहीं, बल्कि internal development process में आकर सामने आई
• JS ecosystem में अपेक्षित IDE experience का स्तर बहुत ऊँचा है, और IDE व compiler के बीच की रेखा धुंधली हो चुकी है
• पूरा tooling ecosystem standard JS·TS framework पर बना है, इसलिए उससे अलग कोई language तुरंत सीमाओं से टकराती है
• अपना language server और VS Code extension बनाने के बावजूद, Prisma DSL और React·Node.js file references को साथ जोड़ने पर भी लक्ष्य का सिर्फ लगभग 80% ही हासिल हो सका

अपनी language को अलविदा, TypeScript की ओर बदलाव

• adoption बढ़ता रहा, लेकिन "अपनी language की ज़रूरत क्यों है" यह सवाल खत्म नहीं हुआ; इसे संस्थापकों ने "जैसे handbrake खींचकर गाड़ी चलाना" कहा
• आखिरकार language से मिलने वाले syntax-level फायदे उतने निर्णायक नहीं निकले, और developers परिचित TypeScript में कुछ अतिरिक्त brackets स्वीकार करने को तैयार थे

• असली moat language नहीं, compile time पर app की पूरी समझ है

  • शुरुआत में संस्थापकों ने "language" और "specification" को लगभग एक ही माना था, लेकिन users को वास्तव में पसंद आया high-level specification (main.wasp, अब main.wasp.ts) के जरिए पूरे app को समझ पाना
  • wasp studio command से यह visualize किया जा सकता है कि compile time पर Wasp app structure को कैसे समझता है
  • AI tools और code generation बढ़ने के साथ, non-technical background वाले "vibe-coders" के लिए इस तरह का structural support और भी मूल्यवान हो रहा है
  • इस बदलाव में compiler के सिर्फ "frontend" यानी specification define करने का तरीका बदला जा रहा है, अंदरूनी कामकाज वही रहेगा

• TypeScript SDK — experiment से औपचारिक product तक

  • experimental preview के रूप में लाया गया TypeScript SDK कई नए users ने तुरंत अपना लिया, और कुछ ने Wasp language का उपयोग किए बिना ही शुरुआत की
  • code उदाहरण
    • app.page, app.route से page·route define करना
    • app.query से query define करना, entities specify की जा सकती हैं
    • app.job से async jobs define करना, PgBoss executor और retry options का support
  • इस बदलाव के व्यावहारिक फायदे
    • हर editor में बिना अलग setup के काम
    • conditionals, loops, import का उपयोग — जैसे अपना file-based routing implement करना
    • specification को कई files में बाँटना आसान
    • Full Stack Modules जैसे advanced features की नींव तैयार

DSL पर पुनर्विचार

• इसने माना कि DSL approach न होती तो शायद Wasp का अस्तित्व ही न होता
• DSL approach ने "specification और implementation को अलग रखने" वाली vision के प्रति ईमानदार बनाए रखा
• आगे Python, Rust जैसी अन्य language·runtime support, और compile time पर पूरे app की समझ का उपयोग करके architecture diversification और optimization की संभावनाओं में रुचि बनी हुई है

AI agents के साथ अनुकूलता

• AI के code लिखने में बढ़ती भूमिका के साथ, developers ऐसे tools पसंद कर रहे हैं जिनकी structure और opinion साफ़ हो
• Wasp, जो पूरे full-stack को कवर करता है और लगातार consistency बनाए रखता है, इस प्रवृत्ति के लिए उपयुक्त माना जा रहा है
• Django, Rails, Laravel जैसे "पुराने" monolithic frameworks के फिर से चर्चा में आने का यही संदर्भ है, और Wasp इसे JS ecosystem में लाना चाहता है
• वास्तव में एक developer का उदाहरण भी है जिसने 10 stack आज़माने के बाद Wasp चुना

TypeScript-First Wasp launch की घोषणा

• आने वाले कुछ हफ्तों में Launch Week के जरिए TypeScript SDK को Wasp इस्तेमाल करने का default तरीका बनाकर औपचारिक रूप से जारी किया जाएगा
• नए users नई language सीखे बिना सिर्फ TypeScript से Wasp की सभी सुविधाएँ इस्तेमाल कर सकेंगे