Javascript State of the Union 2015, parte 3

Este artigo é a última parte de uma série de 3 publicações, sobre a apresentação Javascript State of the Union, feita inicialmente em Setembro de 2015.
Veja os slides aqui.

Parte 1 | Parte 2


Computadores existem para satisfazer as nossas necessidades e automatizar tarefas. A forma como nós humanos interagirmos com qualquer sistema que automatize tarefas (não só computadores, pense em carros, por exemplo) é através de uma interface. Antes da internet ser como conhecemos hoje, essa interface era feita através de softwares instalados no sistema operacional. Com a evolução da web e a praticidade da mesma, muitos têm tentado trazer todo o poder do computador para sistemas na web, através de interfaces no navegador.

Fazer software na web é algo relativamente novo, os desafios próprios desta área ainda estão surgindo. O Front-End de hoje está intimamente ligado ao desenvolvimento de software offline — a história que estamos examinando, iniciada em 1950.

A fundação da nossa área, o Front-End, começou há muito tempo atrás. Conceitos considerados novos por muitos, na verdade vem de muitos anos de problemas e desafios hoje já solucionados.

Se olharmos atentamente veremos que a evolução do mercado; o surgimento de empresas e startups; o progresso dos processadores; até mesmo decisões políticas e econômicas influenciam o desenvolvimento de software (tanto no Back-End quanto no Front-End).


Esta é a faixa de 2010 à 2015. Você deve estar se sentindo em casa agora, quer isso seja confortável ou não, esse é o cenário que temos hoje: os navegadores evoluíram consideravelmente rápido nos últimos 5 anos, a ponto de considerarmos o início de uma trégua na guerra dos browsers; o Javascript evoluiu em paralelo (vide ES2015, WebAssembly, UniversalJS). A confusão, reside na faixa dos frameworks e bibliotecas JS.

Podemos separar esse grande BOOM de ferramentas nos seguintes grupos:

  • Frameworks MVC.
  • Frameworks e bibliotecas Funcionais e Reativas.
  • Bibliotecas de Component-View.
  • Ferramentas para Mobile Híbrido.
  • Outros: Module loaders; Bibliotecas de teste; JS compilado tipado; Client/Server-side templating e pré-processadores de CSS; Arte 3D, generativa e animação.

A primeira constatação é que o Javascript invadiu o espaço “nativo” dos aplicativos, tanto para mobile quanto desktop e TVs. Esse movimento não é surpresa — Javascript é a melhor linguagem para desenvolvimento multi-plataforma hoje em dia.

Mais importante que isso é a transformação que ainda está acontecendo. Ao observar os três primeiros pontos da lista acima, na timeline, veremos o que aconteceu de 2010 para 2015. Em ordem cronológica:

  • Nos primeiros anos, frameworks MVC estabilizaram (Angular, Ember…).
  • Recentemente, frameworks e bibliotecas Funcionais/Reativas surgiram, junto com bibliotecas idealizando views componentizadas (Riot, Polymer, React…).
  • Por último, até mesmo frameworks MVC começaram a incorporar os conceitos de reatividade e componentes (Angular2, Aurelia).

Isso foi rápido, vamos voltar um pouco. Nós sabemos que grandes idéias e produtos se comunicam com os usuários através de uma interface — eletricidade / interruptor, carro/painel. Nos computadores (que também tem sua própria interface), softwares respondem às GUIs. Softwares vem sendo desenvolvidos desde 1950 ao passo que na web começamos a fazer Single Page Applications em meados dos anos 2000, pelo menos cinquenta anos de diferença. Ao mesmo tempo, estamos fazendo a mesma coisa, porém em um ambiente completamente diferente.

Podemos considerar que até 2010 tivemos o que chamo “do spaghetti às GUIs”: com o advento do AJAX tivemos cada vez mais lógica no Front-End; começamos a desenvolver software na web usando o AJAX como base e o MVC como padrão de arquitetura; os frameworks trouxeram o UI Data Binding, automatizando o processo de sincronia das views; por fim alternativas para modularizar o código apareceram. Some isso, e temos o que é chamado de Single Page Application ou Client Side Application — podemos dizer que a partir daí, temos Graphical User Interface “done right” na web. Para referência, essa transição é exemplificada por frameworks como Angular, Backbone, Knockout e bibliotecas como Underscore e Browserify.

