utiliza ultima que funciona ejemplos definicion como caracteristicas javascript compression minimize jscompress

ultima - ¿Qué usas para minimizar y comprimir bibliotecas de JavaScript?



javascript que es (17)

¿Qué usas para minimizar y comprimir bibliotecas de JavaScript?



Aquí hay una solución de Microsoft que puedes integrar en Visual Studio para minimizar los archivos automáticamente cuando construyes tu proyecto.

Instalar:

Descargue el msi desde: http://aspnet.codeplex.com/releases/view/40584

Es posible que deba reiniciar su computadora una vez que haya finalizado.

Usar:

Edite su archivo .csproj e incluya lo siguiente al final del archivo (pero antes de la etiqueta </Project> ):

<Import Project="$(MSBuildExtensionsPath)/Microsoft/MicrosoftAjax/ajaxmin.tasks" /> <Target Name="AfterBuild"> <ItemGroup> <JS Include="**/*.js" Exclude="**/*.min.js;Scripts/*.js" /> <CSS Include="**/*.css" Exclude="**/*.min.css" /> </ItemGroup> <AjaxMin JsSourceFiles="@(JS)" JsSourceExtensionPattern="/.js$" JsTargetExtension=".min.js" CssSourceFiles="@(CSS)" CssSourceExtensionPattern="/.css$" CssTargetExtension=".min.css"/> </Target>

Ahora cuando construya su proyecto, se minimizarán todos los archivos CSS y js que no terminan en .min.js, .min.css (Consulte el atributo "Excluir" para excluir que se minimicen otros archivos).



He probado el compresor YUI antes, pero me da un mensaje de error.

Sugiero usar JSMIN para minimizar tu javascript:

JSMin


He usado YUI Compressor durante mucho tiempo y no he tenido problemas con él, pero recientemente comencé a utilizar Google Closure Compiler y tuve cierto éxito. Mis impresiones de eso hasta el momento:

  • En general, supera al compresor YUI en términos de reducción de tamaño de archivo. Por una pequeña cantidad en modo simple, y mucho en modo avanzado.
  • El modo simple hasta ahora ha sido tan confiable como el compresor YUI. Nada de lo que he alimentado ha mostrado ningún problema.
  • El modo avanzado de "compilación" es ideal para algunas secuencias de comandos, pero la reducción de tamaño dramático de la secuencia de comandos se produce a expensas de una gran cantidad de intromisión en el código que tiene una buena probabilidad de romperlo. Hay formas de lidiar con algunos de estos problemas y comprender lo que hace puede ayudar a evitar problemas, pero generalmente evito usar este modo.

Pasé a utilizar el compilador de cierres de Google en el modo simple de "compilación", ya que supera ligeramente al compresor YUI en general. Lo he usado mucho menos que con YUI Compressor, pero por lo que he visto hasta ahora, lo recomendaría.

Otro que todavía tengo que probar pero parece prometedor es UglifyJS de Mihai Bazon .


Herramientas de closure de Google

Puede asignar la versión minimizada al código fuente habitual para depurar en Firebug con su complemento.


No minimizo el JavaScript en absoluto: la compresión gzip es lo suficientemente buena para mí y tiene el beneficio adicional de que los mensajes de error seguirán siendo útiles.


Usted tiene un rebaño de posibilidades aquí:

Desde mi experiencia personal, recomendaría que use el Dojo SDK para crear una compilación personalizada, que a su vez puede configurar para usar su compilador ShrinkSafe habitual o Google Closure, que ahora también admiten .

En términos de compresión, creo que Google Closure es el que mejor rendimiento me ha dado hasta ahora, sin embargo, generalmente estoy satisfecho con ShrinkSafe y es un poco más viejo y más robusto, mientras que Closure Compiler parece un poco nuevo en el bloque. (que a sus partes interesadas podría no gustarles demasiado, por ejemplo).

Sin embargo, algunas personas juran solo por el compresor YUI. Yo personalmente no puedo responder por eso.

