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

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

Quando ero al college della comunità, il Personal Computer stava diventando un toccasana. Ma Ethernet non era ancora molto diffuso e nessuno aveva una rete locale. A quei tempi, il college aveva un mainframe che gestiva i registri degli studenti e fungeva da piattaforma per programmare le lezioni. L'amministrazione aveva terminali che erano collegati al mainframe su una base di condivisione del tempo, ma gli studenti dovevano prendere a pugni le carte per portare a termine i loro compiti di programmazione, un processo arduo. Alla fine, hanno messo in un laboratorio dove gli studenti potevano iscriversi per un certo tempo su un terminale, ma ci volevano ancora circa mezz'ora per ottenere la stampa di errori di mezzo pollice. 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 passò dal server alle singole macchine client, che erano abbastanza potenti da eseguire singole applicazioni di elaborazione testi, fogli di calcolo e linee di business, ma non abbastanza potente da condividere la loro potenza di elaborazione con gli altri. Il server era una macchina simile con capacità simili (forse più memoria e spazio su disco rigido), ma era principalmente usata per condividere file. Questo era chiamato Client / Server. La maggior parte dell'elaborazione è stata spostata sui computer client.

Uno degli svantaggi di eseguire tutta l'elaborazione sui computer client è stato il blocco di questo ciclo perpetuo di installazione e aggiornamenti del software e tutti i mal di testa che ne derivano. Il modello di programmazione di queste macchine (interfacce utente basate su eventi e code-behind) ha incoraggiato la creazione di programmi disordinati, difficili da mantenere (grandi palle di fango). La maggior parte degli utenti finali non aveva le competenze per mantenere correttamente l'hardware e il software, rendendo necessario l'intervento di personale addetto alla manutenzione IT.

Quando i computer divennero sempre più potenti, divennero possibili le divisioni del lavoro. Ora potresti avere file server, 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 gestita da qualcuno con le competenze necessarie. È possibile scrivere programmi eseguiti nel browser Web, quindi le installazioni client non sono più necessarie. Questo è stato chiamato Multi-Tier o n-Tier. I browser erano essenzialmente usati come terminali stupidi, proprio come nei giorni mainframe, anche se il metodo di comunicazione con il server era più sofisticato, meno proprietario e basato su meccanismi di interruzione piuttosto che su time-sharing e polling. L'elaborazione è stata spostata di nuovo sul / sui server.

Tuttavia, lo sviluppo web è venuto con una nuova serie di mal di testa. La maggior parte delle applicazioni commerciali 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à dei browser che hanno scoraggiato la sua adozione diffusa. 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 può essere utile Javascript. Sono emersi nuovi framework di interfaccia utente front-end. È diventato possibile scrivere interfacce utente altamente interattive nel browser, persino completare i giochi. L'elaborazione è tornata di nuovo al client.

Oggi puoi acquistare potenza di elaborazione nel cloud, nel modo più o meno opportuno, ed eseguire programmi sul server. Direi che siamo ora in un posto dove, come sviluppatore di software, hai molte scelte su dove poter eseguire la tua potenza di elaborazione, sia sul client che sul server.

Sembra che tu stia mescolando due concetti molto diversi:

1. Separazione della presentazione e della logica aziendale (MVC) = > aumentare la manutenibilità
2. Assegnazione dell'esecuzione a un nodo = > aumentare l'efficienza

Indietro nei giorni Il computer client / server era spesso confuso per implicare il primo perché i clienti in genere non offrivano molta potenza di calcolo, rispetto ai server. Quindi è sembrato naturale spostare la "pesante" computazione 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) per tradurre tra i due.

Con i clienti che ora hanno facilmente a che fare con le abilità dei processi che una volta implicavano un costoso hardware del server, le linee sono sfocate 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 trade-off, ad esempio:

• latenza del client v.s. Complessità: l'elaborazione lato server semplifica i sistemi perché non è necessario distribuire / scaricare codice sul client, ma a costo della latenza lato client durante il calcolo.

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

