Estou animado todos os dias, porque escrevo código de front-end com essas ferramentas incríveis que agora temos para criar aplicativos do lado do cliente com prazer.
Eu gostava de JavaScript, mas digitar tantos colchetes estava acabando com meu teclado, então descobri o CoffeeScript.
Eu estava tentando desesperadamente racionalizar minha atividade de copiar e colar para seletores em CSS, mas isso foi antes de LESS salvar minha vida.
Eu me perdia todas as vezes na marcação HTML prolixa de longas páginas da web e não conseguia perder tempo esquecendo as tags de fechamento, então Jade parecia uma faxineira para mim.
Todas essas linguagens (e outras como LiveScript, SCSS, etc.) (infelizmente?) Não são lidas nativamente pelos navegadores para os quais desenvolvemos, adicionando ao nosso processo de teste e lançamento uma etapa extra de construção.
É aqui que ferramentas como Grunt ou Brunch eram necessárias, automatizando essa “compilação”.
Pessoalmente, usei muito o Brunch por considerá-lo mais fácil para tarefas comuns na pilha que uso, e realmente aprecio sua usabilidade e seu comportamento fora da caixa.
Eu adorei tanto que escrevi um esqueleto kewl para começar a fazer protótipos rapidamente com ele.
No entanto, quando tentei usar sempre mais plug-ins para realizar tarefas mais complexas, como marcar ativos com uma soma de verificação e, em seguida, adicioná-los em um arquivo de manifesto em cache, percebi os limites dessas ferramentas, essencialmente porque são baseadas na configuração em vez de código.
E então, descobri Gulp.
Como desenvolvedores, amamos o código. Gostaríamos de saber o que está acontecendo lá no fundo quando chamamos alguma função obscura.
Gulp se livra dessa abordagem de “caixa preta” e propõe uma filosofia radicalmente diferente para criar sua fábrica front-end perfeita.
Convido você a descobrir mais sobre o Gulp neste gitbook: http://david.nowinsky.net/gulp-book .