เครื่องมือใหม่ที่ชื่อว่า tsbro สัญญาว่าจะสามารถรัน TypeScript ได้โดยตรงในเบราว์เซอร์โดยไม่ต้องผ่านขั้นตอนการ build แต่นักพัฒนาต่างตั้งคำถามเกี่ยวกับแนวทางทางเทคนิคและผลกระทบต่อประสิทธิภาพ เครื่องมือนี้มีเป้าหมายที่จะแก้ปัญหาการที่ TypeScript เป็นภาษาระดับรองในเบราว์เซอร์โดยการข้ามระบบ import แบบดั้งเดิม
ข้อมูลจำเพาะทางเทคนิค:
- ใช้ SWC WebAssembly สำหรับการคอมไพล์ TypeScript (ขนาดดาวน์โหลด 5MB+)
- ใช้ synchronous XHR สำหรับการดึงไฟล์
- แปลง ES modules เป็นรูปแบบ CommonJS
- รองรับ JSX พร้อมการกำหนดค่า pragma ได้
- ต้องใช้ importmap สำหรับการจัดการแพ็กเกจ
ปัญหาประสิทธิภาพจากแนวทางการใช้ Synchronous XHR
ความขัดแย้งหลักมุ่งเน้นไปที่การใช้ synchronous XMLHttpRequest (XHR) ของ tsbro ในการดึงและคอมไพล์ไฟล์ TypeScript แนวทางนี้ได้รับการวิพากษ์วิจารณ์จากนักพัฒนาที่มีประสบการณ์ซึ่งเตือนเกี่ยวกับปัญหาประสิทธิภาพที่รุนแรง ลักษณะ synchronous หมายความว่าเบราว์เซอร์ต้องรอให้แต่ละไฟล์ดาวน์โหลดและคอมไพล์เสร็จก่อนที่จะไปยังไฟล์ถัดไป ซึ่งสร้างคอขวดที่อาจทำให้โปรเจ็กต์ขนาดใหญ่ใช้งานไม่ได้
เครื่องมือนี้ทำงานโดยการดึงโค้ด TypeScript แบบ synchronous แล้วแปลงด้วย SWC WebAssembly แปลง ES modules เป็นรูปแบบ CommonJS แล้วประเมินผลลัพธ์ แม้ว่าจะสร้างประสบการณ์การพัฒนาที่ราบรื่น แต่ก็มาพร้อมกับข้อแลกเปลี่ยนที่สำคัญ
หมายเหตุ: Synchronous XHR บล็อก main thread ของเบราว์เซอร์ ป้องกันไม่ให้การดำเนินการอื่นๆ ทำงานได้จนกว่าคำขอจะเสร็จสิ้น
ปัญหาด้านประสิทธิภาพ:
- XHR แบบ Synchronous ทำให้ main thread ของเบราว์เซอร์หยุดทำงาน
- ประสิทธิภาพแย่สำหรับ module graph ขนาดใหญ่
- ต้องดาวน์โหลด WebAssembly ขนาด 5MB+ ในครั้งแรก
- Stack traces อ่านยากเนื่องจากการ transpilation
- ยังไม่มี source map support ในขณะนี้
แนวทางทางเลือกและความท้าทายทางเทคนิค
การสนทนาในชุมชนเผยให้เห็นแนวทางทางเลือกหลายแบบที่สามารถแก้ไขปัญหาประสิทธิภาพเหล่านี้ได้ นักพัฒนาบางคนแนะนำให้ใช้ service workers เพื่อดักจับคำขอ TypeScript และคอมไพล์แบบ asynchronous ในพื้นหลัง วิธีนี้จะหลีกเลี่ยงการบล็อก main thread ของเบราว์เซอร์ในขณะที่ยังคงให้ฟังก์ชันการทำงานที่ต้องการ
แนวทางแก้ไขอื่นที่เสนอคือการเดิน import graph แบบ asynchronous เพื่อรวบรวมไฟล์ทั้งหมดก่อน จากนั้นส่งผ่านคอมไพเลอร์แบบ batch แนวทางนี้ถูกใช้สำเร็จแล้วโดยโปรเจ็กต์ Playground Elements ของ Google สำหรับตัวอย่างโค้ดแบบโต้ตอบ
อย่างไรก็ตาม ทางเลือกเหล่านี้ก็เผชิญกับความท้าทายของตัวเอง แพ็กเกจ SWC WebAssembly ที่ tsbro ใช้มีขนาดมากกว่า 5MB ซึ่งต้องดาวน์โหลดก่อนที่จะเริ่มการคอมไพล์ใดๆ ได้ สิ่งนี้สร้างการลงโทษการโหลดครั้งแรกที่สำคัญซึ่งส่งผลต่อประสบการณ์ผู้ใช้
แนวทางทางเลือก:
- การคอมไพล์แบบใช้ service worker (ใช้โดย sucrase-build-iife )
- การเดินผ่าน import graph แบบอะซิงโครนัส ( Google Playground Elements )
- การคอมไพล์ฝั่งเซิร์ฟเวอร์ด้วย endpoint เฉพาะ
- โซลูชันที่เน้น WebAssembly สำหรับการรองรับข้ามภาษา
ผลกระทบที่กว้างขึ้นสำหรับการพัฒนาเว็บ
การสนทนาเกี่ยวกับ tsbro สะท้อนให้เห็นการถกเถียงที่ใหญ่กว่าเกี่ยวกับความซับซ้อนของเบราว์เซอร์และเวิร์กโฟลว์การพัฒนา นักพัฒนาบางคนโต้แย้งว่าการเพิ่มฟีเจอร์เข้าไปในเบราว์เซอร์เพิ่มความซับซ้อนและสร้างภาระการบำรุงรักษาระยะยาวเนื่องจากข้อกำหนดความเข้ากันได้แบบย้อนหลัง พวกเขาแนะนำให้มุ่งเน้นไปที่การปรับปรุงการสนับสนุน WebAssembly แทน ซึ่งจะช่วยให้นักพัฒนาใช้ภาษาใดก็ได้ในขณะที่ API ของเบราว์เซอร์ยังคงเรียบง่าย
คนอื่นๆ ชี้ให้เห็นว่านักพัฒนาต้องการการเข้าถึงระดับแรกไปยัง browser APIs อย่าง DOM โดยไม่มีการลงโทษประสิทธิภาพ ทำให้เครื่องมืออย่าง tsbro มีคุณค่าแม้จะมีข้อจำกัด ความท้าทายอยู่ที่การสร้างสมดุลระหว่างความสะดวกของนักพัฒนากับประสิทธิภาพทางเทคนิคและความยั่งยืนระยะยาว
บทสรุป
แม้ว่า tsbro จะแก้ไขความต้องการที่แท้จริงสำหรับเวิร์กโฟลว์การพัฒนา TypeScript ที่เรียบง่ายกว่า แต่การใช้งานปัจจุบันทำให้เกิดความกังวลที่สมเหตุสมผลเกี่ยวกับประสิทธิภาพและความสามารถในการขยายตัว การสนทนาในชุมชนเน้นย้ำถึงความตึงเครียดที่ดำเนินต่อไประหว่างประสบการณ์นักพัฒนาและการเพิ่มประสิทธิภาพทางเทคนิคในเครื่องมือพัฒนาเว็บ เมื่อโปรเจ็กต์พัฒนาต่อไป การแก้ไขปัญหาประสิทธิภาพเหล่านี้ผ่านสถาปัตยกรรมทางเลือกอย่าง service workers หรือการคอมไพล์แบบ asynchronous อาจช่วยให้บรรลุศักยภาพในขณะที่หลีกเลี่ยงข้อผิดพลาดของการดำเนินการแบบ synchronous
อ้างอิง: tsbro