Microsoft ไม่มีแนวทาง GUI ที่สอดคล้องกันอีกเลยนับตั้งแต่ยุคของ Petzold

 (jsnover.com)
8 คะแนน โดย GN⁺ 23 일 전 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • จนถึงช่วงปลายทศวรรษ 1980 การพัฒนาแอป Windows ยังชัดเจนด้วยโมเดลเดียวที่ยึด Win16/Win32 API เป็นศูนย์กลาง แต่หลังจากนั้นหลายทศวรรษก็เกิด การเปลี่ยนแพลตฟอร์มแบบไร้ความสอดคล้อง ซ้ำแล้วซ้ำเล่า
  • การล่มสลายของกลยุทธ์ Windows GUI ไม่ได้เกิดจากความล้มเหลวของเทคโนโลยีใดเทคโนโลยีหนึ่ง แต่มีต้นตอจากปัจจัยเชิงองค์กร 3 อย่าง ได้แก่ การเมืองระหว่างทีม วัฒนธรรมการประกาศที่ขับเคลื่อนด้วยคอนเฟอเรนซ์นักพัฒนา และการเปลี่ยนทิศทางโดยไม่แจ้งล่วงหน้า
  • ในปี 1988 หนังสือ Programming Windows ของ Charles Petzold ให้คำตอบที่ชัดเจนว่า "จะสร้างแอป Windows อย่างไร" ด้วย API เดียวและ mental model เดียวคือ Win32 แต่ตลอด 30 ปีหลังจากนั้น Microsoft ก็ไม่เคยกู้คืนความชัดเจนแบบนั้นได้อีก
  • ตั้งแต่ MFC, OLE, COM, ActiveX, WPF, Silverlight, WinRT, UWP, WinUI 3 ไปจนถึง MAUI เกิด ความกระจัดกระจายของเฟรมเวิร์ก GUI ตลอดหลายทศวรรษ และทุกครั้งที่โครงการใดล้มเหลว สาเหตุหลักมักเป็นความล้มเหลวในการตัดสินใจภายในองค์กรมากกว่าข้อบกพร่องทางเทคนิค
  • ปัจจุบัน Windows มี เทคโนโลยี GUI ที่ใช้งานจริงมากกว่า 17 แบบ และในบรรดานั้น เทคโนโลยีเดสก์ท็อป GUI ที่ถูกนำไปใช้อย่างแพร่หลายที่สุดคือ Electron ซึ่งไม่ได้ถูกสร้างโดย Microsoft
  • "ถ้าแพลตฟอร์มตอบคำถามว่า 'ควรสร้าง UI อย่างไร' ไม่ได้ภายใน 10 วินาที แปลว่าแพลตฟอร์มนั้นทำให้นักพัฒนาล้มเหลว" คือข้อวินิจฉัยสำคัญที่ยังใช้กับ Microsoft ได้ตรงตัวแม้ในปี 2026

Microsoft หลังการหายไปของแนวทาง GUI ที่สอดคล้องกัน

  • ตลอดเวลากว่า 30 ปี ความสับสนของกลยุทธ์ Windows GUI ดำเนินต่อเนื่อง และไม่มีคำตอบที่ชัดเจนสำหรับคำถามว่า “ถ้าจะสร้างแอปเดสก์ท็อป Windows ใหม่ ควรใช้เฟรมเวิร์กอะไร”
  • ในปี 1988 ยังมีโมเดลเดียวคือ Win16/Win32 API ทำให้นักพัฒนาสามารถเขียนแอปด้วยแนวทางเดียวกันได้
  • แต่ตลอดหลายทศวรรษหลังจากนั้น Microsoft ไม่สามารถรักษาแพลตฟอร์มที่สอดคล้องกันไว้ได้ เพราะ การเมืองภายใน การตัดสินใจที่ยึดการสาธิตเป็นหลัก และการเปลี่ยนกลยุทธ์ธุรกิจ
  • ผลลัพธ์คือมี เทคโนโลยี GUI 17 แบบ ตั้งแต่ Win32 ถึง MAUI อยู่ร่วมกัน และนักพัฒนาต้องเผชิญความสับสนบน แพลตฟอร์มที่ไร้กลยุทธ์
  • ต้นเหตุไม่ใช่ความล้มเหลวทางเทคนิค แต่เป็น ความล้มเหลวเชิงองค์กร

