Dajmy już sobie spokój z UWP. I ze sklepem Microsoft Store też

Jednak z rewolucjami w Windows jest jak z końcem świata: ogłasza się go niemal co chwilę, wszyscy z niecierpliwością na niego czekają, licząc na ulgę, a on uparcie nie chce nadejść, zmuszając do życia kolejny dzień w świecie, który trzeba dzielić ze spoconymi ludźmi w autobusie, muzyką disco polo i Kumulatywnymi Aktualizacjami pakietu Adobe Flash Player. Mimo wielokrotnych ogłoszeń, przełom nie następuje. A ponieważ tychże nowych technologii ktoś jednak używa, argument że okazały się porażką jest przyjmowany z trudem lub odrzucany. I nie chodzi tu tylko o Windows 10. Ani nawet o Windows 8. Tę samą historię przeżywał sam .NET Framework i jako żywo pamiętam, jak ogłaszano, że bliżej nieokreślona, „przyszła” wersja Windows będzie „napisana” właśnie w nim. Nie chodzi o to, że to niemożliwe, bo .NET wymaga maszyny wirtualnej, więc raczej trudno w nim napisać cały system, a o to, że popularyzacja platformy przebiegła w stopniu znacznie niższym, niż początkowo zakładano.

Nie można powiedzieć, że .NET okazał się klęską. Przez ostatnie dwadzieścia lat w języku C♯ powstała niezliczona ilość aplikacji. Znajomość .NET to solidna, poszukiwana umiejętność na rynku pracy, a samo środowisko uruchomieniowe jest niezwykle rozbudowane. C♯ stał się standardem ECMA i jeszcze wiele lat przed uwolnieniem jakoopen source powstały jego alternatywne implementacje. Jedna z nich – Mono – wciąż pełni ważną rolę i zasila wnętrze środowiska Xamarin, choć należy się spodziewać, że z biegiem czasu jednak zniknie.

Niemniej, Windows nie został przepisany do .NET, podobnie, jak wcześniej jego GUI nie zostało przepisane do HTML/JS (co obiecywał Internet Explorer 4). Plan maksimum nie został zatem zrealizowany. Jednak ze względu na przebojowy sukces .NET na rynku, słowa „.NET był porażką” nie są dobrze przyjmowane i bardzo łatwo argumentować, że są błędne. Mocno utrudnia to dyskusję. Tym bardziej, że dorzuca się w niej szereg pozornie trafnych, ale w praktyce nieistotnych argumentów. W kwestii .NET FX 3.0 i Avalon była mowa o tym, że brak eksplozji popularności to wina anulowania projektu Longhorn i wyrzucenia kilku lat prototypowania do kosza.

Paralele między .NET a dzisiejszą dyskusją dotyczącą Windows 10 i UWP są uderzające. Dziś jako wymówkę braku popularyzacji UWP stawia się klęskę na polu mobilnym: po co komu uniwersalne aplikacje, skoro nie ma telefonów z Windows, a tablety w ogóle wymarły? Jednocześnie, wiele osób burzy się na słowa o niepowodzeniu UWP mówiąc, że przecież powstało mnóstwo aplikacji uniwersalnych, i choć stanowią mniejszość, jest to i tak ilość nie do pominięcia. Ale dlaczego mówimy o .NET, a nie o Windows 10? Ano dlatego, że konieczne jest dogłębne wytłumaczenie powodów niedoszłej rewolucji i .NET pełni rolę doskonałego przykładu.

Ogłoszony w maju .NET 5.0 ma na celu zamknięcie luki między starym Frameworkiem a nową, otwartą i wieloplatformową wersją .NET Core. Rozbieżność ta, w postaci braku wymienności kodu, bywała bolesna. Z poziomu starego .NET FX nie da się robić nowych rzeczy z Core, a w Core nieosiągalne są niektóre rzeczy z FX, szczególnie te skoncentrowane ściśle na Windows. Brakowało też innych rzeczy. Sam natknąłem się na brak obsługi scaffoldingu Entity Framework dla projektów ASP.NET w języku Visual Basic (oczywiście wszystko da się napisać ręcznie), ale normalni ludzie trafiali na poważniejsze, mniej kosmiczne problemy. Nowy .NET 5.0 ma docelowo pojawić się jako wbudowane API w Windows i egzystować na równi z CLR 3.5 i 4.8.

