Bitwa o przeglądarki: Netscape, IE, Chrome i wpływ na Web

Internet przed wojną przeglądarek – krótki obraz epoki

Sieć lat 80. i wczesnych 90. – zanim pojawiły się przeglądarki

Przed pierwszą wojną przeglądarek Internet nie przypominał kolorowego, interaktywnego świata znanego z Chrome czy Firefoksa. Sieć była domeną naukowców, wojskowych i zapalonych adminów, którzy poruszali się po niej z poziomu terminala tekstowego. Zamiast kliknięć myszą – komendy wpisywane w linii poleceń, zamiast responsywnych stron – surowy tekst przesyłany protokołami zaprojektowanymi z myślą o prostocie, a nie o designie.

ARPANET, poprzednik dzisiejszego Internetu, opierał się na protokole NCP, a później TCP/IP. Użytkownicy korzystali z narzędzi takich jak telnet, FTP, później także Gopher czy Usenet. Do przeglądania zasobów informacji służyły tekstowe interfejsy, często na terminalach podłączonych do dużych maszyn typu mainframe lub minikomputerów. Nie było idei „strony www” z grafiką, animacją i skryptami – były dokumenty, katalogi, listy plików.

Gopher był jednym z ciekawszych etapów przejściowych: tworzył hierarchiczną strukturę menu, po której można było poruszać się za pomocą klawiatury. Działał szybko, był prosty i z perspektywy użytkownika bardziej przyjazny niż surowy FTP. Jednak nadal pozostawał tekstowy, mało elastyczny i słabo przystosowany do bogatego formatowania treści. Świat wyglądał więc raczej jak rozległy katalog dokumentów, a nie sieć hiperłączy, które można dowolnie łączyć.

Narodziny WWW i pierwsze przeglądarki graficzne

Przełom nastąpił, gdy Tim Berners-Lee w CERN połączył kilka pomysłów w jedną całość: protokół HTTP, format dokumentu HTML i system adresowania URL. Tak powstał World Wide Web – warstwa logiczna nad „surowym” Internetem, która wprowadziła hipertekst, czyli klikanie w linki zamiast ręcznego wklepywania ścieżek do plików. Pierwsza przeglądarka WorldWideWeb (później przemianowana na Nexus) była programem działającym na NeXTSTEP i miała interfejs graficzny, ale pozostawała niszowa.

Naprawdę głośno zrobiło się dopiero wraz z Mosaic, przeglądarką stworzoną w NCSA (National Center for Supercomputing Applications). Mosaic łączył obsługę grafiki in-line (obrazki w treści, a nie w osobnym oknie), proste formatowanie oraz intuicyjny interfejs z przyciskami „Back”, „Forward”, „Bookmarks”. Dla kogoś przyzwyczajonego do terminala Mosaic był jak przesiadka z czarno-białej telewizji na kolorową – nagle można było „zobaczyć” Internet.

Wczesny Web nadal był jednak bardzo prosty: HTML oferował podstawowe nagłówki, akapity, listy, linki i obrazki. Nie istniał CSS, a o JavaScripcie nikt jeszcze nie myślał. Layout strony określały głównie znaczniki strukturalne, a nie dokładne pozycjonowanie elementów. Strony były statyczne – serwer generował dokument HTML, który przeglądarka wyświetlała bez większej ingerencji. Jeśli coś się zmieniało, to po ponownym załadowaniu strony, a nie „w locie” jak w aplikacjach SPA dziś.

Jak korzystało się z Internetu przed masowym GUI

Korzystanie z Internetu bez nowoczesnych przeglądarek przypominało bardziej pracę z systemem plików niż surfowanie po sieci. Typowy użytkownik (jeśli w ogóle miał dostęp) łączył się z serwerem przez modem, otwierał terminal, logował się do zdalnej maszyny i korzystał z tekstowych narzędzi. Przeczytanie artykułu na grupie dyskusyjnej wymagało znajomości klienta Usenet, pobranie pliku – obsługi FTP.

Wejście GUI, znanego z systemów takich jak Windows czy Mac OS, zmieniło to radykalnie. Przeglądarka stała się „oknem na świat”, które nie wymagało znajomości protokołów, portów i katalogów. Użytkownik widział adres w pasku, klikał linki, przewijał myszą. Progi wejścia spadły dramatycznie, a Internet z zabawki dla techników zaczął się zmieniać w masowe medium. Dopiero ten moment stworzył realny grunt pod „bitwę o przeglądarki” – skoro przeglądarka stała się bramą do wszystkiego, kto kontrolował bramę, ten miał władzę.

Z perspektywy biznesowej wczesny Internet był jeszcze terytorium eksperymentalnym. Firmy traktowały sieć jako ciekawostkę marketingową, uczelnie i instytucje – jako narzędzie wymiany informacji. Nikt poważnie nie zakładał wtedy, że sam wybór przeglądarki może decydować o miliardowych przepływach w e-commerce, reklamie czy SaaS. To dopiero nadchodzące „wojny przeglądarek” miały uświadomić branży, jak strategiczna jest ta mała ikona na pulpicie.

Narodzin Netscape Navigator i początek pierwszej wojny przeglądarek

Od Mosaic do Netscape – jak garstka ludzi rozpędziła lawinę

Mosaic zachwycił użytkowników, ale prawdziwą rewolucję biznesową przyniósł dopiero Netscape Navigator. Kluczowa była tu grupa ludzi z NCSA, w tym Marc Andreessen, którzy postanowili przekuć sukces akademickiego projektu w komercyjny produkt. Tak powstała firma Netscape Communications, finansowana kapitałem wysokiego ryzyka, z jasnym celem: stać się standardową bramą do Internetu dla całego świata.

Netscape Navigator szybko wyprzedził Mosaic technicznie i wizerunkowo. Firma postawiła na intensywny rozwój funkcji, szybkie wydania i agresywną dystrybucję. Navigator był dostępny na różne systemy (Windows, Mac, Unix), działał relatywnie stabilnie i oferował przyjazny interfejs. Użytkownicy czuli, że to „ich” przeglądarka – dynamiczna, nowoczesna i związana z rodzącą się kulturą Internetu.

