Microsoft đã không có chiến lược GUI mạch lạc kể từ Petzo...

Cách đây vài năm, tôi đã tham dự một cuộc họp với các nhà phát triển và có người đã hỏi một câu hỏi đơn giản: “Framework phù hợp cho một ứng dụng desktop Windows mới là gì?”

Im lặng như tờ. Một người gợi ý WPF. Một người khác nói WinUI 3. Người thứ ba hỏi liệu họ có nên dùng Electron không. Cuộc họp đi chệch hướng và chúng tôi chưa bao giờ trả lời được câu hỏi đó.

Sự im lặng đó chính là câu chuyện. Và câu chuyện đã bắt đầu từ hơn ba mươi năm trước.

Khi một nền tảng không thể trả lời câu hỏi “làm thế nào để xây dựng giao diện người dùng?” trong vòng chưa đầy mười giây, thì nó đã thất bại với các nhà phát triển của mình. Dừng lại.

Lần Cuối Cùng Windows Có Một Câu Trả Lời Rõ Ràng

Năm 1988, Charles Petzold xuất bản cuốn *Programming Windows*. 852 trang. Win16 API bằng C. Và dù dày cộp, nó đại diện cho một điều đáng chú ý: một câu trả lời duy nhất, mạch lạc, có thẩm quyền về cách viết một ứng dụng Windows. Trong ngành, chúng ta gọi đó là một 'chiến lược'.

Win32 theo sau còn lớn hơn nhưng vẫn mạch lạc. Message loops. Window procedures. GDI. Mô hình tư duy hơi kỳ quặc, nhưng đó là *một* mô hình tư duy duy nhất. Petzold đã giải thích nó. Nó giống như định luật F=MA của Windows. Đơn giản. Mạnh mẽ. Bạn học nó. Bạn sử dụng nó. Bạn thành công.

Sự rõ ràng là bạn của bạn! Một hệ điều hành, một API, một ngôn ngữ, một cuốn sách. Không có ủy ban nào tranh luận về các lựa chọn thay thế mã được quản lý. Chỉ có Win32 và Petzold, và nó hoạt động. Đây là Vật lý chứ không phải Hóa học (cái này hoạt động nhưng chỉ cho phần này của bảng tuần hoàn. Và chỉ trong điều kiện áp suất này. Và chỉ trong phạm vi nhiệt độ này. Và chỉ khi Mặt trăng nằm trong cung thứ 7 của Sao Mộc).

Những gì xảy ra tiếp theo là một bậc thầy về cách một công ty với những con người xuất sắc và nguồn lực khổng lồ có thể tạo ra một màn trình diễn kéo dài ba mươi năm bằng cách tối ưu hóa cho những thứ sai lầm. Hay còn gọi là *Những người xuất sắc làm những điều ngu ngốc*.

Cơn Ác Mộng Hướng Đối Tượng (1992–2000)

Win32 có những hạn chế thực sự, vì vậy Microsoft đã làm như những gì Microsoft thường làm: họ ra mắt một cái gì đó mới cho hội nghị nhà phát triển. Vài thứ.

MFC (1992) bọc Win32 trong C++. Nếu Win32 không thanh lịch, MFC giống như Win32 mặc một bộ tuxedo làm từ các bộ tuxedo khác. Rồi đến OLE. COM. ActiveX. Thực tế không có cái nào trong số này là framework GUI – chúng là kiến trúc thành phần – nhưng chúng đã lây lan đến mọi ngóc ngách của việc phát triển Windows và giới thiệu một mức độ phức tạp nhận thức khiến Kierkegaard đọc giống như Hemingway.

Tôi đã tham dự một buổi hội thảo vào cuối những năm chín mươi để cố gắng hiểu sự khác biệt giữa tài liệu OLE, đối tượng COM và điều khiển ActiveX. Tôi nhìn người thuyết trình như thể anh ta có một cái đuôi chuột thò ra khỏi miệng trong suốt một giờ.

