Client-side o muerte

16
sty/10
26

Dzisiaj chciałbym zaryzykować parę kontrowersyjnych stwierdzeń n.t. budowania aplikacji internetowych. Pamiętacie mój poprzedni wpis o pluginizowaniu aplikacji PHP? Po jego napisaniu uznałem, że stworzę malutki framework korzystający z dobrodziejstw idei stojących za HMVC. Tak dla przykładu i dla własnej chorej rozrywki. Mam aktualnie dużo pracy, a co za tym idzie mój umysł pracuje na wystarczająco wysokich obrotach, by poradzić sobie w ekspresowym tempie i wolnym czasie rozwiązać problemy dotyczące architektur oprogramowania. Na tyle szybkim tempie, by nie zamęczyć się dodatkowo swym hobby i wypuścić kilka ciekawych wpisów. Przez ostatnie tygodnie powstawały szkice, klasy i interfejsy napisane w ulubionym PHP. Powstawały dopóki nie przystanąłem na chwilę i nie spojrzałem na ostatnie lata ewolucji aplikacji internetowych, dystansując się do swojego doświadczenia. I wiecie co? Patrzyłem na web-developing, który musi zostać zduszony w postaci w której utkwił. Musimy zrobić krok do przodu. Client-side albo śmierć.

Tworzenie w sieci w ostatnich latach rozgałęziło się w 3 modele wykonywania internetowych produktów:

  • Główna gałąź, czyli standardowe witryny generowane przez języki server-side i serwowane w HTML.
  • Bogate aplikacje wykonane na platformach RIA, które zapoczątkował Flash w momencie wprowadzenia ActionScript (rok 2000).
  • Bogate aplikacje bazujące na podstawowych narzędziach webowych, tj. HTML i JavaScript.

Ewolucja to idiotka, kręcimy się w kółko potykając o własne nogi. Rewolucyjne platformy do tworzenia aplikacji RIA wyrastały od 2004 roku jak grzyby po deszczu i tam gdzie technologie webowe wymiękały zachęcano nas do instalacji kolejnych, irytujących, wtyczek do przeglądarek. Dostaliśmy w nasze ręce kolejne maszyny wirtualne, tym razem oferujące tworzenie aplikacji z ładniejszym interfejsem. Po co kombinować z rozwijaniem istniejących standardów kiedy można stworzyć parę innych? Z drugiej strony kilka pomysłów zatrzęsło świadomością developerów i kierowników, a to za sprawą: beznadziejnych mechanizmów generowania JavaScript i tu już użytecznych generatorów stron, np. administracyjnych. Gdzie się zgubiliśmy?

Cały czas wyodrębniamy model budowy standardowych witryn od RIA i używamy narzędzi server-side do generowania treści HTML. Używamy przerośniętych frameworków do serwowania stron i łatamy dziury funkcjonalności klejonym na poczekaniu kodem JavaScript po stronie klienta. Przecież w przeglądarkach posiadamy już technologię do porzucenia tego podejścia za siebie. Mamy asynchroniczne zapytania, mamy świetny język po stronie klienta wspierany przez liczne, dojrzałe, biblioteki. Mamy silniki JavaScript które biorąc udział w wyścigu na wydajność są z miesiąca na miesiąc coraz szybsze. Dlaczego by nie traktować zwykłych serwisów jak aplikacji takich jak Gmail? Dlaczego mamy tkwić w epoce kamienia łupanego internetu?

Po chwili zastanowienia można wymienić kilka problemów, które stoją na przeszkodzie:

  1. Mentalność programistów i trudności ze zmianą podejścia do pisania aplikacji.
  2. Dostępność i świadomość istniejących narzędzi.
  3. Umiejętności i zrozumienie języka sterowanego zdarzeniami jakim jest JavaScript.

