Newsgroup: it.lavoro.informatica
Titolo: Re: [.NET] Conviene lavorare su Sharepoint e Dynamics?

 I miei interessi sono per lo più orientati al frontend (mi piacerebbe lavorare su ultime versioni di MVC ed in particolare i diversi framework client javascript)
 >
Perdona la curiosità, ma che ci trovi di interessante nell'usare fw che 
cambiano ogni 3 mesi?
 

 cambiano ogni 3 mesi?
 
è inutile che lo chieda a tutti. è un discorso che abbiamo già affrontato,
a te provoca scompensi ma molte persone apprezzano che un progetto sia
manutenuto e sviluppato con continuità. i framework possono avere
aggiornamenti anche più frequenti che ogni tre mesi ma tendenzialmente
quelli che rompono la compatibilità non sono di sicuro più frequenti 
di quelli dei framework che usi te. infatti su questo ci sarebbe molto
da discutere, ma molto.
 
 


Mah, estremizzo così si capisce meglio.
Prendi sul cloud un'archittetura che scala in base al carico, ci metti 
sopra un bel terminal server e dentro ci fai il classico gestionale che 
gira con Access come front/end e lato dati quello che ti pare, ma fatto 
pure a strati con la logica che sta per conto suo.
Ora fissi un tempo x e vedi che quel tempo è per il 90% dedicato agli 
aspetti funzionali e il resto all'implementazione e il risultato finale 
non fa certo cagare, anzi. E ci arrivi con tablet, smartphone, pc.
Poi magari ti fai un fw in casa che ti fa il rendering in base al 
dispositivo che si attacca, ma scrivi tutto lato server con le comodità, 
facilità, robustezza del caso, per lo sviluppo e il debug.
 
Che brutto scenario vero? Ci sarebbe un bel po' di gente che dovrebbe 
smettere di scrivere libri, far corsi, e creare nuovi fw un mese si e 
l'altro pure.
E ci sarebbero pure applicazioni che per l'utente funzionano meglio e 
con costi accettabilissimi.
 

 Mah, estremizzo così si capisce meglio.
 
le tue "idee" architetturali erano già chiare e non voglio tornarci sopra che
tanto sarebbe fiato, anzi banda sprecata. ti lascio alla convinzione
che la tua idea sia geniale e che non se la fila nessuno per il solito
"gomblotto", questa volta della pericolosa casta di quelli che scrivono
libri e fanno corsi.
 
 

 libri e fanno corsi.
Mai parlato di complotti.
Vedi te con la banda che migliora in continuazione se non si finirà li...
Io dico che fra un 10/15 anni tutto si risposta pesantemente lato 
server, generazione della UI compresa.
 
 

 server, generazione della UI compresa.
 
provo una sincera ammirazione per la convinzione con cui fai queste
previsioni, davvero. però non è che basta. quando uno fa una previsione 
di questo tipo dovrebbe farlo sulla base di elementi attuali che la
supportano, altrimenti non si chiamano più previsioni ma divinazioni (per
chi crede al paranormale, illazioni per tutti gli altri). sinceramente
l'affermazione che in 10/15 anni scomparirà l'http a favore di un rdp o 
quel che sarà mi pare un po' fortina,  così come la tesi della banda "che
migliora in continuazione" è un po' deboluccia. negli ultimi 15 anni la
disponibilità di banda è cresciuta più o meno raddoppiando ogni 3 anni
eppure il trend delle applicazioni è diametralmente opposto. se dobbiamo
discuterne nei termini di "tanto non c'è controprova" allora diciamo anche
che fra 15 anni avremo tutti le orecchie a punta e la proboscide. ecco,
con la tua previsione siamo su questi livelli.
 

 con la tua previsione siamo su questi livelli.
Pensa quel che vuoi, intanto segnatela però... :-D
 
 

 Pensa quel che vuoi, intanto segnatela però... :-D
 
si si, insieme agli orecchi a punta e la proboscide.


No no, quella è una fesseria. L'altra no.
 

 No no, quella è una fesseria. L'altra no.
 
seriamente, adesso basta scherzare: hai detto una stronzata immonda. 
anche te segnati questa. 


