Front-Trends 2010 - część 1

Co robi informatyk, gdy nie chce mu się programować potrzebuje nowej inspiracji? Chodzi na konferencje. Rok temu byłem na Pyconie, tym razem skusiłem się na Front-Trends, czyli warszawską konferencję na temat HTML i JavaScriptu.

Poniższy tekst jest nie tyle relacją, co opracowaniem moich notatek, piszę subiektywnie i z dość specyficznej perspektywy (uważam siebie za programistę raczej backendowego niż frontendowego).

Trendy

Skoro Front-Trends, to może najpierw o najbardziej wyraźnych trendach.

Mobile World

W wielu wykładach przewijał się motyw aplikacji mobilnych. Już zaraz, za chwilę zobaczymy świat, w którym na jednego użytkownika desktopowego przypadnie kilku korzystających z telefonów komórkowych i podobnych urządzeń a mobilny kanał dostępu nie będzie już kaprysem czy dodatkiem ale podstawową formą obsługi.

Narzędziem developerów ma być tu odejście od pisania osobnych aplikacji na każdy rodzaj telefonu na rzecz programowania opartego o standardy webowe. HTML, JavaScript i standaryzowane API pozwolą tworzyć nie tylko mobilne frontendy do aplikacji sieciowych ale także natywne aplikacje na smartfony i inne urządzenia przenośne.

HTML5 i CSS3

HTML5, CSS3 i nowe API przeglądarkowe stają się wreszcie realnością, rozmawiamy o nich już nie jako o egzotyce ale dyskutując możliwości praktycznego stosowania, techniki migracji i konkretne sztuczki i kruczki.

JavaScript Anywhere

JavaScript przestaje być jedynie językiem oprogramowywania przeglądarek. Służyć ma do pisania natywnych aplikacji klienckich, zwłaszcza mobilnych ale i na tym ambicje się nie kończą. Coraz więcej projektów szuka sposobów wykorzystywania JavaScriptu na backendzie, zyskując możliwość dzielenia kodu między warstwami aplikacji, migrowania między nimi funkcjonalności czy wreszcie ograniczania ilości specjalizacji w zespole programistów.

Osobiście jestem tu dość sceptyczny i traktuję to trochę jako chęć uzyskania samodzielności przez frontendowych programistów w której nieco uproszczają problemy z jakimi stykają się backendowcy. Ale ... życie pokaże.

Prezentacje

Konferencja toczyła się dwutorowo i musiałem wybierać, poniżej parę słów o każdej z obejrzanych przeze mnie prezentacji.

Najbardziej podobały mi się pokaz programowania Christiana Johansena i wizjonerski wykład Petera-Paula Kocha. Niestety nie widziałem prezentacji Chrisa Heilmana i Jake Archibalda, które koledzy ocenili wysoko.

Open Web Products For Everyone

Andy Dennis zachęcał do używania otwartych technologii (rozumianych jako HTML, CSS, JavaScript i standaryzowane API dla tego języka) przy tworzeniu aplikacji webowych.

Podstawą wykładu była następująca propozycja procesu rozwoju aplikacji:

• zacznij od ustalenia konkretnych potrzeb użytkowników,
• zdefiniuj najprostsze możliwe rozwiązanie,
• zbuduj tradycyjną aplikację webową - używając HTML4 (który jest bezpieczny jako obecny wszędzie, także na platformach mobilnych), CSS (bez złożonych efektów) i tradycyjnego modelu linków i submitów, a nie używając JavaScriptu - wersja ta będzie stanowiła bezpieczną podstawę możliwą do uruchomienia niemal wszędzie,
• wykorzystaj enhance.js do warunkowego ładowania CSS i JavaScriptu odpowiednio do możliwości przeglądarki,
• wykorzystaj PhoneGap do stworzenia natywnej wersji aplikacji z tego samego źródła,
• opublikuj efekt w AppStore-ach (poza sklepami Apple i Android jest też wiele innych, patrz wipconnector.com/appstores, spore nadzieje budzi perspektywa sklepu Mozilli).

Andy-ego dobrze się słuchało ale tak naprawdę wyniosłem z jego prezentacji tylko link do enhance.js i (po raz pierwszy) pomysł tworzenia natywnych aplikacji mobilnych w HTML/JavaScript (zamiast Javy, Objective-C itd).

Peer to Peer Web and Why You Should Care

