Chiến lược giao diện của Microsoft: 30 năm hỗn loạn kể từ thời Petzold

Cách đây vài năm, tôi đang trong một cuộc họp với các nhà phát triển khi có người đặt một câu hỏi rất đơn giản: “Khung làm việc (framework) nào là phù hợp để xây dựng một ứng dụng desktop Windows mới?”

Đó là sự im lặng chết chóc. Một người đề xuất WPF. Người khác nói WinUI 3. Người thứ ba hỏi liệu có nên chỉ dùng Electron thôi không. Cuộc họp đi vào ngõ cụt và chúng tôi chưa bao giờ trả lời được câu hỏi đó.

Sự im lặng ấy chính là câu chuyện. Và câu chuyện này kéo dài hơn ba mươi năm.

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

Lần cuối cùng Windows có 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 ngôn ngữ C. Và dù dày cộm, nó đại diện cho một điều đáng chú ý: một câu trả lời duy nhất, nhất quán và có thẩm quyền về cách viết một ứng dụng Windows. Trong nghề này, chúng tôi gọi đó là một “chiến lược”.

Win32 ra đời sau đó lớn hơn nhưng vẫn nhất quán. Vòng lặp thông điệp (message loops). Thủ tục cửa sổ (window procedures). GDI. Mô hình tư duy có hơi kỳ quặc, nhưng đó là một mô hình tư duy duy nhất. Petzold đã giải thích nó. Đó là định luật F=MA của Windows. Đơn giản. Mạnh mẽ. Bạn học nó. Bạn dùng nó. Bạn thành công.

Sự rõ ràng là người bạn của bạn! Một OS, 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 giải pháp managed-code. 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 một phần nhỏ của bảng tuần hoàn. Và chỉ dưới áp suất này. Và chỉ trong nhiệt độ này. Và chỉ nếu Mặt trăng ở ngôi nhà thứ 7 của Mộc tinh).

Những gì xảy ra sau đó là một bài học kinh điển về cách một công ty với những người briliant và nguồn lực khổng lồ có thể tạo ra một mớ hỗn độn kéo dài ba mươi năm bằng cách tối ưu hóa cho những sai lầm. Hay còn gọi là Những người thông minh làm những việc ngu ngốc.

Cơn sốt hướng đối tượng (1992–2000)

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

MFC (1992) bọc Win32 trong C++. Nếu Win32 thô kệch, MFC giống như Win32 mặc một bộ vest làm từ những bộ vest khác. Sau đó đến OLE. COM. ActiveX. Không cái nào trong số này thực sự là khung GUI – chúng là kiến trúc thành phần – nhưng chúng xâm chiếm mọi ngóc ngách của phát triển Windows và giới thiệu một mức độ phức tạp về nhận thức khiến đọc Kierkegaard còn dễ hơn đọc Hemingway.

Tôi đã ngồi hết một buổi hội nghị vào cuối những năm 90 cố 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ể họ có cái đuôi chuột thò ra khỏi miệng trong suốt một giờ đồng hồ.

Microsoft không đang bán một câu chuyện mạch lạc. Họ đang bán các nguyên tố công nghệ và bảo các nhà phát triển tự tìm ra câu chuyện. Đó là Thảm họa trong các bài diễn văn hội nghị – Microsoft tối ưu hóa để một giám đốc điều hành gây ấn tượng với bài diễn văn của họ chứ không phải vì sự thành công của người dùng hay nhà phát triển.

PDC 2003 và Tầm nhìn tự nuốt chửng lấy mình

Tại PDC 2003, Microsoft công bố 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 (hệ thống tệp quan hệ), Indigo (truyền thông thống nhất), và Avalon – sau này là WPF – một hệ thống con UI dựa trên vector, tăng tốc GPU, được điều khiển bởi ngôn ngữ khai báo XML gọi là XAML. Các nhà phát triển thấy bản demo Avalon và phát cuồng. Đó là tầm nhìn đúng đắn.

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

Đến tháng 8 năm 2004, Microsoft thông báo thiết lập lại hoàn toàn phát triển. Hủy bỏ. Bắt đầu lại từ nền tảng mã Server 2003. Và sau khi thiết lập lại, lãnh đạo đưa ra một chỉ đạo thầm lặng: không có mã managed-code nào trong Windows. Tất cả mã mới bằng C++. WPF sẽ được tung ra cùng với Vista, nhưng chính shell của Windows sẽ không dùng nó.