ยุคของ Petzold: ช่วงสุดท้ายที่ทุกอย่างยังชัดเจน

  • ในปี 1988 หนังสือ Programming Windows ของ Charles Petzold (852 หน้า) คือคำตอบเชิงอำนาจเพียงหนึ่งเดียวสำหรับการใช้ Win16 API ด้วยภาษา C และนั่นเองคือ กลยุทธ์ของการพัฒนา Windows
  • แม้ Win32 จะมีขนาดใหญ่ขึ้น แต่ก็ยังรักษา mental model เดียว เอาไว้ ทั้ง message loop, window procedure และ GDI ซึ่ง Petzold อธิบายไว้อย่างชัดเจน และนักพัฒนาก็สามารถเรียนรู้แล้วนำไปใช้ได้ทันที
  • “OS เดียว, API เดียว, ภาษาเดียว, หนังสือเล่มเดียว” — ความชัดเจนนี้คือสัญญาณของความน่าเชื่อถือของแพลตฟอร์ม

กระแส Object-Oriented (1992–2000): จุดเริ่มของความซับซ้อน

  • ปี 1992 MFC เข้ามาห่อ Win32 ด้วย C++ แต่หลังจากนั้น OLE, COM และ ActiveX ก็ปรากฏขึ้น ทำให้สถาปัตยกรรมคอมโพเนนต์เหล่านี้เข้ามาครอบงำการพัฒนา Windows โดยรวม แทนที่จะเป็นเพียงเฟรมเวิร์ก GUI
  • Microsoft ไม่ได้เล่าเรื่องที่สอดคล้องกัน แต่เลือก ให้ primitive ทางเทคโนโลยี แล้วปล่อยให้นักพัฒนาไปประกอบกันเอง ซึ่งเป็นผลจากวัฒนธรรมการประกาศที่ยึดคีย์โน้ตในคอนเฟอเรนซ์เป็นหลัก และให้ความสำคัญกับการสร้างความประทับใจแก่ผู้บริหารมากกว่าความสำเร็จของนักพัฒนา

PDC 2003 Longhorn: วิสัยทัศน์ที่กลืนกินตัวเอง

  • Longhorn ที่เปิดตัวในงาน PDC ปี 2003 เป็นวิสัยทัศน์ที่ชวนเชื่ออย่างมาก โดยมี 3 เสาหลักคือ WinFS (ระบบไฟล์เชิงสัมพันธ์), Indigo (การสื่อสารแบบรวมศูนย์), Avalon (UI แบบ XAML เร่งด้วย GPU)
  • เดือนมกราคม 2004 Jim Allchin เขียนบันทึกภายในเรียกมันว่า “หมูตัวหนึ่ง (a pig)” และในเดือนสิงหาคมปีเดียวกันก็ประกาศรีเซ็ตการพัฒนาใหม่ทั้งหมด — ย้อนกลับไปใช้โค้ดเบสของ Server 2003
  • หลังการรีเซ็ต ผู้นำออกแนวทางว่า “ห้ามใช้ managed code ภายใน Windows, โค้ดใหม่ทั้งหมดต้องเป็น C++” และแม้ WPF จะออกมาพร้อม Vista แต่ shell เองกลับไม่ได้ใช้ WPF
  • การตัดสินใจนี้จุดชนวน สงครามภายในองค์กรยาวนาน 13 ปี ระหว่างทีม Windows กับทีม .NET และท้ายที่สุดก็นำไปสู่การถูกทอดทิ้งของ WPF, การยกเลิก Silverlight และความล้มเหลวของ UWP

