After watching the talk for about five times (it hardly gets old), I started to wonder whether it is only those two languages that exhibit similarly confusing behavior... The answer is of course "No", and that should be glaringly obvious to anyone who knows at least a bit of C++ ;) But beating on that horse would be way too easy, so I'd rather try something more ambitious.
Hence I ventured forth to search for "wat" in Python 2.x. The journey wasn't short enough to stop at mere addition operator but nevertheless - and despite me being nowhere near Python expert - I managed to find some candidates rather quickly.

I strove to keep with the original spirit of Gary's talk, so I only included those quirks that can be easily shown in interactive interpreter. The final result consists of three of them, arranged in the order of increasing puzzlement. They are given without explanation or rationale, hopefully to encourage some thought beyond amusement :)

Behold, then, the Wat of Python!

3. Strange loop

None shall pass!

2. Can't catch me

It takes much more to summon Batman, you know.

1. The truth is out there

You had probably seen it coming.... Yeah, you certainly had.

If you know any similar quirks of Python, be sure to present them in comments!

But it's usually not too long before our list grows big and it becomes unfeasible to render it all on the server. Or maybe, albeit less likely, we want it to be updated in real-time, without having to reload the whole page. Either case requires to incorporate some JavaScript code, talking to the server and obtaining next portion of data whenever it's needed.

Obviously, that data has to be rendered as well, and there is one option of doing it on the server side, serving actual HTML directly to JS. An arguably better solution is to respond with JSON or similar representation of our items. This is conceptually simpler, feels less messy and is potentially reusable as a part of website's external API. There is just one drawback: it forces rendering to be done also in JavaScript.

While it isn't a hindrance by itself (there are many great tools to help, including Mustache or - sadly discontinued - jQuery Templates), it raises an issue of code duplication. Ideally, we would still want some initial data to be displayed just when the page itself is loaded. And at first, this seems as to require both server-side and client-side rendering functions... I hope I do not really have to explain why it would be a mighty bad idea to create, use and (try to) maintain them.

Client is king

That's why we would opt for rendering exclusively in the browser. Fortunately, it is not only possible, but also quite easy if we already have the logic for handling AJAX calls. Using it, we can prepare initial items in JSON format and put them directly inside some <script> block:

Here, the |json filter represents the before mentioned logic, while renderItems draws the objects-turned items as children of given element. What it does inside can vary from manipulating HTML strings directly (eww!), creating DOM objects (slightly better) or invoking some JS templating engine (best).

Striving for modularity

A simple solution, outlined above, looks sufficient for many practical applications. It is far from ideal, though. For one, it suffers from an acute disconnection, since the actual place where the data is displayed ($('#items')) can be arbitrarily far from the <script> tag. But more importantly, it scales poorly and lacks modularity: should we need to use our list on more than one site, we may need to carefully tailor several moving parts - such as the '#items' selector.

Incidentally, both of those issues can be resolved at once. Let's create a self-replacing <script>: quite similar to the one above, but with some interesting twists. Rather than referencing some DOM element via hard-coded selector, it shall render the items "where they stand": exactly where the very <script> is located. And just as a final touch, the script will even remove itself from the DOM tree when it's no longer needed.

The solution...

Sounds like a pretty clever trick, but it's not exactly complicated at all. In its entirety, it can look somewhat like this:

What makes it work is the fact that var $script = ...; line lies outside of the $document.ready function. Thanks to that, it is executed as soon as the <script> block is parsed - before the rest of document is processed, and way before the $(document).ready callback is invoked.
At that early time, this script is therefore the last <script> element in the DOM tree. In other words, it's exactly what $('script').last() will return! What we are doing in the first line is therefore nothing else, but obtaining a reference to the enclosing <script>.

How's that useful, though?... Well, if we have indeed dropped this <script> right where we wanted our dynamic list to display, its parent() would be the element to render our items in. And because we don't mind cleaning up after ourselves when done, we finish this by remove()-ing the script. Nice and tidy.

...and how to use it

What makes it a pretty powerful technique is easy and flexible integration with modern templating engines. We can almost effortlessly made this snippet into a reusable template part, such as Jinja macro:

The final usage would be then extremely clean and simple:

