Se você se perguntou por que e quando essas estruturas são usadas e se é hora de implementar uma em seu projeto, você não está sozinho. Alguns anos atrás, enquanto trabalhava em um projeto paralelo, Hackterms, meu próprio...

Você provavelmente já ouviu falar sobre estruturas front-end. Nomes como React, Vue e Angular abundam em tutoriais e debates do Hacker News. Se você se perguntou por que e quando essas estruturas são usadas e se é hora de implementar uma em seu projeto, você não está sozinho. Alguns anos atrás, enquanto trabalhava em um projeto paralelo, Hackterms,minha própria frente se tornou desajeitada. Eu tinha uma sensação frouxa de que implementar uma estrutura era o próximo passo, mas eu tinha pouca ideia sobre o que eles fizeram. (Vamos voltar a ser como isso acabou no final do artigo.) Esta é a explicação que eu gostaria que tivesse então. Neste post, vamos ter uma visão de olho de pássaro sobre o problema estruturas front-end estão tentando resolver e quando você pode querer usar um.

Especificamente, vamos revisar:

Como uma frente cresce.

Os problemas de arquitetura que você pode encontrar à medida que ele escala.

Como uma estrutura front-end pode ajudar a lidar com isso.

Outras alternativas que você pode considerar.

Rápido à parte: "front-end framework" recebe um hífen, já que é um adjetivo composto. No entanto, seu aplicativo tem um "front end" — substantivo, sem hífen. Fique nerd comigo.

Alguns termos para revisar

Vamos falar sobre frameworks front-end um monte (você pode ter recebido uma dica do título), então vamos entrar na mesma página em torno da terminologia:

Uma estrutura de software é uma estrutura de aplicativo pré-escrita para você construir em cima. Na prática, é uma coleção de arquivos e diretórios que você adiciona seu próprio código e arquivos. Uma estrutura é feita para ajudá-lo a construir aplicativos mais rapidamente, abordando problemas comuns de desenvolvimento e muitas vezes começa com:

Código caldeiraplata, cobrindo funções que são reutilizadas pela maioria dos aplicativos.

Uma estrutura de diretório, muitas vezes seguindo uma filosofia de design.

Um conjunto de princípios de design que seu tipo de aplicação encontra frequentemente. Quadros que aplicam esses princípios, como Ruby on Rails, são geralmente referidos como opinativos.

Uma frente é a camada de apresentação da sua aplicação. É muitas vezes descrito como todas as coisas que o usuário vê, mas, mais geralmente, é qualquer código que é responsável por exibir dados eficientemente para o usuário. Assim, a front-end inclui a construção de interfaces intuitivas e agradáveis, bem como o armazenamento, apresentação e atualização eficientes de dados recebidos do back-end ou da API.

Uma estrutura frontal é um andaime para construir sua parte frontal. Geralmente inclui alguma maneira de estruturar seus arquivos (por exemplo, através de componentes ou um pré-processador CSS), fazer solicitações AJAX, estilizar seus componentes e associar dados com elementos DOM.

Um aplicativo em crescimento

Você pode construir um frontend simples com apenas três arquivos: HTML, CSS e JavaScript. No entanto, à medida que seu aplicativo escala, seus arquivos crescerão junto com ele, preenchendo com código de espaguete inescrutável e inacompensável.

Como é tradição, vamos olhar para um exemplo bobo: digamos que você está construindo o MySquare, um ranking para jogadores de tabuleiro competitivos. Neste aplicativo, os usuários podem compartilhar os jogos de tabuleiro que jogaram, seus resultados competitivos sancionados pela liga (agora há uma liga, rolar com ele) e avaliações curtas de partidas competitivas. O recurso mais importante do aplicativo é a página do perfil do usuário:

Você constrói a primeira versão desta página de perfil com as três tecnologias básicas, HTML, CSS e JavaScript. Funciona algo assim: 

Na carga inicial da página, o back-end inicialmente envia uma página de perfil em branco com estilo mínimo. Em seguida, e para todas as cargas futuras, o front-end solicita dados do usuário via AJAX.

