Jak Microsoft chciał przejąć sieć Web – historia Internet Explorera, część IV

Dla ludzi pamiętających, jak nieskutecznie, powoli i wadliwie uruchamiał aplikacje internetowe szacowny Internet Explorer 6.0, powyższe stwierdzenie może uchodzić za herezję. Da się je jednak obronić za pomocą twardych dowodów i przytoczyć trzy zaskakujące przykłady. Zacznijmy od najważniejszego.

Wspomnianym elementem jestobsługa wewnątrz-procesowego serwera dla instancji klasy o identyfikatorze ED8C108E-4349-11D2-91A4-00C04F7969E8, zawarta w bibliotece w „XML Object Model for Win32”. Wyżej wymieniona „klasa” nosi na szczęście również wewnętrzną nazwę, która powinna już brzmieć zdecydowanie mniej odstręczająco. Brzmi ona bowiem „XmlHttpRequest”. A to przecież serce technologii AJAX i w praktyce fundament całego Web 2.0, bez którego dzisiejsze aplikacje internetowe nie miałyby racji bytu.

Formant obsługi interfejsu IXMLHTTPRequest powstał, bo Microsoft bardzo chciał używać przeglądarki internetowej jako klienta Exchange, a więc do zadania do którego z definicji kompletnie się nie nadawała. Cel miał zostać osiągnięty bez dodatkowych wtyczek. A przecież cała koncepcja ActiveX polegała właśnie na unikaniu ograniczeń WWW: załadować kod aplikacji lokalnej w ramach sesji przeglądarki, a następnie udawać że to strona internetowa, a nie lokalny, binarny kod, odpowiada za widoczne efekty działania. Strony HTML były bowiem z definicji statyczne – a to jest problem w przypadku np. poczty elektronicznej. Próby rozwiązania tego problemu to przede wszystkim ujęcie strony WWW za pomocą metodyki DOM, wprowadzającej myślenie programistyczne. Ciąg dalszy to skrypty, jak JavaScript. Następnie, na tak stworzonym stosie, wołano kolejne elementy „OBJECT”, korzystające z instalowanych na żądanie kontroler ActiveX, realizujących swoje zadania po stronie klienta. Cały ten łamaniec, opięty terminologicznym parasolem „DHTML” (dynamiczny HTML) omijał statyczną naturę stron internetowych, ożywiając je, by reagowały na zmiany po stronie użytkownika. Pozwalając sobie na nieco kreatywnej nadinterpretacji, można powiedzieć, że właśnie o to chodziło w całym Internet Explorerze 4.0: sprzedać metodę ożywienia treści dostarczanych do użytkownika z sieci. (Drobnym drukiem: za pomocą wstawek z lokalnym kodem wykonywalnym).

Nie podejmuje to jednak próby rozwiązania innego fundamentalnego ograniczenia, które staje się widoczne natychmiast potem: wpływanie na stan zdalnego serwera. Gdy Internet Explorer ładuje jakiś obiekt ActiveX, będący np. zaawansowanym klientem jakiejś usługi (w domyśle: usługi zbyt ograniczonej dla przeglądarki), tenże obiekt często zestawia własne połączenie i własną komunikację. Nie jest to już komunikacja w ramach sesji WWW: jedyną rolą przeglądarki staje się hostowanie obiektu ActiveX, który kradnie jej rolę komunikatora. Co więcej, taka łączność w ogóle nie musi przebiegać po HTTP! Taki poziom swobody, planowany jako zaleta Internet Explorera, okazuje się wadą i pułapką: prędko wygrywa postawa „OK, nie da się tego zrobić, robimy to po swojemu, przeglądarka dostarczy tylko kontrolkę, która będzie robić wszystko sama”. Zniechęca to do tworzenia aplikacji internetowych.