Sự đắng cay của đội Windows đối với .NET chưa bao giờ lành. Theo góc nhìn của họ, việc đánh cược vào một khung managed-code mới đã tạo ra sự thất bại nhục nhã nhất trong lịch sử công ty. Sự đắng cay đó đã tạo ra một cuộc nội chiến thể chế kéo dài mười ba năm giữa đội Windows và đội .NET, cuối cùng khiến WPF bị bỏ rơi, giết chết Silverlight, kết án UWP, và mang lại cho chúng ta hệ sinh thái GUI hỗn loạn như ngày nay.

Silverlight: Mô hình đã được thiết lập (2007–2010)

WPF ra đời cuối năm 2006. Nó đáng chú ý – XAML, kết xuất tăng tốc phần cứng, ràng buộc dữ liệu thực sự. Nếu Microsoft đã biến nó thành câu trả lời xác định và đầu tư không ngừng nghỉ, câu chuyện có thể đã kết thúc khác đi. Thay vào đó, năm 2007, họ tung ra Silverlight: một plugin trình duyệt 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 tương lai của ứng dụng khách phong phú.

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

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

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

Cơn hoảng loạn Metro và Cuộc chiến hai đội (2012)

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

Thực sự có hai câu chuyện được kể đồng thời bên trong Microsoft. Đội Windows đang xây dựng WinRT. Đội .NET vẫn đang truyền giáo WPF. Tòa nhà khác, Phó chủ tịch khác, lộ trình khác.

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

Các nhà phát triển doanh nghiệp nhìn một lần vào sandbox của UWP, yêu cầu triển khai qua Store, và các API Win32 bị thiếu, rồi bỏ đi. Khung làm việc được thiết kế để lôi kéo 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 máy tính bảng chưa bao giờ thành hiện thực.

UWP và sự lan tràn của WinUI (2015–Hiện tại)

Windows 10 mang lại Nền tảng Windows Phổ quát (UWP) – viết một lần, chạy trên PC, điện thoại, Xbox, HoloLens. Hấp dẫn trên giấy. Vấn đề: Windows Phone đang chết, và các ứng dụng cờ hiệu của chính Microsoft – Office, Visual Studio, chính shell – không dùng UWP. Thông điệp rõ ràng dù không ai nói to lên.

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

Những người thông minh làm những việc ngu ngốc. Chuyển động Brownian trong 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 đề lại tồn tại. Các điều khiển của UWP bị gắn vào OS vì đội Windows sở hữu chúng. Đội .NET thì không. Đội công cụ phát triển thì không. Project Reunion là một giải pháp tổ chức được ngụy trang thành giải pháp kỹ thuật.

Tóm tắt của một nhà phát triển, viết năm 2024: “Tôi đã theo dõi những thay đổi liên tục của Microsoft: UAP, UWP, C++/CX bị thay thế bởi C++/WinRT không có hỗ trợ công cụ, XAML Islands, XAML Direct, Project Reunion, 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 thay đổi hướng. Người đó xứng đáng được nhận một huy chương và một lời xin lỗi, theo thứ tự đó.

Sở thú không có người quản lý

Dưới đây là mọi công nghệ GUI thực sự đang chạy trên Windows hôm nay:

Khung native của Microsoft:

• Win32 (1985) – Vẫn còn đây. Vẫn được dùng. Cuốn sách của Petzold vẫn áp dụng.
• MFC (1992) – C++ wrapper trên Win32. Chế độ bảo trì. Sống trong doanh nghiệp và CAD.
• WinForms (2002) – .NET wrapper trên Win32. “Có sẵn nhưng không khuyến khích”. Vẫn nhanh nhất cho form nhập dữ liệu.
• WPF (2006) – XAML, kết xuất 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. Cược hiện tại của đội .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 có 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, thay thế nhẹ nhàng cho Electron.
• Qt – C++/Python/JavaScript. Tùy chọn đa nền tảng nghiêm túc.
• React Native for Windows – Cổng do Microsoft hỗ trợ của khung di động của Facebook.
• Avalonia – Kế thừa tinh thần WPF mã nguồn mở. Được dùng bởi JetBrains, GitHub, Unity – những 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 sống. Vẫn nhanh. Vẫn trong phần mềm thị trường dọc.
• Java Swing / JavaFX – Vâng, vẫn đang sản xuất. Doanh nghiệp không bao giờ quên.

Sự hỗn loạn của các framework Windows

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 nó khi tôi thấy nó.

Bài học

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

Hoặc là bạn có một Lý thuyết Thành công Plausible bao phủ toàn bộ vòng đời – áp dụng, đầu tư, bảo trì và di chuyển – hoặc là bạn có một bài diễn văn tại hội nghị nhà phát triển.

Một cái là chiến lược. Cái kia là một mớ hỗn độn ba mươi năm.

Charles Petzold đã viết sáu ấn bản của Programming Windows cố gắng bắt kịp mỗi thứ mới mà Microsoft công bố. Ông ấy dừng lại sau ấ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.