Następny krok rozwoju Webu: całkowicie asynchroniczne interfejsy

Jeśli spojrzymy na standardowy sposób, w jaki budowane są strony internetowe, łatwo zauważymy ich główną wadę: przy okazji każdej operacji odświeżana jest cała strona, zarówno podczas przeglądania treści, jak i przy edycji danych.

Oczywiście coraz więcej twórców stron radzi sobie z tym, wykorzystując Ajaksa, ale potencjalne możliwości obejścia tego problemu są znacznie większe, niż to co widzimy dziś w Sieci.

Alex MacCaw przedstawił wczoraj sposób, w jaki radzi sobie z problemem komunikacji z serwerem za pomocą asynchronicznego interfejsu, który ma zwiększyć obserwowaną przez użytkownika szybkość strony.

Nie jest to jedynie sztuka dla sztuki. Programista przytacza dane, według których zwiększenie czasu ładowania Amazona o 100 ms spowodowało spadek sprzedaży o 1%, Google zwiększając czas ładowania o 500 ms, doprowadziło do zmniejszenia liczby zapytań o 20%, a Yahoo! przez zwiększenie czasu ładowania strony o 400 ms spowodowało wzrost liczby wycofań ze strony o 5-9%.

Dla sklepów internetowych krótszy czas ładowania się strony przekłada się więc bezpośrednio na statystyki i w konsekwencji na zyski.

MacCaw przedstawił demonstrację interfejsu wykorzystującego standardowe zapytania do serwera oraz wersję zbudowaną z wykorzystaniem interfejsu asynchronicznego. Zauważcie, że w tej drugiej demonstracji zapisywanie czy edycja stron działają niemal natychmiast.

Wersja asynchroniczna została zbudowana po stronie serwera na Railsach, a po stronie UI na Spine i Ajaksie. Kod źródłowy można zobaczyć tutaj. Szczególnie interesujący jest kontroler.

Tak wygląda przykład zmiany nazwy strony i jej zapisu:

page = Page.find(1)
page.name = "Hello World"
page.save()

Jak widać, interfejs aktualizuje się natychmiast, natomiast zapis do bazy przebiega asynchronicznie. Ryzykowne, prawda? Jak jednak uważa McCow, w wielu wypadkach błędy zapisu asynchronicznego są wyjątkami od reguły, którą są poprawne zapisy. Dlatego też, gdy wystąpi błąd można zawsze poinformować o tym użytkownika i odświeżyć widok, aby pokazać poprzednie wartości.

Inne pojawiające się problemy to walidacja, którą McCow proponuje powielić po stronie klienta, oraz generowanie identyfikatorów. W tym wypadku stosuje on tymczasowe identyfikatory po stronie klienta, do czasu uzyskania „oficjalnych” z serwera.

Podejście McCowa jest świetne. Nawet Google pracuje już nad obsługą zapytań JavaScriptu, więc i problem pozycjonowania niedługo zostanie rozwiązany. Tak powinny być budowane wszystkie strony internetowe – oprócz stron banków oczywiście, chyba że w części systemu odpowiedzialnej za zmniejszanie salda. Zapoznać się ze szczegółami rozwiązania możecie tutaj.

źródło: alexmaccaw.co.uk, pic: sxc.hu/svilen001

Podoba Ci się ten tekst? Powiedz o tym innym na Fb: lub na G+:

publikuj:

wydrukuj

8 skomentuj »

Komentarze

#1 adi_82^® 2011-11-17 16:09:09 0
Najbardziej irytujace na stronach webu jest to ze jak klikasz na inne zdjecie w galerii to wczytywana jest ponownie cala strona... a po wczytaniu wraca na poczatek strony a nie tam gdzie powinno - tregedia. I to jeszcze na podstawowych portalach jak np. gazeta.pl

Problem z przegladalnoscia stron AJAX przez boty mozna rozwiazac samemu, http://code.google.com/web/ajaxcrawling/

Ale strona dziala duzo lepiej szybciej, a nawt potrafi dzialac offline (przez wykorzystanie odpowiednich narzedzi co po czesci umozliwia gwt).
IP: 77.253.223.[...] Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.120 Safari/535.2
#2 Wszerad 2011-11-17 16:35:47 0
Ciekawa sprawa, jako, że bawię się z Node.js to najprawdopodobniej też będę miał możliwość zastosowania wspomnianych technologi.
IP: 213.17.128.[...] Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0a1) Gecko/20111114 Firefox/11.0a1
#3 Subey 2011-11-17 16:53:39 0
@adi_82®

