"เรากำลังใช้ Rust คอมไพล์ JavaScript ให้ออกมาเป็น JavaScript เพื่อเอาไปรันในเอนจินที่เกือบทั้งหมดเขียนด้วย C++"

ประโยคชวนคิดนี้มาจากบทความ "The JavaScript midlife crisis" ซึ่ง Maroun Baydoun วิศวกรซอฟต์แวร์ในเบอร์ลิน เผยแพร่เมื่อวันที่ 22 กันยายน 2026

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

ถ้าใครติดตามข่าวเครื่องมือสาย JavaScript อยู่เรื่อยๆ คงคุ้นตากับคำโฆษณาว่าเครื่องมือตัวใหม่ "เร็วกว่าเดิม 10 เท่า" ผู้เขียนยอมรับว่าเครื่องมือพวกนี้เร็วกว่าเดิมจริง แต่เขากลับตั้งคำถามในมุมที่ผลทดสอบความเร็วอย่าง benchmark ไม่เคยบอก นั่นคือ ความเร็วที่เพิ่มขึ้นมานี้ เราต้องแลกกับอะไร?

คำตอบของผู้เขียนคือ เราต้องแลกกับจำนวนคนที่สามารถเปิดอ่านโค้ดของเครื่องมือเหล่านั้น ทำความเข้าใจ ช่วยแก้บั๊ก หรือส่งโค้ดกลับไปพัฒนาโปรเจกต์ ซึ่งลดน้อยลงเรื่อยๆ

หลังจากมีคนนำบทความนี้ไปโพสต์ใน Hacker News เว็บบอร์ดสนทนาสายเทคโนโลยี ชุมชนนักพัฒนาก็เข้ามาถกเถียงกันจนแบ่งออกเป็นสองฝั่งชัดเจน และสำหรับนักพัฒนาทั่วไป คำถามสำคัญที่ตามมาคือ แล้วเราจำเป็นต้องไปเรียนภาษา Rust หรือ Go เพิ่มเติมด้วยหรือไม่?

30 ปีที่ไม่มีใครแทนที่ JavaScript ได้

ตลอด 30 ปีที่ผ่านมา มีคนพยายามหาภาษาใหม่มาแทนที่ JavaScript อยู่เรื่อยๆ เริ่มตั้งแต่ Microsoft ที่เคยใส่ VBScript และ JScript เข้ามาใน Internet Explorer ฝั่ง Macromedia ก็ผลักดัน ActionScript ผ่าน Flash ส่วน Google ก็เคยเดิมพันกับ Dart ก่อนที่ภายหลัง Dart จะย้ายไปเติบโตใน Flutter ขณะที่ CoffeeScript เลือกใช้วิธีเพิ่มไวยากรณ์ใหม่เพื่อให้เขียนโค้ดได้ง่ายขึ้น

ส่วนในช่วงที่ไม่ได้พยายามหาภาษาอื่นมาแทน นักพัฒนาก็ช่วยกันสร้างไลบรารีอย่าง jQuery, Lodash และ Moment.js มาเติมฟีเจอร์ที่ตัวภาษายังขาดอยู่

แต่ภาษาเดียวที่ประสบความสำเร็จอย่างแท้จริงคือภาษา TypeScript ซึ่งต่อยอดมาจาก JavaScript เพราะ TypeScript ยอมรับความจริงข้อสำคัญที่ภาษาอื่นไม่ยอมรับ นั่นคือ JavaScript จะไม่มีวันหายไปไหน ผู้เขียนสรุปไว้ว่า "คุณจะปรับปรุง จะซ่อน จะเขียนภาษาอื่นแล้วแปลงออกมาเป็นมัน หรือจะนั่งบ่นก็ได้ แต่ไม่มีทางกำจัดมันทิ้งได้แน่นอน"

ข้อดีของ toolchain ภาษาเดียวที่เราอาจมองข้ามไป

ผู้เขียนมองว่า การที่ JavaScript ครองระบบนิเวศทั้งหมดมีทั้งข้อดีและข้อเสีย แต่ตลอดหลายปีที่ผ่านมา เรามักจะพูดถึงแต่ข้อเสียจนลืมข้อดีสำคัญไป ข้อดีที่เขาเรียกว่า "พลังพิเศษ" นี้ซ่อนอยู่ในเรื่องธรรมดามากๆ

เครื่องมือใน toolchain ที่ผู้เขียนยกตัวอย่างมีอยู่ 4 กลุ่มหลัก:

