Webpack: como e por que?

Por que utilizamos Webpack?

Há muito tempo, em um navegador chamado Internet Explorer, aplicações Web eram simples: seu servidor emitia três tipos de conteúdo: o HTML, CSS e JavaScript.

Fazendo uma comparação com o corpo humano, o primeiro corresponde ao nosso esqueleto, aos nossos órgãos, ao nosso formato, a nossa estrutura. O segundo corresponde a nossa aparência, nossa cor de pele, nossa altura. E o último corresponde ao nosso cérebro, a capacidade de agir, de não ser algo estático como uma pedra.

E assim, com estrutura, estilo, e programação, desenvolvíamos a forma mais primitiva de uma aplicação web.

E nos modernizamos…

Surge o jQuery! Uma biblioteca JavaScript que fornece uma API única e fácil para gerenciar os elementos do seu DOM, e em qualquer navegador!

E jQuery, invejando o Mr. Catra, tem muitos filhos, chamados plugins. A suprema maioria correspondia a widgets para sua página Web: um menu suspenso, uma seção com guias, uma tabela de dados, um banner rotativo…

Porém cada plugin precisava que você adicionasse, além do próprio jQuery, os arquivos que ele indicava. Essa quantidade absurda de arquivos deixava nossas aplicações lentas para inicializar.

Então, decidimos adotar uma solução simples para isso: todos os nossos arquivos JavaScript serão unidos em um único arquivo, que será minificado para optimizar o seu tamanho. O mesmo para estilos.

E nos modernizamos…

O conceito de aplicação agora é melhor adotado. Nossas páginas não são mais programadas para modificar sua estrutura e estilo, mas sim para gerar estrutura e estilo. HTML sendo estruturado no próprio navegador, com o auxílio de bibliotecas poderosíssimas como Angular.js e Backbone. Não trabalhamos mais com o DOM, com os elementos da nossa UI, trabalhamos também com os dados que eles apresentam.

E quanto ao JavaScript e CSS? Quem quer usar essa linguagem limitada! “Oh! Não podemos evoluir, se não o W3Schools criado em 1900 A.C. irá parar de funcionar, blah, blah, blah!”. Eu não quero ficar limitado porque a linguagem não vai evoluir. Então, tchau JavaScript, bem vindo CoffeeScript. E LESS. E SASS. Vem todo mundo! Quanto mais melhor!!!

Então tínhamos que converter nossos arquivos fontes em .coffee .less em .js .css, concatenar todos em um único arquivo, minificar, e não podia esquecer de rodar um NgAnnotate antes para evitar problemas com o injetor de dependências do Angular. Ah! Live Reload. Não quero ter que executar este comando toda hora que salvar este arquivo, muito menos ter que apertar F5. Trabalho demais para uma pessoa só. Vamos automatizar com Grunt ou Gulp, eles dão conta!

E nos modernizamos…

Alguém inventou o conceito de micro modularização. Já não bastava separar controllers, filters, services em cada arquivo, estamos literalmente separando funções! E testando! E versionando!

Nós não temos frameworks, isso é coisa de Back-End. Não importa se é React ou Vue, use Axios para requisições HTTP!

SASS, LESS, Stylus… Todo mundo já usa. Eu quero é modularizar também. E essa classe input, essa classe é para aplicar só neste componente, não quero saber de interferir com o .input do Bulma não. E não só para estilos, eu não quero ter que me preocupar com imagens e fontes também não! Chega de cp src/{fonts,img} dist/ ! Eu quero é usar import !

JavaScript evoluiu! Evoluiu de verdade! Mas temos que tomar cuidado, os navegadores não irão se atualizar assim que o TC-39 lançar uma especificação nova. E eu quero garantir a consistência do meu código, então vou usar um Flow ou um TypeScript, porque todo mundo sabe que linguagem tipada evita bug de principiante.

