O ecossistema front-end é notoriamente complexo. Em todos os níveis, parece haver padrões incompatíveis e concorrentes.
Não existe um sistema universal de importação . Módulos ES, CommonJS, Definição de Módulo Assíncrono (AMD) e Definição de Módulo Universal (UMD) são maneiras diferentes de importar ou compartilhar código. Os empacotadores tentam resolver esse problema oferecendo suporte a vários métodos. Mas o código passa por múltiplas camadas de compactação, ofuscação e tradução. TypeScript é compilado em JavaScript. O código na rede é compactado (para reduzir a largura de banda da rede) ou ofuscado (para evitar cópia). O mapeamento de origem pode resolver alguns desses problemas, mas é outra coisa a configurar. Obter o rastreamento de pilha correto pode ser complicado. Isso requer coordenação entre linguagens, ferramentas e tempos de execução.
Ambiente extremamente diferente . Um recurso e um bug. Espera-se que o código front-end seja executado em qualquer lugar - não apenas no navegador. Os contextos e APIs disponíveis em diferentes ambientes variam e é difícil saber quais contextos estão disponíveis para você (e muito menos saber o que as bibliotecas que você está importando assumem). Este código será executado no servidor? Este código será executado no cliente? Isso é difícil para os desenvolvedores (que código posso usar) e difícil para os mantenedores de bibliotecas (para quais ambientes devo otimizar meu código?).
Ênfase exagerada na estrutura de arquivos . Muitas ferramentas front-end dependem da estrutura do projeto para seu comportamento. A configuração deve estar no diretório raiz do projeto (resultando em uma longa lista de tailwind.config.js, postcss.config.js, eslint.config.js, next.config.js, etc.). A estrutura de arquivos é um mal necessário para importar código, mas no front end ela faz muito mais. Pode ser uma API que roteia um arquivo específico para uma página da web, seja como uma API, ou como uma página da web estática, ou como uma página da web regenerada dinamicamente. Eles são convenientes, mas às vezes pode ser difícil depurar e descobrir partes da base de código.
Inferno de configuração . Existem muitas ferramentas disponíveis prontas para uso. Há muito tempo temos o create-react-app, um kit de ferramentas aclamado que integra muitas dessas ferramentas para fornecer aos desenvolvedores uma configuração utilizável desde o início. No entanto, se você se desviar desse caminho dourado, ficará preso a mais de 20 ferramentas de desenvolvimento e interações complexas. Quase todas as ferramentas estão em conflito com outras ferramentas. ESLint (ferramenta de inspeção de código) e Prettier (ferramenta de formatação de código) geralmente entram em conflito.
Desequilíbrio de desenvolvimento . Ter tantas etapas entre o código e a implantação significa que o desenvolvimento de recarga a quente costuma ser complexo. Isso levou a ferramentas como o webpack-dev-server, que resolve a maioria dos problemas para você. Mas cuidado com a magia. Existem tantas suposições incorporadas nesses servidores de desenvolvimento que eles podem rapidamente desviar-se do comportamento de produção.
Texto original: https://matt-rickard.com/why-is-the-frontend-stack-so-complicated
Autor: Matt Rickard