Ahora bien, si tu pregunta es comprimir bibliotecas y no solo tu propio código JavaScript, obviamente se vuelve mucho más complicado, ya que necesitarás para la mayoría de estas herramientas exportar los símbolos que no deberían ser renombrados o eliminados. La mayoría de los compresores decentes eliminarán las funciones que creen que no se usan, a menudo el caso de una biblioteca, si no está vinculado a un proyecto, obviamente, y cambian los nombres para acortarlos y usar menos caracteres, también un problema ya que obviamente quieres un público API para no ser manipulado.

Puede encontrar otros hilos sobre este tema también y encontrar información en la documentación de soporte de las herramientas. También es posible que desee echar un vistazo a JSBuilder2 , una especie de colgante de la herramienta Dojo''s Build (por lo tanto, utilizando ShrinkSafe o Closure Compiler) para ExtJS (utilizando el compresor YUI).

(Lo siento, al ser un nuevo usuario de SO, no puedo agregar más de un enlace, así que no puedo vincularlo directamente a las herramientas).

EDITAR: con respecto a las preocupaciones expresadas en algunas respuestas, la compresión puede introducir errores y facilita la depuración ya que el código no se destruye: sí, es una preocupación válida. Sin embargo:

  • obtendrá una mejora muy significativa en términos de ancho de banda si usa un minificador, incluso con la compresión gzip activada (y puede aprender a aprovechar la compresión gzip haciendo que la vida del compresor sea más fácil)
  • solo debe probar su código en modo de depuración y producción para asegurarse de que el comportamiento sea idéntico. Quiero decir, es parte de tu trabajo también ...
  • algunos de estos compresores han existido por un tiempo y realmente no introducirán errores en su código. En realidad solo están reorganizando cosas y sustituyendo cadenas.
  • algunos compresores (por ejemplo, el sistema de compilación dojo) vienen con opciones que le permiten producir salidas comprimidas y no comprimidas, de modo que puede habilitar diferentes modos para depuración y producción, usando parámetros de consulta, por ejemplo.


Yo también uso YUI Compressor. Tengo una tarea similar a esta que uso en mis proyectos:

<!-- YUI Compressor tasks http://www.julienlecomte.net/yuicompressor/README --> <property name="yuicompressor.jar" value="C:/devlibs/yuicompressor-2.2.4/build/yuicompressor-2.2.4.jar"/> <target name="js.compress"> <!-- Create min directory under js direcrtory if it doesnt exist --> <mkdir dir="${js-directory}/min" /> <apply verbose="true" executable="java" parallel="false" failonerror="true"> <fileset dir="${js-directory}" includes="*.js"/> <arg line="-jar"/> <arg path="${yuicompressor.jar}"/> <srcfile/> <arg line="-o"/> <mapper type="glob" from="*.js" to="${js-directory}/min/*-min.js"/> <targetfile/> </apply> </target>



Yo uso JavaScript :: Minifier de perl. Funciona bastante bien y puedes, por ejemplo, reemplazar algunas frases usando Perl.



http://code.google.com/p/jsmin-php/

El bueno de Doug Crockford :-) La belleza de esto es que con el control de caché puede obtener una compresión automatizada solo cuando sea necesario. O en uno de mis proyectos, solo imprimo los archivos comprimidos / gzip y los borro cuando realizo un cambio. Para un entorno de desarrollo, simplemente no llamo al script de minificación.


El empacador de Dean Edward logra unas relaciones de compresión bastante buenas. Tiene implementaciones de línea de comandos que le permiten ser utilizado en un proceso de integración continua.



UglifyJS es uno nuevo.

UglifyJS se comprime mejor que YUI Compressor y casi a la par con Google Closure Compiler. Por ejemplo, la versión comprimida de jQuery del compilador de cierres de Google es solo 403 bytes más pequeña que la versión producida por UglifyJS, ¡impresionante! UglifyJS es también el más rápido de ejecutar por un tiro largo, superando el cierre por más de 6 segundos.

Además, el código producido por UglifyJS es más seguro que el código que genera Closure. Por ejemplo, Closure no sabe cómo tratar con eval o con {} - simplemente registra un error y continúa cambiando el nombre de las variables de todos modos. Esto, obviamente, conduce a un código roto. UglifyJS no tiene este problema.

Puede encontrar más información aquí: http://badassjs.com/post/971960912/uglifyjs-a-fast-new-javascript-compressor-for-node-js