Microsoft เริ่มแปลง WinUI ของ Windows 11 เป็นโอเพ่นซอร์ส

 (neowin.net)
6 คะแนน โดย GN⁺ 2025-08-07 | 3 ความคิดเห็น | แชร์ทาง WhatsApp
  • Microsoft ได้ประกาศแผนเป็นขั้นตอนเพื่อเปิดซอร์ส WinUI ซึ่งเป็น เฟรมเวิร์กอินเทอร์เฟซผู้ใช้ ของ Windows 11
  • WinUI มีโครงสร้างที่ซับซ้อนและโค้ดที่เป็นกรรมสิทธิ์จำนวนมาก จึงไม่สามารถเปิดเผยได้ทั้งหมดในทันที (ต้องมีการแยกส่วนที่ สามารถแบ่งปันได้กับส่วนที่ไม่สามารถแบ่งปันได้)
  • การเปิดซอร์สคาดว่าจะดำเนินการผ่าน สี่ขั้นตอน
    • ขั้นที่ 1: เพิ่มความถี่การอัปเดตการ mirror : หลังจากปล่อย WASDK 1.8 (ปลายเดือนสิงหาคม) จะซิงก์คอมมิตภายในกับ GitHub บ่อยขึ้น เพื่อแบ่งปัน ความโปร่งใสและความคืบหน้าการพัฒนา
    • ขั้นที่ 2: การสร้างและคอมไพล์ในเครื่องสำหรับนักพัฒนาภายนอก : ผู้พัฒนาภายนอกจะสามารถคลอนรับโค้ดมาและทำการคอมไพล์บนเครื่องท้องถิ่นได้เอง และยังมีการให้ เอกสารการตั้งค่าและ dependency ด้วย
    • ขั้นที่ 3: การมีส่วนร่วมและการทดสอบจากภายนอก: ผู้มีส่วนร่วมจากชุมชนจะสามารถส่ง Pull Request และทดสอบแบบ local ได้ และจะมีการจัดระเบียบ dependency ภายในและเปิดเผย โครงสร้างพื้นฐานสำหรับการทดสอบ ด้วย
    • ขั้นที่ 4: การย้ายระบบการพัฒนาให้เป็นศูนย์กลางด้วย GitHub : สุดท้าย GitHub จะกลายเป็น ศูนย์กลางหลักของการพัฒนา การจัดการ issue และการสื่อสารกับชุมชน ในขณะที่ระบบ mirror ภายในจะถูกยกเลิกทีละขั้น
  • แผนโอเพ่นซอร์สของ WinUI ถูกจัดการแบบสาธารณะบน GitHub Project Board
  • นักพัฒนาและผู้ใช้สามารถมีส่วนร่วมในพัฒนาการของ WinUI ได้ผ่าน feedback, การเขียน issue อย่างชัดเจน, และการโหวตความคิดเห็นเดิม

บทความที่เกี่ยวข้อง

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

 
regentag 2025-08-07

ไม่ชอบ COM หรือ Webview ... ถ้ามี GUI ที่ใช้งานได้จริงสักตัวก็ดีเลยนะ ตอนนี้ในบรรดา UI สำหรับ Windows ที่เคยลองใช้มาแล้ว ตัวที่ชอบที่สุดก็คือ Qt4 นี่แหละ ตั้งแต่ Qt5 เป็นต้นมา รู้สึกว่า "ฟีล" เปลี่ยนไปเยอะมาก
 
regentag 2025-08-07

จริง ๆ แล้วผมก็จำได้ว่า MFC ก็มันไม่แย่มากนะ...ฮ่าๆ
 
