บทเรียนจากเวลา 5 ปีและเงิน 5 ล้านดอลลาร์: การสร้างภาษาโปรแกรมใหม่สำหรับพัฒนาเว็บคือความผิดพลาด | Wasp

• Wasp เฟรมเวิร์กฟูลสแตกสำหรับเว็บจากสาย Y Combinator เปิดเผยการตัดสินใจเลิกพัฒนาภาษาของตัวเองที่อิงกับ DSL เฉพาะทาง หลังพยายามมา 5 ปี และหันไปใช้ TypeScript แทน
• เริ่มต้นจากแนวคิด "Rails/Laravel ฉบับ JS" โดยวางโครงสร้างให้ นิยามสเปกของแอปแบบ declarative บน React, Node.js และ Prisma พร้อมระดมทุนรวมมากกว่า 5 ล้านดอลลาร์
• คำต่อท้าย "lang" ทำให้คนเข้าใจผิดว่าเป็นภาษาที่จะมาแทน JavaScript และภาระในการสร้าง การรองรับ IDE และ ecosystem ของเครื่องมือ ก็ใหญ่กว่าที่คาดไว้มาก
• คุณค่าหลักที่แท้จริงไม่ใช่ภาษาใหม่ แต่คือการคง สเปกระดับสูงของทั้งแอปฟูลสแตก ไว้ในช่วงคอมไพล์ไทม์
• ต่อจากนี้มีแผนเปิดตัวอย่างเป็นทางการผ่าน Launch Week โดยใช้ TypeScript SDK เป็นอินเทอร์เฟซหลัก ขณะที่กลไกภายในยังคงเดิม

---

เบื้องหลัง: ทำไมถึงอยากสร้างภาษาใหม่

• Wasp ก่อตั้งในปี 2021 โดยพี่น้องฝาแฝด ผ่าน Y Combinator และระดมทุนรวมได้ มากกว่า 5 ล้านดอลลาร์
• แนวคิดแรกเริ่มคือการเป็น "เฟรมเวิร์กอเนกประสงค์" ที่ทำงานได้กับทุกสแตก และจึงมองว่าจำเป็นต้องมีภาษาใหม่
• เป้าหมายคือสร้าง abstraction แบบเดียวกับ Terraform สำหรับโครงสร้างพื้นฐานคลาวด์ แต่ใช้กับสแตกของเว็บแอป

ความเหนื่อยล้าจากการเปลี่ยนสแตกและความซับซ้อนที่เกิดขึ้นโดยไม่จำเป็น

• ในอดีต หากเลือก Spring Boot, Django หรือ Rails สักตัว ระบบยืนยันตัวตน, routing และ state management มักได้มาพร้อมกัน
• ปัจจุบันต้อง ประกอบและเชื่อมต่อเอง ระหว่าง React, Redux, Webpack, Express, Passport, Sequelize และอื่น ๆ
• ทำให้เสียเวลากับการจัดการสแตกมากกว่าการเขียน business logic ซึ่งถูกนิยามว่าเป็น "accidental complexity"

แนวคิดโครงสร้างแบบ "ประกาศครั้งเดียวก็พอ"

• Wasp วางแนวคิดให้ความต้องการอย่าง "อยากใช้ล็อกอินด้วย Google และ GitHub", "route /profile ให้เข้าได้เฉพาะผู้ใช้ที่ยืนยันตัวตนแล้ว", "รัน cron job ทุกวันเวลา 17:00" ถูกเขียนเป็น สเปก (specification) ที่ไม่ผูกกับการ implement
• รูปแบบตัวอย่าง
  • auth: Google, GitHub
  • page Profile -> /profile, authRequired: true
  • job updateStats: run function doSomeCalc from stats.js every day at 5pm