Dla milionów nowych internautów Netscape Navigator stał się wręcz synonimem sieci. Ikonka z żółwiem czy statkiem (w zależności od wersji) była pierwszym kliknięciem po uruchomieniu komputera. W latach 1995–1996 udział Netscape’a w rynku przeglądarek sięgał zdecydowanej większości – mówiono o 80–90%. W praktyce oznaczało to, że to Netscape decydował, czym jest Web.

Model biznesowy Netscape – darmowy dla ludzi, pieniądze od firm

Netscape zastosował sprytny model „get big fast”: przeglądarka dla użytkowników końcowych była darmowa lub tania, natomiast zarabiano na licencjach dla firm, serwerach i rozwiązaniach korporacyjnych. Navigator był rozprowadzany na płytach CD, dołączany do czasopism komputerowych, oferowany dostawcom Internetu jako część pakietu „startowego”. Każdy, kto podłączał komputer do sieci, bardzo szybko trafiał na Netscape’a.

Firma rozumiała, że liczy się przede wszystkim udział w rynku i tempo adopcji, a nie natychmiastowy zysk z każdej kopii. Im więcej osób korzystało z Navigatora, tym silniejszą pozycję negocjacyjną miała spółka wobec twórców stron, dostawców Internetu i producentów oprogramowania. Na dodatek Netscape sprzedawał swoje serwery webowe i narzędzia developerskie, spinając w całość cały ekosystem – od serwera po przeglądarkę.

Marketing Netscape’a był jak na tamte czasy bardzo agresywny. Firma organizowała konferencje dla deweloperów, wydawała obszerne dokumentacje, promowała „Netscape Now!” – logotypy do wstawiania na strony. Twórcy witryn czuli, że trzymają się zwycięskiego obozu, co dodatkowo wzmacniało pozycję Navigatora. A że Microsoft spał? Cóż, to już inna historia.

Techniczne przewagi i autorskie rozszerzenia HTML

Netscape nie tylko podążał za standardami – on je wyprzedzał, a często po prostu wymyślał. Firma wprowadzała własne rozszerzenia HTML, które nie istniały jeszcze w specyfikacjach W3C. Przykładem słynny znacznik <font>, czy <blink>, a także dodatki do formularzy i ramek. Dla twórców stron była to gratka: można było szybciej budować efektowne witryny, korzystając z nowych możliwości.

Netscape mocno przyczynił się też do narodzin JavaScriptu (początkowo nazwanego LiveScript). Skrypty po stronie klienta pozwalały reagować na działania użytkownika, walidować formularze, tworzyć dynamiczne elementy. W połączeniu z tzw. DHTML (dynamiczny HTML) przeglądarka zaczynała przypominać środowisko uruchamiania prostych aplikacji, a nie tylko pasywnego czytnika dokumentów.

Ta jednostronna kreatywność miała jednak cenę: powstawał Web zależny od konkretnej przeglądarki. Strony tworzone „pod Netscape Navigator” korzystały z tagów, których inne przeglądarki nie znały, co w praktyce utrudniało konkurencji dogonienie lidera. Programiści szybko zaczęli używać komunikatów typu „Best viewed in Netscape” – zapowiedzi nadchodzącej epoki kompatybilnościowego chaosu.

Wejście Microsoftu – narodziny Internet Explorera

Microsoft przesypia początek Webu i nagle się budzi

Microsoft w pierwszej połowie lat 90. był skoncentrowany na swoim głównym koniu – systemie Windows i pakiecie Office. Firma zakładała, że przyszłość należy do aplikacji desktopowych, a Internet to miły dodatek, ewentualnie kanał dystrybucji plików. Przeglądarka nie była traktowana jako produkt strategiczny, raczej jako kolejny program w kategorii „akcesoria”.

Sytuacja zaczęła się zmieniać, gdy Netscape Navigator zaczął rosnąć w zawrotnym tempie. Raporty pokazujące, że Netscape instaluje własne rozwiązania serwerowe i ma ambicje stworzyć platformę aplikacyjną ponad systemem operacyjnym, zabrzmiały w Redmond jak alarm przeciwpożarowy. W słynnym „Internet Tidal Wave Memo” Bill Gates ogłosił, że Internet jest priorytetem numer jeden. Od tego momentu Microsoft wrzucił szósty bieg.

Perspektywa była jasna: jeśli przeglądarka stanie się głównym interfejsem użytkownika, to system operacyjny zsunie się do roli niewidocznej warstwy. To zmniejszało przewagę Windows i zagrażało przychodom z pakietu Office, który potencjalnie można było zastąpić aplikacjami webowymi. Dla Microsoftu brak własnej, dominującej przeglądarki był zatem ryzykiem strategicznym, a nie tylko niedoborem w portfolio.

Pierwsze wersje Internet Explorera i licencja na Mosaic

Aby nadgonić Netscape’a, Microsoft nie zaczynał od zera. Firma wykupiła licencję na kod Mosaic od spółki Spyglass. Na tej bazie powstały pierwsze wersje Internet Explorera. IE 1 i IE 2 były raczej ciekawostką niż realną konkurencją – ubogie w funkcje, mało stabilne, nieprzyjazne. Jednak Microsoft miał coś, czego Netscape nie posiadał: pełną kontrolę nad systemem operacyjnym Windows.

Internet Explorer 3 i 4 zaczęły już wyglądać poważniej. Pojawiły się obsługa CSS (choć jeszcze kulawa), technologie takie jak ActiveX, wsparcie dla JScript (implementacji JavaScriptu). Interfejs był ściśle zintegrowany z Windows, korzystał z mechanizmów systemowych, w tym z biblioteki WinInet. Microsoft konsekwentnie rozwijał IE, równolegle poprawiając integrację z innymi produktami – przede wszystkim z pakietem Office i usługami serwerowymi.

Rynek początkowo traktował IE z rezerwą. Navigator miał przewagę rozpoznawalności i funkcjonalności. Ale Microsoft grał długofalowo, wiedząc, że może rozdać przeglądarkę za darmo razem z systemem. To zmieniało zasady gry: przeglądarka przestawała być osobnym produktem, a stawała się składnikiem Windows – dokładnie tym, co później wywołało proces antymonopolowy.

