Por que eu deveria usar ES6?

Escultura "O Pensador" de Rodin

Eu não sei se já reparou, mas muitos talks sobre Javascript, muitas palestras tanto gringas quanto nacionais estão mostrando em suas apresentações snippets ou pedaços de código já usando as sintaxes do ES6 ou ES2015 ou o que seja.

A primeira coisa que passou pela minha cabeça quando comecei a perceber que já estava sendo bombardeado por essa novidade, foi a questão: Será que eu devo migrar meus códigos para a nova especificação?

O mais espantoso é que embora para mim seja óbvio se perguntar isso, não é fácil encontrar textos sobre este tipo de dúvida. Será que as pessoas não se questionam se deveriam ou não mudar a forma de fazer as coisas? Será que o marketing no front-end hoje está tão forte que as pessoas simplesmente estão seguindo as tendências sem sequer questionar?


Um pouco de filosofia…

Depois de um bom tempo me preocupando mais com códigos e algoritmos, entrei em uma fase de tentar entender mais as pessoas, tentar entender o relacionamento entre as pessoas e comecei a prestar mais atenção no meu próprio comportamento.

É incrível o que você aprende levantando a cabeça, parando de jogar olhando só para a bola, ampliando seu horizonte limitado. Eu acabei percebendo que existem predominantemente 2 tipos de programadores : Early Adopters e Laggards.

É claro que existem outros tipos, mas o que eu quero dizer com predominante é que são estas duas categorias que tendem a ter mais relevância pois são exatamente opostas, e portanto mais propensas à conflitos entre si.

Este post portanto é um post filosófico, ele não possui códigos, ele possui pensamentos, conclusões tiradas exclusivamente através da experiência, a minha experiência.


Os Early Adopters

São aqueles que já abraçam logo de cara uma idéia inovadora, são pessoas que tentam coisas novas, costumam sair mais da sua zona de conforto. E com isso você deve se perguntar se esta característica é uma coisa ruim. Apenas analisando a definição não, mas é a consequência dela ante determinadas ações que pode se tornar nociva.

O problema do Early Adopter é que ele invariavelmente ele acaba evangelizando, tentando transformar tudo aquilo que vê em algo potencialmente passível de mudança para uma determinada tecnologia sem um argumento ou motivo específico. Às vezes esta pessoa pula tanto de tecnologia em tecnologia, que não consegue se aprofundar em nenhuma e acaba esquecendo que precisa de um motivo ou razão pelo qual escolheu certa tecnologia. É movida pela emoção, se gosta é bom, se não é ruim.

Toda tecnologia nova precisa não apenas da sua compreensão, mas também de experiência de uso. O que acontece com o caso extremista é que ele não possui um conhecimento considerável em uma tecnologia, mas tem certeza absoluta de que aquela solução é a melhor.

Dependendo do caso, este tipo de raciocínio pode não fazer sentido ou não ser prático, uma vez que ao alterar um padrão ou uma metodologia outras partes serão afetadas, pessoas precisam aprender a como usar a novidade de forma sã, isto demanda um tempo, demanda experiência, e o tempo custa.

Bom, no meu caso foi um amigo desenvolvedor mais Early Adopter que me vendeu a idéia de que atualizar para ES6 era o melhor a se fazer, há uns 6/8 meses atrás. O projeto que eu trabalhava era grande, código legado etc… É um lugar onde você pensa 10 vezes antes de fazer qualquer tipo de refatoração.

É claro que você já deve ter percebido que existem problemas ao adotar esta tecnologia logo de cara, mas o que realmente me incomodava era a falta de propósitos ou uma argumentação que me convencesse de que isto seria uma boa idéia apesar dos problemas. Bom, não tive nem os propósitos e nem as argumentações, por motivos óbvios, Early Adopters costumam não precisar de motivos, eles apenas seguem o fluxo do mercado, seguem as tendências.

Mas você deve achar que falo com desdém, como se fosse uma criatura superior e diferente das outras ou melhor. Não, todo mundo transita pelas categorias Early Adopter e Laggards em alguma coisa na vida, não é bem ser, é estar. São estados, mindsets .


Os Laggards