Mo me la segno, tranqui.
 

 più funziona meglio grazie appunto al miglioramento della connettività?
 
Parli di generare l'html lato server e spedirlo al client as it is, il quale poi si preoccuperà semplicemente di rimpiazzare il pezzo html tramite un semplice innerHtml o simili? Questo è ad esempio l'approccio che JSF.
Che dire, funziona e svilupparci su è abbastanza semplice. 
Ci sono però svariati problemi, come ad esempio il fatto che scala male lato server. Infatti se una pagina JSF ha migliaia di componenti i risultati si vedono (cioè la pagina diventa pesante). Un altro problema che vedo è che hai poco controllo sull'interfaccia.
Inoltre sarà pure vero che la connettività va migliorando in genere, ma l'entrata dei dispositivi mobile rende la questione alquanto delicata. In alcuni casi i byte si pagano (o consumano il fisso mensile) e se un'interazione AJAX con JSF consuma decine/centinaia di migliaia di byte, è possibile che una soluzione JSON sia molto più leggera.
 
Morale se devi fare un'intefaccia in velocità per una clientela ristretta e controllata (quella "enterprise") puoi anche vivere felice così. Se non hai questo "privilegio", direi che rischi di produrre applicazioni di non altissima qualità. Sta a te decidere cosa conviene.

 gradi di quello che si sta discutendo?
 
non voglio fare a chi ce l'ha più lungo. in un dibattito tecnico 
l'autorevolezza di una opinione si misura sulla base della qualità
delle argomentazioni che ciascuno mette sul piatto. ed è sulla
base di questo che sostengo sul tema in discussione di saperne più di te. 
non c'è problema, sei sempre in tempo a smentirmi, ma fintanto che
continui a fare il pierino deridendo il lavoro dei tuoi colleghi sei
fuori strada.

 Parli di generare l'html lato server e spedirlo al client as it is, il quale poi si preoccuperà semplicemente di rimpiazzare il pezzo html tramite un semplice innerHtml o simili? Questo è ad esempio l'approccio che JSF.
 
non credo. l'html poi deve essere renderizzato, così come l'interazione
utente e la manipolazione successiva del dom gestiti dal javascript più o 
meno nascosto al programmatore, e queste
cose lui sostiene di non volerle. parla di una interfaccia che arriva al
client già renderizzata stile rdp o vnc, ma non si è capito di quale 
tecnologia stia parlando. sostiene inoltre che questa fantomatica tecnologia
soppianterà il browser in 10/15 anni. 
però non vuole dirci di quale tecnologia parli.


Beh, se mi sfanculi rispondo di conseguenza, i miei messaggi nascono 
dalla curiosità, poi se uno se la prende pazienza.
 


Questa fantomatica tecnologia ora non c'è. Pensavo come detto enne volte 
ad una evoluzione della modalità terminal-server con le caratteristiche 
che ho già scritto.
Tutto insomma per evitare di diventare pazzi dietro a js, html e css e 
gli enne browser + enne fw che circolano.
 
 
 

 gli enne browser + enne fw che circolano.
 
Se fossi in te mi metterei a studiare invece di fantasticare di mondi che non esistono e mai esisteranno.


Motivi? Sul fatto che non esisteranno.
 


Aggiungo anche un'altra domanda.
Se html + css + js son così robusti come risposta, perché esistono le 
app per ios e android quando invece sarebbe sufficiente usare i loro 
browser?

 nuove versioni spendendoci sopra quanto tempo?
 
il mio gruppo da tre anni circa lavora con angular + bootstrap con la 
stessa formazione di tre anni fa. l'unica rottura di compatibilità si
è avuta passando da bootstrap 2.x a 3.x, ma nessun programmatore con un
qi nella media impiega più di qualche ora ad assimilare i cambiamenti. 
qualche ora in tre anni io dico si può accettare.


ti rigiro io la domanda: perché esistono una miriade di tools per lo
sviluppo multipiattaforma di app mobile native basati su html5?
 
a titolo di esempio e senza la pretesa di essere esaustivo:
http://ionicframework.com/
 
http://cordova.apache.org/
 
https://appery.io/