GN⁺ 2025-08-07
ความคิดเห็นจาก Hacker News

  • ฉันกังวลเกี่ยวกับอนาคตของเทคโนโลยี UI เนทีฟของ Windows ผู้พัฒนาระบบปฏิบัติการมักสร้างแอปเนทีฟที่ทำงานได้ดีและมีความสอดคล้องกันด้วยผลิตภัณฑ์ที่ตัวเองใช้เอง แต่ใน Windows 11 กลับเกิดเรื่องตรงกันข้าม ตั้งแต่ Windows 10 เป็นต้นมา ก็มีแอป Mail และ Calendar พื้นฐานที่อย่างน้อยก็ทำงานได้ แต่ในการอัปเดตล่าสุดของ Windows 11 แอปเหล่านี้ถูกลบออก และถูกแทนที่ด้วย WebView wrapper แบบช้า ทำให้ใช้เวลาเป็นวินาทีในการรัน

    • ถ้ามองจาก WinUI Community Call จะเห็นว่าพนักงานหน้าใหม่ส่วนใหญ่แทบไม่มีประสบการณ์กับ Windows และผู้บริหารเองก็ไม่ค่อยให้ความสำคัญ ทำให้ไม่สามารถยึดหลักการพื้นฐานได้อย่างเข้มแข็ง คำถามที่นักพัฒนา Windows ควรรู้ดีควรตอบได้ กลับยังตอบไม่ได้ และยังไม่เข้าใจด้วยซ้ำว่าคำถามเหล่านั้นมาจากที่ไหน ปัจจัยนี้ทำให้ตัวอย่าง WebView2 แผ่กระจายเต็ม Windows 11

    • ปัญหาของ UI ใน Windows 11 คือให้ความสำคัญกับแอปและฟีเจอร์ใหม่มากเกินไป พร้อมกับไม่อัปเดตเครื่องมือเก่า ตัวอย่างเช่น Control Panel แทบไม่เปลี่ยนสกินมานานตั้งแต่ Windows 7 ขุดลึกลงไปอีกจะเห็นเครื่องมือเก่าๆ ซ่อนอยู่รอบๆ เหมือนคลิปติดอยู่ที่ตัวโฮเมอร์ ซิมป์สัน มันดูใหม่จากด้านนอกเท่านั้น แต่พอใช้งานจริงจุดอ่อนก็โผล่ขึ้นเร็วมาก

    • สักวันหนึ่งอาจเห็นการเขียนใหม่ MSO (Office) ด้วยเทคโนโลยีอย่าง Dart และ WASM อย่างสมบูรณ์ ในรูปแบบที่แยกออกจาก Native toolkit อย่างแท้จริง และอาจทำให้การทำซ้ำความสามารถทั้งหมดของ Excel พร้อมใช้งานได้แบบ Anywhere ในรูปแบบ O365 Premium Plan สุดท้ายอาจกลายเป็นเหมือน ChromeOS ที่มี UI เนทีฟแค่บริเวณล็อกอิน/ล็อกเอาต์เท่านั้น ที่เหลือจัดการแบบเบาๆ

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

    • Windows รู้สึกเหมือนปะปน UI framework ต่างๆ กันอย่างน้อย 10 ตัว Windows 11 เหมือนไปเที่ยวพิพิธภัณฑ์ธรรมชาติ ก็ยังมีแอปที่ค้างอยู่กับดีไซน์สมัย Windows 2000 แบบ MSC และเห็น UI โทน Metro ที่หยาบและสีจัดอย่างชัดเจน Win11 style สมัยใหม่ดูมีชีวิตชีวา แต่จริงๆ คล้ายการทาลิปสติกให้หมู เมนูคลิกขวาคือกรณีตัวอย่างที่ชัดที่สุด ดูดีแต่ฟีเจอร์ยังไม่พอ จนต้องกดปุ่ม "เพิ่มเติม" ถึงจะเห็นความสามารถมากขึ้นแบบสไตล์เก่า สรุปแล้วคือความวุ่นวายไปหมด

  • เมื่อฟังคำประกาศของ Microsoft อย่าง "alignment กับเป้าหมาย Microsoft" หรือ "จัดสรรทรัพยากรอย่างรอบคอบ" รู้สึกว่าความซื่อสัตย์ขาดหายไป ในทางกลับกันดูเหมือนนโยบายกำลังผลัก framework ออกไปให้ผู้ร่วมพัฒนาภายนอกที่มีแต่ความตั้งใจเข้ามาดูแล โดย Microsoft ค่อยๆ ถอนทรัพยากรตัวเองออก

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

    • พูดให้ตรงกันใหญ่ก็ชัดเจนว่ามันคือคำแบบองค์กรที่ว่า "ไม่มีการรับประกันการซัพพอร์ต ไม่มีแผนอัปเดตเพิ่มใดๆ นอกจากแก้บั๊กความปลอดภัย ใช้เอาเอง"

    • มีมุขในใจว่า "Apache Windows จะออกเมื่อไหร่นะ" ถ้าพูดตรงๆ เดสก์ท็อป UI toolkit ตอนนี้ไม่เหลือความสามารถเป็นจุดขายหรือความยากในการเข้าไปพัฒนาอีกแล้ว เพราะใน Windows มีสไตล์ทางการอย่างเป็นทางการ 3-4 แบบ แต่ความปลอดภัยและเสถียรภาพยังเป็นสิ่งที่ Windows ต้องพึ่งพาเพื่ออยู่รอดในองค์กร การเงิน และหน่วยงานรัฐ

    • การเปิดซอร์ส UI framework ของบริษัทอื่นก็มีเหตุผลบางอย่างที่เข้าใจได้ เช่น framework ของ Atlassian หรือ AWS ใช้กับ Jira/AWS จึงเหมาะลองใช้กับ B2B SaaS แต่สำหรับ framework นี้ไม่รู้เลยว่าควรจะใช้ทำไม หากไม่ได้ทำแค่แอปเนทีฟบน Windows โดยตรง ก็คิดว่ามีทางเลือกที่ดีกว่าอยู่แล้ว

    • ผมคิดว่า WinUI ล้มเหลว

  • ในชุมชนพัฒนา Windows คนที่ยังใส่ใจ WinUI มีน้อยมาก เหลือแต่ผู้ที่เคยลงทุนใน WinRT/UWP มาจนติดอยู่แล้วไม่สามารถหลุด ตั้งแต่ Windows 8 เป็นต้นมา มีการตัดข้อต่อมากเกินไป จนชุมชนสูญเสียความไว้วางใจ โดยนัย มันดูเหมือนว่า Microsoft เลือกโยนปัญหาให้ชุมชนแทนที่จะซ่อมเอง

    • บริษัทอย่าง DevExpress และ Progress Telerik เองก็ไม่ได้ลงทุนพัฒนา WinUI controls ของตัวเอง ซึ่งก็คือสัญญาณว่าพวกเขาไม่เชื่อในอนาคตของ WinUI ในปัจจุบันสำหรับแอปองค์กร ตัวเลือกที่เป็นจริงในเชิงใช้งานได้มีแต่ WinForms และ WPF ผมยังไม่เคยเห็นแอปในงานจริงที่พัฒนาด้วย WinUI3

    • พูดตามตรง ใครจะจริงจังกับ UI framework ใดๆ ของ Microsoft ต่อไป กรอบงานที่เคยใช้มาก็ถูกทิ้งไว้แบบไม่สมบูรณ์อยู่ตลอดเวลา และเร็งกว่ายังพึ่งพาฟีเจอร์ใหม่ๆ ที่ดูเงาวูบ จนท้ายที่สุดก็ถูกลืมหมดไป ตรงกันข้าม โอเพ่นซอร์สครอสแพลตฟอร์มกลับมีพื้นฐานและความสามารถครบกว่า รวมถึงการบำรุงรักษาที่ดีกว่า WinUI ต่อจากนี้จึงก็คงเป็นอีกชะตากรรมของ UWP ที่ถูกเพิกเฉย

  • ตอนนี้นับจำนวน UI framework ของ Windows ก็สับสนมาก รู้สึกว่าเกินไปมากที่จะต้องคาดหวังอะไรจากการเปิดซอร์ส มันสร้างภาพว่าทุกอย่างเปิดเผย? หรือให้ประโยชน์จริงๆ แก่นักพัฒนาเป้าหมาย Windows กันแน่

    • WinUI พัฒนามาจาก UWP และ UWP เองคือวิวัฒนาการของ WinRT เห็นจุดประสงค์ของ WinUI ได้ค่อนข้างชัดเจน และเป็นเทคโนโลยีที่พัฒนามายาวนาน (ตอนนี้คือ WinUI 3) ส่วน MAUI เป็นทางเลือกข้ามแพลตฟอร์มมากกว่าเป็นคู่แข่งจริงๆ แต่หากจะสร้างความเชื่อมั่นระยะยาวได้ก็ต้องทำ UI ของทั้ง OS โดยเฉพาะเครื่องมือจัดการใหม่ด้วย WinUI ให้ได้ก่อน

    • ตอนแรกเมื่อเห็นตัวย่อและคำอธิบายยาวๆ ข้างต้น ฉันนึกว่าเป็นการเสียดสี WinUI, UWP, WinRT, XAML, Avalon, WPF, Project Reunion, Win2D, MFC, wxWidgets, Qt ฯลฯ มีชื่อเวอร์ชันและ framework ปนกันมากจนการอ่านอธิบายก็เหนื่อยและสับสน

    • อาจเป็นอีกครั้งที่ Microsoft ทุ่มเทกับเทรนด์ใหม่ๆ (ตอนนี้คือ AI!) อย่างเดิม และอาจกำลังหาหนทางจัดการเทคโนโลยีเดิมให้จบไปอย่างสงบโดยไม่เกิดเสียงค้านหนัก คาดว่าใครที่คัดค้านจริงๆ มีไม่มาก

    • สิ่งที่เป็นจริงคือ Windows มี UI framework อยู่ไม่กี่ตัว และเหลือเพียงสองตัวที่ยังมีอยู่จริงจัง อีกสองตัวเป็นการพัฒนาซ้ำซ้อนของสาย Win32/Native และ WPF/Managed WinUI3 ก็มาจึงเพื่อเชื่อมช่องว่างระหว่างสองสายนี้

    • ในระยะยาว MFC ยังอาจเป็นตัวเลือกที่ยืนยาวที่สุด แม้ตอนนี้การอัปเดตหยุดไปแล้ว แต่เชื่อว่าจะอยู่ได้นานได้อีก 20 ปี

  • อยากให้ Microsoft พัฒนาต่อยอด WPF ต่อไปนานๆ ใช้กับโปรเจกต์หลากหลายเป็นเวลานานแล้ว แม้มีช่วงเวลากระโดดเชี่ยวชาญ (learning curve) อยู่บ้าง แต่ Data Binding, ViewModel, XAML ยังใช้งานได้ดี อย่างไรก็ดี WPF ต้องการการปรับปรุงหลายจุดเพื่อให้ครบเครื่อง ผมลอง framework ใหม่จาก Microsoft และโอเพ่นซอร์ส (เช่น Avalonia, Uno) มาแล้ว แต่ตัวอย่างบางส่วนรันไม่ผ่าน หรือแนวทางการพัฒนาก็ไม่เข้ากับเรา สุดท้ายจึงกลับไปใช้ WPF ตัวเดิมเสมอ ไอเดียปรับปรุง WPF ที่สำคัญที่สุดคือการทำระบบ Data Binding แบบใช้โค้ดสร้างตอนคอมไพล์ใน .NET แทนการใช้ Reflection ระดับรันไทม์ หากทำแบบนี้ จะทำให้ AOT build เป็นจริงได้ เพิ่มประสิทธิภาพแบบก้าวกระโดด และยังได้ข้อดีอย่างความปลอดภัยเชิงชนิดของ XAML และการรองรับข้ามแพลตฟอร์มมากขึ้น เคยตั้งใจจะทำเป็นโอเพ่นซอร์สเอง แต่ไม่มีเวลาและงานเยอะเกินไป

    • ย่อหน้าที่สองที่พูดไปตรงกับ Avalonia ได้เป๊ะ Avalonia รองรับ AOT, ข้อผิดพลาดจากการ bound แบบ compile-time และความสามารถข้ามแพลตฟอร์มอยู่แล้ว ถ้าคุณยังไม่เห็นการอัปเดตมาแล้วสักพัก ให้เช็ก Avalonia compile-time data binding docs และ XamlX project

    • วิธีนี้ยังทำให้ทำ assembly trimming ได้ด้วย ถ้าต้องการ deployment แบบ standalone ตอนนี้ .NET library ยังติดมากว่า 200MB แต่แนวทางนี้ลดได้มาก

  • ตอนเคยประเมิน WinUI3 มาก่อน ประสบการณ์นักพัฒนาก็ไม่ได้ดีเลย ถ้าต้องการดีบั๊กแอปที่กำลังแจกจ่าย ต้องติดตั้งมันจริงๆ ในระบบ ทำให้มีรายการซ้ำซ้อนใน Start menu เยอะ และเรจิสทรีรก็รกขึ้นไปอีก ยังมีตัวอย่างที่เมื่อคลิกปุ่มในตัวอย่าง โค้ดแอปค้าง/ปิดลงทันที ผมยังทำแอป Windows โดยใช้ Win32+WTL อยู่เสมอ

    • การต้องติดตั้งแอปจริงเพื่อดีบั๊กเกิดจากการเลือกแบบ "แพ็กเกจ" นี่เอง เพราะมันต้องจัดการกับฟีเจอร์และสิทธิ์ ใน macOS ก็เช่นกัน หากเป็นแอปแบบแพ็กเกจจะต้องติดตั้ง แต่ถึงไม่แสดงใน Launchpad ก็ยังค้นหาได้ด้วย Spotlight

  • อย่างที่หลายคนชี้แล้ว UI framework ของ Windows ยืดเยื้อโดยไม่มีการจัดระเบียบที่ชัดเจน ทำให้ความสับสนยิ่งทวีคูณ เสียดายที่โลกโอเพ่นซอร์สข้ามแพลตฟอร์มก็ไม่ต่างกัน GTK เคยพังเป็นช่วงเวลาหนึ่ง และแม้ Qt จะมีฟีเจอร์มาก แต่โครงสร้างลิขสิทธิ์แบบมืออาชีพชวนเบียดบังความเป็นไปได้มาก (หายไปตั้งแต่สมัย Nokia และการมาของ Elop ที่ MS, ต่อมาเปลี่ยนเจ้าของ Qt ทำให้สถานการณ์ยิ่งเปลี่ยน) ในบางโดเมนมีทางออกที่ดีเช่น Dear Imgui โดยรวมแล้วทางเลือกสำหรับ Native/Cross-platform UI widget framework ที่ให้ permissive license, native compile, โครงสร้าง widget ที่ดี และรองรับการเรนเดอร์ Vulkan 3D ได้อย่างครบถ้วนยังแทบไม่มี

    • สาเหตุที่ Electron หรือ React Native ถูกวิจารณ์มักเพราะเรื่อง "เว็บไม่ดีพอ" แต่หากต้องการความยืดหยุ่นของแพลตฟอร์ม ความเป็นจริงคือทางเลือกแทนแทบไม่มีเลย Microsoft เคยมีโอกาสทำผลิตภัณฑ์ที่มีความหมายจริงๆ ในพื้นที่นี้ แต่ความพยายามกลับไม่ร้อนแรงพอ จึงไม่ค่อยได้เห็นผลลัพธ์ที่ดี

  • ถ้าอยู่ใน Windows 11 อยากให้มีแถบงานแนวตั้งเนทีฟกลับมาอีกครั้ง ฟีเจอร์นี้มีมาตั้งแต่ Windows 98 แต่กลับหายไปใน Windows 11 ยังมีเครื่องมือของบุคคลที่สามเช่น Windhawk (บังคับแถบงานแนวนอน) หรือ StartAllBack (คืนโค้ด Windows 10) อยู่ แต่ยังไม่สมบูรณ์

    • การเปิดโอเพ่นซอร์ส UI framework ไม่ได้หมายความว่าจะขยายความสามารถของแถบงาน ในพื้นที่แบบนี้ ความช่วยเหลือจากภายนอกสามารถเกิดได้ก็ต่อเมื่อตัวแถบงานตัวเอง (หรือกล่าวคือ explorer.exe) เปิดซอร์ส

    • ข้อสังเกต: ตัวเลือกแถบงานแนวตั้งมีมาตั้งแต่ Windows 95

    • โหมดการทำงานของแถบงานเป็นฟังก์ชันของ explorer.exe ประกาศการเปิดซอร์สที่พูดถึงตอนนี้ไม่เกี่ยวกับ explorer

    • ยังสงสัยว่าทีม Windows จริงๆ กำลังทำ Native desktop UI ด้วย WinUI อยู่หรือเปล่า

  • งาน UI สําหรับ Windows ช่วงนี้ทำผ่าน Win32, GDI และ DirectDraw เป็นหลัก ด้วย CsWin32 และ C# เวอร์ชันล่าสุด (ref returns) ความเข้าถึงดีขึ้นมาก สมัยก่อนมักต้องตั้งโปรเจกต์ C++ แยกเอง แต่ตอนนี้แค่เขียนฟังก์ชันที่ต้องการลงใน NativeMethods.txt ก็ให้ codegen จัดการแทน Win32 แน่นอนว่าลึกกว่า UI framework อื่นๆ เสมอ แต่ในอีกด้านกลับแก้หรือยกเลิกยากสำหรับ Microsoft มองระยะยาวแล้วไม่มี API ใดคงอยู่ได้มั่นคงเท่าพวกนี้ มุมมองระยะยาวเรื่องแพลตฟอร์มเว็บยังไม่พอเปรียบเทียบได้

    • แม้มีอีกหลายส่วนที่ยังคงต้องใช้ C++ อยู่ เพราะ Microsoft ยอมรับแนวทาง COM อย่างมั่นคง Windows Runtime Components เคยเป็นโอกาสเพิ่มระดับ .NET ecosystem แต่กลับพลาดไป ฟีเจอร์อย่าง shell extension หรือ context menu extension ต้องใช้ C++ และถ้าจะทำใน .NET สุดท้ายต้องวาง C++ stub แล้วเรียกเข้า .NET process

    • การคุยเรื่อง framework ระดับสูงดูน้อยกว่าการคุย API ระดับต่ำ stack การเรนเดอร์ทั้งหมดของ Windows ตั้งอยู่บน GDI/DirectX แล้ว Win32 เองก็ยังอยู่บน GDI ถ้าจะสนทนาเชิงลึกเกี่ยวกับ UI stack ของ Windows ที่ใกล้ระดับ hardware ควรเริ่มที่ DirectX มากกว่า

    • สำหรับผู้ใช้ปกติ Win32 ก็ยังค่อนข้าง high-level อยู่ดี จนถึงตอนนี้ toolkit ที่วาดปุ่มและแถบเลื่อนได้ถูกต้องมีแต่ Win32

    • อยากให้มี framework ที่ดีจริงๆ สำหรับการพัฒนา Windows native ได้จากชุมชน แต่ความจริงคือยังไม่มีขนาดชุมชนที่เพียงพอที่จะทำแบบนั้นได้

  • สิ่งที่คิดถึงมากที่สุดในการพัฒนา UI เดิมๆ ของ Windows คือ การได้รับความช่วยเหลือให้สร้างแอปที่เข้ากันได้อย่างเป็นธรรมชาติราวกับเป็นงานที่ทีม Microsoft ทำเอง หลังจากนำเทคโนโลยีเว็บเข้ามา ประสบการณ์ UI ของ Windows ถูกสั่นคลอนเรื่องความสอดคล้องอย่างมาก ปัญหาไม่ใช่แค่ Microsoft ไม่อัปเดตแอปเก่า แต่ framework ใหม่ก็มักไม่มอบไลบรารีที่ตรงตาม style guide เริ่มเห็นอาการนี้มาตั้งแต่ Vista และใน MSDN แหล่งตัวอย่างที่เคยบอกว่า "ใช้ฟีเจอร์นี้แบบนี้" ก็ลดลงเรื่อยๆ