Niewątpliwie z takim problemem zderzył się sam Microsoft, gdy chciał stworzyć webowego klienta swojej usługi pocztowej Exchange. Komunikacja w ramach HTTP była zbyt jednostronna, a podłączanie całej kontrolki ActiveX po to, by otworzyć skrzynkę odbiorczą miało niebezpiecznie mało sensu: na tej zasadzie o wiele lepszym pomysłem byłoby bowiem… po prostu uruchomić Outlooka! Dlatego zdecydowano się stworzyć mechanizm, pozwalający wysyłać żądania API do serwera, a odpowiedzi traktować jako bodźce do zmiany stanu zbioru DOM, czyli wyświetlanej strony internetowej. Strona internetowa wołałaby ten mechanizm, bez konieczności sięgania i pobierania nowej kontrolki ActiveX. W ten sposób do Internet Explorera dodano uniwersalny mechanizm o identyfikatorze „ED8C108E-4349-11D2-91A4-00C04F7969E8”.

Warto tutaj podkreślić, że dalej nie mamy tutaj do czynienia z interaktywną komunikacją na żywo. Dalej jest to zmiana stanu statycznego dokumentu (jakkolwiek oksymoronicznie może to brzmieć). Dalej łączność nie jest ciągła. XmlHttpRequest to tak naprawdę bardzo mało – aby zakopać przepaść między aplikacjami webowymi, a klasycznymi, dziś używamy dodatkowo jeszcze bardzo wielu technologii, które nie będą już tak dobrze obsługiwane przez IE: WebSocket, Service Workers, Single-Page Application Model, REST API oraz kilka innych. Pierwszym krokiem było jednak wymyślić coś więcej, niż tylko „push interface” oraz „XML everywhere!”. Czymś takim był model komunikacji z serwerem „pomiędzy” żądaniami załadowania strony. Jak tłumaczy Alex Hoppman, właśnie takiego elementu potrzebowali ludzie z zespołu Exchange. Wspólnie z zespołem IE, rozszerzyli biblioteki XML o obsługę żądań do komunikacji z serwerem. Wybór biblioteki XML jako nośnika owego mechanizmu był nieco przypadkowy, przez co nazwa „XMLHTTPRequest” pozostała wieczyście myląca, ale pozwoliło to przyspieszyć dodanie kodu do Internet Explorera. Wersje 5.x IE uchodzą za mało wyraziste, pozbawione nowych funkcji i zwyczajnie nudne. W powszechnej opinii, Microsoft „poddał się”, gdy wygrał wojnę przeglądarek i IE5 było już znacznie mniej doniosłe od poprzednika. Tymczasem to właśnie wersja piąta przeglądarki dostarczyła obsługę technologii, która przeobraziła Internet. Ze względu na to, że wkrótce potem IE stał się hamulcowym postępu, ten fakt jest mało znany i niektórym nie mieści się w głowie.

Niesławny XMLHTTPRequest to jednak nie wszystko. Jeszcze jeszcze jeden ambitny i doniosły projekt, tym razem jednak dosć mocno nietrafiony. Kiepska implementacja i schizofreniczne miotanie między rozsądkiem a szkodliwymi zwyczajami sprawiły, że nie odniósł sukcesu jeden z głównych programistycznych selling pointów IE5, czyli... aplikacje internetowe na prawach pulpitu. W roku 2018 walczymy o wprowadzenie obsługi aplikacji typu PWA, po kilkunastu latach mobilnej rewolucji, ktoś zaczyna wreszcie zauważać, nie ma sensu robić gigantycznej appki mobilnej, a następnie odtwarzać jej mechanizm, tworząc portal internetowy o identycznej funkcjonalności. Najlepiej byłoby wpuścić stronę internetową w pulpit, dać jej dostęp do systemowych mechanizmów i pozwolić działać offline. Fakt, przełomowa idea. Musieliśmy czekać dwadzieścia lat, by wróciła. Microsoft pracował bowiem właśnie nad tym w roku 1999.

Interaktywny, kafelkowy i pełen gadżetów pulpit Active Desktop miał być dopiero pierwszym krokiem. W przyszłości, cały interfejs miał być tworzony za pomocą języka HTML. Aplety, panele i cały arsenał kreatorów – wszystkie elementy klasycznego UI miały ustąpić miejsca prostym, zadaniowym „centrom aktywności”, z interfejsem rysowanym w całości przez IE. Miały być uruchamiane we własnych oknach, w praktyce będących Explorerem bez kontrolek. Aplikacje uruchamiane w ten sposób miałyby dostęp do mechanizmów systemowych i podzbioru WinAPI. Mogłyby modyfikować rejestr, odwoływać się do urządzeń i wyświetlać powiadomienia. Dzięki temu (przynajmniej teoretycznie) osoby zaznajomione z tworzeniem stron WWW mogłyby niskim nakładem pracy zacząć pisać aplikacje pulpitowe dla Windows.

