Silverlight – przepis na kiepską kopię umierającej technologii

Podczas instalacji starszych wersji Windowsów, lub podczas aktualizowania programu Internet Explorer, istniała możliwość wyboru instalowanych komponentów (przypominam, że żyjemy w czasach, w których owa opcja jest jedynie odległym wspomnieniem). Domyślnie zaznaczonymi elementami zawsze były kontrolki COM dla „Macromedia Shockwave” i „Macromedia Shockwave Flash”. Dzięki temu system był zaopatrywany we wtyczkę ActiveX dla Flasha w wersji 5 lub 6 (aktualizowanej na żądanie, gdy jakaś strona zażyczy sobie nowszą wersję), co było niezbędne, ponieważ przez wiele lat przeglądanie „bogatych” i „multimedialnych” treści w internecie wymagało Flasha i nie było z tym żadnej dyskusji.

Drugim takim gniotem, również instalowanym bezpośrednio przez Microsoft, była moja ukochana Java. Wynikało to z prostego, acz niespodziewanego dla marketingowców faktu: HTML, nawet z JavaScriptem i kolejnymi warstwami, jak XML, VBS, CSS i „DHTML”, nie nadaje się do zbudowania interaktywnej aplikacji multimedialnej. Podobnie, jak w filmie „Zakazana Planeta” z 1956 (i jednej z nielicznych poważnych ról Lesliego Nielsena), w którym brak cyfrowych efektów specjalnych zastąpiono animacjami, braki w HTML zamieciono pod dywan, uruchamiając oddzielną aplikację warstwę wyżej. Tą aplikacją był renderer Flash, rysujący kod absolutnie niepodobny do HTML. Ale wszystko jest przecież OK, tak długo, jak tytuł okna brzmi „Microsoft Internet Explorer”.

Flash od zawsze był niebezpieczny i pełen dziur. Zawsze wywoływał zadyszkę w układach chłodzenia laptopów. I zawsze wywoływał on to bolesne, głębokie przekonanie, że to wszystko musi się dać zrobić inaczej. Dopiero Steve Jobs, nie umiejąc sobie poradzić z drenażem baterii, nakazał Flashowi umrzeć. Ów głos Apple zapewne sprawił, że wszyscy powinni byli odetchnąć z ulgą, ale polityka rozszerzenia błędnie implementowanych standardów o własnościowe, ciężkie binarne bloby była rdzennym dogmatem innego gracza na rynku IT, czyli dawnego Microsoftu.

A więc gdy świat coraz częściej rozglądał się za alternatywami, Microsoft zapragnął mieć własnego Flasha. Był to ostatni z wielkich, monolitycznych i skazanych na porażkę projektów owej firmy. Wkrótce potem nastąpił bowiem odwrót w stronę masowej kompatybilności. I mimo, że „Flash od Microsoftu” był faktycznie ostatnim z pomysłów w dawnym duchu, jego istnienie i tak zaskakuje, bowiem już wtedy powinno było być jasne, że „to się nigdy nie przyjmie”. Przypomnijmy więc na chwilę Silverlighta.

Silverlight. Po co to komu?

Silverlight to, odcinając marketingowy bełkot, niewiele ponad „zróbmy to samo, co Flash, ale zepnijmy zaplecze techniczne ze wszystkimi naszymi zabawkami!”. Nazwa kodowa "WPF Everywhere" brzmi zuchwale i zachęcająco, ale w praktyce nie jest to wcale czarodziejsko przenośny WPF, a znacznie, znacznie mniej. Owszem, byłoby naprawdę dziwne, gdyby Microsoft nie podjął próby zbudowania czegoś, co bezpośrednio konkuruje z Flashem. Z tym, że właściwym momentem na Silverlight był mniej więcej rok 1999 i okolice. Wtedy jednak programistyczne zabawki, jak .NET i XAML były w powijakach… No ale znów, gdy owe technologie dojrzały, na Silverlighta nie powinno już być miejsca. No więc co teraz? Przyznać się do błędu? Powiedzieć na głos, że istnieje nierozwiązany od niemal dekady problem brakującej technologii? Poprawiać dotychczasowe implementacje, a może promować otwarte standardy? Ależ skąd. Należy udawać, że wszystko jest w porządku i forsować projekt dalej.

