Reclamações contra a complexidade das configurações de ferramentas de desenvolvimento da web modernas têm aumentado nos últimos anos, à medida que a plataforma da web continua a evoluir e inovar. Uma iteração recente desse movimento em direção à simplicidade é chamada de abordagem “stackless” (ou “framework-less”), cunhada por Daniel Keyhoe de yax.com .
Os princípios básicos da abordagem sem pilha são:
- Conheça recursos e padrões com suporte nativo da plataforma da web
- Evite construir ferramentas e estruturas usando pacotes npm servidos por CDN em vez disso
- Use componentes da web
O sentimento central da utilização de padrões é admirável e, de fato, pode ser suficiente para projetos ou protótipos muito pequenos, mas aqui estão alguns motivos pelos quais essa abordagem é inviável na prática para desenvolvimento web profissional ou projetos de tamanho material.
Frameworks nunca irão embora
Frameworks desempenham um papel crítico no ecossistema de front-end. À medida que a plataforma da web avança, também avançam as estruturas que se baseiam nela. Eles servem como um espaço crítico para inovar e informar a direção futura dos padrões da Web.
As estruturas são construídas para superar as deficiências dos recursos padrão até que novos recursos padrão sejam introduzidos para preencher as lacunas. Eles podem se mover mais rápido do que os padrões e podem experimentar recursos para ajustá-los e validá-los antes de serem propostos e adotados pela plataforma. Um exemplo disso foi a revolucionária função jQuery (comumente chamada de $ ) nos anos 2000 e 2010, que informou diretamente o que conhecemos hoje como document.querySelectorAll .
Stackless tem muitas limitações
Para crédito de Keyhoe, as limitações da abordagem sem pilha são claramente reconhecidas em os tutoriais introdutórios . Infelizmente, eles são proibitivamente graves para muitos tipos de projetos modernos de desenvolvimento da web.
A persistência de dados é ignorada
Talvez a maior omissão na abordagem sem pilha seja que ela não leva em consideração a persistência dos dados. A abordagem fala sobre abandonar Rails para JavaScript baseado em padrões, HTML e CSS, mas Rails resolve um problema diferente das tecnologias de navegador front-end.
Que tal uma API para ocultar lógicas de negócios confidenciais ou proprietárias do front-end? E quanto à persistência de estado centralizado? E a autenticação do usuário? Existem tantos problemas e paradigmas comuns que a abordagem sem pilha simplesmente não leva em consideração.
O uso de”funções”(significando funções sem servidor ou Lambda) é mencionado de passagem, mas se você estiver usando funções sem servidor apoiadas por um banco de dados ou outro armazenamento, de repente você terá uma”pilha”novamente.
CSS é de nível muito baixo para autorizar a manutenção sem uma estrutura
CSS é poderoso e repleto de recursos, mas em favor da flexibilidade, ele carece de restrições adequadas para guiar os engenheiros em direção a soluções de fácil manutenção ou de contribuição dos membros da equipe.
Mesmo com ferramentas poderosas como pré-processadores CSS, o tópico de manter CSS sob controle e bem documentado é um ponto comum de discussão para equipes de software. Mesmo a abordagem sem pilha recomenda o uso de uma estrutura CSS no bom imprimir. Isso é semelhante ao título de um artigo “Como fazer um tour pela América a pé” e, em seguida, no parágrafo principal, escreva: “Até descobrirmos uma maneira de andar mais rápido, é só usar um carro”.
A gestão do estado não é contabilizada
Os componentes da web são mal equipados para gerenciar o estado complexo necessário para construir um aplicativo front-end avançado. A abordagem sem pilha pode funcionar para sites informativos simples, mas para aplicativos com interfaces de usuário complexas, o gerenciamento de estado torna-se difícil de manejar sem a ajuda de uma estrutura ou biblioteca de gerenciamento de estado.
Esta é a segunda vez que a resposta para “como construir um aplicativo sem uma estrutura” é “na verdade, apenas use uma estrutura”. Existem muito poucas classes de aplicativos que são úteis e não requerem o gerenciamento de estados complexos.
A complexidade não é resolvida
O principal problema com a abordagem sem pilha é que ela tenta abandonar a complexidade sem uma proposta sobre para onde essa complexidade deve ir. A complexidade, em geral, não pode ser eliminada-só pode ser empurrada para diferentes partes do sistema. Aqui estão alguns exemplos:
APIs de hipermídia vs APIs RESTful personalizadas. APIs de hipermídia retornam os dados relevantes para o recurso, junto com links para recursos de API relacionados que o cliente deve solicitar posteriormente. A complexidade de montar a imagem completa é enviada ao cliente.
Uma API sob medida, por outro lado, pode lidar com a complexidade de reunir todos os dados relevantes antes de devolvê-los ao cliente em um pacote único e organizado. A complexidade de reunir os dados necessários pode ser mudada, mas não eliminada.
create-react-app e react-scripts . A equipe do Facebook por trás do React tentou abstrair a complexidade de manter webpack e outra configuração para inicializar um aplicativo React o mais rápido possível. Isso permite que os engenheiros criem um aplicativo React totalmente funcional sem ter que se preocupar com a instalação e configuração de todas as ferramentas; eles só precisam instalar o pacote react-scripts .
A complexidade da ferramenta de construção não foi embora, sua carga apenas foi transferida para as dependências do aplicativo, em vez de nos ombros do engenheiro que está criando o aplicativo.
Resgatando qualidades do caminho sem pilha
Embora o uso da abordagem sem pilha possa não ser viável para projetos maiores do que hobbies ou protótipos, existem alguns pontos excelentes em sua filosofia que podem beneficiar projetos de software, independentemente da abordagem que eles usam.
- “Usuários são os usuários.” O foco nas necessidades dos usuários, onde a definição de usuários é literalmente os usuários finais do software, é um ponto crítico que os desenvolvedores devem ficar o mais próximo possível. É apenas mantendo os usuários em mente que os aplicativos podem ser projetados com empatia e com atributos críticos como desempenho e aprimoramento progressivo em primeiro plano.
- “Siga os padrões”. Uma das melhores características da web é que ela avança em padrões abertos e um espírito infalível de compatibilidade com versões anteriores. Os autores e os usuários de frameworks devem adotar e utilizar recursos padrão o máximo possível (sem medo de usar tecnologia não padrão, como frameworks, quando isso permite que construam um software melhor com mais rapidez).
- “Adote a simplicidade sempre que possível.” A ideia de usar a melhor e mais simples ferramenta para o trabalho é difundida na abordagem sem pilha e, de fato, faz parte do DNA central da web. É fácil para os engenheiros cair na armadilha de soluções de”engenharia excessiva”para problemas que acabam criando mais problemas por conta própria; é preciso disciplina e sabedoria para evitar essa armadilha.
Use stackless onde fizer sentido
Como qualquer outra ferramenta, a abordagem sem pilha pode ser uma filosofia útil ao abordar um problema. Se você precisa construir um aplicativo simples em que os recursos da plataforma web bruta sejam suficientes, vá em frente.
Usar a tecnologia menos poderosa capaz de realizar a tarefa ou resolver o problema é uma maneira excelente de criar soluções.
Mas, ao trabalhar em uma equipe ou em um projeto com complexidade até moderada, o aproveitamento de estruturas modernas provavelmente renderá dividendos ao longo da vida do projeto.
A postagem O caso para usar frameworks apareceu primeiro em LogRocket Blog .