pamietaj że każde przeładowanie strony to nowe wyświetlenia reklam ;) No bo chyba nie twierdzisz ze taka gazete nie stać na wdrożenie czegoś takiego :D
IP: 178.37.86.[...] Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20100101 Firefox/8.0
#4 slawek22 2011-11-18 02:36:52 1
>Move state & view rendering to the client side

To bardzo droga i niepewna zabawa. Właściwie dzisiaj nie da się tego zrobić. Jeśli sklep potrzebuje 100ms na przeładowanie strony i można tak zmniejszyć czas do np. 70ms to być może w idealnych warunkach sprzedałoby się 1-5% więcej towaru, ale to tylko teoria.

Taki interface ma tendencje do wysypywania się po czasie i na pewno w części klientów nie będzie działał. I to będzie niestety dość znacząca część jeśli porównywać straty z zyskiem biorąc pod uwagę nawet samo IE6 i ludzi z wyłączonym JS. Pomijając już nawet koszmarne możliwości i obsługę standardów czy JS przeglądarek mobilnych.

Nie wspominając już o tym, że jakiekolwiek SEO będzie niemożliwe. Parsowanie JS przez google to bajki - w najlepszym razie osiągną coś podobnej jakości jak parsowanie Flasha.

Typowy przykład przeoptymalizowania. Z resztą widać na tym prostackim przykładzie. UI z paroma polami edit nie radzi sobie nawet z przyciskiem wstecz na najnowszej wersji Chrome. Pod IE8 jest już totalna kaszana i jedynie błędy JS bo nie działa NIC (edit/show), etc.

Autor tego rewolucyjnego sposobu dowiedział się miesiąc temu co to AJAX a o sieci to w ogóle nie ma pojęcia. Zróbmy asynchroniczny UI, wywalmy wszystkich którzy nie używają chrome w kosmos. Przecież u mnie działa :) Jeśli więc bardzo was denerwuje konkurencja proponuję zrobić gdzieś mirror tego artykułu i dopisać parę pochlebnych komentarzy - jak to rośnie sprzedaż. Jeśli nie zbankrutują to na pewno utopią dużo forsy i stracą mnóstwo czasu :)
IP: 83.4.103.[...] Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.121 Safari/535.2
#5 zaggi^® 2011-11-18 08:17:58 0
@slawek22

Potwierdzam, to samo chciałem wyrazić, lecz widzę że nie ma potrzeby.

Często programiści popełniają ten błąd, że zapędzają się w skrajności - tak jak ten pan optymalizację jako cel sam w sobie, jakby nie widząc konsekwencji takiego działania bądź pomijając jako mało istotne błędy, które przecież są promilem w ogólnej statystyce działania...
IP: 89.174.8.[...] Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.121 Safari/535.2
#6 kallosz^® 2011-11-18 10:46:54 0
ale nic nie stoi na przeszkodzie aby domyślnym interface był właśnie asynchroniczny. Oczywiście nie wyobrażam sobie aby taka strona nie miała alternatywy w postaci zwykłego interface bez JS :)
IP: 87.205.92.[...] Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.41 Safari/535.7
#7 Siof 2011-11-18 14:09:55 0
zawsze można sie też pobawić w witty ^^ który daje taką możliwość domyślnie oraz pozwala na wyświetlanie strony w htmlu bez używania js/ajaxa: http://www.webtoolkit.eu/wt
IP: 83.12.219.[...] Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20100101 Firefox/8.0
#8 jacek2v^® 2011-11-18 17:36:28 0
Programowanie asynchronicznego interfejsu web wcale nie wymaga JS. Np. wystarczy dobrze oprogramować rozdzielenie warstw aplikacji na tę od danych i od wizualizacji. Tę od danych zrobić jako usługę (np. REST) wywoływaną ze strony i działającą asynchronicznie.
IP: 178.36.189.[...] Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.120 Safari/535.2

Aby dodać komentarz, musisz podać swój nick, treść komentarza oraz poprawnie przepisać oba słowa z obrazka (słowa muszą być rozdzielone spacją).
W treści komentarza można używać języka formatowania BBcode.