Przyszłość to web?

Jak w temacie.
Czy przyszłość to aplikacje webowe czy raczej pulpitowe? Jak Wam się wydaje i czym to możecie uzasadnić?

Temat to nie trolling. Pytam poważnie i też na takie odpowiedzi liczę.

Przyszłość znałby Nostradamus gdyby jeszcze żył. Ale ponieważ on nie żyje, to nikt nie zna przyszłości.
Można spróbować dowiedzieć się przyszłości u Cyganki lub jakiejś wróżki, która ma kryształową kulę, ale Nostradamus i tak wiedziałby lepiej.
Na pewno nie wolno pytać Billa Gatesa o to jaka będzie przyszłość informatyki.

Na pewno nie wolno pytać Billa Gatesa o to jaka będzie przyszłość informatyki.

Akurat jego wizja się sprawdziła. Komputer na każdym biurku.

@mvt8 90% softu który się teraz produkuje to soft webowy. Ale z drugiej strony informatyka zatacza koła co jakiś czas, więc nie tak łatwo wyrokować. Bo przecież na początku tworzyło się soft działający na terminalach, potem były grube klienty (żeby wykorzystać zasoby komputera użytkownika), potem znów były cienkie klienty, teraz webowe...

Pewne jest, że standardowe aplikacje desktopowe na pewno całkowicie nie znikną. Co najwyżej ich udział w rynku może być mniejszy niż aplikacji webowych. Zajmij się tym co lubisz, jak będziesz dobry to pracę na pewno znajdziesz nieważne jak niszowe to by było.

A programowanie pod web to syf najgorszy jaki może być. Nie cierpię tego tak bardzo że nie da sie nawet opisać.

A programowanie pod web to syf najgorszy jaki może być.

I dlatego można ze spokojem stwierdzić, że będzie popularne jeszcze przez dłuuugi czas.

othello napisał(a):

A programowanie pod web to syf najgorszy jaki może być. Nie cierpię tego tak bardzo że nie da sie nawet opisać.

Ale dlaczego? Bo nie rozumiesz ich działania, nie chce Ci się do tego przysiąść i nauczyć? Czy jakiś konstruktywny argument dasz?

Ja może podam dwa główne powody:

1. Używanie bezstanowego protokołu HTTP do tworzenia stanowych aplikacji.
2. Rozbieżności w interpretacji HTML, CSS, JS i czego tam jeszcze nie wymyślą w różnych markach i wersjach przeglądarek.

Ciekawy temat.
Tak na dobrą sprawę to sam się nad tym zastanawiałem jakiś czas temu i szukałem informacji z czego w większości mnie one nie zadowoliły. Moim skromnym zdaniem aplikacje działające w sieci mogą bardzo ułatwić życie chociażby z tego powodu, że mamy do nich bezpośredni dostęp zarówno z komputerów o przeróżnej architekturze - bo przeglądarkę mamy zawsze ale i nie jesteśmy uzależnieni od systemu operacyjnego. IMO łatwiej jest dostosować jakąś stronkę do interfejsu smartfona (patrz np. chip.pl) niż przepisać aplikację z Windowsa na Maca.
Tym samym możemy np. kontrolować bazę danych naszych klientów z autobusu, pociągu, samolotu i wielu innych miejsc.
IMO takie są zalety.

Teraz wady... ogromna niechęć społeczeństwa co można stwierdzić chociażby patrząc na Wasze wypowiedzi. To taki mniejszy problem. Gorzej z tym, że łatwiej można wykraść informacje z takich aplikacji. Bądź co bądź stronę internetową jest łatwiej zhackować.

Aplikacja RALPH autorstwa Allegro również działa w sieci i jest bardzo użyteczna pomagając pracownikom Allegro.
Dużych przykładów sukcesów aplikacji webowych nie trzeba szukać daleko. Tak mam na myśli Google:
-Dokumenty;
-Google Drive;
-GMail;
-PicasaWeb

to wszystko działa w sieci i spójrzcie jakie odnosi sukcesy.

