Forum.Gomoku.pl

[templar]

Ponieważ temat HTML5 jest co raz żywszy i bardziej popularny w świecie web developerów, to pomyślałem sobie, że warto byłoby wyjaśnić o co w ogóle w tym wszystkim chodzi... i postaram się to wyjaśnić w sposób w miarę przystępny. Ponieważ temat jest bardzo obszerny, to nie sposób o wszystkim w pełni opowiedzieć, dlatego zakładam, że osoby, które to czytają mają przynajmniej blade pojęcie o tym czym HTML jest.

Zacznijmy więc od podstaw. Czym jest HTML5? Tak de facto to jest to tylko i wyłącznie specyfikacja, pewien zbiór zasad na bazie których powinny działać przeglądarki. Zasady te są tworzone i rozwijane przez organizację o nazwie World Wide Web Consortium, w skrócie W3C. Co ciekawe nazwa HTML5 jest dość mylna, bo z samym HTMLem to nie wiele ma wspólnego (bardziej z przyczyn historycznych jest jaka jest). Prawdą jest że do samego metajęzyka zostało dodanych parę nowych tagów, takich jak <canvas> czy <video>, ale żeby uzyskać pożądane efekty to i tak trzeba wesprzeć JavaScriptem (nie mylić z Javą).

Przypomnę, że JavaScript jest językiem programowania, którego używają wszystkie nowoczesne przeglądarki (niestety nie we wszystkich działa wszystko tak samo). Podsumowując: można powiedzieć, że HTML5 jest specyfikacją dotyczącą nowej wersji metajęzyka HTML oraz języka JavaScript. Nowinek w HTML5 jest naprawdę masa, więc ciężko tu wszystko opisać. Kilka więc moich myśli:

<canvas>, <video> i <audio>

Tagi te umożliwiają: tworzenie animacji, wyświetlanie plików wideo i puszczanie plików muzycznych odpowiednio. Bezpośrednio w przeglądarce. Do tej pory, żeby móc używać tego typu rzeczy, to trzeba było korzystać z Flasha czy innych wtyczek. Pierwszy z wyżej wymienionych tagów jest używany w nowej (eksperymentalnej) wersji kurnika. Oczywiście, żeby wykorzystać w pełni ich możliwości (zwłaszcza canvasa) to trzeba użyć do tego JavaScriptu, w którym możemy dokładnie zaprogramować to co chcemy uzyskać.

WebSocket

O, to jest coś naprawdę fascynującego i dobrego. Żeby zrozumieć o co z tym chodzi, to musimy zrozumieć jak się odbywa komunikacja przez internet. Przeglądarki działają na protokole HTTP (tak de facto HTTP/1.0), którego możliwości są niestety ograniczone. Postaram się zobrazować jak to wszystko działa.

