ถ้าชอบ overengineering ล่ะก็ตามสบายเลย

อนึ่งก็แปลกดีทำไมมันไป Error ตรง personal ทั้ง ๆ ที่ Snippet ข้างต้นก็ใช้ TS ตัวเดียวกัน

เตือนแล้วยังไงต่อครับ เช็คแค่ใน ide รันผ่านก็เท่านั้น ผมหมายถึง ts เขาห้าม compile ผ่าน

ถ้าเห็น Error แล้วยังจะรันต่อเพราะคิดว่าใน Runtime จะปกติดีก็เชิญตามสบายเลย

แต่วิธีนี้ js มันแก้ข้อเสียตัวเองยังไง มันพึ่งพาอย่างอื่นหนิ

TS โดยไม่มี TS Check มันก็ไม่ต่างกันนะ แถมรันบนเบราว์เซอร์ไม่ได้จนกว่าจะเอาไปผ่าน TSC อีกที

และก็ ถ้าตั้งคำถามนี้ขึ้นมาได้ ก็จะเข้าใจปัญหาของทิศทางการพัฒนา TS ในขณะนี้ทันที ผมเองก็ใช่ว่าจะปฏิเสธการมีอยู่ของ TS เลยนะ เป็นโปรเจกต์ที่ควรจะเกิดขึ้นนั่นแหละ มันมีประโยชน์มากทีเดียวในการช่วย Type Check ก่อนรัน แต่คำถามคือ "ทำไม" ต้องพัฒนาภาษาขึ้นมาใหม่ ในเมื่อ JavaScript ในสถานะปัจจุบันก็พร้อม และ JSDoc ก็พร้อมอยู่แล้ว และสามารถใช้อ้างอิงและ Debug ทั้งโปรเจกต์ได้อยู่แล้ว

นั่นก็จะทำให้เราย้อนกลับไปตั้งแต่ที่ TS พัฒนาขึ้นมาใหม่ ๆ ปัญหาของ JS มันคือ ดั้งเดิมมันเป็นภาษาที่ออกแบบมาให้ Duck Type ตั้งแต่ต้น คุณจะเขียน Type ใหม่ลงไปในตัวแปรเดิมยังได้เลย และมันไม่เคยมี Concept ของ Class, Type, Interface, และ Enum มาให้ตั้งแต่แรก เพราะมันไม่จำเป็นยังไงล่ะ ด้วยความที่ภาษานี้ไม่เคยจะเป็นภาษาที่เหมาะเอามาใช้กับสเกลใหญ่ ๆ ตั้งแต่แรก และไม่เคยมีเป้าหมายนั้น จนกระทั่ง Node.JS คิดอุตริเอาภาษาจำพวก Duck (ที่ Duck จริง ๆ) อย่าง JS มาใช้กับสเกลขนาดใหญ่ โหดร้ายกว่าการใช้ PHP อีก อย่างน้อย PHP ก็ออกแบบมาใช้กับ Server ข้อผิดพลาดก็เพิ่มขึ้นเป็นเงาตามตัว และด้วยความที่ JS มันพัฒนาช้ามาก (อย่าง module เอง Mozilla สร้าง CommonJS ที่ไม่ได้ adopt โดยเบราว์เซอร์) คนถึงเริ่มอยากได้ Typed JS จริง ๆ จัง ๆ ขึ้นมา และ TS ก็เติมเต็มจุดนั้น และแถม Type Check ตอนคอมไพล์ (more like, just remove TS syntax) มาให้ในตัวเลย ลดข้อผิดพลาดได้เยอะ และสเกลได้มากขึ้น

