Ena izmed stvari, ki se mi je v razvojnem svetu v zadnjih nekaj mesecih zdela zanimiva, je, kako se sodobne aplikacije premikajo nazaj k umestitvi več inteligence v odjemalca namesto v strežnik. Model odjemalec-strežnik seveda ni nič novega: to je način, kako se že leta gradijo tradicionalne aplikacije, z bogatimi odjemalci pa se pogovarjajo s strežniškimi aplikacijami. Toda v dobi spleta in celo spleta 2.0 se je poudarek preselil na spletne aplikacije, v katerih je bila večina inteligence na spletnem strežniku (običajno na aplikacijskih strežnikih, ki temeljijo na Javi), odjemalec pa je bil le preprosta spletna stran v brskalnik, kamor ste vsakič, ko ste kliknili, naložili novo stran.
Toda v zadnjem času je zorenje HTML5, CSS in še posebej JavaScript vodilni razvijalci, ki v samo spletno stran umeščajo resnično inteligenco in resnično obdelavo. Zlasti smo videli porast različnih okvirov na strani odjemalca, ki temeljijo na JavaScript, ki olajšajo ustvarjanje inteligentnih sprednjih delov, ki popolnoma delujejo v sodobnem spletnem brskalniku. Vključeni brskalniki so običajno tisti, ki temeljijo na mehanizmu Webkit, vključno s Chromeom in Safarijem, vendar se zdi, da je večina aplikacij tudi v trenutnih različicah Firefoxa in Internet Explorerja v redu. Na koncu imate bolj zapleteno spletno stran, ki se dinamično spreminja in po potrebi potegne podatke s strežnika.
Zdi se, da zlasti največ pozornosti pritegnejo trije okviri MVC: Backbone.js, Ember.js in Angular.js. (MVC pomeni krmilnik modela-pogleda - v bistvu gre za arhitekturo, ki stoji za računalništvom spletnega odjemalca. "Js" pomeni JavaScript.) V bistvu je to vse odraščanje pristopa AJAX (asinhroni JavaScript in XML), priljubljenega v zadnjem desetletju oz. tako, vendar postaja veliko bolj zrel in skoraj standardiziran. Ideja je, da se v brskalnik postavi več stanja in obveščevalnih podatkov, nato pa se brskalnik poveže z API-ji REST na strani strežnika.
Hrbtenica je morda najosnovnejši in minimalni od teh okvirov; Uporablja se na različnih koncih na številnih priljubljenih spletnih mestih. Ember je izrasla iz okvira, imenovanega Sproutcore, ki ga je podprl Apple, in je veliko bolj celovit okvir, zasnovan tako, da lahko uporabljate namizne aplikacije. Pogosto se uporablja pri Bootstrapu - nabor predlog za HTML in CSS, ki so jih prvotno ustvarili zaposleni na Twitterju. Angular je Googlova alternativa, ki se zdi, da je nekje vmes - nekateri mislijo, da je nekoliko bolj prilagodljiva ali vsaj "manj samozadovoljna" od Emberja, vendar bolj obsežna kot Backbone. (Upoštevajte, da Google pritiska na razvijalce, naj uporabijo Angular za izboljšanje kakovosti kodiranja, vendar interno dejansko uporabljajo drugačen, zaščiten nabor okvirov.) Tudi Microsoft je za te okvire dodal kljuke v Visual Studio.
Ker gre za splet, obstaja več deset možnosti. Eden bolj zanimivih, ki sem ga slišal v zadnjem času, je Meteor, zasnovan za delo z JavaScript na strani odjemalca in strežnika. A to je še zelo zgodaj in še ne vem nobenega pravega uporabnika. Medtem se več razvijalcev igra z Node.js, ki se pogosto uporablja za implementacije JavaScript na strani strežnika.
Prednost takšnih okvirov se zdi jasna. Bogate aplikacije za spletne odjemalce so močnejše od aplikacij za tanke odjemalce, kjer vse deluje na strežniku, lahko nudijo boljši uporabniški vmesnik in ponujajo možnost informacij brez povezave. S pomočjo teh okvirov lahko ustvarite bogate aplikacije za spletne odjemalce veliko hitreje, kot bi lahko, tako da vse zgradite iz nič in izkoristite prednosti skupnosti, ki se razvijajo okrog njih.
Morda je najpomembneje, da lahko ustvarite mobilne aplikacije, ki obsegajo različne naprave, ne da bi morali pisati posebne izvorne aplikacije. Za domače aplikacije je še vedno dober argument, ki lahko bolj neposredno obravnava posebne značilnosti vsake platforme. Vendar pa je veliko razvijalcev ugotovilo, da takšni okviri lahko drastično pospešijo razvoj platform, zlasti če se uporabljajo v povezavi s stvarmi, kot je PhoneGap, odprtokodni mobilni okvir, ki ga je kupil Adobe in ki je na voljo v projektu Apache Cordova.
Seveda mobilnost prinaša svoje omejitve, vključno s hitrostjo procesorjev in morda še pomembneje, hitrostjo in včasih pomanjkanjem povezljivosti. Eden od razlogov, da so ljudje všeč aplikacije na spletnih straneh, je, da lahko pogosto prenesete osnovno funkcionalnost prek Wi-Fi-ja ali hitre povezave in samo dobite potrebne podatke, ne pa celotnega dizajna. Paketi, kot je PhoneGap, to težavo rešijo tako, da JavaScript prenesejo v preneseno aplikacijo.
Obstajajo pa tudi druge težave s takšnimi okviri. Po definiciji je več računalništva na strani odjemalca poveča zapletenost v primerjavi s preprosto aplikacijo samo za strežnik in res se nekatere pomanjkljivosti starega modela odjemalec-strežnik povrnejo. Razvijalci morajo upravljati stanje na obeh straneh. Koda na dveh mestih pomeni, da se morate na obeh mestih osredotočiti na varnost. Ker ima razvojni tim pogosto ljudi, ki delajo na odjemalcu in druge na strežniku, imate dodatne težave s komunikacijo. Po drugi strani se nekatere starejše izdaje odjemalca-strežnika ne vrnejo in namesto tega ohranite prednosti spletne programske opreme. To je veliko bolj usmerjen svet, ki ga vodi skupnost, zato niste tako odvisni od enega samega lastniškega okolja. Z delitvijo odjemalca in delov na strani strežnika imate lahko tudi čistejšo in enostavnejšo izvedbo na strani strežnika, ki samo obdelavo in ne uporabniški vmesnik, zato bo morda potrebno manj sredstev. Še vedno pa imate prednost, ker lahko posodobite vse stranke hkrati, saj običajno brskalnik naloži kodo s strežnika, ko se prikliče aplikacija.
Očitno vidimo premik k inteligentnejšim spletnim odjemalcem - ne v vsakem primeru, ampak v številnih novih aplikacijah. Mnogo težje je sprejeti starejše aplikacije in jih premakniti na ta model, vendar opazimo tudi nekaj tega. Ne gre za povsem stari model odjemalec-strežnik, vendar se še približuje.