O back-end envia alguns dados do usuário público como JSON, e você usa JavaScript para anexar dinamicamente elementos DOM para crachás de jogo e registros na página.

Quando você decide construir páginas específicas do jogo que listam todos os usuários e seus registros, você cria novos arquivos JavaScript que replicam grande parte do código, já que eles estão se baseando nos mesmos dados do jogo.

Cada crachá de jogo (e crachá de correspondência) usa o mesmo HTML, então você armazena a marcação em uma string JavaScript e descobre uma maneira de injetar dados específicos do jogo lá, ex: “p{{Game Name}}/p”. Em seguida, você anexar o crachá HTML na página para cada jogo.

Quando um usuário atualiza algum valor na página, você pode ler dados do DOM consultando atributos ou anexando os ouvintes de eventos a cada elemento — obtendo os dados lendo-os do DOM.

À medida que o MySquare se torna popular e seu conjunto de dados cresce, essa abordagem rapidamente se torna desordenada:

Você encontra-se anexando dados à página e, em seguida, lendo-os do DOM, capturando div valores ou leitura de ids ou atributos de dados.

O número de balões de arquivos JavaScript e CSS, e há muito código repetido entre eles.

Você está vinculando os ouvintes de eventos a elementos comuns de interface do usuário, como campos de entrada e botões, em seguida, escrevendo funções para atualizar os valores nesses mesmos elementos.

Quando você precisa fazer até mesmo uma pequena mudança, você se preocupa com como isso vai impactar o resto da aplicação.

Quando seu amigo se oferece para ajudar com o trabalho de desenvolvimento (para alguma equidade, é claro), você passa horas explicando como seu código funciona.

Gerenciar esses problemas é viável com baunilha JavaScript e paciência suficiente. Com planejamento e previsão, você pode ser capaz de estruturar seu aplicativo para antecipar alguns desses problemas. No entanto, à medida que sua frente cresce, esses problemas só se aprofundarão — você nunca pode ter certeza de como seu aplicativo vai evoluir. 

Você percebe que armazenar seus dados no DOM e gastar incessantemente HTML armazenado em strings JavaScript não pode ser a melhor maneira de lidar com este projeto. Felizmente, não há necessidade de reinventar a roda. Quando você se encontra precisando construir uma interface do usuário robusta e mantida, é hora de... Você adivinhou! Uma estrutura frontal.

Enter, framework

Estruturas front-end existem porque, para muitos aplicativos, a parte frontal cresce e se esforça de maneiras previsíveis. Embora cada estrutura popular ofereça sua própria filosofia de design, todos eles estão tentando resolver os mesmos problemas gerais que encontramos anteriormente:

Seu código deve ser mantido: fácil para você e outros lerem, testarem e mudarem.

Interfaces complexas são geralmente feitas dos mesmos componentes. Você deve ser capaz de criar e reutilizar esses componentes para criar facilmente novas páginas.

Uma vez que as manipulações do DOM são lentas, você deseja executar o menor número possível de atualizações de elementos.

Você deve ser facilmente capaz de manipular sua interface do usuário com base em dados.

Sua interface do usuário deve ser consistente e intuitiva; isso significa padronizar tipografia, cor, botões, entradas e outros elementos.

Você não deve precisar reinventar a roda e escrever toneladas de caldeiras quando se trata de resolver esses desafios front-end comuns.

Você deve ter uma linguagem comum através da qual comunicar suas ideias e padrões com outros desenvolvedores.

Diferentes estruturas abordam algumas, mas geralmente não todas, dessas questões. Alguns, como Bootstrap e SemanticUI,se concentram na criação de HTML e CSS legíveis e manteníveis, enfatizando o design visual consistente. Outros, como Vue, Reacte Angular,triunfam na estruturação do fluxo de dados ao longo de sua aplicação, permitindo que você se concentre na manipulação dos dados em vez do DOM.

(Sarah Drasner tem uma introdução fantástica que demonstra a diferença entre ler dados do DOM e armazená-los em JS. Embora seu exemplo discuta a mudança de jQuery para Vue, você pode lê-lo como uma mudança de mentalidade mais ampla da manipulação do DOM para focar em estruturas de dados.)

