รู้จักกับ WebAssembly ทำไมถึงเป็นเรื่องที่น่าสนใจ

WebAssembly เป็นเรื่องที่เราคุยกันมานานกว่า 10 ปีแล้ว มันผ่านกาลเวลา และการพัฒนามาเยอะมาก ๆ จนทุกวันนี้ถือว่าเป็นอีกภาษาที่อยู่เคียงคู่กับสามทหารเสือของโลกเว็บไซต์เป็นที่เรียบร้อยแล้ว แถมมันยังไปต่อในโลกของ Edge Computing และ Serverless อีก วันนี้เราเลยอยากจะมาแนะนำให้ทุกคนรู้จักกับมันกันว่า มันคืออะไร และเราสามารถเอามันมาทำอะไรได้บ้าง

เมื่อ Javascript ไม่ใช่คำตอบเดียวของงานเว็บอีกต่อไป

ในโลกของ Web Development มันผ่านการเดินมาไกลมาก ๆ ตั้งแต่ยุคเริ่มต้นที่มี HTML นิ่ง ๆ ในยุค Web 1.0 จากนั้นมี Javascript เข้ามาเติมเต็มความมีชีวิตชีวา สามารถโต้ตอบกับผู้ใช้ได้ จนในปัจจุบัน Web Browser ไม่ได้ทำหน้าที่แค่การ Render หน้าเว็บอีกต่อไปแล้ว เราทำทุกอย่างบน Web Browser ตั้งแต่ Web App จัดการข้อมูล ทำงานเอกสารทั่ว ๆ ไป จนถึง Application ที่ซับซ้อนมาก ๆ อย่าง AutoCAD และ Adobe Photoshop

แต่เมื่อเราพยายามผลักดัน อยากให้เว็บเป็นมากกว่าเว็บ มาทำหน้าที่ประมวลผลงานหนัก ๆ ไม่ว่าจะเป็นการเข้ารหัสวีดีโอ, Image Processing, 3D Graphic หรือกระทั่งทำ AI Inference บน Web Browser เราจะต้องชนกับกำแพงที่เรียกว่า Javascript

เรารู้กันดีกว่า Javascript เป็น High-Level, Dynamic Type Language ที่มีข้อจำกัดทางธรรมชาติของมันคือ เมื่อ JS ถูกส่งเข้าไปรันใน Web Browser ภาระอันหนักอึ้งนี้ จะตกไปอยู่กับ JIT ของ Engine เช่น V8 และ SpiderMonkey ซึ่งต้องเผชิญกับ Overhead มหาศาลมาก ๆ หนักกว่านั้นยังมีความเสี่ยงที่จะเกิด De-Optimisation หาก Type ของข้อมูลเปลี่ยนไป รวมถึงความไม่แน่นอนจากการทำงานของ Garbage Collector ทำให้ Javascript ขาดคุณสมบัติที่สำคัญสำหรับงานในระดับ System-Level คือ Predictable Performance หรือ ประสิทธิภาพที่คาดเดาได้และคงที่

นี่แหละคือจุดที่ WebAssembly (WASM) ก้าวเข้ามาเป็นตัวเลือกใหม่ ตัวมันเองไม่ใช่ ภาษาใหม่ที่เราต้องมาเรียนรู้คำสั่งใหม่ แต่มันเป็น Binary Instruction Format ระดับ Low-Level ที่มีโครงสร้างกะทัดรัด และใกล้เคียงกับ Machine Code ที่สุด หรือพูดให้ง่ายกว่านั้น มันคือ Compilation Target อันใหม่ของ Compiler หรือพูดให้ง่ายกว่านั้นคือ เราสามารถ Compile Source Code หลากหลายภาษา เช่น C, C++, Rust และ Go ให้กลายเป็น WASM Binary เพื่อนำไปรันบน Web Browser ด้วยความเร็วระดับ Near-Native ทำให้เกิดคำถามต่อไปว่า แล้วถ้ามันเป็นแบบนี้ WASM มันออกแบบมาเพื่อฆ่า JS ให้สูญพันธุ์รึเปล่า

