🎞️ Videos → Intro to Web Assembly

เริ่มต้นการพูดคุยและแนะนำตัว (Intro & Technical Difficulties)0:00

สวัสดีค่ะ โทษทีปัญหาทางเทคนิคนิดหน่อยค่ะ มันงอแงค่ะ วันนี้ดัน error ใน production ซะงั้น

ได้ยินอยู่เนาะ

ชื่อการนะคะ วันนี้เดี๋ยวจะมาแชร์กับ web assembly ค่ะ ก็มาดูกันว่ามันคืออะไร ใช้งานยังไง แล้วเราจะเอามันมา plugin กับสิ่งที่เราทำอยู่ทุกวันนี้ ได้อย่างไรคะ ข้อดีของมันคือมัน portable แล้วกัน แต่ portable ยังไง มีข้อจำกัดอย่างไรบ้าง แล้วทำไมมันถึง portable ไปดูกันนะคะ แต่ว่าก่อนอื่นขอขายของนิดนึงค่ะ วันอังคารหน้านะคะ ทาง MFX กับ HashiCorp จัดงาน conference กันค่ะ ก็เกี่ยวกับ HashiCorp stack infrastructure as code security แล้วก็ automation นะคะ ที่คอนแรดบางกอกค่ะ ก็คือตามไปได้นะคะ ก็เข้างานฟรีค่ะ

แล้วก็มี swag แจกด้วย ทีมงานฝากบอกมานะคะ ก็สแกน QR code ลงทะเบียนกันได้ค่ะ

WebAssembly คืออะไร? (What is WebAssembly?)0:58

แนะนำตัวก่อนนะคะ ชื่อการนะคะ ก็ปัจจุบันเป็น independent consultant ค่ะ ก็คือออกมาเดี่ยวแล้ว พเนจร ไม่ได้มีสังกัด ส่วนตัวก็คือเป็นคนที่ชอบ automate แล้วก็ optimize หลายๆ อย่างเนาะ เพราะงั้นคืออะไรก็ตามที่ลดเวลา runtime ได้จะแฮปปี้มาก เวลาว่างบางทีก็คืออยากรู้ว่าอะไรไวกว่ากัน ก็เลยจะไปทำ experiment มา แล้วถ้าขยันหน่อยก็จะเอาดาต้าที่ได้มามาออกเป็นบล็อก แล้วก็สรุปบทความให้คนอื่นเค้าอ่านกันเล่นนะคะ ส่วนมากคือจะ engage ใน community หลายส่วน ปัจจุบันก็คือเป็นทั้ง Amazon community builder แล้วก็ HashiCorp ambassador ด้วยค่ะ มีบล็อกอยู่นะคะ เข้าไปตามอ่านกันได้ค่ะ มีภาษาไทยบางบทความ การพึ่งเขียนล่าสุดออกไปเนาะ โซเชียลมีเดียจริงๆ Facebook มี แต่ว่ารู้สึกรกก็เลย เหมือนกันค่ะ ก็ตามไป search กันได้นะคะ แนะนำก่อนว่า web assembly คืออะไร สำหรับคนที่เรียน computer science มาเนี่ย เราก็จะได้ยิน assembly เนาะ ซึ่งถ้าเกิดชีวิตนี้ไม่เคยต้องเขียนมาถือว่าโชคดีแล้วค่ะ จะได้ไม่ฝันร้าย assembly เนี่ยคือมันเป็นอะไรที่แบบเขียนแบบเข้าใกล้ ภาษามาชีนมากๆ แต่ว่าข้อดีของมันคือตัว artifact binary มันจะเล็ก แล้วเราเอามันไปทำอะไรหลายๆ อย่าง แต่ว่าพอมันเป็น web assembly เนี่ยก็คือมองว่า มันก็คงความเป็น assembly แต่ว่ามันจะมายืนอยู่บนฝั่ง web platform แทน คำว่า web platform ที่ว่าคืออะไรก็ตามที่เป็น web assembly แล้วถ้าเกิดเรามี browser runtime เราจะใช้งานมันได้ เพราะงั้นคือจากเมื่อก่อนที่เวลาที่เราจะ deploy

ปัญหาโลกแตกของการ Deploy workloads แบบเดิมๆ (Deployment Problems)2:41

workload เนี่ย คือถ้าเกิดเป็นฝั่ง web เนาะ แล้วก็จะมีตัว front-end back-end แล้วก็ database ใช่มั้ย database ปัดมันไปก่อนนะ ตัวอย่างอย่างตัว front-end เนี่ย เราก็ deploy เป็น static site ก็ได้ หรือเป็น server ก็ได้ อะไรก็ว่ากันไป แต่มันต้องมีสักตัวนึงทำหน้าที่เป็น web server ให้เราเอาของไปวาง ก็ต้องมีคนเลี้ยง web server เอาไว้ แต่ถ้าเกิดเป็น back-end เนี่ยยังไงก็ตามก็ต้องมี server เพราะว่า back-end ไม่ได้เกิดมาจากอากาศธาตุ คือจะมาบอกว่า it runs on my machine ก็ไม่ได้

เพราะว่าชาวบ้านชาวช่องเค้าโทรเข้ามาไม่ได้