Microsoft không bán một câu chuyện mạch lạc. Họ bán các nguyên tắc công nghệ và yêu cầu các nhà phát triển tự mình hình dung ra câu chuyện. Đó là sự rối ren của các bài phát biểu quan trọng tại Hội nghị - Microsoft tối ưu hóa cho ban giám đốc gây ấn tượng với mọi người bằng bài phát biểu của họ chứ không phải cho sự thành công của người dùng hoặc nhà phát triển.

PDC 2003 và Tầm Nhìn Tự Hủy Diệt

Tại PDC 2003, Microsoft đã giới thiệu Longhorn – thực sự là một trong những tầm nhìn kỹ thuật hấp dẫn nhất mà công ty từng đưa ra cho các nhà phát triển. Ba trụ cột: WinFS (một hệ thống tệp quan hệ), Indigo (truyền thông hợp nhất) và Avalon – sau này là WPF – một hệ thống phụ UI tăng tốc GPU, dựa trên vector, được điều khiển bởi một ngôn ngữ XML khai báo gọi là XAML. Các nhà phát triển đã xem các bản demo Avalon và phát cuồng. Đó là tầm nhìn đúng đắn.

Nó cũng là, theo lời của bản ghi nhớ nội bộ của Jim Allchin từ tháng 1 năm 2004, “một con lợn.”

Đến tháng 8 năm 2004, Microsoft đã công bố một lần thiết lập lại hoàn toàn việc phát triển. Bỏ đi. Bắt đầu lại từ cơ sở mã Server 2003. Và sau lần thiết lập lại đó, ban lãnh đạo đã đưa ra một chỉ thị im lặng: không sử dụng mã được quản lý trong Windows. Tất cả mã mới sẽ bằng C++. WPF sẽ được phát hành cùng với Vista, nhưng bản thân giao diện người dùng sẽ không sử dụng nó.

Sự cay đắng của nhóm Windows đối với .NET chưa bao giờ nguôi ngoai. Từ góc nhìn của họ, việc đánh cược vào một framework mã được quản lý mới đã dẫn đến thất bại đáng xấu hổ nhất trong lịch sử công ty. Sự cay đắng đó đã tạo ra một cuộc nội chiến thể chế kéo dài mười ba năm giữa nhóm Windows và nhóm .NET, cuối cùng sẽ bỏ rơi WPF, giết chết Silverlight, làm tiêu tan UWP và mang lại cho chúng ta khung cảnh giao diện người dùng tồi tệ như ngày nay.

Silverlight: Mô Hình Được Thiết Lập (2007–2010)

WPF được phát hành vào cuối năm 2006. Nó thật đáng kinh ngạc – XAML, hiển thị tăng tốc phần cứng, ràng buộc dữ liệu thực tế. Nếu Microsoft biến nó thành câu trả lời dứt khoát và đầu tư không ngừng, câu chuyện có thể đã kết thúc khác. Thay vào đó, vào năm 2007, họ đã ra mắt Silverlight: một plugin trình duyệt được cắt giảm để cạnh tranh với Flash, đa nền tảng, thanh lịch và là nền tảng cho Windows Phone. Khoảng năm 2010, nó trông giống như tương lai của client phong phú.

Sau đó, tại MIX 2010, một giám đốc điều hành của Microsoft đã nói trong một buổi Hỏi & Đáp rằng Silverlight không phải là chiến lược đa nền tảng – nó dành cho Windows Phone. HTML5 giờ đã là chính sách. Nhóm Silverlight đã không được thông báo về điều này. Các nhà phát triển đã đặt cược các ứng dụng LOB của họ vào Silverlight thì biết điều này từ một buổi Hỏi & Đáp tại hội nghị.

Silverlight không bị giết chết bởi lỗi kỹ thuật. Công nghệ vẫn ổn. Nó bị giết chết bởi một quyết định chiến lược kinh doanh, và các nhà phát triển là những người cuối cùng biết điều đó.

Hãy nhớ mô hình đó. Chúng ta sẽ thấy nó lại.

Sự Hoảng Loạn Metro và Cuộc Chiến Hai Đội (2012)