• Linter สำหรับตรวจจับจุดผิดพลาดในโค้ด
• Bundler สำหรับรวมไฟล์โค้ดหลายๆ ไฟล์เข้าด้วยกันเพื่อให้เว็บเบราว์เซอร์โหลดไปใช้งานได้
• Formatter สำหรับจัดรูปแบบโค้ดให้เป็นระเบียบและเป็นมาตรฐานเดียวกันทั้งโปรเจกต์
• Test runner สำหรับรันชุดทดสอบที่เขียนไว้

จุดสำคัญคือ ตลอดหลายปีที่ผ่านมา เครื่องมือทั้งหมดนี้เขียนด้วยภาษา JavaScript ซึ่งเป็นภาษาเดียวกับโค้ดของแอปพลิเคชันที่เครื่องมือเหล่านี้ต้องตรวจ จัดรูปแบบ รวมไฟล์ และทดสอบ

ลองนึกภาพว่าถ้าวันหนึ่ง bundler ของโปรเจกต์ทำงานผิดพลาด นักพัฒนา JavaScript ทั่วไปก็สามารถเปิดเข้าไปดูโค้ดของตัว bundler ได้ทันที เพราะเป็นภาษาที่ตัวเองเขียนและอ่านอยู่ทุกวัน ทำให้มีโอกาสเข้าใจได้ว่าบั๊กเกิดจากอะไร อาจจะแก้ปัญหาได้ด้วยตัวเอง หรือส่งโค้ดแก้ไขกลับไปให้คนดูแลโปรเจกต์ได้ ผู้เขียนยังแซวไว้ว่า อย่างน้อยที่สุด เราก็รู้ภาษาดีพอจะโทษคนดูแลโปรเจกต์ได้อย่างมั่นใจว่าบั๊กเป็นความผิดของเขา

นอกจากนี้ การใช้ภาษาเดียวกันยังเปิดโอกาสให้นักพัฒนาย้ายจากฝั่งเบราว์เซอร์ไปสู่ฝั่งเซิร์ฟเวอร์ได้อย่างราบรื่น จนทำให้สายงานที่ทำได้ทั้งระบบอย่าง Full-stack Developer เติบโตขึ้นอย่างรวดเร็ว

ความเร็วที่แลกมาด้วยคนช่วยดูแล

แต่แล้ว ภาษาอย่าง Rust, Go และ Zig ก็เข้ามามีบทบาทมากขึ้น ภาษาเหล่านี้เป็นภาษาแบบคอมไพล์ คือแปลงโค้ดเป็นโปรแกรมที่เครื่องรันได้โดยตรง ปัจจุบันทั้งสามภาษากำลังเข้ามาแทนที่เครื่องมือใน toolchain ทีละชิ้น และขยายวงกว้างขึ้นเรื่อยๆ ด้วยเหตุผลง่ายๆ คือทำงานได้เร็วกว่าเดิมมาก

ผู้เขียนเข้าใจดีว่าคงไม่มีใครอยากนั่งรอแถบความคืบหน้านานๆ ตอนที่สั่ง build โค้ด แต่เมื่อเครื่องมือตัวใหม่โปรโมตว่าเร็วกว่าตัวเดิมถึง 10 เท่า ทั้งที่ของเดิมก็ทำงานได้เร็วพออยู่แล้ว เขาก็อดตั้งคำถามไม่ได้ว่า เสี้ยววินาทีที่ได้คืนมานั้น เราเอาไปทำอะไรได้บ้าง? ดื่มกาแฟเพิ่มได้อีกจิบหนึ่งหรือเปล่า?

แต่สิ่งที่ผู้เขียนกังวลมากกว่าคือสิ่งที่เราต้องเสียไป เพราะเมื่อมีคนเขียน bundler ขึ้นมาใหม่ด้วย Rust ความเร็วก็เพิ่มขึ้นจริง แต่จำนวนนักพัฒนา JavaScript ที่มีความรู้พอจะเข้าไปช่วยดูแลโปรเจกต์นั้นกลับลดลง ภายนอกเครื่องมือตัวใหม่ดูเหมือนเดิม แต่ไส้ในกลายเป็นอีกภาษาหนึ่ง และคนที่เข้าใจภาษานั้นก็เหลืออยู่น้อยลง

แม้โค้ดจะยังคงเปิดให้อ่าน แต่ประตูที่เปิดรับคนนอกเข้าไปช่วยพัฒนากำลังค่อยๆ ปิดลง

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