Żeby zrozumieć, czym jest Silverlight, trzeba pamiętać, czym jest Flash. Narzekanie na Flasha jest, jak żarty o płodach, zawsze na miejscu, ale niestety trzeba się pogodzić z faktem, że jego powstanie i długa kariera były uzasadnione i niezbędne. Bowiem Silverlight to nie jest tzw. „me‑too attempt” względem Flasha. To coś niewątpliwie inspirowane owym rozwiązaniem, ale mocno rozbudowane w obszarach, w których Flash niedomagał. A w których to z racji braku alternatyw, był wykorzystywany. Otóż Flash tworzył aplikacje, istnieje do niego IDE, znane jako Flex Builder, oferujące środowisko programowania. Pierwsze lepsze gry Flashowe to event-driven aplikacje o wektorowym interfejsie, a Adobe Flash pełni w nich rolę środowiska runtime (proszę nie wspominać w tym momencie ani słowem o Adobe Air!). Wskutek masowego oszustwa, komponenty Flash w powszechnej wyobraźni funkcjonowały jako elementy strony internetowej. Tymczasem równie dobrze mogłyby działać jako samodzielne instancje, zupełnie poza przeglądarką. Nie był to rzadki zabieg, strony internetowe często ładowały np. kontrolkę ActiveX dla Windows Media, żeby odtwarzać dźwięk w tle. Jakoś nie funkcjonowało w powszechnej wyobraźni technicznej przekonanie, że to sam HTML+JS może być platformą dla treści multimedialnych. Milcząco zakładano, że strony internetowe to jednak coś, co powinno się dać otworzyć w Notatniku i parsować gołym okiem. (Prawdopodobnie to myślenie jest powodem, dla którego cache przeglądarki IE można przeglądać eksploratorem jak zwykły katalog) Musiało upłynąć wiele lat, i wiele binarnych, skompresowanych skryptów JS, by to myślenie się zmieniło. Najwyraźniej jednak nie zmieniło się u wszystkich, co widać po silverlightowym wpychaniu WPFa w stronę internetową…

Flash pełnił też inną rolę, w której wyraźnie niedomagał dotychczasowy RealPlayer/Windows Media Player. Był bowiem odpowiedzialny za transmisje strumieniowe, w jutubowym formacie FLV. Co ciekawe, FLV był całkiem niezłym, porządnie kompresującym się formatem. Na początku XXI wieku był w praktyce jedynym używanym mechanizmem strumieniowania multimediów, zanim w ogóle ktokolwiek słyszał o YouTube. Microsoft miał swoją platformę multimediów, ale przegrywała z konkurencją. As w rękawie (DivX 3) został ukradziony, a Windows Media Services 9 nie umiało się przebić. Silverlight miał rozwiązać ten problem, oferując transmisję strumieniową w HD o wysokiej kompresji. Obiecywano, że komputery przestaną płonąć podczas odtwarzania cięższych filmów z sieci, co miało miejsce w przypadku FLV.

Do Silverlighta dołączono środowisko programowania. Było ono kompletnie odmienne od Flex Buildera i ActionScriptu, ale na odległość było widać, że zbiór „Microsoft Expression” zaprojektowano do konkurowania z rozwiązaniami Adobe. Osoby zaznajomione z tworzeniem interfejsów WPF mogły bez większego przeszkolenia zmienić typ swojego projektu w Visual Studio i w mig zamiast aplikacji na pulpit tworzyć aplikację Silverlight. Zalecane było jednak używanie wspomnianych zestawów Microsoft Expression. Dzięki owym narzędziom nie istniała konieczność instalowania .NET Framework, a tak stworzona aplikacja stawała się „przenośna”. To oczywiście bzdura, bowiem klient Silverlight wydano tylko na Windows, a Windows Update dawno na każdym komputerze zainstalował pakiet .NET Framework, więc zaleta z tego żadna.

Sama możliwość uruchamiania multimedialnych aplikacji .NET z przeglądarki była pośrednim dowodem na to, że w Microsofcie istnieje, często przeze mnie przywoływany, zbiór wzajemnie wrogich sobie obozów. Jestem przekonany, że założenia funkcjonalne Silverlighta były na roadmapie ludzi od ASP.Net. Musiało tak być. Te projekty wcale się nie dopełniają, wyglądają za to jak efekty oddzielnie prowadzonych prac w wykonaniu zespołów, które nie mają pojęcia o swoim istnieniu.

