Node.js ได้เข้าร่วมการแข่งขันในการสนับสนุน TypeScript แบบ native ในที่สุด แต่ชุมชนนักพัฒนาตั้งคำถามว่าการเคลื่อนไหวนี้มาช้าเกินไปจนไม่สำคัญแล้วหรือไม่ ด้วยเวอร์ชัน 23.6.0 ที่เปิดใช้งาน type stripping โดยค่าเริ่มต้น Node.js ตอนนี้สามารถรัน TypeScript code ได้โดยตรงโดยไม่ต้อง transpilation ซึ่งเป็นการเปลี่ยนแปลงที่สำคัญสำหรับ runtime ที่มีประสบการณ์ยาวนาน
การใช้งานนี้ช่วยให้นักพัฒนาสามารถรันไฟล์ TypeScript ได้โดยใช้คำสั่งง่ายๆ โดยจะลบ type annotations โดยอัตโนมัติ สำหรับ TypeScript syntax พื้นฐานไม่จำเป็นต้องใช้ flag เพิ่มเติมในเวอร์ชันล่าสุด ฟีเจอร์ที่ซับซ้อนกว่าเช่น enums และ namespaces ต้องใช้ experimental transform flag แต่รากฐานได้ถูกวางไว้แล้ว
ไทม์ไลน์การรองรับ TypeScript ใน Node.js:
- v22.6.0: การลบ type แบบทดลองด้วยแฟล็ก
--experimental-strip-types - v22.7.0: เพิ่มการแปลงไวยากรณ์ TypeScript ด้วยแฟล็ก
--experimental-transform-types - v23.6.0: การลบ type เปิดใช้งานโดยค่าเริ่มต้นสำหรับไวยากรณ์ TypeScript ที่ลบได้
สงคราม Runtime ทวีความรุนแรง
การตอบสนองของชุมชนเผยให้เห็นความกังวลที่เพิ่มขึ้นเกี่ยวกับ Node.js ที่ตกหลังจากทางเลือกใหม่ๆ นักพัฒนาเปรียบเทียบ Node.js กับ runtime สมัยใหม่เช่น Deno และ Bun มากขึ้นเรื่อยๆ ซึ่งมีการสนับสนุน TypeScript ตั้งแต่เริ่มต้น การอภิปรายนี้เน้นย้ำคำถามพื้นฐาน: ขนาดของ ecosystem ยังคงสำคัญกว่าฟีเจอร์สมัยใหม่หรือไม่?
มันเป็นเรื่องของ ecosystem ล้วนๆ ในจุดนี้ Deno, Bun หรือ runtime ใดๆ ก็ทันสมัยกว่า เป็นเรื่องดีที่พวกเขากำลังตามให้ทัน แต่เมื่อถึงเวลาที่ typescript เป็น native citizen ใน node คนอื่นอาจจะได้ครองราชย์แล้ว
ความรู้สึกนี้สะท้อนความผิดหวังของอุตสาหกรรมโดยรวมต่อการยอมรับฟีเจอร์ที่เป็นมิตรกับนักพัฒนาที่ช้าของ Node.js ในขณะที่ Node.js ยังคงรักษาข้อได้เปรียบด้าน ecosystem ขนาดใหญ่ คู่แข่งมอบประสบการณ์ที่ดีกว่าตั้งแต่เริ่มต้นด้วยฟีเจอร์เช่นการสนับสนุน TypeScript ในตัว APIs สมัยใหม่ และเครื่องมือที่เรียบง่าย
บริบทการเปรียบเทียบ Runtime:
- Node.js: ระบบนิเวศที่ใหญ่ที่สุด การรับเอา TypeScript อย่างค่อยเป็นค่อยไป
- Deno: รองรับ TypeScript แบบ Native, APIs ที่ทันสมัย, มีปัญหาความเข้ากันได้บางประการ
- Bun: ประสิทธิภาพที่รวดเร็ว, TypeScript ในตัว, ระบบนิเวศที่เล็กกว่า
ข้อกังวลด้านการใช้งานทางเทคนิค
แนวทางทางเทคนิคยังได้รับการตรวจสอบอย่างใกล้ชิดจากนักพัฒนาที่คุ้นเคยกับเครื่องมือ TypeScript บางคนตั้งคำถามว่าทำไม Node.js ถึงสร้าง type stripper ของตัวเองแทนที่จะใช้โซลูชันที่มีอยู่แล้วเช่น TypeScript Compiler หรือ SWC โดยตรง การตัดสินใจนี้ทำให้เกิดความกังวลเกี่ยวกับการรักษาความเข้ากันได้เมื่อ TypeScript พัฒนาและเพิ่ม language constructs ใหม่
อย่างไรก็ตาม การใช้งานนี้ใช้ SWC ภายใต้ฝาครอบซึ่งควรช่วยเรื่องประสิทธิภาพและความเข้ากันได้ แนวทาง type stripping หมายความว่าฟีเจอร์ TypeScript ใหม่ไม่ควรทำลายการทำงานที่มีอยู่ เนื่องจากระบบเพียงลบ type annotations แทนที่จะแยกวิเคราะห์ syntax ที่ซับซ้อน
คุณสมบัติ TypeScript ที่รองรับ:
- การตัดประเภทข้อมูลพื้นฐาน: พารามิเตอร์ของฟังก์ชัน ประเภทการคืนค่า การกำกับตัวแปร
- การแปลงขั้นสูง: Enums, namespaces (ต้องใช้ experimental flag)
- ข้อจำกัด: มีข้อจำกัดเชิงทดลองบางประการ (ดูเอกสาร Node.js API)
ประโยชน์ในทางปฏิบัติเริ่มปรากฏ
แม้จะมีการถกเถียง นักพัฒนาบางคนรายงานประโยชน์ในทางปฏิบัติทันที การรวมกันของการสนับสนุน TypeScript แบบ native กับความสามารถในการทดสอบที่ปรับปรุงของ Node.js กำลังขจัดความจำเป็นในการใช้ build pipelines ที่ซับซ้อนในสภาพแวดล้อมการพัฒนา การทดสอบทำงานเร็วขึ้นด้วย dependencies ที่น้อยลง แม้ว่านักพัฒนายังคงต้องปฏิบัติตามแนวทางเฉพาะเช่นการใส่ annotation ให้กับ type imports และการใช้ file extensions
ฟีเจอร์นี้แสดงถึงความพยายามของ Node.js ในการทำให้ทันสมัยขณะรักษาความเข้ากันได้แบบย้อนหลัง ว่ากลยุทธ์นี้จะสามารถแข่งขันกับ runtime สมัยใหม่ที่สร้างขึ้นเพื่อจุดประสงค์เฉพาะได้หรือไม่ยังคงเป็นคำถามเปิดในขณะที่ JavaScript ecosystem ยังคงพัฒนาอย่างรวดเร็ว
อ้างอิง: Running TypeScript Natively