De ce Windows 11 continuă să primească aplicații web în loc de aplicații native?

A fost o vreme când construirea unei aplicații Windows nu necesita o dezbatere.

Dezvoltarea inițială a Windows se învârtea în jurul unei singure abordări bine înțelese. Win32 era răspunsul. Un singur API și o modalitate clară de a realiza lucrurile.

Totuși, în loc să evolueze Win32 în ceva mai modern, Microsoft a continuat să introducă noi straturi și alternative.

Mai întâi a apărut MFC ca wrapper C++. Apoi WinForms pentru dezvoltatorii .NET. WPF a urmat cu XAML și randarea accelerată hardware. Silverlight a apărut ca o opțiune multiplatformă.

Apoi au apărut WinRT și UWP în era Windows 8 și Windows 10. Și acum avem WinUI 3 cu Windows App SDK, alături de MAUI pentru dezvoltare multiplatformă.

Fiecare dintre acestea a fost anunțată cu un argument puternic despre viitorul dezvoltării Windows. Fiecare le-a cerut dezvoltatorilor să investească timp, să învețe noi modele și să construiască pe baza acestora.

Problema nu era că aceste tehnologii erau proaste. Multe dintre ele erau cu adevărat înaintea timpului lor. Problema era că „viitorul” era înlocuit în mod repetat înainte de a se putea stabiliza complet. În loc de o singură platformă în evoluție, dezvoltatorii erau lăsați să urmărească ”ținte în mișcare”.

Acum câțiva ani, Jeffrey Snover era într-o întâlnire cu dezvoltatori și cineva a pus o întrebare simplă: „Care este framework-ul potrivit pentru o nouă aplicație desktop Windows?”

Liniște totală. O persoană a sugerat WPF. Alta a spus WinUI 3. O a treia a întrebat dacă ar trebui să folosească pur și simplu Electron. Întâlnirea a decurs prost și Jeffrey nu a răspuns niciodată la întrebare.

Acea tăcere este povestea. Și povestea datează de peste treizeci de ani.

Când o platformă nu poate răspunde la întrebarea „cum ar trebui să construiesc un UI?” în mai puțin de zece secunde, își dezamăgește dezvoltatorii. Punct.

Ultima dată când Windows a avut un răspuns clar

În 1988, Charles Petzold a publicat „Programarea Windows”. 852 de pagini. API-ul Win16 în C. Și, în ciuda volumului său, reprezenta ceva remarcabil: un răspuns unic, coerent și autoritar la modul în care scrieți o aplicație Windows. În domeniu, numim asta „strategie”.

Win32 care a urmat a fost mai mare, dar totuși coerent. Bucle de mesaje. Proceduri de fereastră. GDI. Modelul mental era puțin ciudat, dar era un singur model mental. Petzold l-a explicat. Era F=MA al Windows. Simplu. Puternic. Îl învățai. Îl foloseai. Aveai succes.

Claritatea îți este prietenă! Un sistem de operare, un API, un limbaj, o carte. Nu exista niciun comitet care să dezbată alternativele la cod gestionat. Existau doar Win32 și Petzold, și funcționa. Aceasta era fizică, nu chimie (funcționează, dar numai pentru această porțiune a tabelului periodic. Și numai sub aceste presiuni. Și numai în limita acestei temperaturi. Și numai dacă Luna se află în casa a 7-a a lui Jupiter).

Ceea ce s-a întâmplat apoi a fost o lecție de măiestrie despre cum o companie cu oameni străluciți și resurse enorme poate produce o poveste de treizeci de ani, optimizând pentru lucrurile greșite. Adică oameni străluciți care fac lucruri stupide.

Abordarea orientată pe obiecte (1992–2000)

Win32 avea limitări reale, așa că Microsoft a făcut ceea ce face Microsoft: a lansat ceva nou pentru conferința dezvoltatorilor. Mai multe lucruri.

MFC (1992) a integrat Win32 în C++. Dacă Win32 era neelegant, MFC era Win32 purtând un smoking făcut din alte smokinguri. Apoi au apărut OLE. COM. ActiveX. Niciunul dintre acestea nu era cu adevărat framework-uri GUI – erau arhitecturi de componente – dar au infectat fiecare colț al dezvoltării Windows și au introdus un nivel de complexitate cognitivă care îl face pe Kierkegaard să pară Hemingway.