Jan Lehnhardt (jeden z autorów CouchDB) także rysował wizję mobilnej rewolucji. Przyszłość internetu jest mobilna, wkrótce będziemy mieć więcej smartfonów niż komputerów i coraz chętniej ich używamy, są obszary (np. Afryka) w których wręcz internet=mobile bo faza desktopów została pominięta. Świat aplikacji mobilnych jest inny (inny rodzaj formularzy, touch, zawodna sieć, baterie) ale podstawy używalności i technologii są te same.

Pojawił się też akcent wolnościowy. Dzisiejszy Web jest scentralizowany, kontrolowany przez firmy takie jak Google, Facebook, Twitter czy Amazon. Tim Berners-Lee wymyślił URL pozwalające adresować cokolwiek-gdziekolwiek ale marzenie o tym, że każdy będzie miał swój web serwer się nie spełniło (choć Opera Unite może zwiastować zmianę, norweska firma nieraz wyprzedzała rozwój sieci, szkoda tylko że sieci telekomunikacyjne tak ograniczają upstream). Przyszły, mobilny internet, będzie bardziej demokratyczny i zdecentralizowany, bardziej oparty na bezpośredniej wymianie danych i informacji. Wymuszą to nawet proste względy techniczne - jak słaba, niepewna sieć.

Moim własnym zdaniem zwiastunem czasów jest raczej cloud (wynoszenie tradycyjnie prywatnych danych - jak pliki, dokumenty, kontakty - na zdalne usługi), niż prywatne webserwery. Ale kto wie...

Wreszcie, bardziej pragmatycznie, Jan wskazał, że aplikacje nie powinny wymuszać na użytkowniku oczekiwania na zakończenie interakcji. Kliknięcie Wyślij w programie pocztowym powinno zawsze zadziałać, nawet gdy użytkownik jedzie akurat tunelem, po prostu program powinien zapamiętać decyzję i przesłać dane, gdy tylko stanie się to możliwe. Decouple editing data from putting it online. Podobnie raz pobrane dane powinny pozostać lokalnie dostępne nawet przy braku sieci lub jej słabej jakości.

Zwieńczeniem wykładu była zachęta do poznania i używania CouchDB - bazy danych, która może działać na urządzeniach mobilnych (choć skaluje się także do dużo większych zastosowań), wspomaga synchronizację, udostępnia JSONowe API po HTTP, pozwala się oskryptawiać JavaScriptem (włącznie z możliwością budowy pełnych aplikacji bez dodatkowego webserwera) i w ten sposób zarówno w pełni wspiera model lokalnych, asynchronicznie wymieniających dane aplikacji, jak świetnie wpisuje się w programowanie oparte o standardy webowe.

Jan zakończył rekomendując książkę o CouchDB której jest współautorem. Mam tę książkę (w formie ebooka) i mogę potwierdzić, że czyta się ją dobrze i stanowi wyczerpujące wprowadzenie do różnych sposobów używania CouchDB. Opinii na ile sensowne jest wykorzystywanie tej bazy danych jeszcze sobie nie wyrobiłem.

Pragmatic CSS3

Lea Verou przeprowadziła systematyczny, rozbudowany przegląd nowości w CSS3. Bardzo dopracowana wizualnie, przemyślana i pełna szczegółów prezentacja, chyba najlepsza ze wszystkich przeprowadzonych pierwszego dnia konferencji.

Wielką zaletą było, że autorka nie robiła po prostu spisu funkcji ale zawsze wychodziła od konkretnych potrzeb i porównywała rozwiązania w CSS2 i CSS3. Zaokrąglone rogi robiliśmy na czterech divach a będziemy via border-radius. Cienie wymagały sztuczek z obrazkami, teraz mamy box-shadow (który przy okazji pozwala na nowe ciekawe efekty, np. jasny inset przy górnej krawędzi daje efekt rozświetlenia). Przeplatane wiersze trzeba było wspomagać w kodzie aplikacji (naprzemienne klasy), teraz mamy :nth-child (który dodatkowo umie dużo więcej - tu parę przykładów). I tak dalej, i tak dalej... Wszystko opatrywane realistycznymi przykładami wykorzystania i dynamicznym podglądem konsekwencji rozmaitych zmian stylu.

Lea obiecała, że w przyszłym tygodniu umieści prezentację na swoim blogu, na pewno warto zajrzeć.

Lea opublikowała swoją prezentację, tutaj można ją obejrzeć online (uwaga: może się w tej wersji ślimaczyć, min. przez duże obrazki), stąd pobrać w formie pliku .zip a tutaj przeczytać dodatkowe objaśnienia autorki. Lea korzystała z Firefoksa 4 beta, w innych przeglądarkach niektóre elementy stylu mogą jeszcze nie być obsługiwane.

