Na początku zastrzeżenie ;-) Jestem developerem, i teraz zajmuję się głównie aplikacjami webowymi. Kocham JavaScript, a HTML mimo wszystkich wad jest świetny jeśli chodzi o budowę prostych interfejsów użytkownika.
Po zastrzeżeniach ;-) przechodzimy do sedna, czyli tego, że nie podoba mi się idea wspierana przez Chrome OS, czyli idea wyrażająca się słowami "wszystko jest aplikacją webową".
Oto dlaczego.
Po pierwsze aplikacja webowa z zasady będzie wolniejsza od aplikacji lokalnej. Prosty przykład to kontrola pisowni.
Jeżeli chcielibyśmy dodać do aplikacji webowej sprawdzanie pisowni on-line to będzie ono zawsze wolniejsze od sprawdzania pisowni lokalnie.
Czemu? Bo nawet jeśli przyjmiemy, że prędkość transmisji jest nieskończenie wielka, czyli sam czas transmisji jest zerowy, oraz czas obróbki po stronie serwera też jest zerowy to i tak mamy pewien minimalny czas potrzebny na komunikację.
Jeżeli serwer jest od nas o 1.5 tysiąca kilometrów, to sygnał musi przebyć 3 tysiące kilometrów po światłowodzie. Prędkość światła w światłowodzie to 2/3 prędkości światła w próżni czyli około 200000 km/s. Czyli od momentu wysłania słowa do sprawdzenia, do momentu gdy otrzymamy odpowiedź minie najmniej 150 ms. W 1GHz procesorze w 150 ms będziemy mieli 15 milionów taktów oczekujących na odpowiedź. Gdy będzie to procesor 2.2 GHz z 2 rdzeniami będzie to już 66 milionów taktów. Spokojnie w połowie tych taktów koniecznych na samą transmisję będzie można tego sprawdzenia dokonać lokalnie.
Mówiąc inaczej w świecie webowych systemów operacyjnych Twój komputer będzie głównie czekał.
Drugi powód to druga strona medalu, czyli utrata mocy komputera spowodowana tym, że to co można zrobić łatwo robi się trudno.
Przeglądarka to program komputerowy, który wyświetla pewne dane utworzone na podstawie HTMLa, CSSów i JavaScriptu.
Działanie aplikacji webowej to w dużym uproszczeniu coś takiego:1) Twoja przeglądarka chce wyświetlić stronę więc przesyła po sieci żądanie do serwera,2) serwer rozpoznaje żądanie, odsyła potwierdzenie i zaczyna przygotowywać stronę, w końcu wysyła HTMLa, CSSy i JavaScripty do Twojego komputera,3) Twoja przeglądarka interpretuje HTMLa, CSSy i JavaScripta i rysuje Ci stronę, 4) przyciskach guziczek, w tym momencie system operacyjny informuje o tym przeglądarkę,5) przeglądarka wykonuje jakieś zadanie napisane w JavaScript,6) przyciskach kolejny guziczek, system znów przekazuje żądanie do przeglądarki,7) przeglądarka stwierdza, że tym razem musi znów poprosić serwer o coś, i wraca do punktu 1W przypadku aplikacji natywnej [Java i C# też są w tym przypadku natywne], wszystko odbywa się w miejscu i nie ma momentu gdy trzeba interpretować coś by wyświetlić wyniki.
Tak naprawdę w aplikacji webowej każda robota odbywa się 2 razy, bo raz w przeglądarce, a drugi raz na serwerze.
AJAX tu trochę sprawę polepszył, ale mimo tego, że uważam AJAXa za jeden z największych wynalazków to jest to leczenie objawów, a nie przyczyn.
A taka kontrola poprawności danych to w ogóle świetna rzecz. Po pierwsze po stronie klienta wypada to zrobić bo głupio by było zmuszać klienta do czekania przez sekundę czy 10 na odpowiedź mówiącą tylko tyle, że nie wpisał jakiejś wartości, lub wpisał złą wartość. Po drugie, nawet gdy po stronie klienta to zrobisz to
musisz zrobić to samo po stronie serwera. Nie masz gwarancji czy ktoś Ci nie zmodyfikuje danych w locie, albo że nie przyśle Ci złych danych.
W przypadku aplikacji natywnej za to wszystko odpowiada system operacyjny. W przypadku aplikacji webowej nie odpowiada i nie będzie odpowiadał, bo to co możesz pominąć w systemie lokalnym, czyli ryzyko zmiany danych między interfejsem użytkownika, a logiką, w aplikacji webowej jest nie do pominięcia. Powód trzeci to konieczność wynajdywania koła za każdym razem gdy chcemy go użyć.
Przykładem niech będzie komponent zwany ComboBox'em. Jest to edytorek + lista wyboru.
HTML zna edytorek, zna listę wyboru, ale nie zna ComboBox'a.
Gdy jako developer chcąc użyć ComboBox'a musisz sobie go samemu napisać. Możesz też użyć jakiejś biblioteki, ale jest prawie pewne, że inna aplikacja użyje innej biblioteki, a jeszcze inna aplikacja, jeszcze innej biblioteki.
De facto każdy twórca każdej z aplikacji musiał wymyślić koło od początku.
To samo z rozwijalnymi menu i np. oknami modalnymi. Da się zrobić, ale trzeba samemu.
Tu jest jeden plus ;-) interfejsy się upraszczają. Gdy developerzy nie dostają wszelkiego rodzaju gadżetów to po prostu muszą korzystać z tego co jest i często wychodzi to aplikacji na dobre.
Powód czwarty to ograniczenie możliwości tworzenia aplikacji.
Teraz chcąc napisać program do zarządzania notatkami, muszę napisać kod i wymyślić jak przechowywać lokalnie dane. W aplikacji webowej muszę jeszcze znaleźć i opłacić serwer, który będzie służył do przechowywania notatek. Muszę dodać bardzo dużo zabezpieczeń by np. notatki te nie były dostępne dla kogoś innego niż Ty.
To są podstawowe powody.
Oczywiście to, że mnie się to nie do końca podoba nie oznacza, że takie podejście nie wygra ;-)Zalet jest co niemiara. Jeśli przeglądarki będą się synchronizowały między komputerami to ziści się niemal idealna bezszwowość aplikacji. Np. zaczniesz oglądać film na YouTube, Hulu czy czymś innym, na swoim netbooku. Po chwili postanowisz dalej oglądać go na laptopie podpiętym do telewizora HD. Wystarczy tylko "podnieść stan" tej akurat tabki na laptopie i można dalej działać.
Albo piszesz maila na laptopie, ale musisz szybko wyjść, i kończysz go pisać na komórce.
To wszystko jeszcze nie do końca działa z dzisiejszymi przeglądarkami, ale Chrome OS może tutaj zapoczątkować dobry trend. Przecież wystarczy by przeglądarki synchronizowały się w taki sposób, że przesyłałyby także ciasteczka i lokalnie składowane dane aplikacji i wszystko będzie działało super.
Chrom OS może zacząć też erę nowych komputerów.
Procesor powiedzmy 1 GHz, bez wiatraka, 1 GB RAM, do tego malutki dysk flash powiedzmy 8 GB i mamy maszynę na której możemy robić co nam się żywnie podoba. Ceny mogą tu naprawdę spaść.
W odróżnieniu do wielu osób nie uważam za to tego, że Chrome OS musi być ciągle on-line za wadę.
Nie licząc komórki, dzięki której jestem non-stop on-line, to prawie zawsze i tak jestem on-line na którymś z komputerów.
Ktoś może powiedzieć "OK, to Ty, ale zwykli ludzie nie mają Blueconnecta, a często nie mają też sieci w domu bo to drogie".
Tak, jest drogie, ale popatrzcie na to tak :-)
W 2002 roku płaciłem po chyba 70 złotych za 30 godzin miesięcznie połączenia z internetem z prędkością około 40 kbps.
W 2003 TPSA zaproponowała Neostradę 512 kbps za 160 złotych, a później chyba za 120 czy 100 złotych.
W 2005 roku Era sprzedawała Blueconnecta z prędkością 240 kbps lub 384 kbps za około 140-150 złotych.
W 2006 lokalni providerzy za 60-80 złotych dawali dostęp do sieci z prędkością 1-2 Mbps.
W 2007 Era w ramach Blueconnecta za 100 złotych dała prędkość 3.6 MBps, a później 7.2 MBps.
I tak dalej i tak dalej, w ciągu 5 lat transfer z którego korzystałem wzrósł o blisko 200 razy.Jeszcze inny przykład, przed 2004 rokiem każdy kto korzystał głównie z webowych aplikacji pocztowych uchodził wśród "śmietanki" za lamera.
W 2004 pojawił się GMAIL i z biegiem czasu większość tej "śmietanki" przesiadła się na webowego klienta e-mail.
W 2000 roku robiąc stronę WWW trzeba było myśleć o użytkownikach przeglądarek tekstowych i takich, którzy będą mieli wyłączone obrazki by przyśpieszyć transfer. Sam by przyśpieszyć działanie BuffyPedii zakodowałem jej cały mechanizm w JavaScript'cie, a i tak się przejmowałem, że przy pierwszym kontakcie klient będzie musiał pobrać ponad 27 KB JavaScript'u............
Dziś wiele stron w stylu blogów [czyli prostych stron] na dzień dobry ściąga 0.5 MB danych i nikt nie narzeka ;-)
A wracając do Chrome OS, to ciekawe czy Google będzie wspierać Java'ę. Chociaż w postaci apletów. Jako fan Java'y jestem za :-)
Podobne postybetaNajkrótsza droga do przyszłości - Polymer ;-)Przepis na szybkie programy ;-)Wybory i ordynacjeCeleron M353 900MHz vs. Intel Atom 1.6GHz, czyli o tym czemu jest remis? ;-)Elektryczna książka 2 - a może by tablecik? ;-)
