Platforma sieciowa
Sieć powstała jako medium, które miało służyć do publikowania dokumentów naukowych, składających się głównie z tekstu. Ale wraz z upływem lat zmieniły się także wymagania, jakie przed nią stawiamy. Obecnie Sieć wyrosła na pełnoprawną platformę uruchomieniową. Mówiąc inaczej: stała się tak naprawdę konkurencją dla systemów operacyjnych. Obecnie większość rzeczy można zrobić, nie opuszczając przeglądarki. Są aplikacje do edytowania zdjęć (z Photoshopem włącznie), pisania tekstów (w tym sieciowa wersja Microsoft Office’a), tworzenia aplikacji internetowych (incepcja!)… W wielu przypadkach takie aplikacje starczają do codziennych zastosowań. I mają jedną przewagę nad swoimi desktopowymi odpowiednikami: nie wymagają żadnej instalacji i są dostępne zawsze. Sieć z miejsca dystrybucji dokumentów stała się miejscem, w którym da się pracować nad wszelkimi rzeczami.
Strony a aplikacje
Ta zmiana pociągnęła za sobą także i pojawienie się istotnego dylematu nomenklaturowego. Na początku Sieć składała się ze stron internetowych. Wraz z rozwojem technologicznym pojawił się termin aplikacja internetowa. I rozgorzała dyskusja na temat znaczenia każdego z tych terminów. Jednym z podejść jest rozgraniczenie na “czytanie rzeczy” (strony) oraz “robienie rzeczy” (aplikacje). I na swój sposób jest to intuicyjne. W przeglądarkowym Photoshopie robimy rzeczy – edytujemy zdjęcia – i nikt raczej nie ma wątpliwości, że to aplikacja. Tak samo dowolny portal z newsami jest typową stroną, na którą wchodzimy, by konsumować jakieś treści. Ale bardzo szybko okazuje się, że istnieją sytuacje niejasne, np. czytnik RSS-ów – czy to jeszcze strona, czy już aplikacja? Czy blog z możliwością komentowania wpisów jest jeszcze stroną, czy już wchodzi w zakres aplikacji? Być może mamy do czynienia tak naprawdę ze spektrum.
Robin Rendle idzie jeszcze dalej i dobitnie oznajmia, że aplikacje internetowe nie istnieją, a sam termin jest używany często do tego, żeby zignorować dbanie o dostępność czy responsywność. A przecież dla końcowej osoby użytkowniczej jedno i drugie jest tym samym. Ostatecznie i strona, i aplikacja powstają w tych samych technologiach i osoba użytkownicza wchodzi w nimi w interakcję w dokładnie taki sam sposób – przy pomocy przeglądarki. To rozróżnienie w dużej mierze ma sens wyłącznie dla osób tworzących strony i aplikacje internetowe. Może być wykorzystane pozytywnie i pomóc w doborze odpowiedniej technologii, ale może być także wykorzystane szkodliwie, do uzasadnienia braku dostępności.
Kompatybilność
Jedną z najważniejszych cech odróżniających Sieć od innych platform jest jej absurdalna wręcz kompatybilność wsteczna. W przypadku systemów operacyjnych dość trudno uruchomić obecnie aplikacje mające po 20 i więcej lat. 16-bitowa aplikacja z Windowsa 95 wymaga sporej gimnastyki, żeby ją uruchomić na 64-bitowym Windowsie 11. Natomiast w przypadku Sieci pierwsza strona WWW wciąż wyświetla się dobrze we współczesnych przeglądarkach. Spora w tym zasługa otwartych standardów sieciowych, które tworzone są w myśl zasady “nie psuć Sieci”. Ma to swoje minusy – do technologii sieciowych zwykle dokłada się nowe rzeczy, podczas gdy usunąć choćby najmniejszą jest niezwykle trudno. Ma to też swoje plusy: strona Space Jam z 1996 działa tak samo perfekcyjnie jak w 1996!
Ale absurdalna kompatybilność Sieci stanowi też niespotykane nigdzie indziej wyzwanie programistyczne. Gdy pisze się aplikację pod Windowsa 11, można z dużą dozą prawdopodobieństwa stwierdzić, co potrafi platforma, na jakiej zostanie uruchomiona nasza aplikacja. W przypadku Sieci można jedynie snuć domysły. Na rynku istnieje co najmniej kilka silników przeglądarek (Blink, WebKit, Gecko) i każdy z nich implementuje inny wycinek standardów sieciowych. Tak, spora część z nich się pokrywa, ale w niektórych miejscach występują rozbieżności (na was patrzę, tabelki), w innych czają się błędy. Niektóre przeglądarki nie wspierają jakichś technologii z etycznych powodów, inne od lat czekają, żeby ktoś się nimi zainteresował i je wdrożył (jak np. element() w CSS-ie). Wreszcie – nawet jeśli wszystkie silniki implementują potrzebne nam ficzery, nie wiemy, czy osoba użytkownicza ma odpowiednią wersję przeglądarki. I jest to problemem nawet w przypadku samoaktualizujących się przeglądarek. Można by rzecz z przekąsem, że Sieć dba o kompatybilność na poziomie standardów, ale też – niejako wymusza myślenie o niej wśród osób webdeveloperskich.
Na szczęście Sieć istnieje już na tyle długo, że środowisku udało się wypracować odpowiednie techniki radzenia sobie z tego typu problemami. Jedną z najbardziej uznanych jest bez wątpienia Progressive Enhancement. Ale przecież również responsywność wpisuje się w taki sposób myślenia. Wszak dzięki niej strony mogą działać dobrze na (niemal) dowolnym urządzeniu. Tego typu praktyki są istotne choćby dlatego, że, w zależności od grupy odbiorczej strony, wciąż można natknąć się na żywe trupy pokroju Internet Explorera.
Technologiczny skok
Nie da się ukryć, że obecne możliwości platformy sieciowej pozwalają jej w wielu przypadkach zastąpić aplikacje natywne. Ba, doszliśmy do momentu, w którym Internet i Sieć – przynajmniej z technologicznego punktu widzenia – nie są już synonimami. W końcu aplikacje internetowe mogą działać całkowicie offline.
Jednak tempo zmian nie zwalnia, można wręcz powiedzieć, że przyśpiesza. Jak zauważa Alex Russell, Sieć musi ewoluować, żeby pozostać konkurencyjna. Jeśli zostanie w tyle w porównaniu do systemów operacyjnych, to nikt nie będzie miał powodu, żeby tworzyć aplikacje internetowe zamiast aplikacji natywnych. Jednym z przejawów takiego myślenia jest projekt Fugu – mający na celu rozszerzenie możliwości przeglądarki Chromium, często w dość eksperymentalnych obszarach. Jednym z tych obszarów jest komunikacja z aplikacjami natywnymi, dzięki czemu obydwa te światy mogą ze sobą współpracować. Kolejnym obszarem jest komunikacja z hardware’em. Jednak takie rozszerzanie możliwości przeglądarek budzi dość zrozumiałe obawy o bezpieczeństwo i prywatność osób użytkowniczych. Czy przeglądarka powinna być w stanie odczytywać dane z urządzeń podłączonych po USB? A jeśli tak, to czy i jak pytać o pozwolenie osobę użytkowniczą? A może oddać tę kontrolę w ręce osoby webdeveloperskiej? Niestety, sporo z tych pytań, jak i nowych technologii, utyka w polityce. Podczas gdy jedni chcą pchać Sieć do przodu jak najszybciej, inni wolą powolne zmiany lub wręcz ich brak w niektórych obszarach. Kto ma rację? Osobiście bliżej mi do nieustannego parcia do przodu, ale nie mogę nie zauważyć, że często przy tym cierpi prywatność i bezpieczeństwo. Być może kiedyś uda się wypracować kompromisowy model, w którym znajdzie się miejsce zarówno na dynamiczny rozwój Sieci, jak i dbanie o bezpieczeństwo i prywatność osób użytkowniczych. Na ten moment jednak mamy wojnę pozycyjną i nikt nie chce zmienić swojego twardego stanowiska.
Są też i osoby, które widziałyby raczej rewolucję niż ewolucję Sieci. Douglas Crockford, twórca JSON-a i jedna z prominentnych postaci w świecie JS-a, twierdzi, że to pora, aby ten język pogrzebać i stworzyć coś nowego. Wtóruje mu Ian Hickson, który widziałby przejście na Sieć zbudowaną na WASM-ie. Czy tak się stanie? Nie wiem, ale osobiście raczej bym na to nie stawiał. Na ten moment platforma sieciowa jest niewyobrażalnie rozbudowana i rozwiązuje sporo technologicznych wyzwań i problemów. Odrzucenie lat pracy i doświadczeń może sprawić, że wiele z tych wyzwań powróci. No i całkiem nowa Sieć oznacza też zerwanie z kompatybilnością wsteczną i śmierć “starej” Sieci. A to raczej nie jest coś, czego ktokolwiek chciałby.
Ostateczna platforma
Sieć jest platformą niemal idealną. Raz stworzona aplikacja może działać na praktycznie dowolnym urządzeniu. W połączeniu z PWA aplikacje internetowe są w stanie powoli, ale skutecznie, wypychać aplikacje natywne z konkretnych nisz. Rownież najnowsze zmiany w podejściu regulatorów rynków cyfrowych zwiastują spore zamieszanie, zwłaszcza na mobilnych systemach operacyjnych. Być może właśnie stoimy na progu kolejnej sieciowej rewolucji.
Sieć ma szansę stać się platformą ostateczną. Fajnie byłoby jej nie zmarnować.
Źródła
- Addy Osmani, Photoshop is now on the web!. Enabled by WebAssembly, Web Components…, (data dostępu: ), w: Medium, (data dostępu: ).
- Jeremy Keith, By any other name, (data dostępu: ), w: Jeremy Keith, Adactio, (data dostępu: ).
- Robin Rendle, Web Apps Are Not A Thing, Please Stop, (data dostępu: ), w: Robin Rendle, Robin Rendle, (data dostępu: ).
- Jake Lazaroff, The Website vs. Web App Dichotomy Doesn't Exist, (data dostępu: ), w: Jake Lazaroff, jakelazaroff.com, (data dostępu: ).
- Jeremy Keith, Insecure, (data dostępu: ), w: Jeremy Keith, Adactio, (data dostępu: ).
- Barry T. Smith, Motherfucking Website, (data dostępu: ).
- Miriam Eric Suzanne, Tweet Miriam Eric Suzanne'y z 31.03.2021, (data dostępu: ), w: Twitter, (data dostępu: ).
- Brian Kardell, Web Engine Diversity and Ecosystem Health, (data dostępu: ), w: Brian Kardell, Brian Kardell, (data dostępu: ).
- Eric Bailey, “Evergreen” Does Not Mean Immediately Available, (data dostępu: ), w: CSS Tricks, (data dostępu: ).
- Michelle Barker, My Browser Support Strategy, (data dostępu: ), w: Michelle Barker, CSS { In Real Life }, (data dostępu: ).
- Adrian Roselli, Internet Explorer Still Does Not Go Away Today, (data dostępu: ), w: Adrian Roselli, Adrian Roselli, (data dostępu: ).
- Chris Nielsen, I Replaced My Native iOS App with a Cross-Platform Web App and No One Noticed, (data dostępu: ), w: Medium, (data dostępu: ).
- Paul Kinlan, The local-only web, (data dostępu: ), w: Paul Kinlan, Paul Kinlan, (data dostępu: ).
- Alex Russell, Platform Adjacency Theory, (data dostępu: ), w: Alex Russell, Infrequently Noted, (data dostępu: ).
- Ada Rose Cannon, Reduce the barrier between your Web App and Native Apps with one quick step., (data dostępu: ), w: Medium, (data dostępu: ).
- François Beaufort, Accessing hardware devices on the web, (data dostępu: ), w: web.dev, (data dostępu: ).
- Noam Rosenthal, Should The Web Expose Hardware Capabilities?, (data dostępu: ), w: Smashing Magazine, (data dostępu: ).
- Sam Sneddon, The Permissions Based Web, (data dostępu: ), w: Sam Sneddon, There Should Be No Red, (data dostępu: ).
- Paul Kinlan, The off by default web, (data dostępu: ), w: Paul Kinlan, Paul Kinlan, (data dostępu: ).
- Alex Russell, Progress Delayed Is Progress Denied, (data dostępu: ), w: Alex Russell, Infrequently Noted, (data dostępu: ).
- Honeypot, Why We Should Stop Using JavaScript According to Douglas Crockford (Inventor of JSON), (data uploadu: , data dostępu: ), w: YouTube, (data dostępu: ).
- Ian Hickson, Towards a modern Web stack, (data dostępu: ).
- Laurie Voss, You Will Never Be A Full Stack Developer, (data dostępu: ), w: Laurie Voss, Seldo.com, (data dostępu: ).
- Alex Russell, Why Are Tech Reporters Sleeping On The Biggest App Store Story?, (data dostępu: ), w: Alex Russell, Infrequently Noted, (data dostępu: ).
Dodatkowe materiały
- Chen Hui Jing, Internet Explorer 3, an adventure in cross-browser compatibility, (data dostępu: ), w: Chen Hui Jing, Chen Hui Jing, (data dostępu: ).
- Morten Rand-Hendriksen, Tweet Mortena Rand-Hendriksena z 22.08.2019, (data dostępu: ), w: Twitter, (data dostępu: ).
- Fronteers, Jeremy Keith & Remy Sharp - How We Built the World Wide Web in Five Days, (data uploadu: , data dostępu: ), w: Vimeo, (data dostępu: ).
- Jeff Huang, This Page is Designed to Last: A Manifesto for Preserving Content on the Web, (data dostępu: ), w: Jeff Huang, Jeff Huang, (data dostępu: ).
- Aaron Gustafson, The Illusion of Control in Web Design, (data dostępu: ), w: A List Apart, (data dostępu: ).
- Do websites need to look exactly the same in every browser?, (data dostępu: ).
- Jeremy Keith, Insecure …again, (data dostępu: ), w: Jeremy Keith, Adactio, (data dostępu: ).
- Carl M. Johnson, Dropping Support For IE11 Is Progressive Enhancement, (data dostępu: ), w: Carl M. Johnson, The Ethically-Trained Programmer, (data dostępu: ).
- Chris Taylor, The tough truth of reality, (data dostępu: ).
- Keith Cirkel, How we think about browsers, (data dostępu: ), w: The GitHub Blog, (data dostępu: ).
- Tim Kadlec, Using the Platform, (data dostępu: ), w: Tim Kadlec, Tim Kadlec, (data dostępu: ).
- Jeremy Keith, Seams, (data dostępu: ), w: Jeremy Keith, Adactio, (data dostępu: ).
- Nolan Lawson, What I’ve learned about accessibility in SPAs, (data dostępu: ), w: Nolan Lawson, Read the Tea Leaves, (data dostępu: ).
- Thomas Steiner, Web Apps on macOS Sonoma 14 Beta, (data dostępu: ), w: Thomas Steiner, blogccasion, (data dostępu: ).
- Robin Wieruch, Web Applications 101, (data dostępu: ), w: Robin Wieruch, rwieruch, (data dostępu: ).
- Kevin Basset, Why haven’t PWAs killed native apps yet?, (data dostępu: ), w: Medium, (data dostępu: ).
- Charlie Gerard, Building an aircraft radar system in JavaScript, (data dostępu: ), w: Charlie Gerard, Charlie Gerard, (data dostępu: ).
- Bertrand Delacretaz, The Web Platform Is Back, (data dostępu: ), w: Medium, (data dostępu: ).
- Oxford Harrison, Rethinking the Modern Web, (data dostępu: ), w: DEV Community, (data dostępu: ).
- Aaron Gustafson, Native And PWA: Choices, Not Challengers!, (data dostępu: ), w: Smashing Magazine, (data dostępu: ).
- Mitch Lenton, Designing For A Browserless Web, (data dostępu: ), w: Smashing Magazine, (data dostępu: ).
- Guillermo Rauch, 7 Principles of Rich Web Applications, (data dostępu: ), w: Guillermo Rauch, Guillermo Rauch, (data dostępu: ).
- Aaron Gustafson, Widgets!, (data dostępu: ), w: Aaron Gustafson, Aaron Gustafson, (data dostępu: ).
- Thomas Steiner, Not everyone's currently building for the Web, but probably more people should, (data dostępu: ), w: Thomas Steiner, blogccasion, (data dostępu: ).