Executando verificação de segurança...
6

O Webpack e o Desenvolvedor Curioso: Vale a Pena Aprender a Configurar um Boilerplate do Zero, "na unha"?

Tempos atrás eu configurei um boilerplate do zero utilizando Webpack. Foi uma jornada de aprendizado interessante. Em breve trarei um artigo explicando o passo a passo dessa experiência. Por agora, quero apenas compartilhar algumas reflexões sobre como uma experiência assim pode agregar para nossa prática de desenvolvimento de software.

Algumas experiências do desenvolvedor iniciante fazem parecer contra-produtivo se empenhar em desenvolver um boilerplate do zero:

  • Quando começamos a aprender frameworks e bibliotecas JavaScript, os cursos geralmente nos direcionam para boilerplates prontos, criados por ferramentas como CRA, Vite etc.
  • Nos projetos em que já trabalhei como freelancer, estes boilerplates prontos deram conta do recado.
  • A maioria dos projetos das empresas já existem quando os devs entram. Então, eles não precisam fazer a configuração do zero.

Tudo isso faz parecer perda de tempo aprender a configurar um boilerplate “na unha”, tomando decisões de customização para cada opção do arquivo de configurações do Webpack e para cada lib que interage com ele.

Apesar destes fatos, não é necessário um extremo exercício mental para entendermos que o conhecimento profundo sobre uma ferramenta que é o alicerce da maioria dos projetos de um ecossistema está longe de ser um desperdício de tempo. Se você trabalha no ecossistema JavaScript, deve saber que atualmente existem alternativas ao Webpack, que prometem uma performance melhor. Aqui eu não entrarei no mérito das vantagens e desvantagens dos empacotadores. O ponto é que o Webpack ainda é muito popular e muitos projetos em que daremos manutenção foram construidos com ele.

Ao criar um boilerplate eu não tive a intenção de aprender para sair por aí reproduzindo essa prática como uma prática recreativa, embora admita que me empolgou bastante🤣. A ideia foi ter UM boilerplate para usar quando necessário, com configurações que são básicas para a maioria dos projetos e que me desse liberadade arquitetural, quando fosse necessário aplicar determinado padrão de arquiterura a um projeto. Sim, liberdade, amigos. Eu sei que para quem desenvolve software tudo é posśivel, inclusive gambiarras. Então, também sei que dá para adaptar boilerplates criados por algumas ferramentas de uso comum para atender a uma arquitetura de projeto, mas, convenhamos, estaremos lutando contra uma configuração padrão realizada por essas ferramentas. E, no final das contas, não sabemos como outros devs, que posterioremente trabalharão no projeto, entenderão a adaptação que fizemos.

A fim de escolher a configuração para cada opção do arquivo de configurações do Webpack, eu tive de pesquisar sobre todas as possibilidades. O mesmo aconteceu ao configurar o Typescript, os linters etc. Mas confesso que a sensação de “abrir o capô”, proporcionada por toda essa pesquisa, recompensou a trabalheira.

A verdade é que para quem trabalha em um projeto com Webpack, este bundler é um ambiente de trabalho que muitas vezes a pessoa só conhece o escritório, embora existam outras dependências, incluindo um sótão e um porão nunca antes visitados. Você não sabe o que tem lá. Para além da sensação de segurança advinda de conhecer melhor o “local de trabalho”, conhecer as entranhas do Webpack traz facilidades para identificar problemas que surgem relacionados a transpilação de código, incompatibilidade com versões de libs etc. Quando surge um problema, você já tem pistas. Pelo menos já sabe em quais locais deve iniciar a busca. E, ao encontrar a causa, tem maior facilidade em resolver a situação.

Com base na experiência que tive, recomendo a todos que trabalham com JavaScript, mas que ainda não tiveram a oportunidade de configurar um boilerplate do zero, utilizando Webpack, que o façam logo que tiverem um tempinho. O objetivo não deve ser construir o boilerplate dos sonhos, abandonar o Vite para usar sua própria obra prima em todos os projetos. Até mesmo porque o meu está longe de ser um primor e sempre estou fazendo modificações nele. Além disso, toda decisão sobre ferramentas e padrões de arquitetura deve ser feita caso-a-caso, de acordo com os requisitos de cada projeto. O ponto a considerar é a visão que você ganhará com isso, o conhecimento sobre cada pequeno agente que integra o bonde e contribui para o resultado final, e como esse resultado seria diferente se cada biblioteca fosse configurada de maneira diversa.

E você? O que pensa a respeito? Compartilhe sua opinião sobre esse assunto. É confrontando ideias que expandimos nossos horizontes. A comunidade será grata por suas considerações. ;)

Carregando publicação patrocinada...
2

É sempre enriquecedor quando desenvolvedores decidem "abrir o capô" e entender as ferramentas que usam diariamente. Isso não apenas amplia o conhecimento técnico, mas também oferece uma compreensão subjetiva de como e porque as coisas funionam do jeito que funcinam.

Como você mencionou, não se trata necessariamente de construir algo do zero, mas de entender como as peças se encaixam. Esse conhecimento permite que os desenvolvedores façam ajustes e otimizações sem cair na armadilha de criar "gambiarras".

Ferramentas como Webpack e Vite são essenciais no desenvolvimento web moderno. No entanto, elas também são um dos desafios mais complexos. A grande maioria dos desenvolvedores tendem a usar soluções prontas sem realmente entender o que está acontecendo.

Um dos maiores problemas é que, quando algo dá errado ou não funciona como esperado, poucos sabem como solucionar o problema; um outro é que apenas quando se entende essas ferramentas, se pode contribuir para melhorias, otimizações e inovações no processo de bundle que precisa desesperadamente destas contribuíções.

1

Isso mesmo, clacerda. Se nos limitarmos ao que já vem pronto, usaremos o pronto quando é possível e tentaremos usar mesmo quando ele não é a melhor solução. Já vi pessoas tentando esticar ferramentas até onde não dá mais, outros defendendo uma tecnologia como sendo solução pra tudo, só porque o conhecimento não lhes permite ter escolha. Eu sei que a gente faz o que pode, enquanto não pode fazer melhor. Mas a ideia é continuar crescendo em competências.

2

Fala Domingos!

Cara, este exercício que fez eu considero essencial pra todos os devs de front principalmente. Nós estamos na era dos metaframeworks e outras ferramentas como next, gatsby, astro, que já fazem uma série de automatizações e bundling que precisamos.

Mas é muito importante saber como esses bundlers funcionam, porque voce pode acabar se surpreendendo como pode inclusive criar boilerplates próprios e perceber que eles podem ser até mais simples, mais performáticos do que as soluções que temos de mercado.

Quanto mais aprender e entender como essas ferramentas funcionam, mais livre estará pra criar algo customizado, personalizado pra sua empresa, para os seus problemas.

Fiz alguns boilerplates na minha vida como Front, o último eu fiz usando justamente Webpack, o plugin webpack-html-plugin e usei pug pra gerar minhas páginas html, e aí usava uma biblioteca Js pra poder tornar as coisas dinâmicas. Era no MPA no final das contas.

Aprendi muito usando webpack, e com isso fui atrás pra conhecer outras, rollup, parcel, e agora olhando um pouco de vite. Mas todas elas são muito próximas, algumas te dão algumas facilidades extras, webpack é um pouco mais manual, porém dá pra você fazer muito mais.

Parabéns pela sua iniciativa, qq dia a gente troca figurinha ae, compartilha nossos boilerplates e aprendizados.

Um abraço

1