Actualmente existen múltiples enfoques para crear aplicaciones web:

1. Solo del lado del servidor

Este es un enfoque clásico en el que representa páginas en el servidor mediante un marco web como Ruby on Rails, Django, Express, Play! Marco y etc.

Flujo de trabajo típico : cree toda su lógica empresarial, modelos y plantillas de vista en el servidor en el marco de su elección.

2. API del lado del cliente + REST

Hace relativamente poco tiempo, la comunidad web en su conjunto comenzó a construir aplicaciones del lado del cliente en Angular, Backbone, Ember y algunas docenas de otros marcos JavaScript MV *. Y ahora también tenemos React.js unirse a la fiesta.

ACTUALIZACIÓN : No hay malentendidos. Lo que quise decir solo con el lado del cliente es la separación completa de las preocupaciones. Tiene un servidor API REST y una aplicación del lado del cliente que se comunica con ese servidor. Dependiendo de su caso de uso, lo más probable es que nunca tenga una verdadera aplicación solo del lado del cliente que no se conecte a un back-end para autenticación o persistencia de datos.

Flujo de trabajo típico : pase horas decidiendo Angular vs Backbone vs Ember vs X. Luego construye sus rutas, modelos, vistas, controladores en el cliente. Una vez que haya terminado, ahora cree modelos, controladores, rutas en el servidor. En cierto modo, estás haciendo el doble de trabajo.

3. Híbrido

No sé mucho sobre el uso de este enfoque, pero si tuviera que adivinar, representaría sus vistas (Vista del marco MVC) en el servidor. Como resultado, obtienes soporte SEO y cargas de página más rápidas.

En el frente híbrido hay un reproductor de airbnb que supuestamente combina backbone y express.

Eric Florenzo ha publicado en su blog hoy: Reaccionar: Finalmente, una gran pila web de servidor / cliente .

La cantidad de formas de crear aplicaciones web es abrumadora. Y para alguien que está aprendiendo desarrollo web, esto puede convertirse en un problema. ¿Cómo se decide qué enfoque usar para construir su próxima aplicación?

Creo que ha entendido totalmente mal el "lado del cliente solamente".

En primer lugar, debe etiquetarse "Cliente centrado" Todo este punto de marcos como Angular es que las partes "VC" de MVC se implementan completamente en el navegador en Javascript. La lógica de nivel superior "M" de la parte "M" - el Modelo - se implementa en el navegador y la lógica de "CRUD" de nivel inferior se implementa en el servidor.

La lógica de negocios se desarrolla una vez. La lógica de vista se desarrolla una vez. La lógica de control se desarrolla una vez, todo en el marco de elección de Javascript. La lógica de acceso a datos también se desarrolla solo una vez, pero esta vez en cualquier marco RESTy o SOAPy que elija en el lado del servidor.

En casos extremos, puede implementar el Modelo completamente en el cliente, si es aceptable acceder a los datos desde un solo navegador en una máquina, y hacer que los datos se eliminen cada vez que se selecciona la opción "Borrar cookies".

La respuesta a la pregunta es que depende de los requisitos. Una mirada al menos superficial a la historia del desarrollo de la "web" indica una cultura vaquera en la que a menudo se pasa por alto hablar con las partes interesadas, los clientes y la recopilación de requisitos.

Tuve la suerte de asistir a una charla hace algunos años donde escuché algo que realmente me quedó grabado: "eliges el diseño para cumplir con los requisitos, no los requisitos para cumplir con el diseño". Entonces, cuando se enfrenta a una pregunta como esta, debe averiguar qué es lo que realmente necesitan las personas que le piden que cree este software.

Su trabajo es explicar los pros y los contras detrás de cada enfoque.

Creo que uno de los puntos clave de los enfoques y marcos más nuevos es que hay menos acoplamiento entre las tecnologías front-end y las tecnologías back-end.

La idea es que puede usar cualquier marco en el cliente y extraer datos y / o vistas de cualquier número de fuentes, independientemente del marco del lado del servidor.

Esto nos permite elegir las mejores herramientas para hacer el trabajo y nuestras elecciones pueden evolucionar independientemente.

Es cierto que no he usado Angular o Backbone, por lo que no puedo hacer ninguna recomendación con experiencia. Mi pila base actual consiste en el mvc más delgado del lado del servidor o los servicios relajantes que puedo encontrar. Principalmente entregando plantillas y datos. Los datos se procesan y / o los datos posteriores se recuperan del lado del cliente utilizando principalmente javascript, jquery y css.

Comienzo aquí y construyo sobre él donde necesito. Los beneficios de este enfoque son evidentes cuando piensa en admitir múltiples plataformas de clientes: navegador, móvil, etc. Si necesita una representación específica del cliente, no debería necesitar hacer cambios masivos en el lado del servidor.