Mroczne początki mobilnego internetu, czyli jak wyglądała era przed iPhone'em

Wydaje ci się, że debugowanie aplikacji mobilnych potrafi dziś doprowadzić do szału? Wyobraź sobie, przez co przechodzili deweloperzy budujący strony na komórki pod koniec lat dziewięćdziesiątych. Zanim iPhone odmienił wszystko w 2007 roku, istniała chaotyczna epoka, gdy "internet mobilny" oznaczał walkę z ekranikami wielkości pudełka od zapałek, własnościowymi językami znaczników i prędkościami połączeń, przy których nawet starutek modem 56k wyglądałby jak światłowód.

Przejście z internetu stacjonarnego do mobilnego nie było po prostu aktualizacją — to była całkowita reinwencja tego, co mogło oznaczać korzystanie z sieci. I szczerze? Większość wczesnych prób była niedopracowana w sposób, który do dziś wpływa na to, jak tworzymy projekty mobilne.

Dlaczego mobilny internet kuleje od samego początku

Kiedy tradycyjny internet stawał się masowy, miał czas, żeby dojrzeć. Studenci i uczelnie testowali wczesne protokoły, szlifując problemy zanim cokolwiek dotarło do zwykłych ludzi. Kiedy wreszcie wskoczyły firmy, technologia była już ustabilizowana.

Mobilny internet wystartował zupełnie inaczej — skierowany do ogółu społeczeństwa od pierwszego dnia, z kosztami transmisji danych wliczonymi w każdy megabajt. To natychmiast wywołało tarcia. Użytkownicy oczekiwali internetu, który znali, ale deweloperzy dostarczyli jedynie przerobione wersje stron desktopowych, które po prostu nie działały na małych urządzeniach.

Wyzwania techniczne były potężne:

• Ekrany wielkości wizytówki sprawiały, że tradycyjne układy stron stawały się bezużyteczne
• Ograniczona moc obliczeniowa oznaczała, że JavaScript po stronie klienta był mrzonką
• Przerywane połączenia kłóciły się z bezstanową naturą HTTP
• Ograniczenia baterii wymuszały, żeby każdy bajt walczył o swoje miejsce w transmisji

To nie był problem skalowania — to był fundamentalny problem przeprojektowania. Większość wczesnych treści mobilnych to były desktopowe strony zaadaptowane, a nie koncepcje stworzone od podstaw z myślą o mobile.

Wojny protokołów: rozdrobniony krajobraz

Zanim HTML5 stał się uniwersalnym standardem, mobilny internet był patchworkiem konkurujących ze sobą technologii. Każdy gracz próbował rozwiązać te same problemy kompletnie innymi metodami.

AT&T PocketNet (1996) — Era "Talii Kart"

Usługa PocketNet od AT&T wprowadziła interesującą metaforę, która będzie rezonować przez całą historię mobilnego rozwoju: model talii kart. Ponieważ telefony komórkowe miały tak ograniczone wyświetlacze, interakcje stały się dialogowe. Użytkownicy robili wybory, które prowadziły do kolejnych opcji, każda decyzja zawężała ścieżkę dalej.

Innowacją tu było grupowanie — wszystkie "karty" z talii można było wysłać w jednej transakcji, redukując ból latencji przy wolnych połączeniach. Treści były dostarczane przez Handheld Device Markup Language (HDML), czyli zubożałego krewnego HTML-a, z mikroprzeglądarką UP.View zajmującą się renderowaniem.

To była sprytna inżynieria, ale też własnościowe rozwiązanie. Rozdrobnienie już się zaczęło.

Palm.Net WebClipping (1998) — Wczesne triumfy optymalizacji

Palm poszedł inną drogą, uznając, że PDA mają więcej przestrzeni ekranowej niż telefony, ale wciąż potrzebują optymalizacji. Ich technologia WebClipping cache'owała statyczne treści internetowe na samym urządzeniu, transmitując przez powietrze tylko treści dynamiczne.

To była essentially edge computing zanim w ogóle nadano temu nazwę. Redukując niepotrzebne transfery danych, Palm udowodnił, że mobilny internet może być szybki — jeśli tylko ktoś był gotów przemyśleć założenia o przepływie treści.

NTT DoCoMo i-mode (1999) — Azjatycka historia sukcesu

Tu robi się ciekawie. Podczas gdy WAP miał spektakularną porażkę w Europie i Ameryce Północnej, i-mode od NTT DoCoMo stało się ogromnym sukcesem w Japonii, ostatecznie osiągając ponad 52 miliony użytkowników na całym świecie.

Co sprawiło, że i-mode było inne? Kilka czynników zgrało się idealnie:

1. Dane pakietowe od pierwszego dnia — to było technicznie lepsze niż podejścia z komutacją obwodową, których używali inni
2. Dedykowany przycisk sprzętowy — jednoklikowy dostęp do wyselekcjonowanego portalu eliminował tarcie
3. Ekosystem partnerów — DoCoMo zajmowało się fakturowaniem, redukując bariery dla dostawców treści
4. Atrakcyjne treści — tysiące oficjalnych stron, odkrywalne przez portal