การที่เราจะเอาสมมติ back-end ไปวางเนี่ย มันก็ต้องมีตัว server และ server จะเป็นของเราหรือของเค้าก็แล้วแต่จะตกลงกัน แล้วไม่พอก็ขึ้นอยู่กับว่าเราใช้ภาษาอะไรเขียนด้วย เพราะถ้าเกิดว่าเราใช้ node เขียน API ข้อดีก็คือมาตรฐานสามัญชน คนใช้งานง่าย มีตัวอย่างให้เยอะ แต่เราก็ต้องเอาตัว node runtime เนี่ยไปวางไว้ ในตัว server นั้น หรือถ้าเกิดถ้ามาตรฐานหน่อยก็ตั้งเป็น docker เข้าไป แต่ docker ที่ว่านี้ก็ต้องมี node runtime ด้วยนะ แล้วก็ต้องมี node_modules ด้วย ซึ่งเราก็รู้กันว่า node_modules คือสิ่งที่หนักที่สุด ในจักรวาล ยังไม่มีใครโค่นมันได้ ใช่มั้ย

เจ็บใจมาก คือบอกเลยว่าแบบรอบนี้คือลงทุนซื้อ Mac 1 terabyte เพราะว่า node_modules เต็มเครื่อง

คือ redeploy application นั้นแล้วก็มันไม่รอดสักอันที่หนึ่งเลย ก็แบบใช้เงินก็ไม่ใช่ปัญหา โอเคต่อทีเนี่ย หรือถ้าเกิดว่าบังเอิญแจ็กพอตเราอยู่ในบริษัทที่เค้าใช้ Rust ใช้ Go language หรือ API ข้อนี้ก็คือเป็น binary ข้อเสียคือ binary ของคุณไม่ได้รันได้ทุกที่ค่ะ เพราะว่า binary บน Linux ก็อันหนึ่ง binary บน Mac ก็อันหนึ่ง บน Windows ก็อันหนึ่ง คือเราจะมาปั้น binary บน Mac แล้วไปดีพลอยบน server ที่เป็น Linux อันนี้ก็ไหว้พระดีๆ ค่ะ เดี๋ยวมันจะระเบิดนะคะ หรือไม่ก็บางทีเจอเหตุการณ์นี้ค่ะ คือใน Mac ได้ ใน Windows ได้ Linux ได้

แต่เป็น Intel หรือ AMD นะ แต่พอไปอยู่บน server ARM ปุ๊บระเบิดตูม ไม่เคยเจอ error นี้มาก่อน แล้วจะให้เทสบนเครื่องไหน เพราะเครื่อง dev ไม่มี ARM อ้าวฉิบหาย นั่นแหละ เพราะงั้นคือกลับไปที่ว่าพอมันเป็น WebAssembly เนี่ย สิ่งที่เกิดขึ้นคือปั้นมาแล้วรันได้ ก็คือรันได้เพราะทุกคนไปใช้ runtime เดียวกัน

ข้อดีของ WebAssembly: เบาและรันได้ทุกที่ (Advantages: Lightweight & Portable)5:05

คือ browser runtime เพราะงั้นปัญหาโลกแตกที่จะต้องมาเจอ ว่าถ้าเกิดเป็น Docker ใช่มั้ย Docker ก็มี architecture คือ Docker คุยกันข้าม OS และ CPU ไม่ได้ คุยกันก็คือระเบิด คือโอเค image มันดึงออกมาได้ แต่ตอนรันจริงมันจะ error ว่าใส่เราแล้วมันจะรันไม่ผ่าน แล้วมันจะรันไม่ติดนั่นแหละ เพราะงั้นคือแล้วมันจะเจอความบันเทิงตรงที่ว่า คือ node เนี่ยบางทีนะ dependency เนี่ย ก็ปกติไม่มีอะไร แต่พอไปอยู่บนสมมติเครื่อง ARM อย่างเงี้ย dependency ลงไม่ติด ลงไม่ได้ คือลงไม่ได้ build ไม่ได้ รันไม่ได้ อ้าวจบ กลับทำยังไงดีประมาณนั้น เพราะงั้นคือปัญหาโลกแตกที่มันต้องแบบ โอเคคือ dev ก็อันหนึ่ง แล้วตอน deploy ก็อันหนึ่ง คนมันคนละ target กัน คือแบบ CPU กับ architecture สลับฝั่งสลับตัวอะไรกันเงี้ย มันจะหมดไปเพราะว่าพอมันเป็น WebAssembly เนี่ย ก็คือปั้นมาทีเดียวจบ คือปั้นได้ก็คือได้ รันได้ก็คือรันได้ ไม่ต้องไปนั่งลุ้นหน้างานว่าแล้วมันจะรันบนปลายทางได้มั้ย ปลายทางที่เราอาจจะไปรู้ตอนที่โยนขึ้นไปแล้วก็ได้ แล้วกลับเรามาไม่ทัน นั่นแหละค่ะ

ทีนี้ปัญหาโลกแตกอีกอันต่อมาคือ dependency

ตรงนี้ยังไม่จบง่ายๆ เพราะว่าคือมันจะมีเหตุการณ์อย่างนี้ คือบางทีเราลงได้เรา build ได้

แต่เราอาจจะรันมันไม่ได้ หรือรันมันได้แต่บางอย่างหาย เราไม่รู้นอกจากว่าคุณจะเขียน test กำกับไว้ทุกจุด ซึ่งอันนี้เป็นกับทุกภาษา หรือไม่บางทีก็คือปั้นมาได้