So, I decided to bring up Firebug and find out how this nifty trick actually works. Taught by past experiences, I expected a tightly coupled mis-mash of DOM and CSS hacks, with lots of moving parts that need to be carefully adjusted in face of any changes. Alas, I was wrong: it turned out to only use CSS, in succinct and elegant manner. After simple reverse-engineering, I uncovered a clever solution involving gradients, opacity and :before/:after pseudo-elements. It definitely deserves some press, so let's look into it.

CSS is just not there yet

As far as I am aware, there is no portable way to do graphical post-processing of element's content using just CSS attributes (IE-specific filter styles and early CSS4 drafts notwithstanding). In other words, CSS is far below in sophistication and power when compared even to first generation of pixel shaders - an ancient technology from two decades ago. Any techniques that appear to use such magic anyway - like multiplicative blending of text with gradient texture - are therefore just faking it, most likely with smart tricks involving overlapping layers, images and backgrounds, carefully positioned one over another.

The gradient-fade text ellipsis, which I'm describing here, is no different. It uses the sole type of per-pixel transformation that is easily accessible in present-day CSS: alpha blending. Thanks to years of standarization and growing pressure on browser vendors, the power of opacity control is now at our disposal, ready to take us into the semi-transparent future...
But while the simple opacity property is often the exact thing we need, it's not the case if we want to apply a gradient over text. Mostly because it wouldn't be really smooth (especially for larger font), and partially because of the ugly markup it would result in, with every character wrapped up in its own <span>... Eww! Surely there must be a better way.

If it's going out, then something is covering it

And indeed, there exists a much cleaner solution. It involves placing an additional layer over the text - one with an actual gradient background. In CSS3, it is possible to generate such background on the fly by using the linear-gradient function:

This will create a pattern going (left to right) from transparent to opaque white. When applied to a block element, this style turns it into a "dimmer" which can be placed over content that we want to be fading out. Provided we do this correctly, the browser's alpha blending mechanism will take care of rest.

Note that linear-gradient is a CSS3 feature. For maximum compatibility, you should include the vendor-specific versions of it, prefixed by -moz-, -webkit-, -o- and -ms-. This is yet another reason to use a CSS preprocessor such as LESS.

How to position it properly

CSS veterans probably know all crooks and crannies of the infamous position property and the exact rationale behind choosing specific value for it. Mere mortals (like us) just vaguely remember some tidbits, such as the need of using position:absolute if you want to organize your content into layers. That's just part of the puzzle, though - you also need position:relative on the parent element:

Specifying 0 for both top and bottom will automatically set the correct height of our .dimmer element, while right:0 will align it properly. Its width can be specified as either percentage or px; this adds some flexibility should we want to apply this effect to elements of varying sizes.

Tidying up

Our solution is not yet complete, as one inconvenience still remains. We require the .dimmer element to be included in HTML, nullifying our effort to only use CSS for the effect. Thankfully, it isn't quite a big of an obstacle as it may look at first glance.

Yet another CSS feature comes handy here: the :before/:after pseudo-elements. Essentially, they give us two "free", virtual children for any DOM element - a first and last one, respectively. Coupled with content and counter-* properties, they allow for some really clean and powerful constructs, such as automatic insertion of quote chars around given text or out-of-the-box numbering (without <ol>).

But for our gradient trick, we don't need these features. We just want to turn one of those pseudo-elements into functional equivalent of the .dimmer <div>, so we don't have to insert it into DOM anymore. As it turns out, this isn't at all difficult:

Here we used the :after element as it seemed more logical, but it is perfectly valid to style the :before one instead. The important bit is getting rid of the inner <div>: since we use a pseudo-element, it is not needed anymore. Our implementation is now purely CSS-based.

Success!

:last

In its current incarnation, CSS is not nearly as powerful and convenient as we (especially programmers) would like it to be. Still, it might allow for neat & tidy solutions - if we know where to look for relevant features and have some creativity to assemble them together.

