Silverlight 2 - Flash, ale nie flash

Silverlight 2 nie spowoduje internetowej rewolucji. Z punktu widzenia zwykłego człowieka nowy produkt Microsoftu pozostanie niewidzialny, bo jest pomyślany jako solidny, ale konserwatywny odpowiednik Flasha, poszerzający środowisko .NET i stanowiący logiczną część oferty Microsoftu dla deweloperów. I tylko tyle.

Na takiej samej zasadzie, na jakiej Flash odtwarza animacje zapisane w formacie SWF, wtyczka Silverlight zainstalowana w przeglądarce potrafi odtwarzać zagnieżdżone na stronie pliki XAP. Teoretycznie jest dostępna od ponad roku w wersji 1.0, ale dopiero wersja 2.0 (tworzona zresztą równolegle z poprzednią i do niedawna znana jako 1.1) stanowi poważną platformę, która może w znaczący sposób zmienić układ sił w świecie multimediów.

Maszyna wirtualna gwarantuje bezpieczeństwo

Użycie maszyny wirtualnej odróżnia Silverlighta od osadzanych w witrynach komponentów COM (znanych także jako ActiveX). Kontrolki są dojrzałą technologią, znacznie potężniejszą i od niego, i od Flasha - a nawet od eksperymentalnej wtyczki Google Native Client. Dają nieograniczoną możliwość łączenia kodu strony z programami uruchomionymi w środowisku Windows (można by na przykład za ich pomocą łatwo utworzyć odpowiednik Google Spreadsheets, w którym interfejs użytkownika widoczny w przeglądarce byłby tworzony w prawdziwym Excelu).

Technikalia

Platforma Silverlight składa się z uproszczonego środowiska .NET: maszyny CoreCLR, okrojonej wersji podstawowej biblioteki BCL (Base Class Library), platformy graficznej WPF oraz kodeków niezbędnych do odtwarzania multimediów w formatach VC-1 (HD), WMV, WMA i MP3. Wszystko to, w postaci ważącej prawie pięć mega wtyczki (jak zapewnia Microsoft, "ściąga się w parę sekund") w wersjach do wszystkich popularnych przeglądarek Windows i Mac OS X, można ściągnąć z oficjalnej strony.

Silverlight, podobnie jak jego bezpośredni konkurenci na rynku RIA (Rich Internet Application - dosłownie: bogata aplikacja internetowa), czyli technologii Flash/Flex i JavaFX, realizuje trzy tendencje programowania do Internetu: uruchamianie kodu w maszynie wirtualnej, użycie grafu sceny (scene graph) jako podstawowej metody definiowania grafiki oraz operowanie abstrakcją wiązania danych (data binding) przy budowaniu interfejsu użytkownika .

Potęga ActiveX jest jednak przeszkodą w praktycznym stosowaniu tej technologii (poza aplikacjami przeznaczonymi do intranetów). Po pierwsze, wchodząc na stronę internetową, nie życzysz sobie, aby jej autor mógł uruchomić dowolny programy na twoim komputerze. Po drugie, jeżeli działanie witryny zależy od kodu przechowywanego na twoim komputerze, tracisz największe zalety aplikacji WWW: niezależność od platformy oraz brak potrzeby instalacji dodatkowego oprogramowania. Zwycięstwo Flasha nad apletami Javy i kontrolkami ActiveX pokazało, że ograniczenia platformy mogą paradoksalnie być zaletami, zwłaszcza gdy upraszczają instalację i administrowanie środowiskiem.

Maszyna, na której opiera się Silverlight, jest okrojoną wersją platformy CLR używanej przez .NET. Usunięto z niej elementy wymagające głębokiej integracji z systemem operacyjnym, a zatem mogące powodować luki w zabezpieczeniach. Silverlight nie ma więc bezpośredniego dostępu do lokalnych komponentów COM i niskopoziomowych bibliotek systemowych (używanych w .NET wywołań P/Invoke). Tworząc aplikacje za pomocą tej platformy, programista musi się ograniczyć do stosowania tych funkcji systemowych, które ona oferuje. W praktyce oznacza to brak dostępu do dysku użytkownika (z wyjątkiem kilku prostych scenariuszy), drukarki, skanera czy lokalnej bazy danych (jak w Adobe Air lub podpisanym cyfrowo aplecie). Nie ma też możliwości zainstalowania określonego kodu (np. biblioteki) na stałe na komputerze, co może utrudniać tworzenie większych, modularnych aplikacji.