Jeffrey Snover a stat la o sesiune de conferință la sfârșitul anilor nouăzeci încercând să înțeleagă diferența dintre un document OLE, un obiect COM și un control ActiveX.

Microsoft nu vindea o poveste coerentă. Vindea tehnologii primitive și le spunea dezvoltatorilor să-și dea seama singuri de poveste. Acesta este grupul de discursuri principale pentru conferințe – optimizat de Microsoft pentru un director care impresionează oamenii cu discursul său principal și nu cu succesul utilizatorilor sau dezvoltatorilor.

PDC 2003 și viziunea care s-a autodistrus

La PDC 2003, Microsoft a dezvăluit Longhorn – cu adevărat una dintre cele mai convingătoare viziuni tehnice pe care compania le-a prezentat vreodată dezvoltatorilor. Trei piloni: WinFS (un sistem de fișiere relațional), Indigo (comunicații unificate) și Avalon – mai târziu WPF – un subsistem UI bazat pe vectori, accelerat de GPU, condus de un limbaj XML declarativ numit XAML. Dezvoltatorii au văzut demonstrațiile Avalon și au înnebunit. Era viziunea corectă.

De asemenea, era, în cuvintele notei interne a lui Jim Allchin din ianuarie 2004, „o nebunie”.

Până în august 2004, Microsoft a anunțat o resetare completă a dezvoltării. Renunțare. O luare de la capăt de la baza de cod Server 2003. Și după resetare, conducerea a emis o directivă discretă: fără cod gestionat în Windows. Tot codul nou în C++. WPF urma să fie livrat odată cu Vista, dar shell-ul în sine nu îl urma să îl folosească.

Amărăciunea echipei Windows față de .NET nu s-a vindecat niciodată. Din perspectiva lor, pariul pe un nou framework cu cod gestionat al produsului a fost cel mai jenant eșec din istoria companiei. Această amărăciune a creat un război civil instituțional de treisprezece ani între echipa Windows și echipa .NET, care în cele din urmă avea să lase WPF orfan, să distrugă Silverlight, să condamne UWP și să ne ofere ecosistemul GUI de-a dreptul spectaculos pe care îl avem astăzi.

Silverlight: Modelul stabilit (2007–2010)

WPF a fost lansat la sfârșitul anului 2006. A fost remarcabil – XAML, randare accelerată hardware, legare reală a datelor. Dacă Microsoft ar fi făcut din acesta răspunsul definitiv și ar fi investit neobosit, povestea s-ar fi putut termina diferit.

În schimb, în ​​2007, au lansat Silverlight: un plugin de browser simplificat pentru a concura cu Flash, multiplatformă, elegant și fundamentul pentru Windows Phone. În jurul anului 2010, părea viitorul.

Apoi, la MIX 2010, un director Microsoft a spus într-o sesiune de întrebări și răspunsuri că Silverlight nu era o strategie multiplatformă – era vorba despre Windows Phone. HTML5 era acum o politică. Echipa Silverlight nu a fost anunțată că acest lucru va veni. Dezvoltatorii care își pariaseră aplicațiile LOB pe Silverlight au aflat în urma unei sesiuni de întrebări și răspunsuri la o conferință.

Silverlight nu a fost ucis de o defecțiune tehnică. Tehnologia era bună. A fost ucisă de o decizie strategică de afaceri, iar dezvoltatorii au fost ultimii care au aflat.

Țineți minte acest tipar. Îl vom vedea din nou.

Panica Metro și Războiul celor Două Echipe (2012)

Apple vânduse 200 de milioane de iPhone-uri. iPad-ul eroda vânzările de PC-uri. Răspunsul Microsoft a fost Windows 8 și Metro – un runtime tactil numit WinRT, care nu a fost construit în mod deliberat pe .NET. Vă amintiți de amărăciunea echipei Windows? Aici se manifestă. WinRT era un runtime nativ C++. O ruptură categorică de la WPF, WinForms și un deceniu de investiții ale dezvoltatorilor în .NET.

De fapt, în cadrul Microsoft se spuneau două povești simultan. Echipa Windows construia WinRT. Echipa .NET încă promova WPF. Clădiri diferite, vicepreședinți diferiți, foi de parcurs diferite.

Ce au auzit dezvoltatorii la //Build 2012: viitorul este WinRT, și HTML+JS este de primă clasă, și .NET încă funcționează, și C++ a revenit, și ar trebui să scrieți aplicații Metro, iar codul WPF încă rulează bine. Aceasta nu este o strategie.