• ไม่ได้ตั้งใจมาแทนสแตกเดิมทั้งหมด แต่ใช้แนวทางที่ ให้ logic อยู่ใน React และ Node.js ส่วนกระดูกสันหลังหลักแยกออกมาอีกชั้น
• ข้อสังเกตสำคัญคือโดเมนของเว็บแอป (หน้า, route, API, data model) แทบไม่เปลี่ยน แต่ วิธี implement เปลี่ยนเร็วมาก

ทำไมไม่ใช้ภาษาที่มีอยู่ แต่เลือกสร้างภาษาใหม่

• มีสองเหตุผลหลักที่ออกแบบภาษาใหม่ตั้งแต่ต้น
  • ควบคุมไวยากรณ์ได้ทั้งหมด เพื่อลด boilerplate ให้เหลือน้อยที่สุด
  • มุ่งสู่เครื่องมือแบบ runtime-agnostic — เช่น บางส่วนรันบน Node.js ส่วนงานข้อมูลเข้มข้นใช้ Python
• แม้จะมีฟีดแบ็กตั้งแต่แรกว่าให้อาศัย embedded DSL บน TypeScript แต่ตอนนั้นมองว่าเหมือนทรยศต่อวิสัยทัศน์เดิมจึงปฏิเสธ
• Wasp เชื่อว่าการเปิดตัวในฐานะภาษาอิสระจะส่งสารได้ชัดกว่าในการ สร้างความแตกต่างจากเฟรมเวิร์กที่ผูกกับภาษาอย่าง Rails หรือ Django
• ผู้ก่อตั้งก็ยอมรับตรง ๆ ว่าตนเองเป็นแฟน Haskell และการทำภาษา/คอมไพเลอร์ก็เป็นงานที่น่าหลงใหลในตัวมันเอง

ปฏิกิริยาจากตลาด: ผู้คนชอบไอเดีย แต่ภาษากลับเป็นสิ่งที่ต้องฝืนรับ

• หลังเปิดอัลฟาได้ราว 1 ปี ก็เริ่มมีผู้ใช้กลุ่มแรก ผ่านเข้า Y Combinator และระดมทุนรอบ pre-seed ได้
• หลังเบตา อัตราการนำไปใช้เพิ่มขึ้นจริงจัง โดยแรงผลักสำคัญคือความเหนื่อยจาก boilerplate และการประกอบสแตก
• ช่วงเวลาใกล้กันก็มีเฟรมเวิร์กแนว "Rails ฉบับ JS" อย่าง RedwoodJS และ BlitzJS เกิดขึ้นเช่นกัน
• แต่ RedwoodJS ผูกกับ GraphQL มาก ส่วน BlitzJS ผูกกับ Next.js มากเกินไป ขณะที่ Wasp อยู่รอดได้เพราะไม่ผูกกับเทคโนโลยีใดเทคโนโลยีหนึ่ง

• wasp-lang มาแทน JavaScript หรือไม่?

  • คำต่อท้าย "lang" ทำให้นักพัฒนาตีความโดยอัตโนมัติว่าเป็นภาษาทั่วไปแบบ Rust หรือ Java
  • ความจริงแล้ว 90% ของโค้ดยังคงเขียนด้วย React และ Node.js แต่ การวางตำแหน่งผลิตภัณฑ์กลับชวนให้เข้าใจผิด
  • ส่งผลให้ถูกจัดอยู่ในหมวด "ดูเท่ แต่ยังเร็วเกินไปสำหรับตอนนี้"

• ใช้ร่วมกับ IDE และเครื่องมือเดิมได้หรือไม่

  • คำถามว่า "ต้องสร้าง ecosystem ของตัวเองด้วยหรือเปล่า" เกิดขึ้นตามธรรมชาติ
  • นักพัฒนารู้ดีว่าการสร้างมาตรฐานใหม่และขยาย ecosystem ต้องจ่ายต้นทุนสูงมาก