Zestaw funkcji i-mode czyta się jak list życzeń mobile-first, których pełną realizację osiągnęliśmy dopiero kolejną dekadę później: klawisze dostępu do nawigacji, skróty do numerów telefonów, wsparcie dla emoji. Celowo pominięto też tabele, mapy obrazkowe i arkusze stylów — funkcje, które dodawały złożoności bez wartości na małych ekranach.

WAP — Otwarty standard, który otwarty nie był

Wireless Application Protocol wystartował w 1999 jako "otwarty międzynarodowy standard" wspierany przez Nokię, Ericsson, Motorolę i Openwave. Obietnica brzmiała: ujednolicony mobilny dostęp do internetu na wszystkich urządzeniach i sieciach.

Rzeczywistość była... inna. WAP stał się synonimem frustracji, zyskując przydomki takie jak "Wait And Pay" (Czekaj i Płać) i "Worthless Application Protocol" (Bezwartościowy Protokół Aplikacji). Dlaczego?

Częściowo przez timing — sieci 2G nie były zaprojektowane pod transmisję pakietową, a stos WAP dodawał narzut, który sprawiał, że i tak wolne połączenia stawały się jeszcze gorsze. Częściowo przez wykonanie — standard był skomplikowany, a implementacje różniły się diametralnie. I częściowo przez biznes — operatorzy kontrolowali doświadczenie, rozdzierając to, co powinno być jednolitym internetem.

Ironia jest taka, że cele WAP były słuszne. Po prostu potrzebowaliśmy lepszej technologii (3G, smartfony) i lepszych modeli biznesowych (płatne transfery danych, otwarte sklepy z aplikacjami), żeby je zrealizować.

Lekcje, które wciąż mają znaczenie

Patrząc wstecz na tamtą erę, wyłaniają się wzorce, które pozostają aktualne dla każdego, kto buduje rozwiązania mobilne:

1. Mobile to nie desktop — nigdy nie było. Pokusa przenoszenia istniejących rozwiązań na nowe formy jest silna. Wczesne porażki mobilnego internetu właśnie z tego założenia wynikały. Responsive design, progresywne aplikacje webowe i metodologia mobile-first — wszystko to istnieje, bo wreszcie nauczyliśmy się tej lekcji.

2. Założenia o łączności padają na mobile. Model request-response HTTP zakładał trwałe połączenia. Sieci mobilne tak nie działają. Dziś service workers, architektury offline-first i edge computing — wszystko to wyrasta z akceptacji tej rzeczywistości.

3. Modele biznesowe kształtują adopcję technologii. i-mode odniosło sukces częściowo dlatego, że DoCoMo zajmowało się fakturowaniem, usuwając tarcie dla deweloperów i użytkowników. Stripe, zakupy w aplikacjach i subskrypcje SaaS istnieją, bo nauczyliśmy się, że komplikacje płatnicze zabijają zaangażowanie.

4. Otwarte standardy wygrywają ostatecznie. Własnościowa natura WAP była jego zgubą. Internet odniósł sukces, bo każdy mógł na nim budować. Mobilność odniosła sukces, gdy przeglądarki stały się zgodne ze standardami, a sklepy z aplikacjami otworzyły się dla deweloperów.

Gdzie jesteśmy teraz

Mobilny internet przeszedł długą drogę od tamtych wczesnych dni. Mamy teraz responsywne układy, które adaptują się do każdego ekranu, service workers umożliwiające działanie offline, powiadomienia push przywracające użytkowników, i API łączności pomagające aplikacjom reagować na warunki sieciowe.

Ale podstawowe wyzwania pozostają zaskakująco spójne: ograniczenia przepustowości, przerywana łączność, różne rozmiary ekranów i wieczne napięcie między natywnymi doświadczeniami aplikacji a dostępnością webu.

Następna fala — 5G, WebAssembly, rozwój wspierany AI i być może Web3 — przyniesie nowe frameworki i paradygmaty. Ale fundamentalne pytanie zostaje to samo: jak dostarczać wartościowe doświadczenia przez coraz bardziej zróżnicowane urządzenia i połączenia?

To pytanie warto przemyśleć, niezależnie od tego, czy wdrażasz swoją pierwszą stronę docelową, czy architektonizujesz rozproszony system dla milionów użytkowników mobilnych.

Podróż mobilnego internetu od frustracji WAP do dzisiejszych doświadczeń przypomina nam, że innowacja rzadko przebiega po linii prostej. Czasem trzeba wydać niedoskonały produkt, wyciągnąć wnioski z jego porażek i iterować w kierunku czegoś, co naprawdę działa. Dotyczy to protokołów, platform i infrastruktury hostingowej, która je obsługuje.