Dezvoltatorii de companii au analizat sandboxing-ul UWP, cerințele de implementare a magazinului și API-urile Win32 lipsă și au plecat. Framework-ul conceput pentru a-i aduce în era modernă fusese optimizat pentru un magazin de aplicații pentru tablete care nu s-a materializat niciodată.

UWP și extinderea WinUI (2015–prezent)

Windows 10 a adus Platforma Universală Windows – o singură utilizare, rulare pe PC, telefon, Xbox, HoloLens. Convingător pe hârtie. Problema: Windows Phone era pe moarte, iar aplicațiile emblematice ale Microsoft – Office, Visual Studio, shell-ul în sine – nu foloseau UWP. Mesajul era clar, chiar dacă nimeni nu l-a spus cu voce tare.

Când UWP s-a blocat, răspunsul oficial a fost că depinde. Folosește UWP pentru aplicații noi, păstrează WPF pentru cele existente, adaugă API-uri moderne prin insule XAML, așteaptă WinUI 3, dar există și WinUI 2 special pentru UWP, iar Project Reunion va rezolva totul, cu excepția faptului că îl redenumim Windows App SDK și tot nu înlocuiește complet UWP și…

Project Reunion / WinUI 3 reprezintă un progres autentic. Dar întreabă-te de ce a existat problema. Controalele UWP erau legate de sistemul de operare, deoarece echipa Windows le deținea. Echipa .NET nu. Echipa de instrumente pentru dezvoltatori nu. Project Reunion a fost o soluție organizațională deghizată în soluție tehnică.

„Am urmărit schimbările constante ale Microsoft: UAP, UWP, C++/CX înlocuit de C++/WinRT fără suport pentru instrumente, insule XAML, XAML Direct, Project Reunion, repornirea WinAppSDK, trecerea haotică între WinUI 2.0 și 3.0…” – rezumatul unui dezvoltator, scris în 2024

Paisprezece ani. Paisprezece schimbări de direcție. Acea persoană merită o medalie și scuze, în această ordine.

Grădina Zoologică fără îngrijitor

Iată toate tehnologiile GUI livrate astăzi pe Windows:

Framework-uri native Microsoft

• Win32 (1985) – Încă aici. Încă folosit. Cartea lui Petzold este încă valabilă.
• MFC (1992) – wrapper C++ pe Win32. Mod de întreținere. Există în mediul enterprise și CAD.
• WinForms (2002) – wrapper .NET pe Win32. „Disponibil, dar descurajat.” Încă cel mai rapid pentru formularele de introducere a datelor.
• WPF (2006) – XAML, randat cu DirectX, open source. Fără o nouă investiție Microsoft.
• WinUI 3 / Windows App SDK (2021) – Răspunsul „modern”. Foaie de parcurs incertă.
• MAUI (2022) – Succesorul multi-platformă al Xamarin.Forms. Pariul actual al echipei .NET.

Microsoft web-hybrid

• Blazor Hybrid – Componente .NET Razor într-un WebView nativ.
• WebView2 – Încorporează Chromium într-o aplicație Win32/WinForms/WPF.

Terți

• Electron – Chromium + Node.js. VS Code, Slack, Discord. Cea mai răspândită tehnologie GUI pentru desktop pe Windows în acest moment – ​​iar Microsoft nu a avut nicio legătură cu ea.
• Flutter (Google) – Dart, renderer personalizat, multiplatformă.
• Tauri – Backend Rust, alternativă ușoară la Electron.
• Qt – C++/Python/JavaScript. Opțiunea serioasă multiplatformă.
• React Native pentru Windows – Portare susținută de Microsoft a framework-ului mobil al Facebook.
• Avalonia – Succesorul spiritual open source al WPF. Folosit de JetBrains, GitHub, Unity – dezvoltatori care au încetat să mai aștepte Microsoft.
• Uno Platform – API-uri WinUI pe fiecare platformă. Mai dedicați decât Microsoft.
• Delphi / RAD Studio – Încă în viață. Încă rapid. Încă pe piața de software.
• Java Swing / JavaFX – Da, încă în producție. Întreprinderea nu uită niciodată.

Șaptesprezece abordări. Cinci limbaje de programare. Trei filozofii de randare. Aceea nu este o platformă.