คำตอบคือ โน้ววว ห่างไกลเลย มันไม่ได้ถูกสร้างมาเพื่อแทนที่แต่อย่างใด เช่น WASM ไม่สามารถเข้าถึง DOM หรือ Web API ได้โดยตรง แต่มันถูกออกแบบมาเพื่อทำงานร่วมกัน คล้าย ๆ กับการแบ่งงานกันทำอยู่ เรายังคงใช้ JS ในการจัดการ UI, State และ Business Logic เพราะมันทำงานกับ DOM ได้ดีเยี่ยม เขียนได้ง่าย รวดเร็ว แต่เมื่อไหร่ก็ตามที่ Application เราต้องเจอกับงานคำนวณโหด ๆ ต้องรีดพลังของ CPU ออกมา เราจะ Offload งานพวกนี้ไปให้กลุ่ม WebAssembly Module จัดการต่อ

จากยุคมืดแห่งความเละ สู่ W3C Standard

WebAssembly ไม่ใช่ความพยายามแรกในการหาทำเอา Compiled Languge มารันบนเว็บ มันผ่านเรื่องราวยุคมืดมาเยอะมาก ๆ หากใครเกิดทัน โลกเรามีของจำพวก Plug-in อย่าง Java Applets, ActiveX หรือ Flash ซึ่งเราเห็นกันมาแล้ว แม้ว่ามันทำงานได้ แต่มันคือฝันร้ายด้าน Security แบบ ฉ่ำ ๆ ดูได้จาก CVV ที่รายงานกันฉ่ำมาก ๆ แต่ละตัว แดงเถือกทั้งนั้น แถมยังมีประสบการณ์ใช้งานอันเลวร้ายมาก ๆ Crash บ่อย และกินเครื่องดุ จนสุดท้าย มันก็แก้ไม่ไหว พัฒนาต่อไม่คุ้ม ล้มหายตายจากกันไป หลังจากนั้น มันเลยมีความพยายามออกมาเป็น 2 ทางในการแก้ปัญหานี้

ฝั่งแรกคือ Google พยายามสร้าง Native Client (NaCl) ซึ่งอนุญาติให้รัน C/C++ แบบ Native ภายใน Sandbox ของ Web Browser ได้เลย Performance ที่ได้นั้นดีมาก ๆ แต่ติดปัญหาที่สำคัญอย่างสถาปัตยกรรมของ CPU ทั้ง x86 และ ARM เพื่อแก้ปัญหานี้ Google เลยออก PNaCl ที่ Compile ออกมาเป็น LLVM Bytecode ก่อน แล้วค่อยแปลงมันเป็น Machine Code ที่ฝั่ง User อีกที แต่ถึงมันจะเก่ง และดีแค่ไหน มันก็ยังถูกจำกัดอยู่แค่ในฝั่ง Google Chrome ทำให้มันไม่ได้รับเป็นมาตรฐานกลาง ฟิล ๆ ว่า เธอดีนะ แต่เธอ Introvert ก็เรื่องของเธอ

อีกฝั่งคือ Mozilla เลือกอีกทาง เข้าเมืองหลิวต้องหลิวตาตาม ด้วยการเปิดตัว asm.js ในปี 2013 โดยตัวมันไม่ได้ทำตัวเป็นภาษาใหม่อะไรทั้งสิ้น แต่มันคือ Strict Subset ของ Javascript ที่ถูกตัด Feature ออกไปหมด เหลือแค่โครงสสร้างพื้นฐานเท่านั้น Main Idea คือการใช้เครื่องมือของ Emscripten เพื่อแปลง C/C++ Source Code ให้กลายเป็น Code ที่รันบน asm.js ได้

ความฉลาดของ asm.js คือ การใช้ลูกเล่นสนุก ๆ เพื่อจำลองสิ่งที่มีอยู่ใน C/C++ ให้อยู่ในร่างของ JS เช่น ใช้ ArrayBuffer ก้อนใหญ่ ๆ อันนึง เพื่อจำลองการมีอยู่ของ Heap Memory หรือกระทั่ง Type Hinting สนุกเลยละ

พีคกว่านั้นคือ เมื่อ Firefox ตอนนั้นเห็น Directive use asm อยู่ด้านบนของไฟล์มันจะรู้ได้ทันทีว่า Code ชุดนี้โดน Optimise มาแล้ว มันจะข้ามขั้นตอนบางอย่างแล้วไปทำ Ahead-Of-Time (AOT) Compilation เลย นั่นแปลว่า Performance โคตรใกล้กับ Native มาก ๆ และที่สำคัญ มันรันได้บนทุก Web Browser เพราะเนื้อแท้ไส้ในมันคือ Javascript ธรรมดาเท่านั้นเลย

