Bài học từ 5 năm và 5 triệu USD: Tạo ra một ngôn ngữ lập trình mới cho phát triển web là một sai lầm | Wasp

• Wasp, framework web full-stack xuất thân từ Y Combinator, đã công bố quyết định từ bỏ nỗ lực phát triển ngôn ngữ riêng dựa trên DSL sau 5 năm và chuyển sang TypeScript
• Khởi đầu với mục tiêu trở thành "Rails/Laravel cho hệ JS", trên nền React·Node.js·Prisma với cấu trúc mô tả đặc tả ứng dụng theo kiểu khai báo, công ty đã huy động được tổng cộng hơn 5 triệu USD vốn đầu tư
• Hậu tố "lang" khiến nhiều người hiểu nhầm đây là ngôn ngữ thay thế JavaScript, và gánh nặng hỗ trợ IDE cùng xây dựng hệ sinh thái công cụ lớn hơn dự đoán rất nhiều
• Giá trị cốt lõi thực sự không nằm ở bản thân ngôn ngữ mới, mà ở việc duy trì đặc tả cấp cao cho toàn bộ ứng dụng full-stack tại thời điểm biên dịch
• Trong Launch Week sắp tới, Wasp dự kiến phát hành chính thức TypeScript SDK làm giao diện mặc định, trong khi cơ chế vận hành bên trong vẫn được giữ nguyên

---

Bối cảnh: Vì sao họ muốn tạo ra một ngôn ngữ mới

• Wasp được cặp anh em song sinh sáng lập vào năm 2021, đi qua Y Combinator và huy động tổng cộng hơn 5 triệu USD đầu tư
• Ý tưởng ban đầu là một "framework phổ dụng" có thể hoạt động với bất kỳ stack nào, và họ cho rằng để làm được điều đó thì cần một ngôn ngữ mới
• Mục tiêu là cung cấp cùng một lớp trừu tượng cho stack ứng dụng web, tương tự như cách Terraform làm với hạ tầng đám mây

Sự mệt mỏi vì chuyển stack và độ phức tạp ngẫu phát

• Trước đây, chỉ cần chọn một trong Spring Boot, Django hoặc Rails là có thể giải quyết đồng loạt xác thực, routing và quản lý trạng thái
• Hiện nay, lập trình viên phải tự kết hợp và nối ghép React, Redux, Webpack, Express, Passport, Sequelize...
• Vì thế, họ tốn nhiều thời gian quản lý stack hơn là viết business logic; Wasp gọi đây là "độ phức tạp ngẫu phát (accidental complexity)"

Thiết kế một cấu trúc "chỉ cần khai báo một lần"

• Họ hình dung một cách biểu đạt các yêu cầu như "muốn dùng xác thực Google và GitHub", "route /profile chỉ cho người dùng đã xác thực truy cập", hay "chạy cron job mỗi ngày lúc 5 giờ chiều" dưới dạng đặc tả (specification) không phụ thuộc cách triển khai
• Dạng ví dụ
  • auth: Google, GitHub
  • page Profile -> /profile, authRequired: true
  • job updateStats: run function doSomeCalc from stats.js every day at 5pm
• Đây không phải để thay thế stack hiện có, mà là giữ logic trong React·Node.js và đặt riêng một xương sống trung tâm
• Nhận định cốt lõi: miền ứng dụng web (page, route, API, data model) gần như không thay đổi nhiều, nhưng cách hiện thực lại thay đổi rất nhanh

Vì sao không dùng ngôn ngữ sẵn có mà chọn làm ngôn ngữ mới

• Có hai lý do để tự thiết kế ngôn ngữ từ đầu
  • Kiểm soát hoàn toàn cú pháp, giảm boilerplate tối đa
  • Hướng tới công cụ không phụ thuộc runtime (runtime-agnostic) — ví dụ: một phần logic chạy trên Node.js, phần xử lý dữ liệu chuyên sâu chạy trên Python