Silverlight: การสถาปนาแพตเทิร์นที่จะเกิดซ้ำ (2007–2010)

  • WPF เปิดตัวปลายปี 2006 แต่ในปี 2007 Silverlight ก็ปรากฏขึ้นในฐานะปลั๊กอินเบราว์เซอร์เพื่อต่อกรกับ Flash ทำให้การลงทุนด้านการพัฒนาถูกแบ่งกระจายออกไป
  • ในงาน MIX 2010 ผู้บริหาร Microsoft กล่าวกลางช่วง Q&A ว่า “Silverlight ไม่ใช่กลยุทธ์ข้ามแพลตฟอร์ม แต่เป็นกลยุทธ์ของ Windows Phone” — ทีม Silverlight ไม่ได้รับการแจ้งล่วงหน้า และนักพัฒนาที่ลงทุนสร้างแอป LOB บน Silverlight ก็เพิ่งมารู้จากช่วง Q&A ในคอนเฟอเรนซ์เช่นกัน
  • จุดจบของ Silverlight ไม่ได้มาจากความล้มเหลวทางเทคนิค แต่เป็นผลของ การเปลี่ยนกลยุทธ์ธุรกิจ และรูปแบบที่นักพัฒนาจะเป็นฝ่ายได้รับแจ้งเป็นคนสุดท้ายก็ถูกตอกย้ำตั้งแต่นั้น

Metro และสงครามของสองทีม (2012)

  • เพื่อตอบโต้การที่ Apple ขาย iPhone ได้ 200 ล้านเครื่อง และ iPad เข้ามาแย่งบทบาทของพีซี Microsoft จึงออก Windows 8 และ Metro แต่ WinRT ถูกออกแบบให้เป็นรันไทม์ native C++ โดยตั้งใจ ไม่ใช่บน .NET — เป็นผลโดยตรงจากท่าทีต่อต้าน .NET ของทีม Windows
  • ในงาน //Build 2012 นักพัฒนาได้รับ สารที่ขัดแย้งกันพร้อมกัน ว่า “อนาคตคือ WinRT, HTML+JS เป็นพลเมืองชั้นหนึ่ง, .NET ก็ยังใช้ได้, C++ ก็กลับมาแล้ว, เขียนแอป Metro ได้, และโค้ด WPF ก็ยังรันต่อได้”
  • นักพัฒนาองค์กรเห็น sandbox ของ UWP, ข้อกำหนดการแจกจ่ายผ่าน Store และ Win32 API ที่หายไป ก็ถอนตัวทันที — “แอปสโตร์สำหรับแท็บเล็ตไม่เคยเกิดขึ้นจริง”

ความสับสนของ UWP และ WinUI (2015–ปัจจุบัน)

  • UWP (Universal Windows Platform) ของ Windows 10 ถูกวางวิสัยทัศน์เป็น “เขียนครั้งเดียว รันได้ทุกที่” ครอบคลุมทั้งพีซี โทรศัพท์ Xbox และ HoloLens แต่เมื่อ Windows Phone ถดถอย และแม้แต่แอปเรือธงของ Microsoft เองอย่าง Office, Visual Studio และ shell ก็ไม่ได้ใช้ UWP สัญญาณก็ชัดเจนแล้ว
  • คำตอบอย่างเป็นทางการเสื่อมสภาพเหลือเพียง “แล้วแต่กรณี (it depends)” — ทั้ง UWP, การคง WPF, XAML Islands, การรอ WinUI 3, การอยู่ร่วมของ WinUI 2, การเปิดตัว Project Reunion และการเปลี่ยนชื่อเป็น Windows App SDK ยิ่งเพิ่มความสับสน
  • Project Reunion / WinUI 3 แม้จะเป็นความก้าวหน้าทางเทคนิค แต่การมีอยู่ของมันเองก็เป็นผลผลิตจากปัญหาเชิงองค์กรที่ UWP controls ถูกผูกกับ OS และทีม .NET กับทีมเครื่องมือนักพัฒนาไม่สามารถเป็นเจ้าของมันได้
  • คำรำลึกของนักพัฒนาคนหนึ่งในปี 2024: “UAP, UWP, การแทนที่ C++/CX ด้วย C++/WinRT โดยไม่มีการรองรับจากเครื่องมือ, XAML Islands, XAML Direct, การเริ่ม Project Reunion, การรีสตาร์ต WinAppSDK, การเปลี่ยนผ่านอันสับสนระหว่าง WinUI 2.0 กับ 3.0… 14 ปี, 14 ครั้งของการหักพวงมาลัย”

สวนสัตว์ไร้คนดูแล: รายชื่อเทคโนโลยี GUI ของ Windows ในปัจจุบัน