แต่ว่าพอเอาไปรันจริงคือเหมือน implementation น่ะ มันจะไม่เหมือนกันเวลาข้าม architecture กัน เพราะว่ามีเหมือนกับ if else condition อยู่ในหลังบ้าน อะไรเงี้ยมันก็จะเกิดอาการพังได้ เพราะงั้นคือมันเลยเป็นอะไรที่แบบท้าชะตาฟ้าดินมากๆ กับการที่เรา dev บนเครื่องแบบหนึ่ง แล้วเราต้องไป deploy ไปเข้าอีกแบบหนึ่ง โดยที่เราไม่มี environment จำลองแบบเครื่องปลายทาง ให้เรามานั่งลุ้นกัน คือปัญหาตรงนี้มันเกิดขึ้นเพราะว่า คือตัว compute ถ้าเกิดเป็น ARM ราคาถูกกว่าแบบเว่อร์มาก เพราะงั้นคือหลายๆ คนเลยพยายามในการที่ dev ยังไงก็ dev ไป แต่ว่าตอน deploy คือต้องไป deploy แบบเป็น ARM ต้องการลด cost แล้วราคามันต่างกันแบบเว่อร์ๆ นะ ต่างกันแบบเว่อร์จริง เพราะงั้นคือเค้าถึงลงทุนทำตรงนี้กัน แต่พอมันเป็นอย่างเงี้ยที่แบบติดเรื่อง CPU ติดเรื่อง OS อะไรเงี้ย มันก็เลยเป็นเรื่องที่แบบ คือถ้าเกิดเราไม่มีระบบจัดการดีๆ มันจะกิน man-day ของ dev เยอะ ในการที่เราต้องไปนั่ง debug ว่าปัญหาคือตรงไหน แล้วมันก็จะกลายเป็นสูญเสียเวลางาน เพราะว่าต้องมานั่งลุ้นกันว่าทำอะไรไป แล้วจะมีอะไรพังมั่งประมาณนั้น คือ QA ก็จะมานั่งลุ้นเรา เพราะแบบรำคาญว่าแบบแล้วพวกแกหยุดแก้กันได้ยัง ประมาณนั้น นั่นแหละ

ผมไม่เอา ARM ไว้นะคะทุกคน

WebAssembly vs. Rust/Go: ขนาดไฟล์และประสิทธิภาพ (File Size & Performance Comparison)7:51

ทีนี้แต่ข้อดีของ WebAssembly คือมันเบา

เอาง่ายๆ คือถ้าเกิดเป็น Rust เนี่ย ที่เรารู้กันว่า Rust binary มันก็เบาอยู่แล้ว คือถ้าเกิดพูดถึง binary เนี่ย ก็จะเป็น Rust กับ Go เนาะ ซึ่ง Go แน่นอนว่า compile ไว แต่ว่า binary ก็จะอ้วนตุ๊ต๊ะประมาณหนึ่ง แต่ถ้าเกิดเป็น Rust เนี่ย โอเคเขียนยากกว่า ใช้เวลา compile นานกว่า แต่ว่าตัว binary มันจะเบากว่า แต่พอเป็น WebAssembly เนี่ย binary 100 KB

ไม่ได้เว่อร์พูดจริง มันเบามากเบาแบบไม่ต้องคิดชีวิตเลย เพราะงั้นคือถ้าเกิดเราต้องปั้นอะไรสักอย่างมา แล้วแบบมันเปลี่ยนจาก Go หรือ Rust เป็น WebAssembly ได้เนี่ย โอ้โหคือแบบ storage หายไปเยอะมาก คือปกติเวลา deploy กันน่ะ มันต้องเอา artifact เนี่ยไปขึ้นไปใน storage พอมันขึ้นไป storage เนี่ย เรา build บ่อยๆ release บ่อยๆ test บ่อยๆ storage มันบวม แต่ถ้าเกิดว่าเราลดกำลังได้ ว่า storage มันจะมีของไปวางน้อยลง มันลดตังค์ได้เยอะมาก คือแล้วยิ่งถ้าเกิดเป็นบริษัทที่ทำกันหลาย service น่ะ ตังค์ตรงเนี้ยลดได้ระดับแบบหลายเปอร์เซ็นต์เลย คือคุ้มจริง เพราะงั้นคือถ้าเกิดว่าเค้าทำเรื่องของ financial operation

กันจริงๆ เค้าจะมาแบบรีดแข่งขันกันทุกส่วน ตรงนี้ก็เป็นจุดหนึ่งที่เค้าเอามารีดแข่งขันกันได้

ข้อดีเพิ่มเติม: Client-side execution และลดค่าใช้จ่าย (Client-side & Cost Reduction)9:09

ทีนี้ข้อดีอีกอย่างหนึ่งคือพูดถึง backend ใช่มั้ย backend เนี่ยมันอยู่ที่อื่นไม่ได้อยู่ที่เรา เพราะงั้นคือถ้า backend เราร่วง user ก็ใช้ระบบเราไม่ได้ แต่พอเป็น WebAssembly มันเป็น client-side นั่นแปลว่าสมมติว่าเรามี logic อันหนึ่ง แล้วกันเป็น logic ในการ encryption key เนาะ ซึ่งถ้าปกติก็คือเราอาจจะบอกว่า โอเคไอ้ logic นี้มันเขียนสมมติว่า อาจจะเป็นเคสที่ว่าไอ้ logic ตรงนี้เนี่ย มันเขียนเป็นใน TypeScript ยากเหลือเกิน เขียนเป็น Rust มันง่ายกว่า แล้วก็อาจจะไปขึ้น API เป็น Rust แต่พอขึ้น API เป็น Rust เนี่ย เราก็ต้องไป deploy ตัว API ตัวนี้ แล้วก็ให้ชาวบ้านมานั่งทะลุมาหาเรา แต่ถ้าเกิดว่าเราไปปั้นตัวเนี้ยมาเป็น Rust แต่ว่าปั้นออกมาเป็น WASM แล้วเราเอา WASM ตรงเนี้ยมาฝังไว้ในหน้า frontend น่ะ มันเรียกกันเองได้เลยโดยที่หน้างาน โดยที่เราไม่ต้องไปทะลุ API ให้วุ่นวาย นั่นหมายความว่าเราไม่ต้องเปลืองตังค์ ในการมานั่ง deploy API

