TypeScript เร็วขึ้น 10 เท่า

• Microsoft ประกาศว่า ประสิทธิภาพของ TypeScript ดีขึ้น 10 เท่า ผ่านการพอร์ตคอมไพเลอร์และเครื่องมือไปเป็นเนทีฟ
• เวลาเริ่มต้นของเอดิเตอร์ดีขึ้นอย่างมาก, เวลา build สั้นลง 10 เท่า, และลดการใช้หน่วยความจำลงอย่างมาก
• มีแผนจะออกเวอร์ชันพรีวิวของ tsc ภายในกลางปี 2025 และจะรองรับการ build โปรเจ็กต์เต็มรูปแบบและ language service ภายใน ปลายปี 2025

เบื้องหลังการปรับปรุงประสิทธิภาพของ TypeScript

• คุณค่าหลักของ TypeScript คือประสบการณ์นักพัฒนาที่ยอดเยี่ยม
• ยิ่ง codebase มีขนาดใหญ่ คุณค่าของ TypeScript ก็ยิ่งมากขึ้น แต่ในโปรเจ็กต์ขนาดใหญ่ก็เกิดปัญหาด้านประสิทธิภาพ
  • มีปัญหาเรื่องเวลาโหลดและเวลาตรวจสอบที่ยาวนาน
  • ต้องหาสมดุลระหว่างเวลาเริ่มต้นของเอดิเตอร์ที่รวดเร็วกับการวิเคราะห์ codebase ทั้งหมด
• ฟีเจอร์ที่ขับเคลื่อนด้วย AI ต้องการข้อมูลเชิงความหมายที่รวดเร็วและแม่นยำ
• มีความต้องการเพิ่มขึ้นในการตรวจสอบสถานะของ codebase ผ่านการ build บนบรรทัดคำสั่ง

แผนการพอร์ตเป็นเนทีฟ

• เริ่มดำเนินงานพอร์ตคอมไพเลอร์และเครื่องมือของ TypeScript ไปเป็นเนทีฟ
• เป้าหมายของการปรับปรุงประสิทธิภาพ:
  • ลดเวลาเริ่มต้นของเอดิเตอร์ลงอย่างมาก
  • ลดเวลา build ได้สูงสุด 10 เท่า
  • ลดการใช้หน่วยความจำ
• กลางปี 2025: มีแผนออกเวอร์ชันพรีวิวของ tsc ที่สามารถตรวจสอบชนิดผ่านบรรทัดคำสั่งได้
• ปลายปี 2025: มีแผนรองรับการ build โปรเจ็กต์เต็มรูปแบบและ language service

การรันโค้ดและการทดสอบ

• สามารถ build และรันโค้ดได้จาก คลังโค้ด TypeScript Go
• ในคลังมีคำแนะนำสำหรับการ build และรัน tsc และ language server
• จะมีการอัปเดตฟีเจอร์ใหม่อย่างสม่ำเสมอ

เร็วขึ้นแค่ไหน?

• จากการทดสอบเวลา build ของโปรเจ็กต์ TypeScript ปัจจุบันบน codebase ยอดนิยมหลายตัว พบว่าประสิทธิภาพดีขึ้นดังนี้:
  • โปรเจ็กต์ VS Code ที่มีโค้ดประมาณ 1.5 ล้านบรรทัด เร็วขึ้นจาก 77.8 วินาทีเหลือ 7.5 วินาที หรือประมาณ 10.4 เท่า
  • โปรเจ็กต์ Playwright ที่มีโค้ดประมาณ 350,000 บรรทัด เร็วขึ้นจาก 11.1 วินาทีเหลือ 1.1 วินาที หรือประมาณ 10.1 เท่า
  • โปรเจ็กต์ TypeORM ที่มีโค้ดประมาณ 270,000 บรรทัด เร็วขึ้นจาก 17.5 วินาทีเหลือ 1.3 วินาที หรือประมาณ 13.5 เท่า
  • โปรเจ็กต์ date-fns ที่มีโค้ดประมาณ 100,000 บรรทัด เร็วขึ้นจาก 6.5 วินาทีเหลือ 0.7 วินาที หรือประมาณ 9.5 เท่า
  • โปรเจ็กต์ tRPC ที่มีโค้ดประมาณ 18,000 บรรทัด เร็วขึ้นจาก 5.5 วินาทีเหลือ 0.6 วินาที หรือประมาณ 9.1 เท่า
  • โปรเจ็กต์ rxjs ที่มีโค้ดประมาณ 2,000 บรรทัด เร็วขึ้นจาก 1.1 วินาทีเหลือ 0.1 วินาที หรือประมาณ 11 เท่า
