ควรแยก JavaScript ออกเป็น 2 ภาษาหรือไม่?

 (devclass.com)
9 คะแนน โดย GN⁺ 2024-10-28 | 4 ความคิดเห็น | แชร์ทาง WhatsApp
  • วิศวกรของ Google นำเสนอข้อเสนออย่างเป็นทางการต่อคณะกรรมการกำหนดมาตรฐานให้แยก JavaScript ออกเป็นสองภาษา
    • เสนอให้แยกเป็นแกนหลักที่ถูกติดตั้งในเอนจินรันไทม์ และอีกแบบหนึ่งที่มีความสามารถมากกว่าโดยอาศัยเครื่องมือที่คอมไพล์มัน
  • มีการนำเสนอในที่ประชุม Emca TC39 เมื่อต้นเดือนนี้
    • TC39 คือคณะกรรมการของ Ecma International ที่พัฒนาสเปกของ JavaScript (ชื่อทางการคือ ECMAScript)
  • การนำเสนอจัดขึ้นโดย Shu-yu Guo จาก Google และมีผู้ร่วมเขียนสไลด์จาก Mozilla, Apple, Moddable และ Sony
    • Shu-yu เชี่ยวชาญด้าน JIT, VM, คอมไพเลอร์ และการกำหนดมาตรฐาน
  • ข้อโต้แย้งของผู้เขียน
    • ฟีเจอร์ใหม่ของภาษานั้นแทบจะทำให้ความปลอดภัยแย่ลงเสมอ และส่งผลเป็นกลางหรือเชิงลบต่อประสิทธิภาพ
    • ความเสถียรบางครั้งก็แย่ลง และความสามารถของแอปจะดีขึ้นก็ต่อเมื่อนักพัฒนาใช้ฟีเจอร์ใหม่เท่านั้น
    • JavaScript VM (เครื่องเสมือน) มีความซับซ้อนสูงมากอยู่แล้วจากแรงกดดันด้านความเร็ว ซึ่งบั่นทอนความปลอดภัย และยิ่งดูแย่เมื่อฟีเจอร์ใหม่ไม่ถูกนำไปใช้
    • เนื่องจากช่องโหว่ด้านความปลอดภัยและ 'ต้นทุนของความซับซ้อน' ของรันไทม์ส่งผลต่อการใช้งานนับพันล้านครั้ง ขณะที่ประโยชน์จำกัดอยู่เฉพาะนักพัฒนาและแอปพลิเคชันที่ใช้ประโยชน์จากความซับซ้อนนั้นจริง ๆ เทคโนโลยีฐานรากของ JavaScript จึงควรเรียบง่าย
  • แม้จะมีหลายองค์กรเข้าร่วม แต่โครงการริเริ่มนี้ดูเหมือนจะมี Google เป็นผู้นำอยู่พอสมควร
    • ในสไลด์แผ่นหนึ่งมีข้อความชี้แจงว่า "แนวทางแก้ไขที่เป็นไปได้นี้เป็นแนวทางที่ Google ต้องการ และไม่จำเป็นต้องเป็นแนวทางของผู้พัฒนารายอื่น"
  • แนวทางแก้ไขที่เสนอ
    • ไม่ใช่การย้อนฟีเจอร์เดิมกลับ แต่เป็นการเปลี่ยนแนวทางในอนาคตให้ฟีเจอร์ใหม่ส่วนใหญ่ถูกนำไปทำในเครื่องมือแทนที่จะอยู่ในเอนจิน
    • เรียกภาษาที่ติดตั้งในเอนจินว่า "JS0" และเรียกภาษาที่ติดตั้งผ่านเครื่องมือว่า "JSSugar"
    • เป็นแนวคิดที่เหมาะกับ JavaScript โดยเฉพาะ เพราะนักพัฒนาจำนวนมากเขียนโค้ดด้วย TypeScript อยู่แล้ว และพึ่งพาคอมไพเลอร์อย่าง Babel, Webpack และ TypeScript compiler
    • หากได้รับการยอมรับ ฟีเจอร์ด้านไวยากรณ์ในอนาคตจะไปอยู่ใน JSSugar ส่วน API และฟีเจอร์เชิงความสามารถจะไปอยู่ใน JS0
    • เอนจินที่รองรับก็เพียงแค่ต้องรองรับ JS0
    • ภาระจะถูกย้ายไปยังผู้พัฒนาเครื่องมือเพื่อรองรับ JSSugar
      • ผลข้างเคียงคือผู้พัฒนาเครื่องมือจะต้องมีส่วนร่วมกับกระบวนการมาตรฐานมากขึ้น และอาจต้องตั้งกลุ่มเทคนิคใหม่
  • ข้อเสนอนี้เป็นที่ถกเถียงแล้ว
    • มีนักพัฒนาที่ขอว่าอย่าให้เครื่องมือ JavaScript มีสถานะอย่างเป็นทางการ และนักพัฒนา JavaScript จำนวนมากก็อยากพึ่งพาเครื่องมือเหล่านี้ให้น้อยลง
    • แม้จะมีฉันทามติอย่างกว้างขวางว่าควรให้ความสำคัญกับความปลอดภัย ประสิทธิภาพ และความเสถียร แต่แนวคิดที่จะทำให้ JavaScript ต้องพึ่งพาเครื่องมือขั้นกลางกลับไม่ได้รับความนิยม
    • นักพัฒนาคนหนึ่งถึงกับพูดว่า "RIP Vanilla JS"