อือหือ ทีนี้มันก็มีข้อเสียเหมือนกันคือ ตัว WebAssembly เนี่ยมันใช้เวลาช้ากว่าในการรัน ถ้าเกิดเทียบกับเป็นแบบ native หรือ Docker แล้วกัน คือตรงนี้เป็น overhead เพราะว่า browser จริงๆมันก็ไม่ได้ไวอยู่แล้ว

แต่มันรันแบบ common มากที่แบบว่าทุกที่ก็คือมี browser ทุกที่คือใช้ browser ได้ เพราะฉะนั้นคือตรงเนี้ยมันเลยเป็นเรื่องของการ trade-off มากกว่าว่าเราจะแลกกันระหว่างตัว portability กับ speed ในการ execute ซึ่งตรงนี้ไม่ได้เป็นเรื่องแย่เสมอไป เพราะว่าบางทีคือ speed มันช้ากว่าก็จริง แต่ว่ามันอาจจะไม่ได้ต้องรันถี่ขนาดนั้น มันก็เลยไม่มีข้อขวด มันก็เลยเป็นความช้าที่มันพอรับได้อยู่แล้วกันประมาณนั้น อือหือ

การใช้งาน WebAssembly นอก Browser (WASM Outside Browsers)10:52

ทีนี้นอกจากการที่เราจะเอาตัว WebAssembly เนี่ยไปฝังไว้ใน browser ให้คนทั่วไปมาใช้ เราก็สามารถเอามารันแบบเป็น binary program ได้ปกติ คือหมายความว่าปกติสมมุติอาจจะเป็น .exe อะไรพวกนี้ เราก็สามารถเอาตัว WebAssembly ที่เป็น binary เนี่ยมารันตรงๆได้เหมือนกัน ก็แน่นอนว่า speed ก็ช้ากว่า แต่ก็มีข้อดีคือเราไม่ต้องมานั่งเสียเวลา setup pipeline

ในการทำ deploy หรือ release แล้วก็มานั่ง config แยกกว่า ถ้าเกิดเราจะ release ตัว binary เป็นแต่ละ target ให้มันรองรับทุกสิ่งอย่างบนโลกใบนี้ มันต้องทำยังไงกันยังไง เพราะว่าปกติถ้าเกิดเราจะ distribute ตัว binary

สิ่งที่เกิดขึ้นคือแน่ๆคือต้องมี Linux Darwin แล้วก็ Windows แล้วก็ต้องมี ARM64 แล้วก็ Linux AMD64

แล้วก็อาจจะมี RISC-V เข้ามาอีก ซึ่งตรงนี้บางทีอาจจะเจอผีที่ว่า ปั้น Intel ผ่าน แต่ปั้น ARM ไม่ผ่าน อันนี้ก็ต้องไปรื้อหน้ารันกันว่า dependency ลงครบไหม แล้วอีกอย่างนึงคือการที่เราต้องใช้กระบวนท่า ในการ cross-compile จากสมมุติเราอยู่บนเครื่อง AMD แต่ว่าเราต้องการปั้น binary เป็น ARM อย่างเงี้ย มันจะใช้เวลานานมาก คือถ้าเกิดว่าใครที่ใช้ M1 Mac รุ่นแรกๆแล้วต้องใช้ Docker จะจำได้ดี เพราะว่าทุกอย่างยังเป็น image AMD อยู่ แล้วเวลาเอามารันบน Mac มันจะช้าแบบเต่าคลานเลย ถึงขั้นต้องให้คนไปหัดวิธี build กันในเครื่อง ไม่งั้นคือทำอะไรกินไม่ได้ แล้วถ้าเกิดจะไป build แบบ ARM raw ไว้ ก็คือรอประมาณ 3 ชั่วโมงเสร็จได้ นอกจากจะไปปลุก runner CI ที่เป็น ARM มานั่งรัน

แต่ก็คือเราก็ต้องมานั่ง config ของใครของมันแยกอยู่ดี ก็เลยเป็น trade-off ตรงนี้ว่า คือเวลาที่เสียไปแต่ละจุดมี แต่ว่าเอามาเฉลี่ยกันเนี่ย ถ้าเกิดมันออกท่า WebAssembly เนี่ย อาจจะทำให้ทุกคนเสียเวลาน้อยสุดก็ได้เหมือนกัน

อือหือ

WebAssembly กับ IoT (WASM and IoT)12:53

ทีนี้พอมันเบาเนี่ย สิ่งที่เกิดขึ้นคือ IoT จะ happy มาก เพราะว่า IoT ที่ว่าเนี่ย อาจจะเป็นตัว single-board computer ที่ทำเป็น cluster อยู่บนพื้นที่ห่างไกล หรืออะไรก็แล้วแต่ หรืออาจจะเป็นรถก็ได้ หรือ vehicle ก็ได้

เพราะว่าอันนี้มีการใช้งานจริง คือบางที่ค่ะคือมันจะมีเหมือนกับ function บางอย่าง ที่เค้าต้องรันเวลามันเป็น part ของ OS บนพวกรถยนต์

