Perché le basi di codice nello sviluppo di livello n hanno una quantità uguale, se non di più, di codice JavaScript ora?

Ho fatto la programmazione web da molto tempo ormai, e da qualche parte, ho perso la traccia del perché stiamo facendo quello che stiamo facendo oggi (o come siamo arrivati ​​a fare le cose in questo modo)?

Ho iniziato con lo sviluppo web ASP di base e molto presto, la pagina e la logica di business erano miste nella pagina. Lo sviluppo sul lato client è variato notevolmente (VBScript, diverse versioni di JavaScript) e abbiamo ricevuto molti avvisi sulle convalide lato server (e quindi sono rimasto lontano dalla logica lato client).

Mi sono quindi trasferito a ColdFusion per un po '. ColdFusion è stato probabilmente il primo framework di sviluppo web che ha separato la logica di visualizzazione e di business utilizzando i loro tag. Mi è sembrato molto chiaro, ma molto dettagliato, e ColdFusion non era molto richiesto dal mercato, e così sono passato.

Ho quindi saltato sul carro a banda ASP.NET e ho iniziato a utilizzare il loro approccio MVC. Mi sono anche reso conto che Java sembrava essere un linguaggio torre d'avorio di sistemi aziendali e ho anche provato il loro approccio MVC. Successivamente, ASP.NET ha sviluppato questo modello di progettazione MVVM e anche Java (precisamente, J2EE o JEE) ha faticato ed è uscito con i suoi approcci MVC2.

Ma oggi, quello che ho scoperto è che la programmazione back-end non è più l'eccitazione e il progresso. Inoltre, le pratiche MVC basate sul lato server sembrano essere obsolete (le persone usano davvero più JSTL?). Oggi, nella maggior parte dei progetti in cui mi trovo, ho scoperto che i framework JavaScript e lo sviluppo lato client sono il luogo in cui vengono fatti tutti i progressi entusiasmanti e innovativi.

Perché si è verificato questo passaggio dallo sviluppo lato server a quello lato client? Ho fatto un semplice conteggio delle righe di uno dei miei progetti JEE e ci sono più righe di codice in JavaScript che Java (escluse le librerie di terze parti). Trovo che la maggior parte dello sviluppo back-end usando linguaggi di programmazione come Java o C # sia semplicemente quello di produrre un'interfaccia simile a REST e che tutto il duro sforzo di visualizzazione, visualizzazione, input / output dei dati, interazioni dell'utente, ecc ... siano stati affrontati tramite framework lato client come Angular, Backbone, Ember, Knockout, ecc ...

Durante l'era pre-jQuery, ho visto molti diagrammi in cui c'era una linea chiara e concettuale tra M, V e C in MVC nello sviluppo di livello n. Post-jQuery, dove sono disegnate queste linee? Sembra che MVC e MVVM siano tutti lì nel codice JavaScript, lato client.