Wyobraźmy sobie, że mamy użytkownika A i serwer X. Komunikacja przez HTTP działa tak, że użytkownik A wysyła żądanie do serwera X (np. w postaci linka, przykładowo http://google.pl ). Serwer X odbiera żądanie, przerabia je i odpowiada stroną HTML. Użytkownik A odbiera stronę HTML od serwera, przeglądarka ją wyświetla i połączenie zostaje zamknięte.

Ten schemat sprawia, że serwer może obsłużyć o wiele więcej połączeń w danym czasie niż by mógł, gdyby tych połączeń nie urywał. Ale ma to też swoje minusy. Wyobraźmy sobie znów serwer X, ale teraz mamy trzech użytkowników: A, B i C. Użytkownicy Ci siedzą na czacie, który działa tak: użytkownik A wysyła wiadomość do serwera X, serwerem ją odbiera i rozsyła tę wiadomość do B i C.

Ale tu się pojawia problem. Jak serwer X może wysłać wiadomość do B i C, skoro połączenie między nimi jest martwe? Zgodnie z protokołem HTTP komunikacja między serwerem, a użytkownikiem może mieć miejsce tylko i wyłącznie gdy użytkownik sam wyśle żądanie. Serwer sam z siebie nie może wysyłać nic do B i C. To B i C muszą poprosić o dane.

Problem ten nie istnieje gdy się używa dwukierunkowych protokołów, jak np. TCP czy UDP. W TCP serwer wie o tym, że użytkownicy A, B i C są do niego podłączeni i może spokojnie rozsyłać do nich wiadomości, a one mogę wysyłać do niego. Wszystko działa gładko i przyjemnie, ale niestety stałe utrzymanie łącza TCP o wiele bardziej obciąża serwer niż HTTP.

Natomiast protokół HTTP jest jednokierunkowy. Więc jak działają czaty w przeglądarkach (bez wtyczek)? Są na to różne tricki (np. tzw. long-polling), żeby ominąć jednokierunkowość HTTP, ale na koniec dnia i tak zostajemy z jeszcze bardziej niewydajnym systemem niż TCP.

Temu problemowi wychodzi na przeciw HTML5 definiując protokół HTTP/1.1. Umożliwia on utworzenie dwukierunkowego połączenia TCP między użytkownikiem, a serwerem. JavaScript daje programistom narzędzie nazwane WebSocket, które właśnie pozwala na tworzenie takowych połączeń z serwerem.

Jest to rzecz bardzo ważna. Do takiego stopnia, że sam kurnik musiał być postawiony na Javie. Nie ze względu na jakieś graficzne aspekty (których brak jest oczywisty), ale właśnie ze względu na to, że wcześniej przeglądarki nie miały możliwości tworzenia połączeń TCP. A w grach multiplayer tego typu połączenia są koniecznością. Java (jako wtyczka do przeglądarek) już takowe połączenia tworzyć z pewnością może (tutaj trochę spekuluję, bo nie jestem programistą Javy, ale byłbym bardzo zaskoczony gdyby to nie miało miejsca).

Podsumowanie

Co to wszystko tak naprawdę oznacza? Jakie będą tego konsekwencje? No, w przeciągu najbliższych lat z pewnością popularność Flasha, Javy, Silverlighta czy innych wtyczek bardzo spadnie. Być może do tego stopnia, że część z nich kompletnie umrze, tak jak np. już umarło Google Gears. Dlaczego umrą? Z powodu unifikacji. Potrzebna będzie znajomość tylko jednego języka, JavaScript, żeby zaprogramować odtwarzacz wideo, czy zrobić jakąś animację czy po prostu naklepać stronkę. Do tej pory trzeba było znać ActionScript (Flash) albo Javę albo C# (Silverlight), nigdy więcej.

Wsparcie

Wiem tylko jak wygląda wsparcie dla canvasa i WebSocketów, bo te dwa aspekty HTML5 mają dla mnie największe znaczenie.

Jak do tej pory od dłuższego czasu FireFox i Chrome wspierają HTML5 maksymalnie jak się da.

Pozostałe przeglądarki są w tyle. IE9 wspiera canvasa, ale WebSockety ma ponoć dopiero IE10 wspierać - jak będzie, to się okaże.

Safari i Opera wspierają canvas, ale nie WebSockety. Obydwie przeglądarki wspierają starszą (już nieaktualną) wersję WebSocketów. W tym momencie jest ona niewykorzystywana.

Tak to mniej więcej wygląda. Jak by ktoś chciał o coś zapytać, czy skomentować, czy skrytykować to zapraszam do dyskusji.

templar

[Magda]

"Skrytykować" powinno być pogrubione!

[ermijo]

Super post. Przeczytałem całość, może dlatego, że treść oscylowała na granicy "przydługawa" VS "ciekawa". Ja tam wolałem flashowe wtyczki wideo, bo łatwo można było wyłuskać plik na podstawie źródła strony. Z tymi javasctiptowymi jest albo gorzej albo tragicznie.

[bad_mojo]

[truskawek]

(Nauczyłeś się o tym na studiach? Czy jesteś samoukiem?)


Co oznacza "wspiera" w twoim poście?

[templar]

[Chaosu]

. . .Wspiera to tłumaczenie angielskiego support i pewnie dlatego tak się mówi. Nieco trafniejsze wydaje się polskie obsługuje choć ani jedno ani drugie nie jest uniwersalne, a angielskie handling jest używane w zupełnie innych sytuacjach. Dlatego pewnie używa się w j. polskim bezpośrednich tłumaczeń (żeby się informatykom nie myliło).

[soul_reaper]

[bad_mojo]

Ja też miałem informatykę na SGH, na zajęciach teoretycznych uczyłem się o ploterze, a na praktycznych naukę skończyliśmy na tym, że w programie jest pasek adresu i pasek stanu. I niestety nie żartuję - moją pracę zaliczeniową z praktycznej części rysowałem ołówkiem na kartce papieru. Poważnie. A to było w 2006 roku. Powinienem o tym nakręcić chyba film, bo mi nikt nie uwierzy.

[Barfko]

A mnie się studia przydają. Od czasu do czasu działam na dużych grafach i o ile kodowanie nie ma wiele wspólnego z tym na studiach (które i tak głównie było w pseudokodzie), algorytmy, nawet te dające najlepsze współczynniki z (zeszłego roku np.) nie odbiegają istotnie od algorytmów, których się na studiach uczyłem. Nie sądzę natomiast, że cokolwiek ze studiów przydałoby mi się w kodowaniu dla przemysłu. Prawie rok dorabiałem jakiś czas temu na NetWeaverze - ze studiami nie miało to nic wspólnego.

[ermijo]

Pamiętam czasy studiów, rok 4 i 5, od kiedy to studentów zaczynano traktować nieco bardziej "po ludzku" niż zasadzie "wykuj i zdaj". Pewien dość swobodnie prowadzący ćwiczenia z elektroniki doktor wygłosił poważnie, że:
"studia tak na prawdę uczą umiejętności uczenia się".