Zmierzch tradycyjnych aplikacji internetowych na rzecz SPA

Miło mi napisać do Ciebie te krótkie przemyślenia. Otóż jakiś czas temu dyskutowałem z kolegą na temat zmierzchu popularności tradycyjnych aplikacji internetowych. Przez określenie „tradycyjne” mam na myśli typu SSR (ang. Server Side Rendered), gdzie treść generowana jest po stronie serwera i HTML wysyłany jest do przeglądarki.

Po drugiej stronie, na krzywej wzrostowej znajdują się aplikacje tzw. SPA (ang. Single Page Application). Są one wykonywane w JavaScript lub coraz częściej w TypeScript, ale dla potrzeb naszych rozważań zostawmy przy tym pierwszym, jako że środowisko uruchomieniowe jest po stronie przeglądarki.

SPA charakteryzują się tym, że cały kod klienta pobierany jest z serwera do przeglądarki i tam uruchamiany, czyli cała apka znajduje się na naszym komputerze. Potrzebne jej informacje pobiera poprzez API (ang. application programming interface) i cała wymiana danych odbywa się poprzez ten interfejs.

Jakie są typowe za i przeciw tych rozwiązań?

Trzy powodu pisania tradycyjnych aplikacji.

1. Aplikacja musi działać w środowisku, w którym przeglądarka nie obsługuje JavaScriptu,
2. Wyświetlana strona ma prostą budowę, ma minimalne wymagania funkcjonalne lub nie ma pól formularza do wprowadzania treści.
3. Zespół programistów tworzący aplikację nie ma doświadczenia z JavaScriptem i programowaniem frontendów.

Trzy powody, kiedy stawiamy na rozwiązanie SPA.

1. Kiedy oprócz aplikacji internetowej tworzymy apkę mobilną i tworzymy do nich wspólne API.
2. Przy budowaniu aplikacji o wysokiej interakcji z użytkownikiem i bogatym interfejsie użytkownika.
3. Gdy w skład zespołu programistów wchodzą osoby z wiedzą o JavaScript i budowie frontendu.

Czy generowanie stron na serwerze przetrwa?

Popularność JavaScript na pewno wpływa na ilość tworzonych tradycyjnych aplikacji, ale na pewno nie wyprze ich zupełnie.

Środowiska i przeglądarki bez JavaScriptu.

Wbrew pozorom nie jest rzadkością, że funkcjonują urządzenia, w których nie ma lub jest ograniczona funkcjonalność uruchamiania kodu o stronie klienta. Mogą do nich należeć czytniki e-booków, terminale o małej mocy obliczeniowej oraz cała rzesza urządzeń automatyki przemysłowej.
Urządzenia te wyświetlają informacje otrzymane od serwera, lecz interakcja z nimi poprzez ekran jest uproszczona. Moc obliczeniowa również jest ograniczona, co wydatnie sprzyja obniżeniu kosztu urządzenia.

Strony o małej liczbie pól formularzy lub dużej ilości treści do czytania.

Weźmy pod uwagę główną stronę wyszukiwarki Google. Mamy tam jedno pole tekstowe i przycisk wyszukaj. Na tego typu stronach nie ma potrzeby tworzyć specjalnie do tego osobnej aplikacji działającej po stronie przeglądarki, wystarczy przeładować stronę i zaprezentować wyniki wyszukiwania.
Tak samo jest w przypadku blogów, forum i stron, gdzie większość stanowi treść do przeczytania (przejrzenia), a użytkownik nie wprowadza tam własnych danych.

Niechęć programistów backend do języka JavaScript.

Tak, tak, nie jest to rzadki przypadek, że programiści albo kochają JavaScript lub go nienawidzą. I jeśli masz w zespole tych o poglądach backendowych, to najwygodniejszym dla nich rozwiązaniem zawsze będzie ASP.Net MVC i nic tego nie zmieni.

Na co aplikacje po stronie klienta pozwolą w przyszłości?

Ogromnego postępu w ekspansji SPA zawdzięczamy rozwojowi frameworków typu Angular, React czy Vuejs. Zaczęło się od biblioteki jQuery, ale to platformy programistyczne przyczyniły się do uproszczenia tworzenia dużych rozwiązań w JavaScript. Jest to język pozwalający na wiele skrótów i swobody, co niestety owocuje trudnością utrzymywania skomplikowanego kodu i powoduje powstawanie sporej ilości błędów uwidaczniających się dopiero po stronie przeglądarki.

Szkoda czasu pisać dwa razy.

Obecnie wiele aplikacji oprócz strony internetowej publikuje dedykowane aplikacje mobilne. Kiedy wszystkie te końcówki komunikują się przez wspólne API, to nie ma sensu pisać tego samego po stronie serwera, jak i klienta. Czyli dla uproszczenia piszemy jeden interfejs komunikacji, do którego łączą się zarówno apki mobilne, jak i strona web.

Użytkownik nasz pan.

Przy bogatym interfejsie użytkownika, jaki mamy w większości aplikacji biznesowych, liczy się wygląd i ergonomia użytkownika, a nie wygoda programisty. I dlatego twórcy stają na głowie, żeby ich aplikacje były jak najbardziej interaktywne i przyjazne w obsłudze.
Trudno jest uzyskać takiego bogactwa obsługi kontrolek, tworząc tradycyjne aplikacje. Można wykorzystać technologie Ajax do zmian na stronę lub odświeżania tylko wybranych elementów, ale nigdy nie zbliżymy się do możliwości interakcji, jakie daje JavaScript.

Podział na frontendowców i backendowców.

Od razu przychodzi na myśl co z Full Stackami, czyli programistami piszącymi zarówno bazy danych, jak i CSS. Ano jak to zwykle bywa, podobno istnieje uniwersalny klucz, uniwersalny samochód czy skuter, ale zawsze jednak preferujemy radykalne różnice, czyli albo motocykle sportowe, albo choppery.
Tak samo jest z kodem. Jeśli w zespole mamy osoby doświadczone w JavaScript i frameworkach frontendowych, to korzystniej będzie utworzyć aplikację SPA o dużych możliwościach interakcji i bogatym interfejsie użytkownika, która będzie komunikowała się z usługami backendu za pomocą API.

Co widać na horyzoncie?

Dużymi krokami zbliża się WebAssembly, czyli wykonywanie kodu aplikacji internetowej po stronie naszego komputera. Pozwala to uzyskiwać bardzo dużą wydajność.
Cały czas rozwijane są frameworki. Za chwilę będzie Angular w wersji 10. Możliwości, jakie dają nam React, Vuejs czy Angular pozwalają na pisanie bardzo złożonych systemów.

Wciąż jednak nie zapominajmy o istnieniu i możliwościach aplikacji tradycyjnych, ponieważ nie zawsze nasza aplikacja musi mieć super interaktywny UI/UX, wystarczy, że wyświetli potrzebne dane, a pisanie i wdrażanie tego typu aplikacji jest znacznie prostsze i szybsze.