เฟรมเวิร์ก native ของ Microsoft:

  • Win32 (1985) — ยังถูกใช้งานอยู่ หนังสือของ Petzold ก็ยังใช้ได้
  • MFC (1992) — อยู่ในโหมดบำรุงรักษา ยังหลงเหลือในสาย enterprise และ CAD
  • WinForms (2002) — “ยังใช้ได้แต่ไม่แนะนำ” แต่สำหรับฟอร์มกรอกข้อมูลยังเร็วที่สุด
  • WPF (2006) — XAML, เรนเดอร์ด้วย DirectX, โอเพนซอร์ส, Microsoft ไม่ได้ลงทุนใหม่แล้ว
  • WinUI 3 / Windows App SDK (2021) — คำตอบ “สมัยใหม่” อย่างเป็นทางการ แต่โรดแมปยังไม่ชัด
  • MAUI (2022) — ผู้สืบทอดข้ามแพลตฟอร์มของ Xamarin.Forms คือเดิมพันปัจจุบันของทีม .NET

เว็บไฮบริดของ Microsoft:

  • Blazor Hybrid — .NET Razor components ภายใน WebView แบบ native
  • WebView2 — ฝัง Chromium ในแอป Win32/WinForms/WPF

บุคคลที่สาม:

  • Electron — Chromium + Node.js, ถูกใช้โดย VS Code, Slack, Discord และ ปัจจุบันเป็นเทคโนโลยีเดสก์ท็อป GUI ที่ถูกนำไปใช้แพร่หลายที่สุดบน Windows แต่ไม่เกี่ยวข้องกับ Microsoft
  • Flutter (Google), Tauri (บน Rust), Qt (C++/Python/JS), React Native for Windows (Microsoft สนับสนุน แต่พื้นฐานเป็นเทคโนโลยีของ Facebook)
  • Avalonia — ผู้สืบทอดทางจิตวิญญาณแบบโอเพนซอร์สของ WPF ถูกนำไปใช้โดยนักพัฒนาจาก JetBrains, GitHub, Unity และคนอื่น ๆ ที่ไม่รอ Microsoft
  • Uno Platform — ทุ่มเทให้ WinUI มากกว่า Microsoft เองเสียอีก
  • Delphi/RAD Studio, Java Swing/JavaFX — ยังอยู่รอดในตลาดเฉพาะทางและสาย enterprise

→ 17 แนวทาง, 5 ภาษาโปรแกรม, 3 ปรัชญาการเรนเดอร์ — นี่ไม่ใช่ “แพลตฟอร์ม”

ข้อวินิจฉัยหลัก

  • ทุกโครงการ GUI ที่ล้มเหลวล้วนย้อนกลับไปสู่หนึ่งในสามสาเหตุ: การเมืองระหว่างทีม (Windows vs. .NET), การเดิมพันแพลตฟอร์มล่วงหน้าที่ขับเคลื่อนด้วยการประกาศในคอนเฟอเรนซ์ (Metro, UWP), และ การเปลี่ยนกลยุทธ์ธุรกิจโดยไม่แจ้งนักพัฒนาล่วงหน้า (Silverlight)
  • ตัวเทคโนโลยีเองมักยอดเยี่ยม — WPF ดี, Silverlight ดี, XAML ดี — แต่ความล้มเหลวเชิงองค์กรก็คือความล้มเหลวของผลิตภัณฑ์
  • หากไม่มีกลไก Plausible Theory of Success ที่ครอบคลุมวงจรชีวิตทั้งหมดตั้งแต่ “การยอมรับ-การลงทุน-การบำรุงรักษา-การย้ายระบบ” ก็ไม่ใช่กลยุทธ์ แต่เป็นเพียงคีย์โน้ตในคอนเฟอเรนซ์
  • Charles Petzold เคยแก้ไข Programming Windows ไปจนถึงฉบับที่ 6 เพื่อไล่ตามสิ่งใหม่ ๆ ที่ Microsoft ประกาศออกมา แต่ หลังจากฉบับที่ 6 ซึ่งครอบคลุม WinRT (Windows 8) เขาก็หยุดเขียนต่อ

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

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

 
iolothebard 22 일 전

สุดท้ายก็ลงเอยที่ Win32?!!
 
