Microsoft, Igalia และ Bloomberg ประกาศเมื่อไม่กี่วันก่อนว่า ได้ริเริ่มที่จะรวมไวยากรณ์ สำหรับคำจำกัดความประเภทที่ชัดเจนในข้อกำหนด JavaScript คล้ายกับไวยากรณ์ที่ใช้ในภาษา TypeScript
ในปัจจุบัน การเปลี่ยนแปลงต้นแบบที่เสนอให้รวมไว้ในมาตรฐาน ECMAScript ได้ถูกส่งไปแล้วสำหรับการอภิปรายเบื้องต้น (ขั้นตอนที่ 0)
วันนี้ เรายินดีที่จะประกาศการสนับสนุนและความร่วมมือในข้อเสนอ Stage 0 ใหม่ เพื่อนำไวยากรณ์ประเภทตัวเลือกและแบบลบได้มาสู่ JavaScript เนื่องจากไวยากรณ์ใหม่นี้จะไม่เปลี่ยนวิธีการรันโค้ดโดยรอบ พวกเขาจะทำหน้าที่เหมือนความคิดเห็นอย่างมีประสิทธิภาพ เราคิดว่าสิ่งนี้มีศักยภาพที่จะทำให้ TypeScript ใช้งานง่ายขึ้นและเร็วขึ้นสำหรับการพัฒนาในทุกระดับ เราต้องการพูดคุยเกี่ยวกับสาเหตุที่เราดำเนินการตามนี้ และวิธีที่ข้อเสนอนี้ทำงานอยู่ในระดับสูง
มีการกล่าวไว้ว่าที่ tการมีข้อมูลประเภทที่ชัดเจนจะป้องกันข้อผิดพลาดมากมายในกระบวนการพัฒนา มันจะให้โอกาสในการใช้เทคนิคการเพิ่มประสิทธิภาพเพิ่มเติม ลดความซับซ้อนของการดีบัก และทำให้โค้ดอ่านง่ายขึ้นและง่ายขึ้นสำหรับนักพัฒนาบุคคลที่สามในการแก้ไขและบำรุงรักษา
นอกเหนือจากนั้น เสนอให้ใช้การสนับสนุนประเภทเป็นฟังก์ชันทางเลือก: เอ็นจิ้น JavaScript และรันไทม์ที่ไม่รองรับการตรวจสอบประเภทจะไม่สนใจคำอธิบายประกอบที่มีข้อมูลประเภทและประมวลผลโค้ดเหมือนเมื่อก่อน โดยรับข้อมูลประเภทเป็นความคิดเห็น แต่เครื่องมือตรวจสอบประเภทจะสามารถตรวจสอบข้อผิดพลาดที่เกี่ยวข้องกับการใช้ประเภทที่ไม่ถูกต้องตามข้อมูลที่มีอยู่
พื้นหลัง
แนวโน้มล่าสุดที่ทีมของเราได้เห็นในโลกของ JavaScript คือความต้องการเวลาในการทำซ้ำที่เร็วขึ้นและขั้นตอนการสร้างที่ลดลง กล่าวอีกนัยหนึ่ง "ทำให้เร็วขึ้นและง่ายขึ้น"ในทางหนึ่งสิ่งนี้กำลังเกิดขึ้นแล้ว ต้องขอบคุณความสำเร็จของเบราว์เซอร์ที่ไม่เคยหยุดนิ่ง นักพัฒนามักจะหลีกเลี่ยงการคอมไพล์ JavaScript เวอร์ชันใหม่กว่าเพื่อทำงานบนรันไทม์ที่เก่ากว่าได้ การรวมกลุ่มก็เช่นเดียวกัน: เบราว์เซอร์ส่วนใหญ่มีการสนับสนุนในตัวสำหรับการใช้โมดูล ดังนั้นการรวมกลุ่มจึงถูกมองว่าเป็นขั้นตอนการเพิ่มประสิทธิภาพมากกว่าความจำเป็น นี่เป็นกรณีมากขึ้นเรื่อย ๆ ดังนั้น TypeScript จะทนได้อย่างไร?
ในเวลาเดียวกัน ไม่เหมือนกับข้อมูลประเภทที่ระบุ ผ่านคำอธิบายประกอบ JSDoc ที่ระบุเป็นความคิดเห็น ข้อกำหนดโดยตรง ของประเภทโดยตรงในโครงสร้างการนิยามตัวแปร มันจะทำให้โค้ดมีภาพชัดเจนขึ้น เข้าใจง่ายขึ้น และแก้ไขได้ง่ายขึ้น.
ตัวอย่างเช่น IDE ที่เปิดใช้งาน TypeScript จะสามารถเน้นข้อผิดพลาดในโค้ด JavaScript ที่เขียนได้ทันทีโดยไม่ต้องแปลงเพิ่มเติม นอกจากนี้ การรองรับประเภทในตัวจะทำให้สามารถเรียกใช้โปรแกรมที่เขียนในภาษาจาวาสคริปต์แบบสคริปต์ เช่น TypeScript และ Flow โดยไม่ต้องแปลงจากภาษาหนึ่งไปอีกภาษาหนึ่ง
ประเภท ขอเสนอให้เพิ่ม "สตริง" "ตัวเลข" และ "บูลีน" ซึ่งสามารถใช้เมื่อกำหนดตัวแปร พารามิเตอร์ฟังก์ชัน องค์ประกอบอ็อบเจ็กต์ ฟิลด์คลาส อาร์เรย์ที่พิมพ์ ("number[]") นอกจากนี้ยังเสนอให้สนับสนุนประเภทผสม ("สตริง | หมายเลข") และชื่อสามัญ
จากทั้งหมดนี้ เราวางแผนที่จะนำเสนอข้อเสนอนี้สำหรับด่านที่ 1 ในการประชุมใหญ่ของ TC2022 ในเดือนมีนาคม 39 เราจะทำเช่นนั้นด้วยการสนับสนุนและคำแนะนำของ Rob Palmer จาก Bloomberg และ Romulo Cintra ที่ Igalia ซึ่งเป็นแชมป์ร่วมของเรา
การไปถึงขั้นที่ 1 จะหมายความว่าคณะกรรมการมาตรฐานเชื่อว่าไวยากรณ์ประเภทที่เข้ากันได้สำหรับ ECMAScript นั้นคุ้มค่าที่จะพิจารณา นี่ไม่ใช่สิ่งที่แน่นอน: มีมุมมองที่มีค่ามากมายภายในคณะกรรมการ และเราคาดว่าจะมีความสงสัยอยู่บ้าง ข้อเสนอเช่นนี้จะได้รับความคิดเห็นจำนวนมากและการพิจารณาอย่างละเอียดถี่ถ้วน อาจมีการเปลี่ยนแปลงการออกแบบมากมายระหว่างทางและอาจต้องใช้เวลาหลายปีกว่าจะได้ผลลัพธ์
ในการประชุมครั้งต่อไป ของเดือนมีนาคม ของคณะกรรมการ TC39 มีแผนจะย้ายไปยังขั้นตอนแรก การพิจารณาข้อเสนอด้วยการมีส่วนร่วมของชุมชนผู้เชี่ยวชาญ ECMA
ในที่สุด หากคุณสนใจที่จะทราบข้อมูลเพิ่มเติม คุณสามารถตรวจสอบรายละเอียดในไฟล์ ลิงค์ต่อไปนี้