• แม้ฟีเจอร์จะยังไม่สมบูรณ์ทั้งหมด แต่คาดว่าจะได้ประสิทธิภาพเพิ่มขึ้นเกิน 10 เท่าใน codebase ส่วนใหญ่
• ทำให้การตรวจสอบชนิดและการสำรวจโค้ดทำได้รวดเร็วยิ่งขึ้น
• รองรับการผสาน AI tools และการรีแฟกเตอร์ขั้นสูงได้

การปรับปรุงประสิทธิภาพของเอดิเตอร์

• ปรับปรุงความเร็วในการโหลดและการตอบสนองของเอดิเตอร์
• เวลาโหลดโดยอิงจาก codebase ของ Visual Studio Code:
  • ปัจจุบัน: 9.6 วินาที → เวอร์ชันเนทีฟ: 1.2 วินาที (ดีขึ้นประมาณ 8 เท่า)
• การใช้หน่วยความจำลดลงประมาณ 50%
• คาดว่าประสิทธิภาพของงานใน language service (การเติมโค้ดอัตโนมัติ, quick info, ไปยังคำนิยาม เป็นต้น) จะดีขึ้น
• กำลังดำเนินงานย้ายระบบโดยอิงกับ Language Server Protocol (LSP)

โรดแมปเวอร์ชัน

• TypeScript 5.8 ออกแล้ว และ TypeScript 5.9 จะออกในเร็ว ๆ นี้
• codebase ของ TypeScript ที่อิงกับ JS จะยังพัฒนาต่อในเวอร์ชัน 6.x
• เมื่อ codebase แบบเนทีฟมีเสถียรภาพแล้ว จะออกเป็น TypeScript 7.0
  • TypeScript 6 → เวอร์ชันที่อิงกับ JS
  • TypeScript 7 → เวอร์ชันที่อิงกับเนทีฟ
• หลังจาก TypeScript 7 ออกแล้ว เวอร์ชัน 6.x จะยังคงได้รับการดูแลต่ออีกช่วงหนึ่ง

ขั้นตอนถัดไป

• จะมีการเปิดเผยข้อมูลเพิ่มเติมเกี่ยวกับประสิทธิภาพ, Compiler API, LSP และเรื่องอื่น ๆ
• สามารถดูคำถามที่พบบ่อยได้ที่ GitHub FAQ
• มีกำหนดจัด AMA ใน TypeScript Community Discord วันที่ 13 มีนาคม 2025 (10:00 น. PDT | 17:00 น. UTC)

[click]

ผมรู้สึกว่าทุกคนพูดกันไปโดยไม่ได้คำนึงถึง structural typing กันหรือเปล่า
ถ้าจะเขียนใหม่เป็นภาษาแบบ nominal typing อย่าง C# หรือ Rust ก็คงไม่ง่าย เพราะต้องเปลี่ยนโครงสร้างพื้นฐานของโปรเจ็กต์ไปมากเกินไป
ในบรรดาภาษาที่ใช้ structural typing ถ้าจะให้ประสิทธิภาพสูงกว่า JS เดิมได้ ก็คงมีแค่ C++ หรือไม่ก็ Go แต่ถ้าคำนึงถึงเรื่องผลิตภาพด้วย ก็แทบไม่มีทางเลือกอื่น

[kuthia]

ช่วงหนึ่งผมเริ่มจับ TS น้อยลงไปแล้ว แต่พอเห็นข่าวแบบนี้ก็เริ่มสนใจขึ้นมาอีกนะ?

[pitou106]

ถ้าใน ts ใช้ any แบบพร่ำเพรื่อ ยกเว้นกรณีที่หลีกเลี่ยงไม่ได้จริง ๆ มันก็แทบไม่ต่างจากการใช้ vanilla เลยครับ..ฮ่า

[yshrust]

ดูเหมือนว่าประเด็นถกเถียงจะร้อนแรงพอสมควรจน Anders Hejlsberg เข้ามาคอมเมนต์ด้วยตัวเองเลย

https://github.com/microsoft/typescript-go/…

[jjpark78]

คนหนึ่งที่อยากให้คอมไพล์ด้วย TypeScript แล้วได้ผลลัพธ์ออกมาเป็นไบนารีได้ทันที

[passerby]

ผมไม่ค่อยรู้เรื่องฝั่งฟรอนต์เอนด์เท่าไร.. มันต่างจาก swc ไหม?

[caniel]

SWC มุ่งเน้นไปที่การสร้างโค้ด JavaScript ที่เข้ากันได้แบบเดียวกับ Babel และรวมไฟล์เข้าด้วยกัน ส่วนสิ่งนี้มุ่งเน้นไปที่การแปลงโค้ด TypeScript เป็น JavaScript หรือตรวจสอบข้อผิดพลาด