Poruszam się w środowisku w którym widzę lub słyszę co rusz jak wygląda programowanie interfejsów. Ludzie albo nie mają pojęcia jak się do tego zabrać albo nie są świadomi tego, że dokument po stronie klienta i narzędzia go serwujące to jedna aplikacja. Dlaczego dbają o to by kod siedzący na serwerze był jako tako zarządzany, a już ten po stronie klienta ich nie interesuje? Jak tu utrzymywać kod całego serwisu, który po stronie serwera jest kompleksową aplikacją, ale już po stronie przeglądarki brzydkim kaczątkiem? Problemem najważniejszym jest na pewno zmiana mentalności programistów, bo przecież przyzwyczajenie to druga natura człowieka. Przez wiele lat developerzy tworzyli swoje aplikacje, które po prostu serwowały dokumenty klientowi. Dokumenty, które nie żyły swoim własnym życiem, będąc statyczną reprezentacją stanu aplikacji. Dekorując je kodem wykonywanym w czasie rzeczywistym staramy się tylko ukryć fakt, że serwujemy klientowi tylko ładnie wyglądający bałagan. I nie mówcie mi, że jest inaczej. Mówimy tutaj o świadomości, która wyrosła z troszeczkę innych czasów pisania aplikacji czy serwisów, zwał jak zwał. Czasy malutkich fragmentów kodu, które miały wzbogacić wizualnie witryny skończyły się już dawno. Ostatecznie, nawet jeśli zrobimy wszystko porządnie i po stronie klienta zbudujemy także pełnoprawną i stabilną aplikację działającą na już zaserwowanym widoku także miniemy się z celem. Jaki jest sens utrzymywania dwóch aplikacji, które nota-bene robią niemal dokładnie to samo? Aplikacje mają warstwy, a my je naprawdę porządnie dublujemy.

Główna część naszej aplikacji działa w przeglądarce klienta i tam należy ją przenieść. To w tym miejscu musimy reagować na akcje użytkownika, a serwer zaprzęgać tylko do obsługi danych przechowywanych przez naszą aplikację. Tu pojawia się drugi problem, czyli narzędzia. Kto stosuje takie podejście? Przykładów nie znam. Nie mówię tutaj o edytorach tekstu, arkuszach kalkulacyjnych on-line, mówię o zwykłych serwisach. Jeżeli nikt nie stosuje takiego modelu to zdobycie dobrych narzędzi jest praktycznie niemożliwe. Są jednak zaczątki: od Google mamy Google Web Toolkit, dla JavaScript mamy JavaScriptMVC. Mamy sprawdzone architektury REST czy protokół JSON-RPC. Mamy także nierelacyjne bazy danych jak MongoDB czy CouchDB, idealnie nadające się do takiego modelu.

Ostatni problem to JavaScript. Nie sam język, ale jego natura i flow programu tak odmienny od prostego jak drut liniowego wykonywania zwykłej aplikacji serwującej dokument w PHP czy dowolnym innym języku. Postawcie pierwszego z brzegu programistę, web-developera i każcie mu zaprojektować interfejs Gmaila. Kompletnie inne podejście do problemu.

Jaka jest więc przyszłość w moim odczuciu? Aktualne frameworki server-side przestaną istnieć w takiej formie w jakiej je znamy. Zmienią specjalizację z generowania HTML na narzędzia pośredniczące w dostępie do baz danych i autoryzacji. Na fundamentach istniejących bibliotek JavaScript takich jak Dojo powstaną frameworki MVC, dziedziczące funkcjonalności aktualnych narzędzi server-side. Od czegoś trzeba zacząć, czemu nie zrobić tego przy okazji najbliższej aplikacji?