Sobre a adoção do ES6 no projeto que trabalhava especificamente eu era um Laggard. Laggards são opostos aos Early Adopters, são aqueles que costumam adotar certas tecnologias ou metodologias tardiamente, acabam ficando mais atrasados com relação às novidades pois costumam não sair muito da sua zona de conforto.

Nesta situação eu estava confortável com meu Javascript, estava começando a entender as arquiteturas equivocadas que cometi, e comecei a pensar em outras formas no que diz respeito à organização do código. Para mim, não fazia sentido mudar, estava confortável naquele momento.

Um engano comum é entender que, ao ler apenas as definições de Early Adopter e Laggard, um tipo seria bom e o outro ruim. Ora, está claríssimo aqui que o vilão é o Laggard, e nosso salvador é o Early Adopter, o mercado pede inovação, coisas novas, ninguém quer o velho, o que todo mundo já sabe.

Ironicamente era mais fácil convencer de que eu estava certo, pelo simples fato de que o Early Adopter não gasta muito o tempo pensando nos por quês. Então, a discussão era fácil de ganhar pois eu tinha o que o Early Adopter costuma não ter, argumentos.

Mudar para nova especificação na minha cabeça impactaria diretamente nos meus colegas, aqueles que não sabiam muito bem js teriam ainda mais dificuldade para entender uma sintaxe completamente nova. Com tantos exemplos na internet com Javascript em formato UMD, AMD, CommonJS usando códigos da sintaxe vigente, o programador mais júnior, aquele que está aprendendo, terá disponível em maior quantidade a literatura usando os exemplos práticos e códigos prontos no modelo "antigo". Uma mudança de sintaxe não iria melhorar em nada o projeto, porque o problema maior era a arquitetura e organização, com uma nova sintaxe apenas iria adicionar uma outra stack no processo.

A mudança de sintaxe tem pouca curva de aprendizado para quem é pleno/sênior, e isto também é subjetivo, pois em algumas empresas um front-end pleno não necessariamente tem facilidade com programação. Se sua empresa trabalha com terceiros, isto impacta na vida deles, muitas vezes você não conhece o nível dos profissionais e ao invés de facilitar a vida deles, está dificultando.


A Real Questão

Você pode rebater e me questionar, dizendo que é o dever de todo programador evoluir e continuar crescendo e aprendendo coisas novas. Eu concordo com você, mas a vida é mais complicada do que isso, o lógico é algo que existe nos códigos, mas a vida real muitas vezes não é regida por lógica a vida nem sempre tem características discretas, há infinitas situações nas quais uma equipe pode se encontrar.

Eu poderia convencer algumas pessoas usando estas argumentações, e o fiz. Mas isto não significa que eu estou 100% certo. E é esse o ponto central deste post. O que eu quero verdadeiramente dizer é que não deveríamos perder isso, o constante questionamento sobre nossos atos, sobre nossos dogmas.

O que é melhor ser então? Não sei. Depende muito da situação, do contexto, como tudo na vida é também uma questão de bom senso. O que não podemos fazer é achar que se para uma determinada situação uma idéia é válida, então isto justifica para todas as outras situações.

É claro que estou fazendo uma analogia aqui com a teoria de difusão de inovações, categorias com as quais você pode se encontrar em um ciclo de aceitação de uma nova tecnologia ou algo inovador, sendo bem rudimentar na explicação, você pode achar mais informações sobre isso aqui.

O que percebi é que o ideal é transitar entre estes ciclos de acordo com o contexto, e tentar permanecer no estado Early Majority no seu estado padrão. Este estado costuma fazer mais sentido para mim, por diversas razões. Posso dar uma razão prática e muito comum. Eu costumo usar o Mac, de tempos em tempos o SO atualiza : Mavericks -> Yosemite -> El Captain.

Geralmente o Early Adopter nesse caso acaba se dando mal. Isso porque ninguém conhece verdadeiramente os riscos desta atualização, bem como as consequências pois cada usuário tem programas diferentes e usam a máquina para propósitos bem diferentes. Então os problemas que enfrentar serão relativamente novos, muitos deles imprevistos, e portanto não é fácil achar uma solução caso precise de uma, finalizando, acabará perdendo tempo com coisas que não deveria estar, e se você escolheu fazer esta atualização enquanto está na deadline de um projeto, meus pêsames.