[halfenif]

หากโค้ด TypeScript ไม่ได้เขียนด้วย TypeScript อีกต่อไป ทีมก็อาจเลิกใช้ TypeScript โดยตรง ซึ่งในระยะยาวอาจส่งผลต่อประสบการณ์ในการพัฒนา

มีคำพูดว่า "กินอาหารสุนัขตัวเอง" กันใช่ไหม คือการใช้สิ่งที่ตัวเองสร้างขึ้นด้วยตัวเอง แต่พอเป็นเรื่องของภาษาแล้วก็ชวนให้คิดอยู่เหมือนกันครับ

[dongjinahn]

ในความเห็นส่วนตัว รันไทม์ของ js ที่เป็นฐานของ ts (เช่น spidermonkey, v8) ส่วนใหญ่เขียนด้วย c++ และก็ไม่มีรันไทม์ที่พัฒนาด้วย js ด้วยกันเอง
อีกทั้งการคอมไพล์จาก js -> js ถ้าใช้ pure js ก็ช้าเกินไป จนพวก esbuild อะไรทำนองนั้นเข้ามาแทนกันหมด
เลยทำให้รู้สึกว่าในฝั่ง ts เอง จำเป็นแค่ไหนที่จะต้องยืนกรานกับการกินอาหารหมาเอง

[wogns3623]

กังวลว่าต่อไปอาจละเลยการดูแลโค้ดเบส TypeScript ที่มีอยู่เดิมหรือเปล่า

[tsboard]

เป็นข่าวที่น่ายินดี! น่าแปลกที่ภาษา TypeScript ของ MS ดูเหมือนจะตัดสินใจเลือกสิ่งที่คาดไม่ถึงจริง ๆ อยู่หลายอย่าง ต่างจาก Dart ของ Google ที่พยายามจะมาแทนที่ JS สำหรับ MS แล้วนี่แทบจะเป็นโปรเจ็กต์โอเพนซอร์สชิ้นแรก ๆ และการเลือกแนวทางที่พยายามเข้ามาเสริม JS ก็ดูเป็นการตัดสินใจที่ชาญฉลาดมาก อีกทั้งในครั้งนี้ แม้บริษัทเองก็น่าจะมีภาษาของตัวเองอยู่มากมาย แต่การเลือก Go ของ Google สำหรับภาษาที่ใช้พอร์ตเป็นเนทีฟก็น่าประหลาดใจเช่นกัน

[galadbran]

เอ๊ะ แต่ฝั่ง deno น่าจะมีทูลเชนที่สร้างบน Rust อยู่แล้วไม่ใช่เหรอ... ทำไมจู่ ๆ กลายเป็น Go ล่ะ?

[asheswook]

ดูเหมือนว่าคุณกำลังหมายถึงรันไทม์อย่างเช่น Node แต่สิ่งที่พูดถึงกันที่นี่คือตัวคอมไพเลอร์ของภาษา TS เอง

[galadbran]

อ้อ พออ่านบทความต่ออีกหน่อยก็เหมือนจะมีเรื่องว่า editor เร็วขึ้นด้วย เลยทำให้ผมสับสนไปหน่อยครับ

• tsc เร็วขึ้น 10 เท่า กล่าวคือเวลา transpile จาก ts -> js ลดลงมาก
• เวลาโหลดโปรเจ็กต์ขนาดใหญ่ที่พัฒนาด้วย ts อย่าง VSCode จะเร็วขึ้นมาก กล่าวคือ logic ที่ใช้ฟังก์ชันของ tsc ร่วมกัน เช่น การตรวจไวยากรณ์ของ ts เร็วขึ้น
• ไม่ได้หมายความว่าความเร็วในการทำงานของ VSCode เองเร็วขึ้น
  เป็นเนื้อหาประมาณนี้นี่เองครับ

[illiil1lii]

ผมเคยมีประสบการณ์ว่าเวลาใช้ generic type ที่ประกอบด้วยการเรียกซ้ำแบบ recursive มันช้าจนต้องใช้ทางเลือกอื่น ถ้าเร็วขึ้น 10 เท่า ก็คาดหวังได้เลยว่าส่วนแบบนี้น่าจะดีขึ้นด้วย

[tujuc]

เธรดอภิปรายเรื่องทำไมถึงต้องเป็น Go น่าสนใจดีนะครับ

https://github.com/microsoft/typescript-go/discussions/411

ยังมีเรื่องที่ต้องคิดอีกเยอะ...

[tsboard]

ก็จริงครับ ความรู้สึกของนักพัฒนา .NET เองก็พอเข้าใจได้เหมือนกัน...

[riki3]

นักพัฒนา .NET และ Rust ดูเหมือนจะไม่พอใจกันมากเลย

