Desde criança eu gosto de corridas de carros. Sempre tive jogos desse tipo - como o Gran Turismo, Forza Motorsport, NFS, F1… eu também tentava seguir os torneios.
Me lembro de jogar com meus primos aqueles eventos de resistência no Gran Turismo, corridas de 24h ou com 400 voltas. Nós revezávamos pra jogar, pra evitar o cansaço e também para tentar ganhar a corrida.
E, me lembrando desses velhos (e bons) tempos eu penso no desenvolvimento front-end quase como um daqueles eventos de resistência - o evento é o seu projeto, o carro é o seu ferramental, e a linha de chegada é o prazo do projeto, ou a data de entrega.
Se continuarmos com a metáfora, podemos ver algumas semelhanças entre os dois mundos - nós temos os desenvolvedores novatos e os experientes (assim como os pilotos), nós temos ferramentas rápidas e outras devagar (os carros), nós temos times e lideranças fortes ou fracas (as equipes), também temos as tarefas fáceis e mais complexas (assim como os circuitos), e quem ganha no final é quem tem mais equilíbrio - não o mais rápido nem o mais forte.
Frameworks de front-end são como carros de corrida - temos vários deles, cada um com suas funcionalidades, comunidades e documentações. Alguns deles são bem fortes, fáceis de usar e podemos fazer quase tudo com eles - outros, em contrapardida, são devagares, difíceis de usar e podemos fazer pouca coisa com eles.
Desde o surgimento do ES2015 (ES5, ES6 - sempre me perco) vimos o surgimento de vários novos frameworks JS - React, Vue, Angular, Svelte, Ember, Polymer, Meteor, Node… Existem vários, e a cada dia surge um novo (que diz que vai resolver os problemas do mundo todo). Também temos muitas coisas legais feitas com essas ferramentas; e coisas horríveis. Então, qual é a diferença entre essas coisas legais e as horríveis?
Podemos apontar várias - UX, a arquitetura, o bundler, problemas de performance, suporte, até mesmo os desenvolvedores (que eu evito comparar). Mas, acredito que a principal diferença que nós podemos (e temos que) apontar é o valor entregue - o problema que foi resolvido.
Se o carro é rápido, não significa que ele vai ganhar a corrida. Assim como um framework - você não vai resolver problemas e entregar valor só porque o framework que você usa é rápido ou tem uma comunidade grande. Além da capacidade do framework - o que é importante - temos que considerar o que o seu time consegue fazer com ele. Nem todo mundo consegue vencer uma corrida só porque tem uma Ferrari em mãos.
Para vários usuários (a maioria deles), não importa a arquitetura que você usou, ou qual ferramenta que você usou para gerar o bundle. Eles se importam com o suporte, com a forma que o seu sistema se comporta no smartphone ou com uma rede ruim, eles se preocupam se vão conseguir resolver algum problema usando sua ferramenta.
Outro grande ponto que podemos apontar nessa metáfora é: corridas de resistência exigem experiência, resiliência e esforço/aprendizado contínuo. Você precisa saber quando acelerar ou frear, quando tentar uma ultrapassagem, quando forçar o motor e quando parar para reabastecer… Da mesma forma você precisa saber quando usar a ferramenta X ou Y, quando acelerar seu time, quando entregar novas features ou quando removê-las…
Tanto nas corridas quanto no desenvolvimento, a única forma de ganhar experiência é fazer as coisas; e isso leva tempo, porque você não vai dominar nada do dia para a noite. Cada um tem seu ritmo, então tente criar uma rotina diária para aprender algo novo, ou algo diferente.
Você não ganha a corrida quando quer, mas somente quando ela acabar. E você não vai alcançar o sucesso quando quiser, mas sim quando as pessoas verem o valor que a sua ferramenta/seu app/seu sistema oferece.
Eu tenho visto várias “brigas” entre desenvolvedores - um fala que o React é melhor, outro fala que é o Vue; um fala que o WordPress é ruim e não vai usar… Cada desenvolvedor tem suas preferências - uns gostam de React, outros de Angular; mas, a discussão certa seria “você consegue entregar valor usando essas ferramentas?”.
Eu tenho minhas preferências, e elas mudam (bastante) durante o tempo; sempre tento não ficar parado com apenas uma tecnologia, ou ficar muito acomodado com uma ferramenta em especial. Nos últimos anos meu mantra é: “quanto mais simples, melhor”.
O desenvolvimento de software é feito pra ser simples - se não é, tem algo errado. Eu não estou falando sobre a complexidade de uma linguagem, ou de uma arquitetura - estou falando sobre fazer coisas bem feitas, que resolvem problemas.
Então, falando sobre ferramentas, uma boa dica que eu posso dar é escolha a que melhor se encaixa na sua necessidade. Se é React, vá em frente; se é Vue, vá em frente… Não tente fazer escolhas baseadas em opiniões alheias, ou baseada em um blog post que mostra resultados maravilhosos. Não existe nenhuma bala de prata.
Quando um piloto precisa conhecer o carro, ele vai testá-lo; quando você vai comprar um carro, você vai testá-lo; e quando você está escolhendo uma ferramenta, você também precisa testá-la.
Uma forma legal para testar ferramentas é criar POCs - ou Prova de Conceito. Se você não está familiarizado com isso, basicamente fazer uma POC é criar a parte mais crítica do seu projeto, usando o maior número de possibilidades. Depois de fazer isso, você chegará a um veredíto sobre qual é o melhor caminho para seguir.
Quando você fizer uma POC, anote tudo o que você observar - performance, tempo de scripting, tempo de build, a dificuldade durante as tarefas, como foi a configuração do projeto… E, no final, veja qual alternativa melhor se encaixa no que você precisa fazer. Não tem segredo!
Fazendo isso, você irá garantir que está seguindo o melhor caminho, fazendo as coisas certas e, ao seu lado, você terá uma grande possibilidade de ganhar a corrida!