Prawdziwy przełom czeka jednak za rogiem i nie jest nim wersja 5, a wersja 3. „Piątka” będzie raczej porządkowaniem ścieżek serwisowych. Mimo nowych funkcji, będzie mniej rewolucyjna, niż 3.0. W nadchodzącej „trójce” możliwe jest wykorzystanie Windows Forms (lol) oraz WPF. Możliwe jest też łączenie dwóch różnych światów: korzystanie z kontrolek UWP wewnątrz formatkowych aplikacji klasycznego pulpitu WPF. Pomieszanie obu API jest możliwe w ramach funkcji XAML Islands 1.0, dostępnej w systemie Windows 10 w wersji 1903. Dzięki temu, programiści chcący wykorzystać zalety UWP (a jest ich niemało!), nie muszą przepisywać całej swojej klasycznej aplikacji na WinRT i jeszcze dodatkowo celować w inny Framework. Wystarczy bowiem zaciągnąć NuGetową paczkę Microsoft.Toolkit.Wpf.UI.XamlHost i (ignorując kwestię tego, ile runtime'u trzeba dorzucić do programu, żeby dało się do uruchomić gdzie indziej) możliwe staje się wykorzystywanie kontrolek UWP w projekcie o bardziej klasycznie pulpitowym kodzie.

No ale przecież to dobrze, prawda? Mniej sztucznych ograniczeń i większa władza oddawana w ręce deweloperów. Da się stworzyć więcej za mniej i to wykorzystując UWP! Toż to sukces, progres, awans i rozwój. Zdecydowanie nie porażka ani klęska UWP, jak wielu twierdzi – czyż nie?

Ano nie. Zamknięcie kontrolek, funkcjonalności i klas UWP w oddzielnych projektach, niedostępnych z poziomu starego API, nie było decyzją ideologiczną. Brak możliwości wykorzystania UWP poza projektem Aplikacji Uniwersalnych, trwający wiele lat, to nie światopoglądowy upór, nieprzejednane trwanie w głupocie i brak umiejętności przyznania się do błędu. Oba wyżej wymienione rodzaje aplikacji celowo miały się nie mieszać, na przykład z powodu bezpieczeństwa i ułatwienia zarządzania pakietami. Gdyby nie istniało ryzyko zmarnowania zalet integralności WinRT, wszystkie nowe kontrolki po prostu dorzuconoby do już istniejącego toolboksu WPF i nikt nie przejmowałby się takim sztucznym podziałem. Problem w tym, że ten podział wcale nie był sztuczny. Zrezygnowano z niego, bo nikt (jest to oczywiście „nikt” z gwiazdką) się do niego nie stosował.

I powodem tego wszystkiego była klęska Windows Phone, tak? Przecież wcale nie o to chodzi. Wystarczy trochę popatrzeć na wykresy serwowane przez Gemiusa, w tym historyczne. Głównym powodem nieużywania UWP nie był brak popularności Windows Mobile, a nadmiar popularności Windows 7. API Windows 8 nie zostało przeportowane w dół. Tymczasem .NET Framework wydano nawet na Windows 98, a Windows Vista otrzymał aktualizację KB2117917, która dorzucała API z Siódemki. Owszem, Windows 8 miał być rewolucją i dodanie API do poprzednich wersji byłoby bardzo drogie i trudne. A przecież Windows 8 był płatny! Dopiero 8.1 i 10 były darmowe, ale aktualizacja do nich odbywała się nierzadko wysokim kosztem jakościowym, co dość mocno zniechęcało.

Po co tworzyć aplikacje dla systemu, którego wiele osób nie chce, skoro można stworzyć taką, która działa na każdym? To myślenie, w świecie aplikacji mobilnych i wzrostu popularności alternatywnych OS-ów, doprowadziło do popularyzacji formatu Electron. Framework Electron.js dostarcza wszystkie zalety, które obiecywał UWP, a w dodatku robi to za darmo i na więcej platform. Robi to źle, ciężko, brzydko, niebezpiecznie i powoli. Ale docelowo skutecznie. I dlatego się przyjął. Wie o tym nawet Microsoft: Skype, Teams (to jest dopiero okropność!) oraz nowa aplikacja XBox to wszystko kontenery Electrona. Bowiem zamiast tworzyć wersje Skype'a dla Windows 7, Linuksa, macOS i Windows 10, lepiej stworzyć jedną.

Jak wobec tego wytłumaczyć przenoszenie na Electrona aplikacji, które będą działać wyłącznie na Windows 10? Są dwie hipotezy: pierwsza jest taka, że na rynku brakuje specjalistów od UWP, a od JS jest ich aż nadto. Druga jest gorsza: framework UWP jest niewystarczający i nie nadaje się do cięższych zastosowań. Biorąc pod uwagę niską jakość wbudowanych aplikacji Windows 10, nie jest to aż tak nieprawdopodobne. Aczkolwiek bardziej chyba chodzi o wariant numer 1, z brakiem fachowców. Patrząc na to, jak działa i gdzie instaluje się Microsoft Teams, z powodzeniem można założyć, że naprawdę bardzo mocno brakuje specjalistów i nawet w samym Microsofcie trudno o inżynierów umiejących zaimplementować wytyczne pochodzące właśnie z Redmond. Tymczasem Teams nie jest nawet dostępne w Sklepie Windows.

Sklep wszak też zwiędnie. Jego porażkę jednak ponownie wiele osób usiłuje sprzedać jako sukces, podobnie, jak „sukcesem” miało być UWP. Sklep odnosił same porażki sprzedawane jako sukcesy. Najpierw dodano do niego aplikacje desktopowe, twierdząc, że dzięki konteneryzacji, sandboksowaniu i możliwości używania kafelkowego UI one też są „aplikacjami UWP”. Następnie usunięto z niego aplikacje pochodzące z Redmond (Office i Teams). Wreszcie, wydzielono mechanizm bezpiecznej konteneryzacji serwisowej do oddzielnej funkcji, w postaci pakietów MSIX. Zatem Sklep odniósł kolejne zwycięstwo: jego format pakowania aplikacji może być wykorzystany również w Windows 7 oraz starszych wersjach Dziesiątki. Sukces! Większa dostępność, więcej władzy w rękach programistów, rozwój platformy! I tak dalej...

Dla kontrastu przypomijmy: Poprzednie wersje pomysłów na to samo zostały przez Microsoft udostępnione dla starszych wersji: Internet Explorer działał nawet na Windows 3.1. Framework .NET opublikowano dla Windows 98. Mechanizm Instalatora Windows (MSI), wprowadzony w Windows 2000, został udostępniony również na Windows 95. Jest dziś produkt, który poprawnie wdraża swoje komponenty jako platformę na różne systemy. Jest nim Google Chrome. Używa do dziś pół polskiego internetu.

Microsoft może zmieniać definicję pakietu UWP i twierdzić, że platforma ta się rozwija. Może również promować konteneryzację i wmawiać nam, że Sklep dalej ma sens (Windows Terminal niedawno się na nim pojawił). Ale nie zmienia to faktu, że Windows 10 zostaje coraz mocniej rozmontowany, zresztą zgodnie z przewidywaniami sprzed pół roku. Pozostaje czekać, aż z obrazka znikną również kafelki. To niewątpliwie nastąpi i to już niedługo. Być może wraz z zadumą „co nam w sumie nie pasowało z tym Windows 7...?”. Wystarczy jeszcze kilka takich „sukcesów”, jak te wyżej wymienione. 😉