Client-side é bom, ao invés de uma experiência cortada e em pedaços, oferece um fluxo único sem interrupções; pode ser bem mais rápido que uma aplicação server-side comum, já que parte da lógica pode ser delegada ao client; o desenvolvimento se beneficia por ambos os lados, Back-End e Front-End uma vez que podem ser criados de forma independente.

Mas, ainda faz parte de um processo. Até 2015, desenvolver aplicações client-side significava ter que lidar com alguns problemas. Por estar delegando a renderização ao Front, até que a mesma esteja pronta, o usuário se depara com uma página em branco. É mais complicado lidar com SEO e mapeamento de URLs. Ao criar um sistema de larga escala, podem haver diversos problemas caso não haja cuidado em arquitetar responsabilidades entre servidor/cliente. Ao tentar resolver esses problemas, é comum acabar com lógica duplicada em cada lado. Por último, a arquitetura MVC por si só traz alguns problemas em relação a escalabilidade.

Se olharmos para onde a comunidade Open Source está caminhando, e também nossa timeline, vemos que muitos frameworks e bibliotecas baseadas em Programação Funcional e Reativa surgiram nesse ano.

O nível de interatividade em softwares na web é muito maior do que as tradicionais aplicações desktop offline. Estamos falando de sistemas com uma quantidade imensa de informação, sendo atualizadas constantemente em diversos dispositivos (pense nisso na próxima vez que estiver assistindo Netflix).

As alternativas criadas nesse ano (a maioria baseada no paradigma Funcional/Reativo) não só lidam muito melhor com dados em massa, como solucionam os problemas que tínhamos anteriormente. Com server-side rendering de templates não precisamos mais ter página branca ou problemas com SEO. Compartilhando código entre as duas camadas, eliminamos a possibilidade de lógica duplicada. E a arquitetura Funcional é bem mais escalável do que tínhamos até ano passado.


A linguagem Javascript também está em momentos de glória. O lançamento do ES6 foi um grande passo, mas ainda tem muito chão no caminho do Javascript.

Disclaimer: Afirmações nesta seção vem de anotações feitas no BrazilJS 2015.

  • Boa parte dos próximos avanços serão liderados pela indústria de games. A necessidade de otimização de performance é gigantesca. Estamos falando de tipagem opcional, arrays tipados, objetos tipados, WebAssembly, sharedArrayBuffer, SIMD, etc.
  • ES7 trará além de alguns pontos acima: async, comprehension, observe, guards, int64, etc. Veja a apresentação Solar System of JS.
  • O ES8 provavelmente trará macros, algo parecido com sweet.js.
  • O sistema de gerenciamento e carregamento de módulos vai evoluir, provavelmente incluindo “dead code elimination” ou “tree-shaking”.
  • Mais controle dos browsers, utilizando APIs nativas. Por exemplo Service Workers, veja este artigo recente de Addy Osmani.
  • Vamos precisar entender mais conceitos de ciência da computação. Veja por exemplo este vídeo sobre ImmutableJS.
  • Não estamos usando todo o poder dos computadores. O Javascript é single-thread. Prepare-se para aprender Web Workers e lidar com problemas de paralelismo.
  • Javascript Funcional veio para ficar.
  • WebAssembly eventualmente se tornará uma realidade.

Podemos ir além, como estaremos em 2020? Como será a tecnologia em 5 anos? Já vimos que o Front-End é influenciado por diversos aspectos, nada mais justo que olhar a tecnologia de forma geral.

O resultado da pesquisa está condensado em uma lista neste slide, desde crianças aprendendo código nas escolas até inteligência artificial.

Em resumo, teremos um número grande de desemprego causado pela automatização de trabalho manual (ex: carros que dirigem sozinhos / motoristas desempregados); se tudo der certo, não só drones de entrega como também industriais e militares; inteligência artificial atuando em diversos campos, como na medicina; cada vez mais teremos objetos conectados na internet e transmitindo dados; realidade aumentada ocupará cada vez mais espaço na vida das pessoas.

