ostatnimi czasy zastanawiam się nad przyszłością aplikacji internetowych. Coraz częściej czyta się o real time web, rozwoju JavaScriptu itp. Czy uważacie, że nieuniknionym jest swoiste zwiększanie zaangażowania użytkownika w korzystaniu z aplikacji poprzez automatyczną odpowiedź na jego działania (jak input, kliknięcia, itp.)?
Jak myślicie - wkroczymy niedługo w erę dominacji JavaScriptu zarówno po stronie front- jak i back-endu? Czy JS pozostanie wykorzystywany do frontendu, a do backendu w dalszym ciągu wykorzystywane będą inne języki (jak Ruby)?
Nie chcę rozpętywać kolejnej dyskusji na temat Real Time Web czy wyższości jednego języka nad drugim. Po prostu ciekawią mnie Wasze opinie.
Miałem tak w pierwszej firmie, poszedłem do innej i całkowicie się to zmieniło. Więc zależy to od projektu nad którym się pracuje.
Co do wykorzystania JavaScriptu jako całościowego rozwiązania frontendowego mam lekkie obawy. JavaScript z racji tego, że działa po stronie przeglądarki wykorzystuje silnik przeglądarki a co za tym idzie różnie się zachowuje na różnych przeglądarkach (silnikach). Na razie to trzeba stosować hacki dla różnych przeglądarek żeby dany kod zaskoczył - jakoś średnio mi się to podoba bo kod wtedy rozrasta się i nieciekawie to wygląda.
Druga sprawa to ładowanie szablonów:
a) generowanie po stronie serwer - szybko
b) ładowanie szablonów po stronie klienta - wszystko na poczatku (masakra)
c) ładowanie szablonów asynchronicznie po stronie klienta - potrzeba dodatkowego czasu na wykonanie dodatkowego requesta
d) generowanie fragmentu szablonu po stronie serwer - musze powiedzieć, że to rozwiązanie mi się najbardziej podoba, wykorzystuje je np. twitter (niestety ten ich flight.js jest strasznie okrojony i dużo rzeczy trzeba dodać samemu), znalazłem również rozwiązanie na jednej stronie jak w json był wstawiany kod html.
Zaraz pewnie odezwie się ktoś i powie, że u niego wszystko dobrze działa, podam więc konkretny przykład: sprawdź Androida i iOS dla np. obsługi filmików na stronie lub sharowania do social network, przynajmniej w tych dwóch kwestiach działają inaczej.
Nie twierdzę, że rozwiązania JavaScriptowe są złe, są poprostu inne.
Nie wiem jak jest teraz, ale pewnie dużo się nie zmieniło z obsługą błędów (wyjątków), której w node.js poprostu nie ma. Przykład: pracowałem kiedyś nad aplikacją, która łączyła się z mongodb, jeśli w jakimś momencie wystąpił jakiś exception to proces się zawieszał i trzeba było ręcznie go dobić. Zauważ, że node.js to nadal wersja 0.x a nie 1.x
W mojej opinii frameworki js beda stawaly sie dojrzalsze, wiec bedzie wieksza separacja frontend - backend, zapewne do komunikacji frontend backend node bedzie coraz popularniejszy, a do ciezszych zadan, bedzie ruby, jvm, go, c[++]. No i cale stada nowych i starych baz danych.
Jak czytam o Rubim i o RoR, to zawsze pojawia się ten tajemniczy zwrot “aplikacje webowe”. Ale co on konkretnie oznacza? Czy chodzi po prostu o pisanie stron internetowych?
Tak, głównie o strony, które są dynamiczne, gdzie content się zmienia, bo statyczne możesz sobie po prostu wyklikać w Pajączku. Gdy musisz coś gdzieś zapisać, z czymś się połączyć i tak dalej – wtedy potrzebujesz czegoś więcej niż tylko HTML i CSS.
Haha, “coraz częściej”, masz na myśli “od ostatnich kilku lat”? Póki co i Railsy i node.js mają swoją niszę – w Railsach o wiele wygodniej możesz napisać sobie jakiś CRM lub system do zarządzania zamówieniami niż w nodzie i dowolnym js-owym frameworku, a gdy masz zamiar pisać aplikację, która będzie ciągle oblężona requestami lub prosty backend dla single page app, to node może Ci się bardziej przydać.
Generalnie wydaje mi się, że ciekawszym aspektem rozwoju aplikacji webowych obecnie jest rozwój frontendowych bibliotek JS-owych + ciekam z niecierpliwością na Mozilla Servo i odpowiedź ze strony konkurencji. Prawdopodobnie to będzie miało największe znaczenie w webdevelopmencie w ciągu kilku najbliższych lat, no chyba, że nagle wszyscy postanowią pisać backend w Haskellu albo jakimś innym funkcyjnym języku.
A co do aplikacji webowych w Ruby, to jestem ciekaw Lotusa i czy w ogóle w ciągu najbliższego roku zmieni się podejście społeczności co do pisania railsowych aplikacji. Dużo przykładów było na tegorocznym wroc_love.rb, ale mam wrażenie, że żyję w pewnej bańce i tak naprawdę cała masa developerów dalej propsuje “skinny controllers, fat models”.
Aaaa, rozumiem. Czyli do pisania stron www, które spełniają rolę np. sklepów internetowych takich jak Allegro, Merlin, Amazon, jakiś forów dyskusyjnych, stron do których coś się dopisuje, dodaje, itp. Czy oprócz takich zastosowań Ruby może jeszcze mi się do czegoś przydać, np. do jakiś obliczeń, analizy danych, itp? Czy jednak jest nastawiony wyłącznie na te dynamiczne strony?
Ruby to nie php, dla tego pierwszego widzialem wiele aplikacji, które nie są stronami www, a dla tego drugiego niestety nie znalazlem, co nie oznacza, że nie istnieją.
Dominacji JSa na backendzie mam nadzieję że nie dożyję, ale smutna prawda jest taka że backendy w ciągu najbliższych lat zostaną okrojone wyłącznie do dostawców API i większość logiki wyleci do tłustych javascriptowych klientów. Co zresztą już się dzieje, więc nic ciekawego nie przewidziałem.
Smutna?!
Ja tam się cieszę od dawna, że nie muszę tworzyć nowych formularzy i zawsze tracić 15 minut na rozkminienie dlaczego mi nie działa upload plików (odpowiedzią zawsze jest, że zapomniałem multipart: true).
A tak na poważnie, to logika nie wyleci do javascriptowych klientów, bo musi być obecna w API (prawdziwa walidacja to po stronie serwera). Do frontendu wyleci flow, czyli gdzie ma mnie przenieść jak kliknę przycisk. Warto te dwie rzeczy rozgraniczyć.