Dodatkowo, podobnie jak Flash i AJAX, Silverlight jest ograniczony przez Same Origin Policy: aplikacje nie mogą wykorzystywać Sieci do połączeń z innym serwerem niż ten, z którego zostały pobrane. Oznacza to zmniejszenie funkcjonalności, ale daje użytkownikowi gwarancję, że nikt nie użyje jego komputera jako internetowej stacji do wysyłania spamu lub przeprowadzania ataku DOS.

Ograniczenia platformy są złagodzone podobnie, jak we Flashu. Po pierwsze, Silverlight akceptuje pliki crossdomain.xml (Microsoft uznał w ten sposób standard wprowadzony przez Adobe na potrzeby Flasha), które w sposób kontrolowany przez właścicieli serwisów pozwalają obchodzić ograniczenia SOP. Po drugie, aplikacje Silverlight mogą ściągać z sieci dodatkowy kod (dotnetowe pliki DLL), wskazując jego adres. Jeżeli kilka programów spróbuje skorzystać z biblioteki umieszczonej w sieci pod takim samym adresem URL, można liczyć na to, że plik zostanie ściągnięty tylko za pierwszym razem, a potem będzie wczytywany z pamięci podręcznej przeglądarki.

Wydaje się, że Microsoft nie jest zainteresowany poszerzeniem tych możliwości, na przykład przez utworzenie silverlightowego odpowiednika repozytorium GAC lub specjalnego rodzaju autoryzowanych aplikacji (podobnych do podpisanych apletów). Z punktu widzenia projektantów Silverlighta, aplikacje bardziej skomplikowane niż dzisiejsze witryny we Flashu powinny być realizowane z pomocą zaawansowanych technologii Microsoftu, na przykład no-touch deployment lub z użyciem kontrolek .NET hostowanych w przeglądarce.

Sztaluga i scena

