“O Som da Música” pode pregar, “Vamos começar no início, um bom lugar para começar”. Mas quase todos os desenvolvedores sabem que é um plano insensato. O lugar certo para começar é com uma base sólida construída por uma grande equipe de desenvolvedores de código aberto. Clone o trabalho duro deles e depois adicione código suficiente para torná-lo seu. Não há necessidade de repetir o que todos já fizeram antes.
É um plano fácil – desde que você escolha. Infelizmente, escolher essa base pode ser quase tão difícil quanto começar do início. O mundo dos frameworks web é uma área muito ativa de desenvolvimento e pode haver dezenas de bons projetos open source que seriam ótimos inícios para o seu projeto.
Para piorar as coisas, as diferentes equipes que criaram esses diferentes projetos partiram para um caminho diferente porque tinham sérias diferenças filosóficas com as outras opções. Eles olharam para os outros frameworks e decidiram que poderiam fazer melhor. Em outras palavras, eles fizeram isso por uma razão e você pode ou não concordar com a decisão deles.
A lista de bons lugares para começar abaixo deixa intencionalmente fora os líderes de mercado Reagir, Angular e Vue apenas para tornar as coisas um pouco mais simples. Isso não significa que os três grandes sejam maus. Eles ainda podem ser a coisa certa para você. É que eles são falados constantemente e essas discussões deixam de fora outras opções muito boas.
Existem muitas boas razões para escolher as mais populares. Muitas pessoas no seu lugar olharam em volta e muitas delas escolheram React, Angular, ou Vue por uma boa razão. Mas isso foi então. Entretanto algumas pessoas inteligentes criaram novas estruturas mais rápidas, simples, fortes, ou qualquer um dos grandes superlativos.
Na maioria dos casos abaixo, as equipes criaram algo intrigante e poderoso ao reimaginar a natureza da estrutura. Esta é uma forma elegante de dizer que acabaram por apagar uma funcionalidade tornando assim a estrutura mais eficiente e reduzindo assim a quantidade de memória necessária, acelerando o tempo de arranque, ou tornando-a geralmente mais ágil. Ou em alguns casos, eles adicionaram novas idéias que podem se tornar padrão no futuro.
Se você tem tempo para investir, aqui está uma lista de algumas das outras escolhas interessantes. Elas não são necessariamente certas para algumas pessoas e certamente não são a melhor escolha para todas, mas podem ser uma escolha melhor para você. Seu trabalho, se você optar por aceitá-lo, é criar uma descrição sólida do seu aplicativo web, escrever uma descrição relativamente firme dos diferentes casos de uso e, em seguida, avaliar essas ferramentas com isso em mente.
Talvez você goste de uma abordagem específica para projetar código. Talvez seu aplicativo não precise de alguns dos recursos dos frameworks mais populares e mais gordos. Há dezenas de razões para investir em um desses outros caminhos. Você pode descobrir que um deles funciona bem para o seu aplicativo.
Petit DOM
Se você adora a idéia de um DOM virtual, mas não quer todas as restrições que vêm com a adoção da mentalidade do pessoal da React, Vue, ou sua outra grande estrutura de nomes, então o Petit DOM é o caminho a seguir. Você recebe uma pequena quantidade de código que lhe permitirá manipular uma coleção virtual de tags e depois migrá-las para o DOM real. Tudo o resto sobre a estrutura dos componentes e a renderização depende de você. Se seus componentes são simples, ou se você vai criar alguma hierarquia de renderização super-complexa que será somente sua, esta pode ser sua base porque tudo o que ela fornece é uma ferramenta para virtualizar o DOM.
Surplus
O DOM virtual pode não ser para todos. Ele ocupa espaço, portanto, se suas manipulações não forem muito complexas, você pode também canalizar suas instruções para o DOM oficial. A biblioteca de excedentes faz exatamente isso. Ela pega a marcação favorita de todos JSX e a compila em algum código que irá manipular o DOM real. Como dizem no negócio dos anúncios, corta o intermediário. Sem difusão. Nenhuma camada extra secreta. Apenas manipulação pura do verdadeiro DOM. Se o seu código é simples e directo o suficiente para fazer apenas algumas coisas ao DOM, porque se preocupar com a distracção virtual?
RE:DOM
Outra opção para aqueles que não querem investir nenhuma memória num Dom virtual é uma pequena biblioteca (2KB) chamada RE:DOM. RE:DOM contém algumas rotinas básicas que lhe permitem criar todas as suas tags e componentes com algumas chamadas JavaScript simples. A sintaxe é muito mais próxima de CSS, assim você pode especificar tags bastante elaboradas com IDs e classes com apenas alguns toques de tecla. Suas teclas “menos que” (<) e “maior que” (>) lhe agradecerão.
Mithril
Não todas as alternativas são minúsculas e minimalistas. Neste contexto, o Mithril pode ser chamado de uma estrutura “de médio porte”, apesar de pesar apenas cerca de 8KB. Todo esse código constrói um DOM virtual com um mecanismo de atualização eficiente como os outros, mas também vem com um conjunto padronizado de ferramentas para lidar com muitos dos desafios padrão como roteamento e chamadas XMLHttpRequest. Os designers do projeto querem que os projetos Mithril sejam relativamente padronizados, e eles acham que adicionar este código à biblioteca principal aumenta a padronização. Se isso não for suficiente, eles também pressionam algumas formatações padrão e estruturas idiomáticas.
Bobril
Se você gosta do DOM virtual e dos componentes do React e gosta de programar em TypeScript, então Bobril ou seu primo Angular-friendly ngBobril pode ser apenas o bilhete. O framework é consistentemente muito mais rápido que o React ou Angular em alguns dos benchmarks, talvez por causa dos algoritmos de difusão mais rápidos e da falta de suporte ao JavaScript isomórfico. Existem também funções de shorthand para manipulação de CSS e uma camada completa de gerenciamento de estado, BobX, se você precisar.
Marko
Se você tem gasto algum tempo licitando em dispensadores Pez ou outros coletores, você experimentou o poder do Marko, um framework fino e rápido que o eBay está compartilhando através de uma licença de código aberto. A parte mais agradável pode ser uma sintaxe de templates muito leve que remove inteligentemente a maior parte do excesso de gordura do HTML para que a estrutura seja definida por indentação e não muito mais. E o motor de renderização é muito rápido, capaz de conduzir constelações elaboradas de DIVs dançantes que atualizam mais rápido que 60fps.
Svelte
Seu framework web padrão vem com um compilador e uma biblioteca baixada que manipula em tempo de execução o que o compilador produz. O processo de dois passos permite um código muito elaborado ao preço de esperar que a biblioteca em tempo de execução seja baixada e analisada toda vez que a página é aberta. O compilador Svelte se livra dessa complexidade cuspindo perto do puro JavaScript que está quase pronto para rodar sozinho, embora apenas em alguns dos navegadores mais novos (por exemplo, Chrome, Firefox, Opera, e IE10). É um gambit arquitetônico inteligente que produz sites muito leves que ocupam pouca memória.
Inferno
Inferno é outro framework criado para fazer muito do que o React faz, mas com um download menor e um tempo de execução mais rápido. Ele consegue muito disso jogando fora o elaborado mecanismo de eventos sintéticos e concentrando-se apenas nos mais essenciais como o onClick. Muitas outras partes da API são semelhantes se não as mesmas, tornando relativamente simples mover seu código para cima se ele não precisar da camada de otimização de eventos.
Preact
Um dos menores descendentes do React é o Preact, uma homenagem que oferece a maioria dos recursos mais valiosos como um DOM virtual e componentes sofisticados, mas retira os manipuladores de eventos sintéticos e parte da herança de adereços. Enquanto o Inferno tenta implementar apenas os eventos mais importantes como onClick, o Preact não se preocupa em tentar fazer nada com os eventos, deixando-o a confiar no nativo do navegador addEventListener. Deixando de fora funcionalidades que não adicionam muito (na opinião deles) é como eles fazem o download ainda menor. Esta é uma pequena troca porque os benchmarks mostram que o Preact é um pouco mais lento que o Inferno. É claro que a sua aplicação pode ser diferente e a sua quilometragem pode variar. Se você realmente precisa de compatibilidade pura com o React, há até uma biblioteca (preact-compat) que corrige a maioria dos problemas durante a construção.
Hapi
Muitos frameworks chegam em um único pedaço. Hapi é mais uma coleção de plug-ins, uma constelação de dezenas de bits de código que você pode misturar na sua pilha como você achar melhor. Autenticação, autorização e registro são tarefas que podem ser resolvidas com qualquer número de opções. Se você está construindo uma arquitetura de microserviços cheia de APIs, o plug-in Swagger padronizado irá gerar automaticamente a documentação Swagger a partir do seu código básico.
Koa
Algumas vezes você precisa de uma coleção bastante complexa de rotinas que fazem malabarismos com as solicitações de entrada e as traduzem em múltiplas mudanças, algumas delas elaboradas. Koa é projetado para tornar a organização de todo este trabalho um pouco mais simples. Seu segredo é que ele transforma as funções de retorno que normalmente dominam o JavaScript em um conjunto de funções assíncronas que disparam na hora certa. As pilhas de callback do ninho são transformadas em algo um pouco mais limpo.
Nest
Outra opção para domar a complexidade do servidor vem da equipe Nest, que oferece uma arquitetura cheia de controladores, tubos e provedores com alguns guardas, interceptores e filtros de exceção atirados para manter a ordem. O framework é moderno e pronto para lidar com GraphQL e solicitações de microserviço desde o get-go.
Drupal, WordPress e Rails
Frameworks que são construídos em JavaScript e que rodam em cima do Node.js preenchem o centro psicológico do mundo do desenvolvimento web nos dias de hoje. Mas pode ser um erro ignorar a geração anterior construída em PHP, uma fundação que é mais rápida do que nunca agora que também tem um compilador just-in-time como o JavaScript. E Ruby e seu framework Rails continuam a servir como as pedras angulares de websites sólidos como rocha.
A última geração é marcada por uma batalha e bem testada por mais de uma década de desenvolvimento e trabalho contínuo. Há designers sofisticados que podem criar temas e skins para os aplicativos. Há uma boa chance de alguém já ter construído os módulos com a funcionalidade que você precisa. Então antes de explorar uma estrutura inteligente do Node.js, considere se um dos mais antigos já pode fazer muito, se não tudo o que você precisa.
Vanilla JS
Você pode ver isso como uma escavação média ou talvez uma sátira no nível de “The Emperor’s New Clothes”, mas é difícil argumentar com o seu sucesso. Vanilla JS é um site que se gaba de que a sua estrutura é utilizada em mais sites do que “jQuery, Prototype JS, MooTools, YUI, e Google Web Toolkit-combined”. Isto pode ou não ser verdade dada a proliferação do jQuery, mas vamos rir da queima. O site também vem com um seletorzinho engraçado que permite que você junte um arquivo personalizado de diferentes componentes como Matemática, DOM, fechamentos ou expressões regulares. Não importa o que você escolher, o resultado é um impressionante zero bytes de comprimento. Tente bater esse!
O ponto da piada é que às vezes faz sentido usar apenas alguns dos elementos padrão em JavaScript e pular os extras. Bibliotecas e frameworks como jQuery ou React começaram, em parte, por causa das diferenças loucas entre os navegadores. Muitas destas diferenças desapareceram graças à padronização.
Obviamente os defensores do Vanilla JS não confrontam o facto de funções de estenografia como $() não serem apenas convenientes, eles também poupam espaço no nosso próprio código. Mas se você só vai usar o document.getElementById ocasionalmente, isso pode não importar. Se você vai apenas adicionar algumas funções à sua página web e essas funções vão fazer algumas coisas básicas, o JavaScript pode ser o framework mais rápido para você.