VOLTAR
O crescimento explosivo da Web, que teve início há cerca de 10 anos, causou uma grande confusão no mundo da Internet. Não só tornou possível fazer mais coisas no browser, como também mudou a visão geral do desenvolvimento de aplicações. No entanto, esta abordagem exigiu algumas melhorias na manutenção do código das aplicações baseadas no browser. Esta foi a altura do desenvolvimento das primeiras estruturas de front-end. Hoje vou analisar duas delas ao microscópio.
Paremos por um momento e pensemos onde estamos. Sendo eu um boomer total, duvido sinceramente que há cerca de 10 anos alguém pudesse prever que desenvolvimento web iria tão longe.
As aplicações de ambiente de trabalho utilitárias são uma coisa do passado porque tudo pode ser feito num browser. De facto, as aplicações que precisam de utilizar APIs de nível inferior que não estão disponíveis no navegador são também escritas utilizando motores e linguagens de navegador, porque isso facilita a sua manutenção.
As aplicações móveis podem ser facilmente substituídas por ferramentas utilizadas para o desenvolvimento Web - ver React Nativo, NativeScript. Além disso, temos o PWA, que "imita" facilmente o funcionamento das aplicações móveis. Adicionalmente, os componentes que alimentam uma aplicação escrita em Vue ou React pode facilmente partilhar vários código elementos entre plataformas.
Temos de admitir uma coisa: as aplicações Web são atualmente uma potência que será difícil de reduzir para o rés do chão. Como utilizador, vejo-me a utilizá-las praticamente em todo o lado: a comunicar via Slack, a utilizar um editor de código, a fazer apresentações ou mesmo a escrever um artigo num blogue.
É difícil prever o que acontecerá dentro de alguns anos. O WebAssembly está a entrar em ação e vai permitir nós para transferir as aplicações que requerem cálculos mais complexos para o mundo do browser. No entanto, há um facto que se mantém inalterado - é realmente difícil encontrar um obstáculo para construir, com a utilização de tecnologias Web, uma aplicação com a qual só podemos sonhar.
Vamos voltar ao passado por um momento, antes de aparecerem as primeiras estruturas Web mais significativas e de as aplicações serem desenvolvidas de forma imperativa. Cada mecanismo interativo de uma página era tratado manualmente e era responsável por uma ação específica.
O melhor exemplo que pode ser citado é a biblioteca jQuery - na altura, uma das soluções mais populares para lidar com eventos simples. Com a sua ajuda, foram implementados vários menus pendentes, transições, animações, calculadoras e mecanismos semelhantes.
Vale a pena mencionar que já nessa altura se notavam problemas em aplicações mais complexas - em locais onde partes diferentes e independentes tinham de, por exemplo, reagir a um clique adequado ou à digitação de algo. A maioria das aplicações não tinha um estado explícito e, em vez disso, era salva, por exemplo, pelos atributos dos elementos ou pelas classes que possuíam.
Na altura, era evidente que a abordagem atual carecia de reatividade - uma forma estruturada de os componentes comunicarem entre si e partilharem, por exemplo, o seu estado ou diferentes eventos, o que tornava as aplicações mais fáceis de manter e lhes permitia proporcionar uma boa experiência de utilizador a baixo custo.
Com o tempo, começaram a surgir no horizonte as primeiras frameworks de front-end, com o objetivo de estruturar a arquitetura para aplicações mais complexas.
Essas estruturas baseavam-se principalmente no padrão MVC - algumas sugeriam uma abordagem mais manual, como o Backbone.js, enquanto outras, como o Knockout.js, utilizavam a ligação de dados bidirecional.
No entanto, é possível sentir que escrever a aplicação foi mais difícil, exigiu muito mais codificação e não produziu necessariamente os resultados pretendidos ou compensou o tempo perdido no desenvolvimento da aplicação.
A principal razão pela qual foi difícil encontrar a média dourada no ecossistema JS foi o facto de esta ser um pouco estranha entre os conhecidos linguagens de programação que há muito têm os seus caminhos pavimentados.
E eu não quero me alongar aqui sobre exatamente quais caminhos acompanharam o desenvolvimento de vários frameworks ao longo da história. No entanto, é importante notar uma coisa - o tempo de maturação do ecossistema JS nos browsers não foi fácil e enfrentou muitas provações.
Esta é a única razão pela qual, atualmente, podemos criar aplicações Web e desenvolvê-las de uma forma muito fácil e indolor.
Em vez de atirar carne para o ar, como é habitual na Internet, vamos analisar as duas bibliotecas, recolher informações sobre elas e compará-las - tanto na teoria como na prática.
NOTA: A descrição dos mecanismos que funcionam em Vue refere-se especificamente à versão 2. A versão 3 introduz muitas alterações significativas, mas não é um verdadeiro concorrente do React neste momento, quanto mais não seja devido à sua maturidade - Vue 3 data de lançamento: 18 de setembro de 2020.
Vamos esclarecer uma coisa - ao aprofundar as duas bibliotecas, pode ver que, na verdade, existem mais semelhanças do que diferenças. Deixando de lado a maneira de usar as bibliotecas como tal - ambas têm conceitos muito semelhantes de como funcionam. Ambas são alimentadas por um ecossistema semelhante e a sua utilização não é diametralmente diferente.
O diabo está nos pormenores - quanto mais frequentemente utilizamos uma ferramenta, maiores são as desvantagens das suas diferentes soluções. Um bom exemplo pode ser a ligação de dados bidirecional, que é mais frequentemente utilizada em Vue como uma propriedade v-model: muitas vezes facilita as coisas, trata de muitas coisas automaticamente e não requer a codificação de suporte adicional para a alteração de valores.
No entanto, há casos em que é necessário seguir especificamente uma tentativa de alteração e reagir em conformidade, caso em que os componentes baseados no modelo V nos obrigam frequentemente a mexer noutros Vue mecânicas como a propriedade computorizada, fazendo com que o efeito obtido pareça frequentemente muito pior do que com uma abordagem manual;
Outro aspeto interessante é o JSX, que é uma forma "vagabunda" de modelar conteúdo renderizado utilizando React. Tem opiniões diferentes na comunidade de programadores.
De acordo com as minhas observações, parece que os programadores que utilizam um ambiente diferente do JS, por exemplo PHP ou C#, estão mais inclinados a modelar vistas de uma forma que Vue faz.
Resumindo - modelos conhecidos de Vue permitem definir vistas de uma forma muito clara e elegante, enquanto o JSX do React permite construí-las, em muitos casos, de forma mais rápida, adaptada a necessidades específicas e, frequentemente, requer menos código para construir estruturas diversas;
Vejamos também os ecossistemas destas duas ferramentas. Em princípio, podemos dizer que não diferem em nada. Ambas são chamadas de bibliotecas por uma razão - elas fornecem o mínimo necessário para o suporte de aplicações Web reactivas.
O resto, relacionado com a comunicação com a API, o fluxo de dados, os componentes da IU utilizados em diferentes subpáginas, são os chamados fornecedores - bibliotecas retiradas do exterior, que têm de ser corretamente ligadas ao projeto. É um pouco como o mundo do Lego: se quisermos construir um todo coerente, temos de o juntar a partir de pequenos blocos individuais.
Esta alegoria refere-se precisamente aos componentes ligados, que são o poder das aplicações criadas com React ou Vue;
Um aspeto importante, especialmente para as pessoas que não têm muita experiência no ambiente JS, é o nível de entrada numa determinada biblioteca. Por outras palavras - a complexidade da ferramenta, que consiste no tempo direto que é necessário despender para compreender a sua mecânica.
Penso que há uma coisa que tem de ser inequivocamente afirmada aqui - no caso de Vueé muito mais simples. Temos uma ligação de dados bidirecional, temos um modelo elegantemente especificado que é enganadoramente semelhante a soluções noutras linguagens, por exemplo, twig, e finalmente - não temos dores de cabeça causadas pela aprendizagem de teorias sobre o funcionamento de ganchos individuais e casos em que devem ser utilizadas mecânicas específicas.
Seguir diretamente a voz da multidão não é exatamente uma boa escolha. No entanto, um bom passo para tomar uma boa decisão é analisar o que dizem as pessoas que interagiram com estas bibliotecas.
E sim - estrelas no github pode ser um indicador do grau de envolvimento da comunidade de uma determinada biblioteca no seu desenvolvimento, da forma como é percepcionada pelos criadores e do seu interesse no rumo que está a tomar. Engenheiros que iniciam um determinado repositório recebem frequentemente notificações sobre novas versões ou alterações de código, o que se traduz no seu conhecimento direto da biblioteca.
No entanto, o número de estrelas no github não deve ser visto como um oráculo - nem todos os programadores que gostam de uma ferramenta deixarão uma marca - em vez disso, considero-o um sinal de pura paixão que os programadores têm por um determinado projeto de código aberto.
Google Trends é um serviço bem conhecido que nos permite estudar o interesse por temas específicos ao longo do tempo. Embora não seja um indicador racional de qualidade ou de utilização, pode fornecer todo o tipo de análises.
É fácil ver que o curso dos últimos 5 anos foi traçado de forma bastante semelhante quando se trata de comparar os dois protagonistas do artigo de hoje. A conclusão básica que se pode tirar do gráfico é que React é superior no que respeita à popularidade de pesquisa em relação ao seu adversário.
Para ser claro - estar no topo do Google Trends não significa que uma biblioteca seja melhor. Tem a ver com a popularidade do público, como já referi - provavelmente mais pessoas ouviram falar desta ferramenta, pode ter despertado mais interesse entre CTOs, programadores de software ou pessoas que apenas querem aprender uma determinada ferramenta.
Este gráfico reflecte-se na realidade? De certa forma, sim. De um modo geral, entre as pessoas inquiridas, há mais pessoas que revelam conhecimentos diversificados e sofisticados sobre React do que Vue. Que opiniões se podem obter ao falar com estas pessoas? Tentarei descrever isto no próximo parágrafo.
Estado de JS é um site que todos os anos realiza inquéritos a pessoas que trabalham em tecnologias relacionadas com o JavaScript. O seu objetivo é recolher informações dos programadores sobre a forma como vêem as ferramentas com que trabalham diariamente.
As perguntas abrangem ferramentas individuais para diferentes objectivos - por exemplo, ferramentas utilizadas no front-end e no back-end, mas também ferramentas para testes, gestão do estado da aplicação, etc. Cada uma destas perguntas não é uma simples resposta sim/não, o sítio coloca uma série de questões sobre a própria ferramenta, interesses, experiências e uma avaliação global que se resume à frase "Utilizaria esta ferramenta em projectos futuros?"
O próprio site permite-lhe fazer muitas análises, comparar ferramentas relevantes e, por vezes, descobrir bibliotecas menos conhecidas que estão a começar a ter sucesso no mundo JS, ganhando popularidade e desfrutando de uma elevada taxa de "felicidade de utilização". Encorajo-o sinceramente a navegar pelo conteúdo deste sítio.
Vamos resumir a secção com estatísticas. A análise de diferentes tipos de gráficos pode muitas vezes ser uma boa opção para comparar diferentes aspectos de determinados tópicos. No entanto, é importante ter em conta que seguir a voz da multidão não será necessariamente a coisa mais inteligente a fazer. Em vez disso, pode tomar uma decisão informada utilizando algumas das lições aprendidas com a análise de gráficos.
Anteriormente, referi o limiar de entrada mais baixo para Vue - De facto, permite-lhe concentrar-se um pouco mais rapidamente no desenvolvimento real da aplicação, utilizando a ferramenta e reduzindo ao mínimo o tempo necessário para se familiarizar com o ambiente, a mecânica e os vários casos de utilização.
Em geral, a minha opinião é que Vue é mais adequado para pessoas que ainda não lidaram com bibliotecas de front-end. Certamente que lhe permitirá, de uma forma mais encorajadora, obter resultados satisfatórios num curto espaço de tempo.
No entanto, digamo-lo em voz alta - a falta de conhecimento da linguagem em que utilizamos ferramentas específicas irá prejudicar-nos mais cedo ou mais tarde. É um elemento insignificante para coisas simples, mas à medida que a complexidade das aplicações criadas aumenta, será cada vez mais difícil construir aplicações de forma decente sem um bom conhecimento de JavaScript.
Não me refiro propriamente a ser capaz de escrever algumas funções sofisticadas, porque esta parte pode ser largamente substituída, por exemplo, por fornecedores. Refiro-me a alguns erros comuns que podem ser cometidos na linguagem e ao facto de não se ter consciência de que o comportamento incorreto não se deve à utilização da biblioteca, mas sim à utilização da linguagem. O erro mais comum que se manifesta aqui é a chamada imutabilidade - ou seja, o conhecimento do mecanismo de referência no JavaScript.
Não sou capaz de sugerir qual a melhor biblioteca para programadores mais ou menos familiarizados com o JavaScript. Mas uma coisa eu sei - se quiser ter uma ideia real de como é o desenvolvimento com ambas as ferramentas "por dentro" - tente escrever aplicações em cada uma delas. Isto dar-lhe-á uma ideia, permitir-lhe-á ver quais os mecanismos que lhe agradam mais e qual a melhor escolha para si.
Como referi anteriormente, ambas as bibliotecas são alimentadas por ecossistemas semelhantes e têm visões semelhantes sobre a criação de aplicações com pequenos componentes. Ambas as bibliotecas estão a ter bons resultados - não há qualquer indicação de que alguma delas vá desaparecer num futuro próximo. Consequentemente, as ofertas de emprego em ambas as bibliotecas manter-se-ão a um nível semelhante.
As conclusões são simples - utilize o que lhe convém; acumule experiência e avalie. Isto ajudá-lo-á a desenvolver uma abordagem racional para saber se é melhor utilizar uma ou outra biblioteca num determinado projeto; além disso, tente experimentar - nada ensina tão profundamente como os erros cometidos no passado.
Não é segredo que não existe um meio de ouro que seja a melhor solução para um determinado projeto. Especialmente no front-end, as ferramentas utilizadas para criar aplicações envelhecem rapidamente e, muitas vezes, é difícil encontrar as últimas tendências.
No entanto, a escolha da tecnologia não é, ou pelo menos não deveria ser, uma questão de saber o que se enquadra nas tendências actuais. Em vez disso, devemos orientá-la para expectativas e pressupostos específicos sobre a aplicação que vamos construir. Cada uma das bibliotecas comparadas tem os seus pontos fortes e fracos, que, combinados com o caso de utilização, nos permitirão fazer a escolha mais razoável.
Uma opção interessante pode vir a ser os resumos tecnológicos de grandes empresas, que descrevem frequentemente os seus casos de utilização, como foi ou está a ser o desenvolvimento de grandes aplicações e quais os erros que cometeram no passado. Talvez encontremos entre eles casos que sejam particularmente interessantes no contexto da escolha de uma biblioteca para um determinado projeto.
As caraterísticas que devemos considerar para escolher as ferramentas certas para a aplicação que está a ser construída são: o tempo de desenvolvimento da aplicação, a facilidade de manutenção da aplicaçãoA complexidade da aplicação e a experiência dos programadores na utilização de bibliotecas específicas.
Os programadores são as pessoas que passam mais tempo nas ferramentas que comparo e são eles que podem dar os melhores conselhos e ajudá-lo a fazer a melhor escolha no grande choque de bibliotecas. É durante o desenvolvimento da aplicação que se vêem os vários problemas que surgem diretamente da escolha da tecnologia e se tem a melhor visão dos aspectos que prejudicam a utilização de uma determinada ferramenta para determinadas funcionalidades.
Como mencionei anteriormente - ambas as bibliotecas não parecem estar a desaparecer do mercadoPelo menos, não nos próximos anos. Em vez de tomar decisões com base em estatísticas e opiniões
de várias pessoas da Internet - talvez uma melhor opção seja simplesmente falar com os criadores.
Apresentar-lhes o que se espera da aplicação, o tempo de que dispomos para a entregar e permitir uma troca de opiniões sobre o que pensam das duas soluções antes de tomarmos a decisão final.
As guerras na Internet são normalmente - ou talvez em todos os casos - inúteis. Haverá sempre pessoas que teimarão em afirmar que a sua escolha é a melhor, sem apresentar quaisquer argumentos racionais que confirmem a sua decisão.
Em vez de nos deixarmos cegar por escolhas específicas - concentremo-nos na análise, tentemos tirar conclusões adequadas e utilizemo-las para ajustar ou rejeitar uma solução específica.
Tal como o título indica - não pretendo coroar nenhuma biblioteca em particular como a cura para todas as dores. Em vez disso, são apresentadas algumas hipóteses e revelados os pontos fortes e fracos de ambas as bibliotecas. Dei alguns conselhos sobre o que procurar ao escolher entre elas, de modo a tomar uma decisão sensata e não ser guiado por tendências ou pessoas aleatórias da Internet.
Cada ferramenta pode ser suficientemente adequada às necessidades do projeto. Nenhuma delas desaparecerá rapidamente do mercado nos próximos anos. Ambas têm comunidades poderosas e bastante maturidade, o que nos mostra que estas duas ferramentas estão a ter um bom desempenho.
A escolha final está nas suas mãos. No entanto, se tiver dúvidas ou quiser discutir o seu caso com o The Codest, não hesite em contactar-nos!
Ler mais:
Porque é que deve (provavelmente) utilizar Typescript
Portuguese 
English 
German 
Swedish 
Danish 
Norwegian 
Finnish 
French 
Polish 
Arabic 
Italian 
Japanese 
Spanish 
Dutch 
Estonian 
Greek 
Czech