Integracja z Windows i reakcja użytkowników

Jedną z najważniejszych decyzji Microsoftu było techniczne i marketingowe zlanie Internet Explorera z systemem operacyjnym. Przyciski „Internet” na klawiaturach, skróty na pulpicie, a później eksplorator Windows dzielący komponenty z przeglądarką – wszystko to miało sprawić, że użytkownik nawet nie zastanowi się nad wyborem browsera. Po prostu korzystał z tego, co „już jest w systemie”.

Dla wielu nowych internautów pojawienie się ikonki „Internet Explorer” w menu Start było pierwszym realnym kontaktem z siecią. Część istniejących użytkowników, wiernych Netscape’owi, narzekała na jakość pierwszych IE, ale rosnąca grupa użytkowników mniej technicznych przyjmowała wybór domyślny bez dyskusji. Dla firm liczyły się też koszty wdrożenia – IE był „za darmo” i nie wymagał osobnego procesu instalacji.

Internet Explorer stopniowo nadrabiał braki funkcjonalne i zyskiwał udział w rynku. Kombinacja darmowej dystrybucji, preinstalacji i rosnącej jakości zaczęła działać. Z perspektywy webdeveloperów oznaczało to jedno: czas testować strony w dwóch przeglądarkach, a docelowo – przygotować się na to, że jedna z nich będzie narzucać własne reguły gry.

Pierwsza wojna przeglądarek: Netscape kontra Internet Explorer

Technologiczny wyścig zbrojeń – HTML, CSS, JavaScript, DHTML

Pierwsza wojna przeglądarek to klasyczny przykład wyścigu zbrojeń, w którym technologia rozwija się szybciej niż standardy. Netscape i Microsoft wprowadzali własne rozszerzenia do HTML, CSS i JavaScript, często bez uzgodnienia z W3C. Powstawały tagi tylko dla Netscape’a oraz funkcje działające wyłącznie w IE, co prowadziło do permanentnej frustracji programistów.

Netscape rozwijał JavaScript, Microsoft odpowiadał JScript i VBScript. Netscape miał swoje podejście do warstw i pozycjonowania, Microsoft lansował własne modele DOM i DHTML. Pierwsze implementacje CSS były częściowe i pełne błędów. To, co działało idealnie w Netscape 4, potrafiło rozsypać się w IE4, i odwrotnie. Twórcy stron musieli stosować hacki, komentarze warunkowe, skrypty rozpoznające przeglądarkę.

„Best viewed in…” – rodzi się kultura stron pisanych pod konkretną przeglądarkę

Efektem wojny funkcji była schizofrenia po stronie twórców serwisów. Każda nowa wersja Netscape’a czy IE przynosiła świeże możliwości, ale też nowe różnice implementacyjne. Zamiast jednego Webu zaczęły wyłaniać się dwa równoległe światy: „Web pod Netscape’a” i „Web pod IE”.

Na stronach lądowały znane napisy: „Best viewed in Netscape 3.0 at 800×600” albo „This site requires Internet Explorer 4.0 or higher”. W praktyce oznaczało to:

• użytkownicy byli zachęcani (albo wręcz zmuszani) do instalacji konkretnej przeglądarki,
• firmy testowały serwisy głównie na platformie preferowanej przez własny dział IT,
• część funkcji była po prostu wyłączana dla „tej drugiej” przeglądarki.

Prosty przykład z życia: formularz zamówienia działający idealnie w IE dzięki ActiveX do walidacji numeru karty, w Netscape’ie wyświetlał tylko komunikat „użyj Internet Explorera”. Dla klienta – ściana. Dla dewelopera – kolejny support ticket.

To podejście osłabiało ideę interoperacyjności, ale było wówczas kusząco pragmatyczne. Liczył się czas wdrożenia i efekt „wow”, a nie elegancja względem standardów, które i tak biegły za rynkiem z lekkim opóźnieniem.

Marketing, bundling i „darmowość” jako broń

Choć wojna toczyła się głównie na poziomie technologii, jej rozstrzygnięcie przyniosły działania biznesowo-marketingowe. Microsoft wykorzystał swoją pozycję na rynku systemów operacyjnych, by wypchnąć Internet Explorera wszędzie tam, gdzie tylko się dało.

Kluczowe zagrania wyglądały następująco:

• Preinstalacja w Windows – IE był domyślną przeglądarką w nowych komputerach z Windows 95 OSR2, a później Windows 98 i nowszych. Użytkownik nie musiał nic ściągać ani konfigurować.
• Umowy z producentami komputerów (OEM) – partnerzy otrzymywali Windows z zintegrowanym IE, a ingerencja w „doświadczenie użytkownika” była limitowana zapisami licencyjnymi.
• Współpraca z dostawcami Internetu – pakiety startowe, płyty CD i materiały marketingowe były brandowane logotypem IE, często z prostym przekazem: „Kliknij niebieskie E, żeby wejść do Internetu”.

Netscape nie miał takiego kanału dystrybucji. Mógł dodawać płyty do czasopism, dogadywać się z providerami, ale i tak był zawsze „dodatkową instalacją”. Dla wielu mniej technicznych użytkowników już sama konieczność pobrania i zainstalowania innej przeglądarki była barierą. Dla admina w korporacji – dodatkowym punktem na liście rzeczy, które mogą się zepsuć.

Darmowość IE podcinała też skrzydła modelowi licencyjnemu Netscape’a. Skoro w systemie jest już za darmo „coś, co otwiera strony”, to trudno uzasadnić zakup płatnej przeglądarki, nawet jeśli technicznie jest lepsza.

Proces antymonopolowy przeciw Microsoftowi

Agresywna strategia Microsoftu nie przeszła bez echa. Amerykański Departament Sprawiedliwości (DOJ) oraz część stanów oskarżyły firmę o nadużywanie pozycji monopolistycznej na rynku systemów operacyjnych w celu wyeliminowania konkurencji na rynku przeglądarek.

Główne zarzuty dotyczyły:

• wiązanego licencjonowania – OEM-y, które chciały sprzedawać komputery z Windows, miały ograniczoną swobodę usuwania IE czy promowania alternatywnych przeglądarek,
• technicznej integracji IE z powłoką systemową – połączenie Explorera plików z Internet Explorerem miało umocnić tezę, że przeglądarka jest „nierozłączną częścią systemu”, a nie oddzielnym produktem,
• praktyk mających na celu wypieranie Netscape’a z kanałów dystrybucji – np. presji na partnerów, by rezygnowali z bundlowania Navigatora.

Proces ciągnął się latami, zakończył się szeregiem ugód i zobowiązań, ale dla Webu ważniejsze było coś innego: w czasie, gdy prawnicy dyskutowali o bundlingu, rynek po prostu się przestawił. Netscape tracił użytkowników, developerzy coraz częściej optymalizowali serwisy „pod IE”, a Internet Explorer zaczął zbliżać się do dominacji, jaką wcześniej miał Navigator.

„Zamrożenie” innowacji – era dominacji Internet Explorera

Gdy kurz po pierwszej wojnie przeglądarek częściowo opadł, Internet Explorer wyszedł z niej jako zwycięzca. W okolicach początku lat 2000 udział IE na rynku szacowano na ponad 90%. Netscape był w odwrocie, a nowa konkurencja dopiero raczkowała. Paradoksalnie, triumf IE spowodował spowolnienie innowacji w samym browserze.

Microsoft, mając praktycznie monopol, nie odczuwał presji częstych wydań. Nowe wersje IE pojawiały się rzadko, a ich rozwój podporządkowano głównie potrzebom korporacyjnym i integracji z technologiami Microsoftu (ActiveX, SharePoint, aplikacje intranetowe). Z punktu widzenia Webu publicznego oznaczało to:

• długie utrzymywanie niekompletnych lub błędnych implementacji CSS i DOM,
• wolne wdrażanie nowszych standardów (XHTML, później CSS2+),
• brak konsekwentnego mechanizmu automatycznych aktualizacji u większości użytkowników.

Webdeveloperzy wchodzący do branży w tej epoce często uczyli się „Webu według IE6”. Rozwiązania dopasowane do tej konkretnej przeglądarki, obejścia bugów, hacki CSS i skrypty detekcyjne stawały się częścią codziennej praktyki. Standardy W3C istniały, ale w wielu firmach ich znajomość przegrywała z potrzebą „żeby działało w IE, reszta to bonus”.

Ten okres bywa nazywany „ciemnymi wiekami” front-endu: ogromne możliwości sprzętowe i rosnąca przepustowość sieci zderzały się z przeglądarką, która nie nadążała za ambicjami projektantów i programistów. Jednocześnie jednak rodził się zalążek buntu, który później przełożył się na boom alternatywnych browserów.

Upadek Netscape’a i narodziny Mozilli

Próba kontrataku: Netscape 4.x i przejęcie przez AOL

Netscape nie poddał się od razu. Seria Netscape Communicator 4.x miała być odpowiedzią na rosnącą przewagę IE. Oprócz przeglądarki oferowała klienta poczty, edytor HTML i narzędzia grupowe. W teorii – kompletne środowisko pracy w sieci. W praktyce – ciężki, awaryjny pakiet, z którym wiele osób miało skojarzenia typu „zawiesił mi system, gdy tylko otworzyłem trzy zakładki”.

W 1998 roku Netscape został przejęty przez AOL. Transakcję przedstawiano jako szansę na połączenie silnej marki przeglądarki z ogromną bazą użytkowników AOL. Jednak integracja kultur organizacyjnych była trudna, a priorytety biznesowe różne. AOL bardziej zależało na własnym portalu i usługach abonamentowych niż na technologicznym wyścigu z Microsoftem.

Rozwój Navigatora spowolnił, decyzje produktowe się rozmywały, a rynek coraz wyraźniej przechodził na stronę Internet Explorera. Netscape szukał innej drogi: jeśli nie da się wygrać klasycznymi metodami, może czas otworzyć kody i zbudować wokół nich społeczność?

Otwarcie kodu – projekt Mozilla jako eksperyment

W 1998 roku Netscape ogłosił, że udostępni kod swojego oprogramowania jako open source i powoła projekt Mozilla. Dziś brzmi to jak klasyczna strategia: „uwolnijmy kod, zbudujmy społeczność, iterujmy szybko”. W tamtym czasie było to posunięcie odważne i dość ryzykowne.

Początkowo zakładano, że baza kodu Netscape’a zostanie po prostu „otwarta”, a społeczność pomoże ją poprawić, posprzątać i rozwinąć. Rzeczywistość okazała się boleśniejsza:

• kod Navigatora był mocno złożony, z licznymi zależnościami i „długiem technicznym”,
• dokumentacja nie zawsze nadążała za implementacją, co utrudniało zewnętrznym programistom wejście w projekt,
• równoległe prace nad produktem komercyjnym Netscape’a wprowadzały napięcia w priorytetach.

Dość szybko zapadła decyzja: zamiast łatać stare fundamenty, lepiej zbudować silnik przeglądarki od nowa. Tak narodził się Gecko – nowy engine renderujący, projektowany z myślą o lepszym wsparciu dla standardów i przenośności między platformami. To wydłużyło czas dostarczenia gotowego produktu, ale dało solidniejszą podstawę na kolejne lata.

Narodziny gecko, suite Mozilli i problem „za ciężkiego wszystkiego”

Pierwsze publiczne wersje opierające się na Gecko przybrały formę pełnego pakietu: przeglądarka, klient poczty, chat, composer HTML – wszystko w jednym. Mozilla Application Suite (często po prostu „Mozilla”) była imponująca pod względem funkcji, lecz dla wielu użytkowników zwyczajnie za duża i zbyt wolna.

W porównaniu z lekkim (przynajmniej z pozoru) IE, który „po prostu był” w systemie, instalacja dużego pakietu tylko po to, żeby mieć inną przeglądarkę, nie porywała mas. Za to wśród programistów i bardziej zaawansowanych użytkowników Mozilla zaczęła budzić sympatię:

• miało to być narzędzie „po stronie standardów”,
• otwarty kod pozwalał na eksperymenty i rozszerzenia,
• wspierano wieloplatformowość – Windows, Linux, macOS.

