Esistono attualmente diversi approcci per la creazione di applicazioni Web:

1. Solo lato server

Questo è un approccio classico in cui si esegue il rendering di pagine sul server da un framework Web come Ruby on Rails, Django, Express, Play! Quadro ecc.

Flusso di lavoro tipico : crea tutta la logica aziendale, i modelli e visualizza i modelli sul server nel quadro che preferisci.

2. Lato client + API REST

Relativamente non molto tempo fa, la comunità web nel suo insieme ha iniziato a creare applicazioni lato client in Angular, Backbone, Ember e alcune decine di altri framework JavaScript MV *. E ora abbiamo anche React.js che si unisce alla festa.

AGGIORNAMENTO : non ci sono malintesi. Quello che intendevo solo per lato client è la completa separazione delle preoccupazioni. Hai un server API REST e un'applicazione sul lato client che comunica con quel server. A seconda del caso d'uso, è probabile che non avrai mai una vera applicazione solo lato client che non si connette a un back-end né per autenticazione né persistenza dei dati.

Flusso di lavoro tipico : trascorri ore decidendo su Angular vs Backbone vs Ember vs X. Quindi costruisci i tuoi percorsi, modelli, viste, controller sul client. Al termine, ora crea modelli, controller, route sul server. In un certo senso stai facendo una doppia quantità di lavoro.

3. Ibrido

Non so molto sull'uso di questo approccio, ma se dovessi fare un'ipotesi, visualizzi le tue visualizzazioni (Vista del framework MVC) sul server. Di conseguenza, ottieni supporto SEO oltre a carichi di pagina più rapidi.

Sul fronte Hybrid c'è il rendr di airbnb che presumibilmente combina la spina dorsale e si esprime insieme.

Eric Florenzo ha pubblicato oggi sul suo blog: React: Finalmente un grande stack web server / client .

La quantità di modi per creare applicazioni Web è semplicemente travolgente. E per qualcuno che sta imparando lo sviluppo web questo può diventare un problema. Come si decide quale approccio utilizzare per costruire la loro prossima applicazione?

Penso che tu abbia completamente frainteso il "Solo lato client".

Innanzitutto dovrebbe essere etichettato "Client Centric". L'intero punto di framework come Angular è che le parti "VC" di MVC sono implementate interamente nel browser in Javascript. La logica di livello superiore "M" della parte "M" - il Modello - è implementata nel browser e la logica "CRUD" di livello inferiore è implementata sul server.

La logica aziendale viene sviluppata una volta. La logica della vista viene sviluppata una volta. La logica di controllo viene sviluppata una volta, tutto nel framework di scelta Javascript. Anche la logica di accesso ai dati viene sviluppata una sola volta, ma questa volta su qualsiasi framework RESTy o SOAPy scelto sul lato server.

In casi estremi è possibile implementare il Modello interamente nel client, se è accettabile accedere ai dati da un solo browser su una macchina, e fare in modo che i dati vengano cestinati ogni volta che si seleziona l'opzione "Cancella cookie".

La risposta alla domanda è che dipende dai requisiti. Uno sguardo almeno superficiale alla storia dello sviluppo del "web" indica una cultura da cowboy in cui si trascura spesso parlare con le parti interessate, i clienti, la raccolta dei requisiti.

Ho avuto la fortuna di partecipare a un discorso alcuni anni fa in cui ho sentito qualcosa che mi ha davvero colpito: "scegli il design per soddisfare i requisiti, non i requisiti per soddisfare il design". Quindi, di fronte a una domanda come questa, devi scoprire cosa è realmente necessario alle persone che ti stanno chiedendo di creare questo software.

Il tuo compito è quello di spiegare i pro ei contro dietro ogni approccio.

Penso che uno dei punti chiave dei nuovi approcci e quadri sia che c'è meno accoppiamento tra le tecnologie front-end e le tecnologie back-end.

L'idea è che è possibile utilizzare qualsiasi framework sul client ed estrarre dati e / o viste da qualsiasi numero di origini indipendentemente dal framework lato server.

Questo ci consente di scegliere gli strumenti migliori per svolgere il lavoro e le nostre scelte possono evolversi in modo indipendente.

Certo, non ho usato Angular o Backbone, quindi non posso formulare raccomandazioni con esperienza. Il mio attuale stack di base è costituito dal mvc lato server più sottile o dai servizi riposanti che riesco a trovare. Fornisce principalmente modelli e dati. I dati vengono renderizzati e / o successivamente recuperati dal lato client utilizzando principalmente semplicemente javascript, jquery e css.

Comincio da qui e ci costruisco dove ho bisogno. I vantaggi di questo approccio sono evidenti quando si pensa al supporto di più piattaforme client: browser, dispositivi mobili, ecc. Se è necessario un rendering specifico del client, non è necessario apportare modifiche sostanziali sul lato server.