Como seria o MySquare se você implementasse uma estrutura frontal popular, como o React? Aqui estão algumas mudanças que você experimentaria:

Você criaria componentes HTML/CSS/JavaScript reutilizáveis com espaços reservados de dados para os crachás do jogo, registros de correspondência e outros elementos comuns. O framework renderizaria esses elementos com base em dados recebidos (o JSON que obdepois do servidor ou das APIs). Por exemplo, se o JSON tiver nove recordes de jogos, renderizamos nove componentes Match com dados de correspondência inseridos automaticamente.

Você seguiria a estrutura do diretório da caldeira para criar componentes, scripts e folhas de estilo de uma maneira fácil de seguir e manter. Precisa mudar a estrutura e o estilo dos recordes de jogos? Encontre o pequeno componente autônomo Match e faça suas alterações.

Você seria capaz de aproveitar os recursos javaScript mais recentes, bem como um pré-processador CSS como o SASS para escrever código conciso, expressivo e moderno. A estrutura transpilará isso para o HTML/CSS/JavaScript que os navegadores entendem.

Com essa infraestrutura em vigor, você poderia se concentrar em manipular os dados em vez de se preocupar com o DOM. Os recursos de vinculação de dados do nosso framework reativarão automaticamente os componentes relevantes quando os dados mudarem. Por exemplo, se você receber dados sobre um novo resultado de correspondência do servidor, a estrutura anexará automaticamente outro componente Match na tela.

Se você se encontrasse preso a um problema, você poderia aproveitar a comunidade de quadros para obter ajuda. Deve ser ainda mais fácil explicar seu problema, já que você está seguindo convenções de quadro que ajudam a construir recursos front-end populares.

Como as estruturas populares geralmente seguem princípios de design semelhantes, seria mais fácil colaborar com outros desenvolvedores, mesmo aqueles que não se desenvolvem em sua estrutura específica — você não precisaria levar novos desenvolvedores através de sua própria estrutura de código personalizado.

Separação de preocupações

Idealmente, você gostaria que sua frente operasse como um aplicativo autônomo, solicitando dados do back-end, processando e exibindo-os (você pode ouvir isso chamado "consumindo uma API"). O princípio que sustenta isso é referido como "separação de preocupações", e afirma que cada parte do seu programa deve operar de forma independente, ter um propósito claro e singular, e comunicar-se através de uma interface bem definida. Embora sua frente não precise implementar uma estrutura para seguir o princípio da separação das preocupações, a maioria dos quadros incentiva esse padrão arquitetônico.

A vantagem do design modular resultante é que os desenvolvedores podem trabalhar em diferentes partes do seu aplicativo independentemente, desde que seu componente aceite entradas previsíveis e ofereça saídas previsíveis. Ter uma frente com uma única responsabilidade (composta de componentes modulares que seguem o mesmo princípio) facilita a adaptação à mudança. Se você decidir passar de Angular para Reagir, por exemplo, você pode fazê-lo com confiança; ambas as estruturas esperam dados do back-end, para que você possa se concentrar em como a interface do React recebe esses dados e como ele os usa, não como a parte frontal está incorporada em seu aplicativo maior.

Como a camada de exibição dedicada do seu aplicativo, sua parte frontal deve ser a única responsável pela lógica ao redor:

quais elementos devem ser exibidos ou escondidos

quando solicitar dados ou enviar atualizações para o servidor

quando exibir mensagens simples de validação e erro

quais escolhas de estilo fazer com base em dados

Aqui estão dois cenários do MySquare: um onde a arquitetura segue a separação das preocupações, e o outro onde ela a viola. Veja se você pode descobrir qual é qual!

O back-end envia uma lista de registros de jogos; cada registro contém uma pontuação, nomes de dois jogadores e a data da partida. A parte frontal anexa um componente HTML para cada partida, com uma cor de fundo vermelho ou verde, dependendo de quem ganhou a partida.