Moim zdaniem przyszłość, to wieloplatformowość (albo multiplatformowość ?). Web też ma tu swoje miejsce, a może lepiej, wykorzystanie Internetu. Swoją drogą to może się rozprzestrzenić też w kierunku np. budownictwa inteligentnego itp. Prozaiczna kwestia - zakupy. Mamy program X, którego jedynym zadaniem jest przechowywanie listy zakupów. Działa on sobie na smartphonie, desktopie, laptopie, czytniku ebook, tablecie i naszej "inteligentnej" lodówce, która również jest podłączona do sieci Web. Jak przystało na inteligentną lodówkę, "wie" ona co się kończy, czego brakuje, co trzeba kupić. Najprościej jeśli te informacje będą przechowywane gdzieś w sieci, a na poszczególne platformy będą napisane programy klienckie korzystające z tych danych (i przypominające nam "co kupić ?").

To dodatkowo determinuje większe wykorzystanie wszelkiego rodzaju uC i rozwój systemów embedded.

Czy aplikacje Web'owe czy desktopowe ? Jeśli mamy aplikację kliencką, która jest małym oknem wyświetlającym się stale na pulpicie, ale korzystającą z danych pobieranych z serwera, to jaka to będzie aplikacja ?

Tak tak, aplikacje webowe, z ich wszystkimi zaletami. A spójrzcie na to: - czy nie byłoby to o wiele bardziej naturalne podejście do tematu aplikacji webowych niż całe asp.net (przykładowo) i stosowanie wielu hacków i masy udziwnień aby osiągnąć stanowość aplikacji? Do tworzenia aplikacji webowych (nie stron internetowych tylko aplikacji webowych) coś takiego byłoby na pewno naturalniejsze.

To jest jednak tylko ciekawostka i taką już pozostanie. Ale gdyby któryś z "wielkich" graczy zastosowałby takie podejście do tworzenia aplikacji webowych i nie byłby to tylko na maksa spierdolony i eksperymentalny projekt jednego tylko człowieka to kto wie czy by to się nie przyjęło.

Gdyby - przykładowo - aplikacja WPF w .net framework bez problemu mogłaby być uruchamiana jako webowa w przeglądarce z wykorzystaniem websockets i html5, z uwzględnieniem wszystkich niuansów jak piękny wygląd (style skórki itd), odpowiednie zabezpieczenia na poziomie sieci (autoryzacja, szyfrowanie danych), kompresja przesyłanych danych i byłoby to naprawdę dopracowane, to na pewno byłoby to lepsze podejście od aplikacji webowej w dzisiejszym rozumieniu tego słowa, zwłaszcza że ten sam program mógłby działać jednocześnie jak aplikacja webowa albo tradycyjna desktopowa. Ale raczej komercyjnie nikt nie myśli aby iść w tym kierunku - szkoda.

Zamiast tego mamy wykorzystywanie na siłę bezstanowego protokołu http do tworzenia aplikacji które mają działać jako stanowe, co wymaga masy udziwnień i hacków i tylko wszystko utrudnia. Dobrze by było nie stawiać znaku równości pomiędzy stroną internetowa, a aplikacją webową i nie używać tej samej technologii do jej tworzenia - ta druga ma zachowywać się tak samo jak desktopowa tyle że działać w przeglądarce. Więc to nie jest to samo co bezstanowa strona internetowa, która ma tylko wyświetlać informacje po kliknięciu w odnośnik.

Zawsze można użyć Flasha, Silverlighta czy JavyFX.

Na pewno JavęFX można odpalać w przeglądarkowym sandboxie i jako samodzielną desktopową aplikację bez większych zmian.

Pewnie że można, ale przykład gtk broadway pokazuje ze mozna inaczej. Filozofia oddzielenia warstwy gui programu od tego co program realizuje bardzo trafia mi do przekonania. Programista tworzy aplikację jak zawsze - jako stanową i desktopową, a to w jaki sposób zostanie uruchomiona - czy gui ma przesyłać do klienta przez web, czy wyświetlać lokalnie to nie ma już żadnego znaczenia.