เมื่อคำว่า "Written in Rust" กลายเป็นจุดขาย

อีกประเด็นที่ผู้เขียนชี้ให้เห็นคือ พฤติกรรมเห่อเทคโนโลยีใหม่ โดยคำว่า "written in Rust" เริ่มกลายมาเป็นจุดขายทางการตลาด มากกว่าการอธิบายรายละเอียดทางเทคนิคว่าสร้างเครื่องมือขึ้นมาอย่างไร พอมีเครื่องมือตัวหนึ่งเขียนใหม่แล้วเร็วขึ้นมาก ตัวอื่นๆ ก็ทำตามกันมา จนทำให้การเขียนเครื่องมือด้วย JavaScript กลายเป็นตัวเลือกที่ดูด้อยไปโดยปริยาย

อย่างไรก็ตาม เขาย้ำว่าการเลือกใช้ภาษาแบบคอมไพล์ไม่ใช่เรื่องผิด และในหลายกรณีก็เป็นเครื่องมือที่เหมาะสมที่สุดด้วยซ้ำ สิ่งที่เขาอยากให้นักพัฒนาแยกให้ออกคือ ความต่างระหว่าง "เครื่องมือที่เหมาะกับงานนี้" กับ "เครื่องมือที่เราหยิบมาใช้กับทุกงาน เพียงเพราะงานนั้นดูคล้ายสิ่งที่คู่แข่งทำ" สองอย่างนี้อาจจะดูคล้ายกัน แต่วิธีคิดต่างกันอย่างสิ้นเชิง เพราะแบบแรกเริ่มจากตัวปัญหาตรงหน้า ส่วนแบบหลังเริ่มจากการทำตามกระแสคนอื่น

ผู้เขียนเปรียบเทียบภาพรวมทั้งหมดนี้ว่า เหมือนเรากำลังสร้างรางรถไฟความเร็วสูงขึ้นมาเรื่อยๆ ให้กับรถไฟหัวจักรไอน้ำที่วิ่งได้ช้า โดยรางรถไฟก็คือบรรดาเครื่องมือรอบตัว JavaScript ที่เราพยายามทุ่มแรงเร่งความเร็วให้ตลอดเวลา ส่วนขบวนรถไฟก็คือตัวภาษา JavaScript เอง ซึ่งยังคงเป็นปลายทางของโค้ดทั้งหมด ถ้าตัวรถไฟไม่ได้สร้างมาให้วิ่งเร็วตั้งแต่แรก การพัฒนาให้รางรองรับความเร็วได้มากขึ้นเรื่อยๆ ก็จะช่วยเพิ่มความเร็วให้ขบวนรถได้น้อยลงทุกที

ถึงอย่างนั้น ผู้เขียนก็มองว่าภาษาโปรแกรมต่างๆ สามารถอยู่ร่วมกันได้ และ JavaScript ก็ไม่จำเป็นต้องผูกขาดหรือครอบคลุมทุกส่วนของระบบ เพื่อรักษาความสำคัญของตัวเองไว้

สองฝั่งที่ถกเถียงกันบน Hacker News

ฝั่งที่มองว่าการย้ายภาษาคุ้มค่า

นักพัฒนาฝั่งแรกมองว่า ถ้านักพัฒนา JavaScript คนไหนอ่านภาษาอย่าง Rust หรือ Go ไม่ออก ก็ไม่ควรเข้ามารับหน้าที่ดูแลระบบโครงสร้างพื้นฐานสำคัญตั้งแต่แรก เหตุผลของฝั่งนี้คือ โค้ดของเครื่องมือเหล่านี้ส่วนใหญ่เปิดให้อ่านอยู่แล้ว สิ่งเดียวที่เป็นอุปสรรค คือนักพัฒนาจะยอมเปิดใจเรียนรู้ภาษาใหม่ๆ นอกโลกของ JavaScript หรือไม่เท่านั้น

นอกจากนี้ ฝั่งนี้ยังยืนยันว่าตัวภาษาส่งผลต่อเรื่องความเร็วอย่างชัดเจน มีผู้ใช้ในกระทู้ยกตัวอย่างคอมไพเลอร์ของ TypeScript ที่ทีมพัฒนาแปลงโค้ดไปเขียนด้วยภาษา Go แทบจะตรงตัว แทบไม่ได้รื้ออัลกอริทึมหลักหรือเปลี่ยนโครงสร้างข้อมูลมากนัก แต่ผลลัพธ์ที่ได้กลับเร็วขึ้นถึงประมาณ 10 เท่า เนื่องจาก JavaScript จัดการเรื่อง multithreading หรือการกระจายงานให้หลายแกนประมวลผลของ CPU ทำงานพร้อมกันได้ไม่ดีเท่า ซึ่งเรื่องความเร็วของ TypeScript ฉบับ Go เราเคยเขียนสรุปไว้อย่างละเอียดแล้ว