Compatibilidade com IE7, esquece! “E com a primeira versão do Edge, Firefox, Chrome, Safari e Opera?” Não é nosso problema, eles já se atualizam sozinhos mesmo. Eu quero é compatibilidade com Android 2.3, R$50 o telefone. E a internet é 2G, não pode mais juntar tudo em um arquivo só, tem que separar e ir baixando a media que o código é necessário.

Live Reload. Affs, 2015 não né! Hot Reload. E mantenha meu estado por favor, não quero ter que esperar também você fazer mais uma requisição AJAX.

Você entendeu o problema?

Até hoje, o método de desenvolvimento de aplicações Web se moderniza, mas ainda somos obrigados a fornecer as aplicações Web na sua forma mais primitiva: uma estrutura, mesmo que inicial, em HTML, que será estilizada com um pouco de CSS e ganhará vida com scripts em JS.

Webpack é hoje a solução popular para resolver este problema.

Como?

Para compreender todos os casos, Webpack possui quatro elementos fundamentais:

  • Entries são os arquivos de entrada da sua aplicação. A partir deles, Webpack vai montar uma árvore de dependências incluindo todos os arquivos requisitados dentro do código.
  • Loaders são confundidos como interpretadores/compiladores do Webpack, já que eles atuam em cima dos arquivos da árvore de dependências, mas não é isso que eles fazem. Como o Webpack só entende JavaScript, Loaders são os responsáveis por transformar os arquivos requisitados em módulos. Assim, é possível chamar qualquer tipo de arquivo dentro da sua aplicação, entre estilos, imagens, fontes, que com o Loader adequado, ele será modularizado e incluindo na sua árvore de dependências. Já os interpretadores e compiladores, eles são os mesmos que você utilizaria normalmente. Por isso você tem que instalar node-sass quando escreve seus arquivos em SASS, pois na hora da modularização, o sass-loader irá utilizar a API programática do compilador para que seu módulo tenha como saída CSS utilizável.
  • Output são os arquivos gerados pelo Webpack. Corresponde a todos os arquivos da árvore de dependências unidos por um código do Webpack que mantém a estrutura modular da aplicação. O resultado final é então um conjunto de chunks, onde cada chunk é um arquivo gerado, seja ele JavaScript, CSS, PNG, JPG.
  • Plugins complementam este processo, sendo a estrutura utilizada pelo próprio Webpack. É uma função JavaScript que tem acesso a todo o processo de compilação, sendo assim poderosa o suficiente para realizar qualquer tarefa a nível global (diferentes dos loaders que são por arquivos). Plugins também são responsáveis por determinar como os chunks serão gerados, habilitando funcionalidades como Code Splitting e Hot Reloading.

E agora?

Webpack é o seu canivete suíço no desenvolvimento de aplicações Web. E apesar de muitas pessoas o utilizarem, poucos conseguem explicar como ele funciona.

A justificativa para isso se deve ao fato de que a maneira que o Webpack irá gerar o produto final é unicamente baseado em toda a configuração que você definiu para ele, remetendo ao velho debate de convention over configuration. O Webpack não assume nada sobre sua aplicação, mas para facilitar o trabalho, diversas ferramentas fornecem configurações prontas, e estas são utilizadas por muitos profissionais, já que simplesmente funciona. Podemos citar o Vue CLI, o Laravel Mix e o Create React App.

Se você ainda não utiliza o Webpack principalmente no desenvolvimento de aplicações mais modernas, já está na hora de reconsiderar. 2016, onde aprender Webpack era uma das obrigatoriedades para criar SPAs, PWAs, UWAs já ficou para trás, e você pode criar aplicações modernas com o mínimo de conhecimento sobre o assunto. Porém, isso não remove a necessidade de aprender esta ferramenta incrível, e por isso eu recomendo estes links a seguir

Novamente: Webpack é o seu canivete suíço no desenvolvimento de aplicações Web. Aprenda-o, e seja feliz!!!

Ou aguarde até que o nosso ecossistema lançar uma ferramenta melhor, trate ela como um Deus e te obrigue a usar, caso contrário você será um programador atrasado programando como nos primórdios de 2017…

Happy Coding!