- Cho đến cuối những năm 1980, việc phát triển ứng dụng Windows còn rõ ràng với một mô hình duy nhất xoay quanh Win16/Win32 API, nhưng trong nhiều thập niên sau đó, các cuộc chuyển nền tảng thiếu nhất quán liên tục lặp lại
- Sự sụp đổ của chiến lược GUI Windows không bắt nguồn từ thất bại của một công nghệ cụ thể, mà từ ba nguyên nhân mang tính tổ chức: chính trị giữa các nhóm, văn hóa công bố lấy hội nghị nhà phát triển làm trung tâm, và các lần chuyển hướng chiến lược không báo trước
- Năm 1988, Programming Windows của Charles Petzold đã đưa ra câu trả lời rõ ràng cho câu hỏi “làm thế nào để xây dựng ứng dụng Windows” bằng một API duy nhất là Win32 và một mô hình tư duy duy nhất, nhưng trong 30 năm sau đó Microsoft không thể khôi phục lại sự rõ ràng này
- Từ MFC, OLE, COM, ActiveX, WPF, Silverlight, WinRT, UWP, WinUI 3 đến MAUI, tình trạng hỗn loạn của các framework GUI kéo dài suốt hàng thập niên; và với mỗi sáng kiến thất bại, nguyên nhân cốt lõi thường không phải lỗi kỹ thuật mà là thất bại trong ra quyết định nội bộ
- Hiện nay trên Windows có hơn 17 công nghệ GUI đang được sử dụng thực tế, và trong số đó, công nghệ GUI desktop được triển khai rộng rãi nhất là Electron, vốn không phải do Microsoft tạo ra
- Nhận định cốt lõi “nếu một nền tảng không thể trả lời câu hỏi 'phải xây UI như thế nào?' trong vòng 10 giây, thì nền tảng đó đã làm thất bại các nhà phát triển” vẫn còn nguyên giá trị với Microsoft ở thời điểm 2026
Microsoft sau khi đánh mất chiến lược GUI nhất quán
- Trong hơn 30 năm, sự hỗn loạn trong chiến lược GUI của Windows kéo dài, khiến câu hỏi “nên dùng framework nào để tạo một ứng dụng desktop Windows mới” không có câu trả lời rõ ràng
- Năm 1988, tồn tại một mô hình duy nhất là Win16/Win32 API, cho phép các nhà phát triển viết ứng dụng theo một cách thống nhất
- Trong nhiều thập niên sau đó, Microsoft không thể duy trì một nền tảng nhất quán do chính trị nội bộ, ra quyết định thiên về trình diễn, và các lần đổi hướng chiến lược kinh doanh
- Kết quả là từ Win32 đến MAUI, 17 công nghệ GUI cùng tồn tại, và các nhà phát triển phải xoay xở trong một nền tảng thiếu chiến lược
- Nguyên nhân gốc rễ không phải là thất bại kỹ thuật mà là thất bại tổ chức
Thời Petzold: giai đoạn rõ ràng cuối cùng
- Năm 1988, Programming Windows của Charles Petzold (852 trang) là câu trả lời có thẩm quyền duy nhất cho việc xử lý Win16 API bằng C, và đó chính là chiến lược phát triển Windows khi ấy
- Win32 sau đó mở rộng hơn, nhưng vẫn giữ một mô hình tư duy duy nhất gồm message loop, window procedure và GDI; Petzold giải thích được nó và các nhà phát triển có thể học rồi áp dụng ngay
- “Một OS, một API, một ngôn ngữ, một cuốn sách” — sự rõ ràng đó chính là tín hiệu cho thấy nền tảng đáng tin cậy
Cơn sốt hướng đối tượng (1992–2000): khởi đầu của sự phức tạp
- Năm 1992, MFC bọc Win32 bằng C++, nhưng rồi OLE, COM và ActiveX xuất hiện, khiến các kiến trúc thành phần chứ không phải framework GUI dần xâm lấn toàn bộ việc phát triển Windows
- Thay vì đưa ra một câu chuyện nhất quán, Microsoft chỉ cung cấp các primitive công nghệ và để nhà phát triển tự ghép nối; điều này xuất phát từ văn hóa công bố xoay quanh keynote hội nghị, nơi việc tạo ấn tượng với lãnh đạo được ưu tiên hơn thành công của nhà phát triển
PDC 2003 Longhorn: tầm nhìn tự nuốt chửng chính mình
- Longhorn được công bố tại PDC 2003 là một tầm nhìn thuyết phục với ba trụ cột: WinFS (hệ thống tệp quan hệ), Indigo (truyền thông hợp nhất), Avalon (UI dựa trên XAML tăng tốc bằng GPU)
- Tháng 1/2004, một bản ghi nhớ nội bộ của Jim Allchin gọi nó là “một con lợn” (a pig), và đến tháng 8 cùng năm tuyên bố reset phát triển hoàn toàn — quay lại codebase của Server 2003
- Sau đợt reset, lãnh đạo đưa ra chỉ thị “cấm managed code trong Windows, mọi mã mới đều phải là C++”; WPF vẫn được phát hành cùng Vista nhưng bản thân shell không dùng WPF
- Quyết định này châm ngòi cho 13 năm nội chiến tổ chức giữa nhóm Windows và nhóm .NET, cuối cùng dẫn tới việc WPF bị bỏ rơi, Silverlight bị khai tử và UWP thất bại
Silverlight: thiết lập khuôn mẫu lặp lại (2007–2010)
- WPF ra mắt cuối năm 2006, nhưng đến 2007 Silverlight xuất hiện như plugin trình duyệt để đối phó Flash, khiến đầu tư phát triển bị phân tán
- Tại hội nghị MIX 2010, một lãnh đạo Microsoft nói trong phần Q&A rằng “Silverlight không phải chiến lược đa nền tảng mà là chiến lược cho Windows Phone” — đội Silverlight không được báo trước, và các nhà phát triển đã đầu tư ứng dụng LOB vào Silverlight cũng chỉ biết điều này lần đầu qua phần hỏi đáp tại hội nghị
- Cái chết của Silverlight không phải do thất bại kỹ thuật mà là kết quả của một lần đổi hướng chiến lược kinh doanh, và chính tại đây mô hình “nhà phát triển luôn là người được báo sau cùng” được định hình
Metro và cuộc chiến giữa hai đội (2012)
- Để đáp trả việc Apple bán được 200 triệu iPhone và iPad lấn sân PC, Microsoft tung ra Windows 8 và Metro, nhưng WinRT được thiết kế có chủ ý như một runtime C++ native thay vì nền tảng dựa trên .NET — kết quả phản ánh trực tiếp ác cảm của nhóm Windows với .NET
- Tại //Build 2012, các nhà phát triển đồng thời nhận được những thông điệp mâu thuẫn: “tương lai là WinRT, HTML+JS là công dân hạng nhất, .NET vẫn chạy, C++ trở lại, có thể viết ứng dụng Metro, mã WPF vẫn tiếp tục chạy”
- Các nhà phát triển doanh nghiệp kiểm tra sandbox của UWP, yêu cầu phân phối qua Store và các Win32 API bị thiếu, rồi lập tức rời đi — “kho ứng dụng cho tablet cuối cùng đã không bao giờ thành hiện thực”
Sự hỗn loạn của UWP và WinUI (2015–nay)
- UWP (Universal Windows Platform) của Windows 10 mang tầm nhìn “viết một lần, chạy mọi nơi” trên PC, điện thoại, Xbox và HoloLens, nhưng khi Windows Phone suy tàn và ngay cả các ứng dụng chủ lực của Microsoft (Office, Visual Studio, shell) cũng không dùng UWP, tín hiệu đã rất rõ ràng
- Câu trả lời chính thức bị hạ xuống thành “it depends” — UWP, duy trì WPF, XAML Islands, chờ WinUI 3, WinUI 2 cùng tồn tại, phát hành Project Reunion rồi đổi tên thành Windows App SDK, khiến sự hỗn loạn càng nặng hơn
- Project Reunion / WinUI 3 là bước tiến kỹ thuật, nhưng bản thân sự tồn tại của nó cũng là sản phẩm của một vấn đề tổ chức: các control UWP bị gắn chặt với OS và nhóm .NET cùng nhóm công cụ phát triển không sở hữu được chúng
- Hồi tưởng của một nhà phát triển năm 2024: “UAP, UWP, việc thay C++/CX bằng C++/WinRT (mà không có hỗ trợ công cụ), XAML Islands, XAML Direct, Project Reunion, khởi động lại WinAppSDK, quá trình chuyển đổi hỗn loạn giữa WinUI 2.0 và 3.0… 14 năm, 14 lần pivot”
Một sở thú không người trông coi: danh sách công nghệ GUI trên Windows hiện nay
Framework native của Microsoft:
- Win32 (1985) — vẫn đang được dùng, sách của Petzold vẫn còn giá trị
- MFC (1992) — ở chế độ bảo trì, vẫn còn tồn tại trong doanh nghiệp và CAD
- WinForms (2002) — “dùng được nhưng không được khuyến nghị”, vẫn nhanh nhất cho các form nhập liệu
- WPF (2006) — XAML, render bằng DirectX, mã nguồn mở, Microsoft không còn đầu tư mới
- WinUI 3 / Windows App SDK (2021) — câu trả lời “hiện đại” chính thức, nhưng roadmap chưa rõ ràng
- MAUI (2022) — hậu duệ đa nền tảng của Xamarin.Forms, là canh bạc hiện tại của nhóm .NET
Hybrid web của Microsoft:
- Blazor Hybrid — các component .NET Razor trong WebView native
- WebView2 — nhúng Chromium vào ứng dụng Win32/WinForms/WPF
Bên thứ ba:
- Electron — Chromium + Node.js, được VS Code, Slack, Discord sử dụng, hiện là công nghệ GUI desktop được triển khai rộng rãi nhất trên Windows nhưng không liên quan đến Microsoft
- Flutter (Google), Tauri (dựa trên Rust), Qt (C++/Python/JS), React Native for Windows (được Microsoft hậu thuẫn nhưng dựa trên công nghệ của Facebook)
- Avalonia — người kế thừa tinh thần mã nguồn mở của WPF, được các nhà phát triển như JetBrains, GitHub, Unity chấp nhận thay vì chờ Microsoft
- Uno Platform — tận tâm với WinUI còn hơn cả Microsoft
- Delphi/RAD Studio, Java Swing/JavaFX — vẫn sống sót trong các thị trường ngách và môi trường doanh nghiệp
→ 17 cách tiếp cận, 5 ngôn ngữ lập trình, 3 triết lý render — không thể gọi đó là một “nền tảng”
Chẩn đoán cốt lõi
- Mọi sáng kiến GUI thất bại đều quy về một trong ba nguyên nhân: chính trị giữa các nhóm (Windows vs. .NET), đặt cược nền tảng quá sớm theo công bố hội nghị (Metro, UWP), đổi hướng chiến lược kinh doanh mà không báo trước cho nhà phát triển (Silverlight)
- Bản thân công nghệ thường rất tốt — WPF tốt, Silverlight tốt, XAML tốt — thất bại tổ chức chính là thất bại của sản phẩm
- Nếu không có một Plausible Theory of Success bao trùm toàn bộ vòng đời “adoption-investment-maintenance-migration”, thì đó không phải chiến lược mà chỉ là một bài keynote hội nghị
- Charles Petzold đã sửa Programming Windows tới bản thứ 6 để theo kịp những gì Microsoft liên tục công bố, nhưng sau bản thứ 6 viết về WinRT (Windows 8), ông đã ngừng viết
2 bình luận
Mở đầu kết thúc đều là Win32?!!
Ý kiến trên Hacker News
Vấn đề cốt lõi là Microsoft chỉ cố giải quyết tính nhất quán của GUI ở lớp framework
Họ liên tục đưa ra framework mới như WinForms, WPF, UWP, WinUI rồi cuối cùng lại bỏ
Trong khi Apple xem chính hệ thống thiết kế là sản phẩm, còn framework thì được làm cho vô hình, Microsoft lại luôn tiếp cận theo hướng ngược lại
Có thể kể thêm ví dụ bên Apple không?
Dạo này WPF đang bắt chước giao diện WinUI, nên dù sao Microsoft cũng đang cố gắng
Nó vẫn là một trong các con đường chính thức ngay cả trong stack .NET mới nhất
WinForms vẫn rất hấp dẫn
Nhờ WebView2 mà việc phát triển ứng dụng hybrid trở nên dễ dàng hơn, và dù có thể chuyển hẳn sang web, cảm giác mà chrome native mang lại vẫn tốt hơn
Tất cả khách hàng của tôi đều dùng Windows nên tôi không cần phải chống lại điều đó
Gần đây tôi đang làm một trợ lý AI với tổ hợp .NET10 + WinForms + WebView2
Tôi không muốn tưởng tượng việc cứ phải chỉnh đi chỉnh lại UI lịch sử hội thoại bằng WinForms thuần
Tôi không đồng ý với ý kiến “WPF từng tốt”
Trên phần cứng phổ thông cuối những năm 2000, ứng dụng WPF chạy chậm
Ví dụ như Logos Bible Software chỉ là một ứng dụng văn bản đơn giản mà vẫn đòi hỏi hiệu năng đồ họa, khiến laptop cũ bị giật lag
Về sau tôi mới biết Logos 4 dùng WPF, và bài trên diễn đàn cũng có rất nhiều phàn nàn tương tự
Cuối cùng chúng tôi phải viết lại phần lớn code bằng Direct3D/Direct2D
Kiến trúc WPF tự thân đã là vấn đề
Lý do được nói là vì chữ bị mờ và vấn đề hiệu năng
Bài liên quan: edandersen.com / Reddit
Bài liên quan: Ars Technica
Cuối cùng thì tranh cãi về hiệu năng luôn lặp lại theo từng thời kỳ
Apple cũng gặp vấn đề tương tự khi chuyển từ AppKit/UIKit sang SwiftUI
Khi ChatGPT mới bùng nổ, việc Bing tích hợp một phiên bản có thể truy cập web là một ý tưởng thiên tài
Nhưng Microsoft đã không làm tốt các chi tiết triển khai như nén ngữ cảnh, nên cuộc trò chuyện nhanh chóng bị chặn
Trong khi đó OpenAI, Perplexity và các bên khác làm việc này rất tốt, và giờ nó đã trở thành chuẩn chung
Nếu khi đó Microsoft làm cho ra hồn, họ thậm chí có thể thay thế Google
Cuối cùng vấn đề là độ hoàn thiện của UI/UX còn kém, và tôi cho rằng điều đó đến từ sự thiếu nhất quán trong văn hóa tổ chức
Việc Apple ngăn đóng gói thư viện UI từng khiến tôi thấy khó chịu, nhưng đúng là nhờ vậy mà tính nhất quán UI được giữ vững
Phần lớn người dùng không quan tâm
Có người cứ lặp đi lặp lại câu chuyện ăn tối với một giám đốc Microsoft, nội dung là “Microsoft đang all-in vào enterprise”
Nhưng thực tế là ngay cả doanh nghiệp cũng đang rời đi vì chất lượng Windows và Azure đi xuống
Công ty tôi cũng từng bị ảnh hưởng bởi vấn đề SLA của Azure và không nhận được bồi thường nào
Vì thế chúng tôi đang giảm dần sự phụ thuộc vào Active Directory và Windows
Rốt cuộc thì không tồn tại thị trường doanh nghiệp nếu không có người dùng
Từ sau Win32, Microsoft chưa từng đi theo một hướng quá 2 năm
WinRT cũng ổn, nhưng rồi Nadella đến và chuyển trọng tâm sang Azure, bỏ rơi nền tảng Windows
Từ Windows → Office → Azure, bản sắc của họ ngày càng mờ nhạt
Office có cả web lẫn desktop, họ cũng có phần cứng và store
Tầm nhìn của Satya Nadella không được truyền đạt rõ ràng
Store thì tệ hại, và chỉ giống một dự án để phục vụ thăng tiến nội bộ
Việc Microsoft liên tục tung ra framework GUI mới đúng là vấn đề, nhưng dù vậy ứng dụng Win32 vẫn còn có thể viết được
Microsoft từ lâu đã định hướng theo web, và cũng góp phần vào sự phát triển của các công nghệ như AJAX, Flexbox, Grid
Tôi chủ yếu phát triển hệ thống đa nền tảng dựa trên web·Java·Python
Không có lý do gì phải làm GUI chỉ dành cho Windows
Ứng dụng web linh hoạt hơn và dễ tiếp cận hơn
Web chạy ở mọi nơi, và với PWABuilder còn có thể phát hành lên app store
Tôi đang tham gia dự án này, và có thể tạo ứng dụng nhanh, nhẹ mà không cần Electron
Xem tài liệu Active Desktop thì có thể thấy thời đó khá thử nghiệm
Web chỉ là giải pháp tạm, trải nghiệm thực sự tốt vẫn đến từ native
Khoảng năm 2007 tôi chuyển từ Delphi sang WPF, nhưng đến 2010 thì rời bỏ Windows hoàn toàn
Chính trị nội bộ ở Microsoft và việc liên tục khai tử công nghệ quá mức nghiêm trọng
Khi đó Rails đang lên nên việc chuyển hướng cũng khá dễ
Có thể là hội chứng Stockholm, nhưng Visual Studio vẫn dùng WPF nên tôi cũng không quá lo
Có thể xem đó là phiên bản báo trước của vấn đề Big Tech ngày nay
Gần đây Steven Sinofsky cũng đăng bài về đúng chủ đề này
liên kết x.com
Ông ấy ở DevDiv thời WinRT, nhưng đội Windows lại không hiểu nhu cầu của lập trình viên
Từng có cả prototype Python/WinRT, nhưng bị bỏ vì họ cho rằng “lập trình viên chỉ muốn JS”
Họ còn ép Metro style đến mức đổi toàn bộ menu của Visual Studio thành CHỮ HOA
Windows RT cũng cắt đứt tính tương thích nên gần như không có ứng dụng, và cuối cùng thất bại
Thậm chí một số khẳng định kỹ thuật của Sinofsky còn sai (.NET 3.0 đã được tích hợp trong Vista)
xcancel.com hiện vẫn chưa hỗ trợ điều đó
Câu trả lời rất rõ ràng — Qt
Không đùa đâu, nếu không dùng Electron thì Qt đúng là lựa chọn thay thế thực sự
Qt làm đây là mảng kinh doanh cốt lõi nên họ không đổi hướng liên tục