Como eu estruturo meus projetos vanilla JS

Nota: apenas traduzi o texto abaixo e postei aqui.

Uma das perguntas que recebo com frequência é como estruturo e organizo meus projetos vanilla JS. Hoje vou mostrar como.

Estrutura dentro de um script

A primeira coisa que faço com qualquer script novo é encapsular ele em uma function para mantê-lo fora do escopo global.

Se for algo que desejo executar explicitamente mais tarde ou em um horário específico, envolvo-o em uma named function que posso chamar mais tarde.

var myScript = function () {
    // Algum código bonito...
};

// Mais tarde...
myScript();

Caso contrário, eu encapsulo ela em uma Immediately Invoked Function Expression, ou IIFE.

(function () {
    // Algum código bonito...
})();

Dentro do meu script, divido meu código em três seções distintas:

• Variáveis
• Métodos
• inicializações e event listeners

Isso ajuda a manter meu código previsível e organizado.

(function () {
    //
    // Variáveis
    //
    var elem = document.querySelector('#app');


    //
    // Métodos
    //
    var handleClicks = function (event) {
        console.log(event.target);
    };


    //
    // Inicializações & Event Listeners
    //
    elem.addEventListener('click', handleClicks);
})();

Código Modular

Muitas pessoas presumem que, como não uso frameworks e module bundlers, mantenho todo o meu código em um arquivo JavaScript gigante.

Eu não. Isso seria uma loucura!

Tenho um diretório /js em meu projeto onde guardo todos os meus scripts individuais. Eu uso Gulp, um JavaScript task runner de linha de comando, para combinar arquivos (chamado concatenação) e minificar eles.

Aqui está meu Gulp Boilerplate. Se você prefere GUIs ou simplesmente não se sente confortável com linha de comando (já não me sentia confortável há muito tempo), CodeKit e Prepros fazem a mesma coisa e são ambos muito bons.

Splitting de código

Eu não carrego apenas todos os scripts em todas as páginas.

No meu diretório /js, tenho alguns arquivos individuais e alguns subdiretórios. Quaisquer scripts que estejam dentro de uma pasta no meu diretório /js são concatenados em um arquivo com o nome dessa pasta. Arquivos individuais são minificados, mas mantidos separados.

Por exemplo, /js/main/mailchimp.js e /js/main/heading-links.js são combinados em main.js, enquanto /js/search.js é minificado, mas permanece search.js.

Meu arquivo main.js contém o código que uso em todas (ou na maioria) das páginas do meu site. Ele é carregado em todos os lugares.

Os outros arquivos individuais são normalmente usados em apenas uma ou duas "views". Eu uso loadJS() do Filament Group para carregar condicionalmente esses scripts apenas nas páginas que precisam deles.

É uma maneira superleve e fácil de "code-splitting" sem mexer com um module bundler complicado.

Tornando o JS inline

Quando se trata de desempenho na web, 14kb é um número mágico. Esse é o número aproximado de bytes em uma única HTTP request de ida e volta.

Servers enviam arquivos para o navegador em pequenos "packets", em vez de tudo de uma vez. Se você tiver um arquivo JavaScript de 20 KB, serão necessárias duas viagens de ida e volta para chegar ao navegador.

Quanto mais "round trips", mais lento será o site (geralmente falando).

Depois de "minifying" e "gzipping" meu código, meu JavaScript combinado de CSS, HTML e main.js para uma página típica em meus sites geralmente tem apenas 14 KB ou menos.

Se eu tornar inline meu CSS e JavaScript diretamente no HTML, isso significa que posso enviar a página inteira em uma única HTTP request e ela começará a ser renderizada imediatamente.

Se os arquivos combinados forem maiores que 14 KB, é melhor carregá-los externamente para que sejam armazenados em cache pelo navegador. Mas para mim, "inlining" é o motivo pelo qual meus sites parecem tão incrivelmente rápidos.

Fonte

Newsletter de Go Make Things