O back-end envia uma lista de registros de jogos; cada registro contém uma pontuação, nomes de dois jogadores, a data da partida e um código de hex de cor para ganhar/perder estilo de partida, calculado com base em qual perfil está solicitando o código. A parte frontal adiciona um componente por partida, estilizando-o com a cor de fundo enviada pelo back-end.

Você pegou a violação? A parte de trás não deve se preocupar com estilo. Essa lógica deve viver na parte frontal, que determina como os dados são exibidos. Se seus designers querem enfeitar o design do MySquare, eles não devem se preocupar com estruturas de dados.

Vantagens em usar uma estrutura

Vamos recapitular as principais maneiras pelas quais a adoção de uma estrutura front-end ajudará nosso aplicativo em rápido crescimento:

Manutenção: Dividir seu aplicativo em componentes autônomos reutilizáveis facilita a ção rápida de alterações que não afetam o resto do aplicativo.

Separação de preocupações: O design de estrutura moderno incentiva uma arquitetura modular e sustentável e permite que seus desenvolvedores front-end se concentrem no que fazem de melhor: pegar dados e exibi-los aos usuários de forma intuitiva e eficiente.

Velocidade: O código boilerplate destinado a resolver problemas comuns facilita a execução do aplicativo; o design baseado em componentes torna mais rápido o desenvolvimento.

Colaboração: Uma vez que as estruturas geralmente seguem padrões de design semelhantes, é mais fácil para desenvolvedores que são novos na sua base de código desenvolver e manter seu aplicativo.

Comunidade: Estruturas populares têm uma comunidade de pessoas ao seu redor com tutoriais dedicados, fóruns, encontros e desenvolvedores geralmente de apoio que você pode buscar ajuda.

Desvantagens e alternativas

É claro que, como qualquer ferramenta, uma estrutura front-end nem sempre é a solução certa para o seu aplicativo. Aqui estão alguns fatores a considerar antes de implementar um.

Desvantagens

Código de sobrecarga abstraído: Até que você esteja completamente familiarizado com ele, o código de estrutura é uma caixa preta. Pode ser difícil discernir quanto do código é útil para o seu aplicativo e frustrante corrigir bugs resultantes de código que você não está familiarizado.

Curva de aprendizado: Aprender a usar uma estrutura efetivamente leva tempo. Para ser produtivo, você precisa entender a sintaxe, a ferramenta e a filosofia por trás de como uma estrutura funciona. Para projetos onde a velocidade é essencial, aprender uma nova tecnologia pode não ser o melhor uso do seu tempo.

Exagero para projetos menores: Se você está procurando implantar um site estático ou um site onde cada componente é único, você pode não precisar da energia e da sobrecarga de uma estrutura completa. Ainda pode ser útil implementar uma estrutura mínima ou até mesmo biblioteca — discutiremos isso na próxima seção.

Configuração: Configurar e personalizar uma estrutura para o seu caso de uso específico leva tempo. Se a velocidade é essencial, vá com o que você sabe, ou com o que sua equipe de desenvolvimento está confortável.

Opiniões fortes: Uma estrutura opinativa pode parecer constrição, e seus princípios de design podem colidir com o seu. Certifique-se de pesquisar a estrutura específica que está implementando. Se você preferir construir do zero, vá com sua própria solução.

Evolução do ecossistema: O ecossistema de estruturas JavaScript é famosamente volátil. A estrutura mais quente de hoje pode não ser popular no próximo ano, e com essa mudança, desenvolvedores e suporte podem ser difíceis de encontrar.

Alternativas

Existem algumas alternativas para grandes frameworks JavaScript como Vue, React e Angular. Como mencionamos anteriormente, diferentes estruturas front-end tentam resolver diferentes problemas. Dependendo de suas necessidades, estruturas menores e bibliotecas podem funcionar para você. Além disso, você pode abandonar a separação de preocupações e ir com um aplicativo de pilha completa monolito com visualizações renderizadas do lado do servidor. Aqui estão algumas alternativas a considerar:

Motores templating: Se tudo o que você precisa são componentes reutilizáveis, considere um motor templating como Guidão.js, EJS, Underscore.js, ou bigode. Esses motores permitem que você armazene componentes HTML/CSS/JavaScript e insira variáveis JavaScript neles. Eu mencionei lutando com como escalar meu projeto, Hackterms, no início deste artigo. Em retrospectiva, eu absolutamente deveria ter usado uma estrutura completa. No entanto, na época, eu estava com pouco tempo e paciência, então usei com sucesso o Guidão para criar modelos reutilizáveis.

Estruturas e bibliotecas CSS: Se você está procurando criar uma interface do usuário consistente, uma ferramenta como Bootstrap, SemanticUI, Bulmaou Tailwind pode ser uma boa opção. Alguém uma vez descreveu o uso de uma estrutura CSS como "ter um designer olhando por cima do ombro, cutucando você para boas práticas". Você não precisa herdar o design visual dessas frameworks, mas para um desenvolvedor sem um fundo de design forte, pode ser realmente útil saber quantas fontes usar, quais são diferentes estados de botão e como são as formas intuitivas.

Aplicativos de monolitos completos: Muitas estruturas full-stack, como Ruby on Rails, Meteor.jse Django, vêm com seus próprios motores templating, que tornam HTML no servidor. Renderização do lado do servidor e arquitetura monolito são conceitos que merecem seus próprios posts no blog, mas você pode pensar nessa opção como escolher uma estrutura de pilha completa para todo o seu aplicativo e escrever a camada de apresentação e a lógica do servidor dentro de uma única base de código. A maioria das estruturas de pilha completa permitem que você conecte as estruturas front-end de sua escolha, mas padrão você usar seus próprios motores templating. Esta é uma boa solução se você quiser dobrar o uso de uma única estrutura para todo o seu aplicativo; também pode ser uma maneira rápida de protótipo de um aplicativo full-stack.

Em conclusão

As estruturas front-end são uma ferramenta poderosa para o desenvolvimento de interfaces complexas de usuário. Eles encorajam você a construir uma arquitetura autônoma, modular e autônoma que facilita a construção de seu aplicativo e a colaboração com outros desenvolvedores. Estruturas populares são apoiadas por comunidades de apoio, uma riqueza de documentação e tutoriais, e oferecem código testado em batalha que aborda desafios comuns que as extremidades dianteiras representam à medida que escalam. Frameworks permitem que você toque nos recursos mais modernos do JavaScript e ofereça ferramentas que facilitem para protótipos de aplicativos. Finalmente, eles te capacitam com uma linguagem compartilhada para discutir sua arquitetura e desafios.

As estruturas front-end e as bibliotecas vêm em muitas formas e tamanhos — você pode usar uma estrutura de interface do usuário completa para construir toda a sua parte frontal, implementar uma biblioteca CSS para apertar seu design visual ou usar um mecanismo de templating para criar componentes reutilizáveis.

No entanto, uma estrutura front-end pode ser um exagero para projetos e protótipos menores, e a curva de aprendizado íngreme, juntamente com o ecossistema JavaScript em rápida evolução, pode dificultar a implementação em um projeto jovem. No final do dia, você deve implementar uma estrutura popular se você estiver animado para aprender sobre princípios de design bem testados, esperar que sua frente em escala ou precisar protótipo rapidamente quando o desempenho não é uma grande preocupação. Se você gosta de entender completamente cada parte do seu aplicativo, ou não quer aprender uma nova tecnologia, então provavelmente não é a melhor opção.

Espero que essa visão geral tenha lhe dado uma ideia dos problemas que uma estrutura front-end resolve, e se é o ajuste certo para o seu próximo projeto. Como tem sido sua experiência com frameworks front-end? Qual é o seu quadro de escolha? Ansiosos por seus comentários abaixo!

O Avance Network é uma comunidade fácil de usar que fornece segurança de primeira e não requer muito conhecimento técnico. Com uma conta, você pode proteger sua comunicação e seus dispositivos. O Avance Network não mantém registros de seus dados; portanto, você pode ter certeza de que tudo o que sai do seu dispositivo chega ao outro lado sem inspeção.