• ปฏิกิริยาแบบ "ไม่อยากเรียน Haskell"

  • แม้ตัวคอมไพเลอร์จะเขียนด้วย Haskell แต่ ผู้ใช้ปลายทางใช้แค่ TypeScript
    • โครงสร้างก็เหมือน Prisma core ที่เขียนด้วย Rust หรือ Terraform HCL ที่เขียนด้วย Go
  • แต่การตลาดที่โดนใจชุมชน Haskell มากเกินไปทำให้ Wasp ถูกจดจำผิดเป็น "ภาษาที่สร้างบน Haskell"
  • แม้แต่แถบ "Languages" บน GitHub ที่ขึ้นว่า "Haskell: 90%" ก็ยิ่งตอกย้ำภาพจำที่ผิดนี้

• ปัญหาเรื่อง packaging

  • นักพัฒนาที่ลองใช้จริงส่วนใหญ่พอใจ และพบว่ายังใช้ React กับ Node.js เดิมได้ พร้อม ปล่อยโปรดักต์ได้เร็วขึ้น
  • แต่ช่วงที่ยากที่สุดคือการพาคนจาก "ไม่เข้าใจว่านี่คืออะไร" ไปสู่ "งั้นลองใช้ดูสักครั้ง"
  • เพื่อลดกำแพงการเริ่มต้น Wasp จึงสร้างโปรดักต์ชั้นบนอย่าง starter แบบโอเพนซอร์สสำหรับ SaaS และของแนว Lovable รุ่นแรก ๆ บนตัว Wasp
    • แม้ช่วยดึงผู้ใช้เข้าได้ แต่ปัญหาหลักยังคงอยู่

• จุดชี้ขาด: ความยากของการทำ IDE support

• ข้อจำกัดไม่ได้มาจากผู้ใช้ แต่เกิดขึ้นระหว่าง กระบวนการพัฒนาภายในเอง
• ระดับประสบการณ์ IDE ที่คาดหวังใน ecosystem ของ JS สูงมาก และเส้นแบ่งระหว่าง IDE กับคอมไพเลอร์ก็เริ่มเลือน
• ecosystem ของเครื่องมือทั้งหมดถูกสร้างบนเฟรมเวิร์กมาตรฐาน JS/TS อยู่แล้ว ทำให้ ภาษาอื่นเจอข้อจำกัดแทบจะทันที
• แม้ Wasp จะสร้าง language server และส่วนขยาย VS Code ของตัวเอง แต่เมื่อรวม Prisma DSL กับการอ้างอิงไฟล์ React/Node.js เข้าไป ก็ไปได้เพียงราว 80% ของเป้าหมาย

การบอกลาภาษาของตัวเอง และการย้ายไป TypeScript

• แม้การนำไปใช้ยังเพิ่มขึ้นเรื่อย ๆ แต่คำถามว่า "ทำไมต้องมีภาษาของตัวเอง" ก็ไม่เคยหายไป เปรียบเหมือน "ขับรถโดยดึงเบรกมือค้างไว้"
• สุดท้ายข้อได้เปรียบเชิงไวยากรณ์ของภาษานั้นไม่ได้ชี้ขาดอย่างที่คิด และนักพัฒนาก็ ยอมรับ TypeScript ที่คุ้นเคย พร้อมวงเล็บเพิ่มอีกไม่กี่บรรทัดได้สบาย

• คูเมืองที่แท้จริงไม่ใช่ภาษา แต่คือความเข้าใจทั้งแอปในช่วงคอมไพล์ไทม์

  • ช่วงก่อตั้ง บริษัทมองว่า "language" กับ "specification" เป็นคำเดียวกัน แต่สิ่งที่ผู้ใช้ชอบจริง ๆ คือการ มองเห็นภาพรวมของทั้งแอปผ่านสเปกระดับสูง (main.wasp, ปัจจุบันคือ main.wasp.ts)
  • คำสั่ง wasp studio ใช้แสดงภาพว่าระหว่างคอมไพล์ Wasp เข้าใจโครงสร้างแอปอย่างไร
  • เมื่อเครื่องมือ AI และการสร้างโค้ดอัตโนมัติเพิ่มขึ้น คุณค่าของการรองรับเชิงโครงสร้างแบบนี้ก็ยิ่งมากขึ้นสำหรับคนรุ่น "vibe-coders" ที่ไม่ได้มาจากสายเทคนิคโดยตรง
  • การเปลี่ยนครั้งนี้คือการเปลี่ยนเฉพาะ "frontend" ของคอมไพเลอร์ (วิธีนิยามสเปก) เท่านั้น โดย กลไกภายในยังคงเหมือนเดิม

