ในความไม่คาดฝันของวงการพัฒนาเว็บ ปลั๊กอิน Vite ใหม่ที่มีชื่อว่า vite-plugin-use-golang ได้เปิดโอกาสให้นักพัฒนาเขียนโค้ดภาษา Go โดยตรงภายในไฟล์ JavaScript โดยทำการคอมไพล์เป็น WebAssembly ในขั้นตอนการบิลด์ ปลั๊กอินดังกล่าวได้จุดประกายการอภิปรายอย่างร้อนแรงทั่วทั้งชุมชนนักพัฒนาเกี่ยวกับความเหมาะสมและความฉลาดหลักแหลมในการผสมผสานภาษาโปรแกรมในรูปแบบที่ไม่เป็นไปตามธรรมเนียมปฏิบัติเช่นนี้
แนวทางที่ไม่เป็นไปตามธรรมเนียมในการพัฒนาเว็บ
กลไกการทำงานของปลั๊กอินเป็นไปอย่างเรียบง่ายแต่น่าประหลาดใจ: นักพัฒนาเพียงเพิ่ม use golang ที่ด้านบนของไฟล์ JavaScript ใดๆ จากนั้นจึงเขียนโค้ด Go มาตรฐานตามลงไป ในระหว่างกระบวนการบิลด์ Vite จะแยกโค้ด Go ออกมา คอมไพล์เป็น WebAssembly โดยใช้ TinyGo และทำให้ฟังก์ชันที่คอมไพล์แล้วสามารถเรียกใช้ได้ผ่านออบเจ็กต์ window ส่วนกลาง เหมือนเป็นฟังก์ชัน JavaScript ทั่วไป วิธีการนี้เลี่ยงการแยกความรับผิดชอบตามแบบดั้งเดิมระหว่างภาษาสำหรับส่วนหน้าและส่วนหลัง สร้างสิ่งที่นักพัฒนาบางส่วนเรียกว่าประสบการณ์การพัฒนาที่พิลึกแต่มีอยู่จริง
การดำเนินการทางเทคนิคเกี่ยวข้องกับการแยกโค้ด Go ไปยังไฟล์ชั่วคราวโดยอัตโนมัติ รันการคอมไพล์ด้วย TinyGo โดยตั้งเป้าเป็น WebAssembly และรวมไฟล์ WASM ที่ได้เข้ากับแอปพลิเคชัน ฟังก์ชันที่เปิดเผยผ่านเมธอด js.Global().Set() ของ Go จะสามารถเรียกใช้จาก JavaScript ได้ทันที สร้างสะพานเชื่อมระหว่างสองสภาพแวดล้อมอย่างราบรื่น
แทนที่จะมีคำสั่ง 'use golang' ก็ควรอนุญาตให้นำเข้าไฟล์ .go ได้แทน นี่เป็นวิธีที่สอดคล้องกับตัวรวม JS มากกว่า
ข้อกำหนดสำคัญ:
- ต้องใช้ TinyGo แทน Go มาตรฐานเพื่อให้ได้ขนาดไฟล์ WASM ที่เหมาะสม
- ฟังก์ชันต้องตรงกับรูปแบบ:
func(this js.Value, args []js.Value) interface{} - ใช้
js.Global().Set()เพื่อเปิดเผยฟังก์ชันให้กับ JavaScript (ไม่ใช่คอมเมนต์ //export) - Hot Module Replacement จะทำให้เกิดการโหลดหน้าเว็บใหม่ทั้งหมดเมื่อมีการเปลี่ยนแปลงโค้ด Go
การประยุกต์ใช้จริง เทียบกับ ความกังวลเชิงปรัชญา
ชุมชนนักพัฒนาดูจะแตกออกเป็นสองฝ่ายในเรื่องคุณค่าทางปฏิบัติของปลั๊กอิน ผู้สนับสนุนชี้ให้เห็นกรณีใช้งานที่มีเหตุผลซึ่งไลบรารีมาตรฐานอันแข็งแกร่งของ Go สามารถให้ข้อได้เปรียบอย่างมีนัยสำคัญในสภาพแวดล้อมเบราว์เซอร์ การประมวลผลภาพเป็นตัวอย่างชั้นเยี่ยม - โดยความสามารถในการจัดการภาพของ Go สามารถแทนที่โค้ด JavaScript ที่ซับซ้อนนับร้อยบรรทัดด้วยโค้ด Go ที่กระชับและผ่านการทดสอบมาแล้ว ประโยชน์ในทำนองเดียวกันอาจนำไปใช้กับการเข้ารหัสลับ การแยกวิเคราะห์ข้อมูลสำหรับรูปแบบที่ไม่ธรรมดา และสถานการณ์การคำนวณทางวิทยาศาสตร์ที่นักพัฒนามีฐานโค้ด Go จำนวนมากอยู่แล้ว
อย่างไรก็ตาม ผู้ที่ยังสงสัยตั้งคำถามว่ากรณีใช้งานเหล่านี้สามารถชี้วัดความซับซ้อนที่เพิ่มเข้ามาได้หรือไม่ บางคนแย้งว่าสำหรับงานที่ใช้การคำนวณหนัก เช่น การประมวลผลเสียงหรือวิดีโอ เบราว์เซอร์ยังคงเป็นสภาพแวดล้อมที่ไม่เหมาะสม ไม่ว่าภาษาที่ใช้จะเป็นอะไรก็ตาม บางคนตั้งข้อสังเกตว่าเบราว์เซอร์มี API ดั้งเดิมอันทรงพลังสำหรับงานเหล่านี้หลายงานอยู่แล้ว ตั้งแต่ WebGL และ WebGPU สำหรับกราฟิกส์ ไปจนถึงฟังก์ชันการเข้ารหัสลับในตัว ผลประโยชน์ด้านประสิทธิภาพของ WASM เมื่อเทียบกับ JavaScript ที่ได้รับการปรับแต่งให้เหมาะสมแล้วก็ถูกตั้งคำถามเช่นกัน โดยนักพัฒนาบางส่วนเสนอแนะว่าโอเวอร์เฮดจากการย้ายข้อมูลระหว่าง JavaScript และ WebAssembly อาจลบล้างข้อได้เปรียบทางการคำนวณใดๆ ที่มี
ผลกระทบในวงกว้างต่อการพัฒนาเว็บ
เหนือไปกว่าการพิจารณาทางเทคนิคในทันที ปลั๊กอินนี้ทำให้เกิดคำถามเกี่ยวกับธรรมชาติที่กำลังพัฒนาของเวิร์กโฟลว์การพัฒนาเว็บ แนวทางนี้แสดงถึงการเบี่ยงออกจากรูปแบบดั้งเดิมของตัวรวม (bundler) ซึ่งการนำเข้าไฟล์ Go แยกต่างหากจะดูเป็นธรรมชาติมากกว่าสำหรับนักพัฒนา JavaScript สมาชิกในชุมชนบางส่วนมองว่านี่เป็นอาการของสิ่งที่พวกเขาเรียกว่า การติดเชื้อ React/Vercel - ความคิดที่ไม่เป็นไปตามธรรมเนียมที่ให้ความสำคัญกับความใหม่มากกว่าลวดลายที่ตั้งมั่นแล้ว
กระนั้น การมีอยู่ของปลั๊กอินนี้ก็เน้นย้ำถึงเทรนด์ที่กำลังเติบโต: ขอบเขตระหว่างโดเมนการพัฒนาที่แยกจากกันตามธรรมเนียมกำลังมีความพรุนเพิ่มมากขึ้น ดังที่นักพัฒนาคนหนึ่งระบุ พวกเขาเคยใช้เทคนิคที่คล้ายกันเพื่อสร้างฟังก์ชันการทำงานแบบ WASM ที่ทำหน้าที่เป็นทางเลือกสำรองเมื่อ API ไม่พร้อมใช้งานหรือผู้ใช้ทำงานออฟไลน์ ลวดลายการใช้งาน WebAssembly นี้เพื่อขยายขีดความสามารถของเบราว์เซอร์โดยไม่ต้องพึ่งพาเซิร์ฟเวอร์ แสดงให้เห็นถึงแนวทางใหม่ในการสร้างแอปพลิเคชันเว็บที่มีความยืดหยุ่นมากขึ้น
การอภิปรายขยายไปถึงการพิจารณาด้านประสิทธิภาพ โดยนักพัฒนาถกเถียงกันว่าเบราว์เซอร์สมัยใหม่เป็นตัวแทนของทรัพยากรการคำนวณที่ถูกใช้ไม่เต็มที่หรือไม่ บางคนแย้งว่าการใช้ประโยชน์จากพลังการประมวลผลฝั่งไคลเอ็นต์สำหรับงานที่ใช้ทรัพยากรหนักเป็นเรื่องที่สมเหตุสมผล โดยเฉพาะเมื่ออุปกรณ์ของผู้ใช้มักมีขีดความสามารถเหนือกว่าเซิร์ฟเวอร์ ในขณะที่บางคนยืนยันว่า API เฉพาะทางของเบราว์เซอร์และ JavaScript ที่ได้รับการปรับแต่งให้เหมาะสมแล้วยังคงเป็นเส้นทางที่มีประสิทธิภาพสูงสุดสำหรับแอปพลิเคชันเว็บส่วนใหญ่
ตัวเลือกการกำหนดค่า Plugin:
tinygoPath: เส้นทางไปยังไฟล์ binary ของ TinyGo (ค่าเริ่มต้น: "tinygo")buildDir: ไดเรกทอรีสำหรับไฟล์ที่คอมไพล์แล้ว (ค่าเริ่มต้น: ".vite-golang")optimization: แฟล็กการเพิ่มประสิทธิภาพของ TinyGo (ค่าเริ่มต้น: "z" สำหรับขนาดที่เล็กที่สุด)generateTypes: สร้างไฟล์คำจำกัดความ TypeScript (ค่าเริ่มต้น: true)cleanupDays: ลบ build เก่าอัตโนมัติหลังจากจำนวนวันที่กำหนด (ค่าเริ่มต้น: 7)
การหาจุดสมดุลที่เหมาะสม
ในขณะที่ภูมิทัศน์ของการพัฒนาเว็บยังคงพัฒนาต่อไป เครื่องมืออย่าง vite-plugin-use-golang ก็ทำหน้าที่เป็นตัวเริ่มบทสนทนาที่สำคัญเกี่ยวกับอนาคตของการพัฒนาข้ามภาษา แม้ว่าปลั๊กอินนี้อาจไม่กลายเป็นแนวปฏิบัติมาตรฐานสำหรับโปรเจกต์ส่วนใหญ่ แต่มันก็แสดงให้เห็นถึงความคิดสร้างสรรค์ที่กำลังผลักดันวงการพัฒนาเว็บให้ก้าวไปข้างหน้า ปฏิกิริยาที่หลากหลายของชุมชน - ตั้งแต่การยอมรับอย่างกระตือรือร้น ไปจนถึงการปฏิเสธด้วยความสงสัย - สะท้อนให้เห็นถึงความตึงเครียดอย่างต่อเนื่องระหว่างลวดลายที่ตั้งมั่นแล้วกับแนวทางใหม่ๆ ในสาขาที่เปลี่ยนแปลงอย่างรวดเร็ว
คุณค่าสูงสุดอาจไม่ได้อยู่ที่การถูกนำไปใช้อย่างกว้างขวาง แต่อยู่ที่การท้าทายสมมติฐานเกี่ยวกับว่าอะไรควรอยู่ที่ไหนในสแต็กการพัฒนาเว็บ อย่างที่ผู้เขียนยอมรับเอง บางครั้งความคิดที่โง่ที่สุดก็คือความคิดที่สนุกที่สุดในการสร้างต้นแบบ - และจากแบบทดลองเช่นนี้ บางครั้งลวดลายที่มีประโยชน์อย่างแท้จริงก็เกิดขึ้นมา
อ้างอิง: vite-plugin-use-golang