Pierwszy, prosty i ograniczony mechanizm do uruchamiania aplikacji z interfejsem HTML (HTA – HTML Application) pojawił się w systemie Windows 2000. Przepisano do niego kilka apletów, przede wszystkim Panel Sterowania, okno Dodaj/Usuń Programy oraz znany z Windows Server nawigator „Zarządzaj swoim serwerem”. Nieco bardziej rozbudowana obsługa HTA pojawiła się wraz z Windows Millennium i wydaniem Internet Explorer 5.5, gdzie aplikacje HTML mogły w szerszym stopniu komunikować się z systemem operacyjnym. Zbiór kreatorów, jak Przywracanie Systemu i Centrum Pomocy, miały być drogowskazami dotyczącymi przyszłego rozwoju interfejsów w Windows i zachętą do tworzenia nowych aplikacji właśnie z użyciem języka HTML. Anulowano jednak bardziej rozbudowane projekty nowych interfejsów, czyli wspomniane Centra Aktywności. Udało się jednak dostarczyć platformę pozwalającą tworzyć aplikacje pulpitowe z webową logiką w środku. Dziś tworzonych jest tak coraz więcej programów, czerpiąc inspirację z aplikacji mobilnych.

Trzeba jednak zgodnie z prawdą przyznać, że aplikacje HTA, koncepcja przecież rewolucyjna i przyszłościowa, niestety nie wypaliły. Anulowane Centra oraz projekt Neptune pozwalają zobaczyć, że aplikacje HTML miały w zamierzeniu umieć znacznie więcej, niż być kreatorami-nawigatorami. Ich możliwości miały być porównywalne ze środowiskiem WinRT oraz właśnie aplikacjami PWA. Gdyby ten projekt udało się dostarczyć w pełni wraz z IE 5, otrzymalibyśmy aplikacje „Modern” piętnaście lat wcześniej. A Internet Explorer stałby się naprawdę niemożliwy do usunięcia z systemu.

Silnik HTA posiadał bowiem moduł rozszerzający jego możliwości, rozwijany w ramach projektu Neptune. Moduł ten, zwany „Mars” ponownie jest przedmiotem spekulacji. Nawet Paul Thurrott nie umiał poprawnie stwierdzić, jakie miało być jego docelowe zastosowanie. Składając kilka wątków, można wysnuć hipotezę, że nowe UI programu MSN Explorer napędziło rozwój narzędzia, wkrótce potem przeznaczonego do rysowania UI dla wielu innych aplikacji. Gdy cel okazał się zbyt ambitny, fragment pozwalający tworzyć interfejsy użytkowe wydzielono jako silnik HTA dla Internet Explorera 5. Moduły, które umożliwiały bardziej niskopoziomową komunikację z systemem operacyjnym uratowano poprzez włączenie ich do Pomocy i Przywracania Systemu (PC Health) dla Windows Millennium. Na tym historia środowiska Mars się kończy: silnik HTA wydzielono, a reszta funkcji była wykorzystywana przez PC Health. Pozostałe elementy przeznaczone do rysowania Marsem, w tym ekran logowania Windows XP, otrzymały własne, oddzielne silniki. Mechanizm uruchamiania aplikacji internetowych na prawach pulpitu powrócił dopiero w Windows 8.