Early Majority

O desenvolvedor que costuma ser um pouco mais Early Majority reconhece estes problemas por experiência, e acaba adotando uma postura um pouco mais conservadora. Vai dar maior preferência aos motivos pelo qual deve migrar ou mudar sua ferramenta ou tecnologia. Vai esperar, para que todos ou a maioria dos problemas primários sejam resolvidos, ou que suas soluções estejam facilmente acessíveis.


Devo ou não aprender ES6?

Bom, vamos finalmente ao que importa, na minha opinião você deveria aprender ES6, porque:

  • Será o padrão, o Javascript vai ser atualizado eventualmente quer você queira ou não.
  • Muitas features vieram para facilitar, isso vai fazer com que você gaste menos tempo resolvendo problemas de uma linguagem desatualizada.
  • Menos tempo perdendo procurando bibliotecas que cuidam de problemas recorrentes.
  • Hoje o Babel e outros transpilers estão muito mais sólidos do que antes.
  • Grande parte das palestras, principalmente as gringas já utilizam a sintaxe nova, e você pode ter dificuldade em entender alguns exemplos.
  • Se deixar para aprender muito tardiamente, perderá o timming de experiência com as features novas, e portanto vai começar a cometer os mesmos erros que já foram cometidos por pessoas que adotaram as mudanças mais cedo, e portanto vai estar defasado na qualidade dos seus códigos.
  • Seu código ficará um pouco mais sucinto, mais organizado estruturalmente, ficará mais fácil estruturar o código e deixar mais padronizado, fazendo com que novos desenvolvedores aprendam um formato menos caótico.
  • Hoje com a sintaxe atual do js, é necessário uma experiência considerável na linguagem para escrever um código bem organizado. Consequentemente, também necessário uma certa experiência para entender esta organização.

Bom Senso

Há inúmeras razões para se aprender ES6, mas isso não significa que você deva usar em qualquer projeto. Estude um pouco sobre o babel, ou outros transpilers e veja se será viável a migração, leia sobre as diferentes aplicações e opções que estas ferramentas te dão, tempo de "compilação" também é importante, você não quer que seu projeto demore 5 minutos pra gerar os minificados.

Em um projeto legado, veja se é possível inserir a nova sintaxe sem que impacte outras partes do projeto, identifique se existe uma solução capaz de fazer com que esta migração seja o mais indolor possível, combine com sua equipe e motive-a com um POC mostrando a nova sintaxe e mostre os benefícios, isso vai despertar uma curiosidade maior em quem é mais relutante, um exemplo prático em um projeto que já existe prova de forma mais real a possibilidade e os benefícios da adoção.

Em um projeto novo, pequeno, que possui poucas features em Javascript, praticamente pede inovação, é um ambiente perfeito para experimentar. Lembre-se que um projeto novo pode residir inclusive em um projeto grande.

Ferramentas em nodejs que te ajudam em determinadas tarefas nos projetos como grunt, gulp, escreva-os usando algumas features do ES6, o Nodejs já aceita algumas features, basta olhar a documentação.

No meu caso, meus projetos pessoais são escritos usando o Jails felizmente ele conversa muito bem com vários outros frameworks e bibliotecas e funciona de forma modular usando a RequireJS . Usando o babel consigo traduzir todos os códigos ES6 que estão numa pasta chamada es6/ e gerar os respectivos arquivos na pasta js/ .

Isto é um exemplo onde a migração de um projeto legado neste caso é indolor, tudo o que antes era lido da pasta js, continua sendo lido da pasta js. O que era antigo continua, o que é novo é escrito em ES6 e salvo na pasta js no formato AMD como esperado.


Concluindo

Você tem mais motivos para aprender ES6 do que não aprender, porém saiba que você possui motivos para não usar também. Então, aprenda, mas saiba o porquê de estar aprendendo e use de forma lúcida nos seus projetos.

Como qualquer outra coisa que envolve inovação, minha sugestão é de que esteja sempre atualizado com as novidades, aprenda-as de maneira superficial para entender o porque daquilo existir, mas deixe para implementações quando estas forem realmente necessárias em um determinado contexto.