• Dù đã có phản hồi ban đầu gợi ý dùng embedded DSL trên nền TypeScript, họ từ chối vì khi đó điều này giống như phản bội tầm nhìn ban đầu
• Họ cho rằng phát hành Wasp như một ngôn ngữ độc lập sẽ tạo ra thông điệp khác biệt mạnh hơn so với các framework phụ thuộc ngôn ngữ như Rails hay Django
• Các nhà sáng lập cũng thẳng thắn thừa nhận họ yêu thích Haskell, và bản thân việc xây dựng ngôn ngữ cùng compiler là một công việc đầy hấp dẫn

Phản ứng thị trường: Mọi người thích ý tưởng, nhưng phải gồng mình với ngôn ngữ

• Khoảng 1 năm sau khi ra mắt alpha, Wasp đã hình thành nhóm người dùng đầu tiên, được nhận vào Y Combinator và gọi được vòng pre-seed
• Sau beta, tỷ lệ chấp nhận tăng rõ rệt; sự mệt mỏi với boilerplate và việc ghép nối stack là động lực lớn
• Cùng thời điểm đó, những framework kiểu "Rails cho hệ JS" như RedwoodJS và BlitzJS cũng xuất hiện
• Tuy nhiên, RedwoodJS bị gắn chặt với GraphQL còn BlitzJS phụ thuộc mạnh vào Next.js; việc Wasp không bị khóa vào một công nghệ cụ thể là yếu tố giúp họ tồn tại

• "wasp-lang" có phải là ngôn ngữ thay thế JavaScript không?

  • Vì hậu tố "lang", lập trình viên tự động hiểu nó như một ngôn ngữ phổ dụng kiểu Rust hay Java
  • Trên thực tế, 90% mã vẫn được viết bằng React·Node.js, nhưng cách định vị sản phẩm lại gây hiểu nhầm
  • Kết quả là Wasp bị xếp vào nhóm "trông ngầu đấy nhưng còn quá sớm"

• Nó có tương thích với IDE và công cụ hiện có không

  • Câu hỏi "có phải họ còn phải xây cả hệ sinh thái riêng không" xuất hiện gần như ngay lập tức
  • Lập trình viên hiểu rất rõ chi phí của việc tạo ra một chuẩn mới và nuôi lớn một hệ sinh thái

• Phản ứng kiểu "tôi không muốn học Haskell"

  • Dù compiler nội bộ được viết bằng Haskell, người dùng cuối chỉ dùng TypeScript
    • Cấu trúc này tương tự việc lõi Prisma viết bằng Rust hay Terraform HCL được viết bằng Go
  • Việc marketing đến cộng đồng Haskell lại hiệu quả quá mức, khiến Wasp bị đóng khung sai thành một "ngôn ngữ dựa trên Haskell"
  • Thanh "Languages" trên kho GitHub hiển thị "Haskell: 90%" cũng càng củng cố cách định vị sai này

• Vấn đề đóng gói sản phẩm

  • Phần lớn lập trình viên đã thử thì đều hài lòng, xác nhận rằng họ có thể ra mắt nhanh mà vẫn giữ React·Node.js
  • Nhưng bước khó nhất là khiến người ta đi từ "tôi không hiểu cái này là gì" sang "để tôi thử xem"
  • Để hạ thấp rào cản gia nhập, Wasp đã xây dựng các sản phẩm tầng trên như starter SaaS boilerplate mã nguồn mở hay một dạng Lovable đời đầu trên nền Wasp
    • Dù có hiệu quả trong việc kéo người dùng vào, vấn đề cốt lõi vẫn còn nguyên

• Đòn quyết định: độ khó của việc triển khai hỗ trợ IDE

• Họ chạm trần không phải ở phía người dùng mà ngay trong quy trình phát triển nội bộ
• Mức kỳ vọng về trải nghiệm IDE trong hệ sinh thái JS là cực cao, và ranh giới giữa IDE với compiler ngày càng mờ đi
• Toàn bộ hệ sinh thái công cụ được xây trên các framework JS·TS tiêu chuẩn, nên mọi ngôn ngữ nằm ngoài quỹ đạo đó lập tức chạm giới hạn
• Họ đã phát triển language server riêng và extension cho VS Code, nhưng khi phải kết hợp cả Prisma DSL lẫn tham chiếu tới file React·Node.js, kết quả vẫn chỉ đạt khoảng 80% mục tiêu

Chia tay ngôn ngữ riêng, chuyển sang TypeScript