To właśnie z tej grupy przyszła idea: rozbić monolit na mniejsze, wyspecjalizowane aplikacje, które będą bardziej strawne dla zwykłego użytkownika. Pakiet pakietem, ale rynek domagał się prostego „okienka do Internetu”, które włączy się szybciej niż czajnik z wodą.

Od suite do Firefoksa – podejście „przeglądarka przede wszystkim”

W ramach projektu Mozilla zaczęły się pojawiać inicjatywy zmierzające do wydzielenia samej przeglądarki i uproszczenia interfejsu. Jednym z najważniejszych efektów była aplikacja, która początkowo nazywała się Phoenix, potem Firebird, aż w końcu przyjęła znaną dziś nazwę Firefox.

Kluczowe założenia Firefoksa były celnie wymierzone w słabości ówczesnego IE:

• lekkość i szybkość – pozbycie się balastu niepotrzebnych modułów, skupienie na samym przeglądaniu stron,
• wspieranie standardów – bardzo dobra implementacja CSS, DOM i JavaScriptu, zbliżona do specyfikacji W3C,
• rozszerzalność – system dodatków (extensions), pozwalający użytkownikom dostosować przeglądarkę do swoich potrzeb.

To ostatnie okazało się jednym z największych atutów. Możliwość zainstalowania blokady reklam, narzędzi developerskich, menedżera haseł czy integracji z ulubionymi usługami sprawiała, że Firefox szybko zdobywał fanów wśród power userów. W czasach, gdy IE był praktycznie niezmienny z wersji na wersję, elastyczność Firefoksa robiła różnicę.

Dla front-end developerów Firefox stał się z kolei narzędziem referencyjnym: jeśli coś działało poprawnie w Firefoksie zgodnie ze standardem, a w IE nie – łatwo było zidentyfikować, po której stronie leży problem. Pojawienie się dodatków typu Firebug (protoplasta dzisiejszych DevTools) zrewolucjonizowało debugowanie JavaScriptu i stylów. Po latach programowania „na ślepo” nagle można było podejrzeć DOM, podglądać żądania HTTP, modyfikować CSS w locie. Dla wielu osób był to moment „jak to, można tak było od początku?”.

Mozilla Foundation i nowy model rozwoju przeglądarki

Aby uniezależnić projekt od polityki korporacyjnej AOL/Netscape, w 2003 roku powołano Mozilla Foundation – organizację non-profit odpowiedzialną za rozwój przeglądarki i pokrewnych technologii. Choć w praktyce spora część finansowania pochodziła z umów z wyszukiwarkami (przede wszystkim z Google, które płaciło za domyślne pole wyszukiwania), formalna niezależność miała znaczenie symboliczne i operacyjne.

Nowy model pozwolił na:

• ustalanie roadmapy w oparciu o potrzeby użytkowników i społeczności open source, a nie priorytety pojedynczego właściciela,
• przyciąganie kontrybutorów z całego świata, w tym firm, które widziały w zdrowym ekosystemie przeglądarek swój interes,
• bardziej przewidywalny cykl wydań, z częstszymi aktualizacjami i szybszym reagowaniem na problemy bezpieczeństwa.

Firefox, rozwijany już pod szyldem fundacji, zaczął realnie odbierać udziały Internet Explorerowi, szczególnie wśród użytkowników domowych i w środowisku technicznym. Dla Webu oznaczało to powrót konkurencji – ale tym razem o nieco innym charakterze. Zamiast „kto doda więcej własnych tagów”, stawką stało się „kto lepiej i szybciej zaimplementuje standardy oraz zaoferuje wygodniejsze narzędzia”.

Druga fala konkurencji: Opera, Safari i presja „małych graczy”

Opera – przeglądarka, która była zbyt wcześnie „do przodu”

Równolegle do pojedynku IE–Mozilla rozwijała się Opera, często pomijana w masowych narracjach, ale bardzo wpływowa technicznie. Wywodząca się z Norwegii przeglądarka długo była produktem niszowym, lecz to właśnie tam testowano rozwiązania, które reszta świata poznała znacznie później.

Opera wcześnie eksperymentowała z:

• kartami – wygodne przełączanie wielu stron w jednym oknie (w czasach, gdy IE stawiało na osobne instancje okien),
• szybkim wybieraniem (Speed Dial) – ekranem startowym z ulubionymi stronami,
• gestami myszy – sterowaniem przeglądarką za pomocą ruchów kursora przy wciśniętym przycisku,
• silnym naciskiem na wydajność, szczególnie na słabszym sprzęcie i w sieciach o niskiej przepustowości.

Biznesowo Opera długo szukała swojego modelu: płatne licencje, wersje z reklamami, współpraca z producentami telefonów i urządzeń embedded. Choć globalny udział rynkowy na desktopie pozostawał niewielki, webdeveloperzy musieli się z nią liczyć – zwłaszcza, że silnik Presto był bardzo „standardowy” i bezlitośnie obnażał sztuczki pisane „pod IE”.

Opera stała się też poligonem testowym dla przeglądania mobilnego. Wersje Mini i Mobile, ze swoimi mechanizmami kompresji i proxy, były dla wielu użytkowników pierwszym sensownym sposobem na „prawdziwy Internet w telefonie”, zanim smartfony weszły do mainstreamu.

Safari i WebKit – ruch Apple w grze o Web

Kiedy Apple zdecydowało się zrezygnować z Internet Explorera jako domyślnej przeglądarki na macOS, pojawiło się pytanie: „to co w zamian?”. Odpowiedzią było Safari, oparte na silniku WebKit, który wyrósł z otwartego projektu KHTML (środowisko KDE).

Ten wybór miał kilka istotnych konsekwencji:

• Mac stał się poligonem dla WebKita – Apple intensywnie inwestowało w wydajność renderowania i JavaScriptu, co później zaowocowało szybkimi postępami także na innych platformach.
• Świat open source zyskał kolejnego silnego gracza – Apple kontrybuowało do WebKita, a równocześnie korzystało z pracy społeczności, co tworzyło ciekawą, czasem burzliwą, symbiozę.
• Ekosystem Apple zaczął się bardziej zamykać wokół własnej przeglądarki – na iOS silnik WebKit stał się obowiązkowy dla wszystkich browserów, nawet jeśli miały inną „markę” (np. mobilny Chrome).