Mimo porażki ambitnej inicjatywy, okrojony efekt w postaci silnika HTA i tak był zaskakująco świeżym i nowoczesnym projektem. Miał on jednak kilka dyskwalifikujących wad. Pierwszą z nich była naturalnie słabość silnika: program HTA mógł uruchamiać skrypty Visual Basic, ale nie dostarczało to aż tak rozbudowanej integracji z systemem, jak początkowo planowano. Poza tym, aplikacja HTA, mimo działania w kontekście aplikacji, a nie strony, dalej mogła być rysowana wyłącznie przez Internet Explorera. Jeżeli weźmiemy pierwszą z brzegu aplikację stworzoną we frameworku Electron, na przykład klienta Discord, i spróbujemy przenieść jego funkcje pod Internet Explorera 5, nie udałoby się nam wykonać nawet ułamka potrzebnej pracy. Niniejszych braków nigdy nie załatano, a programistów sieciowych usiłowano potem zwabić na pulpit udostępniając im technologię XAML. Doprowadziło to do fragmentacji API, a nie do ich zintegrowania. Świat najwyraźniej nie był gotowy na PWA w roku 1999.

Ostatni przełomowy pomysł rodem z Internet Explorera 5 jest malutki: to obsługa zasoby ‘favicon’, czyli ikony dla skrótu do strony internetowej pojawiającego się po dodaniu jej do Ulubionych. Taką ikonę można było umieścić na pulpicie, a późniejsze wersje IE używały ich do oznaczania kart i zakładek, dodając stronie więcej „duszy” – dzięki temu nie występowały wszystkie pod jedną ikoną „Dokumentu HTML”. Faviconę można było również zabudować w manifeście dla HTA, dzięki czemu strona internetowa mogła na pełniejszych prawach prezentować się jako aplikacja. Obsługę favicony skopiowali wszyscy istotni konkurencji Internet Explorera, dodając przy okazji wsparcie dla formatów innych, niż okropne „ICO” oraz „ANI”. Dzisiejsze aplikacje HTML5 zaopatrzone w manifest JSON, definiujący zasady instalowania strony-aplikacji jako elementu w ekranie startowym, pośrednio czerpią właśnie z pomysłu wdrożonego w IE5.

Internet Explorer 5.0, najmniej wzruszające wydanie z serii, okazuje się być więc całkiem przebojowym, solidnym i przełomowym produktem. To dobrze, bowiem później było już tylko gorzej. Wydanie wersji szóstej IE to dobry moment na wstrzymanie rozważań i próbę podsumowania zrywu, jakiego podjął się zespół Internet Explorera w drugiej połowie lat dziewięćdziesiątych. W dobrym tonie jest uważać, że właśnie wtedy Microsoft wykazał się szczytem podłości i za wszelką cenę próbował promować swój produkt, a następnie uzależniać od niego swoich użytkowników. Liberalnie interpretując istniejące standardy oraz wymyślając własne niby-technologie, usiłował przejąć rozwój Internetu i pod płaszczykiem innowacji, zmusić cały świat do przejścia na Windows. Ale czy tak było w istocie?

Należy koniecznie zwrócić uwagę na fakt, że Microsoft nie był pionierem w kwestii wymyślania tego, jak ma działać Internet: Netscape robił dokładnie to samo. Taki detal, jak JavaScript został wymyślony właśnie tam i zaimplementowano go w przeglądarce Navigator o wiele wcześniej, niż sam język został opublikowany jako standard. Buńczuczny „Active Desktop” i próba wepchnięcia całego peceta do Internetu wcale nie była też wyłączną zaczepką Microsoftu: Netscape próbował zrobić dokładnie to samo, a nawet więcej: projekt „Constellation”, nieukończona koncepcja przeglądarki do wszystkiego, zawierał właśnie takie pomysły, jak strony skryptowo aktualizowane na żywo, strony-aplikacje możliwe do funkcjonowania offline, aktywne kanały na modłę CDF/RSS… Było to dokładnie to samo, co próbował Microsoft ze swoim Internet Explorerem. Netscape był jednak zbyt pewny siebie i za mały: chciał osiągnąć więcej, mając mniej. Mniej pieniędzy, mniej zaplecza technicznego, mniej ludzi. Obiecując kompletny produkt, gdy nie istniał nawet prototyp oraz szafując hasłami o zbędności Windows w przyszłym świecie, dał Microsoftowi nie tylko gotowy schemat produktu-zwycięzcy, ale także wystarczająco dużo motywacji do zgładzenia ich, denerwując swojego większego kolegę nadmiarem ambicji. W dodatku Microsoft miał coś, o czym konkurencja mogła pomarzyć: gotową ścieżkę dostępu do pozostałych swoich technologii. Ludzie z Redmond mogli po prostu pójść do innego budynku, popatrzeć na kolegów od Visual Studio i powiedzieć „dajcie nam za darmo podzbiór waszego projektu, przyszyjemy go do IE”. Tymczasem Netscape musiałby to wszystko stworzyć samemu od podstaw.

