Smokescreen to nowy startup, który mylnie określany jest jako sposób na konwersję Flash do technologii, które wprowadza HTML5. Tak na prawdę, Smokescreen to plugin Flash napisany w JavaScript, który dodatkowo korzysta z technologii dostępnych w HTML5 np. tag ) jednak w większości korzysta on z dużo starszego rozwiązania - SVG.

Jak można się domyślić, powodem powstania pluginu Flash w wersji JS jest oczywiście brak wsparcia technologii Adobe na wielu platformach np. Apple iPad, które z kolei posiadają przeglądarki umożliwiające znośne wykonywanie kodu JS. Co prawda twórcom chodziło głównie o odtwarzanie reklam Flashowych na takich urządzeniach, co nie jest może najbardziej chwytliwym rozwiązaniem, ale jak widać udało się odpalić trochę bardziej skomplikowane flashe.

Jak dokładnie działa SmokeScreen? Jak już wspomniałem - nie jest to żaden konwerter, ale plugin, który powstał dzięki upublicznieniu specyfikacji. Plugin pozwala na uruchomienie aplikacji Flash wprost z pliku SWF i nie wymaga żadnej wcześniejszej modyfikacji. Niestety, jak to bywa z wersjami rozwojowymi (wersja 0.1.2 została opublikowana 27 maja 2010) bywa, plugin nie jest jeszcze w 100% kompatybilny i nie wszystkie Flashe udaje się w nim uruchomić.

Poniżej znajdziecie wideo-prezentację SmokeScreen na iPadzie:

Osobiście przyznam, że Smokescreen wydaje się ciekawym rozwiązaniem - ale chyba tylko dla posiadaczy produktów Apple i innych, nie posiadających oficjalnej wersji pluginu Flash. Należy pamiętać, że jest to implementacja w języku, który nie słynie z najlepszej wydajności - jednak może dzięki zastosowaniu JIT (WebKit zdaje się posiadać własny mechanizm kompilacji JS do kodu maszynowego) umożliwi on wyświetlanie wspomnianych reklam i mniej wymagających aplikacji Flash na urządzeniach mobilnych.

Aplikacja tworzona jest na zasadach Wolnego Oprogramowania i kod już niebawem powinien pojawić się na GitHub.com. Niecierpliwi mogą pobrać aktualną wersję prosto ze strony SmokeScreen.us

Przyszła uwaga - strona wyświetla się błędnie w przeglądarkach pod Linuxem i Maciem. Chodzi o najnowszego Firefox. Czemu? Nie wiem - walczyłem z tym już dłuższą chwilę, wydawało mi się, że się poprawiło (i u mnie i u znajomego było ok) jednak znalazł się ktoś, komu wyświetla się źle.

Przychodzi polecenie od klienta, mail przechodzi przez zarząd i trafia do mnie - poprawić. Trudno, trzeba zainstalować kolejnego Linuxa w VM i sprawdzić. Tylko właściwie czemu? Wg. ranking.pl użytkownicy Linux wszelkiej maści i Mac w sumie nie mają nawet 1/3 tego, co ma IE6, który przez wielu jest odrzucany jako produkt przestarzały i używany przez tak małą grupę użytkowników, że nie warto sobie nim zawracać głowy.

Co okazuje się być źródłem problemu? Ano to, że dane Ubuntu domyślnie zdaje się nie posiadać Tahomy, czyli jednej z popularniejszych w sieci czcionek, zaś alternatywna powoduje, że zastosowanie paddingu o takiej a nie innej wartości rozwala stronę...

Znajomy podrzucił mi właśnie link do kolejnej "ciekawostki" ujawnionej na Google I/O 2010 - mowa o Native Client. Na pierwszy rzut oka technologia może wydać się znajoma - jest to dodatek do przeglądarki pozwalający na uruchamianie kodu napisanego w C/C++ właśnie w przeglądarce. Czyżby Google na nowo odkrywało applety Javy i konkurowało z pluginem Flash, którego tak zawzięcie bronią w walce z Apple? Na to wygląda.

Native Client to technologia pozwalające za pomocą API i SDK integrować programy napisane w C++ z przeglądarką co pozwala nam na zarządzanie jej zasobami z naszych aplikacji - dodatkowo, pozwala ona na przenoszenie kodu z platformy na platformę bez obawy o kompatybilność naszego kodu z danym systemem - wystarczy, że będziemy trzymać się wytycznych narzuconych przez SDK i dla docelowego systemu operacyjnego wydana zostanie przeglądarka Google Chrome obsługująca te technologię.

Nie byłem przekonany do tego rozwiązania do czasu aż nie zobaczyłem tego filmiku (przeskoczcie sobie do mniej więcej 8-mej minuty). Pracownicy Google wraz z autorami Unity3D wykonali port ich silnika gier 3D wykorzystujący właśnie Native Client co pozwala na uruchamianie gier 3D prosto w przeglądarce. Nie jest to jakaś lipna, softwarowa implementacja 3D jak miało to miejsce w większości przypadków przy Flashu, ale normalna wykorzystująca nasz sprzęt aplikacja.

Wraz z tą technologią Google zaprezentowało coś co może nas przekonać do korzystania z jej dobrodziejstw - Chrome Web Store (niestety, zdaje się jeszcze być niedostępny publicznie) w którym możemy kupować aplikacje pracujące wewnątrz naszej przeglądarki. Aplikacje mogą być wykonane zarówno w technologii HTML + CSS + JavaScript, Flash czy właśnie w Native Client.

