WinterJS รันไทม์จาวาสคริปต์ที่พัฒนาต่อจาก SpiderMonkey และเขียนด้วย Rust เพิ่งประกาศเปิดตัวมาเมื่อสี่เดือนที่แล้ว ตอนนี้โครงการเข้าสู่เวอร์ชั่น 1.0 เรียบร้อยแล้ว เนื่องจากทำ API เข้ากันได้กับมาตรฐาน WinterCG และยังทำ API ของ Cloudflare

ในแง่ของประสิทธิภาพ WinterJS รันแบบเนทีฟได้ที่ระดับ 150k req/s เร็วกว่า Bun และ NodeJS ชัดเจน แต่หากคอมไพล์เป็น WASM นั้นประสิทธิภาพยังได้เพียง 20k req/s เท่านั้น

ไลบรารี urllib3 ออกเวอร์ชั่น 2.2.0 เพิ่มฟีเจอร์สำคัญคือการรองรับการใช้งานบน Pyodide รันไทม์ภาษาไพธอนสำหรับ WASM ซึ่งทำให้สามารถรันโค้ดไพธอนได้บนเบราว์เซอร์หรือ Node.js

urllib3 เป็นไลบรารีที่พัฒนาอิสระ แข่งกับโมดูล urllib ที่เป็นไลบรารีมาตรฐานในตัวไพธอนเอง และมันเป็นไบรารีเบื้องหลังโมดูล requests ที่ได้รับความนิยมสูงเนื่องจากออกแบบ API ให้อ่านได้ง่าย

โครงการ Wasmer ประกาศนำ SpiderMonkey มาทำโครงการ WinterJS รันไทม์สำหรับรัน Service Worker แบบเดียวกับ Cloudflare Workers, Deno Deploy, หรือ Vercel โดยอาศัยการอิมพลีเมนต์ API จากมาตรฐาน wintercg

เรื่องจาก Wasmer ต้องการให้โค้ดรันผ่าน WASM ได้ด้วย จึงต้องเลือกใช้เทคโนโลยีที่รองรับการคอมไพล์ไปยัง WASM ได้ด้วย ตัวโค้ดหลักของ WinterJS ใช้ SpiderMonkey ผ่านทาง Rust API ของโครงการ spiderfire

ตัวโครงการ WinterJS สามารถรันผ่านคำสั่ง wasmer ตามปกติ หรือจะรันแบบเนทีฟผ่านทางคำสั่ง cargo ของ Rust ก็ได้

ที่มา - Wasmer

กูเกิลและ JetBrains โชว์การนำภาษา Kotlin มาเขียนเว็บ โดยคอมไพล์เป็น WebAssembly เพื่อให้รันในเบราว์เซอร์ได้ มีประสิทธิภาพเกือบเทียบเท่าเนทีฟ