Jego celebracja w założeniu polega na napisaniu notki, w której polecamy swoim czytelnikom pięć innych blogów - na przykład takich, które regularnie czytujemy. Nic prostszego, prawda? Wystarczy przecież spojrzeć na listę w swoim czytniku RSS - i już...
Cóż, niezupełnie - a przynajmniej nie w moim przypadku. Chociaż bowiem lista nie jest pusta, to nie wydaje mi się, żebym mógł się nią jakoś specjalnie chwalić. Widnieją na niej głównie klasyki, które powinny być wszystkim znane - takie jak Coding Horror czy Joel on Software - lub wyspecjalizowane blogi poświęcone wąskiemu tematowi - jak blog Nicka Johnsona o Google App Engine. Nie widzę specjalnego sensu w szczegółowym opisywaniu któregokolwiek z nich. Mógłbym co najwyżej wspomnieć o rzadko aktualizowanych perełkach w stylu Linux Hater's czy Hyperbole and a Half, ale wolałbym nie obdarzać was zbyt wielką liczbą narzędzi wspomagających prokrastynację ;)

Dlatego też postanowiłem odwrócić "tradycję" Dnia Blogowania i poprosić czytelników o polecenie innych blogów podobnych do niniejszego - lub nawet zupełnie odmiennych, o ile tylko zachowamy ustalone proporcje (4 do 1). Przy odrobinie szczęścia długość powstałej w ten sposób listy interesujących blogów powinna o wiele rzędów wielkości przekroczyć 5 :)

W ramach zapoznawania się z poszczególnymi składowymi HTML5, nie mogłem więc nie przyjrzeć się bliżej elementowi <canvas> - bo to o nim oczywiście mowa. Tradycyjnym testem dla tego rodzaju rozwiązań (tj. graficznych bibliotek 2D), który zawsze staram się zaimplementować na początku, jest... chmara odbijających się piłeczek :) Nie inaczej było i w tym przypadku, czego efekty zamieszczam tutaj wraz z krótkim opisem i wprowadzeniem w podstawy Canvasa.

Gotowe demo

Twoja przeglądarka nie obsługuje elementu canvas.


Rezultat końcowy powinien być widoczny powyżej - a przynajmniej takie jest założenie :) Jeśli przykład uruchamia się poprawnie, to oprócz podziwiania trzech piłeczek, które są w nim już od razu, możemy dodawać nowe poprzez klikanie w obszar canvasa.
Robiąc to wystarczająco uparcie możemy dokonać prostej oceny efektywności renderowania w naszej przeglądarce. Wystarczy obserwować, jak zmienia się licznik FPS w miarę dodawania kolejnych obiektów. Nie obiecuję jednak, że zauważymy jakiekolwiek interesujące zmiany zanim zabawa nam się znudzi ;)

Jak to jest zrobione

Całość przykładu od strony kodu HTML zamyka się w jednym jedynym znaczniku <canvas>:

Pod względem zachowania wobec innych elementów strony, jest on bardzo podobny do znacznika <img>, czyli zwykłego obrazka. Różnica polega oczywiście na tym, że można w nim swobodnie rysować. Trzeba tylko pamiętać o ustawieniu wymaganych atrybutów width i height na wartości w pikselach - użycie stylów CSS niestety nie wystarczy.

Narysowanie czegokolwiek wymaga już kodu przez nieco większe K, czyli JavaScriptu. Dla wygody założę, że dysponujemy biblioteką jQuery. Jeśli nie jest to prawdą, to właśnie jest doskonała okazja, żeby naprawić to niedopatrzenie ;P Biblioteka ta nie jest wprawdzie pomocna do samego rysowania po canvasie, ale znakomicie ułatwia wszystkie inne czynności, które są z tym związane.

Kontekst rysowania

Graficzne API elementu <canvas> jest w całości zamknięte w obiekt kontekstu. Jest to odpowiednik kontekstu urządzenia z Windows GDI, obiektu Graphics z GDI+ i pewnie jeszcze wielu podobnych obiektów z innych bibliotek. Wszystkie wywołania, które rysują cokolwiek albo zmieniają parametry rysowania, wykonywane są na tym właśnie obiekcie.
Kontekst pobieramy z obiektu DOM canvasa metodą getContext:

...oczywiście po wcześniejszym sprawdzeniu, czy jest ona dostępna. Od razu też rozwieję nadzieje: niestety, obecnie "2d" jest jedyną pewną opcją :)

Funkcja update