Wydaje mi się, że może być to ciekawy krok, szczególnie biorąc pod uwagę rozwijany przez Google Chrome OS który de-facto jest systemem operacyjnym opartym o przeglądarkę. Tyle, że w tej przeglądarce mamy już komercyjnej jakości gry 3D, programy do edycji grafiki - a to wszystko w sklepie internetowym, w którym nasze produkty mogą z dnia na dzień trafić do setek tysięcy odbiorców. Czy może to przełożyć się na korzyści finansowe znane już developerom korzystającym z Apple Store? Ja obstawiam, że tak.

Na odbywającej się właśnie konferencji Google I/O 2010 internetowy gigant zaprezentował swój nowy produkt - tytułowe Google Font API szybko okrzyknięte przez niektórych zbawieniem webdeveloperów, krokiem ku przyszłości czy "jednolinijkowym rozwiązaniem". Czy aby na pewno?

Na początek wypada wyjaśnić o co właściwie chodzi. Każdy, kto kiedykolwiek zajmował się na poważnie tworzeniem serwisów internetowych wie, że możliwość korzystania z różnorodnych dostępnych czcionek ograniczona jest tym, jakie czcionki posiada zainstalowany odwiedzający - jeżeli nie ma tej, którą wybraliśmy, wyświetli mu się alternatywna (zdefiniowana przez nas lub przez jego przeglądarkę). Oczywiście pojawiały się różne próby dodania obsługi czcionek w CSS - jednak jak to bywa z przeglądarkami, Microsoft wprowadził do IE swoje standardy, część przeglądarek zaczęła adaptować rozwiązanie zaproponowane dla CSS3, IE6 nie obsługiwał prawie nic .... Teraz, kiedy zbliża się czas w którym IE6 będziemy mogli porzucić a większość przeglądarek zdaje się już finalizuje obsługę font-face z CSS3 możemy zacząć rozważnie stosować te technikę.

Jak to dokładnie działa? W CSS możemy zdefiniować sobie nowe czcionki w oparciu o udostępnione przez nas pliki, np:

@font-face {
        font-family: Delicious;
        font-weight: bold;
        src: url('Delicious-Bold.otf');
}

Zadeklaruje nam nową czcionkę o nazwie "Delicious" i do jej wyświetlenia użyje pliku "Delicious-Bold.otf" dostępnego na naszym serwerze. Oczywiście, każdy z użytkowników musi pobrać te czcionkę co powoduje dwie rzeczy:

1. Do czasu pobrania czcionki tekst wyświetlany jest przy użyciu czcionki alternatywnej
2. Każdy użytkownik musi pobrać plik czcionki przez co wzrasta transfer nasz i odwiedzającego

I tutaj wchodzi Google - nowa usługa polega na udostępnianiu czcionek prosto z serwerów Google co pozwala nam zaoszczędzić na transferze, odwiedzający zaś pobierze czcionkę tylko raz - jeżeli przejdzie na inną stronę, która także używa danej czcionki i również korzysta z usługi Google nie musi pobierać jej ponownie.

I o ile jest to rozwiązanie korzystne na pierwszy rzut oka, o tyle nie jest ono w żaden sposób rewolucyjne - nie jest to żadne "end-all" rozwiązanie wprowadzające jakąś technologiczną nowość czy dodające funkcjonalność, której do tej pory przeglądarki nie miały. Nie sprawi to, że magicznie nowe czcionki pojawią się w IE6 - po prostu jest to rozwiązanie CSS3 wykorzystujące CDN (ang. content delivery network, sieć dostarczania treści - pozwala to na dostarczenie użytkownikowi materiałów z serwera który znajduje się "najbliżej" jego lokacji) Google.

I tu pojawia się problem dla mnie. Po pierwsze dodajemy kolejny supełek na linie łączącej nas z Google - jeżeli nagle panom znudzi się usługa i postanowią ją wyłączyć zostajemy na lodzie i mamy kilka stron do poprawienia. Czcionki dodawane do Google Font Directory udostępniane są na licencji open source, co daje nam pewność, że nie każą nam za nie nagle płacić, ale wybór (na razie) jest mizerny. No i pozostaje sam CDN - mam nadzieję, że będzie działać on dużo lepiej niż Google AJAX Libraries API który potrafi notorycznie wieszać się i wisieć na "Trwa pobieranie z google..." co w przypadku JS potrafi zawiesić działanie reszty strony.

Ktoś powie, że ten ostatni problem jest specyficzny dla JS i nie powinien powodować problemów w CSS - przecież czcionkę pobieramy raz. Czcionkę tak, plik CSS od Google nie - jeżeli serwer będzie odpowiadał wolno, przyjdzie nam czekać na załadowanie CSS by wskazał czcionkę, którą już mamy na dysku.

Podsumowując - cały szum wokół Google Font API zdaje się być zupełnie chybiony - cała "aplikacja" jest przecież tylko frontendem do Google Font Directory pozwalającym w 2 linijkach HTML i CSS zrobić to, co od dłuższego czasu możemy zrobić w 3-4 CSS...

aktualizacja: okazuje się, że byłem w błędzie i jak to wytkną mi trójkąt w komentarzach Google Fonts API radzi sobie nawet w IE6 (chociaż u mnie mało stabilnie, ale może to być wina nie natywnej wersji IE6 - IETester). Jeżeli żądanie czcionki wyjdzie z "nowej" przeglądarki - serwer Google odpowie nam wysyłając czcionkę w formacie TTF. Jeżeli zaś to samo żądanie, pod ten sam URI wyślemy z IE6 - serwer Google wyśle nam plik EOT - jest to format czcionek obsługiwanych przez IE od dłuższego czasu.

Biję się w pierś i przyznaje - jednak jest w tym rozwiązaniu coś interesującego :-)