อย่างไรก็ตาม นับตั้งแต่ที่ ES6 ออกมา ความห่างชั้นระหว่าง JS และ TS ก็น้อยลงเรื่อย ๆ ด้วยความสามารถของ Native Class Support ที่อ้างอิงจาก Object Prototype เดิม เพิ่ม Native Import ยิ่ง ECMAScript Proposal ใหม่ๆ เข้ามา ทำให้สร้าง Type และ Type Check ได้ง่ายและหลากหลายกว่าเดิม และ TS Check ก็ได้อานิสงส์จากตรงนี้ไปด้วยในการไล่ตรวจสอบข้อผิดพลาดให้กับ JavaScript ทำให้เห็นความจำเป็นที่จะใช้ TS ลดน้อยลงไปอีก (คนละอย่างกับ TS Check on JS นะ) ตอนนี้มันแทบไม่ต่างเลยระหว่าง JS + JSDoc + TS Check และ TypeScript + TSC ที่เหลือมันคือ Aesthetics ล้วน ๆ ว่าชอบโค้ดแบบไหน อย่าง Type ข้างตันเองก็ใช้ JS Class แก้ปัญหาได้เหมือนกัน ต่างแค่วิธีเขียนก็แค่นั้น

ตัวอย่างใกล้เคียงกันก็คือ C/C++ กับ Zig นี่แหละ แต่เกิดตรงข้ามกัน ภาษา Zig เองถอนฟีเจอร์ออกไปด้วยซ้ำ เพราะฟีเจอร์เหล่านั้นมันทำให้โค้ดอ่านยาก ซึ่งก็น่าจะคล้าย ๆ กับมุมมองของ @dhh ที่มีต่อ TypeScript นั่นแหละ ฟีเจอร์ที่เพิ่มเข้ามาก็ใช่ว่าจะแก้ปัญหาได้เสมอไป หรือคำถามจริง ๆ คือ มันใช้แก้ปัญหาได้จริง ๆ หรือไม่

ถ้าใครชอบใช้ TS แล้วมีความสุขดีผมก็แนะนำให้ใช้งานต่อไป ไม่มีประโยชน์ที่จะย้าย Workflow กลับมา สร้างภาระโดยที่ผลลัพธ์ออกมาเท่าเดิม หรือใครที่ใช้ JS กับโปรเจกต์ใหญ่ ๆ ก็เริ่ม Refactor จาก Prototype ไป Class แล้วเขียน JSDoc ร่วมกับใช้ TS Check ช่วยตรวจสอบก็ได้ ไม่ต้องพยายามดึงดันไปใช้ TS ส่วนใครที่จะเริ่มโปรเจกต์ใหม่ ก็ถามตัวเองได้เลยว่าเราควรจะไป TS หรือไม่ การเพิ่มภาระในการเพิ่มคำสั่ง TSC เข้ามาอีกหนึ่งตัว (อนุมานว่าใช้ ECMAScript ล่าสุด แต่ถ้าไม่ก็ TSC + Babel + Webpack) ถือว่าเป็นภาระหรือไม่ เอาจริง บางทีไม่ต้องใช้ TSC เลยถ้าเกิดว่าใช้โปรเจกต์กับ Deno หรือ Bun เพระมันแปลงให้ในตัวเลย หรือว่าเครื่องมือที่เราใช้ร่วมนั้นนั้นบังคับ TS ล้วนหรือเปล่า หรือแนะนำให้ใช้ TS เป็นค่าเริ่มต้นหรือไม่ (อย่าง Phaser.JS นี่ Integrate TS มาแทบจะแนบแน่นเลย ตอนพอร์ตมา JS ก็แทบจะ Type Check ด้วย TS Check ไม่ได้) ก็สุดแล้วแต่จะเลือก แต่มันก็ไม่ใช่เหตุผลที่จะยกระดับ TypeScript ให้สูงกว่า JavaScript ปัจจุบันแต่อย่างใดเพียงเพราะว่ามันมี Type Check ทั้งที่ JavaScript ก็มี 3rd Party Type Check เหมือนกัน

ปล. Microsoft เองก็เสนอ Proposal ใหม่เข้า ECMAScript ด้วยการเพิ่ม Type พื้นฐานให้กับ JavaScript ไปแล้วแต่ยังไม่ได้รับการพิจารณา ซึ่งถ้าเข้ามาได้ก็แทบไม่มีความจำเป็นจะต้องใช้ TS อีกเลยเพราะการทำ Integrate Type Check ผ่านทาง Third Party จะง่ายยิ่งกว่าเดิม