[bungker]

เข้าใจฝั่ง .NET นะ แต่รู้สึกว่า Rust น่าจะอยู่ตำแหน่งเดียวกับ Go มากกว่า ไม่ว่าอย่างไรก็ตาม ดูเหมือนว่าโปรเจกต์และไลบรารีฝั่ง JS ที่มีอยู่เดิมซึ่งทำด้วย Go ก็น่าจะมีอิทธิพลต่อการตัดสินใจเหมือนกัน

[aa1567]

การพัฒนาภาษา C# ไม่ได้หยุดลงเสียทีเดียว แต่รู้สึกว่ามีเฟรมเวิร์กที่ใช้ C# หลายตัวถูกปล่อยปละละเลยมากเกินไป

[clastneo]

เขียนด้วย Go~

[caniel]

น่าตื่นเต้นมากครับ

[GN⁺]

ความเห็นจาก Hacker News

• Daniel Rosenwasser จากทีม TypeScript มาแจ้งข่าวการประกาศ และพร้อมตอบคำถามร่วมกับ Ryan Cavanaugh หัวหน้าทีม
  • สามารถดูข้อมูลเพิ่มเติมได้ใน Discord AMA
• เครื่องมือพัฒนาที่เร็วขึ้นเป็นเรื่องยอดเยี่ยม และน่ายินดีที่ทีม TypeScript ให้ความสำคัญกับประสบการณ์นักพัฒนาอย่างลึกซึ้งมาโดยตลอด
  • หากโค้ด TypeScript ไม่ได้เขียนด้วย TypeScript อีกต่อไป ในระยะยาวอาจกระทบต่อประสบการณ์นักพัฒนา เพราะทีมจะไม่ได้ใช้งาน TypeScript ด้วยตัวเอง
  • มีการยกกรณีของ Flow ที่เขียนด้วย OCaml และล้มเหลวขึ้นมา พร้อมตั้งคำถามว่าทีมคิดอย่างไรกับเรื่องนี้
• มีการกล่าวถึงสองโปรเจ็กต์ที่เคยพยายามสร้าง tsc แบบเร็วด้วย Rust มาก่อน
  • stc: ยุติไปแล้ว
  • ezno: ยังพัฒนาอย่างต่อเนื่อง และไม่ได้ตั้งเป้าความสอดคล้องแบบ 1:1 กับ tsc
• โปรเจ็กต์มักเริ่มต้นด้วยภาษาสคริปต์ที่ยืดหยุ่น แต่สุดท้ายการแสดงออกที่เนทีฟกว่ามักเป็นฝ่ายชนะ
  • ผู้แสดงความเห็นมองว่าอาจเริ่มจากการแสดงออกในระดับล่างกว่าจะดีกว่า
  • ทำให้กลับมาทบทวนสมมติฐานพื้นฐานของการใช้ JS runtime บนเซิร์ฟเวอร์
  • ข้อได้เปรียบของภาษาสคริปต์กำลังลดลงเรื่อย ๆ
• ตอนแรกนึกว่าเป็นข่าววันเมษาหน้าโง่
• การเลือก Go ถือว่าเป็นตัวเลือกที่ดี
  • น่าประทับใจที่เลือก Go แทน Rust
  • เสียดายที่ไม่ได้เลือก .NET แบบ AOT compiled
• สิ่งสำคัญคือการทำให้โค้ดเบสใหม่เข้ากันได้กับของเดิมให้มากที่สุด
  • ไวยากรณ์ของ Go คล้ายกับโค้ดเบส TypeScript จึงพอร์ตได้ง่าย
• ประหลาดใจกับความคล้ายกันทางไวยากรณ์ระหว่าง Golang และ TypeScript
  • มีการแชร์ประสบการณ์ว่าการใช้ sum types ใน Golang ทำได้ยาก
• มีการแนะนำพอดแคสต์ที่ Daniel และ Anders พูดคุยเชิงลึกเกี่ยวกับ native port
• พบปัญหาด้านประสิทธิภาพระหว่างรีแฟกเตอร์ไฟล์ TypeScript ขนาดใหญ่
  • แม้การย้ายโค้ดเบสมาเป็น TypeScript จะช่วยทีมได้มาก แต่ปัญหาด้านประสิทธิภาพก็ยังคงมีอยู่
• เดิมใช้ PHP และเริ่มใช้ TypeScript ตั้งแต่ 4 ปีก่อน
  • ระบบ type ของ TypeScript มีประโยชน์ และคอมไพล์ได้รวดเร็ว
  • แม้จะไม่ได้เป็นแฟนของ Microsoft แต่ก็มองว่า TypeScript เป็นภาษาที่ออกแบบมาได้ดี