To jednak całkiem inna bajka niż flash, silverlight czy java, gdzie wszystko realizowane jest po stronie klienta. Od strony technicznej to niemal to samo, co pobranie aplikacji na dysk klienta i uruchomienie jej po pobraniu - tyle że uruchamia ją przeglądarka poprzez maszynę javy, wtyczkę flasha itd a nie bezpośrednio system operacyjny. Aplikacja webowa to taka, która jest uruchomiona na serwerze, a komunikuje sie z użytkownikiem za pomocą przeglądarki. A nie uruchomiona u klienta. Tak powinno być zdefiniowane pojęcie aplikacji webowej, w tym sensie żaden aplet jaby ani aplikacja we flashu aplikacją webową nie jest - jest tylko aplikacją uruchamianą przez przeglądarkę po pobraniu jej w całości z internetu.

Nie wierzę, że przykładowo MS nie byłby w stanie zrobić tego porządnie, wprowadzając w swoim .net. Gdyby to było zrobione porządnie to byłoby bardzo ciekawą funkcjonalnością. Ale porządnie zrobione to może być tylko wtedy, gdy ktoś się tym porządnie zajmie - czyli licząca się firma która tak naprawdę dyktuje warunki.

Po prostu - tworzenie aplikacji typu asp.net to dla mnie jest nienaturalne podejście i same utrudnienia. A popularne to jest, bo znacznie wygodniejsze dla użytkownika końcowego, łatwiejsze do zarządzania, administracji, aktualizacji. Zalet wymieniać chyba nie trzeba.

Chrome ma takie coś:

http://en.wikipedia.org/wiki/Google_Native_Client

Akurat wcale mi się to nie podoba, bo to dalej web tylko uruchomiony u mnie. Dodatkowo jest to kolejny "standard", którego nikt nie będzie przestrzegać. Może jestem trochę staromodny, ale lubię normalne desktopowe aplikacje. Z drugiej strony nie powiem, że taki np. gmail jest źle zrobiony i go nie używam. Wydaje mi się, że nie można przesadzać - Photoshopa nie musi być w przeglądarce, a poczta to akurat wybitnie sieciowa rzecz.

Właśnie o to chodzi, żeby aplikacja nie działała po stronie klienta - o tym pisałem wyżej. Phothoshop w przeglądarce - a niby czemu nie? Może akurat nie sam phothoshop, ale aplikacja równie skomplikowana - cały ciężar obliczeń przejmuje serwer, a klient loguje się ze smartfona - czemu nie? Gdyby powstało coś na podobnieństo gtk broadway, ale dopracowane i używalne, zrobienie czegoś takiego nie wymagałoby żadnej dodatkowej pracy.

Nie mówię, że nie - może komuś pasuje taki cienki klient. Ja lubię mieć wszystko pod kontrolą. :-P

Inna sprawa to oprogramowanie dla firm. Tam takie coś jest pożądane, ale to chyba już jest? Java cośtamcośtam, nie znam się na tym.

Ale co Wy tak jeździcie po WWW i HTTP? Czyżby wybitni naukowcy z CERNu mieli złe pomysły? ;P

othello napisał(a):

Gdyby - przykładowo - aplikacja WPF w .net framework bez problemu mogłaby być uruchamiana jako webowa w przeglądarce z wykorzystaniem websockets i html5, z uwzględnieniem wszystkich niuansów jak piękny wygląd (style skórki itd), odpowiednie zabezpieczenia na poziomie sieci (autoryzacja, szyfrowanie danych), kompresja przesyłanych danych i byłoby to naprawdę dopracowane, to na pewno byłoby to lepsze podejście od aplikacji webowej w dzisiejszym rozumieniu tego słowa, zwłaszcza że ten sam program mógłby działać jednocześnie jak aplikacja webowa albo tradycyjna desktopowa.

