How much javascript would you have when you decide that minifying is
called for?
Me? When it starts resembling JQuery or prototypejs.
Seriously, how can anybody answer such a general question?
Personally, I roll all my JavaScript myself (that way I understand what
I am doing) and never found myself in a situation where I needed to
minimize the code.
Are you having any specific problems with your current JavaScript?
If so, what kind of problems? Maintainance? Performance? Crossbrowser
compatibility?
Please elaborate a little.
Regards,
Erwin Moller
--
"There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies. The first method is far more difficult."
-- C.A.R. Hoare
On Nov 14, 5:32 pm, Martin Rinehart <MartinRineh... @gmail.comwrote :
How much javascript would you have when you decide that minifying is
called for?
I always try to serve them minified, BUT, do not forget to keep the
non-minified sources in a safe place: usually a "sources" folder (a
"deploy" folder holds the minified versions).
..CSS and .html files can be "minified" too...
A 1000 lines .js with soft-tabs has several kilobytes of %20's...
Also, whenever/if the UA supports it (Accept-Encoding: gzip) serve it
gzipped as well.
How much javascript would you have when you decide that minifying is
called for?
There isn't enough "javascript " in the world to make minifying worthwhile.
Literally.
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
On Nov 14, 5:32 pm, Martin Rinehart <MartinRineh... @gmail.comwrote :
>How much javascript would you have when you decide that minifying is
>called for?
>
I always try to serve them minified, BUT, do not forget to keep the
non-minified sources in a safe place: usually a "sources" folder (a
"deploy" folder holds the minified versions).
Since no human beings (possible savants aside) can decipher minified code in
a reasonable amount of time so as to compare if the code they use is
equivalent to the code that is in the `deploy' "folder", what should it be
good for? That's the core problem with minifying: you test code but you use
completely different code; the tests, as thorough as they may have been, are
ultimately futile. Especially as most people don't even know how the
minifier works that they are using.
My recommendation: When serving, strip the documentation comments if you
must (and provide a version that includes them also), but do not minify.
.CSS and .html files can be "minified" too...
To what end? Better support RFC 1149?
A 1000 lines .js with soft-tabs has several kilobytes of %20's...
So what? Assuming "several" means 2 (KiB), that's about 0.293 seconds
download time on a 56k modem in the best case (56 kBit/s), about 0.341
seconds in the worst case that I have seen yet (48 kBit/s). Literally
in the blink of an eye already, and broadband Internet connections,
which are more than 26 times faster than that, tend to be more common nowadays.
Also, whenever/if the UA supports it (Accept-Encoding: gzip) serve it
gzipped as well.
That's the ticket instead.
PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm>
How much javascript would you have when you decide that minifying is
called for?
Never? I use JSMin to strip comments and trailing spaces occasionally.
Serving one larger file instead of several small ones, and delivering it
gzipped will yield *much* better results, than all this minifiying fuss.
>How much javascript would you have when you decide that minifying is
>called for?
>
Never? I use JSMin to strip comments and trailing spaces
occasionally. Serving one larger file instead of several small ones,
and delivering it gzipped will yield *much* better results, than all
this minifiying fuss.
This. And also: nothing will reduce the size of a js file better than
gzip. See content-encoding.
On Nov 14, 10:18 pm, Thomas 'PointedEars' Lahn <PointedE...@we b.de>
wrote:
>
Since no human beings (possible savants aside) can decipher minified code in
a reasonable amount of time so as to compare if the code they use is
equivalent to the code that is in the `deploy' "folder", what should it be
good for? That's the core problem with minifying: you test code but you use
completely different code; the tests, as thorough as they may have been, are
ultimately futile. Especially as most people don't even know how the
minifier works that they are using.
>
I have had a problem of this kind just once, when using the
"agressive" setting (which I have never used again). But not with the
"conservati ve" setting. The "minimal" setting seems to just strip out
comments, empty lines and trailing spaces, if that makes you feel
better.
JSMin is the "final touch" that every (big) .js file deserves, IMO.
A 1000 lines .js with soft-tabs has several kilobytes of %20's...
>
So what? Assuming "several" means 2 (KiB)
2 spaces per tab stop per line account for much more than that.
that's about 0.293 seconds
download time on a 56k modem in the best case (56 kBit/s), about 0.341
seconds in the worst case that I have seen yet (48 kBit/s).
....and there are millions of mobile users out there.
Literally
in the blink of an eye already, and broadband Internet connections,
which are more than 26 times faster than that, tend to be more common nowadays.
>
What's in your opinion the number of kiloBytes of junk that is ok to
send again and again and again ?
"Martin Rinehart" <MartinRinehart @gmail.comwrote in message
news:1063c6af-c5af-4c4e-9f99-8f6575ef6369@b3 8g2000prf.googl egroups.com...
How much javascript would you have when you decide that minifying is
called for?
What everybody else said plus:
Why minimize a Javascript file to save the odd K or two then the same page
probably has a dozen images that could be better compressed (at almost zero
loss of quality) saving hundreds of K.
Why minimize a Javascript file to save the odd K or two then the same page
probably has a dozen images that could be better compressed (at almost zero
loss of quality) saving hundreds of K?
Because most browsers block the loading of additional assets until the
JavaScript file has been completely loaded, compiled, and executing. The largest
component is the loading time, and minification and gzipping are very effective
optimizations.
I highly recommend that you get Steve Sourders's book on performance.
>>A 1000 lines .js with soft-tabs has several kilobytes of %20's...
>So what? Assuming "several" means 2 (KiB)
>
2 spaces per tab stop per line account for much more than that.
Even if its twice that amount it is still negligible as compared to the rest
of the file.
>that's about 0.293 seconds download time on a 56k modem in the best
>case (56 kBit/s), about 0.341 seconds in the worst case that I have
>seen yet (48 kBit/s).
>
...and there are millions of mobile users out there.
You don't serve large script files to mobile devices.
Anyhow, for 2 KiB that is
13.0 kbit/s on GSM, ca. 1.260 s
14.4 kbit/s on CSD, ca. 1.138 s
115.2 kbit/s on HSCSD, ca. 0.142 s
171.2 kbit/s on GPRS, ca. 0.096 s
384.0 kbit/s on EDGE, ca. 0.043 s
384.0 kbit/s to 7.2 Mbit/s on UMTS, ca. 0.043 down to 0.002 s
And, as others have already noted, if you are worried about the script size
you really should be worried about the document and image file size first.
>Literally in the blink of an eye already, and broadband Internet
>connections, which are more than 26 times faster than that, tend to be
>more common nowadays.
>
What's in your opinion the number of kiloBytes of junk that is ok to send
again and again and again ?
Wrong question. Whitespace is _not_ junk.
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
On Nov 15, 7:57 pm, Thomas 'PointedEars' Lahn <PointedE...@we b.de>
wrote:
>
You don't serve large script files to mobile devices.
>
You don't know what you're talking about: The last iPhone webApp that
I have written (not counting iui.js): 2256 lines of JavaScript, 64592
characters -43286 characters minified (conservative setting) ->
11561 bytes gzipped.
Minification alone shrinked it by 20k+.
Anyhow, for 2 KiB that is
>
13.0 kbit/s on GSM, (...) etc etc
Mobile users don't get that speeds, those are (in theory) maximum
speeds, nothing to do with what you really get.
On Nov 15, 7:57 pm, Thomas 'PointedEars' Lahn <PointedE...@we b.de>
wrote:
>
And, as others have already noted, if you are worried about the script size
you really should be worried about the document and image file size first..
>
Yeah, but not in this thread. This one is about minifying JS.
Comment