อีกคอมเมนต์ยังยกตัวอย่างอีกสองกรณีที่ย้ายไปใช้ WebAssembly ซึ่งช่วยแปลงโค้ดภาษาอื่นให้เบราว์เซอร์รันได้ เคสแรกคือเอนจินส่วนคำนวณของ Google Sheets ที่ระบุว่าทำงานเร็วขึ้นถึง 2 เท่า หลังจากย้ายจาก JavaScript ไปใช้เทคโนโลยีนี้ในเวอร์ชัน WasmGC ส่วนเคสที่สองคือแอปพลิเคชัน Prime Video ที่ระบุว่าเร็วขึ้น 2 เท่าเช่นกัน หลังจากเขียนใหม่ด้วย Rust แล้วคอมไพล์ออกมาเป็น WebAssembly

แต่ทั้งสองเคสนี้ก็มีคนเข้ามาแย้ง โดยมีอีกคอมเมนต์ชี้ว่า เคสของ Google Sheets นั้นเป็นการนำตัวเลขจากขั้นตอน build คนละขั้นตอน และรันบน runtime หรือสภาพแวดล้อมการทำงานคนละตัวมาเทียบกัน ส่วนเคสของ Prime Video ก็ไม่ได้เปิดเผยโค้ดที่ใช้วัดผลจริง เขาจึงสรุปว่าทั้งสองเคสยังเป็นการเทียบของคนละอย่าง จนกว่าจะมีหลักฐานพิสูจน์

ฝั่งที่เห็นว่ามีต้นทุนแฝงที่ต้องจ่าย

ฝั่งที่สองเห็นด้วยกับบทความต้นทาง โดยโต้แย้งฝั่งแรกว่า ระหว่าง "คนที่แค่เปิดโค้ดดูผ่านๆ เป็นครั้งคราว" กับ "คนที่เชี่ยวชาญระดับดูแลโครงสร้างพื้นฐานได้" ยังมีช่องว่างตรงกลางอยู่อีกมาก คอมเมนต์ฝั่งนี้อธิบายว่า การเข้าไปอ่านโค้ด open source ของเครื่องมือที่ใช้งานอยู่ทุกวัน คือบันไดขั้นสำคัญที่ช่วยให้นักพัฒนาหลายคนได้เรียนรู้และเติบโตในสายอาชีพ แต่พอเครื่องมือเหล่านั้นเปลี่ยนไปเขียนด้วยภาษาที่ไม่คุ้นเคย ก็กลายเป็นกำแพงขึ้นมาทันที แม้จะเป็นกำแพงที่ปีนข้ามได้ด้วยการเรียนรู้ แต่ก็ยังเป็นอุปสรรคอยู่ดี

นอกจากนี้ ยังมีคนชี้ให้เห็นต้นทุนทางเทคนิคที่จับต้องได้มากกว่านั้น เพราะหลังจากคอมไพเลอร์ของ TypeScript ย้ายไปเขียนด้วย Go ระบบนิเวศเครื่องมือของ JavaScript ก็แตกกระจายออกเป็น 3 ภาษาหลัก คือ Go, Rust และ JavaScript ข้อมูลส่งหากันภายใน Go ได้ราบรื่น แต่ส่งข้ามไปยังเครื่องมือที่เขียนด้วย Rust หรือ JavaScript ได้ไม่ดีนัก และถ้าต้องคัดลอกข้อมูลก้อนใหญ่ข้ามไปมา เครื่องมือก็ต้องหันไปประมวลผลทั้งก้อนทีเดียว แทนที่จะอัปเดตเฉพาะส่วนที่เปลี่ยนแปลง