Używając kontekstu możemy od razu coś narysować, ale jeśli nie chcemy prezentować tylko statycznych obrazków, to musimy jakoś zapewnić regularne wywoływanie kodu renderującego. Nie możemy oczywiście wpaść w pętlę, więc typowym rozwiązaniem jest funkcja setTimeout z odpowiednio krótkim interwałem. W HTML5 istnieje jednak teoretycznie lepsze rozwiązanie w postaci funkcji requestAnimationFrame. Ponieważ jednak z jego obsługą w różnych przeglądarkach jest różnie, trzeba sobie niestety zapewnić odpowiedni fallback:

W zamian możemy liczyć na wywołania zwrotne z częstotliwością ok. 60 na sekundę i - przynajmniej w teorii - optymalizację rysowania po elemencie DOM wskazanym jako drugi parametr.

Rysujemy piłki

Jak nietrudno zauważyć, piłeczki które odbijają się powyżej to po prostu wypełnione okręgi. Narysowanie takiej jakże skomplikowanej figury geometrycznej nie jest może wielkim wyzwaniem, ale wymaga zastosowania kilku koncepcji z API elementu <canvas>.
I tak zaczynamy od ustawienia stylu wypełnienia na jednolity kolor fioletowy:

Styl ten może być nie tylko dowolnym kolorem (w formacie CSS, czyli np. #ffffff lub rgba(...)), ale także gradientem lub powtarzalnym wzorem złożonym z kopii obrazka. Przypomina więc to np. obiekt typu brush z GDI.
Samo rysowanie kółek jest trochę bardziej złożone niż można by się spodziewać, bo wymaga w sumie trzech wywołań:

Jest tak dlatego, że kształty na canvasie opisujemy w formie ścieżek (paths), które potem wypełniamy (metodą fill) lub obrysowujemy (stroke). Kształt każdej piłki to nowa ścieżka (beginPath), składająca się z jednego łuku okręgu (arc), który opisujemy pozycją środka, promieniem oraz zakresem kątów. Nas oczywiście interesuje pełne koło, więc ów zakres ustalamy na .

Trochę tekstu

Poza samymi piłkami na ekranie widoczna jest też ich ilość oraz, naturalnie, licznik FPS-ów :) Wartość dla tego ostatniego liczymy dokładnie tak samo, jak w każdej innej sytuacji, tj. pobierając w każdej klatce aktualny czas (tutaj funkcją now z jQuery) i odejmując od niego poprzedni rezultat, a następnie uśredniając wynik:

Komu powyższy kod nie wydaje się do końca zrozumiały (przy wzięciu poprawki na język programowania, rzecz jasna ;]), polecam chociażby mój artykuł na temat pętli czasu rzeczywistego, gdzie powyższa konstrukcja jest dokładnie opisana.
Tutaj zajmiemy się natomiast wypisaniem obliczonej wartości FPS oraz aktualnej ilości piłek. Nie jest to bynajmniej trudne:

Tym razem ustawiamy styl obrysowania i wyrównywanie tekstu względem pozycji rysowania. Tekst wypisujemy funkcją strokeText, przyjmującą też współrzędne X i Y.

Reszta...

To w zasadzie tyle, jeśli chodzi o samo rysowanie po canvasie. Do poprawnego działania przykład potrzebuje oczywiście jeszcze kilku innych rzeczy, takich jak choćby implementacja poruszania się i odbijania piłek oraz obsługę kliknięć. Ponieważ jednak nie dotyczą one bezpośrednio API graficznego, nie będę im poświęcał miejsca w tym i tak już zdecydowanie przydługim wpisie. Można się im oczywiście przyjrzeć, czytając pełny kod przykładu działającego wyżej.

Jeśli zaś ktoś chciałby dalszych informacji na temat możliwości i wykorzystania elementu <canvas>, to dobrym punktem wyjścia jest tutorial na stronach Mozilli. Zawsze też można odwołać bezpośrednio do standardu :)