Quello che voglio sapere è, perché abbiamo fatto una simile transizione (dall'enfasi della programmazione lato server a quella lato client, dal favorire i linguaggi compilati ai linguaggi di scripting, dalla programmazione imperativa a quella funzionale, tutto ciò sembra essersi verificato contemporaneamente ) e quali problemi ha risolto questa transizione / turno?

Spostare il carico di elaborazione tra il server e il client è un fenomeno ciclico, ed è stato per un bel po 'di tempo.

Quando ero al college della comunità, il Personal Computer stava solo prendendo piede. Ma Ethernet non era ancora ampiamente utilizzata e nessuno aveva una rete locale. All'epoca il college aveva un mainframe che gestiva i record degli studenti e serviva da piattaforma per le lezioni di programmazione. L'amministrazione disponeva di terminali collegati al mainframe in base alla condivisione del tempo, ma gli studenti dovevano perforare le carte per svolgere i compiti di programmazione, un processo arduo. Alla fine, hanno messo in un laboratorio in cui gli studenti potevano iscriversi per un po 'di tempo su un terminale, ma ci sono voluti ancora circa mezz'ora per ottenere una stampa spessa di mezzo pollice di errori. Tutto il lavoro di elaborazione è stato eseguito sul mainframe (il server).

Ma i mainframe erano costosi, quindi le aziende iniziarono a installare reti locali e il carico di elaborazione si spostò dal server alle singole macchine client, che erano abbastanza potenti da eseguire singole elaborazioni di testi, fogli di calcolo e applicazioni line-of-business, ma non abbastanza potenti da condividere la loro potenza di elaborazione con gli altri. Il server era una macchina simile con capacità simili (forse più memoria e spazio sul disco rigido), ma era principalmente utilizzato per condividere file. Questo si chiamava Client / Server. Gran parte dell'elaborazione era passata ai computer client.

Uno degli svantaggi di eseguire tutte le elaborazioni sui computer client è che sei stato bloccato in questo ciclo perpetuo di installazione e aggiornamento del software e di tutti i mal di testa che ne derivano. Il modello di programmazione di queste macchine (interfacce utente basate su codice e basate sugli eventi) ha incoraggiato la creazione di programmi disordinati e difficili da mantenere (grosse palle di fango). La maggior parte degli utenti finali non aveva le competenze per mantenere correttamente il proprio hardware e software, il che richiedeva eserciti di personale di manutenzione IT.

Man mano che i computer diventavano sempre più potenti, divennero possibili divisioni di lavoro. Ora potresti avere server di file, server di database, server Web, server di stampa e così via. Ogni macchina potrebbe essere in qualche modo ottimizzata per l'attività che è stata fornita e mantenuta da qualcuno con le competenze necessarie. È possibile scrivere programmi eseguiti nel browser Web, pertanto le installazioni client non sono più necessarie. Questo era chiamato Multi-Tier o n-Tier. I browser erano essenzialmente usati come terminali stupidi, proprio come ai tempi dei mainframe, sebbene il metodo di comunicazione con il server fosse più sofisticato, meno proprietario e basato su meccanismi di interruzione piuttosto che sulla condivisione del tempo e il polling. L'elaborazione era tornata ai server.

Tuttavia, lo sviluppo web è arrivato con un nuovo set di mal di testa. La maggior parte delle applicazioni della linea di business scritte per il browser erano moduli e report statici. Nell'interfaccia utente era disponibile poca interattività. Javascript non ha ancora trovato il suo secondo vento e ci sono stati grossi problemi con le incompatibilità del browser che hanno scoraggiato la sua diffusa adozione. Tuttavia, le cose sono migliorate molto. HTML5 e CSS3 forniscono nuove e sostanziali funzionalità al modello di programmazione del browser, jQuery è uscito e ha aiutato un'intera generazione di programmatori a scoprire quanto JavaScript potesse essere utile. Sono emersi nuovi framework dell'interfaccia utente front-end. È diventato possibile scrivere interfacce utente altamente interattive nel browser, anche giochi completi. L'elaborazione è tornata al client.

Oggi è possibile acquistare la potenza di elaborazione nel cloud, quanto basta o meno, ed eseguire programmi sul server. Direi che ora siamo in un posto in cui, come sviluppatore di software, hai molte scelte su dove puoi eseguire la tua potenza di elaborazione, sia sul client che sul server.

Sembra che tu stia mescolando due concetti molto diversi:

1. Separare la presentazione e la logica aziendale (MVC) => aumentare la manutenibilità
2. Assegnare l'esecuzione a un nodo => aumentare l'efficienza

Ai giorni precedenti, il calcolo client / server era spesso confuso per implicare il primo perché i client generalmente non offrivano molta potenza di calcolo, rispetto ai server. Quindi è sembrato naturale spostare il calcolo "pesante" della logica aziendale (M) sui server, mantenendo l'elaborazione della vista "leggera" (V) sui client. A sua volta, dovevi implementare una sorta di arbitro (C) da tradurre tra i due.

Con i client che ora mostrano facilmente l'abilità del processo che una volta implicava un costoso hardware server, le linee si sono confuse su dove eseguire la logica di business - lato client o lato server. In realtà, la risposta dipende dal tuo caso d'uso specifico e dalla tua scelta di compromessi, ad esempio:

• latenza del client vs complessità: l'elaborazione sul lato server semplifica i sistemi perché non è necessario distribuire / scaricare codice sul client, tuttavia comporta un costo di latenza sul lato client durante il calcolo.

• complessità vs carico del server: l'elaborazione lato client può aumentare la complessità del sistema ma può anche aiutare a ridurre il carico del server.

• resilienza delle applicazioni decentralizzata vs esecuzione centralizzata: in un mondo di app mobili, può essere importante far funzionare i client nonostante una disconnessione di rete. Tuttavia, ciò comporta il costo della gestione di più versioni distribuite della logica aziendale.

Questa è una lista non esaustiva di molti compromessi.

Perché gli utenti hanno sempre desiderato le stesse funzionalità, campane e fischietti con le loro app Web (non solo i siti Web) che avevano con le app desktop. Far funzionare tutto questo in un browser (in realtà più browser) non è come ai vecchi tempi quando si poteva collegare un modulo VB a un database con poco codice. Questo è più facile da realizzare quando non è necessario tornare al server.

la maggior parte dello sviluppo back-end che utilizza linguaggi di programmazione come Java o C # consiste semplicemente nel produrre un'interfaccia simile a REST e che tutto il duro sforzo di visualizzazione, visualizzazione, input / output dei dati, interazioni dell'utente, ecc ... viene affrontato tramite client- quadro laterale come Angolare, Backbone, Ember, Knockout, ecc ...

Forse la programmazione / i servizi di backend sembrano la stessa cosa vecchia, ma è il cuore dell'applicazione. Le pratiche di codifica possono essere più efficienti in questi settori. Gli strumenti, le lingue, i browser e i framework sono ancora in evoluzione, quindi l'interfaccia utente / UX è difficile da sviluppare. Sono le nuove cose che il vecchio ASP non aveva. Se potessimo cavarcela con le interfacce utente con moduli semplici e tabelle html, non ci sarebbe molto interesse / hype in quelle aree, ma gli utenti vogliono trascinare e rilasciare, animazioni, transizioni, pop-up, ecc.

Oggi, nella maggior parte dei progetti in cui mi trovo, ho scoperto che i framework JavaScript e lo sviluppo lato client sono il luogo in cui vengono fatti tutti i progressi entusiasmanti e innovativi.

Perché si è verificato questo passaggio dallo sviluppo lato server a quello lato client?

In realtà ci sono due domande qui:

1. Perché è la programmazione lato client in cui si stanno verificando progressi?
2. Perché le applicazioni sono scritte per essere eseguite sul client anziché sul server?

I due sono in realtà distinti.

Perché è la programmazione lato client in cui si stanno verificando progressi?

Perché il runtime, l'ambiente e l'ecosistema sono maturati sostanzialmente negli ultimi tre anni e questo ha aperto nuove nicchie che gli innovatori hanno atteso di sfruttare.

Lo sviluppo del front-end era un tempo difficile . Bisognava programmare per i browser - sempre un ambiente ostile - utilizzando le funzionalità limitate di ECMAScript 3, in un ecosistema che non aveva tecniche o strumenti precedenti per la creazione di applicazioni thin client. Non c'erano caricatori di moduli. Non è possibile gestire correttamente le dipendenze. C'era una scarsità di strumenti per la lanugine. I frame erano immaturi e la scarsa reputazione del front-end distanziava gli innovatori che potevano risolvere questi problemi.

Poiché questi fattori sono cambiati in modo incrementale, hanno creato una massa critica per lo sviluppo rapido di applicazioni rich client e l'esecuzione costante.

In risposta alla tua domanda, quindi, non è così tanto che le nuove tecnologie front-end hanno spinto in avanti i progressi, tanto quanto hanno liberato i colli di bottiglia e hanno permesso ai clienti di recuperare il passo con le aspirazioni degli utenti.

Perché le applicazioni sono scritte per essere eseguite sul client anziché sul server?

Ci sono molte cause immediate, ma la più distintiva degli ultimi anni è l'ascesa degli smartphone.

Gli smartphone rendono il calcolo moderatamente potente economico, onnipresente e utile. Sono di proprietà di miliardi di persone in tutto il pianeta e hanno essenzialmente portato il calcolo alle classi medie delle economie emergenti. Ma le reti mobili sono lente, irregolari e vincolate da problemi di natura geografica, ingegneristica e politica. In questo ambiente, è inevitabile che le applicazioni memorizzino lo stato localmente e patch i dati verso l'alto con riluttanza e in operazioni senza stato.

Come potrebbe essere diverso? Immagina se il tuo smartphone fosse solo un terminale stupido. Ogni mutazione dello stato dovrebbe essere asincrona e fallibile. Ogni carico di contenuti costerebbe centesimi preziosi. Dovresti investire in enormi server farm con un uptime di cinque nove. I costi di elaborazione sarebbero sostenuti direttamente da te, quindi un'improvvisa ondata di popolarità potrebbe effettivamente ostacolare la tua attività.

Le applicazioni lato client consentono di gestire lo stato relativo al singolo utente in modo rapido e sincrono. Ti consentono di scaricare i costi di elaborazione per i tuoi utenti. Ti consentono di evitare tempi di inattività e scarsa connettività di rete. Rendono il codice del server così stupido da poter essere memorizzato nella stessa infrastruttura di rete: file HTML e JS statici o risposte predefinite per le app mobili.

Per dirla in termini molto ampi: lo sviluppo lato client sfrutta i bassi costi del personal computing di media potenza ed evita i costi elevati del calcolo centralizzato ad alta potenza.

Hai fatto diverse domande, alcune delle quali hanno già buone risposte. Alcuni non hanno ancora avuto le loro risposte:

Quello che voglio sapere è, perché abbiamo fatto una transizione del genere (dall'enfasi della programmazione lato server a quella lato client, ... tutto ciò sembra essersi verificato contemporaneamente) e quali problemi ha risolto questa transizione / spostamento?

Robert Harvey ha dato un'ottima risposta.

... dal favorire le lingue compilate ai linguaggi di scripting,

I linguaggi di scripting offrono molti vantaggi ( anche ) rispetto ai linguaggi compilati, ad esempio:

• sono più facili da imparare e usare
• elimina i tempi di compilazione (sviluppo più veloce)
• fornire più funzionalità (controllo delle applicazioni di fascia alta)
• consentire rapide modifiche al codice in esecuzione
• eccetera.

... dall'imperativo alla programmazione funzionale,

Ecco un buon confronto, ma vorrei riassumere dicendo che nel software distribuito (pensa al cloud computing), la gestione dei cambiamenti di stato (sincronizzazione tra molti nodi) può essere un grosso problema. Nella programmazione funzionale, la necessità di gestire i cambiamenti di stato è molto più bassa.