Gdyby to było proste i sensowne, to pewno ktoś by to zrobił. Mi się jednak wydaje, że łatwiej jest zrobić framework webowy i pozwolić profesjonaliście napisać dopasowaną aplikację niż tworzyć uogólnione automagiczne rozwiązania, dzięki którym każda małpa wygeneruje zapewne bardzo słaby i przeciążony kod dla przeglądarki.

Zamiast tego mamy wykorzystywanie na siłę bezstanowego protokołu http do tworzenia aplikacji które mają działać jako stanowe, co wymaga masy udziwnień i hacków i tylko wszystko utrudnia.

Skoro środowisko jest bezstanowe, to czemu na siłę tworzyć aplikacje stanowe? To nie ma sensu.
Najlepsze rozwiązanie - nie korzystać ze stanu.

WWW to nie desktop, nie można oczekiwać, że będzie pisało się tak samo. Równie dobrze można by oczekiwać, że aplikacje na mikrokontrolery będzie się pisało tak samo jak na desktopy.

Naukowcy z CERNu chcieli po prostu zrobić rozproszonego manuala, a nie interaktywne aplikacje webowe.

Skoro środowisko jest bezstanowe, to czemu na siłę tworzyć aplikacje stanowe? To nie ma sensu.
Najlepsze rozwiązanie - nie korzystać ze stanu.

No to wywal sesje i nie wpychaj też stanu do URLa czy ciastek.

Aplikacja bezstanowa, przede wszystkim, musi wyświetlać to samo dla danego zapytania za każdym razem. Czyli np dla URLa http://coźtam.pl/profil musiałaby wyświetlać to samo dla każdego kto wchodzi na stronę.

Wibowit napisał(a):

Naukowcy z CERNu chcieli po prostu zrobić rozproszonego manuala, a nie interaktywne aplikacje webowe.

No to czemu na nich narzekacie?

No to wywal sesje i nie wpychaj też stanu do URLa czy ciastek.

Mi tam nie przeszkadza istnienie całego jednego ciastka z id sesji i zapisanie w niej id oraz nazwy zalogowanego użytkownika nie przeszkadza. To problem raczej tych, którzy chcą przechować informacje o stanie wszystkich kontrolek GUI.

No to czemu na nich narzekacie?

Eeee, że co? Narzekam na tych, którzy ubzdurali sobie, żeby robić stanowe aplikacje z użyciem HTTP.

Jak masz formularz na 10 etapów i chcesz mieć obsługę przycisku wstecz to i tak jest z tym dużo pieprzenia właśnie przez bezstanowość HTTP. Musisz gdzieś zapamiętać stan tych iluś tam już wypełnionych etapów, a zarazem musisz to zrobić tak, żeby ci nie zabrakło pamięci jeśli userzy będą sobie zamykać strony po wypełnieniu 5 etapów i nieoznaczeniu ich jako porzucone.

somekind napisał(a)

Gdyby to było proste i sensowne, to pewno ktoś by to zrobił. Mi się jednak wydaje, że łatwiej jest zrobić framework webowy i pozwolić profesjonaliście napisać dopasowaną aplikację niż tworzyć uogólnione automagiczne rozwiązania, dzięki którym każda małpa wygeneruje zapewne bardzo słaby i przeciążony kod dla przeglądarki.

No i właśnie ktoś już to zrobił, podałem przeciez przykład. W tym co napisałeś masz całkowitą rację. Trick polega na tym, że nie jest to próba automatycznego generowania kodu dla przeglądarki w postaci takiej, w jakiej dziś jest to pisane przez programistów webowych. Tego nie da się zrobić, bo nie można w skali 1:1 przełożyć aplikacji desktopowej na webową, a jeśli ktoś by spróbował to zrobić to wynik by był taki jak napisałeś.

