Pessoal, o Google acabou de liberar algumas bibliotecas que eles usavam internamente. Eu partilarmente acho que vou usar o Closure Compiler, ainda preciso testar.
[quote]Millions of Google users worldwide use JavaScript-intensive applications such as Gmail, Google Docs, and Google Maps. Like developers everywhere, Googlers want great web apps to be easier to create, so we’ve built many tools to help us develop these (and many other) apps. We’re happy to announce the open sourcing of these tools, and proud to make them available to the web development community.
…[/quote]
Mais detalhes em: http://googlecode.blogspot.com/2009/11/introducing-closure-tools.html
Pessoal, estou usando o Closure Compiler aqui e é simplesmente sensacional!
Meu projeto tem 11 arquivos javascript com 210 KB no total.
Depois do build com WHITESPACE_ONLY cai para 89 KB. Com SIMPLE_OPTIMIZATION cai para 78 KB!!!
Não estou usando ADVANCED_OPTIMIZATION pq ele renomeia muita coisa que não pode e é inviável eu configurar para ele não fazer isso (uso muitas bibliotecas no meu projeto). A não ser que eu dê build das bibliotecas junto, mas ai fica muita coisa…
Enfim, para quem usa NetBeans e quiser testar, primeiramente configure o compiler.jar para ir para o build da aplicação e insira o seguinte código no build.xml do projeto.
[code]
<property name="closureCompiler" value="${build.classes.dir}/../lib/compiler.jar"/>
<property name="jsRootFolder" value="${build.web.dir}/javascript"/> <!-- mude /javascript para o diretório que ficam seus JSs -->
<property name="compiledJsFolder" value="${build.web.dir}/javascript"/> <!-- idem anterior -->
<echo>Iniciando otimização do código JavaScript...</echo>
<java jar="${closureCompiler}"
args="--compilation_level SIMPLE_OPTIMIZATIONS
--js ${jsRootFolder}/arquivo1.js
--js ${jsRootFolder}/arquivo2.js
--js ${jsRootFolder}/arquivoN.js
--js_output_file ${compiledJsFolder}/application-min.js"/>
<echo>Otimização do código JavaScript finalizada!</echo>
[/code]
Nesse exemplo, pego 3 arquivos (arquivo1, arquivo2 e arquivoN), otimizo os três e coloco o resultado em application-min.js.
Para mais opções vejam a documentação no site.
[]´s
sabe a diferenca entre o closure compiler e o yui compressor? o closure faz algo a mais? sera q eh mais eficiente?
e aquela biblioteca closure eh feinha hein hehehehe prefiro muito mais o jquery 
[quote=Sergio Lopes]sabe a diferenca entre o closure compiler e o yui compressor? o closure faz algo a mais? sera q eh mais eficiente?
e aquela biblioteca closure eh feinha hein hehehehe prefiro muito mais o jquery :)[/quote]
Então Sergio, sinceramente não sei a diferença pois não cheguei a usar o YUI compressor. Já tentei integrar o JSBuilder (do pessoal do ExtJS) no meu projeto, mas não tive muito sucesso e desencanei. Ontem dando uma olhada no Reader eu vi Closure Compiler e decidi testar e gostei. Eu ia testar o YUI compressor essa semana, mas como já coloquei o Closure Compiler para funcionar, acho que não vou mais alterar isso.
Eu nem olhei a biblioteca deles justamente por ser fã de carteirinha do jQuery. No meu caso o que foi mais útil mesmo foi o Compiler.
[]´s
[quote=Sergio Lopes]sabe a diferenca entre o closure compiler e o yui compressor? o closure faz algo a mais? sera q eh mais eficiente?
e aquela biblioteca closure eh feinha hein hehehehe prefiro muito mais o jquery :)[/quote]
Oi de novo Sergio.
Decidir testar aqui o YUI compressor. Ao meu ver até agora o Closure Compiler é melhor quanto ao uso e a quantidade de opções para se passar para o compressor. O YUI tem pouquíssimas opções e até agora não achei uma forma de colocar vários arquivos em um. Tem que fazer arquivo por arquivo.
Uma vantagem do YUI compressor é que ele compacta css tbm.
Algumas discussões quanto a falta da funcionalidade de juntar arquivos:
http://yuilibrary.com/forum/viewtopic.php?p=4633
Até agora ainda estou achando o Closure Compiler melhor. Vou comparar os arquivos gerados e já posto o que obtive.
[]'s
Pessoal, segue uma comparação bem simples entre o Closure Compiler e o YUI Compressor.
Arquivo usado para compressão: application.js
Tamanho: 84.296 bytes ~ 82,3 KB
Arquivo comprimido com YUI Compressor: application-min-yui.js
Tamanho: 33.966 bytes ~ 33,1 KB
Arquivo comprimido com Closure Compiler: application-min-closure-w.js
Modo de compressão: WHITESPACE_ONLY
Tamanho: 39.607 bytes ~ 38,6 KB
Arquivo comprimido com Closure Compiler: application-min-closure-so.js
Modo de compressão: SIMPLE_OPTIMIZATIONS
Tamanho: 33.318 bytes ~ 32,5 KB
Arquivo comprimido com Closure Compiler: application-min-closure-ao.js
Modo de compressão: ADVANCED_OPTIMIZATIONS
Tamanho: 24.821 bytes ~ 24,2 KB
Conclusões:
- O tamanho dos arquivos gerados quando comparado o YUI compressor com o Closure Compiler em modo SIMPLE_OPTIMIZATION não varia muito.
- O código ofuscado gerado é praticamente o mesmo.
- O Closure Compiler tem muito mais opções que o YUI compressor.
- O YUI compressor também otimiza código css.
Ainda fico com o Closure Compiler.
[]´s
Tem que testar também o tamanho do arquivo depois do gzip, que faz uma diferença brutal
boa, david! valeu pelos testes
e victor, tem razao sobre o gzip. precisa ver se o otimizador usado melhora ou piora o trabalho do gzip
e eu tava lendo sobre o closure e uma opcao pareceu interessante: ele remover codigo nao chamado. q eu saiba o yui nao faz isso
Pessoal, falando em gzip, estou compactando o resultado do Closure Compiler, mas o navegador simplesmente não consegue ler o arquivo .gz.
Minha página tem simplesmente um
Como eu faria para funcionar? Ja procurei bastante e não achei uma solução que funcione. Na verdade consegui algo passando por um servlet primeiro (setando o content-encoding para gzip. Não tem uma forma mais simples?
[]´s
Na aplicação você deixa o arquivo .js normal, sem gzip
O gzip você vai configurar no Apache, habilitando o mod_deflate e adicionando isso no httpd.conf
<Location />
AddOutputFilterByType DEFLATE text/html text/plain text/xml application/javascript text/x-js text/css
</Location>
Assim o Apache vai automaticamente gzipar os htmls, javascripts, css enviados, caso os browser suportem (praticamente todos, até o IE6)
Pra conferir o tamanho final dos arquivos enviados você pode usar algo como o plugin Firebug/YSlow do firefox
[quote=victorcosta]Na aplicação você deixa o arquivo .js normal, sem gzip
O gzip você vai configurar no Apache, habilitando o mod_deflate e adicionando isso no httpd.conf
<Location />
AddOutputFilterByType DEFLATE text/html text/plain text/xml application/javascript text/x-js text/css
</Location>
Assim o Apache vai automaticamente gzipar os htmls, javascripts, css enviados, caso os browser suportem (praticamente todos, até o IE6)
Pra conferir o tamanho final dos arquivos enviados você pode usar algo como o plugin YSlow do firefox[/quote]
É que eu não uso o Apache e sim o Tomcat para desenvolvimento. A minha aplicação vai rodar no Glassfish em produção.
Consegui fazer algo passando por um servlet, mas não gostei de como ficou… Acho que um filtro tbm pode resolver minha questão… Vou dar uma testada.
cada servidor tem uma configuracao especifica pra gzip (tomcat/jetty etc). acho melhor configurar isso no deploy que fazer vc mesmo
Pensei que não tinha como configurar no Tomcat. Como que eu poderia fazer isso Sergio?
[quote=Sergio Lopes]http://tomcat.apache.org/tomcat-6.0-doc/config/http.html
[/quote]
Obrigado Sergio, já consegui configurar aqui 
[]´s