Komentarze (26) Odniesienia (0)
  1. Kocurro.pl
    00:01 on Styczeń 17th, 2010

    Wypowiedź w komponująca się w dyskusję, że programiści PHP to nie programiści. W pewnej chwili pokazałeś programistów PHP jako małpy, które są w stanie pisać tylko aplikacje sterowane żądaniami (które w zasadzie są liniowe) a nie dają sobie rady z aplikacjami sterowanymi zdarzeniami (które są nieliniowe).

    Ja zaczynałem swojej przygody z programowaniem od PHP’a a od TP, Delphi, C++ i dzięki temu potrafię teraz napisać kod server-side jak i client-side, który działa bardzo dobrze.

    Prawdę powiedziawszy tak jak przedstawiłeś problem to wygląda na to, że programiści stricte PHP to nieprogramiści.

  2. Damian Tylczyński
    00:14 on Styczeń 17th, 2010

    Myślę, że powodem nie jest fakt bycia lub nie bycia programistą, ale doświadczenie. Jeden język programowania i jedna specjalizacja nie dają na tyle szerokiego doświadczenia by odnaleźć się w różnych architekturach. Niezależnie czy byłby to PHP czy jakikolwiek inny język zaprzęgnięty do serwowania stron. Co najważniejsze mówiłem tu o bagatelizowaniu programowania interfejsu, nie o braku umiejętności. Możemy tu oceniać poszczególne jednostki i szczerze stronię od wypowiadania się o ogóle, o całej społeczności.

  3. Michał Kwiatek
    01:07 on Styczeń 17th, 2010

    Bardzo inspirujący wpis, muszę się w całości z nim zgodzić. Ale programowanie client-side ma jedną kilka wad m.in. dowolność w interpretacji kodu przez przeglądarki, a serwer zawsze robi to tak samo. Do tego nierówny rozwój przeglądarek etc.

    Aby taka metoda mogła odnieść skutek architektura client-side musiałą by sie znacząco rozwinąć i zunifikować co zapewne nie szybko nastapi w stopniu jaki by nas zadawalał.

  4. sf
    10:57 on Styczeń 17th, 2010

    Osobiście dla mnie wpis jest zbyt mało przejrzysty i naprawdę długo się zastanawiałem o co w nim w ogóle chodzi i tak naprawdę nie wiem. Nie wiem do czego uderzasz, nie podałeś żadnych przykładów stron i nie wymieniłeś co w nich jest złego poza dziwnymi stwierdzeniami dwóch aplikacji, brzydkiego kodu (a gmail ma ładny kod?!) oraz jak to można lepiej rozwiązać bazując na twoich propozycjach. Co nam daje użycie frameworków, który na końcu wymieniłeś i dlaczego uważasz, że przez to, że używasz/chcesz ich używać idziesz do przodu w aplikacjach? Pytanie – w jakich aplikacjach internetowych ma to sens, o tym też nie wspomniałeś, chyba że chcesz wrzucić wszystko do jednego wora.

  5. Egz
    11:11 on Styczeń 17th, 2010

    Bardzo dziwny wpis przyznam :) Wydaje się być bardziej jakimś opisem bliskiego otoczenia, niż obecnego stanu rzeczy w świecie „web-dev”.

  6. Damian Tylczyński
    11:39 on Styczeń 17th, 2010

    Jeżeli gdzieś jest inaczej to muszę się tam szybko znaleźć :) Chętnie przejrzę źródła projektów, które wdrażane są w modelu opisanym przeze mnie. Mógłbyś nam je wskazać? Chętnie zobaczę jak to robią inni, a doświadczenia nigdy dość :)

    @sf, próbuję wskazać jako błąd bagatelizowanie kodu po stronie klienta. Chciałbym, aby przy aktualnych możliwościach przeglądarek przenieść myśl techniczną z języków server-side do client-side. Próbuję wskazać, że niezależnie od tego czy kod jest ładny czy brzydki, w znaczeniu łatwości utrzymania, popełniamy błąd wciąż rozdzielając nasze aplikacje internetowe. Rozdzielamy na dwie boskie warstwy, kiedy najważniejsza istnieje tylko jedna: ta po stronie klienta. Serwer powinien dostarczać tylko dane wstrzykiwane do interfejsu, a nie wstrzykiwać cały interfejs. I co najważniejsze, piszę tu o zwykłych serwisach internetowych, nie o złożonych RIA. Tu podejście powinno się moim zdaniem zmienić.

  7. sf
    13:27 on Styczeń 17th, 2010

    O teraz już rozumiem, ale niestety ja osobiście jestem bardzo wstrzemięźliwy co do takiego podejścia. Może i za XX lat to będzie standard bo tego nikt nie jest w stanie przewidzieć, ale powiedz mi co dzięki temu zyskamy? Bo ja widzę same problemy. Jak sobie wyobrażasz pozycjonowanie takiego serwisu? Gdy prawie wszystko jest serwowane przez javascript. Co z faktem bardziej skomplikowanych projektów graficznych? Aktualnie już dzisiaj przerobienie projektu na html/css dość długo trwa, a potem jeszcze to przerabiać na generowanie przez javascript? Jakiekolwiek zmiany trwałyby znacznie dłużej. To generuje koszty.

    Wg mnie nie ma sensu rzucać się na głęboką wodę, tylko dodawać powoli dodatkową funkcjonalność do serwisów, która jest generowana. Obecnie dobrym tego przykładem są komentarze na stronach agory gdzie wczytywane są one osobno. Wyszukiwarki nie wysysają tych śmieciowych opinii. Po prostu ewolucja, a nie rewolucja.

  8. Damian Tylczyński
    14:13 on Styczeń 17th, 2010

    Wyszukiwarki sobie poradzą. Jeśli chodzi o przygotowywanie designu to już teraz dostępne są systemy szablonów dla JavaScript, jeden nawet zaprojektowany został przez Google. Problemem jest mentalność i przyzwyczajenia. Tak, kompletne porzucenie starego modelu wiąże się z ogromnymi kosztami. Mamy jednak narzędzia od których można zacząć: są technologie, są techniki komunikacji takie jak Comet i WebSockets.

    Projektując następne biblioteki i frameworki można zacząć powoli myśleć jak można by produkować następne aplikacje inaczej. Jeżeli będziemy liczyć na ewolucję to nigdy nie ruszymy się z miejsca. Ostatecznie model, który opisałem przeze mnie generował by oszczędności, np. cykli procesora serwera podczas generowania stron.

  9. Diabl0
    14:45 on Styczeń 17th, 2010

    Jedna „mała” ale o wielkim znaczeniu uwaga – stabilność strony client-side. Ciągle przeglądarki robią sobie z JS to co same chcą, a nie to czego oczekuje programista. Ciągle są spore problemy z zgodnością pomiędzy przeglądarkami. Ciągle pisanie pod JS to wieczne testowanie czy wszystko działa pod IE, FF, O, S, C, przez co znacznie rosną koszty a programista nadal nie ma pewności zachowania pełni kontroli nad treścią po stronie klienta.
    I dlatego większość nadal traktuje JS jako uzupełnienie server-side, a nie główną warstwę aplikacji.

  10. Damian Tylczyński
    15:34 on Styczeń 17th, 2010

    Niekompatybilność dotyczy operacji DOM i ich zdarzeń, nie samego języka. Pierwsza z brzegu biblioteka JavaScript załatwia sprawę, gdy chodzi o modyfikowanie HTML. Dodatkowo, przykładowe Dojo uzupełnia język niezbędnymi do rozwijania dużych aplikacji cechami, takimi jak pakiety przestrzeni nazw umożliwiając zarządzanie zależnościami. Ze spokojną głową można go używać jako główny język tworzenia aplikacji. Spójrzcie jak Node.js wspaniale wykorzystuje jego możliwości.

  11. Zyx
    15:57 on Styczeń 17th, 2010

    Nie wszystkie strony internetowe potrzebują wypasionych i ciężkich javascriptowych interfejsów. Właściwie to powiedziałbym nawet, że są one wskazane do kompletnych aplikacji uruchamianych w przeglądarce (np. GMail), ale bloga czy strony firmowej wykonanej w tej technologii wolałbym nie widzieć.

    Problem z bogatymi aplikacjami polega na tym, że próbują one zmusić strony internetowe do pracy w trybie, do którego nigdy WWW nie było projektowane i sam fakt ich istnienia to jedna, wielka prowizorka. Pierwszy z brzegu przykład to Gmail. Wielkim osiągnięciem jest w ogóle to, że działa tam przycisk „Wstecz”. O wielu aplikacjach JS nie można tego powiedzieć. Jednak nie otworzymy już sobie interesującej nas wiadomości w nowej karcie, ani nie dodamy jej adresu do zakładek. Jedyne, co możemy zrobić, to opalić po raz drugi całą aplikację i tam od nowa dostać się tam, gdzie chcemy. Karty i zakładki nie są elementami protokołu HTTP, tylko powszechnie przyjętymi dodatkami przeglądarek, ale unikalne i jednoznaczne adresy URL do opublikowanych zasobów już tak. W bogatej aplikacji wszystko to zostaje wyrzucone na śmietnik i musi być ewentualnie zaprogramowane od zera w JS. Po co jest Gmailowi reszta przeglądarki? Po nic, po prostu jedynie prowizorka oparta na protokole HTTP jest w stanie dotrzeć do rzesz użytkowników, bo nie ma żadnej innej otwartej i powszechnie przyjętej technologii do udostępniania takich aplikacji przez sieć.

  12. Damian Tylczyński
    16:22 on Styczeń 17th, 2010

    Poczekajmy na szerokie wdrożenia WebSockets i wysyp rozwiązań wspomagających wdrożenia z wykorzystaniem tej technologii. Myślę, że wiele rzeczy się zmieni po jego upowszechnieniu.
    Interfejs zwykłych serwisów zaprojektowany w czystym JavaScript nie musi być ciężki i wypasiony. To przecież tylko kilka komponentów renderujących layout, łączących się z bazą danych i wstrzykujących menu oraz treść strony. Historia przeglądarki może być zarządzana w ten czy inny sposób. Wystarczy wrzucić wujkowi Google „javascript history manager” i dostaniemy liczne gotowe rozwiązania, w tym jako pluginy do wielu bibliotek. Spójrzcie jak to zostało rozwiązane tutaj.

  13. batman
    22:26 on Styczeń 17th, 2010

    A ja pozwolę sobie nie zgodzić się z autorem i przedstawić dosyć odważną tezę – nie znasz warunków rynku i patrzysz na sprawę tylko z jednej strony. Nie wysiliłeś się nawet na sprawdzenie, co ma do powiedzenia druga strona, czyli klient.
    Jakoś nie widzę radości u klienta, który ma otwarte 3 zakładki, a jego procek wyciska z siebie siódme poty, by ogarnąć to co się dzieje z przeglądarką.

    Poza tym nie mogę zgodzić się z częścią Twoich wypowiedzi:
    „Po co kombinować z rozwijaniem istniejących standardów kiedy można stworzyć parę innych?”
    W takim razie proponuję stworzyć dwie nowe przeglądarki, które interpretują HTML+CSS+JS w zupełnie odmienny sposób. Lub napisać nowy system operacyjny, pod który trzeba napisać od nowa sterowniki i oprogramowanie.

    „Dlaczego by nie traktować zwykłych serwisów jak aplikacji takich jak Gmail? Dlaczego mamy tkwić w epoce kamienia łupanego internetu?”
    Ponieważ tkwi tam większość dużych klientów. A tam gdzie duży klient, tam kasa. Nowinki są dla geeków, a nie dla korporacji, którym zależy przede wszystkim na stabilności. Wspomniałeś pod koniec wpisu o CouncDB. Sprawdziłeś na jakim etapie jest ten projekt?

    „…języka sterowanego zdarzeniami jakim jest JavaScript.”
    Jeśli podajesz przykład języka, to podawaj dobry przykład. Znacznie lepszym językiem jest ActionSctipt w wersji 3. Bez zrozumienia modelu zdarzeń, nie ma co podchodzić do tego, a zwłaszcza do Flexa.

    „Niekompatybilność dotyczy operacji DOM i ich zdarzeń, nie samego języka”
    A co powiesz na E4X? Jest to element języka, który działa tylko w Firefox i nie ma możliwości zasymulowania jego działania w popularnych bibliotekach.

    Rozumiem, co chciałeś napisać, jednak odnoszę wrażenie, że nie do końca przemyślałeś temat.

  14. Damian Tylczyński
    23:03 on Styczeń 17th, 2010

    „Po co kombinować z rozwijaniem istniejących standardów kiedy można stworzyć parę innych?”
    Ten fragment akurat wyśmiewał tworzenie platform RIA jako nowych standardów. Nie strzelam sobie w stopy, uwierz mi. Czasem używam po prostu sarkazmu.

    „Wspomniałeś pod koniec wpisu o CouncDB. Sprawdziłeś na jakim etapie jest ten projekt?”
    Jasne, że sprawdziłem. Pijesz do bezpiecznej autoryzacji lub cookie? Osobiście wolę MongoDB, CouchDB był tylko przykładem – komu on odpowiada, ten poczeka na 0.1.

    „A co powiesz na E4X?”
    Dotknąłeś akurat bolączki tego języka, czyli parsowania XML. Ten argument potwierdzam choć osobiście od XML trzymam się z daleka.

    I odpowiadając na najważniejsze. Gdyby interesował mnie tylko klient, pracowałbym dla niego za darmo. Częścią naszego życia jest technologia, a technologię cechuje innowacyjność. Tak, wiem, że jeśli wszystkie strony dzisiejszego internetu podmienić na model, który zaproponowałem powstałby kompletny chaos. Wiem też jednak, że aktualny stan technologii internetowych i zmian, które zachodzą stanowi wielką szansę i aby przyśpieszyć ten proces należy tą szansę wykorzystać już teraz. Niewiele firm stać na innowacyjność pokroju Google, tworzącego pod swoim szyldem niezwykłe rzeczy popychające naszą branżę do przodu. Jeżeli nie stać Cię na nią, stój w miejscu, szlaki przetrą inni. Pamiętaj też, że społeczność internetowa to nie tylko biznesmeni starający wydrzeć dla siebie jak największą część bogatego tortu. To także ludzie dla których ten wirtualny świat to hobby, inżynierowie, którzy za darmo współtworzą narzędzia z których części na pewno sam korzystasz. Ludzie, którzy nie widząc grosza rozwijają naszą branże, na której tak wielu zarabia. Nie zatrzymuj więc takich pomysłów oskarżając je o brak kontaktu z rynkiem. To, że Ty na nich dzisiaj nie zarobisz, nie stanowi większego argumentu.

    I co najważniejsze. Cieszę się, że wpis generuje tyle emocji.

  15. batman
    23:24 on Styczeń 17th, 2010

    Google był innowacyjny jedynie na początku swojej drogi. W chwili obecnej jest to wykupowanie wszystkiego co może przynieść zysk oraz wytwarzanie zapotrzebowania na usługi/produkty, których istnienie pozbawione jest sensu (Chrome OS, Wave).
    Rozwój aplikacji internetowych, jak i desktopowych, powinien być ewolucyjny z jednego, prostego powodu – przyzwyczajenia użytkowników. Nie da się tego zmienić i w żaden sposób kontrolować. Jeśli zmiana będzie na tyle radykalna, że użytkownik będzie musiał się od nowa uczyć obsługi, wówczas istnieje bardzo duża szansa, że odejdzie on do konkurencji lub w ogóle porzuci ten produkt.
    Najważniejsze w tym biznesie jest nie to, kto wymyśli najbardziej absurdalną rzecz, tylko kto będzie potrafił ją sprzedać. Sądzisz, że jeśli Wave zostałby wymyślony i napisany przez firmę z Wólki Wielkiej, to byłby taki szał na świecie? A dlaczego CounchDB ma przed nazwą Apache? Nie myl PR z innowacyjnością.

  16. Damian Tylczyński
    01:49 on Styczeń 18th, 2010

    Google nieinnowacyjny? To, że ich rozwiązania mogą się nie sprzedać nie znaczy, że oferują starą, strawioną wielokrotnie papkę. Nawet jeśli uważasz, że Google Wave pod względem innowacyjności to zeszłoroczny śnieg, to spójrz na rozwiązania, które powstały dzięki takim jak Wave projektom: V8 czy Google Web Toolkit. W takim razie technologia dobra i innowacyjna to taka, która generuje popyt i zysk, tak? I oczywiście, jednocześnie nie zmienia zupełnie nic bo jeszcze klient się obrazi, że coś nowego mu oferujemy? Taka technologia jest innowacyjna i dobra dla kogo?
    Kompletnie nie rozumiem jak można mówić, że ewolucji aplikacji internetowych nie można w żaden sposób kontrolować. Czyżby po ich stworzeniu, w otchłaniach internetu rozmnażały się i rosły bez naszej pomocy? Czyżbyśmy zupełnym przypadkiem odkryli sztuczną inteligencję? To nie my budujemy i nie rozwijamy aplikacji? Nie mamy więc, kompletnym przypadkiem, delikatnego wpływu na ich ewolucję?
    Chciałem zaznaczyć jedną ważną rzecz, już wracając do głównego tematu: model, który zaproponowałem nie zmienia sposobu korzystania z internetu przez użytkowników. Nie zmienia ich przyzwyczajeń. Zmienia wizję sposobu budowy witryn, serwisów czy aplikacji niemal transparentnie dla potencjalnego internauty.

  17. batman
    09:55 on Styczeń 18th, 2010

    Innowacyjność Google polega na wytworzeniu zapotrzebowania, a dopiero potem na wprowadzaniu „nowości”. W chwili obecnej Wave we wczesnej fazie rozwoju i zmieni się jeszcze wiele razy. Wystarczy spojrzeć na ilość zmian, jakie wprowadzane się do API tej usługi. V8 i GWT nie powstały na potrzeby Wave. Pierwszy powstał jako silnik JS dla przeglądarki Chrome, drugi jako konieczność znormalizowania kodu wysyłania do klienta. I była to najnormalniejsza w świecie ewolucja. Od bałaganu i różnego API wielu usług, do jednej platformy, która będzie w przyszłości bazą dla wszystkich usług.
    Nie twierdzę, że postęp jest uzależniony od wielkiej kasy i korporacji. Tzw ruch sierotek marysiek (open source) pręży się i spina, by wprowadzać nowinki, dzięki czemu będzie zauważony i bardzo dobrze. W końcu na 1000 wymyślonych rzeczy jedna rzeczywiście jest tą przełomową, która wytycza standardy. Nie można jednak zapomnieć, że bez dobrego marketingu, nawet geniusz nie byłby w stanie wypromować swojego pomysłu. Najlepszym na to przykładem jest AJAX. Technologia, która była znana na wiele lat przed jej „odkryciem”. Marketingowcy wymyślili „łeb 2.0″ i nagle AJAX stał się standardem.

    A wracając do tematu. Mi również zależy na tym, by serwery pełniły jedynie rolę magazynów danych i dostawców usług sieciowych, a cała zabawa z generowaniem treści odbywała się po stronie klienta. Dlatego też zabrałem się za Adobe AIR, najpierw za wersję JavaScript, a obecnie za Flex-a. I mimo, że pomysł ten bardzo mi się podoba, to nie widzę w najbliższej przyszłości miejsca dla takich aplikacji. Jest na to za wcześnie. Giganci rynku muszą mocno się spiąć, by przekonać użytkowników do takiego modelu. Sądzę, że po to właśnie Google wymyślił Chrome OS. Przecież to jest tylko interfejs dla usług sieciowych.

  18. Damian Tylczyński
    11:21 on Styczeń 18th, 2010

    V8 czy GWT powstały pośrednio i bezpośrednio właśnie dla aplikacji Google oraz jako katalizator zmian w rynku internetowym. Twierdząc inaczej robimy z naszej ulubionej korporacji Matkę Teresę, nudzącą się i rzucającą swoje pliki dolarów w losowo wybrany śmietnik.
    I tak, zgadzam się, wszystkim nam zależy na uporządkowaniu modelu tworzenia aplikacji internetowych. Ja jednak uważam, że pewne zmiany jakie zachodzą i poprzez szybki rozwój przeglądarek i standardu HTML idą właśnie w kierunku zorientowanych na dokumenty bogatych aplikacji (Document Oriented Rich Internet Applications?).
    Myślę, że gdyby powstało narzędzie implementujące taki model, które znalazło by ogromne poważanie po stronie developerów i marketingowców jak zrobił to niegdyś Ruby on Rails, wiele rzeczy mogło by się zmienić. Nawet jeśli jest na to za wcześnie, miło jest próbować promować teraz takie podejście do budowy internetowych produktów. Cieszę się też, że blogosfera pozwala nam dyskutować nad takimi pomysłami i dzielić się doświadczeniem.

  19. batman
    12:08 on Styczeń 18th, 2010

    „poprzez szybki rozwój przeglądarek i standardu HTML”
    Szybki rozwój przeglądarek – tak, standardu HTML – nie. HTML umiera powolną i bolesna śmiercią. Wystarczy porównać datę wydania standardu wersji 4 oraz planowaną datę wydania wersji 5. Rewolucja, jaką miał być XHTML, okazała się wielką klapą, z której W3C się wycofało.

    „Myślę, że gdyby powstało narzędzie implementujące taki model”
    Nieśmiało wspomnę o Flex i Silverlight jako nowych sposobach tworzenia bogatych aplikacji. Obie technologie noszą znamiona przełomowych. Sądzę, że ostrożnie można założyć, że to właśnie przy ich pomocy będą powstawać proste aplikacje desktopowe, zastępujące częściowo to, co jest dostępne jedynie przez przeglądarkę.

  20. Egz
    13:09 on Styczeń 18th, 2010

    „Jeżeli gdzieś jest inaczej to muszę się tam szybko znaleźć :) Chętnie przejrzę źródła projektów, które wdrażane są w modelu opisanym przeze mnie. Mógłbyś nam je wskazać? Chętnie zobaczę jak to robią inni, a doświadczenia nigdy dość :)”

    Internet jest otwarty dla wszystkich, wystarczy pogooglać, poszperać po projektach, po blogach ich autorów. Moje pierwotne wrażenie nadal nie minęło. I podpisuję się pod prośbą Stormfly. O których stronach piszesz? Które projekty należą do grona Twoich zainteresowań? No bo ok, wyjaśnić możemy sobie jedno.. . ‚Polska Partia Przyjaciół Piwa’, czy jakiś ‚Pudelek’ chyba do nich nie należą? :P

  21. Damian Tylczyński
    13:32 on Styczeń 18th, 2010

    Gdybym wymienił te złe przykłady z nazwy w kontekście tego wpisu, robiłbym im czarny PR, a tego robić nie chcę. Podałem jednak rozwiązania, które osobiście uważam za dobry trend i przyjrzenie się ich wzorcom powinno naprowadzić na elementy, które sobie cenię. Ja także zachęcam do googlowania i poszperania po projektach :) Możliwe, że demonizuję, ale krótki felieton w takim tonie jest świetną metodą na rozbudzenie dyskusji.

    @batman, HTML mógłby stanąć i powiedzieć za Markiem Twainem: „pogłoski o mojej śmierci były mocno przesadzone”. W praktyce ten standard po latach stagnacji od roku 2008 zaczyna przeżywać swoją drugą młodość. Data ostatecznego wydania, jak widać po adoptowaniu nowych funkcjonalności przez przeglądarki, nie wpływa negatywnie na rozwój tego standardu.
    Co do platform RIA, rozumiem ostrożne podejście. Osobiście nie wierzę w wydarzenie, które wyłoniło by jedną dominującą, a ten fakt będzie myślę wyznacznikiem ich bytu.

  22. Andrzej Piotrowski
    01:07 on Styczeń 24th, 2010

    Zgadzam sie z Batman’em. Silverlight i Flex to killerzy PHP. Patrząc na rozwijające się zapotrzebowanie na aplikacje web/desktop , nie da się określić jak długo PHP pożyje ale z góry przesądzić o jego losie.
    Propo tworzenia czegoś – Tuner :)
    Na stronie masz prezentacje z Wawy – szkoda że grafika nie animuje się bo wygląda to jakby tam chaos panował :) Zebrałem się w sobie po „występie” i pisze odpowiedz na zarzuty ….

  23. Damian Tylczyński
    01:12 on Styczeń 24th, 2010

    Ja jednak patrzę na te rozwiązania jako na zapchaj dziury na jeszcze najbliższe 3-4 lata. I żeby nie było niedomówień, uważam je jednocześnie za dobre i komplementarne technologie :)

  24. Zyx
    16:54 on Styczeń 27th, 2010

    Andrzej Piotrowski -> a co ma niby wspólego PHP i taki Silverlight? Przecież te technologie pracują w zupełnie innych segmentach, więc nie są nawet bezpośrednimi konkurentami. PHP i inne języki mogą co najwyżej zostać wyparte z roli serwerowego back-endu dla RIA, ale nic poza tym, bo WWW na tym się nie kończy. Są i zawsze będą strony, które takiej funkcjonalności po prostu nie potrzebują.

  25. Andrzej Piotrowski
    13:27 on Luty 7th, 2010

    Tyle że w założeniu Silverlight miał być Flash Killer – co się nie do końca udało ale powoli rośnie w siłę. Również MS jako kombajn .net powoli atakuje „segmenty”. Współdziałanie PHP z Silverlightem to też pewien rodzaj przyzwyczajania klienta że technologia RIA może współpracować ale też sama z siebie daję możliwość wejście w rynek PHP.
    Nie mówię , że KAŻDA strona będzie w wykorzystywać RIA. Wszystko zależy od potrzeb klienta – a to jaki segment wybierze.

  26. Adam
    00:40 on Luty 18th, 2010

    Rozumiem calkowicie autora. Widzialem jak „genialni programisci” wrzucali do jednego worka cala obsluge JS do jednego katalogu (np. app/public/js), wszystko wymieszane lub w pozornym porzadku (podzial: front/admin). W 2010 JS jest NA ROWNI traktowane z z jezykami server-side i posiadanie balaganu lub pseudo-porzadku niczym nie jest usprawiedliwione. Autor poruszyl dosc ciekawy temat.

Niestety, skomentowanie tego wpisu jest niemożliwe.

No trackbacks yet.

Optimization WordPress Plugins & Solutions by W3 EDGE