Come già affrontato su “Javascript vs PHP” (o altro: ASP, CFM, …), la questione di inserire o meno un kernel Web2.0 negli script Javascript, invece di lasciarlo – in maggiornaza – lato server, può creare confusione se non sconcerto. Tuttavia ci sono degli ottimi motivi per favorire il server rispetto al client, motivi che non hanno niente a che fare con il Web2.0 che, al contrario, punta i riflettori proprio sugli script Javascript.
Scalabilità e caching
Se Web2.0 significa migliorare l’esperienza sul Web ed avvicinarsi sempre di più ad un uso “applicativo” delle pagine HTML, diventa necessario costruire una serie di strumenti che migliorino l’accessibilità e l’usabilità di una pagina, così da renderla fruibile al pari di una applicazione standard.
Ne segue, che ad oggi, è necessario scrivere framework (lato client e lato server) in grado di superare gli ostacoli e le mancanze intrinseche dell’HTML. Ciò viene realizzato in gran parte sfruttando le innumerevoli potenzialità del linguaggio Javascript interpretato dal browser, che rende possibile una notevole interazionecon il navigatore, permettendo di creare finestre, popup, menu a tendina, drag & drop, e molto altro. Tuttavia ci sono dei limiti all’immaginazione degli sviluppatori, che se non considerati attentamente rischiano di vanificare qualsiasi sforzo in questa direzione.
Uno dei primi ostacoli che si deve superare è la scalabilità di questi sistemi! Scrivere un framework lato Javascript significa creare un ambiente di sviluppo ed operativo estremamente complesso, dopotutto l’oggetto in questione è proprio applicazione! Questo significa che gli aggiornamenti al codice non sono un evento raro, anzi. Abbiamo, quindi, una notevole quantità di codice Javascript che dev’essere scaricato dal server verso il client. Già questo mette in contraddizione il concetto di Web2.0! Se devo scaricare n mega di codice Javascript perchè non scaricare un applicativo, un ActiveX o un filmato Flash?
“Il Web2.0 non dovrebbe avere come regola l’uso di applicazioni remote?”
Non bisogna dimenticare che l’uso delle applicazioni Web è di notevole interesse quando queste sono remote non quando sono locali, altrimenti parliamo di una cosa diversa!
Peggio ancora ci si deve scontrare con il caching dei browser! Quando viene scaricato dal server un codice Javascript normalmente i browser (e qui si apre un universo di impostazioni personali che ognuno di noi può fare sul proprio browser) tendono a posizionarlo in una cache, in una area di memoria locale, così da non doverlo ricaricare durante la navigazione del sito!
Questo aspetto rende difficile mantenere gli aggiornamenti in linea. Può capitare, inaffti, che un browser non ricarichi correttamente un file Javascript perchè già posizionato nella cache. Alcuni sviluppatori usano un hack per forzare il caricamento di un file Javascript, costringendo il browser a caricare ogni volta il file – o i file – di scripting. Tutto ciò, ovviamente, si rivela ben presto una pessima scelta, rendendo il sito estremamente lento.
“Il caching è davvero un problema attualmente, in svariate situazioni!”
Un framework Ajax con le sofisticate funzioni di programmazione non è certo cosa da poco. Chi sviluppa Web2.0 dovrebbe considerare sin dall’inizio la possibilità di espandere il proprio sistema. Da un lato deve mantenere il codice Javascript al minimo, dall’altro deve poter far ricaricare gli scripting quando è necessario.
“Una possibile soluzione è migliorare le comunicazioni browser-server!”
Se i browser avessero maggiori funzionalità a bordo, la questione diventerebbe sicuramente meno gravosa per gli sviluppatori, che si troverebbe con molto meno codice da scrivere e quindi da scaricare.
“Ma questo non è forse uno scenario già presente?”
“Stiamo trasformando i browser in piccoli sistemi operativi?”
Loading ...
4
ho risolto impostando [cc_objc] //OptionViewController.m -...
Non ci sono commenti per questo Post
Lascia un commento