Nie ukrywam, że prywatnie jestem wielkim sympatykiem technologii Flash i języka ActionScript (prywatnie, gdyż zawodowo Flashem się obecnie nie zajmuję). Tym bardziej zainteresowały mnie coraz głośniejsze szepty na temat zbliżającego się standardu HTML5. Co nowego ze sobą przyniesie? Paradoksalnie, domeną HTML w wersji piątej ma być rewolucja w zakresie wizualizacji treści dzięki rozbudowanemu mechanizmowi Canvas (ang. 'płótno').   Paradoksalnie, gdyż Canvas będzie obsługiwany z poziomu JavaScript'u, a nie z HTML-a. Canvas dostarczy gotowego API do modelowania i renderowania grafiki w przeglądarkach internetowych, mając z założenia wypełnić sporą przepaść między miernymi do tej pory możliwościami obecnych przeglądarek, a technologiami zewnętrznymi udostępnianymi w formie plug-in'ów, głównie Adobe Flash.

Niezmiernie ciekawie rysuje się wizja ewolucji technologicznej przeglądarek, tym bardziej, że wręcz prowokuje do pytania o to, która technologia w niedalekiej przyszłości dzierżyć będzie palmę pierwszeństwa. Nie trzeba wiele, by pobudzić zwolenników obu stron barykady do burzliwej debaty w tym kontekście. Jednak nie ma w tym nic złego, konstruktywna krytyka i mocne argumenty przydają się w każdej wojnie, a w tym przypadku zyskać może tylko użytkownik. Oby...

Argumenty, argumenty...

Pragnąc zaspokoić swą ciekawość, postanowiłem zapoznać się z nową technologią oraz z opiniami samych internautów, dającymi mi wstępny zarys placu boju i ogólny pogląd na sytuację. Co gorsza, im więcej wiem, tym bardziej jestem przekonany, że ani trochę nie będzie to batalia jednostronna, a zwycięzcy długo jeszcze nie poznamy.

W internecie znalazłem trochę informacji na ten temat. Jednymi z najczęściej punktowanych cech technologii Flash według użytkowników internetu mają być poniższe argumenty:

• Do stworzenia aplikacji dla Canvas/JS potrzeba mniej linii kodu, mniejszy jest także plik wynikowy. Skompresowana wersja nowego Network Grapha zajmuje 25 KB, podczas gdy plik flashowy zajmował 111 KB.
• Flash działa marnie na Linuksie i innych niedominujących systemach operacyjnych (mocno przytaczany argument Steve Jobs'a - niższa wydajność Flash'a na produktach Apple).
• Debugowanie i analizowanie kodu jest dla JavaScriptu/Canvas znacznie łatwiejsze - można wykorzystać do tego Firebuga, Web Inspectora, lub podobne narzędzia webdeweloperskie zintegrowane z przeglądarką.
• Aplikacji w Canvas/JavaScripcie nie trzeba kompilować.
• Aplikacje takie nie potrzebują focusu, aby przyjmować zdarzenia z klawiatury.
• Canvas/JavaScript zapewnia lepszą obsługę kursora.

Jakie głosy przemawiają za Flash'em?

• Konieczność ręcznego obsługiwania wycinania i przerysowywania. Canvas w HTML5 to po prostu niskopoziomowe API dla grafiki 2D, nie zawiera obiektów czy warstw, niczego ponad proste elementy do rysowania kształtów i wypisywania tekstów. Flash tymczasem oferuje wszelkiego rodzaju gotowe konstrukty, ułatwiające budowanie graficznych elementów aplikacji. w przyszłości na pewno pojawią się jednak odpowiednie frameworki, rozwiązujące tę słabość Canvas.
• Brak obsługi osadzonych fontów - we Flashu możemy osadzić fonty w aplikacji i nie przejmować się tym, jaki będzie efekt po stronie użytkownika. w wypadku aplikacji dla Canvas, w zależności od dostępnych fontów, efekt może być bardzo różny.
• Brak wbudowanych mechanizmów zawijania linii tekstu w kontenerach - we Flashu to trywialna kwestia. Oczywiście nie jest trudno napisać coś takiego w JavaScripcie, ale wbudowany w API mechanizm byłby lepszy.
• Brak możliwości renderowania na ekranie fragmentów HTML. Mechanizmy takie mają pojawić się w Canvas dopiero w przyszłości (przynajmniej wg autorów szkicu z W3C).
• Problemy z różnicami w implementacji obsługi Canvas w różnych przeglądarkach. Flash jest jeden dla wszystkich - natomiast implementacje standardów W3C są lepsze i gorsze, zależne od starań Mozilli, Google'a czy Apple.