W książce można bowiem znaleźć przegląd kilku elementów składających się na standard HTML5 oraz paru technologii pobocznych, które formalnie do standardu nie należą, ale często są uwzględniane pod parasolem szerszej definicji całego zjawiska/technologii/ruchu/trendu/czegokolwiek-czym-to-jest. Wśród nich mamy takie podstawy jak nowe elementy strukturalne, nowe i przedefiniowane znaczniki opisu tekstu, poszerzone możliwości formularzy i różne drobne usprawnienia składniowo-semantyczne. Nie są one może tak ekscytujące jak "gwiazdy" technologii HTML5, ale fakt ich porządnego uwzględnienia jest według mnie tym bardziej godny uwagi.
Oczywiście nie zabrakło też wielu "nowych wspaniałych API", dzięki którym możemy chociażby tworzyć SQL-owe bazy danych po stronie klienta i wykonywać szereg innych niezbędnych a właściwych dla stron WWW czynności ;D I tak możemy na przykład dowiedzieć się, co to właściwie jest ten Canvas, w jaki sposób zapewnić wsparcie dla techniki drag & drop i do czego w zasadzie mogą przydać się te całe webowe gniazdka (czyli Web Sockets). Ponieważ wszystko pokazane jest na prostych przykładach, opanowanie podstaw każdego z tych rozwiązań dla ogarniętego programisty nie stanowi żadnego problemu.

Kluczowym słówkiem są tu jednak owe 'podstawy'. Chociaż różne tematy są tu opisane z różnym poziomem szczegółowości - czasem nawet zbyt dużym, jak choćby w przypadku <audio>/<video> - to jednak w żaden nie jest opisany wyczerpująco. Nie wskazuję tego jako wady, bo przecież mówimy o książce z wyraźnym napisem "wprowadzenie" na okładce. Poza tym w prawie każdym miejscu, gdzie autorzy świadomie coś pomijają, podawane są inne (zwykle internetowe) źródła, z których można czerpać bardziej szczegółowe informacje. Trzeba też powiedzieć szczerze, że właściwie żaden z opisywanych tematów (może poza Canvasem) osobno nie prezentuje się jako specjalnie skomplikowany bądź obszerny. Skondensowane wprowadzenie może więc równie dobrze być całkowicie wystarczające.

Podsumowując więc: lektura okazała się jak najbardziej pożyteczna. Książkę czyta się szybko i bez wielkiego wysiłku, a jednocześnie można się z niej dowiedzieć wielu interesujących rzeczy. Jeśli nawet nie zamierzamy - za przeproszeniem - programować w HTML5, to przeczytanie tej książki da nam ciekawy wgląd w technologie będące podobno przyszłością Internetu czy nawet aplikacji jako takich.

Centralnym mechanizmem, wokół którego kręci się światek Stack Overflow (oraz niezliczonych innych stron opartych na tym samym silniku) jest reputacja poszczególnych użytkowników. To zwykły numer, w swoim znaczeniu podejrzanie podobny do tzw. karmy, nad której obecnością na forum Warsztatu raz się nawet nieco rozpisałem. Reputacja jest zwiększana między innymi wtedy, gdy nasze pytania lub odpowiedzi zostaną poparte (upvote) przez innych użytkowników. To nam daje punkty, które w większej ilości przekładają się na przywileje quasi-moderatorskie. W sumie jest to więc klasyczny przykład sprzężenia zwrotnego dodatniego (positive feedback loop), występującego w świecie w najprzeróżniejszych formach - od giełdy po FarmVille.

Jak w każdym takim systemie, także i tutaj wszystkie trybiki nie zawsze jednak działają idealnie. Ponieważ reputacja w serwisie SO jest dobrem mającym wartość także poza nim, nie dziwi duża chęć do jej zwiększania, występująca u wielu użytkowników. Nie jest to wbrew pozorom nic trudnego - nawet mimo obecności licznych ekspertów z niemal każdej poddziedziny związanej z programowaniem, którzy weryfikują i oceniają udzielane odpowiedzi.
Jest tak z prostej przyczyny: w serwisie pojawia się całe mnóstwo pytań trywialnych, na które bez problemu odpowie każda średnio zaawansowana w danym temacie osoba. Ze względu na ilość użytkowników (ponad 700 tysięcy) fakt ten generuje dość komiczne sytuacje, gdy w przeciągu mniej niż minuty pojawiają się trzy albo cztery niemal dokładnie identyczne odpowiedzi. Zabawa czasami zamienia się więc raczej w konkurs szybkiego pisania na klawiaturze :)

