¿AngularJS es solo para aplicaciones de una sola página (SPA)?

Estamos buscando opciones para construir el front-end de una aplicación que estamos creando y estamos tratando de evaluar una herramienta que funcione para nosotros y nos brinde la mejor plataforma para avanzar.

Este es un proyecto Node.js. Nuestro plan inicial era usar Express y seguir esa ruta, pero decidimos que antes de comenzar esta etapa, sería mejor revisar lo que hay ahí fuera. Nuestra aplicación tiene varias áreas que no creemos que se ajusten al modelo de una sola página, ya que están relacionadas desde una perspectiva de aplicación, pero no desde una vista.

Hemos visto algunos de los marcos que podríamos usar para construir el cliente como Backbone.js , Meteor , etc. y también AngularJS.

Esta puede ser una pregunta bastante obvia, pero parece que no podemos descifrar si AngularJS es puramente para aplicaciones de una sola página o si puede usarse para aplicaciones de varias páginas como Express, por ejemplo.

ACTUALIZACIÓN 17 de julio de 2013 Solo para mantener a las personas informadas, actualizaré esta pregunta a medida que avancemos en el proceso. Vamos a construir todo juntos por ahora, y veremos qué tan bien funciona. Nos pusimos en contacto con algunas personas que están más calificadas con AngularJS que con nosotros y planteamos la pregunta sobre la división de aplicaciones más grandes que comparten contexto, pero pueden ser demasiado grandes para trabajar en una sola página.

El consenso fue que podríamos servir múltiples páginas estáticas y crear aplicaciones AngularJS que funcionen solo con esas páginas, creando efectivamente una colección de SPA y vinculando esas aplicaciones juntas mediante el enlace estándar. Ahora, nuestro caso de uso es muy específico, ya que nuestra solución tiene varias aplicaciones, y como dije, vamos a probar primero la base de código único y optimizar desde allí.

ACTUALIZACIÓN 18 de junio de 2016 El proyecto cayó por un precipicio, por lo que nunca llegamos a hacer demasiado. Lo hemos retomado recientemente, pero ya no estamos usando angular y estamos usando React en su lugar. Todavía estamos usando la arquitectura descrita en la actualización anterior, donde usamos aplicaciones express y autocontenidas, por ejemplo, tenemos una /chatruta en express que sirve nuestra aplicación de chat React, tenemos otra ruta /projectsque sirve la aplicación de proyectos y pronto. La forma en que lo estamos viendo es que cada aplicación es una raíz agregada en términos de su conjunto de características, debe ser independiente para que se considere una aplicación en sí misma. Técnicamente, toda la información está disponible, es solo un express básico y cualquier sabor de bondad de construcción de aplicaciones del lado del cliente que desee utilizar.

De ningún modo. Puede usar Angular para crear una variedad de aplicaciones. El enrutamiento del lado del cliente es solo una pequeña parte de eso.

Tiene una gran lista de características que lo beneficiarán fuera del enrutamiento del lado del cliente:

• enlace bidireccional
• plantillas
• formato de moneda
• pluralización
• controles reutilizables
• RESTful manejo de la API
• Manejo AJAX
• modularización
• inyección de dependencia

Es una locura pensar que todo eso "solo se puede usar en una aplicación de una sola página". Por supuesto que no ... eso es como decir "Jquery es solo para proyectos con animaciones".

Si se ajusta a su proyecto, úselo.

Luché con el "cómo" al principio con Angular también. Entonces un día me di cuenta: "TODAVÍA es javascript". Hay un montón de ejemplos sobre los entresijos de Angular (uno de mis favoritos junto con el libro https://github.com/angular-app/angular-app ). Lo más importante para recordar es cargar los archivos js como lo haría en cualquier otro proyecto. Todo lo que tiene que hacer es asegurarse de que las diferentes páginas hagan referencia al objeto angular correcto (controlador, vista, etc.) y que esté apagado y funcionando. Espero que esto tenga sentido, pero la respuesta fue tan simple que lo pasé por alto.

Quizás mi experiencia sea útil para alguien. Dividimos nuestro proyecto lógicamente. Un SPA que utilizamos para alimentar, otro para trabajar con el mapa, otro para editar un perfil de usuario, etc. Por ejemplo, tenemos tres aplicaciones: feed, usuario y mapa. Lo uso en las URL separadas, así:

https://host/feed/#/top/
https://host/user/#/edit/1/
https://host/map/favorites/#/add/

Cada una de estas aplicaciones tiene sus propias asignaciones de enrutamiento local entre estados en la aplicación. Creo que es una buena práctica porque cada aplicación funciona solo con su propio contexto y depende de la carga que realmente necesita. Además, es una práctica muy buena para los procesos de depuración e integración.

De hecho, puede hacer fácilmente una combinación de aplicaciones SPA, por ejemplo, el feed será url con la aplicación angularjs, la aplicación de usuario con reactjs y el mapa de la aplicación backbone.js.

En respuesta a tu pregunta:

Angular no solo para SPA, Angular juega bien y rápido para aplicaciones SPA, pero nadie se molesta en construir una aplicación MPA de una variedad de aplicaciones SPA. Pero pensando en su arquitectura de URL, no se olvide de la disponibilidad SEO de sus aplicaciones.

También apoyo la idea:

¿Cuál es la diferencia entre un proyecto y una aplicación? Una aplicación es una aplicación web que hace algo, por ejemplo, un sistema de registro web, una base de datos de registros públicos o una aplicación de encuesta simple. Un proyecto es una colección de configuraciones y aplicaciones para un sitio web en particular. Un proyecto puede contener múltiples aplicaciones. Una aplicación puede estar en múltiples proyectos.

Si todo lo que necesita son algunas páginas con enlace de datos del cliente, iría con Knockout y Javascript Namespacing.

Knockout es excelente, especialmente si necesita compatibilidad con versiones anteriores sin complicaciones y tiene páginas bastante sencillas. Si está utilizando componentes de terceros, los enlaces personalizados de Knockout son sencillos y fáciles de usar.

El espacio de nombres de Javascript le permite mantener su código separado y manejable.

var myCo = myCo || {};
myCo.page = {
    init: function(){ ... },
    ...
}

Y en una etiqueta de secuencia de comandos después de cargar sus otras secuencias de comandos

<script>
    myCo.init();
</script>

La clave es que use la herramienta que desee cuando la necesite. ¿Necesita enlace de datos? Knockout (o lo que quieras). ¿Necesita enrutamiento? sammy.js (o lo que quieras).

El código del cliente puede ser tan simple o complicado como lo desee. Intenté integrar Angular en un sitio muy complicado con un marco propietario existente, y fue una pesadilla. Angular es excelente si está comenzando de cero, pero tiene una curva de aprendizaje y lo encierra en un flujo de trabajo muy ajustado. Si no lo sigue, su código puede enredarse realmente rápido.

Yo diría que Angular es excesivo si solo estás buscando desarrollar un SPA. Claro, si ya te sientes cómodo desarrollando con él, adelante. Pero si eres nuevo en el marco y solo necesitas desarrollar un SPA, elegiría algo más simple con varias ventajas propias. Recomiendo buscar en Vue.js o Aurelia.io .

Vue.js utiliza enlace de datos bidireccional, MVVM, componentes reutilizables, fácil y rápido de recoger, menos código para escribir, etc. Combina algunas de las mejores características de Angular y React.

Aurelia.io , con toda honestidad, no sé mucho al respecto. Pero he echado un vistazo y parece una alternativa que vale la pena considerar, similar a la anterior.

Enlaces:
https://vuejs.org/
http://aurelia.io/