แม้ว่า asm.js จะทำงานได้ดีมาก ๆ แต่มันต้องเจอกบั Overhead ในการ Parse JS Source Code ที่มีขนาดใหญ่ชิบหายกินเวลามาก ๆ ถ้ายังเป็นแบบนี้ต่อไปเรื่องนี้ไม่น่าจะไปต่อได้เลย

ในปี 2015 อะไรใหม่ ๆ ก็เกิดขึ้น เมื่อ Mozilla, Google, Microsoft และ Apple ตกลงจับมือกันร่วมกันสร้างมาตรฐานใหม่ ที่เอาข้อดีของ NaCl ในเรื่องการที่มันเป็น Binary Format และความเร็วเกือบเท่า Native มารวมกับข้อดีของ asm.js ที่ได้เรื่อง Compatibility และ Sandboxing มารวมกัน จนเกิดเป็น WebAssembly

เพราะความร่วมกันขนาดหนัก ทำให้มันถูกพัฒนาไปอย่างรวดเร็วมาก ๆ จนปี 2017 MVP ของมันได้ถูกปล่อยออกมา และได้รับการรองรับแบบ Native ใน Web Browser ทุกตัวพร้อม ๆ กัน ตั้งแต่ Google Chrome, Firefox, Safari และ Edge

จนปี 2019 W3C ได้ประกาศรับรอง WebAssembly ให้เป็น W3C Standard อย่างเป็นทางการ ทำให้ WASM กลายเป็น ภาษาที่ 4 ที่สามารถทำงานบนเว็บได้แบบ Native ต่อจาก HTML, CSS และ Javascript อย่างเต็มตัว ถือว่าเป็นการปิดตำนานความพยายามอันแสนยาวนาน และเปิดประตูสู่ยุคใหม่ของการทำ Modern Web Application อย่างแท้จริง

WASM ทำงานยังไง ?

ความเร็วระดับ Near Native ไม่ได้เกิดจากเวทย์มนต์ อยู่ ๆ จะเกิดก็เกิด แต่เกิดจากการออกแบบสถาปัตยกรรมที่ตัดความซับซ้อนทิ้งไป และ Focus กับสิ่งที่ต้องใช้ในการประมวลผลเป็นหลัก หากเราแงะดูไส้ใน เราจะเจอกับความน่าสนใจในสถาปัตยกรรมของมันหลายอย่างด้วยกัน เราขอยกมา 3 เรื่องที่เราค่อนข้างชอบละกัน

อย่างแรกคือ Stack-Based VM ปกติ คอมพิวเตอรืที่เราใช้งานทั่วไป มักจะใช้ Register-based คือมี Register ความเร็วสูงมาก ๆ เก็บข้อมูลชั่วคราวสำหรับการคำนวณ แต่ WASM เลือกที่จะใช้ Stack Machine คือ Instruction ทั้งหมดจะทำงานผ่านการ Push ข้อมูลลง Stack และ Pop ออกไปทำงาน ข้อดีของการทำแบบนี้คือ Bytecode ขนาดเล็กมาก ๆ สามารถดาวน์โหลดผ่าน Network ได้เร็ว เพราะคำสั่งส่วนใหญ่ ไม่ต้องระบุ Address หรือ Register ให้วุ่นวาย แถมยังทำให้ Web Browser สามารถ Decode และ Validate Binary ทั้งหมดได้ในรอบเดียว

เรื่องถัดไปคือ WASM ไม่ได้มองเห็น RAM ทั้งหมด เหมือนโปรแกรมทั่วไป แต่มันทำงานอยู่บน Linear Memory ซึ่งถอดหน้ากากออกมามันคือ Contiguous Byte Array หรือก็คือ พื้นที่ใน Memory ที่เรียกต่อกันเป็นผืนเดียวกัน ซึ่งฝั่ง JS จะมองเห็นเป็น ArrayBuffer Object ตัวนึงเท่านั้น ตัว WASM จะอ่านและเขียนข้อมูลลงในก้อน Array นี้ผ่าน Index ฟิลคล้าย ๆ กับการทำ Reference บน Pointer เลย

