[Ww.Web] SilverLight, SilverDark, Konkrety

Poniżej parę konkretnych uwag do SilverLighta (SL), aby poprzednie narzekanie na SL nie było gołosłowne. Nie są to wszystkie moje uwago do SL, ale wydaje mi się wystarczająca ilość aby uzasadnić mój punkt widzenia z poprzedniego postu.

1. Środowiska programisty/projektanta/tego-co-robi-SL-aplikację

Spróbowałem pracować z Blendem oraz VS 2008. Niestety, kontrolki z Toolkita nie pokazują się w designerze i w dodatku z jakiegoś magicznego powodu po uruchomieniu wyglądają dziwnie (niektóre elementy są powyciągane, a niektóre mają dobre rozmiary). Zrezygnowałem z Blenda i zacząłem używać VS2008. Ręczna praca z XAMLem oraz kodem "pode spodem" przyniosła efekty - na statycznych plikach z tekstem do wyświetlenia działało dobrze! Niestety próba udynamicznienia aplikacji spowodowała stratę około 2 godzin (jeden wieczór zmarnowany), ponieważ w wersji 1.1 Downloader uruchomiony lokalnie (nie przez serwer Web) nie pozwala "ściągnąć" plików leżących po sąsiedzku ze strona HTML aplikacji SL. Błąd wyświetlany jest baaardzo ogólny i nie wiadomo czy przypadkiem to początkujący SLowiec nie popełnił błędu. Informację o tym znalazłem na forum dyskusyjnym.

2. Debugowanie aplikacji

Chciałem mieć 3 projekty: w pierwszym logika konwersji, w drugim kontrolki związane z SL, a w trzecim prosta aplikacja w ASP.NET zajmująca się publikowaniem Package pod wirtualnymi adresami URL. Tak naprawdę projekt SL i ASP.NET powinny być razem, jako że występują w tym samym Web Site. Niestety nie udało mi się dodać projektu z kontrolkami Toolkita do aplikacji ASP.NET. Wyjściem okazało się dołączenie projektu Toolkita do projektu SL, ręczne włożenie projektu SL do katalogu z projektem ASP.NET i zmiany w pliku solution. Aby debugować jednocześnie ASP.NET i SL należy ustawić oba projekty jako startowe. Dostajemy przy starcie 2 przeglądarki - jedna od ASP.NET (localhost), a druga do SL (local file system) i musimy ręcznie przeklejać i koordynować obie przeglądarki.

3. Uboga podstawowa funkcjonalność

Jak pisałem w poprzednim poście, są tylko naprawdę podstawowe kontrolki. API SL pod .NET jest bardzo zubożone - brak przeładowań metod dla typowych operacji, wygląda jak jakiś wrapper na coś z zupełnie innej bajki. Taka klasa Downloader - koszmarne API, wszystko "lata" jako tekst. XamlReader - tylko metoda Load z parametrem string reprezentującym tekst do sparsowania - nie można przekazać strumienia danych. XamlReader zachowuje się dodatkowo nie przewidywalnie - ten sam tekst przekazany do metody Load czasami przetwarza się poprawnie a czasami zgłasza błąd (Wygląda jak by po przetworzeniu określonej ilości znaków? elementów? zgłaszał błąd - problem z wewnętrznym buforem?).

4. Brak kontrolki TextBox

To tak ważna kontrolka, że brak jej jest jakimś nieporozumieniem lub pomyłką. Resztę na ten temat pominę milczeniem.

5. Brak funkcjonalności layoutowania kontrolek

Pozycjonowanie absolutne, a layoutowanie ręczne w kodzie. W przypadku zegarka to może i zda egzamin jak ma się kilka elementów bez interakcji użytkownika. Ale zastanówcie się ile trzeba spędzić czasu aby zrobic Grida ze stylami, szablonami? Dyskwalifikacja produktu.

6. Brak bindowania danych

Ręczne "wpisywanie danych" w kontrolkę (TextBlock/Glyphs). Takie "tricki" można było robić już w HTMLu i PHP/ASP. Po co do tego wracać? Dyskwalifikacja produktu.

7. Możliwości SL, a WPF

Gdzieś wyczytałem (jak zwykle nie pamiętam gdzie), że SL daje programiście duże możliwości, ponieważ jeśli ktoś chce to może zaimplementować na nim funkcjonalność WPF, a z tego wniosek, że to jest technologia porównywalna z WPF. Zgodzę się że technicznie jest możliwe przenieść sporą część funkcjonalności (nie napisze całość jako że nie znam tak dokładnie WPF), ale jakim kosztem czasowym?

Czasy gdy kilka lat temu walczyło się z materią, pisząc w HTML/JavaScript elementy z "dużych, okienkowych aplikacji" dla mnie przynajmniej już minęły. Nie cieszy mnie już sama możliwość zrobienia Czegoś bez względu na koszt czasowy. Odnosząc to do praktycznego zastosowania, jak widzę sposoby pracy i efekty SL:

