O AngularJS é apenas para aplicativos de página única (SPAs)?

Estamos analisando as opções para criar o front-end de um aplicativo que estamos criando e estamos tentando avaliar uma ferramenta que funcionará para nós e nos dará a melhor plataforma para seguir em frente.

Este é um projeto do Node.js. Nosso plano inicial era usar o Express e seguir esse caminho, mas decidimos que antes de começarmos este estágio, seria melhor rever o que está por aí. Nosso aplicativo tem várias áreas que não consideramos adequadas ao modelo de página única, pois elas estão relacionadas de uma perspectiva de aplicativo, mas não de uma perspectiva.

Vimos alguns dos frameworks que poderíamos usar para construir o cliente como o Backbone.js , o Meteor , etc. e também o AngularJS.

Esta pode ser uma questão bastante óbvia, mas não podemos decifrar se o AngularJS é apenas para aplicação de página única ou pode ser usado para aplicativos de várias páginas, como o Express, por exemplo.


ATUALIZAÇÃO 17 de julho de 2013 Apenas para manter as pessoas informadas, atualizarei esta questão enquanto passamos pelo processo. Vamos construir tudo juntos por agora, e vamos ver o quão bem isso funciona. Entramos em contato com algumas pessoas que são mais qualificadas com AngularJS do que nós e colocamos a questão sobre dividir aplicativos maiores que compartilham contexto, mas pode ser muito grande trabalhando em uma única página.

O consenso era que poderíamos servir várias páginas estáticas e criar aplicativos AngularJS que trabalhassem apenas com essas páginas, criando efetivamente uma coleção de SPAs e vinculando esses aplicativos juntos usando a vinculação padrão. Agora, nosso caso de uso é muito específico, pois a nossa solução tem várias aplicações e, como eu disse, vamos tentar a base de código única primeiro e otimizar a partir daí.

ATUALIZAÇÃO 18 de junho de 2016 O projeto caiu de um penhasco, então nunca chegamos perto de fazer muito. Nós o recuperamos recentemente, mas não estamos mais usando o angular e estamos usando o React. Ainda estamos usando a arquitetura descrita na atualização anterior, onde usamos aplicativos expressos e autônomos, por exemplo, temos uma rota /chat expressa que atende ao nosso aplicativo de bate-papo do React, temos outra rota /projects que exibem o aplicativo de projetos e assim por diante. A forma como estamos olhando é que cada aplicativo é uma raiz agregada em termos de seu conjunto de resources, ele precisa ser capaz de ser autônomo para ser considerado um aplicativo em si. Tecnicamente, toda a informação está lá fora, é apenas um expresso básico e qualquer sabor do aplicativo do lado do cliente que você deseja usar.

De modo nenhum. Você pode usar o Angular para criar uma variedade de aplicativos. O roteamento do lado do cliente é apenas uma pequena parte disso.

Você tem uma grande lista de resources que irão beneficiar você fora do roteamento do lado do cliente:

  • binding bidirecional
  • templating
  • formatação de moeda
  • pluralização
  • controles reutilizáveis
  • Manipulação de APIs RESTful
  • Manipulação de AJAX
  • modularização
  • dependency injection

É uma loucura pensar que tudo isso “só poderia ser usado em um aplicativo de uma única página”. Claro que não .. isso é como dizer “Jquery é apenas para projetos com animações”.

Se couber no seu projeto, use-o.

Eu lutei com o “como” no início com o Angular também. Então um dia me dei conta: “É ainda javascript”. Há um monte de exemplos sobre os prós e contras do Angular (um dos meus favoritos, juntamente com o livro https://github.com/angular-app/angular-app ). A maior coisa a lembrar é carregar os arquivos js como você faria em qualquer outro projeto. Tudo o que você precisa fazer é certificar-se de que as diferentes páginas referenciem o object Angular correto (controlador, visão, etc.) e que você esteja fora de operação. Espero que isso faça sentido, mas a resposta foi tão simples que esqueci.

Talvez minha experiência seja útil para alguém. Nós dividimos nosso projeto logicamente. Um SPA que usamos para alimentação, outro para trabalhar com o mapa, outro para editar um perfil de usuário e etc. Por exemplo, temos três aplicativos: feed, usuário e mapa. Eu uso nos urls separados, assim:

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

Cada um desses aplicativos possui seus próprios mapeamentos de roteamento locais entre os estados no aplicativo. Eu acho que é uma boa prática, porque cada aplicativo funciona apenas com seu próprio contexto e dependencies de carga que ele realmente precisa. Além disso, é uma prática muito boa para os processos de debugging e integração.

De fato, você pode facilmente fazer uma mistura de aplicativos SPA, por exemplo, o feed será url com o aplicativo angularjs, o aplicativo de usuário com o reactjs e o mapa para o aplicativo backbone.js.

Em resposta à sua pergunta:

Angular não apenas para SPAs, Angular é bom e rápido para aplicações de SPA, mas ninguém se incomoda em construir aplicações de MPA de uma variedade de aplicações de SPA. Mas pensar na sua arquitetura de URL não se esquece da disponibilidade de SEO dos seus aplicativos.

Eu também apoio a ideia:

Qual é a diferença entre um projeto e um aplicativo? Um aplicativo é um aplicativo da Web que faz alguma coisa – por exemplo, um sistema de Weblog, um database de registros públicos ou um aplicativo de pesquisa simples. Um projeto é uma coleção de configurações e aplicativos para um site específico. Um projeto pode conter vários aplicativos. Um aplicativo pode estar em vários projetos.

Se tudo que você precisa é de algumas páginas com binding de dados do cliente, eu usaria o Knockout e o Javascript Namespacing.

O Knockout é ótimo, especialmente se você precisar de compatibilidade reversa descomplicada e tiver páginas razoavelmente diretas. Se você estiver usando componentes de terceiros, as ligações personalizadas do Knockout são diretas e fáceis de trabalhar.

O namespace JavaScript permite que você mantenha seu código separado e gerenciável.

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

E em uma tag de script depois que seus outros scripts são carregados

  

A chave é, você usa qualquer ferramenta que você quer para quando você precisa. Precisa de binding de dados? Knockout (ou o que você quiser). Precisa de roteamento? sammy.js (ou o que você quiser).

O código do cliente pode ser tão simples ou complicado quanto você quiser. Eu tentei integrar o Angular em um site muito complicado com uma estrutura proprietária existente, e foi um pesadelo. O Angular é ótimo se você está começando do zero, mas ele tem uma curva de aprendizado e o coloca em um stream de trabalho muito restrito. Se você não segui-lo, seu código pode ficar muito emaranhado muito rápido.

Eu diria que o Angular é um exagero se você está apenas procurando desenvolver um SPA. Claro, se você já está confortável em desenvolver, vá em frente. Mas se você é novo no framework e só precisa desenvolver um SPA, eu vou com algo mais simples, com vários de seus próprios benefícios. Eu recomendo olhar para Vue.js ou Aurelia.io .

O Vue.js usa binding de dados bidirecional, MVVM, componentes reutilizáveis, simples e rápido de pegar, menos código para escrever, etc. Ele combina alguns dos melhores resources do Angular e do React.

Aurelia.io , com toda honestidade, eu não sei muito sobre isso. Mas eu espiei e parece uma alternativa que vale a pena olhar, semelhante ao acima.

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