• TypeScript SDK — จากการทดลองสู่ผลิตภัณฑ์จริง

  • TypeScript SDK ที่เปิดเป็น experimental preview มีผู้ใช้ใหม่จำนวนมากรับไปใช้ทันที และบางรายก็ไม่เคยใช้ภาษา Wasp เดิมเลยด้วยซ้ำ
  • ตัวอย่างโค้ด
    • ใช้ app.page, app.route สำหรับกำหนดหน้าและ route
    • ใช้ app.query สำหรับกำหนด query และระบุ entities ได้
    • ใช้ app.job สำหรับกำหนดงาน async พร้อมรองรับ PgBoss executor และตัวเลือก retry
  • ประโยชน์เชิงปฏิบัติของการย้ายครั้งนี้
    • ใช้งานได้ในทุก editor โดยไม่ต้องตั้งค่าเพิ่ม
    • ใช้เงื่อนไข, loop และ import ได้ — เช่น เขียน file-based routing ของตัวเองได้
    • แยกสเปกออกเป็น หลายไฟล์ ได้ง่าย
    • ปูพื้นฐานสำหรับฟีเจอร์ขั้นสูงอย่าง Full Stack Modules

ทบทวนบทเรียนเรื่อง DSL

• Wasp ยอมรับว่าหากไม่มีแนวทางแบบ DSL ก็คงไม่มี Wasp ในแบบทุกวันนี้
• วิธีคิดแบบ DSL บังคับให้ยึดมั่นกับวิสัยทัศน์เรื่อง "การแยกสเปกออกจากการ implement"
• ในอนาคตยังคงสนใจความเป็นไปได้ในการรองรับภาษาและ runtime อื่น เช่น Python, Rust รวมถึงการใช้ความเข้าใจทั้งแอปในช่วงคอมไพล์ไทม์เพื่อ เพิ่มความหลากหลายและการปรับแต่งสถาปัตยกรรม

ความเข้ากันได้กับ AI agent

• เมื่อ AI มีบทบาทในการเขียนโค้ดมากขึ้น นักพัฒนาก็มีแนวโน้มชอบ เครื่องมือที่มีโครงสร้างและ opinion ชัดเจน มากขึ้น
• Wasp ซึ่งครอบคลุมทั้งฟูลสแตกและรับประกันความสอดคล้องได้ตลอด จึงเข้ากับกระแสนี้
• นี่เป็นบริบทเดียวกับที่เฟรมเวิร์กโมโนลิทแบบ "เก่า" อย่าง Django, Rails, Laravel ถูกหยิบกลับมามองใหม่ และ Wasp ตั้งใจจะมอบสิ่งนั้นให้กับ ecosystem ของ JS
• มีกรณีผู้พัฒนาที่ลองมาแล้ว 10 สแตก ก่อนสุดท้ายจะเลือก Wasp จริง

เตรียมเปิดตัว Wasp แบบ TypeScript-First

• ในอีกไม่กี่สัปดาห์ข้างหน้า Wasp มีแผนเปิดตัวอย่างเป็นทางการผ่าน Launch Week โดยให้ TypeScript SDK เป็นวิธีใช้งานหลักของ Wasp
• ผู้ใช้ใหม่จะสามารถใช้ความสามารถทั้งหมดของ Wasp ได้ด้วย TypeScript เพียงอย่างเดียว โดยไม่ต้องเรียนภาษาใหม่