Jednak, wykorzystując websockets i pewne mechanizmy html5, całe gui aplikacji można narysować w przeglądarce u klienta, zamiast lokalnie tam gdzie program jest uruchomiony. Dokładnie nie wnikałem, ale z grubsza polega to na przesyłaniu obrazków jako elementów gui, które są rysowane w przeglądarce, dodatkowo jest kompresja przesyłanych danych tak że za dużo danych pchać nie trzeba. Całość wygląda tak, jakby były to prawdziwe okna, tyle ze rysowane przez przeglądarkę i to ma szansę nieźle działać. Nie ma problemów z tym, że framework generuje jakiś nieoptymalny kod dla przglądarki bo po prostu nic takiego nie ma miejsca - tylko dwustronna komunikacja przez websockety i nic więcej. Z aplikacją webową w dosłownym rozumieniu tego słowa nie ma to zupełnie nic wspólnego.

Problem jest tutaj inny: same websockety sa niedopracowane, z powodu masy luk, błędów i dziur w zabezpieczeniach i tak są domyślnie wyłączone we wszystkich przeglądarkach. Ja bym jednak tak od razu takiego podejścia do tematu nie przekreślał - ciągle będę bronić tezy, że to ciekawa możliwość, tyle że póki co raczej ciekawostka - niedopracowana i opierająca się na nieukończonych jeszcze i także niedopracowanych rozwiązaniach. Jednak, kto wie co będzie w przyszłości i czy i jak się to wszystko rozwinie. Pożyjemy zobaczymy.

Ale co Wy tak jeździcie po WWW i HTTP? Czyżby wybitni naukowcy z CERNu mieli złe pomysły? ;P

Tyle że www to był projekt jednego gościa, klepany po godzinach jako tool który miał mu trochę ułatwić pracę. Cele i zastosowanie było zupełnie inne niż to do czego teraz się tego uzywa ;)

Większość jedzie po aplikacjach webowych bo tak bardzo je się źle pisze, zapominają tylko o jednym: użytkownika końcowego wali czy to się programiście dobrze programowało czy niedobrze - liczy się funkcjonalność a aplikacje webowe je oferują.
Jakby się dobrze przyjrzeć to 90% rozwiązań, które się przyjęły w IT wywodzi się z prowizorki i ma braki w designie, które z konieczności są utrzymywane. Protokoły (np. HTTP), procesory (np. x86), języki (np. C++), jeżeli kogoś to tak bardzo boli to polecam zmienić dziedzinę bo będzie się bardzo męczył przy programowaniu.

Większość jedzie po aplikacjach webowych bo tak bardzo je się źle pisze, zapominają tylko o jednym: użytkownika końcowego wali czy to się programiście dobrze programowało czy niedobrze - liczy się funkcjonalność a aplikacje webowe je oferują.

Na jakiej podstawie twierdzisz, że zapominają?

Jeśli chodzi o funkcjonalność, to zwykle większą funkcjonalność mają aplikacje desktopowe, a nie webowe. No chyba, że chodzi o coś typu społecznościówki.

jeżeli kogoś to tak bardzo boli to polecam zmienić dziedzinę

A to już ponarzekać nie można? Ponarzekać i spróbować zmienić sytuację.

Disclaimer: Nie znam się dobrze na GWT
Google opiera w większości swoje aplikacje na GWT, dzięki czemu elegancko omija (przynajmniej częściowo) problem bezstanowości HTTP i różnic między przeglądarkami, kosztem sporej ilości wygenerowanego gównianego JavaScriptu, którym przecież użytkownicy końcowi się nie przejmują.

Po prostu - tworzenie aplikacji typu asp.net to dla mnie jest nienaturalne podejście i same utrudnienia. A popularne to jest, bo znacznie wygodniejsze dla użytkownika końcowego, łatwiejsze do zarządzania, administracji, aktualizacji. Zalet wymieniać chyba nie trzeba.

Kiedy po raz pierwszy pokazano mi aplikację obiektową, stwierdziłam, że jest to nienaturalne, niezrozumiałe podejście i same utrudnienia. Programowanie sekwencyjne - to jest to!
Byłam jednak w stanie wgryźć się w temat, i teraz już wiem, że jest to po prostu podejście inne. Straszne, póki nie znane.

