Re: [Lift] minified js artifacts (was Re: Re-opened #363)
Indrajit Raychaudhuri indraj...@gmail.com writes: A quick followup on this minified js concern... [...] So the question is, should we: 1. Continue using yuicompressor (to compress js files at build time) and apply the strategy universally to all toserve/**/*.js OR 2. Include the minified version of the js artifacts and get rid of the build time compression trick While #1 has the clear advantage of having human-readable js files in the repository, it is critically dependent on build time compression. Exact opposite set of argument holds for #2. Or 2.5: use 1. for the js artifacts included with Lift and let the user decide how to handle their own js files. I would hate to be forced into using the yui compressor for my own files that I put in toserve (not that it isn't a good idea :-) And since we are debating on this, the other option could be: 3. Keep both the form (un-minified and minified) available in resources/toserve and serve the un-minified form via gzip filter if user-agent has support for it (most does nowadays) or resort to minified form if user-agent doesn't. But gzip doesn't remove the need for minify. Gzipped minified jQuery is 40% smaller than gzipped jQuery: http://stackoverflow.com/questions/807119/gzip-versus-minify The behavior could be controlled via LiftRules even. Of course, this assumes that most production sites would be behind reverse proxies with proper cache control etc. and the overhead of gzip-ing is marginal. Bringing the decision (of minifying) in the framework realm also opens up the possibility of lazily creating one big js (synthetic or cached) and serving the entire stuff as one single response minified or otherwise depending on run.mode. Yes this would be the ideal and has been discussed on the list recently. /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] minified js artifacts (was Re: Re-opened #363)
On 03/03/10 9:21 PM, Jeppe Nejsum Madsen wrote: Indrajit Raychaudhuriindraj...@gmail.com writes: A quick followup on this minified js concern... [...] So the question is, should we: 1. Continue using yuicompressor (to compress js files at build time) and apply the strategy universally to all toserve/**/*.js OR 2. Include the minified version of the js artifacts and get rid of the build time compression trick While #1 has the clear advantage of having human-readable js files in the repository, it is critically dependent on build time compression. Exact opposite set of argument holds for #2. Or 2.5: use 1. for the js artifacts included with Lift and let the user decide how to handle their own js files. I would hate to be forced into using the yui compressor for my own files that I put in toserve (not that it isn't a good idea :-) Yep, just disable yui compressor in your application pom.xml and this would be quite the case (because lift-webkit-version.jar has already being created by now with the minified js either using #1 or #2). My interest in the current context, is to have consistent behavior in the js artifacts bundled with Lift. To me (and Marius) #2 is also worth consideration. True that you'd have a compressed (IDE unfriendly) js in the codebase but you'd also be able to remove build-time dependency on yui compressor. (one less dependency, one less step etc.) And since we are debating on this, the other option could be: 3. Keep both the form (un-minified and minified) available in resources/toserve and serve the un-minified form via gzip filter if user-agent has support for it (most does nowadays) or resort to minified form if user-agent doesn't. But gzip doesn't remove the need for minify. Gzipped minified jQuery is 40% smaller than gzipped jQuery: http://stackoverflow.com/questions/807119/gzip-versus-minify I learned this today, thank you! The behavior could be controlled via LiftRules even. Of course, this assumes that most production sites would be behind reverse proxies with proper cache control etc. and the overhead of gzip-ing is marginal. Bringing the decision (of minifying) in the framework realm also opens up the possibility of lazily creating one big js (synthetic or cached) and serving the entire stuff as one single response minified or otherwise depending on run.mode. Yes this would be the ideal and has been discussed on the list recently. I realize I have to catch up with the recent discussions, am way out of sync :( /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] minified js artifacts (was Re: Re-opened #363)
Info about yuicompressor-maven-plugin : * could aggregate js * could be configured to avoid minified some files * could generate minified under src with suffix (default -min) * could generate the gzip version and avoid doing it at runtime * could be invoked only in a profile (for release) or from command line when you want to minified (without being attached to a phase) * also compress/minified css * also check js validity (jslint) Disclaimer : * I'm the guy who introduce yuicompressor into lift build * I'm the guy who wrap yuicompressor into a maven plugin, to have unminified into my source and minified into war. see http://alchim.sourceforge.net/yuicompressor-maven-plugin/ /davidB On Wed, Mar 3, 2010 at 17:23, Indrajit Raychaudhuri indraj...@gmail.com wrote: On 03/03/10 9:21 PM, Jeppe Nejsum Madsen wrote: Indrajit Raychaudhuriindraj...@gmail.com writes: A quick followup on this minified js concern... [...] So the question is, should we: 1. Continue using yuicompressor (to compress js files at build time) and apply the strategy universally to all toserve/**/*.js OR 2. Include the minified version of the js artifacts and get rid of the build time compression trick While #1 has the clear advantage of having human-readable js files in the repository, it is critically dependent on build time compression. Exact opposite set of argument holds for #2. Or 2.5: use 1. for the js artifacts included with Lift and let the user decide how to handle their own js files. I would hate to be forced into using the yui compressor for my own files that I put in toserve (not that it isn't a good idea :-) Yep, just disable yui compressor in your application pom.xml and this would be quite the case (because lift-webkit-version.jar has already being created by now with the minified js either using #1 or #2). My interest in the current context, is to have consistent behavior in the js artifacts bundled with Lift. To me (and Marius) #2 is also worth consideration. True that you'd have a compressed (IDE unfriendly) js in the codebase but you'd also be able to remove build-time dependency on yui compressor. (one less dependency, one less step etc.) And since we are debating on this, the other option could be: 3. Keep both the form (un-minified and minified) available in resources/toserve and serve the un-minified form via gzip filter if user-agent has support for it (most does nowadays) or resort to minified form if user-agent doesn't. But gzip doesn't remove the need for minify. Gzipped minified jQuery is 40% smaller than gzipped jQuery: http://stackoverflow.com/questions/807119/gzip-versus-minify I learned this today, thank you! The behavior could be controlled via LiftRules even. Of course, this assumes that most production sites would be behind reverse proxies with proper cache control etc. and the overhead of gzip-ing is marginal. Bringing the decision (of minifying) in the framework realm also opens up the possibility of lazily creating one big js (synthetic or cached) and serving the entire stuff as one single response minified or otherwise depending on run.mode. Yes this would be the ideal and has been discussed on the list recently. I realize I have to catch up with the recent discussions, am way out of sync :( /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en. -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] minified js artifacts (was Re: Re-opened #363)
Indrajit Raychaudhuri indraj...@gmail.com writes: [...] My interest in the current context, is to have consistent behavior in the js artifacts bundled with Lift. To me (and Marius) #2 is also worth consideration. True that you'd have a compressed (IDE unfriendly) js in the codebase but you'd also be able to remove build-time dependency on yui compressor. (one less dependency, one less step etc.) But why is it a problem with the build-time dependency on yui compressor if it only concerns the building of the lift-*.jar? Or am I missing something? Ideally the lift jars should contain both, and the non-minified used in development. /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Re: [Lift] minified js artifacts (was Re: Re-opened #363)
On 03/03/10 10:21 PM, Jeppe Nejsum Madsen wrote: Indrajit Raychaudhuriindraj...@gmail.com writes: [...] My interest in the current context, is to have consistent behavior in the js artifacts bundled with Lift. To me (and Marius) #2 is also worth consideration. True that you'd have a compressed (IDE unfriendly) js in the codebase but you'd also be able to remove build-time dependency on yui compressor. (one less dependency, one less step etc.) But why is it a problem with the build-time dependency on yui compressor if it only concerns the building of the lift-*.jar? Or am I missing something? No question with the worthiness of yui-compressor as such, it does the job perfectly and great for the purpose :) It about when to use it. If we are using it to minify the set of third party js files (jquery, json etc.) repeatedly which never change we might as well consider keeping the minified form directly. Hence the worthiness behind consideration. Note that Lift's internal js files (e.g., jlift.js) are fine going the yui-compressor route. But more than anything, we need to be consistently following either of these (particularly for the 3rd party js artifacts). Ideally the lift jars should contain both, and the non-minified used in development. Yes, better. Which actually led to the other thought (#3). But git should contain only one form in that case (the un-minified one). /Jeppe -- You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to lift...@googlegroups.com. To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