Dla twórców stron oznaczało to pojawienie się kolejnego ważnego punktu odniesienia. Testowanie „IE + Firefox + Opera” przestało wystarczać – do zestawu dołączyło Safari, które wprowadzało własne interpretacje niektórych rozwiązań CSS i JS. Nie były to już jednak dzikie odchyłki w stylu „nasz własny tag <marquee>”, tylko różnice w tempie implementacji i drobnych detalach specyfikacji.

Standardy w centrum: Acid, W3C i rosnące oczekiwania wobec przeglądarek

Kiedy liczba poważnych graczy wzrosła, a Web rósł w tempie wykładniczym, coraz trudniej było udawać, że każdy silnik może „po swojemu” interpretować HTML i CSS. Potrzebne były narzędzia, które jasno pokazywałyby, kto jak daleko odbiegł (lub nadąża) za specyfikacją.

Tę rolę spełniły testy Acid – proste z pozoru strony, które w praktyce były skomplikowanym zestawem przypadków brzegowych:

• Acid1 i Acid2 sprawdzały przede wszystkim zgodność z CSS i modelem pudełkowym,
• Acid3 dołożył testy JavaScriptu, DOM i SVG, przypominając przeglądarkom, że świat nie kończy się na „ładnym box-modelu”.

Deweloperzy Safari i Opery ochoczo chwalili się kolejnymi punktami procentowymi w tych testach, Mozilla robiła swoje, a Microsoft – przynajmniej przez długi czas – wyglądał, jakby nie do końca był zainteresowany pogonią. Z perspektywy front-endu miało to prosty efekt: coraz wyraźniej powstawał podział na „przeglądarki nowej generacji” oraz IE, który zostawał w tyle.

Do gry aktywniej weszło też W3C oraz inicjatywy pokrewne, takie jak WHATWG, które zaczęło pracę nad HTML5 bardziej ewolucyjnie, w oderwaniu od sztywnego, jednorazowego „domknięcia” specyfikacji. Zamiast czekać dekadę na kolejną wielką wersję, specyfikacje zaczęły funkcjonować jako żywe dokumenty, aktualizowane wraz z rozwojem przeglądarek.

Wejście Google: narodziny Chrome i trzecia wielka wojna przeglądarek

Dlaczego Google w ogóle zbudował własną przeglądarkę

Na początku lat 2000 Google był już gigantem wyszukiwania, ale działał w środowisku kontrolowanym przez cudze przeglądarki. Strony Google, w tym coraz bardziej złożone aplikacje (Gmail, Google Maps, Dokumenty), musiały radzić sobie z ograniczeniami silników, które nie zawsze nadążały za ich ambicjami.

W firmie pojawiło się kilka pragmatycznych pytań:

• Jak zapewnić szybkie i stabilne działanie coraz cięższych aplikacji webowych?
• Jak kontrolować środowisko uruchomieniowe dla JavaScriptu, na którym bazują całe usługi?
• Jak przyspieszyć wdrażanie nowych API (np. offline, lokalne przechowywanie danych), skoro inni producenci mają własne priorytety?

Odpowiedzią stał się projekt Google Chrome, zaprezentowany w 2008 roku. Był to moment, w którym wiele osób sądziło, że „karty rozdane, Firefox walczy z IE, reszta to dodatki”. Chrome pokazał, że talia może zostać przetasowana jeszcze raz, i to bardzo brutalnie.

Architektura Chrome: procesy, sandbox i V8

Chrome od początku stawiał na inżynierską przejrzystość. Zastosowano kilka decyzji projektowych, które mocno odróżniały go od konkurencji:

• architektura wieloprocesowa – każda karta (tab) mogła działać w osobnym procesie, izolowana od innych. Jeśli jedna strona „wybuchała”, nie ciągnęła za sobą całej przeglądarki;
• sandboxing – procesy renderujące działały w piaskownicy z ograniczonymi uprawnieniami, co znacząco utrudniało wykorzystanie luk bezpieczeństwa do przejęcia systemu;
• nowy silnik JavaScript – V8 – projektowany z myślą o maksymalnej wydajności, z kompilacją JIT (just-in-time), optymalizacjami i garbage collectorem dostosowanym do ciężkich aplikacji webowych.

Testy wydajności w tamtym czasie pokazywały niemal szokujące różnice w szybkości wykonywania JavaScriptu między Chrome a konkurencją. Dla użytkownika przekładało się to na subiektywne wrażenie: „to jest po prostu szybsze”, szczególnie na stronach mocno naszpikowanych skryptami.

Dla programistów oznaczało to zielone światło na jeszcze śmielsze pomysły w przeglądarce. Jeśli ktoś wcześniej zastanawiał się, czy „to nie za dużo jak na JavaScript w 2008 roku”, po V8 odpowiedź coraz częściej brzmiała: „już nie”.

Chrome i WebKit/Chromium – „otwarty” rdzeń, zamknięta strategia

Google nie budował wszystkiego od zera. Rdzeń renderujący oparł na WebKicie, a cały projekt udostępnił jako Chromium – otwartą bazę kodeu służącą jako fundament dla Chrome i innych przeglądarek, które zechcą go wykorzystać.

Ten model miał kilka ciekawych skutków:

• producenci mniejszych przeglądarek mogli zrezygnować z własnych silników i przejść na Chromium, skupiając się na interfejsie i dodatkach,
• Google zyskał pozycję technicznego lidera – to on dyktował tempo rozwoju silnika, a pozostali ścigali się, by nadążyć z integracją zmian,
• społeczność open source otrzymała wpływu na kod, ale niekoniecznie na strategiczny kierunek produktu końcowego (Chrome).

Z czasem ten model doprowadził do zjawiska, które można nazwać „webkit/chrOmium-centrismem”: jeśli jakaś funkcja była dobrze wspierana w Chrome, twórcy stron szybko uznawali ją za domyślną, a brak obsługi w innych przeglądarkach bywał traktowany jako „problem tamtej przeglądarki”, nie zaś wybór projektowy czy różnica w tempie standaryzacji.