Jestem świadom, że rok 2007 to dopiero początek eksplozji mobilnej i świat nie uciekał jeszcze w panice od ciężkich technologii desktopowych. Trwała dopiero masowa migracja z blaszaków na laptopy. Ale trendy mobilne nie były wtedy aż tak egzotyczne, żeby nie wyczuć bezsensu w inwestowaniu w alternatywę dla Flasha. Był to jednak typowy Microsoft – to podręcznikowa zagrywka firmy, która notorycznie nie ma pojęcia, co się wokół dzieje. Podam przykład: od czasu InterDev i oryginalnego ASP, istniała w Redmond silna grupa promująca aplikacje czysto w wersji Web: bez COM, za to z VBS. Jednym komponentem branym z systemu było uwierzytelnianie domenowe, ale powiedzmy sobie szczerze, że sieć typu Active Directory aż się prosi o SSO w aplikacjach webowych, więc to jest w pełni wybaczalne. Jednak obok prac nad ASP toczyły się prace nad ukochanym środowiskiem Visual Basic, forsującym wykorzystywanie kontrolek ActiveX, osadzanych na stronach internetowych. Zbluźnię tutaj i powiem, że pomysł na ActiveX generalnie bardzo mi się podoba: oto mamy program, który potrzebuje jakiejś małej funkcji w systemie – jeżeli jej brakuje, to dociąga sobie z sieci komponent i uzupełnia system o brakującą funkcjonalność. To doskonały pomysł. Ale absolutnie nie do stosowania w stronach sieci Web. Samo istnienie ActiveX w Internet Explorerze to nic ponad syndrom odstawienny myślenia „wymyślmy cały internet od nowa”. Gdy nie udało się skopiować jakiejś technologii, należało ją boleśnie najeżyć wstawkami z własnego garażu. Dlatego ActiveX pasuje do stron WWW jak siodło do krowy. Microsoft uparcie nie był w stanie tego zrozumieć. Gdy wydano ASP.Net i tworzenie czysto webowych aplikacji stało się łatwiejsze, niż kiedykolwiek wcześniej, ktoś znowu napił się z fontanny „ej, a zróbmy to gorzej i dziwniej!” i wymyślił ClickOnce. Czyli niby mamy platformę do aplikacji webowych, ale zróbmy jednocześnie jakiś mechanizm strumieniowania aplikacji EXE do komputerów klienckich, bo wykorzystywanie Zasad Grupy do instalowania oprogramowania jak normalni ludzie jest głupie. Należy osiągnąć to samo, ale najpierw obowiązkowo uruchomić Internet Explorer, ściągając na siebie wszystkie idące za tym ograniczenia i ułomności. No na litość boską!

Wspomniany przed chwilą ActiveX z definicji nie pasował do stron WWW, ale Flash był przecież dokładnie tym samym: kontrolką ActiveX. Po prostu technologia nie nadążała za wymaganiami: ludzie chcieli JEDNOCZEŚNIE multimediów i internetu, więc tworzono aplikację multimedialną i przybijano ją gwoździem do kodu HTML, mówiąc ludziom, że to strona internetowa.

Tymczasem klęska Internet Explorera i kariera Firefoksa doprowadziła do wznowienia prac nad jakąkolwiek innowacyjnością w internecie. Konsorcja WWW i organizacje standaryzacyjne przypomniały sobie o swoim istnieniu, pojawiły się kolejne wersje ECMAScriptu, rodziły się fantastyczne wynalazki, jak WebM, WebGL, WebSockets, do kompletu z odmienianym przez wszystkie przypadki „Web 2.0” (zwrot nieodmienny). Microsoft więc jak na dłoni mógł zobaczyć, że próby sprzedawania aplikacji „internetowych” wymagających tak naprawdę systemu Windows, nie mają przyszłości. I nawet Jobs i jego straszenie baterią nie miałyby tu znaczenia. Microsoft jednak zupełnie nie czuł, w którą stronę wieje wiatr i wydał na świat cudaczny Silverlight.

Czasem mam wrażenie, że projekt po prostu kosztował za dużo pracy i wstyd było go anulować. Liczono może na jakąś formę inercji, dostarczającej popularności. Podejrzewam, że na tej zasadzie IBM rozwijał swój OS/2. Ale czy to wystarczyłoby do wydania oddzielnego Visual Studio i dobicia aż do pięciu głównych wersji? Coś musiało jednak pójść dobrze, skoro projekt trochę pożył. Owszem – istniały dwa obszary, na których Silverlight nie był ostentacyjnie chybionym projektem.