• Dù mức độ chấp nhận vẫn tăng, câu hỏi "vì sao phải có ngôn ngữ riêng" chưa bao giờ biến mất; họ ví điều này như "lái xe trong khi vẫn kéo phanh tay"
• Cuối cùng, lợi thế cú pháp mà ngôn ngữ mang lại không mang tính quyết định như họ từng nghĩ, còn lập trình viên thì sẵn sàng chấp nhận vài dấu ngoặc bổ sung nếu được dùng TypeScript quen thuộc

• Moat thực sự không nằm ở ngôn ngữ, mà ở khả năng hiểu toàn bộ ứng dụng tại thời điểm biên dịch

  • Ở giai đoạn đầu khởi nghiệp, họ từng xem "language" và "specification" là đồng nghĩa, nhưng điều người dùng thực sự thích lại là khả năng nắm toàn bộ ứng dụng thông qua đặc tả cấp cao (main.wasp, nay là main.wasp.ts)
  • Với lệnh wasp studio, có thể trực quan hóa cách Wasp nhận diện cấu trúc ứng dụng tại thời điểm biên dịch
  • Khi công cụ AI và sinh mã tự động ngày càng phổ biến, giá trị của kiểu hỗ trợ có cấu trúc này càng tăng với thế hệ "vibe-coders" không xuất thân kỹ thuật
  • Lần chuyển đổi này chỉ thay phần "frontend" của compiler (cách định nghĩa đặc tả), còn cơ chế bên trong vẫn được giữ nguyên

• TypeScript SDK — từ thử nghiệm thành sản phẩm chính thức

  • TypeScript SDK từng được giới thiệu dưới dạng preview thử nghiệm, và rất nhiều người dùng mới đã chấp nhận nó ngay; thậm chí có người chưa từng dùng ngôn ngữ Wasp lần nào
  • Ví dụ mã
    • app.page, app.route để định nghĩa page và route
    • app.query để định nghĩa query, có thể chỉ định entities
    • app.job để định nghĩa job bất đồng bộ, hỗ trợ PgBoss executor và tùy chọn retry
  • Lợi ích thực tế của việc chuyển đổi
    • Hoạt động trên mọi trình soạn thảo mà không cần cấu hình riêng
    • Có thể dùng câu lệnh điều kiện, vòng lặp, import — ví dụ: tự triển khai file-based routing
    • Dễ chia đặc tả thành nhiều file
    • Tạo nền tảng cho các tính năng nâng cao như Full Stack Modules

Nhìn lại về DSL

• Họ thừa nhận rằng nếu không có cách tiếp cận DSL thì có lẽ Wasp đã không tồn tại
• Cách tiếp cận DSL buộc họ phải trung thành với tầm nhìn "tách đặc tả khỏi triển khai"
• Về sau, họ vẫn quan tâm tới khả năng hỗ trợ các ngôn ngữ và runtime khác như Python, Rust, cũng như đa dạng hóa và tối ưu hóa kiến trúc nhờ tận dụng khả năng nắm toàn bộ ứng dụng tại thời điểm biên dịch

Sự phù hợp với AI agent

• Khi AI đảm nhận tỷ trọng viết mã ngày càng lớn, lập trình viên có xu hướng ưa chuộng các công cụ có cấu trúc và quan điểm rõ ràng hơn
• Wasp, với khả năng bao quát toàn bộ full-stack và luôn đảm bảo tính nhất quán, phù hợp với xu hướng này
• Đây cũng là cùng một bối cảnh khiến các framework monolithic "kiểu cũ" như Django, Rails, Laravel được nhìn nhận lại; Wasp muốn mang điều đó tới hệ sinh thái JS
• Thực tế đã có trường hợp lập trình viên thử tới 10 stack rồi cuối cùng chọn Wasp

Báo trước màn ra mắt Wasp ưu tiên TypeScript

• Trong vài tuần tới, thông qua Launch Week, Wasp sẽ chính thức phát hành TypeScript SDK như cách sử dụng mặc định của Wasp
• Người dùng mới sẽ có thể dùng toàn bộ tính năng của Wasp chỉ với TypeScript, không cần học thêm ngôn ngữ mới