แล้วการที่เค้า deploy มันออกมาเป็น WebAssembly เนี่ยทำให้มันกินที่บน onboard memory ไม่เยอะ แล้ว execution time ก็ถือว่ารับได้ เพราะว่าก็มีแต่คนเดียวใช้งาน ตรงนี้ก็เลยเป็นข้อดีที่ว่า การที่มันมี footprint ที่มันเล็ก เนี่ยทำให้มันคล่องตัวในการ deploy อีกอย่างนึงคือถ้าเกิดสมมุติว่า มันต้องมีการ update binary อะไรพวกนี้ มันก็จะกิน network bandwidth ไม่ค่อยเยอะ เพราะว่าตัว artifact size เนี่ยมันเบาอยู่แล้ว ทำให้มีความคล่องตัวมากขึ้น ในการจัดการอะไรหลายๆอย่างที่มันเป็นเกี่ยวกับระบบ IoT

อือฮึ

WebAssembly กับ CDN (WASM and CDN)13:56

ทีนี้ในเมื่อมันเป็น static และเป็น asset ปกติ เราสามารถไปขี่หลัง CDN ได้ CDN ถ้าเกิดแปลความก็คือ content delivery network ว่าง่ายๆ คือ สมมุติว่าเราดิพลอยเว็บไซต์เป็น static เป็น frontend ธรรมดา HTML JavaScript แล้วเราก็เราอยู่กรุงเทพฯ นะตอนนี้ แต่ server เราอยู่สมมุติอยู่ยุโรปแล้วกัน ถ้าเกิดว่าเราเข้าเว็บนั้นที่มันอยู่ยุโรป แต่เราอยู่ไทยอ่ะ มันจะช้า เพราะงั้นคือ CDN คือมันจะเป็นตัวกลางอีกทีนึงที่บอกว่า มันจะเหมือนกับคอยเอา source ของเราอ่ะ ไปวางไว้หลายๆ จุดบนพื้นที่ จะเป็นอเมริกา ยุโรป เอเชียอะไรก็ว่ากันไป แล้วเวลาเราเข้าไปเนี่ย เราก็จะไปเช็คว่าเราอยู่บนจุดไหนของโลก แล้วเราไป retrieve ของจากไหนถึงจะได้ของไวที่สุดแล้วกัน เพราะงั้นคือถ้าเกิดเทียบกันเนี่ย สิ่งที่เกิดขึ้นคือ ถ้าเป็นในเรื่องของ logic backend น่ะ เราก็ต้องดิพลอยในจุดที่มันใกล้ user ที่สุดน่ะ หมายความว่า ถ้า user เราอยู่ไทย เราคงจะไปดิพลอยที่สิงคโปร์ หรืออินโด หรือไทยแลนด์แล้วกัน

แต่ถ้าเกิดเป็น Wasm เนี่ย เราก็ไม่ต้องคิดอะไรมาก หน้ามืดให้มันเกาะหลัง CDN ไปเลย ก็เกาะกับ frontend ไป ก็ไม่ต้องไปนั่งทำเหมือนกับ replicate region deployment ให้มันมี duplicate deployment กันในหลาย region จะได้ low latency ในการ access service เหล่านี้

ตัวอย่างการใช้งานจริงจาก Google Earth (Google Earth Use Case)15:19

อือฮึ ทีเนี้ยในการใช้งานจริงเนี่ย Google ใช้งานจริงอยู่ค่ะ ก็คือทาง Google เนี่ยได้มีการนำ feature core หลักของ product Google Earth เนี่ย ออกมาเป็น Wasm แล้วก็เอาไปดิพลอยในหลายๆ แพลตฟอร์ม เพราะว่า Google Earth เนี่ยมันเป็น multi-platform แพ็คมันก็จะมีทั้งเว็บ โมบายล์ ร้านแปะอะไรก็ว่าไป เพราะงั้นคือการที่มันเป็นอย่างเงี้ยมันเลยกลายเป็นที่ว่า เราไม่จำเป็นต้อง implement core logic ในหลายๆ ภาษา เพราะว่าเวลาเขียนแอปหรือเขียนเว็บอะไรเงี้ย มันจะใช้คนละภาษากัน แต่ถ้าเกิดว่าเรา abstract ตัวนี้ออกไปเป็นก้อน Wasm เราสามารถแชร์ logic ก้อนเดียวกัน แล้วไม่ว่าคุณอยู่ที่ไหนก็ใช้งานได้นั่นเอง

WebAssembly กับ Containers (WASM and Containers)15:58

อือฮึ แล้วก็อีกอย่างนึงคือตัว Wasm เนี่ย เราสามารถเอามันไปมัดเป็น container ก็ได้ นั่นหมายความว่าตัว container เนี่ยก็จะมี 2 ท่า คือ 1. เราเอาตัว Wasm runtime อ่ะ ไปยัดไว้ใน container เลย แล้วก็เอา Wasm binary แปะปุ๊บเป็น entry point ไป หรือท่าที่ 2 ก็คือ มันเป็น container ที่มีแต่ Wasm binary เลย แต่ว่าเราให้ตัว Wasm runtime อ่ะ ไปเกาะหลังอยู่ตัว daemon ที่ดัน container อีกทีนึง ข้อดีก็คือ image มันจะเบามาก ซึ่งมันน่าจะเป็นเรื่องแบบปลาดมาก ถ้าเกิดว่า Docker image size แค่ 250 KB จะเป็นไปได้แล้วจริง

อือฮึ อันนี้ก็เป็นท่าดิพลอยอันนึงก็คือ เวลาดิพลอยจริงอ่ะก็คือ เราก็ไปขี่คอ CDN ไปเลย ถ้าเกิดว่าจะไม่ได้ดิพลอยเป็นท่า Docker ซึ่งก็ได้เหมือนกัน

Benchmark: เปรียบเทียบประสิทธิภาพ (Performance Benchmark)16:46

