4 คะแนน โดย GN⁺ 2023-09-06 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Watlings เป็นโปรเจ็กต์ฝึกฝนสำหรับเรียนรู้ WebAssembly Text Format ผ่านการแก้โปรแกรมเล็ก ๆ หลายรายการ
  • แต่ละแบบฝึกหัดให้ทำตามคำแนะนำในไดเรกทอรี exercises และทดสอบคำตอบด้วย npm start 001_hello
  • การตรวจดูเฉลยใช้คำสั่ง npm run show 001_hello และการนำเฉลยไปใช้กับแบบฝึกหัดโดยตรงใช้คำสั่ง npm run solve 001_hello
  • ใช้ Node 23+ และ wasm-tools สำหรับการคอมไพล์และทดสอบ โดยภายในสคริปต์จะเรียก wasm-tools parse
  • แบบฝึกหัดตั้งแต่หมายเลข 015 เป็นต้นไปใช้ฟีเจอร์ WebAssembly ที่ใหม่กว่า เช่น exception handling และ GC types และต้องใช้แฟลก --experimental-wasm-exnref ที่มีให้เฉพาะใน Node.js 23 ขึ้นไป
  • มี เวอร์ชันเว็บ ให้ใช้งานบนเบราว์เซอร์ และแนะนำให้ใช้ VSCode พร้อมส่วนขยาย wat-lsp เป็นตัวแก้ไข
  • แนวทางการเรียนรู้เป็นแบบ เน้นการลงมือเขียนโดยตรง โดยใช้คอมเมนต์ในแต่ละไฟล์เพื่ออธิบายงานและพื้นหลัง ลดคำอธิบายให้น้อยที่สุด และเน้นให้ได้พบไวยากรณ์ซ้ำ ๆ ในบริบทที่แตกต่างกัน
  • ระบุ rustlings และ Ziglings เป็นตัวอย่างอ้างอิงของโครงสร้างโปรเจ็กต์

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

 
GN⁺ 2023-09-06
ความคิดเห็นจาก Hacker News
  • เห็นพูดกันอยู่บ่อย ๆ หลายที่ แต่สิ่งที่ WASM ในเบราว์เซอร์ขาดไปไม่ใช่แค่ การเข้าถึง DOM เท่านั้น แต่รวมถึงแทบทุก Web API รวมถึง fetch และ XMLHttpRequest ด้วย
    รายการ Web API ที่เบราว์เซอร์รองรับแต่ WASM ไม่รองรับอยู่ที่นี่ และ DOM เป็นเพียงหนึ่งในนั้น: https://developer.mozilla.org/en-US/docs/Web/API
    ถึงอย่างนั้น หาก GC ได้ข้อสรุปและเบราว์เซอร์รองรับ ก็มีความเป็นไปได้ที่จะใช้อินเทอร์เฟซเหล่านี้ได้ ระบุไว้ว่าถ้ารองรับ GC โค้ด WebAssembly จะสามารถอ้างอิงและเข้าถึง JavaScript, DOM และอ็อบเจ็กต์ที่นิยามด้วย WebIDL ทั่วไปได้
    ดูย่อหน้าสุดท้าย: https://webassembly.org/docs/web/

    • ข้อเสนอ GC ออกมาตั้งแต่ปี 2018 แล้ว https://github.com/WebAssembly/proposals/issues/16 และมีโค้ดด้วย: https://github.com/WebAssembly/gc/blob/master/proposals/gc/O...
      เมื่อคิดถึงความเป็นไปได้ที่มันจะเปิดทางให้ได้ ดูเหมือนว่าความคืบหน้าจะ ช้ามากเกินไป
    • ถ้า “แก้” เรื่องนั้นได้ ก็มีความเสี่ยงว่าจะกลายเป็น Java Applets รุ่นถัดไป
    • ไม่ได้ติดตาม WebAssembly ต่อเนื่องนัก แต่สงสัยว่าทำไมสิ่งที่เคยถูกเรียกว่า “ยารักษา” JS ถึงใช้เวลานานขนาดนี้กว่าจะมี ฟังก์ชันพื้นฐาน
  • ดูคล้ายกับโมเดลของ Exercism มาก ใน Exercism ก็มี คอร์ส WASM ฟรีที่เต็มไปด้วยแบบฝึกหัดเล็ก ๆ: https://exercism.org/tracks/wasm
    สงสัยว่าผู้เขียนเคยพิจารณาจะมีส่วนร่วมกับคอร์สนั้นหรือทำงานร่วมกันหรือไม่ แบบนั้นน่าจะเข้าถึงผู้อ่านได้กว้างขึ้น และใช้ประโยชน์จากเครื่องมือที่ Exercism มีอยู่แล้วได้ด้วย

    • ชอบ Exercism มากจริง ๆ แต่โมเดลแบบฝึกหัดของที่นั่นเป็น รูปแบบอิสระ กว่ามาก เป็นก้อนใหญ่กว่ามาก และสอนน้อยกว่าโดยเปรียบเทียบ
      ในบางบริบทมันเป็นโมเดลที่ดี แต่รูปแบบของ repo นี้ใกล้กับ rustlings หรือ ziglings ที่เรียนไวยากรณ์และฟีเจอร์ไปพร้อมกับตัวอย่างโค้ดมากกว่า
      โมดูล Wasm ของ Exercism ก็ไม่ได้ “เสีย” อะไร เลยไม่แน่ใจว่าการมีส่วนร่วมของผมจะได้รับการต้อนรับหรือไม่
    • สิ่งที่ไม่ชอบใน Exercism คือ นอกจากภาษายอดนิยมแล้ว แบบฝึกหัดโดยรวมมัก ไม่เป็นระบบ
      กล่าวอีกอย่างคือมันใกล้กับชุดโจทย์แบบ LeetCode ที่เรียงตามระดับความยากมากกว่า
      ถ้าเป็นคอร์สที่ดีจริง ๆ ควรจัดแบบฝึกหัดตามฟีเจอร์ของภาษา Exercism ได้สร้างอินเทอร์เฟซที่ยอดเยี่ยมสำหรับเรื่องนี้ไว้แล้ว แต่ภาษาส่วนใหญ่ไม่ได้ใช้ประโยชน์จากมัน: https://exercism.org/tracks/csharp/concepts
  • หนึ่งในวิธีที่ชอบใช้เวลาเรียนภาษาใหม่หรือเฟรมเวิร์กใหม่คือ koans และอันนี้ทำให้นึกถึงสิ่งนั้น: https://github.com/ahmdrefat/awesome-koans/blob/master/koans...
    มันไล่ระดับจากฟีเจอร์พื้นฐานไปจนถึงขั้นสูงได้อย่างนุ่มนวล และกระบวนการแบบ TDD ที่เห็นเทสต์ล้มเหลว ทำความเข้าใจเหตุผล แล้วแก้ไข เหมาะกับการเรียนรู้มาก แถมยังให้โดพามีนตอนเกิดช่วง “อ๋อ!” ด้วย

    • ฟังดูเป็นวิธีที่ดีสำหรับการเรียนภาษาเองคนเดียว เสียดายที่ไม่มี Rust อยู่ด้วย สงสัยว่าพอจะแนะนำลิงก์ได้ไหม
  • ถ้าจะทดลอง ฟีเจอร์อย่าง GC ของ WASM แนะนำให้ใช้ wasm-opt ของ Binaryen แทน WABT เพราะ wasm-opt รองรับส่วนขยายของ WASM ได้มากกว่ามาก

  • ค่อนข้างเจ๋ง
    ยังไม่เคยลงลึกกับ WASM โดยตรง แต่คิดว่าจะลองทำตามไกด์นี้ และตอนนี้ที่ผ่านมาหลายปีแล้ว ก็คิดว่ามันให้ ประโยชน์อย่างมาก กับการพัฒนาเว็บ
    มันไม่ใช่ “ตัวฆ่า JavaScript” อย่างที่บางคนคาดหวัง แต่เดิมทีมันก็ไม่ได้มีเป้าหมายนั้นอยู่แล้ว แทนที่จะเป็นแบบนั้น มันผสานกับระบบนิเวศเดิมได้ค่อนข้างดีเพื่อปรับแต่ง use case ที่มีอยู่ให้เร็วขึ้น และยังเปิด use case ใหม่ ๆ เมื่อจำเป็นต้องมีการคำนวณหนัก ๆ
    เป็นผลดีสุทธิสำหรับนักพัฒนาเว็บทุกคน เราได้ไลบรารีที่เร็วขึ้น เครื่องมือพัฒนาที่น่าประทับใจ และไบนารีของ Node ที่พกพาได้ดีขึ้น

    • ผมเฝ้าดู WASM จากระยะไกล และเข้าใจว่า เหตุผลที่มันไม่ใช่ตัวฆ่า JS คือเพราะไม่สามารถเข้าถึง DOM หรือ DOM API ส่วนใหญ่ได้โดยตรง
      สงสัยว่ามีเหตุผลอื่นที่ผมพลาดไปหรือไม่
  • ดีใจที่การนำ WebAssembly ไปใช้ยังคืบหน้าอย่างต่อเนื่อง ที่นี่ Microsoft มักถูกพูดถึงเพียงเล็กน้อย แต่ถ้าสนใจ WASM แนะนำอย่างยิ่งให้ลอง Blazor WebAssembly
    เป็นเฟรมเวิร์กที่ทรงพลังมาก ซึ่งทำให้ใช้ C# ไลบรารี .NET ส่วนใหญ่ และแม้แต่แพ็กเกจ NuGet ในรูปแบบ WASM ที่คอมไพล์แล้วภายในเบราว์เซอร์ได้

    • ตอนบอกว่า “แพ็กเกจ NuGet ส่วนใหญ่” สงสัยว่า ข้อจำกัด คืออะไร
      ถ้าเป็นแพ็กเกจที่ต้องอ่านไฟล์จากดิสก์ มันจะล้มเหลวทันทีหรือเปล่า หรืออินเทอร์เฟซอ่านไฟล์จะส่งต่อการทำงานไปยังอะไรอย่าง server-side rendering หรือไม่
    • จากที่อ่านมา ดูเหมือนจะมีปัญหาเดียวกับตอนคอมไพล์ Go เป็น WASM คือ เพย์โหลดใหญ่ และแม้บีบอัดแล้วก็มักมีขนาดหลาย MB
  • โปรเจกต์เจ๋งมาก
    ผมดูแล repo ที่เกี่ยวข้องอยู่บ้างที่นี่: https://github.com/eliben/wasm-wat-samples/

    • ดูมีประโยชน์จริง ๆ ถ้ารู้จักสิ่งนี้ตอนเริ่มเรียน wat ก็คงดี น่าจะเป็นแหล่งอ้างอิงที่ยอดเยี่ยม
  • เคยลอง WASM แล้วเจอปัญหาในการเปิดเผย การเชื่อมต่อฐานข้อมูล SQLite ที่พยายามเชื่อมต่อแบบโลคัล
    สงสัยว่ามีใครเคยทำอะไรคล้าย ๆ กัน หรือมีแหล่งข้อมูลดี ๆ แนะนำไหม

    • ลองดู Spin ก็น่าจะดี ตั้งแต่ 1.4 เป็นต้นมา รันไทม์มี การรองรับ SQLite มาให้ในตัว: https://www.fermyon.com/blog/spin-v14
  • น่าสนใจมากที่ WebAssembly ดูเหมือนเป็น ภาษาจริง ๆ ที่พอจะเขียนด้วยมือได้
    น่าจะช่วยลดกำแพงการเริ่มต้นเมื่อตั้งเป็นเป้าหมายการคอมไพล์ได้มากทีเดียว

  • เมื่อ WebAssembly กำลังกลายเป็น ภาษากลาง ของหลายระบบนิเวศ การลงทุนเวลาเพื่อทำความเข้าใจวิธีการทำงานของมันอย่างแน่นหนาก็ยิ่งคุ้มค่าขึ้น