O que custa mais processamento nesses códigos?

[Andrey Knupp Vital 136]

Se está usando jQuery já é perda de processamento !

[Eliseu M. 2]

Realmente, Andrey Knupp, mas é com esse tipo de biblioteca que ganhamos tempo e conseguimos terminar um front end em um dia :D

 

Ultimamente estou estudando mais sobre o core do JavaScript e de outras linguagens. Todas são excepcionais, mas o difícil é encontrar o jeito certo de usar cada recurso.

 

Eu gostaria de ver aqui no fórum uma seção de benchmarks, com um plugin IPB para gráficos e tal. Eu sei que existem ferramentas online para fazer isso (JSPerf, PHP Benchmark), mas há casos específicos que elas não envolvem. Que tal realizarmos desafios de performance? Quem consegue fazer isso rodar mais rápido com menos... como aquelas competições de 1K de código, mas além do foco no tamanho, ter foco no desempenho.

 

Falou.

[Andrey Knupp Vital 136]

Na verdade, eu aprendi bastante coisa de JavaScript quando precisei fazer uns trabalhos com DOM navegando em nodes de um retorno SOAP, html .. entre outros, eu prefiro o JavaScript puro mesmo, o processamento é bem rápido, tanto é que conseguiram emular linux no browser com javascript, ficou sabendo ? mas quando estou sem tempo, mas sem tempo mesmo não dá pra ser no js pure não, vou pro jQuery ui + jQuery .. mas isso nas últimas das opções !

 

Tanto é que eu ainda tenho dúvidas entre o jQuery mim pro jQuery normal, na teoria pensamos que o jQuery mim, que é a versão compactada, demora mais tempo pra compilar, porque aí o browser tem que descompactar o código e depois compilar todo o javascript escrito, já o aberto ele só compila o código .. mas por sua vez, o jQuery mim é bem mais leve em `kb's'` do que o jQuery descompactado.

[Eliseu M. 2]

Vi sim a parada do Linux. JS está ficando poderoso demais, ainda mais com o surgimento do NodeJS há algum tempo, que só vem crescendo.

 

Ah, eu também fico encucado com essas versões min e packed (pior ainda). Apesar de que essa descompactação só ocorre no load da página, depois os objetos são criados e já era. Quem dera se todas as engines JS rodassem bem igual à do IE9 =]

 

Atualmente, na empresa, eu uso o jQuery latest do Google CDN, e dou um fallback para outro local. A vantagem é que o visitante acessou outro site que usou-o, o arquivo já estará em cache, isso é uma maravilha. Com alguns minifies e packs, e concatenando os arquivos, dá pra ter ótimos resultados. O esquema é ter uns 3 ou 4 subdomínios (sem cookies e com cache monstro) para o browser poder realizar vários downloads paralelos (isso funciona mesmo). No caso do ramo que eu atuo, sites para imobiliárias, o JS fica num domínio, o HTML e CSS em outro e as imagens em outro. O carregamento vira um waterfall, quando as requests se aproximam ao máximo de uma cachoeira (verticalmente reta).

 

O esquema é modular bem o código (alguns patterns) e usar só o que for necessário em cada página. A execução dificilmente passará dos 30ms, os quais são ridículos! Os seletores do jQuery estão muito rápidos. A m***** é que alguns inconsequentes não testam alternativas, saem colocando o trecho de código mais fácil e esquecem de performance e consistência, como atribuições de eventos. Perceba a sutileza:

 

Live vs Delegate

Bind vs Click vs Delegate vs Live

Bind vs Click vs Delegate vs Live 2

 

Perceba que às vezes o delegate() é mais rápido, mas nem sempre. No caso do DOM é a mesma, coisa, nem sempre utilizar a tag no seletor é mais rápido o.O

E não é só no JS não. Esses dias descobri que quase sempre um sprite de imagens na horizontal é bem menor que um quadrado ou vertical... vai entender.

Slide de Performance jQuery: http://www.slideshar...nce-tips-tricks

 

É isso aí, até mais!