W czasach, gdy wraz z systemem Windows powstała biblioteka GDI, do tworzenia grafiki służyły operacje podobne do `znanych z programu Paint: rysowanie podstawowych kształtów pędzlami różnej grubości i koloru, kopiowanie prostokątnych fragmentów grafiki z maską lub bez, wstawianie tekstu wybraną czcionką. Program potrafi wykonać serię graficznych operacji, ale nie może manipulować obiektami już nakreślonymi. Na przykład zmiana koloru narysowanego prostokąta jest związana z koniecznością narysowania jeszcze jednego prostokąta, w tym samym miejscu, ale w nowym kolorze. Pozornie proste operacje, takie jak zmiana grubej linii na cienką, okazują się skomplikowanymi przedsięwzięciami, wymagającymi najczęściej przerysowania części obrazka.

Przedstawiony powyżej sposób korzystania z grafiki jest efektywny i doskonale się skaluje. Niezależnie od tego, jak jest skomplikowana, obraz zajmuje tyle samo miejsca w pamięci i wyświetla się tak samo sprawnie. Wykorzystują go niskopoziomowe biblioteki większości tradycyjnych systemów graficznych, w rodzaju microsoftowego GDI+ lub sunowego AWT. Pośrednio myślenie o obrazie w kategoriach serii wykonywanych operacji jest częścią architektury Windows Forms i Swing.

Silverlight wykorzystuje nowocześniejszy model obsługi grafiki, implementowany przez uproszczoną wersję biblioteki Windows Presentation Foundation, notabene zapowiadanej przez Microsoft jako część dotnetowego przełomu jeszcze na konferencji PDC w 2003 roku (pod nazwą Avalon). WPF działa analogicznie do standardów PDF i SVG, a także do rozwiązań użytych w filmach flashowych, systemie Mac OS X, iPhonach (biblioteka Quartz) oraz na platformie JavaFX. We wszystkich tych środowiskach grafiki nie tworzy się, przeprowadzając serię operacji na pojedynczym obiekcie reprezentującym kartkę.

Obraz powstaje przez tworzenie obiektów składowych (obrazków, napisów, filmów) i komponowanie ich w całość. Obraz nie jest traktowany jako dwuwymiarowa tablica pikseli, lecz przetwarza się go jako listę (lub drzewo) elementów graficznych i ich przekształceń. Takie podejście wymaga większych zasobów sprzętowych - ale dla programisty jest to ułatwienie, które pozwala na szybkie tworzenie animacji i efektów znanych z najnowocześniejszych interfejsów graficznych: płynnego powiększania grafiki, obrotów, rozmycia itp. Przetwarzając grafikę w starszych bibliotekach, używa się metafory płótna (canvas), natomiast w nowszych - metafory sceny. Oprócz procedury tworzenia efektownych interfejsów graficznych wysokopoziomowe biblioteki graficzne upraszczają także optymalizację silnika i wykorzystanie sprzętowej akceleracji grafiki (choć na razie Silverlight pozostawia wiele do życzenia w tym zakresie).

Obiektowy model sceny stosowany przez WPF znajduje naturalną reprezentację w języku XAML, będącym rodzajem XML-u, łatwym do opanowania przez każdego, kto zna HTML. Z punktu widzenia grafika XAML to HTML, tyle że pozbawiony archaicznych naleciałości i błędów projektowych, opracowany z myślą o multimediach.

Użycie odrębnego pliku XAML-u pozwala rozdzielić role grafika i programisty, tak jak podczas tworzenia klasycznych aplikacji WWW. Mówi się, że podobną możliwość daje Flash z językiem MXML, ale należy pamiętać, że nie jest on obsługiwany przez zwykłego Flasha, a jedynie przez kompilator Fleksa, będący osobnym produktem. MXML nie służy też raczej do opisu grafiki, tylko do rozmieszczenia kontrolek Fleksa i deklaratywnego związania ich ze źródłami danych. XAML przypomina raczej SVG - różni się od niego ścisłą integracją z technologiami Microsoftu (która objawia się m.in. w konwencjach nazewniczych i dokładnym odzwierciedleniu możliwości platformy WPF).

RIA: komponenty biznesowego GUI i wiązanie danych

Gdyby Flash pozostawał narzędziem do tworzenia gier (w tym najpopularniejszej w portalach: zauważ i traf uciekający przycisk, aby zamknąć reklamę), Microsoft prawdopodobnie nie próbowałby z nim konkurować. Jednak dwa lata temu Adobe zaczęło konsekwentnie rozwijać i promować nowatorską platformę Flex, przejętą od firmy Macromedia razem z Flashem.

Pierwotnym zastosowaniem Fleksa (wtedy w wersji 1) było tworzenie interfejsów użytkownika do aplikacji pisanych w Javie, a zgodnych ze standardem J2EE. Do dziś część oprzyrządowania platformy Flex stanowią serwerowe komponenty, pozwalające na łatwą serializację obiektów utworzonych w Javie i przesłanie ich do Flasha wydajnym, binarnym protokołem.

Flex - rzeczywisty konkurent Silverlighta

Flex dostarczył programistom J2EE wszystkich kontrolek niezbędnych do tworzenia korporacyjnych aplikacji, których brakowało formularzom HTML. Znalazły się wśród nich: rozwijana listy typu combo, kalendarz, tabela umożliwiająca sortowanie i edycję danych, kontrolka do przeglądania danych hierarchicznych i wiele podobnych. Oprócz elementów GUI Flex zawierał doskonale dopracowaną technikę deklaratywnego wiązania interfejsu użytkownika z danymi.

Operacje, które w standardowej Javie wymagały setek wierszy kodu, we Fleksie były deklarowane kilkoma atrybutami w pliku MXML.

Dzięki Fleksowi tworzenie i publikowanie na stronach WWW interfejsów bardzo zbliżonych do aplikacji biurkowych stało się łatwe i szybkie. Flash pozwolił na ominięcie problemu bezstanowości protokołu HTTP w sposób znacznie bardziej elegancki niż metody stosowane w hateemelowych kontrolkach ASP.NET z jednej, a JavaServer Faces z drugiej strony.

Jednocześnie strony stworzone z Fleksem wyświetlały się identycznie i funkcjonowały bez zarzutu na wszystkich popularnych przeglądarkach i systemach operacyjnych. Flex rozwiązał istotne problemy programistów aplikacji intranetowych i zyskał wielką popularność.

Wydaje się, że głównym polem, na którym Silverlight ma konkurować z Flashem, są właśnie zastosowania typowe dla Fleksa: tworzenie aplikacji WWW o bogatym interfejsie użytkownika, złożonym ze standardowych elementów formularzy, które ściągają informacje z jednego lub wielu serwisów.

W odróżnieniu od Adobe, dla którego Flex stanowi osobny produkt, Microsoft uczynił kontrolki i wiązanie danych istotną częścią drugiej edycji swojej platformy. Standardowe kontrolki Silverlighta prezentują się dość ładnie (wyraźnie widać, że Flex był dla Microsoftu źródłem graficznej inspiracji). Trochę gorzej jest z wiązaniem danych, akceptowalnym w WPF, ale wyraźnie gorszym od tego, co oferują konkurenci: Flex i JavaFX. Wiązanie danych wyraźnie nie jest organiczną częścią platformy, robi wrażenie czegoś doczepionego w pośpiechu.

W stosunku do wiązania danych w WPF słyszy się trzy zarzuty. Pierwszym jest przemieszanie warstwy danych i warstwy interfejsu graficznego: w Silverlighcie nie łatwo zmienić interfejs, pozostawiając sam model danych, ponieważ muszą one być ściśle ze sobą powiązane (funkcjonuje mechanizm kontekstów wiązania). Drugi zarzut dotyczy niemożności dowiązywania danych do dowolnych elementów, a jedynie do właściwości przewidzianych przez twórców platformy. Sprawa trzecia to specyfika implementacji własności, która wymaga od programisty nieustającego, nieeleganckiego i podatnego na błędy rzutowania z typu DependencyProperty na właściwe typy docelowe - wielu osobom to się nie podoba.

Deep Zoom

Jedyną ciekawą i nowatorską techniką zastosowaną w Silverlighcie, którą może zauważyć i docenić zwykły użytkownik Sieci, jest Deep Zoom. Tradycyjny sposób umieszczania grafiki w wysokiej rozdzielczości na stronach WWW (na przykład zdjęć, schematów, skanów dokumentów) polega na tworzeniu miniaturek, dzięki czemu widz może szybko i bez zbytniego obciążania łącza zorientować się w zawartości galerii.

Deep Zoom zaciera granicę między miniaturą a pełną wersją zdjęcia. Pozwala na oglądanie grafiki o bardzo dużej rozdzielczości (nawet dziesiątków tysięcy punktów na dziesiątki tysięcy punktów), podobnie jak w Google Maps: można przesuwać obraz myszą, a obracając jej kółkiem, zbliżać się płynnie do wybranych fragmentów grafiki lub oddalać od nich, uzyskując ogólne lub szczegółowe ujęcie. Powiększone fragmenty obrazu są wczytywane dynamicznie, podczas oglądania, więc czas oczekiwania na pojawienie się obrazka nie jest dłuższy od czasu wczytania standardowych miniaturek. Jedynym widocznym ograniczeniem Deep Zoom jest to, że po gwałtownym przybliżeniu jakiegoś fragmentu grafiki lub przeniesieniu kamery z jednego końca powiększonego zdjęcia na drugi obraz pozostaje nieostry aż do ściągnięcia bardziej szczegółowych danych (czas zależy od przepustowości łącza).

Technologia Deep Zoom nie wymaga żadnego specjalnego serwerowego zaplecza. Sekretem jest szczególne przygotowanie grafiki: podzielenie jej na wiele drobnych plików, żeby klient nie musiał ściągać jednego wielkiego bloku, ale mógł pobierać obraz po kawałku, w zależności od tego, który fragment i w jakim powiększeniu znajduje się na ekranie.

Aby wyświetlić obraz z użyciem Deep Zooma, trzeba go najpierw przeskalować i pociąć na kwadratowe obrazki o boku 255 pikseli, umieszczone w folderach odpowiadających kolejnym zbliżeniom. Każde z nich przedstawia grafikę w czterokrotnie wyższej rozdzielczości, więc pierwszy folder zawiera pojedynczy obrazek 255 na 255 pikseli, drugi - cztery takie obrazki, następny - 16, jeszcze kolejny - 64. Dodatkowo każdy obrazek musi mieć nazwę odpowiadającą jego pozycji w pociętej całości, na przykład 13_23.png to trzynasty obrazek w dwudziestej trzeciej kolumnie. Tak przygotowany zestaw nosi trafną nazwę piramidy obrazu i towarzyszy mu plik XML w specjalnym formacie, mogący zawierać dodatkowe informacje (na przykład łączyć kilka piramid obrazu tak, aby niektóre miejsca pierwszej grafiki pozwalały na znacznie głębszy najazd niż inne).

Jak widać z opisu, w technologii Deep Zoom nie ma niczego magicznego - wielu programistów mogłoby się pokusić o samodzielne napisanie programu o podobnej funkcji na każdej innej platformie. Natomiast na korzyść Deep Zooma przemawia doskonały, bardzo wygodny, płynny interfejs oraz dostarczone przez Microsoft bezpłatne narzędzie Deep Zoom Composer. Utworzenie za jego pomocą odpowiedniej piramidy obrazu staje się tak łatwe, jak korzystanie z Picasy. Można się spodziewać, że format archiwum Deep Zoom stanie się standardem dla plików w dużej rozdzielczości, a komponenty potrafiące je wyświetlać pojawią się także w innych technologiach.

Na razie Deep Zoom służy głównie do tworzenia efektownych galerii lub internetowych zabawek (takich jak Deep Zoom Obama: www.deepzoomobama.com). Natomiast można sobie wyobrazić, że w niedalekiej przyszłości wszystkie obrazki będą osadzane na stronach z użyciem tej lub podobnej technologii. Zwiększyłoby to wydajność przeglądarek mobilnych (które mogłyby pobierać dane w najniższej dostępnej rozdzielczości), a także ułatwiło umieszczanie w sieci wykresów, schematów i map, nietracących jakości podczas drukowania lub powiększania strony.

Silverlight, języki dynamiczne i niespełnione obietnice

Jednym z zapowiadanych atutów Silverlighta miała być doskonała współpraca z językami dynamicznymi. I rzeczywiście, w skład platformy weszła biblioteka DLR, czyli Dynamic Language Runtime - zestaw funkcji ułatwiających i standaryzujących implementację języków z dynamicznym typowaniem. Natomiast całe wydarzenie wśród fanów języków skryptowych stało się raczej źródłem zawodu niż radości.

Po pierwsze, część programistów miała nadzieję na dołączenie do Silverlighta nie tylko DLR, ale i samych interpreterów Pythona i Ruby. Ich brak w standardzie powoduje, że spore pliki DLL muszą być dołączane do każdej silverlightowej aplikacji napisanej w jednym ze skryptowych języków. W połączeniu ze wspominanym już brakiem możliwości instalacji bibliotek na stałe po stronie przeglądarki, stanowi to realną przeszkodę we wdrażaniu tej platformy. Po drugie, programiści języków dynamicznych cenią sobie możliwość modyfikowania programu w locie, na serwerze, bez dodatkowych etapów, takich jak kompilacja i pakowanie kodu.

Silverlight 1.1 alfa (który rozwinął się w dzisiejszy Silverlightem 2) pozwalał na uruchamianie w przeglądarce programów pobieranych z serwera w postaci zwykłych plików tekstowych, jak w wypadku zwykłego JavaScriptu. Ta opcja była przez Microsoft przeciwstawiana czasochłonnej procedurze kompilacji i linkowania, wymaganej przez narzędzia Adobe. Niestety, z powodów technicznych (bardzo zresztą ciekawych) zrezygnowanoz niej: aplikacje w językach dynamicznych muszą być pakowane w pliki .xap, tak samo jak wszystkie inne. I nawet prostota tego procesu (plik .xap ma identyczną strukturę, jak .air Adobe AIR czy .jar Javy, zatem jest zwykłym archiwum ZIP, zawierającym skompilowany kod oraz niezbędne deskryptory) nie zmienia faktu, że Silverlight nie pozwala programistom Ruby i Pythona wykorzystać całego potencjału ich ulubionych języków.

Krajobraz przed bitwą

Interesy Microsoftu, Adobe i Suna - czyli firm, które wprowadziły na rynek platformy Silverlight, Flash/Flex i Java/JavaFX - są rozbieżne. W wielkiej bitwie o RIA każda ze stron będzie się starała osiągnąć inne cele.

Adobe jest monopolistą w świecie grafiki komputerowej, Photoshop - jedynym liczącym się programem do obróbki grafiki rastrowej, a narzędzia z serii Flash - jedynymi branymi pod uwagę, gdy trzeba zrobić bardzo bogatą graficznie witrynę, na przykład oficjalną stronę wysokobudżetowego filmu.

Dlatego celem Adobe jest wykorzystanie Flasha i Fleksa do zmiany statusu grafików i projektantów. Chodzi o zdobycie dla nich tej części rynku, która dotąd była zarezerwowana dla zaawansowanych programistów. Pięć lat temu utworzenie GUI do wewnętrznego systemu korporacyjnego, na przykład banku, wymagałoby zatrudnienia wysoko płatnych twórców posługujących się Javą, znających się na bibliotece Swing. Flex sprawił, że tę samą pracę wykona - i to lepiej! - średnio wykwalifikowany i znacznie tańszy deweloper aplikacji internetowych, oczywiście z pomocą komercyjnych narzędzi Adobe.

W scenariuszu Adobe typowi programiści zostają zepchnięci w stronę serwera, stając się kimś w rodzaju nowoczesnych hydraulików: niezbędnych, ale niewidocznych. Natomiast miejsce w świetle reflektorów zajmują wizjonerscy projektanci-programiści, korzystający z uproszczonych platform programistycznych w rodzaju Adobe AIR.

Sun jest na razie wielkim przegranym segmentu RIA. Aplety, które do dziś stanowią najbardziej zaawansowaną technologię do tworzenia "bogatych aplikacji internetowych", wyprzedziły swoje czasy i pozostawiły fatalne wspomnienia. Upłynie dużo czasu, zanim fakty dotrą do świadomości ogółu - w tej chwili nawet samym programującym w Javie trudno przyjąć do wiadomości, że animacje tworzone w tym języku są bardziej wydajne niż flashowe, natomiast objętość przeciętnego apletu i wymagania sprzętowe JVM, które w latach dziewięćdziesiątych wydawały się olbrzymie, teraz robią przeciwne wrażenie.

Sun stracił dużo korporacyjnego rynku aplikacji WWW na korzyść .NET i nie może patrzeć obojętnie, jak Flash (w wersji lite) i Silverlight wdzierają się do jego bastionu, czyli telefonów komórkowych. W interesie twórców Javy jest zachowanie dominującej pozycji na rynku urządzeń wbudowanych, a jednocześnie powstrzymanie odchodzeniu programistów od Javy, która od dłuższego czasu przeżywa kryzys wieku średniego: choć ciągle sprawna i dobrze usytuowana, straciła już opinię młodej i atrakcyjnej.

Microsoft próbuje utrzymać kontrolę nad całym procesem tworzenia i używania oprogramowania, począwszy od projektanta poprzez administratora, architekta i programistę aż do użytkownika końcowego. Dzięki Silverlightowi Visual Studio może zachować swój status narzędzia absolutnego, spełniającego każdą potrzebę użytkownika korporacyjnego. Jednocześnie Silverlight poszerza strefę wpływów języka C i platformy WPF. Jego popularność powinna spowodować wzrost liczby programistów znających .NET, chętnych do użycia powiązanych technologii: serwisów Azure, serwerów Microsoft SQL Server i Internet Information Services.

Dominacja Microsoftu na rynku oprogramowania do biznesu pozostaje niezagrożona, ale właśnie wielkość i rozmaitość oferty jest dla tej firmy niebezpieczna: chcąc nie chcąc, konkuruje sam z sobą i musi sztucznie ograniczać niektóre swoje technologie. Z tego powodu trudno uwierzyć, że Silverlight będzie się rozwijać choć trochę szybciej niż to podyktuje tempo ucieczki Flasha. Microsoft mógłby z łatwością nadać wyścigowi własną prędkość i rozwinąć Silverlighta w doskonalszą wersję Adobe Air, ale ostatnią rzeczą, która opłaca się ludziom Ballmera, jest wieloplatformowe środowisko uniezależniające klientów od systemu operacyjnego.

Dla kogo?

Zatem kogo zainteresuje Silverlight? Raczej nie użytkowników końcowych, którym nie dostarczy niczego więcej niż Flash. Wtyczka będzie zapewne powszechnie instalowana (można założyć, że jej popularność dorówna popularności IE7), ale nikogo nie zainteresuje stojąca za animacjami technologia. Silverlight nie przyciągnie też dotychczasowych flashowców ani grafików preferujących standardowy interfejs narzędzi Adobe. W świecie Javy, poza szczególnymi wypadkami, użycie Silverlighta byłoby raczej niewyobrażalne: technologie Microsoftu są postrzegane jako wrogie, a co najmniej konkurencyjne, a powszechnie stosowany jest Flex (JavaFX to jeszcze inna historia). Natomiast Silverlight zostanie na pewno wykorzystany przez wszystkich programujących dotychczas w VB.NET i C, którym pozwoli osiągnąć modne, flashopodobne efekty bez opuszczania komfortowego Visual Studio i przy użyciu znanych im języków, a nawet klas i bibliotek.

Jedno jest pewne: bliski jest koniec wojen przeglądarkowych. Lada moment rozpocznie się era wojen wtyczkowych.


Zobacz również