GN⁺ 23 일 전
ความเห็นบน Hacker News

  • ปัญหาพื้นฐานคือ Microsoft พยายามแก้ความสม่ำเสมอของ GUI แค่ในระดับ framework layer เท่านั้น
    ออกเฟรมเวิร์กใหม่มาเรื่อย ๆ อย่าง WinForms, WPF, UWP, WinUI แล้วสุดท้ายก็ทิ้ง
    ฝั่ง Apple มองว่า design system เองคือตัวผลิตภัณฑ์ และทำให้เฟรมเวิร์กอยู่เบื้องหลังแบบมองไม่เห็น ขณะที่ Microsoft กลับเดินคนละทางทุกครั้ง

    • ในฐานะคนเกิดยุค 70 ที่ใช้คอมมาตั้งแต่ยุค 80 อ่านแล้วแทบสำลักกาแฟ
      อยากฟังตัวอย่างจากฝั่ง Apple ไหม?
    • มันเป็นไปไม่ได้ที่จะยัด Metro design, ทัชสกรีน และ dark mode ให้แอป Win32 อายุ 40 ปีได้พร้อมกัน
      ทุกวันนี้ WPF ก็พยายามเลียนแบบสกินแบบ WinUI อยู่ อย่างน้อย Microsoft ก็ยังพยายาม
    • เห็นด้วยนะ แต่ WinForms ยังได้รับการซัพพอร์ตอยู่
      แม้แต่ในสแตก .NET รุ่นล่าสุด มันก็ยังเป็นหนึ่งในเส้นทางทางการอยู่ดี
    • คำว่า “Apple แก้ปัญหานี้ได้แล้ว” ฟังดูเหมือนคอมเมนต์ที่เขียน ก่อน Tahoe
    • เป็นคอมเมนต์ที่มีมุมมองลึกดี

  • WinForms ยังมีเสน่ห์อยู่มาก
    ด้วย WebView2 การทำแอปแบบไฮบริดง่ายขึ้น จะไปทางเว็บล้วนก็ได้ แต่ความรู้สึกของ native chrome ยังดีกว่า
    ลูกค้าทุกคนใช้ Windows อยู่แล้ว เลยไม่จำเป็นต้องฝืน
    ช่วงนี้กำลังทำ AI assistant ด้วยชุด .NET10 + WinForms + WebView2
    แค่คิดว่าจะต้องปรับ UI ประวัติการสนทนาด้วย WinForms ล้วนซ้ำไปซ้ำมาก็ไม่อยากนึกภาพแล้ว

  • ไม่เห็นด้วยกับคำพูดที่ว่า “WPF เคยดี”
    บนฮาร์ดแวร์ทั่วไปช่วงปลายยุค 2000 แอป WPF ช้ามาก
    เช่น Logos Bible Software เป็นแอปข้อความธรรมดาแท้ ๆ แต่กลับต้องการ สมรรถนะกราฟิก จนเครื่องโน้ตบุ๊กเก่ากระตุก
    มารู้ทีหลังว่า Logos 4 สร้างบน WPF และในโพสต์ฟอรัมก็มีคนบ่นเรื่องเดียวกันเยอะ

    • ราวปี 2010~2011 เคยทำแอป WPF ที่ซับซ้อนอยู่ตัวหนึ่ง ซึ่งประสิทธิภาพแย่กว่า HTML/JS/Blink มาก
      สุดท้ายเลยต้องเขียนโค้ดส่วนใหญ่ใหม่ด้วย Direct3D/Direct2D
      ปัญหาอยู่ที่ สถาปัตยกรรมของ WPF เอง
    • ราวปี 2010 ก็มีกรณีที่ Evernote เลิกใช้ WPF
      เหตุผลคือข้อความเบลอและปัญหาด้านประสิทธิภาพ
      บทความที่เกี่ยวข้อง: edandersen.com / Reddit
    • ปัญหาใหญ่ไม่ใช่ WPF แต่เป็นเพราะ Microsoft ดันยอมรับฮาร์ดแวร์ Intel ประสิทธิภาพต่ำ ว่า “เพียงพอ” มากกว่า
      บทความที่เกี่ยวข้อง: Ars Technica
    • มันคล้ายกรณีอย่าง Tahoe/iOS 26 ของ Apple ที่ใส่เอฟเฟกต์เยอะเกินไปจนออกมาเกินพอดี
    • เมื่อก่อนคนบอกว่า WinForms ช้า แต่ตอนนี้ Electron มาแทนตำแหน่งนั้นแล้ว
      สุดท้ายแล้ว ข้อถกเถียงเรื่องประสิทธิภาพก็วนซ้ำตามยุคสมัย
      Apple เองก็เจอปัญหาคล้ายกันตอนย้ายจาก AppKit/UIKit ไป SwiftUI

  • ตอนที่ ChatGPT ระเบิดความนิยมใหม่ ๆ การที่ Bing รวมเวอร์ชันที่เข้าถึงเว็บได้เข้าไปถือเป็น ไอเดียระดับอัจฉริยะ
    แต่ Microsoft ไม่ได้ทำรายละเอียดอย่าง การบีบอัดคอนเท็กซ์ เลยทำให้บทสนทนาถูกตัดอย่างรวดเร็ว
    ขณะที่ OpenAI, Perplexity และรายอื่นทำเรื่องนี้ได้ดีจนกลายเป็นมาตรฐานในตอนนี้
    ถ้า Microsoft ทำได้ดีตั้งแต่ตอนนั้น อาจแทนที่ Google ได้เลยก็ได้
    สุดท้ายปัญหาคือ ความเนี้ยบของ UI/UX ที่ไม่พอ และผมคิดว่านั่นมาจาก การขาดความสม่ำเสมอในวัฒนธรรมองค์กร
    แม้จะน่าหงุดหงิดที่ Apple ไม่ยอมให้ bundle UI library แต่ข้อเท็จจริงก็คือมันช่วยรักษา ความสม่ำเสมอของ UI เอาไว้

    • ถึง Apple จะกัน UI library ก็เถอะ ถ้าใช้ การเรนเดอร์แบบแคนวาสอย่าง Flutter หรือ KMP ก็ได้อยู่ดี
      ผู้ใช้ส่วนใหญ่ไม่ได้สนใจหรอก

  • มีผู้ใช้คนหนึ่งชอบคัดลอกเรื่องเล่าจากมื้อเย็นกับผู้บริหาร Microsoft มาวางซ้ำ ๆ โดยใจความคือ “Microsoft ทุ่มสุดตัวให้ enterprise”
    แต่ในความเป็นจริง แม้แต่ฝั่งองค์กรก็ยังหนีเพราะ คุณภาพของ Windows และ Azure แย่ลง
    บริษัทเราก็เสียหายจากปัญหา Azure SLA และไม่ได้รับการชดเชยอะไรเลย
    เลยกำลังลดการพึ่งพา Active Directory และ Windows ลง

    • ปัญหาคือ Microsoft มองแต่ลูกค้าองค์กรจน ลืมประสบการณ์ของผู้ใช้รายบุคคล
      สุดท้ายแล้วก็ไม่มีตลาดองค์กรที่อยู่ได้โดยไม่มีผู้ใช้นั่นแหละ

  • หลัง Win32 มา Microsoft ไม่เคย ดันไปในทิศทางเดียวกันเกิน 2 ปี เลย
    WinRT ถือว่าโอเค แต่พอ Nadella เข้ามาแล้วหันไปโฟกัส Azure ก็เหมือนทิ้งแพลตฟอร์ม Windows ไป

    • ตอนนี้ยังไม่แน่ใจเลยว่า Microsoft ยังเป็น บริษัทแพลตฟอร์ม อยู่ไหม
      พอเปลี่ยนจาก Windows → Office → Azure ตัวตนของบริษัทก็ค่อย ๆ เลือน
      Office ก็มีทั้งบนเว็บและเดสก์ท็อป แถมยังมีฮาร์ดแวร์กับสโตร์อีก
      วิสัยทัศน์ของ Satya Nadella ไม่ได้ถูกสื่อออกมาอย่างชัดเจน
    • WinRT ก็ไม่ได้ดีในเชิงเทคนิค และปัจจัยล้มเหลวที่ใหญ่กว่าคือ นโยบายบังคับใช้ Microsoft Store
      ตัวสโตร์เองก็แย่มาก และเป็นแค่โปรเจกต์ไว้ปั้นผลงานเพื่อเลื่อนขั้นภายในเท่านั้น

  • ปัญหาคือ Microsoft ปล่อย GUI framework ใหม่ออกมาเรื่อย ๆ แต่ถึงอย่างนั้น แอป Win32 ก็ยังเขียนได้อยู่
    Microsoft หันไปทางเว็บมานานแล้ว และก็มีส่วนช่วยผลักดันเทคโนโลยีอย่าง AJAX, Flexbox, Grid ด้วย
    ผมพัฒนาระบบข้ามแพลตฟอร์มบนเว็บ, Java, Python เป็นหลัก
    ไม่มีเหตุผลอะไรให้ต้องสร้าง GUI ที่ใช้ได้เฉพาะบน Windows
    เว็บแอปยืดหยุ่นกว่าและเข้าถึงได้ดีกว่า

    • สงสัยจริง ๆ ว่าทำไมต้องสร้างแอปเฉพาะ Windows
      เว็บรันได้ทุกที่ และยังปล่อยขึ้น app store ได้ผ่าน PWABuilder
      ผมมีส่วนร่วมในโปรเจกต์นี้ด้วย และมันทำให้สร้าง แอปที่เร็วและเบาโดยไม่ต้องพึ่ง Electron ได้
    • Windows เคยรองรับ แอป HTML มาจนถึงก่อน 24H2
      ดูจากเอกสาร Active Desktopแล้ว ตอนนั้นถือว่าทดลองพอตัว
    • แต่ UX ของเว็บแอปก็ยัง ด้อยกว่าแอปเนทีฟ อยู่ดี
      เว็บเป็นแค่ทางออกชั่วคราว ประสบการณ์ที่ดีจริง ๆ ยังต้องมาจากเนทีฟ

  • ราวปี 2007 เคยย้ายจาก Delphi ไป WPF แต่พอถึงปี 2010 ก็ ทิ้ง Windows ไปเลย
    การเมืองภายใน Microsoft และการทิ้งเทคโนโลยีบ่อยเกินไปมันหนักมาก
    ตอนนั้น Rails กำลังมาแรง เลยย้ายไม่ยาก

    • ถ้าวันนี้ยังต้องทำ Windows GUI อยู่ ผมก็จะ ยึด WPF ต่อไป
      อาจจะเป็น Stockholm syndrome ก็ได้ แต่ Visual Studio เองก็ยังอยู่บน WPF เลยไม่ได้กังวลมาก
    • Microsoft มีคนเก่งมากมาย แต่กลับพังเพราะ การขาดผู้นำและวิสัยทัศน์
      เหมือนเป็นตัวอย่างล่วงหน้าของปัญหาที่วันนี้เกิดกับบิ๊กเทคทั้งวงการ
    • อย่างน้อย VB ก็ยังรันได้ เลยยังไม่ถือว่าถูกทิ้งหมด

  • Steven Sinofsky เพิ่งโพสต์เรื่องทำนองเดียวกันเมื่อไม่นานนี้
    ลิงก์ x.com

    • ตลกดีที่ Sinofsky วิจารณ์ .NET
      ตอนยุค WinRT เขาอยู่ฝั่ง DevDiv แต่ทีม Windows ไม่เข้าใจความต้องการของนักพัฒนาเลย
      เคยมีต้นแบบ Python/WinRT ด้วย แต่ถูกทิ้งเพราะมีคนบอกว่า “นักพัฒนาต้องการแค่ JS”
      พวกเขายังบังคับ Metro style ถึงขั้นเปลี่ยนเมนูของ Visual Studio ให้เป็น ตัวพิมพ์ใหญ่ทั้งหมด
      Windows RT ก็ตัดความเข้ากันได้ทิ้งจนแทบไม่มีแอป สุดท้ายเลยล้มเหลว
      แถมข้ออ้างเชิงเทคนิคของ Sinofsky บางส่วนก็ผิดด้วย (.NET 3.0 ถูกรวมมากับ Vista อยู่แล้ว)
    • บทความนั้นเป็น โพสต์ตอบกลับ ต่อบทความนี้ และน่าจะมีการเพิ่มลิงก์ไว้ด้านบน
    • มีคนถามเหมือนกันว่ามีทางอ่านโดยไม่ผ่าน x.com ไหม
      ตอนนี้ xcancel.com ยังไม่รองรับฟีเจอร์นั้น

  • คำตอบนั้นชัดเจนอยู่แล้ว — Qt
    ไม่ได้พูดเล่นนะ ถ้าไม่ใช้ Electron, Qt คือทางเลือกจริง ๆ
    สำหรับ Qt นี่คือ ธุรกิจหลัก เขาเลยไม่เปลี่ยนทิศทางบ่อย