JavaScript: the rise of the Middle-End

Kyle Simpson zaczął od oświadczeń, że LABjs may die, document.write() must die i IE must fork a następnie zaczął propagować zmianę architektury aplikacji webowych.

Obecny model aplikacji webowych, w którym JavaScriptowa aplikacja działająca w przeglądarce komunikuje się z napisaną w innym języku i zgodnie z wzorcem Model-View-Controller częścią backendową, coraz bardziej nie przystaje do bieżących dynamicznych aplikacji. Co zrobić, gdy kod kontrolera ma działać na frontendzie? Jak w praktyce uniknąć uzależniania szablonów od modelu (wbrew teoretycznym wymaganiom, w praktyce szablony zwykle odwołują się do klas modelu), błędów wynikających z rozsynchronizowania się logiki zapisanej w kodzie, szablonach i skryptach (standardowy casus warunkowo dostępnych funkcji)? Dlaczego tak wiele funkcji (zwłaszcza walidacji danych) trzeba przepisywać w dwóch różnych językach programowania?

Rozwiązaniem ma być architektura Client-View-Controller, w której przeglądarkowa aplikacja komunikuje się z warstwą środkową, działającą po stronie serwera ale zapisaną w JavaScripcie, realizującą funkcje kontrolera i widoku, a w celu realizacji funkcji biznesowych komunikującą się z faktycznym backendem przy pomocy JSONowego API.

Podejście to zapewni większą spójność aplikacji, dzielenie kodu, płynne przenoszenie funkcjonalności między przeglądarką a middleendem, rozsądniejsze pakowanie zasobów (świadome kontekstu łączenie skryptów czy styli w pojedyncze pliki), obsługę wieloelementowych odpowiedzi, atomowe cacheowanie, niezależne skalowanie każdej z warstw, a przede wszystkim umożliwi rozwijanie całej tej części aplikacji przez te same osoby i ograniczy złożoność interfejsu faktycznego backendu.

Po tym wprowadzeniu Kyle przeszedł do konkretnych narzędzi. Wspomniał o możliwości wykorzystywania node.JS ale ostrzegł, że wprowadza ono drastycznie inny model programowania (czysto zdarzeniowy i asynchroniczny). Prostszym pojęciowo i łatwiejszym przy migracji kodu rozwiązaniem jest BikechainJS jego autorstwa, w którym serwerowy JavaScript wykonuje się synchronicznie, w formie zdalnie wywoływanych funkcji. A w ramach opartej na nim aplikacji za generowanie stron może odpowiadać HandlebarJS, czyli Javascriptowy moduł szablonów (mogący zresztą działać także na frontendzie).

Ilustracją użycia obu narzędzi stanowiło Shortie, czyli prosty skracacz linków. Kyle prezentował i omawiał fragmenty kodu tej aplikacji a publiczność - korzystając z chwilowo działającego Wi-Fi - szukała nowych zastosowań dla jego aplikacji.

Pokazane fragmenty skryptów nie zrobiły na mnie szczególnie zachęcającego wrażenia ale działający, prawdziwy kod, stanowił miłą odskocznię od teoretyzowania wcześniejszych prezenterów.

Kyle opublikował slajdy z teoretycznej części prezentacji:

(a kod, jak już wyżej wspomniałem, jest na shortie.me).

Keynote 1 (programowanie zdarzeniowe)

Douglas Crockford poświęcił swoją prezentację zderzeniu dwóch stylów programowania - klasycznego, w którym to program steruje przebiegiem przetwarzania i decyduje o momentach wykonywania (synchronicznego) wejścia/wyjścia i zdarzeniowego, w którym nasz kod działa w reakcji na rozmaite zewnętrzne impulsy.

Temat szczególnie nowy dla mnie nie był (nawet sam próbowałem swego czasu o tym podejściu pisać), więc wykład oglądałem bardziej dla przyjemności niż dla nauki (Crockforda naprawdę przyjemnie się słucha, styl rutynowanego profesora umiejącego utrzymać uwagę, wpleść anegdotę, dopilnować tempa).