Punktem, który śmiało może być pretekstem do ważkiej dyskusji na temat różnic na płaszczyźnie HTML5 - Flash, może być wspomniany charakter HTML5 jako technologii będącej w prostej linii niskopoziomowym graficznym API dla przeglądarek, co już z punktu widzenia tylko i wyłącznie tej kwestii nie pozwala HTML5 na porównywanie do Flash'a. Flash to środowisko programistyczne z szeroką gamą bibliotek, o jeszcze szerszych możliwościach, dających możliwość tworzenia bardzo zaawansowanej grafiki i animacji, podczas gdy HTML5 to wciąż udostępniony zbiór JavaScript'owych klas manipulujących graficznymi obiektami niskiego poziomu. Nie jest to jednak jakikolwiek argument "przeciw" dla powstającej webowej technologii, przecież  Flash także kiedyś raczkował, jednak nie powinniśmy popadać w przesadę i opisywać HTML5 jako technologię, która oferuje więcej niż Flash, jednocześnie dopiero wygrzebując się z becika.

Oczekiwania względem nowego HTML'a są naprawdę duże, co rodzi niepokojące myśli o ewentualny "wyścig zbrojeń" producentów przeglądarek. Canvas jest już obsługiwany (lepiej lub gorzej) przez najnowsze wersje kilku najpopularniejszych przeglądarek (oczywiście wyłączając Internet Explorer'a 8). Jednak, jako że technologia ciągle jeszcze jest mocno gorąca od interaktywnego pieca światowej pajęczyny, musimy uważać, by nie sparzyć się na różnych implementacjach Canvas'a w różnych przeglądarkach. Tego byśmy nie chcieli, nie ma bowiem nic gorszego dla developera, niż standard, który przestał być standardem.

Canvas korporacyjny

Spór sporem, ale co właściwie stoi na przeszkodzie, żeby obie technologie współistniały na rynku i wzajemnie się dopełniały? Wspomniany już Steve Jobs, głowa firmy Apple, jest główną twarzą strony "anty-Flash" i jednocześnie gorącym propagatorem HTML5 wspominanym w mediach. Rzecz rozchodzi się o to, że Apple nigdy nie promował technologii Flash w swoich iPod'ach,  iPhone'ach i ostatnio wypuszczonych na rynek iPad'ach.  Argumentuje to ślamazarnością technologii Adobe, jednocześnie promując HTML5 na najnowszych urządzeniach coraz prężniej zalewających rynek (urządzenia mobilne, tablety), tym samym zamykając sporą gałąź  dochodów firmie Adobe. Na humorystyczne riposty obu stron można natknąć się przeszukując internet pod  kątem sporu webowych technologii.  Zaniepokojony wizją, że gdy nie będzie Flash'a, nie zagra on już nigdy w jedną z Flash'owych gier z gatunku 'Tower Defence', internauta otrzymał taką odpowiedź innego internauty:

"Ależ nie potrzebujesz gier Flash. Możesz kupić sobie podobną gierkę w AppStore za jedyne 20 $. Tak naprawdę marzysz o tym, ale jeszcze o tym nie wiesz." - choć wypowiedź zdaje się być bardzo stronnicza, w pewnym sensie oddaje trochę zapędy Apple widziane chłodnym obiektywnym okiem obserwatora branży cyfrowych mediów i Internetu.

Założenia - bliższe i dalsze