Agresywna dystrybucja i automatyczne aktualizacje

Chrome wygrał nie tylko techniką. Ogromną rolę odegrał sposób dystrybucji:

• bundle z innym oprogramowaniem – instalator Chrome pojawiał się przy różnych popularnych aplikacjach, od przeglądarek do PDF po komunikatory,
• promocja na stronie głównej Google – „pobierz szybszą przeglądarkę” widziały codziennie miliony ludzi,
• automatyczne, ciche aktualizacje – użytkownicy niemal zawsze mieli najnowszą wersję, bez ręcznego ściągania instalatorów.

Ten ostatni element był szczególnie przełomowy z perspektywy webdeveloperów. Zamiast wspierać trzy–cztery „wiecznie żywe” wersje przeglądarki (jak to bywało z IE), można było w praktyce zakładać, że większość użytkowników Chrome ma wydanie nie starsze niż kilka miesięcy.

Z czasem podobny model przyjęły także inne projekty, w tym Firefox, ale to Chrome najszybciej zbudował reputację przeglądarki, która „zawsze jest aktualna”. Miało to oczywiście swoją ciemną stronę: jeśli jakaś zmiana łamała zachowanie istniejących aplikacji, potrafiła „przetoczyć się” przez cały Internet w ciągu paru dni.

Rynek reaguje: odpowiedź Microsoftu i Mozilli

Dominacja Chrome, rosnąca niemal z roku na rok, wymusiła reakcję dotychczasowych graczy.

Microsoft po latach utrzymywania IE w stanie konserwacji zdecydował się na poważniejszy krok. Pojawił się Internet Explorer 9, a później 10 i 11, z dużo lepszym wsparciem standardów i poważnymi pracami nad wydajnością. Jednak piętno IE6 i ciężar kompatybilności z aplikacjami intranetowymi był tak duży, że zaufanie developerów odzyskiwało się bardzo wolno.

W końcu Microsoft zdecydował się na radykalny ruch: Edge. Najpierw jako przeglądarka z własnym silnikiem (EdgeHTML), a później – po kilku latach – jako produkt oparty na Chromium, z zachowaniem własnego interfejsu i integracji z Windows. Tym samym firma, która kiedyś dominowała dzięki własnemu silnikowi, postanowiła wejść do obozu technologii rozwijanej przez konkurenta.

Mozilla z kolei postawiła na Firefox Quantum, głęboką przebudowę przeglądarki, obejmującą nowy silnik CSS (Stylo), lepszą wielowątkowość i bardziej agresywne podejście do wydajności. Jednocześnie fundacja mocno akcentowała kwestie prywatności i otwartości, pozycjonując Firefoksa jako kontrę dla coraz szerzej krytykowanego ekosystemu Google.

Na poziomie odczuć wielu developerów zrobiło się trochę paradoksalnie: z jednej strony Chrome był „złotym wzorcem” implementacji nowych API, z drugiej – coraz częściej pojawiało się pytanie, czy zbliżanie się do monokultury jest dobrym pomysłem w długim terminie.

Web jako platforma aplikacyjna: AJAX, HTML5 i eksplozja możliwości

Od statycznych stron do aplikacji jednopage’owych

Na tle wojny przeglądarek zmieniała się sama natura Webu. Początkowo strony były głównie dokumentami z odrobiną interaktywności. Potem pojawił się AJAX, który pozwalał na asynchroniczne pobieranie danych bez przeładowania strony – i nagle okazało się, że przeglądarka może pełnić rolę pełnoprawnej platformy aplikacyjnej.

Tego typu podejście spopularyzowały m.in. Gmail i Google Maps, a w ślad za nimi cała fala webaplikacji:

• poczta, która przypominała klienta desktopowego,
• edytory dokumentów i arkuszy kalkulacyjnych działające w oknie browsera,
• bogate panele administracyjne i dashboardy, które tradycyjnie kojarzyły się z aplikacjami natywnymi.

Biblioteki takie jak jQuery stały się niemal nieodłącznym elementem toolboxu front-endowca. Jego główną zaletą była nie tyle „magia” animacji, co większa spójność API ponad różnymi przeglądarkami. Zamiast pamiętać, który browser jak implementuje zdarzenia czy manipulację DOM, można było pisać w oparciu o bardziej jednolity interfejs.

Najczęściej zadawane pytania (FAQ)

Jak wyglądał Internet przed przeglądarkami typu Netscape czy Internet Explorer?

Przed epoką przeglądarek graficznych Internet przypominał raczej ogromny katalog plików niż kolorową sieć stron. Użytkownicy łączyli się przez terminal tekstowy, wpisywali komendy i korzystali z narzędzi takich jak telnet, FTP, Gopher czy klienci Usenetu. Nie było „stron www” z obrazkami i przyciskami, były dokumenty i listy plików.

Większość ludzi nie miała z tym kontaktu – dostęp do sieci mieli głównie naukowcy, wojskowi i administratorzy. Żeby coś przeczytać lub pobrać, trzeba było znać konkretny adres, komendę i obsługę danego programu. „Surfowanie” polegało więc na skakaniu po katalogach, a nie klikaniu w linki.

Czym różnił się Gopher od World Wide Web (WWW)?

Gopher oferował hierarchiczne menu tekstowe: użytkownik przechodził po drzewie katalogów i wybierał pozycje z listy. Był szybki i prosty, ale mało elastyczny – trudno było tworzyć złożone układy treści, wszystko było w formie tekstu i list.

World Wide Web wprowadził hipertekst: linki, które można było dowolnie łączyć między dokumentami, a nie tylko sztywne menu. WWW opierał się na trzech filarach: protokole HTTP, formacie HTML i adresach URL. Dzięki temu sieć stała się bardziej „płaska” i swobodna – można było przechodzić z jednej strony do drugiej bez wracania do nadrzędnego menu, jak w Gopherze.

Dlaczego Mosaic był takim przełomem dla Internetu?