ความเห็นของ GN⁺

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

บทความที่เกี่ยวข้อง

4 ความคิดเห็น

 
kandk 2024-10-29

ดูเหมือนว่าพวกเขากำลังจะเพิ่มเลเยอร์ขึ้นมาอีกชั้นหนึ่ง และใส่สิ่งที่ช่วยด้าน DX ลงไปในเลเยอร์นั้น
 
savvykang 2024-10-29

นักพัฒนา JavaScript จำนวนมากต้องการพึ่งพาเครื่องมือเหล่านี้ให้น้อยลง
แนวคิดที่ทำให้ JavaScript ต้องพึ่งพาเครื่องมือคั่นกลางนั้นไม่เป็นที่นิยม

แค่ JSX เอง ในทางปฏิบัติก็มีระบบนิเวศที่ถูกสร้างขึ้นมาบนพื้นฐานว่าต้องทรานส์ไพล์อยู่แล้ว ผมจึงคิดว่านี่เป็นความเห็นที่ไม่สอดคล้องกับความเป็นจริง เหมือนกำลังคิดว่า NodeJS คือทุกอย่าง
 
aer0700 2024-10-29

ผมไม่แน่ใจว่าผมเข้าใจถูกเป๊ะไหม แต่ฟีลคล้าย ๆ กับที่มี BOOST ใน C++ นะครับ ถ้าข้อเสนอของ Google ได้รับการเห็นชอบและรวมไลบรารีเดิมเข้าไปใน JSSugar แล้ว จะมีอะไรเข้าไปบ้างครับ? Babel?
 
GN⁺ 2024-10-28
ความเห็นจาก Hacker News

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

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

  • ควรโฟกัสที่ WebAssembly มากกว่า โดยใช้ JavaScript สำหรับงานสคริปต์ และใช้ภาษาอื่นสำหรับแอปพลิเคชันขนาดใหญ่

  • ในฐานะคนที่ชอบ VanillaJS รู้สึกไม่พอใจกับฟีเจอร์ภาษาที่ถูกบังคับให้เปลี่ยน ควรเน้นปรับปรุง API เพื่อให้เว็บแอปทัดเทียมกับแอปเนทีฟ

  • ไม่เห็นด้วยกับคำกล่าวที่ว่า BigInt ไม่มีกรณีใช้งาน ถึงแม้นักพัฒนาฟรอนต์เอนด์ของ Google จะไม่ได้ใช้ แต่นักพัฒนา JS คนอื่น ๆ ก็กำลังใช้อยู่ ควรโฟกัสที่การพัฒนาภาษา

  • ควรแยก JavaScript กับ Wasm ออกจากกันตั้งแต่แรก แต่กลับทำให้ Wasm กลายเป็นพลเมืองชั้นสองที่เข้าถึง Web API ไม่ได้

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

  • ปัญหาเกิดจากการแยกตัวระหว่าง TC39 กับชุมชนนักพัฒนา เครื่องมือของ TypeScript ไม่ได้ถูกทำให้เป็นมาตรฐาน และก็ไม่มีแผนจะพอร์ตไป Rust

  • มีข้อเสนอให้เปลี่ยนแปลง JavaScript เนื่องจากปัญหาในการบำรุงรักษาเอนจิน V8 ของ Google ปัญหาด้านความปลอดภัยและต้นทุนจากความซับซ้อนส่งผลกระทบต่อผู้ใช้ ควรลองใช้ภาษาอื่นแทน C++