ในยุคสมัยที่โลกมี 3 แพลตฟอร์มใหญ่คือ Android, iOS และเว็บ การมีแอพ 3 เวอร์ชันเป็นภาระในการดูแล จึงมีคนหาวิธีสร้างแอพด้วยภาษา-เครื่องมือเดียวกันกับทุกแพลตฟอร์ม (ด้วยวิธีการทางเทคนิคที่ต่างกัน แต่เป้าหมายเดียวกัน) เช่น .NET/Xamarin (C#) หรือ Flutter (Dart)

Wasm Labs กลุ่มพัฒนาการใช้งาน WebAssembly ของ VMware ปล่อย Python ตัวเต็มที่คอมไพล์ให้ทำงานกับ WebAssembly ได้ทั้งชุด เปิดทางให้นักพัฒนาสามารถย้ายแอปไปรันบนรันไทม์ต่างๆ ที่รองรับ WASM ได้ทุกที่

การคอมไพล์ Python เพื่อรันบน WASM นั้นมีมานานแล้ว โดยหลายทีมงานจากหลายบริษัท แต่โครงการของ VMware ครั้งนี้คอมไพล์ตัว Python พร้อมกับไลบรารีมาตรฐานทั้งชุดรวมถึง SQLite ทำให้รองรับแอปพลิเคชั่นที่เป็น Python ได้ค่อนข้างครบ

ทาง Wasm Labs พยายามพอร์ตรันไทม์ภาษาต่างๆ มายัง WASM มานาน ก่อนหน้านี้ภาษาที่พอร์ตมาแล้วได้แก่ PHP และ Ruby นอกจากนี้ทางโครงการยังสัญญาว่าจะคอมไพล์ Python เวอร์ชั่นต่อๆ ไปมาใช้ใน WASM เรื่อยๆ

มาตรฐาน WebSQL เคยได้รับความสนใจช่วงสิบปีที่แล้ว ที่หลายคนอยากให้เบราว์เซอร์มีฐานข้อมูล SQL ใช้งานได้ในตัวโดยไม่ต้องเชื่อมต่อเซิร์ฟเวอร์ แต่มาตรฐานนี้ก็ไม่ได้รับความนิยมนักทำให้เบราว์เซอร์หยุดซัพพอร์ตกันไปโดย Chrome เองก็ประกาศเตรียมถอด WebSQL ตั้งแต่ Chrome 105 เมื่อปีที่แล้วแต่ยังสามารถเปิด policy กลับมาใช้งานได้ ล่าสุดกูเกิลโชว์ให้ดูว่านักพัฒนาที่ต้องการใช้ SQL ในเบราว์เซอร์ตอนนี้สามารถใช้งานได้ด้วยเทคโนโลยี WebAssembly และ OPFS

เมื่อวันที่ 25 ธันวาคม 2565 กลุ่มผู้พัฒนาได้ประกาศปล่อยภาษา Ruby เวอร์ชั่น 3.2.0 ตามธรรมเนียมของชุมชนผู้พัฒนาที่จะออกอัพเดตใหญ่ทุกวันคริสต์มาส

ไฮไลท์ของการอัพเดตครั้งนี้อยู่ที่การเริ่มรองรับการพอร์ตไป WebAssembly ผ่าน WebAssembly System Interface (WASI) ซึ่งจะทำให้โค้ดของ CRuby (ภาษา Ruby ที่ใช้ C เป็น interpreter) สามารถเรียกใช้งานได้บนเว็บเบราเซอร์หรือบนแพลตฟอร์มที่รองรับ WebAssembly และประกาศให้ YJIT ที่เป็น JIT(Just-In-Time) compiler ใหม่ให้อยู่ในสถานะพร้อมใช้บน production จากเดิมที่อยู่ในสถานะ experimental

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

ทาง Tailscale พอร์ตชุดซอฟต์แวร์แบบเดียวกับที่ใช้งานในไคลเอนต์ปกติ ได้แก่ ซอฟต์แวร์ของ Tailscale เอง, Wireguard, ชุดเน็ตเวิร์ค, และ SSH จากนั้นเมื่อล็อกอินแล้ว Tailscale จะสร้างกุญแจยืนยันตัวตนชั่วคราว (ephemeral auth key) โหลดเข้าไปในไคลเอนต์ในเบราว์เซอร์

Docker Inc. ปล่อย Docker Desktop รุ่น Technical Preview ทดสอบฟีเจอร์รองรับ WASM ในตัว โดยใช้ wasmedge runtime แต่ยังควบคุมด้วยคำสั่ง docker เหมือนคอนเทนเนอร์ปกติ พร้อมกับสมัครสมาชิกเข้า Bytecode Alliance กลุ่มผลักดันให้ใช้งาน WASM ได้ทุกที่

ทาง Docker Inc. ร่วมมือกับ WasmEdge พัฒนาชุดครอบ runtime ทำให้ควบคุมได้เหมือน containerd ตัว docker engine จึงมองเห็นโปรแกรม wasm เหมือนคอนเทนเนอร์อื่นๆ

Supabase ผู้พัฒนาแพลตฟอร์มทดแทน Firebase เปิดโครงการ postgres-wasm พอร์ต PostgreSQL ทั้งก้อนเข้าไปรันในเบราว์เซอร์ด้วย WASM แม้ว่าก่อนหน้านี้ Crunchy Data จะเคยทำโครงการแบบเดียวกันมาก่อนแล้ว แต่ก็ทำไว้ใช้งานสำหรับเว็บสอน SQL ของ Crunchy Data เองเท่านั้น แต่ postgres-wasm นี้เป็นโครงการโอเพนซอร์สที่นำไปใช้งานอย่างอื่นได้ด้วย

โครงการนี้ทาง Supabase พัฒนาโครงการร่วมกับ Snaplet โครงการแปลงข้อมูลในฐานข้อมูลเพื่อให้นักพัฒนานำข้อมูลจากโปรดักชั่นไปใช้งานได้ ตัวโครงการ postgres-wasm จึงมี repository สองที่จากทั้ง Supabase และ Snaplet

Bytecode Alliance เปิดตัว Wasmtime 1.0 โครงการที่เริ่มมาตั้งแต่ปี 2019 เมื่อครั้ง Bytecode Alliance ยังเป็นเพียงชุมชนโอเพนซอร์สไม่ได้จดทะเบียนองค์กรจริงจัง และตอนนี้ตัว Wasmtime มีการใช้งานบนโปรดักชั่นกว้างขวางพอสมควรแล้ว และเชื่อว่าระบบเสถียรพอที่จะแนะนำให้คนทั่วไปใช้งาน

Wasmtime เป็นรันไทม์แยก จากเดิมที่ WebAssembly ถูกออกแบบมาให้รันในเบราว์เซอร์ การใช้งานจึงอาจจะเป็นการรันในจาวาสคริปต์รันไทม์ทั้งชุดแต่ในความเป็นจริงผู้ใช้จำนวนหนึ่งต้องการรัน WebAssembly อย่างเดียว แยกระบบออกมาทำให้เวลาเริ่มต้นโปรเซสเร็วขึ้นมาก จากเดิมจาวาสคริปต์ใช้เวลาประมาณ 5ms การรัน WebAssembly จะใช้เวลา 5 microsecond เท่านั้น

Crunchy Data ผู้ให้บริการฐานข้อมูล PostgreSQL บนคลาวด์ เปิดบทเรียน SQL แบบออนไลน์ฟรี ให้ผู้เรียนสามารถฝึกเขียน SQL ได้อย่างอิสระ โดยอาศัยการคอมไพล์ PostgreSQL ทั้งชุดมารันบน WASM ใช้งานได้เหมือนข้อมูลจริง โดยไม่ต้องเปลืองทรัพยากรฝั่งของ Crunchy Data เอง (นอกจากค่าพัฒนาและค่าแบนวิดท์)

Cloudflare อัพเกรดบริการ Workers ให้รองรับมาตรฐาน WASI ที่จะเปิดทางให้นักพัฒนาเขียนโปรแกรมภาษาอะไรก็ได้เพื่อคอมไพล์เป็นแบบ WebAssembly และ WASI แล้วส่งขึ้นไปรันบน Workers

WASI สำหรับโปรแกรมที่คอมไพล์เป็น WebAssembly มองเห็น system call ที่เป็นเหมือนระบบปฎิบัติการบนคอมพิวเตอร์ทั่วๆ ไป สำหรับเราสามารถคอมไพล์โปรแกรมเดิมๆ ไปรันบนแพลตฟอร์มใหม่ๆ ที่รองรับ WASI ได้โดยไม่ต้องแก้ไขเพิ่มเติม

Clouflare สาธิตการใช้โปรแกรมเดิมๆ คอมไพล์ไปรันบน Workers เช่น SWC สำหรับการคอมไพล์ TypeScript เป็น JavaScript หรือ zstd สำหรับบีบอัดไฟล์

Mozilla เผยข้อมูลของ RLBox เทคนิคการทำ sandbox แบบใหม่ที่จะเริ่มใช้ใน Firefox 95 โดยเป็นความร่วมมือกับงานวิจัยของมหาวิทยาลัย UC San Diego และ University of Texas

เว็บเบราว์เซอร์ยุคปัจจุบันมีการทำ sandbox ห่อหุ้มเว็บไซต์ไว้ในโพรเซสของตัวเอง ป้องกันไม่ให้เว็บอันตรายสามารถเข้าถึงเว็บอื่นๆ หรือออกมาสร้างอันตรายนอกเบราว์เซอร์ได้

Mozilla บอกว่าเมื่อห่อหุ้มเว็บเพจได้แล้ว เป้าหมายต่อไปคือการแยกคอมโพเนนต์แต่ละส่วนของเบราว์เซอร์ ไม่ให้มายุ่งเกี่ยวกันได้ (เช่น แยกโพรเซสประมวลผลวิดีโอออกมา ไม่ต้องยุ่งกับเบราว์เซอร์หลัก) โดยเฉพาะไลบรารีภายนอกที่อาจมีช่องโหว่ แต่ Mozilla ไม่สามารถควบคุมคุณภาพของโค้ดได้เอง (ปํญหา supply-chain attack ที่เกิดขึ้นบ่อยในช่วงหลัง)

Fastly, Intel, Mozilla, และ Microsoft ร่วมก่อตั้ง Bytecode Alliance องค์กรไม่แสวงหากำไรเพื่อการพัฒนาซอฟต์แวร์บนมาตรฐาน WebAssembly และ WebAssembly System Interface (WASI) เพื่อให้ใช้งานได้หลายรูปแบบทั้งบนคลาวด์, อุปกรณ์ IoT, หรือสภาพแวดล้อมอื่นๆ

ความพยายามนำไบนารีมารันใน sandbox ที่มีสิทธิ์จำกัดและมีความปลอดภัยแบบเดียวกับจาวาสคริปต์นั้นมีมายาวนาน เช่นโครงการ NaCl ของกูเกิลที่เริ่มมาตั้งแต่ปี 2011 ส่วน Mozilla นั้นเสนอแนวทาง asm.js มาตั้งแต่ปี 2013 ก่อนที่ทั้งอุตสาหกรรมจะหันมาสนับสนุน WebAssembly กันแทบทั้งหมด

Blazor เป็นเฟรมเวิร์คตัวหนึ่งในตระกูล ASP.NET เอาไว้เขียนเว็บแอพแบบหน้าเดียว (single-page) ด้วย HTML ผสมกับ C# แทนที่จะเป็น JavaScript

จุดเด่นของ Blazor คือใช้ภาษา C# ที่นักพัฒนาสาย .NET คุ้นเคย, ใช้โค้ด C# ทั้งฝั่งไคลเอนต์และเซิร์ฟเวอร์, ใช้ไลบรารีของ .NET ได้, มีระบบ UI component ให้พร้อมสรรพ

ก่อนหน้านี้ การทำงานของ Blazor คือต้องรันเซิร์ฟเวอร์ Blazor ที่เป็น .NET ด้วย แต่ล่าสุดในงาน Build 2020 ไมโครซอฟท์เพิ่มวิธีรัน Blazor แบบที่สองคือ Blazor WebAssembly แปลงโค้ดของรันไทม์ .NET เป็น WebAssembly ที่รันในเว็บเบราว์เซอร์รุ่นใหม่ๆ ได้ทั้งตัว

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

Mozilla ร่วมกับทีมวิจัยจากมหาวิทยาลัย 3 แห่งคือ University of California San Diego, University of Texas Austin, Stanford University พัฒนาเทคนิคใหม่ชื่อ RLBox แก้ปัญหานี้ด้วยการแปลงโค้ด C/C++ เป็น WebAssembly ก่อน เพื่อรันใน sandbox ของ WebAssembly แทน

W3C องค์กรวางมาตรฐานเว็บประกาศเผยแพร่เอกสารสเปค WebAssembly เปิดทางสู่การรันโค้ดที่ประสิทธิภาพแทบเท่ากับการรันโปรแกรมแบบ native บนเบราว์เซอร์ ทำให้เบราว์เซอร์กลายเป็นแพลตฟอร์มกลางสำหรับการรันแอปพลิเคชั่น เช่น เกม, ระบบถอดรหัส/เข้ารหัส เสียงและวิดีโอ, อัลกอริทึมเข้ารหัส, ไปจนถึงการรันโค้ดภาษาอื่นๆ

เอกสารแยกออกเป็น 3 ฉบับ ได้แก่

เป็นที่รู้กันดีว่า Mozilla ผลักดันเทคโนโลยี WebAssembly แบบสุดตัว ปัจจุบันเว็บเบราว์เซอร์ 4 ค่ายใหญ่ล้วนรองรับ WebAssembly กันหมดแล้ว ผลงานใหม่ล่าสุดของ Mozilla จึงหันไปจับตลาดนักพัฒนา ด้วยการเปิดตัว IDE สำหรับ WebAssembly โดยเฉพาะ

IDE ตัวนี้ชื่อว่า WebAssembly Studio มันเป็น IDE แบบออนไลน์ใช้งานผ่านเว็บ โดย Mozilla พัฒนาขึ้นจากโค้ดของซอฟต์แวร์โอเพนซอร์สหลายโครงการ เช่น Monaco Editor ของไมโครซอฟท์ (ตัวเดียวกับที่ใช้ใน VS Code), Binaryen, Clang Format ผสมกันออกมาเป็น IDE ที่สามารถเขียนโค้ดในภาษา C/C++/Rust แล้วแปลงเป็น WebAssembly ได้ทันที (กดเข้าไปลองเล่น)

Mozilla ประกาศแผนการพัฒนาให้ภาษา Rust ทำงานร่วมกับ JavaScript ในการใช้เขียนเว็บร่วมกัน

แนวทางของ Mozilla ไม่ได้ต้องการให้ Rust มาแทน JavaScript แต่มองว่าถ้าส่วนไหนจำเป็นต้องใช้ Rust เพื่อประสิทธิภาพที่ดีกว่า (เช่น การ parse ข้อมูลขนาดใหญ่) ก็สามารถใช้ Rust เขียนส่วนนั้น แล้วนำมาใช้ร่วมกับ JavaScript ในส่วนอื่นได้

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

เราทราบกันดีว่า Firefox 57 เร็วขึ้นกว่าเดิมมาก แต่นั่นเป็นเพียงจุดเริ่มต้นเท่านั้น เพราะ Mozilla มีแผนปรับปรุงเอนจินอีกมาก และใน Firefox 58 ก็มีของใหม่ที่ช่วยให้การประมวลผล JavaScript เร็วขึ้นอีก

ที่ผ่านมา Firefox รองรับ WebAssembly หรือการคอมไฟล์ JavaScript เป็นไบนารีเพื่อให้ได้ประสิทธิภาพดีขึ้นกว่าเดิม ใน Firefox 58 จะปรับปรุงการคอมไพล์ WebAssembly โดยใช้เทคนิค 2 อย่างประกอบกัน

WebAssembly ฟอร์แมตไบนารีแบบใหม่สำหรับเว็บเบราว์เซอร์โดยวิศวกรจาก Google, Microsoft, Mozilla, WebKit ที่ทำงานร่วมกันเพื่อรันเว็บแอพให้ได้ความเร็วใกล้เคียงกับแอพแบบเนทีฟ ตอนนี้ถือว่าเป็นฟอร์แมตที่ได้รับการรองรับจากเว็บเบราว์เซอร์เจ้าใหญ่ทั้งหมดสี่เจ้าแล้ว หลังจากที่ล่าสุด Safari และ Microsoft Edge เพิ่งอัพเดตรองรับไป เพิ่มเติมจาก Firefox และ Chrome ที่รองรับไปก่อนหน้านี้ ส่วนเบราว์เซอร์ที่ใช้ฐานจาก Chromium อย่าง Opera และ Vivaldi ก็จะรองรับในอีกไม่นานนัก

Chrome มีฟีเจอร์ PNaCl ที่นำโค้ดแบบเนทีฟมารันบนเบราว์เซอร์ เริ่มใช้มาตั้งแต่ Chrome 31 ในปี 2013 ล่าสุดกูเกิลประกาศถอดฟีเจอร์นี้แล้ว

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

Google ได้ออกอัพเดต Chrome 57 ทั้งบน Windows, Mac และ Linux โดยฟีเจอร์สำคัญในรอบนี้ ได้แก่

Mozilla ได้ออก Firefox 52 ตามรอบการอัพเดตทั้งบนเดสก์ท็อปและ Android โดยรอบนี้มาพร้อมกับฟีเจอร์สำคัญหลายอย่าง โดยบนเดสก์ท็อปมีการเปลี่ยนแปลงที่สำคัญดังนี้