To samo dotyczy aplikacji webowych. Wielu chciałoby odpalić Visual Studio, poprzeciągać kontrolki, odpalić i zapomnieć. Szczególnie źle jest, jeżeli programista aplikacji desktopowych, mający wysokie mniemanie o swoich umiejętnościach, bez żadnego przygotowania (lub liznąwszy temat) zabiera się za aplikacje webowe. I jak coś nie wychodzi, to ta cała dziedzina jest głupia!

Najbardziej marudzicie na bestanowość http. No nie wiem, sam protokół uważam za bardzo dobry - prosty, przejrzysty. Nie zmieniany od 15 lat, a swobodnie można powiedzieć, że od jego powstania w 1991 nie wymyślono nic, co miałoby chociaż pretendować do bycia jego zastępstwem. Myślę, że jego bezstanowość jest jednym z czynników, które wpływają na elegancję http.

Dodatkowo wymyślono mechanizm sesji, by jednak stanowość zapewnić. I hej, to działa! Działa w pewien określony sposób - według mnie działa OK. Dlaczego więc narzekacie na bezstanowość, skoro ewidentnie można zastosować stan? Bo co, bo trzeba to obsłużyć? O matko jedyna, a w C++ trzeba czyścić pamięć, gdy nie jest już używana!
Poza tym nie wiem co to za problemy z sesją macie, od jakichś 5ciu lat nie musiałam sesji obsługiwać, bo ASP.NET i Symfony robią to za mnie.

Jak masz formularz na 10 etapów i chcesz mieć obsługę przycisku wstecz to i tak jest z tym dużo pieprzenia właśnie przez bezstanowość HTTP. Musisz gdzieś zapamiętać stan tych iluś tam już wypełnionych etapów, a zarazem musisz to zrobić tak, żeby ci nie zabrakło pamięci jeśli userzy będą sobie zamykać strony po wypełnieniu 5 etapów i nieoznaczeniu ich jako porzucone.

Szczerze mówiąc, wydaje mi się, że zaprojektowałeś swoją aplikację źle, jeżeli masz takie problemy. Ja to bym prawdę powiedziawszy kolejne elementy formularza doładowywała AJAXem, tak by nigdy nie przechodzić na inną stronę - użytkownik nie musi używać przycisku wstecz.
Nawet jeżeli chcesz koniecznie sobie tego wstecza obsłużyć, wciąż nie widzę problem - przecież sesja ma maksymalny czas trwania, zanim wygaśnie. Gdy wygasa, niszczone są wszystkie zmienne, które były wykorzystywane w danej sesji. Wystarczy dane formularza przechowywać w zmiennej, lub obsłużyć usuwanie danych w momencie wygaśnięcia sesji. To nie jest nic trudnego, i dramatyzujecie tutaj tylko dlatego, że nie chce wam się czytać standardów i do nich stosować.

Jeśli natomiast chodzi o różne interpretowanie htmla przez różne przeglądarki - ok, to jest fakt, że tak się dzieje. Jednakże nie jestem jednym z tych webdeveloperów, którzy uważają, że pod IE się nie musi dobrze wyświetlać, bo się nie da. (Te rozważania dotyczą IE >= 7) Mam ja kolegów webdeveloperów, którzy pokazywali mi swój kod, jako dowód, że IE jest spierdolone. I co się okazywało? Okazywało się, że po prostu Firefox/Opera są na tyle miłe, że ignorują błędy w htmlu i wyświetlają mimo błędów. IE nie dawał rady. I czyja to wina...? Jak ktoś nie zna takich podstaw, jak to, że środkuje się diva przez margin: auto, czy że po zabawach z floatem trzeba zrobić clear: both, to niech się prosze nie wypowiada :/ Albo ci specjaliści od siedmiu boleści, co całość layoutu opierają o position'y, a nie rozumieją różnicy między absolute, relative i fixed -_-'
Dobry kod wyświetla się dobrze pod wszystkimi przeglądarkami. Gdzieś się może rogi nie zaokrąglą, gdzieś nie będzie działał gradient tła, ale jeżeli strona ci się "rozjeżdża", to tylko i wyłącznie twoja wina.