O que isso tem a ver com Front-End? Muito. Da mesma forma que todos os pontos que observamos influenciaram nossa área, estes também irão. O Front é a interface entre produto e usuário, essas previsões só mostram que as interfaces se multiplicarão muito mais daqui para frente. E claro, pode apostar que o Javascript estará em muitas dessas inovações.

Estamos passando por muitas mudanças porque a fundação do Front-End ainda está sendo construída. Olhando a timeline vemos que existe uma diferença de pelo menos 50 anos entre desenvolvimento de software offline e online. Não é só uma questão de transferir o conhecimento de um para o outro ou reutilizar soluções, pois o ambiente de cada um é completamente diferente. Também vimos que leva tempo construir uma fundação sólida.

Em termos do que tem mudado, acredito que duas coisas principalmente: demanda e técnica. Até pouco tempo, não demandávamos aplicações completas na internet, consultar informação era suficiente. A demanda das pessoas mudou. Ao mesmo tempo as técnicas para corresponder tais demandas estão mudando.

O mais importante é o que não mudou. Ainda estamos usando os mesmos conceitos, padrões e paradigmas que existiam e se mostraram suficientes 30, 40 anos atrás. Se pergunte o seguinte, quem constrói os frameworks que todos nós usamos no dia-a-dia? São engenheiros de software, profissionais que de fato estudaram tudo isso.

Infelizmente ainda encontramos muitas ofertas de emprego com requisitos quilométricos. Tudo bem, não é culpa do RH ou do CEO, eles querem satisfazer a demanda interna e “get the job done”. Mesmo assim, empresas que fazem isso não vão encontrar bons profissionais.

Imagine que todas essas tecnologias, frameworks e bibliotecas são como bolinhas atiradas para um cachorro. Se você só se preocupar em entender toda e cada uma delas, não vai chegar em lugar algum. É uma situação muito estressante e infelizmente comum. A pergunta mais comum em fóruns de discussão é “o que devo aprender agora?” ou “o que devo aprender primeiro?”. Não seja como o cachorro.

Seja como o leão, que vai na raiz do problema. Se você jogar bolinhas para um leão, ele vai atrás de você, não das bolinhas, certo? É isso que você tem que fazer. Sempre se pergunte qual problema aquele framework quer solucionar, quais foram as condições da sua origem e se essa solução também cabe a você. Existem coisas que você não precisa saber, pelo menos agora. Acredite nisso.

Se você continuar fazendo isso de novo e de novo, é possível que você chegue a uma verdade. Você pode chegar no ponto de olhar para todas essas ferramentas e ver que é tudo muito parecido, “mais do mesmo”. A gente deve almejar compreender a raiz. Menos distração, mais foco.

Relembre um pouco de quando você era criança e perguntava o “por que” de tudo. Procure saber o que está por traz de cada solução, tente conectar os pontos na sua cabeça. Vai levar um tempo, mas eventualmente tudo passará a fazer mais sentido e você vai naturalmente ter o seu norte.

O que significa evolução? Por mais que hajam mudanças e melhorias, o objeto em questão deve ser o mesmo durante todo o processo, não se transformar em outra coisa. As vezes no processo de evolução o sujeito se transforma em outra coisa com características semelhantes — de carroça para carro por exemplo. Quando os princípios de alguma coisa mudam, já temos algo novo. Uma mesa tem uma superfície plana, quatro pernas e serve de apoio para outros objetos. A partir do momento em que você diminui a altura da mesa e adiciona um encosto, você tem uma cadeira e não mais uma mesa.

Ainda estamos falando de computadores, ainda estudamos as mesmas coisas. O que não mudou foram os princípios da computação. Nesse momento, é muito mais importante para todos nós aprendermos tais princípios ao invés de nos perdermos com a corrente infinita de novas ferramentas. Você deve sim, olhar todas e saber tudo que está acontecendo, mas manter o foco e se desenvolver passo a passo.


Este artigo é a última parte de uma série de 3 publicações, sobre a apresentação Javascript State of the Union, feita inicialmente em Setembro de 2015.
Veja os slides aqui.

Parte 1 | Parte 2