มาที่ Execution Pipeline กันบ้าง ไม่แปลกใจเท่าไหร่ที่มันจะเร็วมาก ๆ เพราะ Binary มัน Pack มาเรียบร้อย ดาวน์โหลดมาปุ๊บ สามารถ Compile เป็น Machine Code ได้เลย ไม่ต้องใช้ JIT แปลงเป็น Bytecode แล้วแปลงเป็น Machine Code อีกแล้ว สิ่งที่เกิดขึ้นคือ Startup Time เร็วมาก ๆ และได้ Performance ที่คาดเดาได้ คล้าย ๆ กับเราโหลด Universal Binary มารันใน Web Browser เลย

และเรื่องสุดท้ายคือ Security นอกจาก Memory Isolation ที่แข็งแกร่งแล้ว ยังใช้แนวคิด Default-Deny ให้ทำงานใน Sandbox ที่เข้มงวดที่สุด WASM Module จะไม่รู้เลยว่า โลกภายนอกคืออะไร ไม่มีสิทธิ์แตะต้อง DOM, ไม่รู้จัก File System และเรียก Network API ไม่ได้

การที่ WASM จะสื่อสารกับโลกภายนอกได้ ต้องทำงาน Import และ Export เท่านั้น ซึ่งมันจะเกิดจากฝั่ง JS เป็นคนป้อน Function ที่อนุญาติเข้าไปในให้ WASM ใช้งาน นี่คือกลไลที่ทำให้การรัน Untrusted Code ก็ยังปลอดภัยโคตร ๆ

จากกรอบของ Web สู่โลกกว้าง

แม้จุดเริ่มต้นของ Web Assembly จะมีคำว่า Web อยู่ในชื่อ และถูกสร้างขึ้นมาเพื่อ Web Browser แต่ด้วยความฉลาดในเชิง Engineering ที่เป็น Platform-Agnostic, ขนาดเล็ก, ทำงานเร็ว และ ปลอดภัยสูงมาก ทำให้นักพัฒนาหลายคนถามว่า ทำไมเราไม่เอาเทคโนโลยีนี้ไปรันบน Server หรือ OS อื่น ๆ ด้วยละ

คำถามนี้แหละ ทำให้เกิดการขยายการใช้งาน WASM ออกไปไกลมาก ๆ จนกลายเป็นเทคโนโลยีใหม่ที่เข้ามาในวงการ Cloud Native และ System Architecture

อย่างที่เราได้เล่าไปว่า WASM มันถูกขังใน Sandbox ไม่รู้จักโลกภายนอกเลย การจะให้มันไปรันบน OS มันจะต้องมีวิธีบางอย่างไว้คุยกับ System Resource เช่น File System และ Network ทำให้เกิดการสร้างมาตรฐาน WASI (WebAssembly System Interface) ขึ้นมา

คิดภาพง่าย ๆ WASI มันเป็นเหมือน POSIX API สำหรับ WebAssembly มันเป็น Standard Interface ที่ยอมให้ WASM Module สามารถขออนุญาติเข้าถึงทรัพยากรของ OS ได้อย่างปลอดภัย และมีการควบคุมสิทธิ์อย่างเข้มงวด การมาของ WASI ทำให้เราสามารถใช้ Runtime อย่าง Wasmtime และ WasmEdge มารันไฟล์ .wasm บน Linux หรือ Windows หรือ macOS ได้โดยตรง เป็นการปัดฝุ่นแนวคิด Write Once, Run Anywhere ให้ฟื้นคืนชีพขึ้นมาอีกครั้งในร่างที่เร็วกว่าเดิมกลายตัว

อีกแนวคิดที่พา WASM ไปอีกขั้นคือ WebAssembly Component Model เป็นมาตรฐานใหม่ที่กำลังถูกพัฒนา แนวคิดคือ ทำให้ WASM Module ที่ถูกเขียนด้วยภาษาต่างกัน สามารถนำมาประกอบร่าง และคุยกันเองได้แบบ Native โดยแชร์ Data Type ที่ซับซ้อนข้ามกันได้โดยไม่ต้องเสียเวลาแปลงข้อมูลไปมา มันเป็นเรื่องที่น่าตื่นเต้นมาก ๆ เพราะมันทำให้เราสามารถเลือกภาษาที่ดีที่สุดสำหรับงานเฉพาะทาง มาประกอบเป็น Application เดียวได้อย่างไร้รอยต่อ ลด Overhead มหาศาล

