- Microsoft đã công bố kế hoạch theo từng giai đoạn để mở mã nguồn WinUI, framework giao diện người dùng của Windows 11
- WinUI không thể được công khai ngay lập tức do có cấu trúc phức tạp và nhiều mã độc quyền (cần phân biệt phần có thể chia sẻ và phần không thể chia sẻ)
- Việc mở mã nguồn sẽ được thực hiện qua 4 giai đoạn
- Giai đoạn 1: Tăng tần suất mirror: Sau khi phát hành WASDK 1.8 (cuối tháng 8), các commit nội bộ sẽ được đồng bộ với GitHub thường xuyên hơn để chia sẻ tính minh bạch và tiến độ phát triển
- Giai đoạn 2: Build cục bộ cho nhà phát triển bên ngoài: Nhà phát triển bên ngoài sẽ có thể clone trực tiếp mã nguồn và build tại local, đồng thời sẽ được cung cấp tài liệu cấu hình và phụ thuộc
- Giai đoạn 3: Đóng góp và kiểm thử từ bên ngoài: Cộng đồng có thể nộp Pull Request và tự kiểm thử cục bộ, đồng thời sẽ tiến hành dọn dẹp phụ thuộc nội bộ và công bố hạ tầng kiểm thử
- Giai đoạn 4: Chuyển sang quy trình phát triển tập trung trên GitHub: Cuối cùng, GitHub sẽ trở thành trung tâm cho phát triển chính, quản lý issue và giao tiếp cộng đồng, khi hệ thống mirror nội bộ được dần dần loại bỏ
- Lộ trình mở mã nguồn của WinUI đang được quản lý công khai trên GitHub project board
- Lập trình viên và người dùng có thể đóng góp cho sự phát triển của WinUI thông qua phản hồi, viết issue rõ ràng, và bỏ phiếu cho các ý kiến đã có
3 bình luận
COM và Webview thì cũng khó chịu... giá mà có một GUI dùng được thì tốt biết mấy. Cho đến giờ, trong số các giao diện UI cho Windows mà mình từng dùng, Qt4 là cái mình thích nhất. Từ Qt5 trở đi, cảm giác như đã khác đi khá nhiều.
Thật ra thì, tôi vẫn nhớ rằng MFC cũng không tệ mấy đâu... haha
Bình luận trên Hacker News
Lo ngại về tương lai của công nghệ giao diện người dùng native của Windows. Các nhà phát triển hệ điều hành thường xây dựng ứng dụng native chạy tốt và nhất quán từ chính sản phẩm mà họ đang dùng. Nhưng trên Windows 11 lại đang diễn ra ngược lại. Từ Windows 10 đã có sẵn app Mail/Calendar cơ bản chạy tương đối ổn; trong bản cập nhật mới nhất của Windows 11, những app này đã biến mất và bị thay thế bằng lớp bao WebView chậm, khiến mở app mất vài giây.
Nhìn vào buổi gọi cộng đồng WinUI thì thấy hầu hết nhân sự mới gần như không có kinh nghiệm Windows, và cả ban lãnh đạo cũng không mấy quan tâm nên thiếu nền tảng cơ bản. Với cả những câu hỏi mà lập trình viên Windows chắc chắn phải biết, họ lại không thể trả lời, và còn không hiểu vì sao câu hỏi lại xuất hiện. Vì vậy, WebView2 bị tràn lan khắp Windows 11.
Vấn đề về UI của Windows 11 là quá tập trung vào app/chức năng mới, trong khi công cụ cũ thiếu được cập nhật. Ví dụ như Control Panel gần như từ thời Windows 7 vẫn chỉ thay lớp ngoài chứ không đổi gì. Nếu đi sâu hơn thì giống như meme dán kẹp vào đầu Homer Simpson, quanh đây lẫn lộn nhiều công cụ cũ kỹ. Chỉ khi sử dụng mới thấy giới hạn hiện ra nhanh chóng.
Có thể một ngày nào đó MSO (Office) sẽ được viết lại hoàn toàn bằng công nghệ như Dart và WASM. Trong cấu hình độc lập khỏi toolkit native, có thể tái tạo toàn bộ tính năng Excel và đóng gói thành kiểu O365 premium plan để truy cập mọi nơi. Có thể sẽ biến thành kiểu ChromeOS: chỉ cần UI native đơn giản cho các màn hình khóa/đăng nhập, phần còn lại làm nhẹ.
Nếu hiểu được cuộc đấu quyền lực nội bộ và chính trường công ty khắc nghiệt tại Microsoft thì có thể hiểu vì sao sự thay đổi này lại xảy ra. Các phòng ban đang cạnh tranh giành lợi thế cho nhau.
Windows dường như đang lẫn lộn ít nhất 10 UI framework khác nhau. Windows 11 giống như đi tham quan bảo tàng tự nhiên vậy. Có app kiểu MSC vẫn đóng băng kiểu thiết kế thời Windows 2000, lại cũng có UI thô và nguyên màu do ảnh hưởng Metro. Giao diện Win11 mới nhìn có vẻ đáng tin, nhưng thực ra chỉ giống bôi son lên con lợn. Menu chuột phải là ví dụ điển hình: nhìn đẹp hơn, nhưng thiếu chức năng đến mức phải bấm "Xem thêm" mới thấy được nhiều tính năng kiểu cũ. Tổng thể thì thật lộn xộn.
Trong những bài phát biểu kiểu "căn chỉnh với mục tiêu của Microsoft", "phân bổ nguồn lực một cách thận trọng", tôi không thấy được sự chân thành. Cuối cùng, đây dường như là chiến lược giao framework ra ngoài, rút tài nguyên về phía bên trong và hy vọng các dev bên ngoài đầy nhiệt huyết sẽ lo bảo trì.
Cụm từ "người thua cuộc đầy nhiệt huyết" nghe quá tiêu cực. Dù tôi không quan tâm đến UI Win11 hoặc đồng cảm với cái nhìn hoài nghi rằng việc mã hóa nguồn mở lần này chỉ nhằm tiết kiệm chi phí, tôi vẫn muốn thể hiện sự tôn trọng với những người đang muốn tiếp tục công việc này.
Nói thẳng thì đây là cách nói kiểu doanh nghiệp: "không có support đảm bảo, không có kế hoạch cập nhật thêm ngoài lỗi bảo mật, dùng đi".
Có cảm giác muốn đùa: "Apache Windows bao giờ ra vậy". Nói nghiêm túc, desktop UI toolkit bây giờ không còn là rào cản hay lợi thế cạnh tranh nữa. Bởi vì trên Windows, có tới 3~4 phong cách khác nhau đang được phát hành chính thức. Nhưng bảo mật và ổn định vẫn là điều kiện bắt buộc để Windows còn sống ở doanh nghiệp, tài chính và cơ quan nhà nước.
Việc mở source UI framework của công ty khác có thể hiểu được. Ví dụ Atlassian hay AWS framework vì đã dùng trong Jira/AWS nên có thể cân nhắc cho B2B SaaS. Nhưng với framework này, tôi không biết vì sao phải dùng. Nếu không hẳn chỉ muốn làm app native Windows, thì đã có lựa chọn tốt hơn.
Tôi cho rằng WinUI đã thất bại.
Trong cộng đồng phát triển Windows, những người quan tâm WinUI gần như không có, chỉ còn những dev đã đầu tư vào WinRT/UWP và không thể thoát ra. Từ sau Windows 8, quá nhiều cầu bị cắt đứt khiến cộng đồng mất niềm tin. Hiểu nôm na là Microsoft muốn đẩy sửa lỗi cho cộng đồng hơn là tự sửa.
DevExpress, Progress Telerik cũng không đầu tư vào phát triển WinUI control nên đó là dấu hiệu họ cũng không tin vào tương lai của WinUI. Tại thời điểm hiện tại, với app doanh nghiệp thì WinForms và WPF gần như chỉ còn lựa chọn thực tế. Tôi chưa từng gặp app nào được làm bằng WinUI3 và chạy trong môi trường thực tế.
Nói thật, giờ ai còn muốn dùng nghiêm túc một UI framework nào của Microsoft nữa? Framework cũ đã dùng cũng luôn bị bỏ dở, để giữa chừng rồi bỏ qua, và rồi lại bị thu hút bởi framework mới lấp lánh nên cuối cùng mọi thứ lại bị quên. Trái lại, framework mã nguồn mở đa nền tảng có nền tảng và tính năng hoàn thiện hơn nhiều, bảo trì tốt hơn. WinUI này cũng chỉ sẽ thành một UWP bị bỏ rơi khác.
Bây giờ tôi khó mà đếm nổi Windows có bao nhiêu UI framework; cảm giác quá hỗn loạn. Không rõ khi mở source thì kỳ vọng gì. Chỉ là hình ảnh "đang mở" hay có lợi ích thực sự cho nhà phát triển nhắm đến Windows?
WinUI là bản phát triển từ UWP, mà UWP vốn là sự tiến hóa của WinRT. Mục tiêu của WinUI rất rõ và là công nghệ đã trưởng thành qua nhiều năm (hiện giờ là WinUI 3). MAUI không phải là đối thủ cạnh tranh, mà là framework đa nền tảng. Nhưng nếu không tái cấu trúc toàn bộ OS, đặc biệt là công cụ quản lý, bằng WinUI thì khó xây dựng niềm tin dài hạn.
Lúc đầu đọc hàng loạt chữ viết tắt và giải thích ở trên, tôi tưởng chừng đây là châm biếm. WinUI, UWP, WinRT, XAML, Avalon, WPF, Project Reunion, Win2D, MFC, wxWidgets, Qt, ... Quá nhiều tên phiên bản và framework trộn lẫn khiến chỉ riêng phần mô tả đã dài và dễ làm bạn bối rối.
Có lẽ Microsoft như mọi lần đang tập trung vào xu hướng mới (lần này là AI!) và đang tìm cách dọn công nghệ cũ một cách âm thầm. Tôi đoán số người phản đối thực ra chỉ là thiểu số.
Trên thực tế, Windows có ba UI framework, trong đó chỉ hai cái thật sự còn sống. Hai phần còn lại chỉ là sự lặp lại phát triển của hai dòng Win32/native và WPF/Managed. WinUI3 được tạo ra để bù đắp khoảng trống giữa hai dòng đó.
Về dài hạn, tôi nghĩ MFC vẫn là lựa chọn có khả năng tồn tại lâu nhất. Dù giờ đã ngừng cập nhật, nhưng tôi tin nó còn sống được 20 năm nữa.
Tôi chỉ mong Microsoft phát triển tiếp WPF. Tôi đã dùng WPF trong nhiều dự án và mặc dù có learning curve, vẫn hài lòng với Data Binding, ViewModel, XAML. Nhưng để WPF hoàn hảo hơn thì cần vài cải tiến. Gần đây tôi cũng thử framework mới của Microsoft hoặc nguồn mở như Avalonia, Uno, ...; nhưng mẫu demo không chạy hoặc cách phát triển không hợp. Kết quả là tôi lại quay về WPF quen thuộc. Ý tưởng cải tiến lớn nhất cho WPF là làm Data Binding bằng sinh mã compile-time của .NET thay cho Reflection runtime. Cách này có thể cho phép build AOT thực sự, hiệu năng sẽ tăng mạnh, và có thêm nhiều lợi thế như tính an toàn kiểu của XAML, hỗ trợ đa nền tảng. Tôi từng muốn thử làm dạng open-source, nhưng thiếu thời gian và quá nhiều việc.
Ý thứ hai ở trên rất hợp với Avalonia. Avalonia đã hỗ trợ AOT, ràng buộc compile-time, và tính năng đa nền tảng. Nếu bạn lâu ngày không thấy bản cập nhật mới, hãy xem Avalonia compile-time data binding docs và dự án XamlX.
Cách này còn giúp trimming assembly. Để triển khai độc lập, hiện tại phải đi kèm thư viện .NET trên 200MB, còn cách này có thể giảm đáng kể.
Khi từng đánh giá WinUI3 trước đây, trải nghiệm lập trình rất tệ. Để debug một app muốn phát hành, bắt buộc cài app đó vào hệ thống. Hậu quả là Start menu đầy những mục thừa và registry trở nên bừa bãi. Thậm chí mã mẫu thì bấm nút xong là app crash luôn. Tôi vẫn làm app Windows bằng Win32+WTL.
Như nhiều người đã chỉ ra, framework UI cho Windows lâu nay chưa được làm gọn mà chỉ đùn đẩy thêm sự lộn xộn. Tiếc là cộng đồng mã nguồn mở đa nền tảng cũng vậy. GTK từng là mớ hỗn độn một thời gian, Qt thì có nhiều tính năng nhưng mô hình giấy phép cho mục đích chuyên nghiệp quá nặng. (Từ thời kỳ Nokia và cả giai đoạn Elop của MS, rồi sau đó đến lần đổi chủ sở hữu Qt, nó cũng chìm dần.) Trong một số lĩnh vực có giải pháp như Dear ImGui khá ổn, nhưng nhìn chung gần như không có giải pháp thay thế cho UI/widget framework native hay cross-platform nào có giấy phép permissive, biên dịch native, cấu hình widget tốt và hỗ trợ render Vulkan 3D.
Tôi mong Windows 11 khôi phục taskbar dọc native. Chức năng này đã có từ Windows 98, nhưng tại 11 nó đã biến mất. Có Windhawk (ép taskbar ngang) hay StartAllBack (phục hồi code kiểu Windows 10) của bên thứ ba, nhưng vẫn chưa hoàn hảo.
Việc open-source framework UI sẽ không làm mở rộng được tính năng taskbar. Đóng góp trong mảng này phải là taskbar (tức explorer.exe) được mở, chứ không phải UI framework.
Nhân tiện, từ Windows 95 đã có taskbar dọc trong tùy chọn.
Tính năng taskbar thuộc explorer.exe. Tuyên bố open-source hiện tại đang bàn đến không liên quan tới explorer.
Tôi nghi ngờ đội Windows có đang thật sự làm UI desktop native bằng WinUI hay không.
Hiện tại công việc UI cho Windows đang được làm bằng Win32, GDI, DirectDraw, v.v. Nhờ CsWin32 và C# mới (ref returns), khả năng tiếp cận đã tăng hơn trước. Trước đây thường phải tách riêng project bằng C++, còn giờ chỉ cần ghi các hàm cần thiết vào
NativeMethods.txt, codegen sẽ làm nốt. Win32 chắc chắn cấp thấp hơn rõ so với các UI framework khác, nhưng ngược lại Microsoft cũng khó can thiệp hay dẹp bỏ nó. Nhìn dài hạn, không có API nào bền vững như vậy. So với API gốc, nền tảng web cũng không thể so sánh theo hướng dài hạn.Dù vậy, vẫn cần C++ ở khá nhiều phần. Do sự cứng nhắc của nhóm Windows với COM. Windows Runtime Components là cơ hội để nâng cấp hệ sinh thái .NET lên một tầm mới, nhưng đã bỏ lỡ. Mở rộng shell, context menu extension, v.v. phải làm bằng C++; nếu làm bằng .NET thì cuối cùng cũng là đặt stub C++ rồi gọi quy trình .NET.
So với tranh luận về framework bề mặt, tôi thấy chuyện API tầng thấp mới thú vị hơn. Tôi nghĩ toàn bộ stack render của Windows được dựng trên GDI/DirectX, và Win32 về bản chất cũng nằm trên GDI. Nếu muốn bàn về stack UI Windows "gần kim loại" hơn, bắt đầu từ DirectX có vẻ hợp lý hơn.
Từ góc nhìn người dùng, Win32 vẫn đủ cấp cao. Cho đến bây giờ, toolkit nào vẽ được đúng button, scrollbar đúng cách thì chỉ có Win32.
Tôi mong cộng đồng tạo ra framework native thật sự tốt cho phát triển Windows. Nhưng thực tế cộng đồng đủ lớn để làm chuyện đó thì chưa.
Điều tôi nhớ nhất ở phát triển UI Windows trước đây là Microsoft từng giúp để dễ tạo app trông tự nhiên như sản phẩm do chính họ làm. Kể từ khi web tech được đưa vào, sự nhất quán của trải nghiệm UI Windows đã sụp xệ nhiều. Không chỉ Microsoft không cập nhật app cũ, mà toolkit mới cũng không cung cấp thư viện theo đúng style guide. Xu hướng này bắt đầu từ thời Vista, và trong MSDN, tài liệu mẫu phong phú kiểu 'đây là cách dùng tính năng này' cũng ngày càng biến mất.