On 03/03/10 9:21 PM, Jeppe Nejsum Madsen wrote:
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 :-)
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.
