‏Wasp چرا زبان برنامه‌نویسی سفارشی‌اش رو کنار گذاشت؟

تیم Wasp — که داره یه فریم‌ورک فول‌استک جاوااسکریپت می‌سازه، چیزی شبیه Rails یا Laravel ولی برای اکوسیستم React و Node.js — یه پست صادقانه منتشر کرده درباره‌ی یکی از بزرگ‌ترین اشتباهات مسیرشون: ساختن یه زبان برنامه‌نویسی کاملاً سفارشی.

ایده‌ی اولیه این بود که توسعه‌دهنده‌ها بتونن نیازهای اپشون رو در یه لایه‌ی سطح‌بالا و مستقل از پیاده‌سازی تعریف کنن. مثلاً بگن «احراز هویت با Google می‌خوام» یا «این صفحه فقط برای کاربران لاگین‌کرده قابل دسترسه»، بدون این‌که درگیر جزئیات پیاده‌سازی بشن. برای این کار یه DSL (زبان مخصوص دامنه) طراحی کردن که فایل main.wasp محور اصلیش بود.

کد پایانی این DSL چنین شکلی داشت:

app todoApp {
  title: "ToDo App",
  auth: {
    userEntity: User,
    methods: { google: {}, gitHub: {}, email: {...} }
  }
}

route RootRoute { path: "/", to: MainPage }
page MainPage {
  authRequired: true,
  component: import Main from "@client/Main"
}

مشکل اصلی از جایی شروع شد که توسعه‌دهنده‌ها آدرس wasp-lang.dev رو می‌دیدن و فکر می‌کردن این یه زبان جدیده که می‌خواد جاوااسکریپت رو جایگزین کنه. بارها این سوال مطرح می‌شد: «آیا این با IDE و ابزارهای موجودم کار می‌کنه؟» و «آیا باید Haskell یاد بگیرم؟» (کامپایلر Wasp با Haskell نوشته شده، ولی کاربران هرگز باهاش روبرو نمی‌شن.)

چالش بزرگ‌تر ساخت ابزارهای IDE بود. اکوسیستم توسعه‌ی وب کاملاً برای TypeScript و JavaScript بهینه شده و هر چیز خارج از این استاندارد باید ابزارهای خودش رو از صفر بسازه. تیم Wasp یه language server و اکستنشن VS Code نوشت، اما به گفته‌ی خودشون هرگز به ۱۰۰٪ نرسیدن.

در نهایت تیم به این نتیجه رسید که ارزش اصلی Wasp هرگز «زبان» نبود؛ بلکه داشتن یه درک سطح‌بالا از کل اپ در زمان کامپایل بود. این ویژگی باعث می‌شه هم انسان و هم هوش مصنوعی بتونن ساختار اپ رو راحت‌تر بفهمن. حالا با TypeScript SDK جدید، همین قابلیت حفظ شده ولی با زبانی که توسعه‌دهنده‌ها از قبل بلدن:

const loginPage = app.page('LoginPage', {
  component: { importDefault: 'Login', from: '@src/pages/auth/Login' }
});
app.route('LoginRoute', { path: '/login', ... });

نکات کلیدی:

• Wasp یه فریم‌ورک فول‌استک برای React و Node.js هست که هدفش کاهش پیچیدگی‌های تکراری وب‌اپ‌هاست
• زبان DSL سفارشی با TypeScript جایگزین می‌شه، ولی معماری و قابلیت‌های داخلی تغییری نمی‌کنه
• مشکل اصلی DSL سفارشی، برداشت اشتباه توسعه‌دهنده‌ها و هزینه‌ی سنگین ساخت ابزارهای IDE بود
• ارزش واقعی Wasp در داشتن یه spec سطح‌بالا از کل اپ در زمان کامپایله، نه در نحوه‌ی نوشتن اون spec
• این تجربه نشون می‌ده که طراحی یه زبان جدید برای مسائل فریم‌ورک‌محور معمولاً هزینه‌اش بیشتر از فایدشه