รันไทม์ JavaScript ตัวใหม่ชื่อ Ant มีขนาดราว 8 MB ส่วน Node.js ซึ่งเป็นรันไทม์หลักที่คนทั้งวงการใช้กันอยู่ มีขนาดราว 120 MB

รันไทม์ในที่นี้คือโปรแกรมที่ใช้รันโค้ด JavaScript นอกเบราว์เซอร์ ทั้งบนเซิร์ฟเวอร์และบนเครื่องของตัวเอง ที่ผ่านมามีให้เลือกอยู่สามตัวคือ Node · Bun · Deno โดยสองตัวหลังเป็นรันไทม์รุ่นใหม่ที่ขึ้นมาท้าชิงกับ Node แต่แล้วก็มีตัวที่สี่โผล่มาพร้อมตัวเลขที่อ่านแล้วต้องมองซ้ำ นอกจากขนาดไฟล์จะเล็กกว่า Node สิบห้าเท่า Ant ยังสตาร์ตในราว 5 ms ขณะที่ Node ใช้เวลาราว 31 ms

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

ตัวเลขสองตัวที่ทำให้คนหันมามอง

ตัวเลขชุดแรกคือขนาดของ binary หรือไฟล์โปรแกรมที่ดาวน์โหลดไปติดตั้ง โดย Ant อยู่ที่ราว 8 MB · Bun ราว 60 MB · Deno ราว 90 MB · Node ราว 120 MB ส่วนตัวเลขชุดที่สองคือ cold start หรือเวลาตั้งแต่รันไทม์เริ่มทำงานจนพร้อมรับงานจริง โดย Ant อยู่ที่ราว 5 ms · Bun ราว 13 ms · Deno ราว 25 ms · Node ราว 31 ms

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

ที่ edge หรือเซิร์ฟเวอร์เล็กๆ ที่กระจายอยู่ใกล้ผู้ใช้ทั่วโลก ขนาดไฟล์ยิ่งสำคัญ เพราะพื้นที่จัดเก็บและหน่วยความจำมีจำกัด ไฟล์ขนาด 120 MB กับ 8 MB จึงกินพื้นที่ต่างกันมาก เช่นเดียวกับเครื่องมือบรรทัดคำสั่งที่อยากให้คนดาวน์โหลดไปใช้ได้ง่ายๆ และอุปกรณ์ฝังตัวที่มีพื้นที่จัดเก็บเพียงระดับเมกะไบต์

ต้องบอกให้ชัดว่าตัวเลขทั้งหมดมาจากการวัดของโปรเจกต์เอง ข้อมูลนี้เผยแพร่ทั้งบนหน้าเว็บทางการ antjs.org และในเอกสาร README ของคลังโค้ดบน GitHub โดยยังไม่มีการวัดจากคนนอกมายืนยัน

ข้อดีคือโปรเจกต์ระบุวิธีวัดไว้ครบ โดยใช้ hyperfine ซึ่งเป็นเครื่องมือจับเวลาคำสั่งบนเทอร์มินัล วอร์มอัป 10 รอบ แล้ววัดจริงอีก 100 รอบบนเครื่อง Apple M5 Pro สคริปต์ที่ใช้วัดจะโหลด Hono ซึ่งเป็นเว็บเฟรมเวิร์ก จากนั้นกำหนด route สองรายการและปิดตัวเองทันที ไม่ได้เปิดเซิร์ฟเวอร์รับทราฟฟิกจริง ตัวเลขชุดนี้จึงวัดเฉพาะช่วงสตาร์ต ไม่ใช่ประสิทธิภาพเมื่อรับงานหนัก นอกจากนี้ ถ้าไล่ดูละเอียดจะพบว่าค่าที่โปรเจกต์รายงานในแต่ละหน้ายังขยับไปมานิดหน่อย บางหน้า 5.4 ms บางหน้า 5.5 ms ลำดับผลตรงกันทุกหน้า แต่ทศนิยมไม่ตรงกันเป๊ะ

Ant Silver คือเอนจินที่เขียนขึ้นเองทั้งหมด

สิ่งที่ทำให้ Ant ไม่ใช่แค่โปรเจกต์ที่ใครทำเล่นๆ คือเอนจิน Ant Silver ที่เขียนขึ้นใหม่ทั้งหมด โดยไม่ได้นำเอนจินสำเร็จรูปอย่าง V8 · JavaScriptCore หรือ SpiderMonkey มาใช้เป็นแกนหลัก

