Pošto ljudi, generalno, ne vole baš mnogo nove stvari, bar ne vole da ih probaju na svojoj koži, trebalo je dosta vremena da prođe od pojave IE5.0 koji je prvi ponudio mogućnost korišćenja ajax-a do toga da široke web developerske mase počnu da koriste isti.
Poslednjih meseci na svim iole posećenijim forumima ili blogovima ljudi koji se bave web developing-om, skoro svaka druga napisana reč je ajax. Naravno kao i u svakoj priči, postoje ljudi koji se oduševljavaju, i oni koji na sve gledaju sa rezervom, zatim oni koji pljuju ove prve, i neki sasvim treći koji uzvraćaju , braneći prve...
Sve u svemu mnogo se priča o ovome. I mislim da je to dobro.
Kao i posle svake revolucije , web developeri će , ukoliko uvide dobre strane ajax-a, početi da ga upotrebljavaju u svim situacijama. Gde je to moguće i gde je nemoguće, gde je potrebno i gde nije potrebno. Bar je tako do sada bilo sa svim novim stvarima.
Ono što mene lično nervira u ovakvim situacijama, je to što će , iako se zna u ovakvoj klijent-server (web browser – web server) arhitekturi šta treba da budu odgovornosti klijenta, a šta servera da nastane totalna zbrka, u kojoj se ne zna ko šta radi. Kad kažem „da se znaju odgovornosti“, naravno da mislim na postojeće design pattern-e. Kad kažem da će “da nastane zbrka”, naravno da mislim na to da će mnogi ponovo da izmišljaju toplu vodu, i da neće uspeti da je izmisle.
Posledica toga će biti da će više od pola započetih projekata (web aplikacija) opet da propadne, pola ostatka da se završi sa gomilom bug-ova i probijenim terminima, pola preostalog dela ostatka da se završi „uspešno” ... naravno , ne kažem da je do sada situacija u softverskom poslu bila bolja što se izvršenja zadataka tiče, već da to da je spisak tehničkih razloga za propadanje sw projekata verovatno dobio još jednog velikog člana.
Šta je u stvari problem?
Pa problem je u tome kako naći pravu meru izmedju dve krajnosti. Između toga da se sve dešava na serveru (klijent samo prikazuje od jednom dobijeni sadržaj) i toga da je klijent toliko pametan da zna šta mu treba i kada mu to treba i da se u tim situacijama obrati serveru i zatraži to od njega.
Prva varijanta je ona od koje se krenulo. Ona koja se koristila na početku web priče. Vremenom su se odredjene odgovornosti prebacivale na stranu klijenta. JavaScript je postao idealna stvar za skoro svaku vrstu validacije, kao i za druge klijentske poslove vezane za prikaz sadržaja. Ubrzani rast sposobnosti klijentske strane da obradjuje podatke, vrši validacije, prikazuje podatke, vuče web priču ka gore pomenutoj , drugoj varijanti.
Druga varijanta na prvu loptu zvuči super, ali se u njoj krije dosta toga.
Prvo, ne možete biti sigurni da svaki browser podržava vaš pametni klijentski kood iz onog ili ovog razloga, i drugo, bitnije, je to što ovakav pristup može da dovede do narušavanja osnovnih principa klijent-server arhitekture i da bude uvod u propast.
