Jakie są plusy i minusy? Co sądzicie o HTML5? Ktoś już robił coś w tym? Czy pokona FLASHA?
Eksperymentalne gry w HTML5
http://www.chromeexperiments.com/
Np. gra Flower Power
http://www.chromeexperiments.com/detail/flowerpower/
wygląda przecudnie.
Inne
http://www.chromeexperiments.com/detail/gravity/
0
0
Przecież nawet Adobe i Microsoft idą w stronę HTML5. Flash i Silverlight pójdą w odstawkę za kilka lat.
0
Nie jestem pewny, czy wiesz dokładnie czym jest HTML5, bo z Twojego postu to nie wynika...
Jeśli można jakkolwiek przewidywać przyszłość, to na pewno HTML5 ma świetlaną. To język znaczników, który będzie rozpowszechniony w Sieci -- tak jak dzisiaj starsze wersje (X)HTML-a. Na nim będzie bazowała Sieć.
A gierki... gierki to tylko wierzchołek góry lodowej. Tak naprawdę zarówno gierki, jak i buzzword "HTML5" używane są do promowania otwartych, ustandaryzowanych, zaimplementowanych bezpośrednio w przeglądarkach rozwiązań.
Do "HTML-a 5" zalicza się nie tylko język znaczników, ale np. również nowe API, widoczne w przeglądarkach z poziomu JavaScriptu. A więc np. web-workery, czyli coś zapewniającego swoistą (uproszczoną, na szczęście) wielowątkowość w JS-ie. Albo web-sockety, które dają zupełnie nowe możliwości wydajnego, dwustronnego łączenia się z serwerem.
Gry z kolei korzystają z elementu <canvas>, który jest bezpośrednio w języku znaczników HTML5 i który -- poprzez API JavaScriptowe -- umożliwia nam rysowanie rzeczy piksel po pikselu. To oraz lekka domieszka CSS3 (np. kolory rgba) to zwykłe ciegiełki, które dają możliwości tworzenia zaawansowanych witryn-dokumentów www. Jednocześnie, cegiełki (API) te stały się na tyle bogate, że dają nadają ludziom piszącym kod natywnie obsługiwany przez przeglądarki możliwości pozwalające tworzyć efektowne gry, które fajnie się PR-owo sprzedają.
W grach i zaawansowanych aplikacjach duże znaczenie ma skok wydajności silników javascriptowych. Bo te gry HTML5 tak naprawdę nie pisze się "w HTML-u 5". Nie! To zwykły JavaScript! Zobacz tylko na kod! Naprawdę: fakt, że korzystasz z canvasa i że masz wreszcie odpowiednik metody putpixel to fajna rzecz, ale z punktu widzenia kodu -- gdy przyjmie się ją za aksjomat -- to w zasadzie pierdoła! Piszesz stary, dobry kod JS-owy, tyle że tym razem możesz go użyć, by wydajnie(j) manipulować grafiką.
A jest wydajnie(j). Silniki nowoczesnych przeglądarek od kilku lat prześcigają się w wydajności JS-owej, uznając ją za priorytet. Kod JS jest kompilowany praktycznie do kodu maszynowego. JavaScript zyskał swój JIT. Dzisiejsze przeglądarki, mimo że są znacznie cięższe niż stare i że ich wymagania sprzętowe rosną, to jednak wykonują kod javascriptowy o rzędy wielkości (!) razy szybciej niż np. stare IE.
JavaScript ma się jako język bardzo dobrze. Standardy też. Są wspierane przez Microsoft, Google (mają Chrome'a i aplikacje webowe, to im zależy), Apple (nie cierpią Flasha), a teraz nawet samo Adobe zaczyna się powoli poddawać...
HTML5 na pewno ma przyszłość; już teraz jest powszechnie używany. Używam go w każdym nowym projekcie. Ale nie robię gierek. Zwykłe aplikacje www. Wrzuć krótki <!DOCTYPE html> i już używasz HTML-a 5 ;). To się po prostu musi przyjąć, bo ludziom nie chce się kopiować za każdym razem DOCTYPE-ów ;).
A czy wyprze toto Flasha... Na razie Flash ma lepsze środowisko. Może Adobe zrobi jedno dla HTML-a 5? Już powstał kompilator Flash -> "HTML5" (tak naprawdę: JavaScript). Toczy się batalia o video w Sieci. HTML5 ma swój element <video>. Mam nadzieję, że wyprze Flasha, który bywa żałośnie niestabilny. Zresztą, jeśli możesz wystarczająco wydajnie rysować piksel po pikselu, to nawet <video> nie jest konieczne -- niedawno ktoś zaimplementował jakiś kodek bezpośrednio w JavaScripcie... Oczywiście, wraz z <video> dodanie filmika do dokumentu HTML będzie łatwiutkie.
0
Masz rację co do stabilności flasha. Wiele osób na niego narzeka. Poruszyłem to w wątku
UWAGA. Nie instalujcie flash playera 11 bo zawiesza kompa
Jedną z ciekawszych rzeczy jakie przeczytałem o Piątce jest to, że precyzuje np. sposób obsługi błędów, co powoduje, że strony będą wyświetlane na każdej przeglądarce tak samo.
0
maszynaz napisał(a)
precyzuje np. sposób obsługi błędów, co powoduje, że strony będą wyświetlane na każdej przeglądarce tak samo.
Standaryzacja obsługi błędów to rzeczywiście dobra rzecz i pomoże zniwelować różnice w wyświetlaniu stron, ale na pewno nie wystarcza, by to osiągnąć.
Zauważ, że obsługa HTML-a 5 (języka znaczników) ma naprawdę nie aż tak wielki wpływ na wyświetlenie strony. Może inaczej: wpływ ma krytyczny, co pokazują IE <= 8, które domyślnie nie pozwalają na jakiekolwiek ostylowanie nowych tagów (!), ale tak naprawdę więcej problemów nastręczy poziom obsługi CSS (konkretnie: zapewne CSS3). To CSS odpowiada za sposób prezentacji dokumentu. Wystarczy, że przeglądarka nie obsługuje jakiejś własności lub wartości -- i już strona nie będzie wyświetlana tak, jak w przeglądarce z pełną obsługą CSS3.
A tak w ogóle niemożliwe jest, żeby strony wyglądały tak samo na każdej platformie. Niemożliwe i niepraktyczne. Ekrany mają różne rozdzielczości, różne odwzorowania kolorów. Ludzie używają różnych urządzeń i tak naprawdę dokument widziany na 24-calowym, panoramicznym ekranie oglądanym z odległości kilkudziesięciu centymetrów będzie wyglądał zupełnie inaczej niż oglądany na trzymanym w ręce telefonie komórkowym o znacznie mniejszej przekątnej ekranu, ale znacznie większej gęstości pikseli. Trzeba po prostu się z tym pogodzić.
0
A tak w ogóle niemożliwe jest, żeby strony wyglądały tak samo na każdej platformie. Niemożliwe i niepraktyczne
ZTCP to w dokumencie można podać kilka CSSów, np jeden do druku, inny do prezentacji, inny na monitory, w piątce może jest też profil na smartfony, itd Jak pokazuje CSS Zen Garden, za pomocą nawet starego CSSa można zrobić naprawdę duże zmiany. Z drugiej strony przeglądarka nie może np usunąć jakieś tam formularze, bo się niby strona na ekranie telefonu nie zmieści. Rozbieżności w implementacjach HTML5 (+ reszta kompletu) spowodują tylko mniejszą popularność tegoż rozwiązania.
0
IMO w 100% nie zostanie wyparty Silverlight ani flash a to z tego powodu, że jednak w JS i canvasie trudniej jest zrobić pewne animacje zwłaszcza problem braku wielowątkowości, do tego na razie brak jakichś frameworków a to co oferuje nam canvas to tylko bardzo ubogie funkcje IMO przydały by się gotowe, rozbudowane funkcje do rysowania np. paraboli, krzywych itp. do tego sockety - trudno jest zrobić gierke "prawie" realtime z requestami http (wiem, że powoli niektóre przeglądarki już implementują sockety - i całe szczęście). W dodatku pisanie animacji wygląda teraz bardziej jak grzebanie w aśmie niż fajne edytory "wysiwyg" znane z silverlighta czy flasha gdzie jakiś laik (w domyśle grafik nie koder) może sobie wszystko wyklikać na lini czasu.
aha a co z reklamami np. flashowymi vs canvas? zaciągniecie sobie JS'a od reklamodawcy na waszą stronę żeby mógł sobie manipulować zawartością waszej strony?
0
- HTML5 ma Web-Workery, a więc wielowątkowość jest.
- Kto komu każe pisać w czystym JS? Można skorzystać z GWT: http://code.google.com/intl/pl-PL/webtoolkit/ http://code.google.com/p/quake2-gwt-port/
- Manipulować? Tzn twierdzisz, że wszyscy (bez wyjątku) reklamodawcy będą wpuszczać syf na strony reklamobiorców? Teraz niby nie mogą? Tak czy siak wkleja się JSa na stronę przecież.
0
znacznik <video> jest fantastyczny. Umożliwia bezproblemowe i pełnoekranowe wyświetlanie filmów, a także można ku mojej uciesze w prosty sposób zapisywać pliki filmowe na dysku czego nie można było zrobić we flashu. Oby jak najszybciej YT przesiadł się na 5-ke a flash niech zdechnie.
0
Ostatnio mielismy dylemat w firmie: html5 czy silverlight.
Wybor padl na silverlight'a. Dlaczego? Srodowisko developerskie! Sprobojcie zarzadzac wiekszym projektem napisanym w javascripcie... powodzenia ;)
html5 jak najbardziej ma przyszlosc acz poki co nie nadaje sie do bardziej skomplikowanych rzeczy - bo niestety ale wiekszosc firm nie ma tylu pieniedzy i czasu co google na tworzenie czegos fajnego w js'ie.
0
Wibowit a pisałeś w GWT ? Bo ja miałem okazję raz i dziękuję.
0
zestawienie ukazujące jakie formaty multimedialne obsługują przeglądarki
http://blog.piotrnalepa.pl/2011/01/08/html5-jak-wstawic-pliki-audio-i-video-na-stronie-za-pomoca-html5/
Z tego wynika, że jak jeden obsługują to innego nie.
Tutaj większe zestawienie obsługiwanych formatów
http://mediaelementjs.com/
0
maszynaz napisał(a)
znacznik <video> jest fantastyczny. Umożliwia bezproblemowe i pełnoekranowe wyświetlanie filmów, a także można ku mojej uciesze w prosty sposób zapisywać pliki filmowe na dysku czego nie można było zrobić we flashu
jest tak fantastyczny, że nie ma wspólnego pomiędzy przeglądarkami formatu, a to powoduje, że enkoder musi wypluwać kilka outputów. jeśli masz repozytorium liczone w TB i duże obciążenie przetwarzaniem filmów, to użycie playera w html5 będzie pomyłką. flash sprzed roku gwarantuje, że kilka formatów filmu odtworzy się wszędzie, gdzie jest zainstalowany (pomijam urządzenia ze znakiem nadgryzionego jabłka, polityka tej firmy jest dla mnie niezrozumiała). co z odpowiednikiem w html5 dla Smooth Streaming (silverlight) czy Dynamic Streaming (flash)?
pliki filmowe i tak trzeba skądś ściągnąć, więc zapisanie ich na dysku jest tak samo proste/trudne w przypadku flasha, jak i html. chyba, że mowa o filmikach zembedowanych lub zrenderowanych do swf'a, takich czasem nie da się wyciągnąć. to jednak marginalne przypadki.
nie bronię flasha, zawiera mnóstwo błędów. niektóre są znane i ignorowane przez Adobe, a wcześniej przez Macromedia od ładnych kilku (!) lat, co powinno zdyskwalifikować to środowisko. jednak tak się nie dzieje, podejrzewam że ze względu na niezwykle wysoką penetrację rynku przez flash playera. to samo zjawisko będzie pomagało utrzymać się flashowi na fali przez jeszcze ładnych kilka lat. pamiętajcie też, że actionscript jako język typowany jest łatwiejszy do użycia przy dużych projektach.