ความต่างข้อนี้อธิบายตัวเลขในหัวข้อที่แล้วได้เกือบทั้งหมด V8 คือเอนจิน JavaScript ของ Google ที่อยู่ทั้งใน Chrome และ Node ส่วน JavaScriptCore คือเอนจินฝั่ง Safari ที่ Bun นำมาใช้ เอนจินเหล่านี้ผ่านการขัดเกลามาสิบกว่าปีและเร็วมากก็จริง แต่มีขนาดใหญ่ ใครนำไปใช้ก็ต้องรวมขนาดของเอนจินเข้าไปในไฟล์โปรแกรมด้วย รันไทม์ที่สร้างบนเอนจินสำเร็จรูปจึงมีขนาดเล็กกว่าตัวเอนจินไม่ได้ ต่อให้เขียนส่วนที่เหลือดีแค่ไหนก็ตาม

ฝั่ง Ant เลือกทางที่ยากกว่าด้วยการลงมือเขียนเอนจินเอง โค้ดในโปรเจกต์เป็นภาษา C ราว 74% และ Zig อีกราว 6% ส่วน JIT คือกลไกที่แปลงโค้ดเป็นภาษาเครื่องขณะรันเพื่อให้ทำงานเร็วขึ้น โดยใช้ MIR ซึ่งเป็นแบ็กเอนด์คอมไพเลอร์ขนาดเล็กที่โปรเจกต์ fork มาพัฒนาต่อเอง

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

รันแพ็กเกจ npm เดิม และรัน TypeScript ได้โดยไม่ต้อง build

รันไทม์จะเล็กแค่ไหนก็ไม่มีประโยชน์ ถ้าต้องทิ้งแพ็กเกจเดิมทั้งหมด Ant จึงรองรับแพ็กเกจจาก npm ซึ่งเป็นคลังแพ็กเกจของโลก JavaScript ได้ตามปกติ คำสั่งติดตั้งคือ ant i <ชื่อแพ็กเกจ> หน้าเว็บของโปรเจกต์อ้างว่าติดตั้งได้เร็วกว่า npm ถึง 40 เท่า พร้อมแสดงตัวอย่างการติดตั้ง Hono ที่เสร็จใน 155 ms ตัวเลขนี้เป็นคำโฆษณาของผู้พัฒนาเองและยังไม่มีใครนอกโปรเจกต์ยืนยัน จึงควรฟังไว้เฉยๆ ก่อน

อีกจุดที่น่าสนใจกว่าคือ TypeScript ซึ่งเป็น JavaScript ที่เติมระบบชนิดข้อมูลเข้าไป โดยปกติต้องคอมไพล์ก่อนด้วย tsc && node dist/app.js จึงจะรันได้ แต่ Ant สั่ง ant app.ts ได้ทันที ไม่ต้องมีไฟล์ตั้งค่า tsconfig ให้ปรับ ไม่ต้องมี bundler หรือตัวรวมไฟล์ และไม่มีโฟลเดอร์ dist ที่เก็บผลคอมไพล์ค้างไว้ ปัจจุบันมีหลายแนวทางในการเร่งการคอมไพล์ TypeScript โดยฝั่งคอมไพเลอร์ทางการเองก็เพิ่งย้ายไปเขียนด้วย Go ใน TypeScript 7.0 RC ส่วน Ant เลือกซ่อนขั้นตอนคอมไพล์ไว้ข้างใน เพื่อไม่ให้คนเขียนต้องมายุ่ง

สำหรับแพ็กเกจที่พัฒนาขึ้นเองและต้องการเผยแพร่ Ant มีคลังของตัวเองชื่อ ants.land ซึ่งใช้โปรโตคอลเดียวกับ npm แพ็กเกจที่เผยแพร่ไว้จึงติดตั้งได้ด้วย ant · npm · yarn · pnpm หรือ bun ตัวไหนก็ได้ โดยไม่จำกัดว่าต้องใช้เครื่องมือของ Ant

sandbox ที่แยกด้วยเครื่องเสมือน ไม่ใช่แค่ป๊อปอัปขออนุญาต

จุดที่ Ant แตกต่างจากตัวอื่นที่สุดไม่ใช่เรื่องความเร็ว แต่คือ sandbox หรือพื้นที่แยกสำหรับรันโค้ดที่ไม่น่าไว้วางใจ

รันไทม์รุ่นใหม่หลายตัวมีระบบสิทธิ์อยู่แล้ว โดยถามผู้ใช้ก่อนว่าจะให้โค้ดอ่านไฟล์หรือต่อเน็ตไหม แต่การควบคุมสิทธิ์ยังเกิดขึ้นภายในโปรแกรมเดียวกับตัวรันไทม์ ส่วน Ant นำโค้ดที่ไม่น่าไว้วางใจไปรันในเครื่องเสมือนแยกต่างหาก โดยใช้ KVM บน Linux และ Hypervisor.framework บน macOS ซึ่งเป็นกลไกสร้างเครื่องเสมือนระดับฮาร์ดแวร์ นอกจากนี้ Ant ยังกำหนดกติกาไว้สองข้อตั้งแต่แรก โฟลเดอร์ที่เปิดให้ sandbox เข้าถึงจะอ่านได้อย่างเดียวจนกว่าจะสั่งเปิดสิทธิ์เขียน ส่วนการเชื่อมต่อเครือข่ายจะปิดไว้เป็นค่าเริ่มต้น โดยเปิดเฉพาะพอร์ตที่ระบุไว้เท่านั้น