Mosaic był jedną z pierwszych popularnych przeglądarek graficznych, która w jednym oknie wyświetlała tekst i obrazki (inline), a do tego oferowała przyciski typu Back, Forward czy Bookmarks. Dla kogoś przyzwyczajonego do czarnego terminala był to skok jakościowy – Internet nagle „pojawił się na ekranie”, zamiast żyć w linijce poleceń.

Prosty interfejs z ikonami i paskiem adresu sprawił, że z sieci mogli zacząć korzystać ludzie bez technicznego zaplecza. Nie trzeba było znać FTP ani struktury katalogów na serwerze; wystarczył link. To otworzyło drogę do upowszechnienia się Webu poza środowiskiem akademickim.

Skąd się wziął Netscape Navigator i dlaczego tak szybko zdominował rynek?

Netscape Navigator wyrósł bezpośrednio z doświadczeń zespołu tworzącego Mosaic w NCSA. Marc Andreessen i kilku współautorów opuściło środowisko akademickie, założyło firmę Netscape Communications i postawiło na komercyjną przeglądarkę rozwijaną w szybkim tempie. Celem było proste: zostać domyślną bramą do Internetu dla zwykłych użytkowników i firm.

Netscape szybko zdobył przewagę dzięki:

• dostępności na wielu systemach (Windows, Mac, Unix),
• agresywnej dystrybucji (płyty CD w czasopismach, pakiety od dostawców Internetu),
• modelowi „darmowa lub tania przeglądarka, zarobek na rozwiązaniach dla firm”.

W połowie lat 90. Navigator miał przytłaczający udział w rynku – dla wielu osób ikona Netscape’a była równoznaczna z ikoną Internetu.

Na czym polegał model biznesowy Netscape – skoro przeglądarka była darmowa?

Netscape stawiał na strategię „get big fast”: najpierw zdobyć użytkowników, potem monetyzować ekosystem. Przeglądarka była darmowa lub bardzo tania dla osób prywatnych, co pomagało w szybkim rozprzestrzenianiu się produktu. Firmy płaciły natomiast za licencje, wsparcie, serwery webowe i narzędzia do tworzenia oraz utrzymania stron.

Dzięki temu Netscape kontrolował nie tylko „okno” po stronie użytkownika, ale też część infrastruktury po stronie serwera. Im więcej osób korzystało z Navigatora, tym chętniej twórcy stron i przedsiębiorstwa wybierali rozwiązania Netscape’a – koło się zamykało. Brzmi znajomo w kontekście współczesnych ekosystemów Big Tech, prawda?

Jakie techniczne nowości Netscape wprowadził do Webu?

Netscape nie ograniczał się do wdrażania istniejących standardów – często je wyprzedzał, dodając własne rozszerzenia do HTML. To stąd wzięły się m.in. znaczniki <font>, <blink> czy rozbudowane możliwości formularzy i ramek. Dawało to webmasterom większą kontrolę nad wyglądem stron, choć kosztem zgodności między różnymi przeglądarkami.

Ważnym wkładem Netscape’a był też udział w powstaniu JavaScriptu (początkowo LiveScript) – języka skryptowego działającego po stronie przeglądarki. Dzięki niemu strony zaczęły reagować na działania użytkownika bez przeładowywania, co było pierwszym krokiem od statycznych dokumentów w stronę interaktywnych aplikacji webowych.

Dlaczego pojawienie się graficznych przeglądarek było tak ważne dla rozwoju Internetu jako medium masowego?

Graficzne przeglądarki schowały pod maską całą złożoność protokołów, portów i ścieżek katalogów. Nagle zwykły użytkownik mógł „wejść do Internetu” jednym kliknięciem w ikonę na pulpicie i poruszać się po sieci za pomocą myszki, linków i przycisków, zamiast uczyć się obsługi kilku różnych narzędzi tekstowych.

To gwałtownie obniżyło próg wejścia i zachęciło firmy, media oraz instytucje do inwestowania w obecność w sieci. Dopiero w tym momencie wybór przeglądarki zaczął mieć realne znaczenie biznesowe – kto kontrolował domyślną przeglądarkę na komputerze użytkownika, ten kontrolował dostęp do sklepów, reklam i usług online.

Kluczowe Wnioski

• Przed erą przeglądarek graficznych Internet był światem tekstu i terminali – bliżej mu było do zdalnego systemu plików niż do dzisiejszego „surfowania po sieci”.
• Narzędzia takie jak telnet, FTP, Gopher czy Usenet wymagały znajomości komend, więc realnie korzystali z nich głównie technicy, naukowcy i administratorzy.
• World Wide Web Tima Bernersa-Lee połączył HTTP, HTML i URL w spójną całość, wprowadzając hipertekst i klikalne linki jako nowy sposób nawigacji po zasobach Internetu.
• Pojawienie się graficznych przeglądarek (od WorldWideWeb/Nexus po Mosaic) zamieniło suchy tekst w „wizualny” Internet, choć sam HTML był wtedy skrajnie prosty i statyczny.
• GUI obniżyło próg wejścia do sieci – zamiast komend pojawiły się paski adresu, przyciski Back/Forward i myszka, co otworzyło drogę do masowego użycia Internetu.
• Netscape Navigator, jako komercyjny następca Mosaic, zdominował w połowie lat 90. rynek przeglądarek, stając się dla wielu użytkowników synonimem samego Internetu.
• Moment, w którym przeglądarka stała się „bramą do wszystkiego”, sprawił, że kontrola nad nią nabrała strategicznego znaczenia biznesowego i przygotowała grunt pod wojny przeglądarek.

Bibliografia i źródła

• Where Wizards Stay Up Late: The Origins of the Internet. Simon & Schuster (1996) – Historia ARPANET-u, protokołów NCP i TCP/IP, wczesnej sieci
• A Brief History of the Internet. Internet Society (1997) – Rozwój Internetu, ARPANET, TCP/IP, wczesne usługi sieciowe
• The World Wide Web: Past, Present and Future. CERN (1990) – Tekst Tima Berners-Lee o koncepcji WWW, HTTP, HTML i URL
• Weaving the Web: The Original Design and Ultimate Destiny of the World Wide Web. HarperCollins (1999) – Autobiograficzna relacja Berners-Lee z tworzenia WWW i pierwszych przeglądarek