Na początek dostaliśmy krótki przekrój przez historię informatyki. Sięgając maszyn Univac, wspominając Murray Hopper (autorkę pierwszego kompilatora - A-0), starą jak informatyka tradycję open-source (kompilator A-2) czy maszyny timesharingowe, dorzucając anegdotę o oporach, jakie programiści mieli przed wykorzystywaniem kompilatorów (programming requires too much creativity to have humans replaced by the machine), Douglas zauważył, że aż tamtych czasów (i nieco późniejszych maszyn timesharingowych) sięga zasada, że I/O jest oparte o blokujący READ zatrzymujący działanie programu. Every language has blocking I/O ... except C, which has no I/O at all. Unfortunately it has stdio. Z drugiej strony przywołany został zdarzeniowy system HyperCard, który pozwolił nie-programistom być zaskakująco produktywnym i znacząco wpłynął na podejście programistów do tworzenia aplikacji (seeing those apps programmers suddenly become wiser), a wpłynął znacząco min. na model przeglądarki WWW.

Zamknięciem tej części stało się stwierdzenie, że JavaScript szczególnie dobrze pasuje do programowania zdarzeniowego: w języku nie ma blokującego READ a cała generacja jego programistów została wychowana do pracy z pętlą zdarzeń. JavaScript programmers are wiser about event loop than other programmers.

Później mieliśmy klasyczne porównanie wad i zalet dwóch podejść do współbieżności: wątkowego i opartego o pętlę zdarzeń. Ryzyko wyścigów lub deadlocków kontra konieczność programowania w stylu never block, never wait, finish fast (z dzieleniem dużych zadań na fazy lub delegowaniem do osobnych procesów), problemy z testowaniem, odpluskwianiem i analizowaniem kodu itd itp. A przy tym opinie I am sure JavaScript won't have threads (ilustrowana wyścigiem przy dopisywaniu do tablicy) oraz Browser event loop is the best part of the browser.

Po dodatkowym skrytykowaniu RPC (two great ideas - function and network communication - merged into one, very bad idea (...) just like READ it attempts to isolate programs from time), paru sugestiach dotyczących unikania opóźnień odczuwanych przez użytkowników (acknowledge input immediately, don't lock while waiting for server, show predicted reply and correct afterwards) Douglas przeszedł do ... dość szczegółowego omówienia mechanizmu ataków XSS. Padło parę smacznych cytatów:

• any site asking password repeatably teaches user to give it up at any time;

• SQL is optimized for SQL injection attacks,

• HTML doesn't ever have markup injection vulnerabilities,

• browser is a gun pointed at your head, <=? is a trigger,

a także bardzo poważne ostrzeżenie: HTML5 nie dość, że niczego tu nie poprawia (jak standard wymuszał na przeglądarkach niebezpieczne zachowania, tak dalej to robi), to przez wprowadzenie nowych API (choćby lokalnego storage) zwiększa znacząco ryzyko.

Wykład zakończyło zachwalanie stosowania JavaScriptu na serwerze (z dalszym wykorzystywaniem pętli zdarzeń). Odpowiednią implementacją jest node.JS, niemal w całości (poza require i paroma opcjonalnymi funkcjami) nieblokujące, pozwalające na bardzo funkcjonalny styl programowania (włącznie z par, seq, map, paror, seqor, mapor) i dające możliwość płynnego przenoszenia funkcjonalności między klientem a serwerem.

Panel dyskusyjny

Panel dyskusyjny raczej rozczarował. Zbigniew Braniecki jako prowadzący, Douglas Crockford, Tantek Çelik i Peter-Paul Koch jako dyskutanci, tymczasem większość czasu zeszła na raczej jałowych rozmowach o tym czy Flash się utrzyma, czy nie, co z IE6 albo dlaczego nie wypalił XHTML, a czasu na pytania z sali było ze względu na opóźnienie konferencji i wykładu wyraźnie za mało.

Zapadły mi w pamięć:

• komentarz Tanteka Çelika na temat rywalizacji standardów webowych z Flashem i podobnymi narzędziami: It's not a sport match with single winner, but continuous evolution,

• obserwacja, że wielu dawnych leniwych, akcydentalnych webmasterów obecnie jest na Facebooku,

• Looks crazy to me jakim Crockford skwitował pytanie o kompilowanie do JavaScriptu (narzędzia takie jak GWT czy Pyjamas),

• pochwała książki Structure and Interpretation of Computer Programs, którą Crockford uznał za najlepszy podręcznik programowania (uwaga: używanym w książce językiem jest Scheme).

Miałem swoje prywatne miłe zakończenie, organizatorzy obdarzyli osoby aktywne w sesji pytań prezentami...

Ciąg dalszy nastąpi

O wydarzeniach drugiego (ciekawszego) dnia jeszcze napiszę... napisałem tutaj.