Od dawna zajmuję się tworzeniem aplikacji webowych. Bardzo długo. Moje pierwsze aplikacje webowe w środowisku tworzyłem w czasach, gdy słowo „google” jeszcze nie było czasownikiem, a do wyszukiwania informacji w Internecie ludzie używali Yahoo! i Rambler. Ja korzystałem z — mieli oni zawężające opcje wyszukiwania i znacznie mniej chaotyczny interfejs niż Yahoo!
Tworzenie aplikacji, wszelkich aplikacji, nie tylko webowych — to praca twórcza. Mało kto podważy to stwierdzenie. A piękno w twórczości jest jak praktyka w naukowym poznaniu — kryterium prawdy. Ale jeśli praktyka naukowa jest obiektywna i oparta na pomiarach, to piękno jest kwestią subiektywną, zależną od tego, kto patrzy. Postawiłem więc sobie pytanie, co dla mnie osobiście stanowi piękną aplikację webową?
(na KDPW nie mój wzrok, to spojrzenie kobiety, ale, IMHO, żeński wzrok na KDPW jest bardziej odpowiedni niż męski, w końcu to — !)
Pod katem przedstawiam moje własne kryteria, według których obecnie można uznać aplikację webową za piękną. Bardzo subiektywne przedstawienie, będące rezultatem mojego osobistego doświadczenia. Możliwe, że dla niektórych moje kryteria piękna będą wydawały się kryteriami brzydoty. Nie dziwcie się, po prostu macie inne doświadczenie.
A skoro już weszliście pod kat, to proszę zachować ostrożność w komentarzach. Bowiem jeśli możecie przerwać czytanie artykułu, gdy to, co jest w nim przedstawione, wyda się wam niepiękne lub wręcz brzydkie, to ja, jako autor, muszę czytać wszystkie komentarze.
Środowisko życia
Protokół
Nie wiem nawet, czy warto ten kryterium wydzielać osobno. Aplikacje webowe żyją w Sieci i muszą przestrzegać praw Sieci (protokół). Główne protokoły w Sieci to — i . Na nich opiera się wiele innych protokołów, ale dla aplikacji webowych uważam, że najważniejszy jest (a właściwie jego rozszerzenie na bazie ). Tzn. piękna aplikacja webowa jest dostępna za pomocą HTTPS/TLS (alternatywnie — HTTP), a inne protokoły (LDAP, RPC, IMAP4, POP3, SMTP, FTP, NNTP, …) sprawiają, że staje się mniej piękna z każdym dodatkowo obsługiwanym protokołem. Sama aplikacja może za pomocą tych dodatkowych protokołów korzystać z zewnętrznych zasobów.
Jeśli chodzi o , więc nie mam wystarczającego doświadczenia z używaniem tego protokołu z aplikacjami webowymi. Wygląda to ładnie i obiecująco, ale jak stabilne i praktyczne to jest — nie mogę powiedzieć.
Przeglądarki
Aplikacja internetowa stoi jedną nogą na serwerze, a drugą na stronie klienta. Strona klienta to przeglądarka. Nowoczesna przeglądarka oferuje , które nowoczesna aplikacja webowa może i powinna wykorzystywać na swoją korzyść. Piękna aplikacja internetowa wykorzystuje nowoczesne funkcje przeglądarek i nie musi działać w tych przeglądarkach, które nie oferują nowoczesnych możliwości. Rozumiem, że to konieczność, ale wygląda to źle. W końcu nie tylko deweloperzy muszą nadążać za nowoczesnymi technologiami, dotyczy to również użytkowników i biznesu.
Języków programowania
używanych do tworzenia aplikacji webowych jest bardzo dużo. W przypadku części klienckiej aplikacji webowych istnieje wiele technologii, które pozwalają programiście ułatwić stworzenie triady HTML/CSS/JS (to, co rozumieją wszystkie nowoczesne przeglądarki). Ale kiedyś miałem do czynienia z i uważam, że pięknie jest, gdy programista widzi w przeglądarce oryginalny kod, a nie wynik kompilacji lub transpilacji. Dlatego stosowanie i podobnych produktów do generowania kodu klienckiego, moim zdaniem, nie jest ładne. Im bardziej kod wykonywalny w przeglądarce przypomina oryginalny kod stworzony przez dewelopera, tym lepiej. Nie wierzycie? Spróbujcie zdebugować w produkcji kod stworzony przez GWT.
Po stronie serwera jest więcej swobody (Java, PHP, Perl, Python, C#, Ruby, …), ale wydaje mi się, że ładnie jest, gdy zarówno po stronie serwera, jak i w przeglądarce używa się jednego języka programowania — JavaScript. W końcu , a zespoły współpracowników są bardziej produktywne.
Człowieczeństwo
Piękna aplikacja webowa powinna być użyteczna. Użyteczna, przede wszystkim, dla człowieka jako końcowego użytkownika. Dlatego nie mogę nazwać piękną aplikacją webową . Zwykłemu człowiekowi (nie deweloperowi webowemu) trudno się z nimi obchodzić. Usługi webowe są piękne na swój sposób,
Piękna aplikacja internetowa powinna mieć intuicyjny interfejs. Można się spierać o to dość subiektywna kwestia. Ale z jest znacznie prostsze, jeśli użytkownik nie może korzystać z aplikacji bez upragnionego — kiepski UX, nieestetyczna aplikacja webowa. Najładniejsze aplikacje zgodnie z tym kryterium mogą być z łatwością używane przez dzieci, które jeszcze nie potrafią czytać.
Skalowalność zwrotna
Dawno temu programy można było przenosić na dyskietkach, teraz — na pamięciach USB lub ściągając bezpośrednio z Sieci. Skopiowanie zwykłej aplikacji i uruchomienie jej na innym komputerze to proste zadanie. Sytuacja z aplikacjami webowymi jest jednak nieco inna. Sieć to globalne środowisko, w którym nie ma potrzeby posiadania klonów tego samego web-aplikacji. Jeden Facebook, Twitter, Instagram, Mail.ru lub Yandex wystarczą. Można mieć różne web-aplikacje w tej samej niszy tematycznej, ale z różnymi odbiorcami (jak Facebook i Vkontakte, Mail.ru i Gmail, Google Maps i Azure Maps). Potrzebne są zasoby sprzętowe, aby zapewnić globalną dostępność takich web-aplikacji, powiedzmy, .
Nigdy nie pracowałem z aplikacjami webowymi na takim poziomie jako programista i nie wyobrażam sobie, jak one tam, w środku, są zorganizowane. Aby zapewnić funkcjonalność takich aplikacji webowych potrzebne są zespoły odpowiednich specjalistów i oddzielne centra danych. Fascynuje mnie zdolność ludzi do współpracy na taką skalę i tworzenia takich produktów, ale moim wzorem piękna jest aplikacja webowa, którą można uruchomić na osobnym laptopie.
Piękna aplikacja webowa skaluje się nie tylko w górę i na szerokość (dla użytkowników), ale także w dół i do wewnątrz (dla programistów).
Amfibijność
Do dostępu do nowoczesnych aplikacji webowych używa się urządzeń dwóch typów:
- komputery (laptopy, desktopy);
- urządzenia mobilne (smartfony i tablety);
Gdzieś na horyzoncie czai się jeszcze „„, ale na razie to tyle.
Komputery różnią się od urządzeń mobilnych tak bardzo, jak stworzenia lądowe różnią się od wodnych. To różne środowiska i stawiają różne wymagania wobec żyjących w nich istot (programów). Piękne aplikacje webowe to nie takie, które przypominają , ale te, które w wodzie — jak ryby, na lądzie — jak zwierzęta, a w powietrzu () — jak ptaki.
Uważam „„ za brzydką, to jak próba siadania na dwóch (z SEO — trzech) krzesłach. Lepiej jak Fiona z Shreka — w dzień jedna, a w nocy druga. Tak, drożej. Ale lepiej.
Cross-sharing
Zauważyłem już w punkcie „Obowiązkowa Skalowalność”, że globalność Sieci daje możliwość posiadania jednego web-aplikacji dla całej Planety. Dlatego każda web-aplikacja musi w jakiś sposób różnić się od innych, aby zapewnić sobie przetrwanie. Niemniej jednak, moje wieloletnie doświadczenie z (szkielet do budowania sklepów e-commerce) mówi, że między poszczególnymi web-aplikacjami może być więcej wspólnego niż różnic. Piękna web-aplikacja nie tylko powinna być modułowa, ale także powinna dzielić swoje moduły z innymi web-aplikacjami. W pewnym sensie ta idea jest odzwierciedlona w JSR 168 i JSR 286 oraz takich frameworkach jak , i ta sama Magento. Im większa liczba modułów web-aplikacji jest używana przez inne web-aplikacje, tym jest bardziej atrakcyjna w moim mniemaniu. Cross-sharing pozwala na tworzenie lepszej jakości modułów i w rezultacie bardziej stabilnych web-aplikacji.
Przez moduł nie rozumiem bibliotek typu jQuery czy RequireJS — raczej większe struktury, jak wtyczki w i . Ale dla bibliotek również prawdziwe jest twierdzenie, że szerokie rozpowszechnienie biblioteki pozwala uczynić ją lepszej jakości i bardziej odporną.
Architektura Harvardzka
, w przeciwieństwie do obecnie dominującej , zakłada oddzielenie kodu od danych. Architektura nie zyskała popularności, ale sama idea wydaje mi się piękna. Szczególnie w przypadku web-aplikacji. Każda statyka (HTML/CSS/JS/Obrazy/…) to kod. Można go i należy buforować zarówno po stronie serwera, jak i klienta. A dane to / (pięknie) lub / (trochę mniej pięknie). Albo WebSockets/JSON (może być najlepszym rozwiązaniem, ale nie próbowałem).
Lokalizacja
Są dwie rzeczy, które szczególnie mnie niepokoją podczas rozwijania web-aplikacji — to interfejs wielojęzyczny i strefy czasowe. Sam pochodzę z Łotwy, u nas używa się trzech języków: LV, RU, EN. Piękna web-aplikacja powinna umożliwiać nie tylko korzystanie z kilku języków w samej aplikacji, ale także pozwalać na rozszerzenie liczby używanych języków przy pomocy zewnętrznych zasobów, takich jak . To samo dotyczy modułów, z których zbierana jest web-aplikacja.
Z strefami czasowymi sprawa jest prosta: we wszystkich sytuacjach, gdy nie wiadomo, jak obsługiwać daty i czasy, postępuj tak: wszystko, co leży na serwerze, wychodzi z serwera i przychodzi z serwera, to UTC; wszystko, co jest wyświetlane u klienta, zgodnie z czasem strefy w profilu użytkownika. To piękne.
Kuźnie zamiast 'Gwiazd Śmierci'
Dawno temu w każdym większym miasteczku była w swojej kuźni. Być może nie jedna. Niektóre lepsze, inne gorsze. Byli kowale znani na całym świecie, a byli też tacy, do których chodzono z braku alternatyw. Przechodziły wojny, epidemie, katastrofy naturalne. Niektóre miasteczka znikały razem z mieszkańcami. Ale rzemiosło kowalskie przetrwało. Zamiast znikających miast powstawały nowe i w nich również pojawiały się kuźnie.
A teraz spójrz na usługę taką jak . Gdy padają serwery główne, .
Moim zdaniem, piękna aplikacja webowa nie może mieć rozmiarów Facebooka czy Mail.ru. To już bliżej '' zarówno pod względem zasobów potrzebnych do budowy, jak i zasobów potrzebnych do jej utrzymania. Tak, w przypadku zniknięcia Facebooka ludzkość nie wyginie, jego funkcje wystarczająco szybko przejmą inne aplikacje (ta sama na terytorium RF i w pobliskich rejonach, Instagram, Twitter, ...). Niemniej jednak, zamykanie znaczącej części populacji Planety w jednej aplikacji — to nie jest ładne. Tym bardziej, mając znacznie bardziej stabilne alternatywy (na przykład, ).
Podsumowanie
Jeśli dotarłeś do końca i czujesz się zdezorientowany — 'co to było?' to wyrażam moje szczere współczucie. Nie zmuszałem cię do czytania tego. Po prostu starałem się ubrać moje myśli w słowa, aby znaleźć tych, którzy myślą podobnie. Może będę mógł omówić z nimi niektóre aspekty tworzenia pięknych aplikacji webowych i poznać odpowiedzi na moje pytania. A mam ich wiele.
Dziękuję za przeczytanie.
Źródło: habr.com