Mnie osobiście ciągnie do webu ale mam ten sentyment do aplikacji desktopowych no i nie umiem tego rzucić :|
Warto zaznaczyć, że .NET to też dziedzina webowa dzięki ASP.NET ale czy ktoś może tu napisać jak ona się obecnie ma? Wydaje mi się, że pracodawcy bardziej stawiają w tym przypadku na PHP.

Nudziłem się wczoraj i poszukałem troszkę ofert pracy na Brytyjskim rynku oraz porównywałem widełki tych webowych do desktopowych. IMO wielkiej różnicy nie widziałem.
http://www.jobsite.co.uk/job/csharp-asp.net-software-developer-943373993?src=search przykład Angielskich widełek.

To ciekawsze:
http://www.jobsite.co.uk/job/software-developer-csharp-.net-sql-winforms-visual-studio-943415554?src=search
28 000 funtów do 37 000 funtów rocznie co miesięcznie daje jakieś (biorąc pod uwagę opcję optymistyczną) 3083 funty (na UK to dosyć dużo, wiem bo mój ojciec tam pracuje) czyli 616 funtów dostajemy tygodniowo (5 dni roboczych) co daje 15 funtów na godzinę.
Podsumowując programista .NET miesięcznie (po przeliczeniu na polskie biorąc na to obecny przelicznik czyli ~5zł) w UK zarobiłby: 15 tyś i 415 zł.
Porównywalnie do Polskiego programisty C++ lub managera co nie?

Mystogan napisał(a):

Warto zaznaczyć, że .NET to też dziedzina webowa dzięki ASP.NET ale czy ktoś może tu napisać jak ona się obecnie ma? Wydaje mi się, że pracodawcy bardziej stawiają w tym przypadku na PHP.

Wydaje mi się że się mylisz. Większość projektów to JavaEE, później (z niewielką różnicą) ASP.NET WebForms/MVC później dopiero PHP i wszelkie inne Django/Ruby itp. Widać to chociażby po ofertach pracy.

@aurel:
To wygasanie sesji to strasznie kiepskie rozwiązanie. Ja dla przykładu w robocie muszę używać i w tym czymś sesja chyba wygasa po 30 czy 15 (sam nie wiem) minutach. Mam co chwilę odświeżać? Wygasanie sesji to problem zarówno dla programisty jak i użytkownika. Nawet pingowanie jest kiepskim rozwiązaniem bo ktoś może mieć chwilowe problemy z siecią, a jeśli ma 10 kart otwartych to pingowanie jest razy 10. Podobnie działanie przycisku wstecz i wieloetapowe formularze - trzeba wstawiać jakiś tymczasowy stan do sesji, no chyba, że używamy AJAXa, ale wtedy utrudnione jest zachowywanie explicite częściowych danych z formularza na później. Z bezstanowością HTTP związane są jeszcze inne problemy, np nie da się zalogować do jednego serwisu jako dwóch lub więcej użytkowników naraz, trzeba stosować jakieś hacki, dla przykładu weźmy dwa konta mail na tym samym serwerze. Wady można wymieniać dalej, ale mi się nie chce.

Oczywiście bezstanowość HTTP można obchodzić na setki sposobów, tworzyć frameworki, etc tylko że frameworków webowych jest mnóstwo, tak samo języków programowania dla web jest też trochę i trzeba dziesiątek takich frameworków do obchodzenia bezstanowości HTTP. Przy każdym z nich oczywiście trzeba zadbać o zgodność z szeregiem przeglądarek. Ogromna ilość dodatkowej roboty, tylko dlatego, żeby robić stanowe aplikacje na bezstanowym protokole.

Mystogan napisał(a):

Oczywiście, że mogę się mylić :) Widzisz..Tobie też się wydaje ;) Dlatego chciałem, żeby jakiś spec sie wypowiedział :)

Spec od czego? Od rynku pracy? To chyba nie na tym forum. Mówię to z własnego doświadczenia.