อันนี้เป็น benchmark นะคะ เทียบกันระหว่างการที่เราเอาตัว native function เป็น hello world ปกตินี่แหละ แต่ว่าเทียบกันระหว่างตัว Rust, Go, Python แล้วก็ Wasm จะเห็นได้ว่า ไม่แน่ใจอ่านได้มั้ย คือ Python น่ะที่มันตรงกลาง 2 อันน่ะ อันนั้นนานสุดอยู่แล้วแหละ แต่ว่าฝั่งซ้ายอ่ะมันจะเป็น Go ซึ่ง Go ที่เป็น Go native กับ Go Wasm อ่ะ ห่างกันประมาณนึง แต่ถ้าเกิดเป็นฝั่งขวา 2 อันน่ะ มันจะเป็น Rust ซึ่งจะเห็นได้ว่าที่เป็น Rust native กับ Rust ที่เป็น Wasm อ่ะ มันห่างกันไม่มาก เพราะงั้นคือถ้าเราอยากได้ performance ของ Wasm ที่มันดีที่สุดน่ะ เราจะต้องไปเขียนเป็น Rust แล้วก็ปั่นออกมาเป็น Wasm วิธีนี้จะทำให้ได้ Wasm binary ที่มีความไวสุด

เปรียบเทียบขนาดไฟล์ Binary และ Container (File Size Comparison)17:27

อันนี้เป็นตัว binary กับ container size ระหว่างที่เป็นตัว binary ของ Wasm กับ native แล้วก็ container ของ Wasm กับ native จะเห็นได้ว่า ถ้าเป็น binary size เนี่ย มันจะห่างกันประมาณ 400% ซึ่งก็ถือว่าเยอะอยู่ แต่ถ้าเกิดเป็น container เนี่ย คือห่างกันแบบเวอร์ไปเลย คือประมาณเกือบ 6,000% ประมาณนั้น ซึ่งตรงนี้ก็จะมีข้อดีคือในการที่เราลด cost ในการที่เราต้อง store image container เอาไว้บน cloud ได้ ก็จะลดตังค์ไปได้เยอะประมาณนึง

การเรียก WebAssembly จากภาษาอื่นๆ (Calling WASM from Other Languages)17:55

ตัวนี้เป็นการที่ลองเอาตัว Wasm อ่ะค่ะ มาเรียกกับภาษาอื่น นั่นหมายความว่าคือจริงๆ อ่ะ Wasm ของมันอ่ะอยู่ของมันอยู่แล้วแหละ แต่ว่าจะลองใช้ภาษาอื่นเช่น Go, Rust, Python มาเรียก Wasm จะเห็นได้ว่า ข้างล่างที่เป็นสีม่วงๆ ค่ะ อันนั้นคือเป็น Wasm ตรงๆ เนาะ มันก็ไวสุดอยู่แล้ว แต่ว่าถ้าเกิดเป็นข้างบนสุดน่ะจะเป็น Python จะเห็นได้ว่า การที่เราเรียก ต่อให้เป็น Wasm ก็ตาม แต่ว่าเรียกผ่าน Python มันจะใช้เวลานานสุด ในขณะเดียวกันถ้าเกิดเป็น Rust กับ Go เนี่ย มันจะใช้เวลาห่างกันไม่ค่อยมาก อันนี้ก็แล้วแต่สะดวกว่า ecosystem ของแต่ละบริษัทใช้อะไรเป็นหลัก

ซึ่งในการเรียกตรงนี้ก็ overhead ไม่ได้ต่างกันมาก ก็คือใช้อันไหนก็ได้ ถ้าเกิดแคร์เรื่อง performance นะคะ

ช่วงถาม-ตอบ (Q&A)18:34

โอเค ก็ประมาณนี้ค่ะ หมดแล้ว มีคำถามมั้ยคะ

โอเคครับผม ก็ขอขอบคุณพี่กานนะครับผม

ก็เรื่อง WebAssembly นะครับ สำหรับทีนี้นะครับก็อย่างที่ผมได้กล่าวไปในช่วงขั้นต้น ใช่มั้ยครับว่าเรามีการ Q&A นะครับผม แล้วก็ใครก็ตามนะครับที่ถาม meaningful question นะครับ ไม่ต้องตึงมากก็ได้นะครับ เรามีแจก JetBrains นะครับ เป็น license 1 ปีเลยครับผม

เข้าสู่ช่วง Q&A ครับ มีใครอยากจะถามคำถามอะไรมั้ยครับ เกี่ยวกับ WebAssembly เชิญครับผม เชิญครับ

คำถามที่ 1: WebAssembly กับ Front-end และ SEO (WASM, Front-end & SEO)19:30

โอเคครับ คือส่วนตัวผมอ่ะ ผมมอง WebAssembly กับตัวที่เป็นของฝั่ง front-end ฝั่ง client น่ะครับ คือส่วนตัวผม ผมมีความสงสัยว่า ถ้าเหมือนเป็นตัวฝั่งของ front-end น่ะ ตัว WebAssembly กับตัวของฝั่งพวกเหมือน JavaScript พวกเช่นพวก React พวก Next อย่างเงี้ย ไอ้ฝั่งของ WebAssembly อ่ะ มันดูจะมี performance ที่มากกว่า ทำไมแบบหลายๆ ที่เค้ายังถึงไม่เป็น ยังไม่ migrate ไปเป็นตัวของ WebAssembly แล้วก็อีกคำถามนึงพวกมีด้วยคือ เพราะว่าผมสนใจฝั่งของ front-end นะครับ คือในมุมมองของ SEO อ่ะ

