Single Page Apps (SPAs) estão rapidamente se tornando a sabedoria convencional para a construção de ricas aplicações web. Eu por exemplo sou uma grande fã de SPAs em geral, e em particular de um certo framework super-heroico.

A popularidade do SPA é provavelmente devido ao rápido amadurecimento de tecnologias de navegador (HTML5, CSS3, motores de alto desempenho JavaScript) e uma grande explosão de frameworks JavaScript MV*. Estamos nos aproximando rapidamente de um ponto em que qualquer coisa que você construa em um aplicativo desktop, você também possa construir em um aplicativo web.

No entanto, apesar da popularidade acima mencionada, SPAs não são universalmente amados. No passado, a principal oposição a eles veio dos fãs da tradicional abordagem MVC do lado do servidor e digamos que dos não-fãs de JavaScript. Pessoalmente, achei os dois campos bastante fáceis de dispensar (com todo o respeito). Porém, um fluxo recente de opiniões anti-SPA de pessoas conhecedoras que eu respeito me fez parar e reavaliar minhas opiniões.

O caso contra SPAs

Provavelmente, o caso mais abrangente contra SPAs foi feito por Stefan Tilkov em sua palestra “Web Development: You’re Doing it Wrong”. Nela, ele explica por que considera SPAs problemáticos, contrastando-os com aplicações escritas em um estilo que ele se refere como Resource Oriented Client Architecture (ROCA).

Então, o que é ROCA? Aqui está uma citação do site:

ROCA é uma tentativa de definir um conjunto de recomendações – independentemente de qualquer framework, linguagem de programação ou ferramentas – que incorpora os princípios daquilo que nós consideramos ser uma boa arquitetura de aplicações web. A sua finalidade é servir de referência, que pode ser implementada como está ou ser comparada com outras abordagens para destacar as decisões de concepção divergentes.

ROCA se divide em duas partes: a arquitetura do lado do servidor e do lado do cliente. O lado do servidor consiste em backends RESTful, servindo conteúdo legível, bem como serviços de comunicação máquina-a-máquina, pública ou interna. O lado do cliente se concentra em um uso sustentável e manutenção de JavaScript e CSS, com base no princípio da Progressive Enhancement. Essa técnica é perseguida por quase todas as tecnologias web básicas, por exemplo, HTML ou HTTP. Cliente e servidor são em grande parte independentes, mas se complementam.

Embora a citação acima não mencione frameworks específicos, Rails 4.0 (que é fortemente influenciado por uma reformulação recente do BaseCamp) é, provavelmente, a implementação mais notável do mundo real. Pjax é outro framework popular, que pode ser usado para implementar um aplicativo estilo ROCA.

ROCA vs SPA

Antes de mergulhar em diferenças relevantes entre SPA e ROCA, vamos mencionar brevemente as semelhanças (que são muitas). Ambos os estilos defendem o uso de backends RESTful e tudo o que isso implica (como URIs bem formados e sessões de stateless), são a favor de um JavaScript discreto, e esperam separação de apresentação (CSS) e conteúdo (HTML).

Qual é então a diferença? Existem algumas, mas a principal delas é o formato que esses backends RESTful fornecem ao cliente. Nos SPAs, os dados que estão sendo enviados para o navegador são JSON ou XML. A responsabilidade de converter esses dados em um HTML compatível com o navegador está inteiramente no cliente. Em ROCA, os dados que estão sendo enviados para o browser são HTML.

Essa diferença aparentemente pequena tem implicações significativas. Por exemplo, os recursos construídos utilizando ROCA são, eles próprios, páginas válidas, que podem ser rastreadas e indexadas pelo motor de busca, marcadas, e exibidas em clientes com JavaScript desabilitado.

De fato, todos os motivos listados acima são os motivos porque apoiadores do ROCA os favorecem sobre SPAs. Na opinião deles, SPAs fundamentalmente quebram o paradigma web essencialmente recriando aplicativos desktop no navegador. Por outro lado, apps ROCA se encaixam muito bem dentro do paradigma web abraçando HTML como o formato para troca de dados entre cliente e servidor.

Meus dois centavos

De um modo geral, eu não sou um fã de uso reflexivo de uma tecnologia ou uma abordagem independentemente do problema a ser resolvido (com exceções notáveis). A partir apenas dessa perspectiva, eu concordo que o uso de SPAs para tudo não é o ideal.

Além disso, a principal razão pela qual eu primeiramente gostei de SPA é que eles forçam a criação de aplicações orientadas a recursos. ROCA faz o mesmo e ainda reforça a compatibilidade web via adesão ao HTML.

Mas e quanto ao desempenho?

Considere o uso massivo de sub-componentes de caching do BaseCamp (por exemplo, a abordagem “Russian Doll”). BaseCamp armazena individualmente cada pedaço de conteúdo exibido em uma determinada página. Esse cache é global e pode, portanto, ser reutilizado entre páginas, usuários, aplicativos etc. O que isso significa para o desempenho? Apesar de todo esse HTML ser gerado do lado do servidor, a página de renderização é ultra-rápida (100 ms ou menos).

Agora, o domínio do BaseCamp (gerenciamento de projetos), funciona bem com essa abordagem. Há muitas peças independentes de conteúdo, que podem ser combinadas e compartilhadas entre páginas e usuários, e assim por diante.

Ok, aplicativos para desktop na Web são ruins, certo?

Bem, não. Eu acho que certos tipos de aplicativos (jogos, editores de imagem, processadores de texto, possivelmente clientes de e-mail de clientes etc.) são bem adequados para a metáfora do “desktop”. A questão realmente interessante é como se decide se SPAs ou ROCA são a opção certa.

Sem pensar muito sobre isso (como é meu costume), eu diria que ROCA é a abordagem padrão, e use SPA se o app:

• não necessita de um servidor (ex.: editor de imagem)
• expõe muitas interações complexas em um grande recurso (ex.: processador de texto.)

Existem outras áreas onde SPAs funcionariam melhor?

***

Artigo traduzido pela Redação iMasters, com autorização do autor. Publicado originalmente em http://tatiyants.com/are-single-page-apps-bad/