W ferworze wymiany argumentów za i przeciw HTML5 oraz stawiania go jako głównego pretendenta do walki z Flash'em, a nawet odgórnie określania mianem zwycięzcy, warto uświadomić sobie kilka faktów, które dadzą jaśniejszy obraz niedalekiej przyszłości i obecności w niej przeglądarek nowej ery. w odniesieniu do bogatego wachlarza graficznych możliwości Flash'a, nowy HTML oferuje API graficznego płótna przeglądarki - aż i tylko. To nie środowisko WYSIWYG, to nie edytor udostępniający wizualne projektowanie aplikacji przy użyciu biblioteki gotowych elementów. Nie ma tu Timeline (timeline we Flash'u - zestawienie sekwencji pojedynczych klatek łączonych w animację). Argumenty przemawiające na korzyść HTML5 i jednocześnie przeciw Flash'owi - o łatwości debugowania aplikacji wprost z poziomu przeglądarki za pomocą narzędzi webdeveloperskich  oraz o braku konieczności kompilowania kodu w przypadku HTML5, mogą szybko obrócić się przeciwko swoim twórcom. Mianowicie co z ochroną kodu? Co z danymi, które bez kompilacji będą dostępne do podejrzenia i pobrania dla każdego? Jeśli zaś HTML5 doczeka się środowiska programistycznego oferującego kompilację skryptów i danych do jednego pliku (przypuśćmy JavaScript, z danymi w formacie JSON), to czym będzie różnić się wtedy od statystycznego pliku 'swf'? Pliki Flash'a można zdekompilować - owszem - ale nie zawsze jest to takie proste, jak się wydaje i nie zawsze zdekompilowany kod po ponownej kompilacji działa tak, jak w oryginale.

Co z odtwarzaniem video w HTML5? Już jest możliwe i można je przetestować w praktyce, choćby w serwisie YouTube. Co z tego, jeśli HTML5 - przynajmniej w pokazanych przykładach - nie wspiera buforowania streamowanych plików, co sprowadza się do pokazu slajdów na wolniejszych łączach.

Kwestii, na tle których możnaby obie technologie porównywać, jest sporo i, jak widać, sporo z tych kwestii, pozornie spójnych, musi być jeszcze dotartych, aby HTML5 traktować w kontekście analogii do Flasha. Powiedziałbym, że jest 'klasa bazowa', ale musi ona doczekać się przemyślanego opakowania w formie kompletnego narzędzia dla developerów. To świetna okazja dla HTML5, który ma szansę tym razem zrewolucjonizować pojęcie 'aplikacji internetowych', nie tyle wypierając Flasha, co przy pomyślnych wiatrach mocno zdegradować znaczenie aplikacji desktopowych na rzecz World Wide Web. Na tym polu nowa odsłona webowego języka skryptowego miałaby szansę konkurować nie tylko z Flashem, ale także w pełni niedocenianą przez twórców sieci i ciągle jeszcze młodą technologią Adobe AIR, ale to już temat na oddzielny artykuł.

Narodziny króla webowego 3D?

Gorąca, rozpalająca do czerwoności kwestia - trzeci wymiar w przeglądarce. HTML5 ma być nadzieją i zbawieniem w tej materii - krążą głosy w sieci, wspierane jednocześnie demem Quake2 odpalonym w przeglądarce korzystającej z HTML5 i Canvas. Kubłem zimnej wody będzie tutaj informacja o tym, że to nie zasługa HTML5, ani Canvas, a WebGL - będącego dopiero w fazie budowy silnika 3D dla JavaScript (oficjalne wypuszczenie WebGL planowane jest na połowę tego roku). Osobiście WebGL interesuje mnie znacznie bardziej niż całe HTML5 (i z pewnością przyjrzę się tej technologii w niedalekiej przyszłości), jednak nie jest z nim bezpośrednio powiązane, a jedynie korzysta z Canvas'a. Chwaląc HTML5 za demo Quake2 na przeglądarkę można równie dobrze pochwalić Flasha za demo Quake3 (które również można znaleźć w sieci) w technologii Adobe Shockwave. Mniej więcej tym jest WebGL przy HTML5, co Shockwave przy Flash'u, więc nie powinniśmy mylić ze sobą tych technologii. Jeśli już jesteśmy przy 3D, WebGL rysuje bardzo ciekawą perspektywę na przyszłość i może określić raz na bardzo długi czas standardy grafiki przestrzennej dla WWW, sprawiając że Flash developerzy odejdą od bibliotek Papervision 3D, Away 3D, czy Alternativa 3D na rzecz kodowania przestrzeni w JavaScript'cie. Nie zapominajmy jednak ani przez chwilę o odrębności WebGL - nie jest częścią HTML5, a jedynie samodzielną biblioteką trzeciego wymiaru korzystającą z Canvas'a.

Podsumowując

Mój wpis miał być obiektywny i myślę, że udało mi się ten cel zrealizować. Choć, po szybkim rzucie oka, mam wrażenie, że większość wspomnianych przeze mnie argumentów może przemawiać za technologią Flash, mam świadomość tego, że najbliższa przyszłość jest trudna do przewidzenia, a trendy technologiczne nie do końca wyznaczać będą odbiorcy owych technologii. Nadmienię tu jednocześnie, specjalnie pod kątem moich kolegów "po fachu" z pracy, że mocno kibicuję HTML5 i mam nadzieję, że szybko wkradnie się w nasze - developerów - łaski- od tego w końcu zależy, czy trafi pod strzechy odbiorców internetu. Potencjał jest duży. Gdyby całość ubrać w wygodne środowisko, dołożyć do tego dedykowany debugger i zamknąć w zgrabnych kompilowalnych paczkach, a dodatkowo zintegrować w pełni z grafiką 3D wspieraną sprzętowo przez GPU… Na początku sceptycznie, ale z biegiem czasu coraz bardziej wydaje mi się to możliwe, a wtedy… Już nie mogę się doczekać!