• resilienza delle applicazioni decentrata v.s. esecuzione centrale: in un mondo di app per dispositivi mobili, potrebbe essere importante mantenere i client in funzione nonostante una disconnessione dalla rete. Tuttavia, ciò comporta il costo della gestione di più versioni distribuite della logica aziendale.

Questo è un elenco non esaustivo di molti compromessi.

Perché gli utenti hanno sempre desiderato la stessa funzionalità, campane e fischietti con le loro app Web (non solo i siti Web) che avevano con le app desktop. Rendere tutto questo eseguito in un browser (in realtà più browser) non è come ai vecchi tempi in cui era possibile collegare un modulo VB a un database con un piccolo codice. Questo è più facile da realizzare quando non devi fare viaggi di nuovo sul server.

most backend development using programming languages such as Java or C# is simply to produce a REST-like interface, and that all the hard effort of display, visualization, data input/output, user interactions, etc... are being addressed via client-side framework like Angular, Backbone, Ember, Knockout, etc...

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

Today, in most projects that I am on, I found out that JavaScript frameworks and client-side development is where all the exciting and innovative progresses are being made.

Why has this movement from server to client-side development taken place?

Ci sono in realtà due domande qui:

1. Perché la programmazione lato client è in corso?
2. Perché le applicazioni scritte vengono eseguite sul client anziché sul server?

I due sono in realtà distinti.

Perché la programmazione lato client è in corso?

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

Lo sviluppo front-end era difficile . Dovevi programmare per i browser - sempre un ambiente ostile - usando le funzionalità vincolate di ECMAScript 3, in un ecosistema che non aveva arte o strumenti per la creazione di applicazioni thick-client. Non c'erano caricatori di moduli. Non è possibile gestire correttamente le dipendenze. C'era una scarsità di strumenti per sfilacciare. I quadri erano immaturi e gli innovatori di bassa reputazione di fascia bassa del front-end 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 la loro esecuzione in modo coerente.

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

Perché le applicazioni scritte vengono eseguite sul client anziché sul server?

Ci sono molte cause prossime, ma il più distinto degli ultimi anni è l'ascesa degli smartphone.

Gli smartphone rendono il computing moderatamente potente economico, onnipresente e utile. Sono posseduti da miliardi di persone in tutto il pianeta e hanno essenzialmente portato l'informatica alle classi medie delle economie emergenti. Ma le reti mobili sono lente, frammentarie e costrette da problemi rigidi geografici, ingegneristici e politici. In questo ambiente, è inevitabile che le applicazioni memorizzino lo stato localmente e correggano 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 di stato dovrebbe essere asincrona e fallibile. Ogni carico di contenuto sarebbe costato preziosi centesimi. Dovresti investire in enormi server farm con uptime di cinque-nove. I costi di elaborazione saranno sostenuti direttamente da te, quindi un'improvvisa ondata di popolarità potrebbe in realtà assorbire il tuo business.

Le applicazioni 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 lasciano andare via con tempi di inattività e scarsa connettività di rete. Rendono il codice del server così stupido da poter essere memorizzato nella cache stessa dell'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 mid-power ed evita gli alti costi di elaborazione centralizzata ad alta potenza.

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

What I want to know is, why did we make such a transition (from the emphasis of server-side programming to client-side, ... all of these seem to have occurred simultaneously) and what problems did this transition/shift solve?

Robert Harvey ha dato una risposta eccellente.

... from favoring compiled languages to scripting languages,

Le lingue di scripting offrono molti vantaggi (also ) su lingue compilate, ad esempio:

• sono più facili da imparare e utilizzare
• elimina il tempo di compilazione (sviluppo più veloce)
• fornire più funzionalità (controllo applicazioni di fascia più alta)
• consente modifiche rapide al codice in esecuzione
• ecc.

... from imperative to functional programming,

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