Apple đã bán được 200 triệu iPhone. iPad đang chiếm lĩnh doanh số bán PC. Câu trả lời của Microsoft là Windows 8 và Metro – một runtime tập trung vào cảm ứng gọi là WinRT, cố tình *không* được xây dựng trên .NET. Còn nhớ sự cay đắng của nhóm Windows không? Đây là nơi nó biểu hiện. WinRT là một runtime C++ gốc. Một sự tách biệt rõ ràng khỏi WPF, WinForms và một thập kỷ đầu tư của nhà phát triển vào .NET.

Thực tế có hai câu chuyện được kể đồng thời bên trong Microsoft. Nhóm Windows đang xây dựng WinRT. Nhóm .NET vẫn đang quảng bá WPF. Các tòa nhà khác nhau, các phó chủ tịch khác nhau, lộ trình khác nhau.

Những gì các nhà phát triển nghe thấy tại //Build 2012: tương lai là WinRT, và cả HTML+JS cũng là hạng nhất, và cả .NET vẫn hoạt động, và cả C++ đã trở lại, và cả bạn nên viết các ứng dụng Metro, và cả mã WPF của bạn vẫn chạy tốt. Đó không phải là một chiến lược. Đó là một sân khấu Hunger Games nơi sáu đội đang tranh giành sự chú ý của bạn.

Các nhà phát triển doanh nghiệp nhìn vào việc sandboxing của UWP, yêu cầu triển khai qua Store và các API Win32 còn thiếu, và bỏ đi. Framework được thiết kế để thu hút họ vào kỷ nguyên hiện đại đã được tối ưu hóa cho một cửa hàng ứng dụng trên máy tính bảng chưa bao giờ thành hiện thực.

UWP và Sự Lan Rộng Của WinUI (2015–Hiện tại)

Windows 10 mang đến Universal Windows Platform – viết một lần, chạy trên PC, điện thoại, Xbox, HoloLens. Hấp dẫn trên lý thuyết. Vấn đề: Windows Phone đang hấp hối, và các ứng dụng chủ lực của chính Microsoft – Office, Visual Studio, bản thân giao diện người dùng – đã không sử dụng UWP. Thông điệp rất rõ ràng ngay cả khi không ai nói ra.

Khi UWP đình trệ, câu trả lời chính thức trở thành *tùy thuộc*. Sử dụng UWP cho các ứng dụng mới, giữ WPF cho các ứng dụng hiện có, thêm các API hiện đại qua XAML Islands, đợi WinUI 3, nhưng cũng có WinUI 2 dành riêng cho UWP, và Project Reunion sẽ sửa mọi thứ, ngoại trừ việc chúng ta đổi tên nó thành Windows App SDK và nó vẫn không hoàn toàn thay thế UWP và…

Những người xuất sắc làm những điều ngu ngốc. Chuyển động kiểu Brown của công nghệ.

Project Reunion / WinUI 3 đại diện cho sự tiến bộ thực sự. Nhưng hãy tự hỏi tại sao vấn đề này lại tồn tại. Các điều khiển của UWP bị ràng buộc với hệ điều hành vì nhóm Windows sở hữu chúng. Nhóm .NET thì không. Nhóm công cụ nhà phát triển cũng không. Project Reunion là một giải pháp tạm thời về mặt tổ chức được khoác lên mình một giải pháp kỹ thuật.

Tóm tắt của một nhà phát triển, viết vào năm 2024: “Tôi đã theo dõi những thay đổi liên tục của Microsoft: UAP, UWP, C++/CX được thay thế bằng C++/WinRT mà không có hỗ trợ công cụ, XAML Islands, XAML Direct, Project Reunion, việc khởi động lại WinAppSDK, sự chuyển đổi hỗn loạn giữa WinUI 2.0 và 3.0…” Mười bốn năm. Mười bốn lần xoay chuyển. Người đó xứng đáng được trao huy chương và một lời xin lỗi, theo thứ tự đó.

Vườn thú không người trông coi

Đây là tất cả các công nghệ GUI thực sự đang được phát hành trên Windows hiện nay:

Các framework gốc của Microsoft:

Win32 (1985) – Vẫn còn đó. Vẫn đang được sử dụng. Sách của Petzold vẫn còn phù hợp.
MFC (1992) – Lớp bọc C++ trên Win32. Chế độ bảo trì. Tồn tại trong doanh nghiệp và CAD.
WinForms (2002) – Lớp bọc .NET trên Win32. “Có sẵn nhưng không được khuyến khích.” Vẫn nhanh nhất cho các biểu mẫu nhập liệu.
WPF (2006) – XAML, render bằng DirectX, mã nguồn mở. Không có đầu tư mới từ Microsoft.
WinUI 3 / Windows App SDK (2021) – Câu trả lời “hiện đại”. Lộ trình không chắc chắn.
MAUI (2022) – Kế thừa đa nền tảng của Xamarin.Forms. Lựa chọn hiện tại của nhóm .NET.

Hybrid web của Microsoft:

Blazor Hybrid – Các thành phần Razor .NET trong WebView gốc.
WebView2 – Nhúng Chromium vào ứng dụng Win32/WinForms/WPF.

Bên thứ ba:

Electron – Chromium + Node.js. VS Code, Slack, Discord. Công nghệ GUI desktop được triển khai rộng rãi nhất trên Windows hiện nay – và Microsoft không liên quan gì đến nó.
Flutter (Google) – Dart, trình kết xuất tùy chỉnh, đa nền tảng.
Tauri – Backend Rust, giải pháp thay thế nhẹ nhàng cho Electron.
Qt – C++/Python/JavaScript. Lựa chọn đa nền tảng nghiêm túc.
React Native for Windows – Bản port được Microsoft hỗ trợ của framework di động của Facebook.
Avalonia – Kế thừa tinh thần mã nguồn mở của WPF. Được sử dụng bởi JetBrains, GitHub, Unity – các nhà phát triển đã ngừng chờ đợi Microsoft.
Uno Platform – API WinUI trên mọi nền tảng. Cam kết với WinUI hơn cả Microsoft.
Delphi / RAD Studio – Vẫn còn tồn tại. Vẫn nhanh. Vẫn trong phần mềm thị trường ngách.
Java Swing / JavaFX – Vâng, vẫn còn trong sản xuất. Doanh nghiệp không bao giờ quên.

Mười bảy cách tiếp cận. Năm ngôn ngữ lập trình. Ba triết lý kết xuất. Đó không phải là một nền tảng. Tôi có thể không có định nghĩa từ điển cho thuật ngữ boof-a-rama nhưng tôi biết khi nhìn thấy nó.

Bài học

Mọi sáng kiến GUI thất bại đều bắt nguồn từ một trong ba nguyên nhân: chính trị nội bộ nhóm (Windows vs .NET), một thông báo hội nghị nhà phát triển thúc đẩy một lựa chọn nền tảng quá sớm (Metro, UWP), hoặc một sự xoay chuyển chiến lược kinh doanh đã bỏ rơi các nhà phát triển mà không có cảnh báo (Silverlight). Không có nguyên nhân nào trong số này là thất bại về kỹ thuật. Công nghệ thường rất tốt – WPF rất tốt, Silverlight rất tốt, XAML rất tốt. Thất bại về tổ chức mới là sản phẩm.

Bạn có một Lý thuyết Thành công Khả thi bao gồm toàn bộ vòng đời – việc áp dụng, đầu tư, bảo trì và di chuyển – hoặc bạn có một bài phát biểu chính tại hội nghị nhà phát triển.

Một là chiến lược. Một là boof-a-rama kéo dài ba mươi năm.

Charles Petzold đã viết sáu phiên bản của Programming Windows để cố gắng theo kịp mọi thứ mới mà Microsoft công bố. Ông đã dừng lại sau phiên bản thứ sáu, bao gồm WinRT cho Windows 8. Đó là năm 2012.

Tôi không trách ông ấy.

Microsoft đã không có một chiến lược GUI mạch lạc kể từ Petzold