ยิ่งไปกว่านั้น เครื่องมืออย่าง ts-morph ซึ่งเป็นไลบรารีสำหรับเขียนโปรแกรมเข้าไปอ่านและแก้ไขโค้ด TypeScript ก็ถูกทิ้งไว้โดยไม่มีตัวตายตัวแทน ผู้เขียนคอมเมนต์คนเดิมยังมองว่า จุดแข็งที่แท้จริงของเครื่องมือในโลก JavaScript คือระบบปลั๊กอินที่เปิดให้นักพัฒนาเขียนส่วนขยายเพิ่มเติมได้ง่าย โดยเขายกตัวอย่าง ESLint เครื่องมือตรวจโค้ดที่เปิดให้นักพัฒนาเขียนปลั๊กอินเพิ่มกฎของตัวเองได้ตามใจชอบ ซึ่งยังไม่มีเครื่องมือภาษาใหม่ตัวไหนมาทดแทนความยืดหยุ่นระดับนี้ได้สมบูรณ์

เขายังยกตัวอย่างเคสที่ย้ายสวนทางกันอย่างน่าสนใจ นั่นคือ VSCode โปรแกรมเขียนโค้ดยอดนิยม ที่เคยย้ายส่วนแกนกลางที่จัดการบัฟเฟอร์ข้อความจาก C++ กลับมาเขียนด้วย JavaScript แล้วปรากฏว่าทำงานได้เร็วกว่าเดิม

บางเสียงในกระทู้ยังตั้งข้อสังเกตว่า เครื่องมือ JavaScript หลายตัวที่เร็วขึ้นหลังเขียนใหม่ เป็นเพราะทีมงานออกแบบโครงสร้างและสถาปัตยกรรมของโค้ดใหม่ให้ดีขึ้น ไม่ใช่เพราะเปลี่ยนภาษาเพียงอย่างเดียว และมองว่าบทความประเภท "เราเขียนระบบใหม่ด้วย Rust" บ่อยครั้งมักเป็นการเปรียบเทียบที่ไม่แฟร์ และเน้นการตลาดมากกว่าเหตุผลทางเทคนิคล้วนๆ

ประโยคที่สะท้อนมุมมองของทั้งสองฝั่งได้ดีที่สุด มาจากคอมเมนต์หนึ่งที่สรุปไว้ว่า การย้ายภาษาคุ้มค่ากับความเร็วที่ได้มา แต่อย่าคิดว่าไม่มีต้นทุนอะไรเลย โดยเฉพาะต้นทุนในการเรียนรู้ของนักพัฒนารุ่นใหม่ ที่จะเติบโตขึ้นมาช่วยดูแลโปรเจกต์ open source เหล่านี้ในอนาคต

เราจำเป็นต้องไปเรียน Rust หรือ Go ไหม?

ความเห็นของเราคือ ถ้าคุณเป็นผู้ใช้งานเครื่องมือ ก็ไม่จำเป็นต้องเรียน เพราะงานประจำวันของคุณอาจไม่ต้องแตะภาษาที่อยู่ข้างในเลย

แต่ถ้าคุณเป็นคนที่อยากเข้าใจการทำงานลึกๆ อยากเปิดเข้าไปดูโค้ดของเครื่องมือที่ใช้งานอยู่ทุกวันเพื่อหาว่ามันพังตรงไหน การเรียนรู้ภาษาที่สองอย่าง Rust หรือ Go ก็เปรียบเสมือนใบเบิกทาง จุดเริ่มต้นที่ง่ายและใกล้ตัวนักพัฒนาสาย TypeScript มากที่สุด คือการลองเข้าไปอ่านโค้ดโปรเจกต์ คอมไพเลอร์ TypeScript ฉบับ Go ของ Microsoft ซึ่งเปิดให้อ่านบน GitHub อยู่แล้ว

มีนักพัฒนาคนหนึ่งในกระทู้เล่าประสบการณ์ว่า พอได้ลองเรียน Go ก็พบว่ามันไม่ได้ต่างจาก JavaScript มาก และการรู้ภาษาที่สองยังช่วยเปิดมุมมองและวิธีคิดในการเขียนโปรแกรมให้กว้างขึ้นกว่าเดิมด้วย

ท้ายที่สุดแล้ว การตัดสินใจขึ้นอยู่กับเป้าหมายของคุณเอง ถ้าเลือกไม่เรียน คุณก็ยังใช้งานเครื่องมือได้ตามปกติ เพียงแต่วันใดที่เครื่องมือมีปัญหา คุณอาจทำได้แค่รอให้คนดูแลโปรเจกต์เป็นคนแก้บั๊กให้ แต่ถ้าสละเวลามาเรียนรู้ คุณก็จะสามารถเข้าไปแกะโค้ดและช่วยแก้ปัญหาของเครื่องมือเหล่านั้นได้

