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

Estamos analisando opções para criar o front end de um aplicativo que estamos criando e tentando avaliar uma ferramenta que funcionará para nós e nos fornecerá a melhor plataforma para avançar.

Este é um projeto do Node.js. Nosso plano inicial era usar o Express e seguir esse caminho, mas decidimos que, antes de iniciarmos este estágio, seria melhor revisar o que está lá fora. Nosso aplicativo possui várias áreas que, acreditamos, não se enquadram no modelo de página única, pois são relacionados da perspectiva do aplicativo, mas não da visualização.

Vimos algumas das estruturas que poderíamos usar para criar o cliente como Backbone.js , Meteor , etc. e também o AngularJS.

Essa pode ser uma pergunta bastante óbvia, mas parece que não conseguimos decifrar se o AngularJS é apenas para aplicativos de página única ou se 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 pergunta à medida que avançamos no processo. Vamos construir tudo juntos por enquanto e veremos o desempenho. Entramos em contato com algumas pessoas que são mais qualificadas com o AngularJS do que nós e levantamos a questão de dividir aplicativos maiores que compartilham contexto, mas que podem ser muito grandes trabalhando em uma única página.

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

ATUALIZAÇÃO 18 de junho de 2016 O projeto caiu de um penhasco, por isso nunca chegamos a fazer muito. Recolhemos novamente recentemente, mas não usamos mais angular e, em vez disso, usamos React. Ainda estamos usando a arquitetura descrita na atualização anterior, em que usamos aplicativos expressos e autocontidos. Por exemplo, temos uma /chatrota expressa que serve nosso aplicativo de bate-papo React, temos outra rota /projectsque serve o aplicativo de projetos e em breve. A maneira como olhamos para ele é que cada aplicativo é uma raiz agregada em termos de seu conjunto de recursos, ele precisa poder ser autônomo para ser considerado um aplicativo em si. Tecnicamente, todas as informações estão disponíveis, é apenas o expresso básico e qualquer que seja o 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 cliente é apenas uma pequena parte disso.

Você tem uma grande lista de recursos que o beneficiarão fora do roteamento do cliente:

• ligação bidirecional
• modelo
• formatação de moeda
• pluralização
• controles reutilizáveis
• Manipulação de API RESTful
• Manipulação de AJAX
• modularização
• Injeção de dependência

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

Se ele se encaixa no seu projeto, use-o.

Eu lutei com o "como" a princípio também com Angular. Então um dia me dei conta: "Ainda é javascript". Existem vários exemplos dos detalhes do Angular (um dos meus favoritos junto com o livro https://github.com/angular-app/angular-app ). A coisa mais importante a lembrar é carregar os arquivos js como faria em qualquer outro projeto. Tudo o que você precisa fazer é garantir que as páginas diferentes façam referência ao objeto Angular correto (controlador, exibição, etc.) e você esteja em funcionamento. Espero que isso faça sentido, mas a resposta foi tão simples que eu a ignorei.

Talvez minha experiência seja útil para alguém. Dividimos nosso projeto logicamente. Um SPA que usamos para feed, 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 local entre estados no aplicativo. Eu acho que é uma boa prática, porque cada aplicativo trabalha apenas com seu próprio contexto e carrega as dependências de que realmente precisa. Além disso, é uma prática muito boa para processos de depuração 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 do usuário com o reactjs e o mapeamento para o aplicativo backbone.js.

Em resposta à sua pergunta:

Angular, não apenas para SPAs, o Angular é bom e rápido para aplicativos de SPA, mas ninguém se preocupa em criar aplicativos MPA para uma variedade de aplicativos de SPA. Mas, pensando na sua arquitetura de URL, não se esqueça da disponibilidade de SEO de seus aplicativos.

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 blog, um banco de dados 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 o que você precisa é de algumas páginas com ligação de dados do cliente, eu usaria Knockout e Javascript.

O nocaute é excelente, especialmente se você precisar de compatibilidade com versões anteriores descomplicada e possuir páginas bastante 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 manter seu código separado e gerenciável.

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

E em uma tag de script após o carregamento dos outros scripts

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

A chave é que você usa a ferramenta que deseja quando precisa. Precisa de ligação de dados? Nocaute (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ê desejar. Tentei integrar o Angular a um site muito complicado com uma estrutura proprietária existente, e foi um pesadelo. Angular é ótimo se você está começando do zero, mas ele tem uma curva de aprendizado e o bloqueia em um fluxo de trabalho muito apertado. Se você não segui-lo, seu código pode ficar muito emaranhado muito rápido.

Eu diria que Angular é um exagero se você está apenas procurando desenvolver um SPA. Claro, se você já está à vontade para desenvolver isso, vá em frente. Mas se você é novo na estrutura e só precisa desenvolver um SPA, eu recomendaria algo mais simples com várias vantagens. Eu recomendo olhar para Vue.js ou Aurelia.io .

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

Aurelia.io , com toda a honestidade, não sei muito sobre. Mas eu dei uma espiada e parece uma alternativa que vale a pena procurar, semelhante à anterior.

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