Pierwszy z nich to Windows Phone 7. Tutaj spisywał się doskonale. Tworzenie aplikacji na Windows CE i jego dziwny nad‑zbiór Windows Mobile było trudne i wymagało fachowej wiedzy. Dlatego, aby odnieść sukces na rynku mobilnym, konieczna była zmiana. Nie można było użyć rozwiązania konkurencji, jakim była Java. Nie dlatego, że Microsoft nie lubił Javy – lubił ją wręcz za bardzo i dołączając ją do systemu oraz sprzedając własne kompilatory tego języka (!) podpadł pod kilka pozwów. Pozostał C#. Na szczęście programować w ce‑płotku potrafi każdy pacan, więc krótkie doszkolenie się z Siverlighta nie było czymś szczególnie bolesnym dla programisty .NET. Z tym, że nikt nie używał Windows Phone 7. Osoby, które posiadały taki telefon, niemal zawsze dostawały go przez przypadek, albo poza swoim udziałem. Tworzenie aplikacji na WP7 było krańcowo nieopłacalną stratą czasu, a sam system miał problemy z tożsamością: Silverlight był jedynym runtimem tego środowiska, ale już Internet Explorer Mobile nie miał pojęcia, co to jest Silverlight i oferował pobranie paczki instalacyjnej EXE. Stąd okazywał się idealnie dobraną technologią do kompletnie nieistotnego produktu. Któremu w dodatku z biegiem czasu udało się upaść jeszcze niżej.

Drugim obszarem, w którym Silverlight odniósł sukces, było strumieniowanie wideo, ze szczególnym naciskiem na strumieniowanie chronione przed kopiowaniem. Microsoft oczywiście posiadał gotowe rozwiązanie tego typu, było nim przecież Windows Media, ale pewnego dnia kazano zespołowi Windows Media przestać pracować, dzięki czemu nowa wersja serwera strumieniowania Windows Media Services nigdy nie powstała. Zamiast tego zalecano wykorzystywanie IIS Smooth Streaming, serwującego strumień w formacie DRM Silverlight. I był to autentyczny sukces. Nie tylko wizerunkowy, jak podczas transmisji Olimpiady 2008, ale również branżowy. Cały Netflix stał na Silverlight’cie, a polskie portale z serialami dla Grażyn również serwowały swój content właśnie w ten sposób. Silverlight odniósł więc sukces w swoim stylu – demolując i niwecząc poprzednią technologię, osiągając przy okazji wyniki będące ułamkiem oczekiwań.

Wreszcie przyszedł Windows 8. I Windows Phone 8. Oba wprowadziły myślenie prawdziwie webowe, które jakims cudem (niespodzianka!) jednak dało się połączyć z całym stosem .NET, bez konieczności ładowania nieprzenośnej, niestandardowej zarazy. Obwieszczono, że Silverlight nie będzie miał następcy. SDK dla Windows Phone nie było już ani trochę oparte o Silverlight, Visual Studio dalej oferowało mocne wsparcie dla owej technologii, ale było już jasne, że nic z tego nie będzie. Silverlight zaczął się zwijać i w Polsce wierzgał jeszcze przez kilka miesięcy na portalach VOD, które nie umiejąc zmigrować na HTML5, zmuszały użytkowników bezwtyczkowego już Chrome’a do instalacji Firefoksa. Obecnie Silverlight jest niemożliwy do użycia: Chrome, Firefox i Edge w ogóle nie obsługują wtyczek ActiveX lub Netscape Plugin. Jedną metodą dostania się do treści stworzonych w Silverlight jest wykorzystanie przeglądarki Internet Explorer, która ostatnią aktualizację otrzymała w 2013 roku.

Najnowszy Visual Studio 2017, który ma premierę za kilka dni, nie obsługuje już Silverlighta. Wsparcie dla Silverlight zostanie zakończone w 2019 roku. Mam szczerą nadzieję, że Windows Update przestanie oferować owego potwora na liście Opcjonalnych Aktualizacji.

A na dobranoc zwiastun innego tematu, w sam raz dla tych, którzy twierdzą, że nawet Silvelight był zbyt mainstreamowy ;)

PS

Jestem też bardzo ciekaw, czy ktoś z czytelników miał jakikolwiek poważny kontakt z Silverlightem. Zapraszam do dyskusji.