Dlatego mimo swojej pewności siebie, manifestowanej ostentacyjnym stawianiem wielkich maskotek Mozilli na przewróconym niebieskim E, to nie Netscape miał rację, a Microsoft – co widać w słowach, których autorem jest Andrew Lees z MS/UK: [quote]"We're very upbeat because they're now in copycat mode. That's very funny coming from a company that said we are out of date and not innovating. We will ship before them, we will build our technology into Windows, we will get broader support than they will, and we will have a better product."[/quote]

And so they did.

Internet Explorer wygrał wojnę przeglądarek. Nie był to jednak ten rodzaj zwycięstwa, którego tak naprawdę oczekiwano w Microsofcie. Większość pobocznych technologii, wymyślonych na potrzeby szturmowania rynku przeglądarek, przegrało i zniknęło. Kwestie multimediów i „treści wzbogaconej” przypadły niemal w całości Flashowi i Javie. Niemniej, przeglądarka Microsoftu stała się monopolistą i kilka miesięcy po wydaniu wersji 6, zdominowała rynek w 95%. Jednocześnie lawinowo rosła liczba użytkowników internetu, a wraz z premierą Windows XP – liczba osób korzystających z sieciowych systemów operacyjnych. Wtedy nastąpił moment przegrzania, kompletnie zignorowany z powodu głębokiego przekonania, że Microsoft nigdy nie przegrywa.

Złośliwa opinia na temat systemów Windows, głosząca że są one niestabilną zabawką, powoli zaczęła ustępować miejsca nowej: Windows (oraz Internet Explorer) okazały się programami dziurawymi jak sito, które mimo rozległej palety funkcji związanych z bezpieczeństwem, zwyczajnie nie potrafią go zapewnić. Internet Explorer dostawał łatki ze zwiększoną intensywnością już od wersji czwartej, było ich tyle, że opracowano dla niego oddzielną linię dodatków Service Pack, a sprawy ani trochę nie poprawił Windows 2000, przyciągający robaki jak magnes, doprowadzając do kilku pomniejszych awarii sieci telekomunikacyjnych na początku stulecia. Windows XP nie poprawił tej sytuacji. Wynikało to z problemów natury fundamentalnej: oprogramowanie w Microsofcie robiono po staremu i na szybko.

Na przykład, aktualizacje dla Internet Explorera były zależne od kolejności instalacji oraz od… wersji językowej. Oznacza to, że załatanie jednej luki w zabezpieczeniach skutkowało wydaniem (i koniecznością przetestowania) około dwustu paczek z aktualizacją. W takich warunkach, produkt miał być nie tylko łatany, ale i w ogóle rozwijany. Zapewne oddalało to możliwość dodawania nowych funkcji o całe lata, skazując świat na dożywotnie korzystanie z wersji szóstej.

Ponadto, Internet Explorer był rozwijany na kilka systemów jednocześnie, a miały one ze sobą mniej wspólnego, niż się wydaje. Ten sam program miał działać na systemie Windows XP Professional, zaopatrzonym w nowe biblioteki, chronioną pamięć, bezpieczne wątki i całą gamę mechanizmów zabezpieczeń – oraz na Windows 98 (pierwsze wydanie), który nie zawierał żadnej z tych rzeczy. Metodą wspólnego mianownika, opracowywano pakiet tak, by nie korzystał w pełni z nowych możliwości, co skutkowało znaczącym pogorszeniem poziomu bezpieczeństwa. Gdy uznano, że IE wygrał i nie trzeba go sprzedawać na siłę posiadaczom systemów, które z definicji nie są bezpieczne, podjęto pewną doniosłą i pozornie sensowną decyzję: nowe wersje IE będą wydawane równolegle z nowymi wersjami Windows i nie zostaną udostępnione jako oddzielny instalator dla starszych systemów.