Mimo tych wad muszę stwierdzić, że uczestnictwo w dyskusjach na SO jest w ogólnym rozrachunku bez wątpienia pożyteczne. Wymierną osobistą korzyścią jest oczywiście sama reputacja, przeliczalna rozmiar ego po bardzo korzystnym kursie ;] Ważniejsza jest aczkolwiek możliwość utrwalania i poszerzania swojej wiedzy w wybranych działkach koderskiej działalności.

Z tą bolączką można sobie oczywiście radzić we własnym zakresie, podłączając na przykład arkusze CSS pod system szablonów normalnie używany do generowania stron HTML na poziomie serwera. Nie wydaje się to jednak najlepszym możliwym sposobem na zużywanie jego zasobów. Istnieją też na pewno bardziej interesujące rzeczy, które mógłby zrobić programista w czasie, gdy będzie takie (z natury raczej specyficzne) rozwiązanie implementował.

I tutaj pojawia się bardzo ciekawy projekt o nazwie LESS, rozszerzający składnię CSS-a o wiele przydatnych elementów, jakich domyślnie w nim nie uświadczymy. Najfajniejsze jest przy tym to, że trik ten odbywa się po stronie klienta przy pomocy odpowiedniego skryptu JavaScript. Możemy więc korzystać z niego niezależnie od backendu naszego serwera czy nawet w ogóle bez serwera, tj. do stron bez dynamicznie generowanej treści. Integracja jest zaś bardzo prosta: sprowadza się do dodania jednego znacznika <script> (oczywiście) oraz lekkiej modyfikacji referencji do arkuszy stylów, czyli znaczników <link rel="stylesheet">.

Co dostajemy w zamian? Oprócz wspomnianych na początku zmiennych i operacji na nich, mamy też w LESS-ie "funkcje" (czy raczej makra) z parametrami. Pozwala to chociażby na łatwiejsze dostarczanie stylów specyficznych dla przeglądarek. Możliwe jest też np. importowanie kodu z innych arkuszy LESS, zagnieżdżanie selektorów oraz... wstawianie komentarzy w stylu C++ :)
Powyższe wyliczenie dodatków nie brzmi może bardzo imponująco, lecz nie jest to wcale dziwne. Tak naprawdę sam CSS już dawno powinien oferować tego rodzaju możliwości. Wiemy jednak, jak jest w rzeczywistości. Sądzę więc, że tym bardziej warto jest używać rozwiązania, które zamienia CSS w coś, czego można w końcu normalnie używać :)

A czy istnieje? No właśnie :) Traktując to jako swego rodzaju pouczającą zabawę, postanowiłem zbadać sprawę i wysmażyłem odpowiedni program, który potrafi automatycznie wykonywać procedurę opisaną na początku, tj. kolejno przechodzić przez teksty w Wikipedii i "klikać" w pierwsze linki z ich treści. Szybko zorientowałem się wtedy, że twierdzenie o zbieżności do Philosophy jest tylko wycinkiem większej, bardziej interesującej całości.
Okazało się bowiem, że Wikipedia ma coś w rodzaju uniwersalnego atraktora, którego 'filozofia' jest częścią. Ma on postać cyklu zmieniającego się w czasie (z powodu edycji, oczywiście) i obejmuje interesujący zestaw pojęć, które semantycznie są połączone zależnością rekurencyjną. Obserwując kształt owego cyklu w dłuższym przedziale czasowym, można by zapewne wyodrębnić terminy zupełnie podstawowe, które są w nim obecne stale lub wypadają tylko na krótką chwilę. Kto wie, może w ten sposób udało by się dokonać jakiegoś fundamentalnego odkrycia z dziedziny filozofii, na przykład odpowiedzieć na pytanie o życie, Wszechświat i całą resztę? ;-)

Nieco mniej ambitnym wyzwaniem jest zbadanie, jak daleko od atraktora znajdują się pewne hasła. Innymi słowy, ile kliknięć dzieli nas od wpadnięcia w cykl zapętlających się pojęć, jeśli zaczynamy od danego artykułu? Jeśli zastanowimy się nad tym chwilę, to można dojść do wniosku, że odpowiedź byłaby miarą odwrotności "stopnia abstrakcji" danego pojęcia. Skoro bowiem w atraktorze znajdują się terminy bardzo ogólne, oddalanie się od niego powinno nas przybliżać do konkretów. Czy tak jest w rzeczywistości?...
Wygląda na to, że faktycznie coś w tym jest. Poniżej przedstawiam tendencyjne wyniki sprawdzenia pewnej liczby bynajmniej wcale nie losowo wybranych haseł. i obliczenia odległości każdej z nich od Czarnej Dziury Abstrakcji:

Nie jestem wprawdzie do końca pewien, co oznacza to, że Angry Birds są niemal dwa razy bardziej abstrakcyjne od Juliusza Cezara, ale na pewno musi to coś znaczyć ;]

• wcale nie muszą być asynchroniczne, chociaż zwykle są
• wcale nie muszą być kodowane w języku JavaScript (chociaż niemal zawsze są)
• wcale nie muszą zwracać wyniku w formacie XML, bo zwykle używa się prostszych formatów

Ważna jest tu zwłaszcza uwaga ostatnia. Chociaż API do wysyłania żądań HTTP składa się z klasy o nazwie XMLHTTPRequest, to w istocie nie ma obowiązku korzystania z wbudowanego w nią parsera XML. Równie dobrze potrafi ona zwrócić odpowiedź serwera HTTP w postaci tekstowej, którą możemy potem przetworzyć ręcznie. W praktyce chyba najbardziej popularnym formatem zwrotnym dla zapytań AJAX-owych jest opisywany już przeze mnie JSON.
Oczywiście, nikt przy zdrowych zmysłach nie pisze samodzielnie kodu do owego "przetwarzania ręcznego" odpowiedzi z serwera. Zarówno ten końcowy etap, jak i samo wysyłanie żądania zostało bowiem opakowane w kilka użytecznych frameworków. Jednym z nich jest choćby jQuery, który poza ukrywaniem zbędnych szczegółów AJAX-u posiada też mnóstwo innych przydatnych funkcji ogólnego przeznaczenia.

Do czego może przydać się możliwość łączenia się z serwerem HTTP z poziomu Javascript? Żeby znaleźć odpowiedź, wystarczy dobrze przyjrzeć się właściwie dowolnej bardziej skomplikowanej stronie internetowej..Prawie na pewno znajdziemy na niej mechanizmy, które w tle pobierają dodatkowe dane z macierzystego serwera lub wysyłają doń jakieś informacje. Dzięki temu mogą one realizować takie funkcje jak:

• Dynamicznie pobieranie nowych treści, które pojawiły się od czasu przeładowania witryny. Ładnym przykładem takie zachowania jest Twitter. Jeśli zostawimy stronę otwartą w zakładce przeglądarki, wówczas po jakimś czasie możemy odnaleźć na niej ramkę z napisem w rodzaju "2 new tweet(s)", po kliknięciu której zobaczymy od razu nowe statusy.
• Doczytywanie starszych elementów w trakcie przewijania. To odwrotny (chronologicznie) przypadek do powyższego, będący alternatywą dla stronicowania. Przykładem strony świetnie stosującej to rozwiązanie jest dzone.
• Wyświetlanie szczegółów elementu, na przykład w dymku (tooltip) po najechaniu na niego kursorem myszy lub po rozwinięciu do większej postaci. Oczywiście ma to sens głównie wtedy, gdy treść do pobrania jest na tyle duża, że nie jest rozsądne dostarczanie jej wraz z pierwotną treścią strony.
• Wysyłanie formularzy bez przeładowywania strony. Normalnie przesłanie formularza na stronie skutkuje jej przeładowaniem w wyniku żądania typu POST (rzadziej GET). Można jednak przechwycić zdarzenie wysłania formularza i zamiast niego przesłać zapytanie AJAX-owe. Sensownym wykorzystaniem tej techniki jest weryfikacja nazwy użytkownika po wciśnięciu osobnego przycisku w formularzy rejestracyjnym do wielu serwisów sieciowych.
• Podpowiadanie zapytań w przypadku wyszukiwania. Tutaj nietrudno o przykłady, bo robią to wszystkie wyszukiwarki internetowe ogólnego przeznaczenia, a także sporo dedykowanych mechanizmów wyszukiwania obecnych w serwisach sieciowych.
• Synchronizacja edytowanego dokumentu (Google Docs), obsługa czata (Facebook), map (Google Maps) i wielu innych zaawansowanych logicznie aplikacji webowych.