สำหรับใครที่เริ่มจากสาย JavaScript และกำลังมองหาภาษาที่สองเพื่ออัปสกิล การเลือกเรียน Go หรือ Rust ถือเป็นตัวเลือกที่ได้ประโยชน์สองต่อ ทั้งได้ฝึกภาษาใหม่ และยังเปิดเข้าไปอ่านโค้ดของเครื่องมือระดับโลกที่เราใช้งานอยู่จริงได้อีกด้วย

4 ข้อที่ควรเช็กก่อนตัดสินใจเปลี่ยน toolchain

ถ้าคุณเป็นหัวหน้าทีมที่กำลังพิจารณาว่าจะเปลี่ยนเครื่องมือในโปรเจกต์ดีไหม นี่คือ 4 ข้อคิดสำคัญที่สรุปได้จากข้อถกเถียงของทั้งสองฝั่ง:

1. วัดเวลาบนโปรเจกต์จริงของตัวเองก่อนปักใจเชื่อตัวเลขโปรโมต ตัวเลขความเร็วที่โฆษณาไว้ในประกาศไม่ได้ทดสอบบนโค้ดในโปรเจกต์จริงของคุณ และในกระทู้เองก็ยังเถียงกันว่าหลายเคสเทียบในสภาพแวดล้อมที่ต่างกัน วิธีทดสอบที่ง่ายและตรงไปตรงมาที่สุด คือการใส่คำสั่ง time นำหน้าคำสั่ง build เดิม เช่น time npm run build แล้วจดเวลาของเครื่องมือเดิมกับเครื่องมือตัวใหม่ไว้เทียบกัน
2. ตรวจสอบให้แน่ใจว่าปลั๊กอินที่ทีมต้องพึ่งพายังทำงานต่อได้ หากเครื่องมือตัวใหม่ยังไม่รองรับปลั๊กอินสำคัญที่ทีมของคุณต้องพึ่งพาอยู่ทุกวัน ความเร็วในการ build ที่เพิ่มขึ้นมา อาจไม่คุ้มกับความสามารถหรือฟีเจอร์ที่ทีมต้องเสียไป
3. ประเมินว่าหากเกิดปัญหาขึ้นตอนนำระบบขึ้นใช้งานจริง คนในทีมสามารถเข้าไปดูโค้ดได้เองหรือไม่ หรือทีมต้องรอความช่วยเหลือจากคนดูแลโปรเจกต์เพียงอย่างเดียว
4. ถามตัวเองว่าความเร็วที่เพิ่มขึ้นมา แก้ปัญหาคอขวดของทีมได้จริงหรือเปล่า หากเวลา build โค้ดไม่เคยเป็นอุปสรรคในการทำงานของทีม การได้เวลาคืนมาเพียงไม่กี่เสี้ยววินาทีก็อาจไม่มีผลอะไรเลย นอกจากการได้จิบกาแฟเพิ่มอีกสักจิบตามที่ผู้เขียนแซวไว้

สิ่งที่ Benchmark ไม่เคยบอกเรา

ความเร็วเป็นตัวเลขที่วัดได้ทันทีตั้งแต่วันแรกที่เปลี่ยนเครื่องมือ แต่ต้นทุนเรื่องจำนวนคนที่เข้าไปช่วยดูแลและแก้โค้ดได้ จะเห็นชัดก็ในวันที่เครื่องมือตัวนั้นพังขึ้นมาจริงๆ

ผู้เขียนบทความทิ้งท้ายไว้ด้วยคำถามชวนคิดว่า เราจะพาระบบนิเวศไปในทิศทางนี้ได้อีกไกลแค่ไหน ก่อนที่การรื้อเทคโนโลยีเว็บแล้วสร้างใหม่ตั้งแต่ฐานรากจะดูเป็นทางออกที่สมเหตุสมผลกว่า

แล้วสำหรับคุณล่ะ เครื่องมือ JavaScript ตัวไหนที่ย้ายไปเขียนด้วย Rust หรือ Go แล้วช่วยให้ชีวิตการทำงานดีขึ้นจริง หรือมีตัวไหนที่ย้ายแล้วเจอปัญหาบ้าง? มาร่วมแชร์ประสบการณ์และพูดคุยกันได้ในช่องคอมเมนต์

---

ที่มา:

• บทความ The JavaScript midlife crisis จาก Maroun Baydoun
• กระทู้ The JavaScript Midlife Crisis จาก Hacker News