Jest to jedna z tych decyzji, które są stuprocentową nowomową korporacyjną. Z pozoru jest ona uzasadniona: nowe Windowsy zawierają nowe mechanizmy zabezpieczeń i po prostu lepiej będzie nie musieć się przejmować poprzednimi i zawsze korzystać z tego, co najnowsze i najlepsze. Wystarczy jednak zrobić krok poza kampus „One Microsoft Way” w Redmond, by zobaczyć jak owa decyzja wygląda w prawdziwym świecie: oto wielki monopolista nie będzie wydawać nowej wersji przeglądarki, zamiast tego każe ludziom po prostu kupować cały nowy system operacyjny. Ponadto, tempo rozwoju Internetu będzie mierzone w odstępach między kolejnymi Windowsami: nie ma szans na wydanie pośrednie, co wskazuje na głębokie przekonanie, że MS może dyktować twórcom stron, czego mogą oczekiwać, bo przecież wszyscy wokół używają IE. Żadna porcja zalet związanych z bezpieczeństwem nie przekona nikogo, że wcale nie jest to próba przeciągnięcia ludzi na Longhorna (przyszłą wersję Windows, która niczym Zalgo – wciąż nadchodzi i nadejść nie może).

Poprawne rozwiązanie tego problemu było bowiem niepojęte dla Microsoftu z lat 2000-2012: należało zostawić w systemie minimalną przeglądarkę, przeznaczyć ją dla użytkowników korporacyjnych złapanych w pułapkę ActiveX, uruchamiać ją w piaskownicy, a rozwój „prawdziwej” pozostawić innemu zespołowi: to oni będą decydować jakich mechanizmów chcą używać i na tej podstawie będą „targetować” pod konkretny system. Tego typu myślenie pojawiło się na horyzoncie dopiero w czasach przeglądarki Edge, a i tak nie jest wdrożone w całości: wszak Edge nie aktualizuje się przez Sklep…

Potrzebowano pięciu długich lat, by stworzyć nową wersję IE, bezpieczną, „piaskownicowaną” i napisaną z użyciem nowych praktyk. Zanim to nastąpiło, Microsoft wycofał się ze swoich bardzo źle przyjętych słów o zakończeniu rozwijania samodzielnego IE – po czym wydał Service Pack 2 do Windows XP, instalujący wersję „2900” Internet Explorera 6, w praktyce realizując właśnie ten anulowany scenariusz: był to wariant IE działający wyłącznie w najnowszym systemie, aktualizowany oddzielnie, przekompilowany, wzbogacony o nowe funkcje, niemożliwy do samodzielnego zainstalowania i niedziałający na Windows 98. Nie było innego wyjścia. Tej skali zmianę można było wprowadzić wyłącznie po cichu, alternatywą było bowiem wykrzyknięcie wniebogłosy, że IE nie nadaje się do użytku w dzisiejszych czasach, bo jest źle zrobiony.

Wtem nastał Firefox: dzięki swojej akcji promocyjnej (zalety były już odstępne wcześniej w Netscape), odebrał IE udziały w rynku, pokazując tym dobitniej, jak bardzo świat potrzebuje nowej przeglądarki: wreszcie pojawiła się możliwość wydawania nowych wersji JavaScriptu, gdzieniegdzie pojawiały się szepty o HTML5 i nowych standardach – a Microsoft dalej nie umiał wydać nowego IE.

Mimo zdementowania słów o zaprzestaniu rozwoju, Internet Explorer 7 zdecydowanie miał działać tylko na Longhornie. Niestety, projekt rozpoczęty jeszcze w końcówce „starych czasów” nie miał szans na powodzenie i został anulowany. Tylko dzięki temu udało się wydać wersję Siódmą również dla XP, ale w porównaniu z „prawdziwą” wersją 7.0 z Visty, była ona okrojona. Mimo niewątpliwego postępu, Firefox dalej był po prostu lepszą przeglądarką. Stawało się jasne, że trzeba zmienić nie tylko przekonanie, że świat = Microsoft, nie tylko proces produkcyjny i wewnętrzną inżynierię oprogramowania, ale także cały pomysł dot. tego, czym tak naprawdę ma być przeglądarka.