a. SL jest przeznaczony dla aplikacji bazujących na HTML i przeglądarce. Aktualnie jest sens użycia tego jeśli klient zażyczył sobie JAWNIE aplikacji "webowej" z wodotryskami. Tak naprawdę jeśli klient chce intranetową, "bogatą" (bogatą w sensie UX/UI) aplikację są inne technologie zapewniające to, bez potrzeby debugowania JavaScript i udawania ze HTML jest prawie jak aplikacja okienkowa. Nie będę rozpisywał się o tym "prawie".

b. Jeśli już trzeba użyć HTML, to wtedy SL można użyć do prostych rzeczy, jak "flashowe" menu, ładne wykresy z odrobiną interakcji.

c. SL używamy do rzeczy prostych, ponieważ napisanie złożonej aplikacji (nawet formatowy edytor danych) wymaga naprawdę duuużo roboczo-godzin lub zasobów pieniężnych (na jedno wychodzi) . A to ze względu na potrzebę napisania tych kontrolek od początku, bądź kupna od jakiejś firmy. Z pobieżnego przeglądu dostępnych kontrolek jeszcze im daleko z funkcjonalnością choćby do podstawowych kontrolek WPFa.

Opublikowane 24 stycznia 08 02:30 przez Wojciech Gebczyk

Komentarze:

# michalz said on stycznia 24, 2008 20:02:

Cóż, mogę zgodzić się z większością uwag, choć nie powstrzymuje to mojego optymizmu na przyszłość. Być może błędem było udostępnienie wersji alfa, która służyć miała głównie jako platforma do uruchomienia (efektownych przyznasz) dem. Patrząc choćby na zmiany w API pomiędzy 1.1 a 2.0, zdecydowanie odradzałbym w tej chwili naukę - po prostu szkoda czasu. Mocno trzymam kciuki za najbliższą (nareszcie otwartą) betę 2.0.

PS. Oczywiście jestem stronniczy ;)

# Tomasz said on stycznia 24, 2008 21:57:

Jedna uwaga - z tego postu wynika jedno - oczekiwania programistów są baardzo wysokie. Kiedyś debugger był luksusem - teraz - jak nie ma kontrolek, designera itp - to programista nic nie może zrobić. A problemem jest "musimy ręcznie przeklejać i koordynować obie przeglądarki". Nie ma kontrolek textbox to się nie da napisać UI itp. W sumie smutne... Ale  - ewolucja

# windywinter said on stycznia 24, 2008 23:09:

Tomasz: Wiesz, chyba odpowiedz mozna sprowadzic do stwierdzenia: "Ja poprostu szanuje swoj czas pracy". Chodzi o to ze literalnie zgodze sie z Twoimi twierdzeniami. W Silverlight DA SIE zrobic to co chcesz. DA sie pracowac bez debuggera i kontrolek (podejscie echo/alert/print z PHP/JavaScript sprawdzalo sie w mojej mlodosci, lecz niestaty nei jest tak produktywne jak normalny debugger). To nie ma dyskusji bo to fakt. Poprostu w robieniu aplikacji (nawet RIA) SL wymaga poswiecenia za duzo roboczogodzin.

Jesli znajdzie sie pracodawca co zasponsoruje takie R&D, to moge siedziec i pisac - tyle ze prawdopodobnie nie przelozy sie to na zysk, na cel pisania oprogramowania ktorym jest dostarczanie rozwiazan spelniajacych wymagania jak najszybciej i najtaniej.

Wezmy OutlookExpress-like aplikacje i zastanowmy sie jak szybciej ja wykonamy: SilverLight/HTTP/HTML czy WPF/ClickOnce/XBAP. NAWET w przypadku aplikacji internetowej na polskie warunki i tak 99% systemow to Win, a XBAP pojdzie na FF rowniez.

Jak juz pisalem, wyroslem z hackowania HTML/JavaScript i zawrywania nocek tylko po to ze pierwszym i jedynym kryteruim polskich firm softwarowych jest koszt produkcji i szkoda paru setek dolarow na na przyklad kontrolki :-) Co jest wiecej warte zestaw kontrolek za 400$ czy 3-6 miesiecy pracy 2-3 programistow ktory to napisza?

Zgodze sie nawet ze SilverLight jest swirtna technologia geekowska, gdzie mozna wykazac sie na tym swoistym Dzikim Zachodzie, ale pozostaje pytanie: Po co...? A ja wolalbym spedzic stracone 2-4 godziny na debugowanie za pomoca pisania do TextBlock, z moim synkiem :-)

Pozdrawiam i milego hackowania.

Komentarze anonimowe wyłączone

About Wojciech Gebczyk

Code Sculptor.