Javascript vs PHP
Venerdì 21 Luglio, 2006Corre voce che attualmente è in corso una discussione sull’uso di Javascript come costruttore di contenuti HTML. In particolare il dilemma assilla l’universo Ajax. Sotto questa sigla si cela un metodo che permette di contattare il Web Server tramite script Javascript, senza che il browser debba ricaricare l’intera pagina con il conseguente - e fastidioso - “fliker” video.
Il fatto che questa tecnica permetta di comunicare con il Web Server significa, in pratica, che si possono inviare - e ricevere - informazioni dal Web Server senza che l’utente - di fatto - se ne accorga! Su quest’ultima affermazioni sarebbe il caso di aprire una discussione a parte.
Tornando alla nostra questione la domanda principale è la seguente: una volta ricevuta la risposta dal Web Server chi deve costruire l’impalcatura HTML tale da poter inserire la risposta nella pagina corrente? Lo deve fare il Web Server al momento dell’invio della risposta o è un compito demandato a Javascript lato client ?
In pratica c’è chi sostiene che il modo migliore è quello di far impacchettare la risposta completa direttamente lato server; così che il client Javascript deve solo prendere ed inserire (get & insert). Altri, invece, sostengono che la cosa migliore sia ricevere i dati spuri, raw, in una struttura XML magari ed elaborare il tutto lato client, tramite Javascript, e sempre con Javascript creare l’impalcatura HTML necessaria per l’inserimento sulla pagina.
Sembra subito evidente, però, che non è possibile - a priori - sostenere un modello rispetto all’altro. Entrambi, evidentemente, devono essere contestualizzati. E’ possibile che in alcuni casi far impacchettare tutto al Web Server risulti effettivamente la scelta migliore, sia in fase di sviluppo che in velocità di trasmissione.
C’è da dire subito che l’idea di caricare grossi quantitativi di codice Javscript sul client non è una bellissima soluzione. Dico questo in ricordo della scalabilità. Un sistema che si presenta già pesante nelle sue fasi iniziali, ha ben poche possibilità di progredire in tranquillità in futuro. Inoltre le ancor diffuse incomptibilità tra i browser disponibili, quindi lato client, rendono stancante sviluppare codice Javascript troppo articolato. Tuttavia c’è chi lo fa! Indubbiamente.
La morale, ad oggi, con i browser e i sistemi operativi che abbiamo, sembra essere quella che ognuno deve scegliere la propria via, domani si vedrà. Nel nostro sito Web Applick.com, il codice è stato scritto utilizzando entrambi i metodi, a seconda del caso.
Domani, magari, usciranno dei browser con codice preconfezionato a bordo! Verrà sicuramente rivisto il componente HTTPRequest. Per ora questa tecnica deve la sua ri-nascita (vedi uso del TAG IFRAME) sia al minimo standard realizzato sul componente HTTPRequest, alla sua presenza e implementazione nei browser e sia all’aumento di banda-media disponibile ai navigatori Internet. L’HTTPRequest è comunque un subcanale HTTP, ne più ne meno. Inviare un codice XML invece che HTML non fa molta differenza, sniffando la rete ce ne rendiamo subito conto. Forse questi sono lamenti di qualche altra cosa che va al di là della questione Ajax. E’ innegabile che una certa parte della comunità Internet chiede un cambiamento, delle modifiche strutturali. Si è parlato - giustamente - delle connessioni pemanenti, che certo non hanno niente a che vedere con la politica attuale (e originaria) del protocollo HTTP.
La realtà, alla fine, potrebbe essere quella di ammettere che la tecnologia attuale di Internet è superata. I suoi protocolli, ideati per altre velocità di rete e altre condizioni, sono obsoleti.
volevo solo essere sicuro che non ci fosse qualche altro...
undolog » Blog Archive » Web 2.0: no Javascript ha detto:
[...] Web 2.0: no Javascript Tags: Ajax, Internet, Javascript, Sviluppo, web2.0Come 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. [...]