ตัวของ WebAssembly มันสามารถทำให้แบบ SEO ดีๆ ได้มั้ยครับ อันนี้คิดว่าต้องแยกกันค่ะ คือหนึ่งตัวจริงๆ อ่ะ WebAssembly เนี่ยมันเป็นท่า

มันเป็นท่าปะกาวแล้วกัน คือมันจะเป็นเคสที่ว่า มันมีสักอย่างอ่ะ ที่แบบต้องการให้มันใช้กันได้ทั่วๆ กันน่ะ แต่ว่าคือไอ้คนใช้อ่ะ มันดันอยู่คนละภาษา อยู่กับคนละ ecosystem เงี้ย คือเหมือนสภาพว่าเหมือนที่แบบบางทีอ่ะ ถ้าเกิดเราจะคุย low-level มากๆ เราต้องใช้ภาษา C แต่ปัญหาก็คือ แต่คือเราอยู่ Go เราอยู่ Rust อยู่ Node เพราะงั้นคือเราก็ต้องเหมือนกับหาทางปะกาว ให้แบบอะไรก็ได้คือ ไปเรียก C มาให้ได้แล้วกัน แต่ว่าเรามาต้องเป็น C เพราะว่ามีแต่ C คุยกับมันรู้เรื่องอย่างเงี้ยเป็นต้น เพราะงั้นคือมันเลยเป็นเคสที่ว่า อะไรที่เป็นเคสที่ว่าคือมันต้องใช้กันหลายที่อ่ะ

แต่ว่าคือไม่ได้มีแต่ front-end ใช้อ่ะ ประมาณนั้น มันก็เลยควรจะเอาไป port อะไรเป็น Wasm แล้วก็เรียกอีกทีนึงเป็นเหมือนกับเป็น foreign object อ่ะ ที่ให้ตัวหน้าบ้านอ่ะ ไปเรียกอีกทีนึงประมาณนั้น ส่วนในเรื่องของ SEO เนี่ย จริงๆ คือคิดว่าไม่เกี่ยวกัน เพราะว่า Wasm ก็คือปั้นออกมาเป็น binary Wasm แล้วกัน เพราะงั้นคือ น่าจะไม่ได้มีความเกี่ยวข้องอะไรกับ SEO คือที่ผมหมายถึงคือแบบ สมมติจะทำแบบทั้งเว็บ ทาง front-end อ่ะ เป็น WebAssembly เลย เพราะว่าเหมือนผมเคยใช้บางที่อ่ะ ที่เป็นแบบเหมือน front-end ที่เป็น WebAssembly เลยอ่ะครับ คือสมมติถ้าแบบอยากทำทั้งก้อนนั้นน่ะ เป็นอย่างนั้น พอมีทางที่จะเป็นไปได้มั้ย จริงๆ ถ้าเกิดมี มันจะมี Rust framework ตัวนึงค่ะ egui มั้ง ถ้าจำไม่ผิดนะ ตัวเนี้ยก็คือ มันจะเป็น UI framework ที่เราก็ใช้ Rust เขียนนั่นแหละ แต่ว่าเวลามันปั้นออกมาค่ะ แล้วเวลามันทำ deploy อ่ะ คือมันสามารถปั้นออกมาเป็น WebAssembly แล้วก็ไป deploy ท่านั้นได้ ถ้าเกิดเป็นของ Go ก็จะมีตัว fyne มั้ง จำชื่อไม่ได้ f อะไรสักอย่างนึงก็แหละ อันนั้นก็คือทำเป็น front-end แล้วก็ปั้นออกมาเป็น Wasm ได้เหมือนกัน แต่ว่าจะมีข้อเสียนะ คือ Wasm ทั้งก้อนที่เป็น front-end น่ะ มันจะช้าแบบเต่าเลย ก็คือแบบนั่ง initial ร่างกายมันคือแบบรอแบบวิสัยเลยอ่ะ เพราะงั้นคืออันนี้ไม่แนะนำ อีกอย่างนึงคือ อาจจะหาคนมาทำต่อแล้วก็ maintain ยาก แล้วก็พอมันไม่ได้เป็น plain text น่ะ มันจะมี overhead ในการที่มันนั่งเหมือนกับ parse อะไร เพราะงั้นคือถ้าเกิดเป็นเว็บที่ ถ้าเกิดเป็น caller ที่เค้า เหมือนกับไม่ได้ทำให้มันดัก แล้วมันสามารถคุยกับไฟล์ WebAssembly ได้ อาจจะเหนื่อยหน่อยประมาณนั้น ซึ่งไม่แนะนำ คือจริงๆ ถ้าเกิดเป็น condition ที่ว่าเป็น front-end เลยอ่ะ อย่างเงี้ย จะไม่แนะนำให้ทำทั้งก้อนเป็น WebAssembly ไม่แนะนำ

ก็คือจะให้เป็นบางส่วน อาจจะแบบเรียก iframe เป็น WebAssembly อย่างนั้นใช่มั้ยครับ ใช่เหมือนกัน คืออะไรก็ตามที่คิดว่าเขียนเองใน Node แล้วมันเขียนยาก

ไปเขียนภาษาอื่นแล้วก็ปั้นมาง่ายกว่า หรือเป็น function core logic ที่ mobile ก็ต้องใช้ desktop ก็ต้องใช้ web ก็ต้องใช้อะไรอย่างเงี้ยเป็นต้น แทนที่จะไป implement ใหม่ทุกรอบ ก็คือทำเป็นกองกลางไปเลย ขอบคุณครับ

คำถามที่ 2: Use Cases และการเลือกใช้ WebAssembly (Use Cases & Selection Criteria)23:01