คนเขาเอา WASM มาทำอะไรบ้าง

ทุกวันนี้ WASM ไม่ใช่แค่ของเล่นทดลองขำ ๆ แต่มันถูกเอามาใช้งานจริงใน Production แล้วในหลากหลายมิติมาก ๆ

อย่างแรกคือ Web Application ที่ต้องการพลังการประมวลผลสูง ๆ ก็หันมาใช้ WASM กันหมดแล้ว ตัวอย่างที่ชัดเจน เห็นผลโคตร ๆ คือ Figma ใช้ C++ มา Compile เป็น WASM ที่สามารถจัดการ Graphic ซับซ้อนมาก ๆ ได้แบบลื่นไหลโคตร ๆ หรืออีกอันที่สนุกคือ Photoshop ที่เอามารันบนเว็บได้

อีกอันที่สนุกไม่แพ้กัน เราเล่นเป็นอย่างแรกเลยคือ การเอามาใช้ในงาน Edge Computing และ Serverless ปัญหาคือ ผู้ให้บริการ Edge Network เขามองเห็นข้อจำกัดของ Container โดยเฉพาะ เวลา และ Resource ในการทำ Cold Start ที่ช้าเกินไปสำหรับงาน Edge เขาเลยเลือกใช้ WASM เป็น Runtime ทำให้สามารถรัน Serverless Function ได้ด้วย Cold Start ที่ต่ำกว่ามิลลิวินาทีซะอีก

และอีกอันที่เป็นเหมือนตรงกลาง ๆ อยู่คือ ตอนนี้ Docker รองรับการรัน WASM Container คู่กับ Linux Container ความน่าสนใจคือ WASM Container มีขนาดเล็กจิ๋ว Start ได้เร็วกว่า และด้วยธรรมชาติของ Sandbox ที่แยก Memory ขาดจากกัน ทำให้มันตอบโจทย์การออกแบบระบบแบบ Zero-Trust ได้อย่างสมบูรณ์แบบ มันแยก Execution Environment ออกมาได้หมดจดถึงระดับ Instruction ซึ่งปลอดภัยกว่าการพึ่งพา OS-Level Isolation เพียงอย่างเดียว

เราคิดว่า เรากำลังอยู่ในช่วงจุดเปลี่ยนสำคัญ WebAssembly กำลังทำหน้าที่เป็น Universal Binary รันได้ทุกที่ตั้งแต่ Browser, IoT และ Edge Node โคตรน่าตื่นเต้นมาก ๆ

สรุป : เมื่อไหร่ควรใช้ และเมื่อไหร่ควรปล่อยให้เป็นงานของ Javascript

ยอมรับเลยว่า เราค่อนข้างตื่นเต้นการมาถึงของ WASM มาก ๆ ยิ่งตอนออก WASI ออกมาอีกก็คือ โหววว ความเจริญ !!! แต่ ๆๆๆ เราไม่ได้จะบอกว่า ให้รื้อ Codebase ทั้งหมดแล้ว Port เป็น C/C++, Rust หรือ Go เพื่อทำเป็น WASM ทั้งหมดนะ หัวใจสำคัญของการใช้ WebAssembly คือการเข้าใจ จุดแข็ง และข้อจำกัดของมัน เพื่อเลือกใช้เครื่องมือที่เหมาะสมกับงาน

งานที่เราคิดว่า เหมาะกับการใช้ WASM มาก ๆ น่าจะเป็นงานที่ต้องการ Performance โหดมาก ๆ หรือต้องการ Isolation และ Security ที่แน่นมาก ๆ รวมไปถึงงานกลุ่ม Edge Computing คือเริ่ดเลยละ แต่งานที่ไม่เหมาะน่าจะเป็น Web Application ที่ทำ CRUD ธรรมดา หรืองานที่ต้อง Manipulate DOM โดยตรง พวกนั้นไปใช้ JS เถอะนะ