import { Sandbox } from 'ant:sandbox'

const box = new Sandbox(({ mount: '.:/workspace' }))
await box.run('untrusted.js')
await box.close()

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

test262 ผ่าน 64% คือข้อจำกัดที่ห้ามมองข้าม

ทุกอย่างข้างบนฟังดูดีเกินไป จนต้องดูอีกด้านให้ครบ

Ant ผ่าน compat-table เต็ม 100% หรือ 1511 จาก 1511 ข้อ ครอบคลุมตั้งแต่ JavaScript รุ่นเก่าอย่าง ES5 ไปจนถึงฟีเจอร์รุ่นใหม่ล่าสุด compat-table เป็นตารางที่ตรวจว่ารันไทม์รองรับฟีเจอร์ภาษาที่ใช้กันจริงในแต่ละยุคครบหรือไม่ นอกจากนี้ Ant ยังผ่านมาตรฐาน WinterTC ซึ่งกำหนดชุด API ขั้นต่ำร่วมกันสำหรับรันไทม์ฝั่งเซิร์ฟเวอร์ ขณะที่ Node เองยังอยู่ในสถานะผ่านบางส่วน

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

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

ลองเมื่อไหร่ ยังไม่ควรใช้เมื่อไหร่

ถ้าอยากลองของจริง เริ่มได้ด้วยสามคำสั่ง โดยติดตั้งตัวรันไทม์ก่อน

curl -fsSL https://antjs.org/install | bash

ลงเฟรมเวิร์กสักตัว แล้วเขียนเซิร์ฟเวอร์สั้นๆ ไฟล์เดียว

ant i hono

import { Hono } from 'hono'

const app = new Hono()
app.get('/', (c) => c.text('Hello from Ant'))

export default app

จากนั้นสั่งรันไฟล์นั้นตรงๆ ได้เลย ไม่ต้องมี adapter หรือตัวเชื่อมเพิ่ม เพราะ Ant รองรับการ export แบบ fetch ซึ่งเป็นรูปแบบมาตรฐานอยู่แล้ว เฟรมเวิร์กอย่าง Hono จึงทำงานได้ทันที

ant server.js

เท่านี้ก็ได้เซิร์ฟเวอร์ที่รันอยู่ที่ localhost:3000 แล้ว ทั้งหมดนี้ใช้ได้บน macOS และ Linux ทั้ง arm64 และ x86_64 โดยไม่ต้องลงชุดเครื่องมือคอมไพล์อะไรเพิ่ม

ตอนนี้มีงานไม่กี่แบบที่เหมาะจะลองกับ Ant งานแรกคือเครื่องมือบรรทัดคำสั่งของตัวเองที่อยากให้เปิดปุ๊บติดปั๊บ งานที่สองคือฟังก์ชันเล็กๆ บน edge ซึ่งทำงานสั้นๆ แล้วจบ ในงานแบบนี้ 5 ms กับ 31 ms ต่างกันจริง งานที่สามคือการรันโค้ดที่ไม่น่าไว้วางใจผ่าน sandbox และงานสุดท้ายคืองานทดลองส่วนตัวที่พังแล้วไม่มีใครเดือดร้อน

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

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

โจทย์การแข่งขันแบบใหม่ของ Ant

ที่ผ่านมา การแข่งขันของรันไทม์ JavaScript วัดกันว่าใครทำอะไรได้มากกว่า ทั้ง API ที่ครบกว่า ฟีเจอร์ที่เยอะกว่า และระบบนิเวศที่ใหญ่กว่า ส่วน Ant เลือกแข่งด้วยโจทย์อีกแบบ นั่นคือทำเรื่องเดิมให้ได้ด้วยไฟล์ที่มีขนาดเล็กลงสิบห้าเท่า

test262 ที่ 64% ในวันนี้จะขยับขึ้นทุกเดือน เมื่อไปถึงจุดที่วางใจได้ ตัวเลข 8 MB จะไม่ใช่ตัวเลขที่ทำให้คนทึ่งอีกต่อไป แต่จะกลายเป็นมาตรฐานขั้นต่ำที่คนเริ่มคาดหวังจากรันไทม์ทุกตัวที่เลือกใช้

ที่มา:

• เว็บไซต์ Ant, a lightweight JavaScript runtime จาก antjs.org
• README javascript for 🐜's, a tiny runtime with big ambitions จาก theMackabu/ant (GitHub)