พี่กานครับ ถือว่าเป็น meaningful question รึเปล่าครับผม ถือว่าคำถามดีนะคะ อยากแจกมั้ยครับ อยากแจกมั้ย อ้อ อ่าแล้วมีเหมือนเค้าจะสละสิทธิ์เลยนะครับผม แต่เค้าจะไม่ได้รับสละนะครับ มีใครมีคำถามเพิ่มเติมมั้ยครับผม

มีมั้ยครับ มีนะครับ ครับ

ได้ครับ โอเคครับ อยากถามเกี่ยวกับ use case ที่เราควรจะเลือกใช้ Wasm นะครับ เพราะว่าอย่างในบางเคสก็ ตอนนี้ยังนึกไม่ออกว่า ถ้าจะต้องไปใช้ Wasm เนี่ย จะใช้ในกรณีใดบ้าง นอกจากพวกที่มันเป็น computing intensive นะครับ

หรือว่า แล้วก็อีกอย่างนึงก็คือว่า เรามีหลักในการเลือกยังไงบ้างว่า เคสเนี้ย native Node.js มัน work อยู่แล้ว แทนที่มันจะต้องไปเขียนเป็น Wasm หรือเคสเนี้ย Node.js มันเกินกำลังละ มันควรจะต้องไปใช้ Wasm แทนอ่ะครับ อ่า โอเคค่ะ มี 2 คำถามนะ ก็คือ 1 ก็คือสลับ workload intensive อะไรเงี้ย จริงๆ มองว่างี้ค่ะ คือในอะไรก็ตาม Wasm อ่ะ คือมันผ่านตัวแปลภาษามาแล้วรอบนึง เพราะงั้นคือยังไงมันก็ช้ากว่าอยู่แล้วแหละ เพราะงั้นคือถ้าเกิดต้องการอะไรที่มันไว หรือ intensive อ่ะ จะไม่แนะนำให้แต่ Wasm เลย แต่ว่า Wasm เนี่ยมันจะมีข้อดีตรงที่ว่าคือ เอางี้ Wasm อ่ะ มันจะดันช้ากว่าชาวบ้านนะ แน่นอนยังไงก็ช้ากว่า แต่ว่ามันจะมีข้อดีตรงที่ว่า

คือถ้าเกิดเป็นอย่างเคส ตัวอย่างก็คือเป็น product Google Earth ของ Google ที่เค้าต้อง deliver และ deploy หลาย platform เช่น มันก็จะมี Google Earth บน web บน mobile ที่เป็น Android แล้วก็ iOS แล้วก็จะมีบน desktop ซึ่งก็เป็น desktop ทั้ง Windows Mac Linux อะไรพวกเนี้ย ซึ่งมันจะมี core logic บางอย่างเหมือนกันอยู่ในนั้น แต่ว่าคือเราก็รู้กันว่า Android ใช้ Kotlin

หรือ Java เขียนใช่มั้ย แล้ว iOS ก็ใช้ Swift บน Windows ก็อะไรก็ไม่รู้

หรืออาจจะเป็น Electron ก็ได้ ง่ายๆ หน่อยใช่มั้ย หรือถ้าเกิดเป็น Mac เป็น macOS app ก็อาจจะเป็น Swift หรือ Electron ก็ได้ถ้าเกิดหน้ามืดหน่อย Linux ก็ GTK อะไรก็ว่ากันไป

คือเพราะงั้นคือถ้าเกิดว่าเราต้องไปใช้ tool แยก ในการที่ implement core logic เนี่ย มันจะกลายเป็นงานถึกมากๆ เพราะว่าคือ logic แบบเดียวกัน คือต้อง implement ประมาณ 3-4 ทีมพร้อมกันน่ะ เพราะงั้นคือตรงเนี้ยถ้าเกิดว่าเราสามารถ extract core logic ออกมาเป็น Wasm ได้ เนี่ยมันสามารถทำให้ใครก็ตามที่อยู่ไหนก็ไม่รู้ แต่ว่าเราเรียกไปใช้ได้เลย โดยที่ไม่ต้องมีการ reimplement logic ใหม่ ในภาษาปลายทาง มันจะเป็นเคสนี้มากกว่าค่ะ เอ่อ ก็คือว่าหมายความว่า อะไรที่เรา ที่มันจะเป็น multi-platform มากๆ เนี่ย Wasm จะเป็นตัวเลือกที่ดี ถูกต้องค่ะ คือเราก็แค่ทำหน้ากาก interface แต่ละ platform แยกไว้ แต่ว่าตัวไส้กองกลางคือเราก็มาจิ้ม Wasm ทีเดียวเลยจบ ไม่ต้องไปนั่ง implement แยกในแต่ละที่เอง โอเคครับ ขอบคุณครับ น่าจะเคลียร์ละ

ขอบคุณนะครับ

ประกาศผู้โชคดีและปิดท้าย (Winner Announcement & Closing)26:03

ทีนี้ถึงช่วงเวลายากนะครับ

อยากจะให้ อยากมีคำถามเพิ่มเติมมั้ยนะครับ ถามก่อน ก่อนที่เราจะเริ่มแจกตัวนะครับ

งั้นเดี๋ยวขอให้พี่กานคิดดีกว่าว่า จะเริ่มคิดหนักกันใช่มั้ยเปล่า เพราะอยากแจก จะเป็นใครดีนะครับ อ่ะให้คุณซื้อ โอเคครับผม

ขอ congratulations นะครับสำหรับ 1 year license นะครับผม ครับผม

เดี๋ยว year ที่ 2 ต้องซื้อเองนะครับ ครับ ขอบคุณพี่กานมากเลยครับ พี่