Nikt nie mógł tego powiedzieć głośno, ale era innowacji w wykonaniu IE była niewątpliwie zakończona. Nadszedł czas wymyślenia się na nowo, by nie pozostać na zawsze pośmiewiskiem. Wbrew pozorom pierwsze próby „wyjścia z przegrywu” nastąpiły już w wersji 8.0, dalej dostępnej dla XP, ale przyszywana zgodność ze standardami, WebSlices i kolorowanie kart to wciąż było za mało. Być może udawało się dogonić Firefoksa (on nie oferował wtedy wieloprocesowości), ale nowy zawodnik, Chrome, wpędzał w zakłopotanie.

Próby „innowacyjności” podejmował już nie zespół IE, ale ludzie od WPF i XAMLa: to oni stworzyli niesławny komponent Silverlight i zestaw Microsoft Expression, chcąc dostarczyć przeciwwagę dla Javy, Flasha i starego Windows Media. Sukces tego spóźnionego przedsięwzięcia, mimo niezrozumiałych zachwytów części analityków IT, był mierny. Sieć zaczynała bowiem powoli dryfować w stronę świata bez wtyczek.

Microsoft zrozumiał jednak, jak należy robić przeglądarkę internetową: żadne nowe elementy Windows nie rysowały już swojego interfejsu Internet Explorerem, a stare oprogramowanie, jak Office 2003, otrzymywały poprzednią jego wersję, opakowaną w tryb zgodności. Przedstawiała się ona jako MSIE 7.0. Przeglądarka-platforma, mieszająca Internet z Windows, została zapakowana do pudełka i wywoływana na żądanie kierowane przez starocie, a do codziennego użytku i dla aplikacji żyjących wyłącznie w sieci miał być używany nowy Internet Explorer, stopniowo rozmontowywany z dawnych korpo-narzędzi i powoli unowocześniany.

Takie były wersje 9-11. Mimo rewolucyjnych zmian, porzucenia sporego bagażu zgodności i wdrożenia całkiem wielu nowoczesnych rozwiązań i technologii, Internet Explorer pozostał już przeglądarką dla firm i babć. Głośno reklamowane innowacje były przyjmowane z entuzjazmem, ale działało to na tej samej zasadzie, co radość z rozwiązania równania kwadratowego przez mniej zdolne dziecko w klasie: „całkiem nieźle, jak na Ciebie!”. W praktyce było to nieskuteczne gonienie konkurencji, która wydawała się możliwa do pokonania dopiero za jakieś 50 lat. Jednocześnie innowacje spod znaku Silverlighta i Expression pogrzebano i zamieciono pod dywan.

Ostatnie lata rozwoju Internet Explorera to zdumiewający przykład tego, jak wiele pracy można wykonać bez jakichkolwiek wartościowych efektów. Internet Explorer 11 jest nieskończenie lepszym produktem, niż nieszczęsna wersja szósta, ale akcja od lat toczyła się gdzie indziej. Wynik był przesądzony od samego początku i jego wpływ na przyszłość okazał się na tyle szczególny, że nawet Edge, rozwijany „po nowemu” ma problemy, by się wybić. Chichotem historii jest, że przeglądarka Edge, w ramach obsługi PWA w Windows 10, ponownie stała się systemową „platformą”, którą mogą wołać inne aplikacje celem uruchomienia się w niej. Na tej samej zasadzie Chrome WebView rysuje ramki ze stronami internetowymi i aplikacje PWA w systemie Android. Więc jest nowocześnie, poprawnie, tak jak ma być. A i tak niewiele z tego wynika.

Jeżeli Edge chce się przebić, musi stać się po prostu lepszym produktem tak, jak na kilku polach próbował tego niegdyś Internet Explorer 3. Ale czy jest to jeszcze możliwe w czasach, gdy oprogramowanie nie jest już ekscytujące, a przeglądarka internetowa ma być niewidzialnym i nieistotnym tłem?