When to minify?

[Martin Rinehart]

How much javascript would you have when you decide that minifying is
called for?

[Erwin Moller]

Martin Rinehart schreef:

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

[Jorge]

On Nov 14, 5:32*pm, Martin Rinehart <[e-mail]:

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.

--
Jorge.

[Thomas 'PointedEars' Lahn]

Martin Rinehart wrote:

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

[Thomas 'PointedEars' Lahn]

Jorge wrote:

On Nov 14, 5:32 pm, Martin Rinehart <[e-mail]:

>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>

[Gregor Kofler]

Martin Rinehart meinte:

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.

Gregor

[Joost Diepenmaat]

Gregor Kofler <us****@gregorkofler.atwrites:

Martin Rinehart meinte:

>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.

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/

[Jorge]

On Nov 14, 10:18 pm, Thomas 'PointedEars' Lahn <[e-mail]>
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
"conservative" 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 ?

--
Jorge.

[Jorge]

On Nov 15, 12:02*am, Joost Diepenmaat <[e-mail]:

>
This. And also: nothing will reduce the size of a js file better than
gzip.

Yes: minify + gzip.

--
Jorge.

[rf]

"Martin Rinehart" <Ma************@gmail.comwrote in message
news:10**********************************@b38g2000 prf.googlegroups.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.

[Douglas Crockford]

rf wrote:

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.

[Thomas 'PointedEars' Lahn]

Jorge wrote:

Thomas 'PointedEars' Lahn wrote:

>>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

[Jorge]

On Nov 15, 7:57*pm, Thomas 'PointedEars' Lahn <[e-mail]>
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.

--
Jorge.

[Jorge]

On Nov 15, 7:57*pm, Thomas 'PointedEars' Lahn <[e-mail]>
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.

--
Jorge.

[Jorge]

On Nov 15, 7:57*pm, Thomas 'PointedEars' Lahn <[e-mail]>
wrote:

>

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.

Huh ?

--
Jorge.

[dhtml]

Douglas Crockford wrote:

rf wrote:

I highly recommend that you get Steve Sourders's book on performance.

It's probably worthy of adding to the FAQ.

--
comp.lang.javascript FAQ <URL: http://jibbering.com/faq/ >

[dhtml]

Jorge wrote:

On Nov 15, 7:57 pm, Thomas 'PointedEars' Lahn <[e-mail]>
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.

Building into one file reduces the number of HTTP requests and adds one
file into the cache (not 20 or so, which can easily happen when applying
good old SRP).

If the file is minified, it will take less room in the cache. Cache
limits are finite. In mobile devices (like iPhone), cache is generally
not as large as a desktop browser.

Garrett
--
comp.lang.javascript FAQ <URL: http://jibbering.com/faq/ >

[Thomas 'PointedEars' Lahn]

Jorge wrote:

Thomas 'PointedEars' Lahn 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.

I happen to own an iPhone 3G. Its support includes EDGE and UMTS. What was
your problem again?

Minification alone shrinked it by 20k+.

On EDGE (I'm not even talking about UMTS) that makes about 0.860+ s less --
blink of an eye.

That said, you don't even see the contradiction: cutting off 20k+ due to
minimization from what, about 100k+ of code? And you are actually caring
about mobile users? That's ridiculous.

>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.

13.0 kbit/s *is about* the transfer rate of (original) GSM (which is not
very common anymore), channel splitting, syncing, bit error correction, and
time slots already considered. You may be right about the other transfer
rates, however even then the time difference would be negligible.

And you still miss the point.
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

[Jorge]

On Nov 16, 6:46 pm, Thomas 'PointedEars' Lahn <[e-mail]>
wrote:

>
That said, you don't even see the contradiction: cutting off 20k+ due to
minimization from what, about 100k+ of code? And you are actually caring
about mobile users? That's ridiculous.

That's ridiculous:

"Cutting 30k by gzipping is allright, but cutting 20k+ by minifying
isn't."

duh!

--
Jorge.

[Jorge]

On Nov 16, 6:46*pm, Thomas 'PointedEars' Lahn <[e-mail]>
wrote:

>
That said, you don't even see the contradiction: cutting off 20k+ due to
minimization from what, about 100k+ of code? *And you are actually caring
about mobile users? *That's ridiculous.

This is ridiculous:

"Cutting 30k by gzipping is allright, but cutting 20k by minifying
isn't."

duh!

--
Jorge.

"Silly things such as logic, common sense, rational
thoughts or good manners are not allowed in this
forum."

[Jason S]

As a regular user with a high-speed internet connection I don't care
about minification.

As a peek-under-the-hood user, I don't like minification.

As a frugal owner of a website hosted by a pay-by-usage service
(http://www.nearlyfreespeech.net/) I use gzip to keep my costs down &
am aware of minification -- if my site usage goes up, it is an option
that I will use to reduce costs.

[Michael Wojcik]

Jorge wrote:

>
This is ridiculous:

"Cutting 30k by gzipping is allright, but cutting 20k by minifying
isn't."

And how much larger is the file if you just gzip, and don't minify?
Frequent strings of repeated spaces ought to find a pretty high place
in the LZ table.

Frankly, as a user who on occasion has to debug scripts on other
people's pages (typically using Firebug) and fix them (generally with
Greasemonkey-injected scripts of my own), I think "minifying" is
damned obnoxious.

I've never felt the need to read web pages, much less attempt to use
ones with grandiose scripts, on a mobile device. If I did, I'd accept
the limitations of the tools I chose to use. I don't expect my toolbox
saw to cut as fast as my power compound mitre saw.

But if you want to cater to the technophiles, that's your business.

--
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University

[Jorge]

On Nov 17, 9:32*pm, Michael Wojcik <[e-mail]:

Jorge wrote:

This is ridiculous:

"Cutting 30k by gzipping is allright, but cutting 20k by minifying
isn't."

And how much larger is the file if you just gzip, and don't minify?
Frequent strings of repeated spaces ought to find a pretty high place
in the LZ table.

Yes, Wojcik, that's a good question, because most UAs "Accept-
encoding: gzip" nowadays: these are the numbers:

..js: 64592 chars.
..js: 43286 chars. (minified).
..js.gz: 14229 bytes. (gzipped).
..js.gz: 11561 bytes. (minified + gzipped).

43286/11561 = 3.74
64592/14229 = 4.54

As you guessed, the several Ks of whiteSpace allow gzip() to get a
better compression ratio.

OTOH, the non-minified script that ends up into the browser's memory
still weights (unnecessarily) +20k more than the minified version:
IOW, it both takes longer to transmit and occupies 50% more memory
once received. Is it a "don't care" ? I don't think so. YMMV.

--
Jorge.

[Jorge]

On Nov 17, 9:32*pm, Michael Wojcik <[e-mail]:

>
I've never felt the need to read web pages, much less attempt to use
ones with grandiose scripts, on a mobile device.

Yeah, but I'm talking about a webApp, not a page with some scripts.
You can't avoid big scripts with webApps, isn't it ?

--
Jorge.

[Gregor Kofler]

Jorge meinte:

OTOH, the non-minified script that ends up into the browser's memory
still weights (unnecessarily) +20k more than the minified version:
IOW, it both takes longer to transmit and occupies 50% more memory
once received. Is it a "don't care" ? I don't think so. YMMV.

Indeed. Since my currently running FF occupies 280MB, I suppose the 20kB
(0.007% of 280MB) are negligible. As you said: YMMV.

Gregor

[Jorge]

On Nov 18, 10:07*am, Gregor Kofler <[e-mail]:

Jorge meinte:

OTOH, the non-minified script that ends up into the browser's memory
still weights (unnecessarily) +20k more than the minified version:
IOW, it both takes longer to transmit and occupies 50% more memory
once received. Is it a "don't care" ? I don't think so. YMMV.

Indeed. Since my currently running FF occupies 280MB, I suppose the 20kB
(0.007% of 280MB) are negligible. As you said: YMMV.

Yeah, no need to gzip() either.

--
Jorge.

[Gregor Kofler]

Jorge meinte:

On Nov 18, 10:07 am, Gregor Kofler <[e-mail]:

>Jorge meinte:

>>OTOH, the non-minified script that ends up into the browser's memory
still weights (unnecessarily) +20k more than the minified version:
IOW, it both takes longer to transmit and occupies 50% more memory
once received. Is it a "don't care" ? I don't think so. YMMV.

Indeed. Since my currently running FF occupies 280MB, I suppose the 20kB
(0.007% of 280MB) are negligible. As you said: YMMV.

Yeah, no need to gzip() either.

Nope - since we are talking about *transferring* either 60kB or 14kB.
Once on the client it won't make a difference.

Gregor

[Jorge]

On Nov 18, 4:00*pm, Gregor Kofler <[e-mail]:

Jorge meinte:

On Nov 18, 10:07 am, Gregor Kofler <[e-mail]:

Jorge meinte:

>OTOH, the non-minified script that ends up into the browser's memory
still weights (unnecessarily) +20k more than the minified version:
IOW, it both takes longer to transmit and occupies 50% more memory
once received. Is it a "don't care" ? I don't think so. YMMV.
Indeed. Since my currently running FF occupies 280MB, I suppose the 20kB
(0.007% of 280MB) are negligible. As you said: YMMV.

Yeah, no need to gzip() either.

Nope - since we are talking about *transferring* either 60kB or 14kB.
Once on the client it won't make a difference.

Gregor

I give up.

--
Jorge.

[Gregor Kofler]

Jorge meinte:

I give up.

Victory, at last! The heinous empire of minifiers defeated.

[David Mark]

On Nov 14, 11:32*am, Martin Rinehart <[e-mail]:

How much javascript would you have when you decide that minifying is
called for?

Why would it matter how much?

The answer to "when to minify" is: right before you start testing the
script. As mentioned, if your server supports HTTP compression, then
the "minification" is mostly a waste (might help with the odd agent
that declines GZIP.)

[Thomas 'PointedEars' Lahn]

David Mark wrote:

The answer to "when to minify" is: right before you start testing the
script. [...]

Right. And when the test fails, you go fix the bug ... wait a minute,
*you can't*.
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

[David Mark]

On Nov 19, 4:46*am, Thomas 'PointedEars' Lahn <[e-mail]>
wrote:

David Mark wrote:

The answer to "when to minify" is: right before you start testing the
script. [...]

Right. *And when the test fails, you go fix the bug ... wait a minute,
*you can't*.

And why on earth not?

[Michael Wojcik]

Jorge wrote:

On Nov 17, 9:32 pm, Michael Wojcik <[e-mail]:

>I've never felt the need to read web pages, much less attempt to use
ones with grandiose scripts, on a mobile device.

Yeah, but I'm talking about a webApp, not a page with some scripts.
You can't avoid big scripts with webApps, isn't it ?

It depends on the application. I've written applications with web
front-ends that use little or no client-side scripting. But I
recognize that's not common these days.

I avoid using web applications from mobile devices just as much as I
avoid reading web pages from them. But, again, I recognize that some
people like that sort of thing, or have other reasons to do so.

My point was that different users have different preferences, so I
wouldn't advocate minimization to optimize for mobile users, unless I
believed there was a good reason to optimize for mobile users. The
mere existence of mobile users does not constitute such a reason, as
far as I'm concerned.

--
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University

[Michael Wojcik]

Jorge wrote:

On Nov 17, 9:32 pm, Michael Wojcik <[e-mail]:

>Jorge wrote:

>>This is ridiculous:
"Cutting 30k by gzipping is allright, but cutting 20k by minifying
isn't."

And how much larger is the file if you just gzip, and don't minify?
Frequent strings of repeated spaces ought to find a pretty high place
in the LZ table.

Yes, Wojcik, that's a good question, because most UAs "Accept-
encoding: gzip" nowadays: these are the numbers:

.js: 64592 chars.
.js: 43286 chars. (minified).
.js.gz: 14229 bytes. (gzipped).
.js.gz: 11561 bytes. (minified + gzipped).

Thanks. That's a useful data point.

OTOH, the non-minified script that ends up into the browser's memory
still weights (unnecessarily) +20k more than the minified version:
IOW, it both takes longer to transmit and occupies 50% more memory
once received. Is it a "don't care" ? I don't think so. YMMV.

Depends on what tradeoff developers want to make, of course, which in
turn probably ought to depend on what targets they're optimizing for.

If you're optimizing for devices with constrained resources (such as
mobile phones), then that 20KB of cache space might justify
minimization. If you're optimizing for really slow links, the 3KB of
additional data transfer might justify it.

If you're optimizing for users with lots of resources who might want
to read the source, you don't want to minimize. If you're concerned
about the possibility (however remote) of transformation effects, you
don't want to minimize.

Clearly, having relevant empirical data (as you now have for this
particular case) helps in determining what tradeoff to make.

--
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University

[Thomas 'PointedEars' Lahn]

Michael Wojcik wrote:

Jorge wrote:

>On Nov 17, 9:32 pm, Michael Wojcik <[e-mail]:

>>Jorge wrote:
This is ridiculous:
"Cutting 30k by gzipping is allright, but cutting 20k by minifying
isn't."
And how much larger is the file if you just gzip, and don't minify?
Frequent strings of repeated spaces ought to find a pretty high place
in the LZ table.

Yes, Wojcik, that's a good question, because most UAs "Accept-
encoding: gzip" nowadays: these are the numbers:

.js: 64592 chars.
.js: 43286 chars. (minified).
.js.gz: 14229 bytes. (gzipped).
.js.gz: 11561 bytes. (minified + gzipped).

Thanks. That's a useful data point.

[...]
Clearly, having relevant empirical data (as you now have for this
particular case) helps in determining what tradeoff to make.

Yes, but only for that particular file and not as a general recommendation,
though. For the figures will be different with different code!

In particular, it depends very much on how many unnecessary repetitions
there are in the code already; many people (and it seems especially those
that use minifiers) don't know how to write scripts properly and e.g. repeat
property accesses over and over again. That accounts for repetitions of
characters (byte sequences) as relevant for the Deflate (and any other)
compression algorithm, and is likely to account for whitespace that
minifying would replace.
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

[Thomas 'PointedEars' Lahn]

David Mark wrote:

Thomas 'PointedEars' Lahn wrote:

>David Mark wrote:

>>The answer to "when to minify" is: right before you start testing the
script. [...]

Right. And when the test fails, you go fix the bug ... wait a minute,
*you can't*.

And why on earth not?

Well, let's say testing shows that there's an error in line 42 of the
minified code that you want to fix. You could attempt to beautify the
minified code again and then compare with the original non-minified code,
but, to begin with, how can you know that even the lines numbers are the
same then?
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f8*******************@news.demon.co.uk>

[Jorge]

On Nov 19, 5:45*pm, Michael Wojcik <[e-mail]:

Jorge wrote:

On Nov 17, 9:32 pm, Michael Wojcik <[e-mail]:

Jorge wrote:

>This is ridiculous:
"Cutting 30k by gzipping is allright, but cutting 20k by minifying
isn't."
And how much larger is the file if you just gzip, and don't minify?
Frequent strings of repeated spaces ought to find a pretty high place
in the LZ table.

Yes, Wojcik, that's a good question, because most UAs "Accept-
encoding: gzip" nowadays: these are the numbers:

.js: 64592 chars.
.js: 43286 chars. (minified).
.js.gz: 14229 bytes. (gzipped).
.js.gz: 11561 bytes. (minified + gzipped).

Thanks. That's a useful data point.

OTOH, the non-minified script that ends up into the browser's memory
still weights (unnecessarily) +20k more than the minified version:
IOW, it both takes longer to transmit and occupies 50% more memory
once received. Is it a "don't care" ? I don't think so. YMMV.

Depends on what tradeoff developers want to make, of course, which *in
turn probably ought to depend on what targets they're optimizing for.

If you're optimizing for devices with constrained resources (such as
mobile phones), then that 20KB of cache space might justify
minimization. If you're optimizing for really slow links, the 3KB of
additional data transfer might justify it.

If you're optimizing for users with lots of resources who might want
to read the source, you don't want to minimize. If you're concerned
about the possibility (however remote) of transformation effects, you
don't want to minimize.

You forgot this one: if the server doesn't support HTTP compression or
if you're optimizing for UAs that don't accept-encoding:gzip, the 20k
of additional data transfer might justify it.

--
Jorge.

[Jorge]

On Nov 19, 7:14*pm, Thomas 'PointedEars' Lahn <[e-mail]>
wrote:

(...)
many people (and it seems especially those that use minifiers)
don't know how to write scripts properly (...)

ROTFL

--
Jorge.

[Jorge]

On Nov 19, 7:19*pm, Thomas 'PointedEars' Lahn <[e-mail]>
wrote:

>
Well, let's say testing shows that there's an error in line 42 of the
minified code that you want to fix. *You could attempt to beautify the
minified code again and then compare with the original non-minified code,
but, to begin with, how can you know that even the lines numbers are the
same then?

Too complicated for you.

--
Jorge.

[David Mark]

On Nov 19, 1:19*pm, Thomas 'PointedEars' Lahn <[e-mail]>
wrote:

David Mark wrote:

Thomas 'PointedEars' Lahn wrote:

David Mark wrote:
The answer to "when to minify" is: right before you start testing the
script. [...]
Right. *And when the test fails, you go fix the bug ... wait a minute,
*you can't*.

And why on earth not?

Well, let's say testing shows that there's an error in line 42 of the
minified code that you want to fix. *You could attempt to beautify the
minified code again and then compare with the original non-minified code,
but, to begin with, how can you know that even the lines numbers are the
same then?

Is this supposed to be a joke? For one, save the original
(obviously.) For two, who debugs by line number?

[Thomas 'PointedEars' Lahn]

David Mark wrote:

Thomas 'PointedEars' Lahn wrote:

>David Mark wrote:

>>Thomas 'PointedEars' Lahn wrote:
David Mark wrote:
The answer to "when to minify" is: right before you start testing the
script. [...]
Right. And when the test fails, you go fix the bug ... wait a minute,
*you can't*.
And why on earth not?

Well, let's say testing shows that there's an error in line 42 of the
minified code that you want to fix. You could attempt to beautify the
minified code again and then compare with the original non-minified code,
but, to begin with, how can you know that even the lines numbers are the
same then?

Is this supposed to be a joke?

No.

For one, save the original (obviously.)

When you can't be sure whether the error that occurred in the minified code
also occurs in the original code in the first place, or the problem is the
result of the minifying instead, saving the original code is not of much
help when finding a problem in the minified code.

For two, who debugs by line number?

OK, so how do you suggest to debug a one-liner that is the result of the
minifying of, say, 500+ LOCs? And even if you could do that *always*, I
seriously doubt you can look at one example of p,a,c,k,e,d code junk and
tell me at once which identifier in it means which in the original code,
because obfuscation is one result of this kind of minifying. Then we have
the issue of semicolon insertion or parenthesizing that needs to be done
explicitly in minified code but not in the original code. And probably I
have forgotten something else.
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann

[David Mark]

On Nov 19, 5:04*pm, Thomas 'PointedEars' Lahn <[e-mail]>
wrote:

David Mark wrote:

Thomas 'PointedEars' Lahn wrote:

David Mark wrote:
Thomas 'PointedEars' Lahn wrote:
David Mark wrote:
The answer to "when to minify" is: right before you start testing the
script. [...]
Right. *And when the test fails, you go fix the bug ... wait a minute,
*you can't*.
And why on earth not?
Well, let's say testing shows that there's an error in line 42 of the
minified code that you want to fix. *You could attempt to beautify the
minified code again and then compare with the original non-minified code,
but, to begin with, how can you know that even the lines numbers are the
same then?

Is this supposed to be a joke?

No.

For one, save the original (obviously.)

When you can't be sure whether the error that occurred in the minified code
also occurs in the original code in the first place, or the problem is the
result of the minifying instead, saving the original code is not of much
help when finding a problem in the minified code.

Perhaps you are just snake-bit, but I have never found such an error.
Before testing, I run the code through JSLint and then the YUI
"minifier." Invariably, the code runs exactly as before. If it ever
did not, I would find the problem easily enough. Thanks for your
concern though.

>

For two, who debugs by line number?

OK, so how do you suggest to debug a one-liner that is the result of the
minifying of, say, 500+ LOCs? *And even if you could do that *always*, I

What difference does it make how many lines of code there are (if you
are not debugging by line number?)

seriously doubt you can look at one example of p,a,c,k,e,d code junk and

Nobody, but nobody, uses that stupid p,a,c,k,e,r. What makes you
think I use it?

tell me at once which identifier in it means which in the original code,
because obfuscation is one result of this kind of minifying.

Again, there is no need to track down bugs in the minified code. If
there ever were, perhaps I would get a new minifier.

*Then we have

the issue of semicolon insertion or parenthesizing that needs to be done
explicitly in minified code but not in the original code. *And probablyI
have forgotten something else.

I already covered that (JSLint.) (The semicolons, etc., not whatever
you forgot.)

[Gregor Kofler]

David Mark meinte:

Nobody, but nobody, uses that stupid p,a,c,k,e,r. What makes you
think I use it?

Your penchant for jQuery makes you a prime contender.

Gregor

[The Natural Philosopher]

Jorge wrote:

On Nov 19, 5:45 pm, Michael Wojcik <[e-mail]:

>Jorge wrote:

>>On Nov 17, 9:32 pm, Michael Wojcik <[e-mail]:
Jorge wrote:
This is ridiculous:
"Cutting 30k by gzipping is allright, but cutting 20k by minifying
isn't."
And how much larger is the file if you just gzip, and don't minify?
Frequent strings of repeated spaces ought to find a pretty high place
in the LZ table.
Yes, Wojcik, that's a good question, because most UAs "Accept-
encoding: gzip" nowadays: these are the numbers:
.js: 64592 chars.
.js: 43286 chars. (minified).
.js.gz: 14229 bytes. (gzipped).
.js.gz: 11561 bytes. (minified + gzipped).

Thanks. That's a useful data point.

>>OTOH, the non-minified script that ends up into the browser's memory
still weights (unnecessarily) +20k more than the minified version:
IOW, it both takes longer to transmit and occupies 50% more memory
once received. Is it a "don't care" ? I don't think so. YMMV.

Depends on what tradeoff developers want to make, of course, which in
turn probably ought to depend on what targets they're optimizing for.

If you're optimizing for devices with constrained resources (such as
mobile phones), then that 20KB of cache space might justify
minimization. If you're optimizing for really slow links, the 3KB of
additional data transfer might justify it.

If you're optimizing for users with lots of resources who might want
to read the source, you don't want to minimize. If you're concerned
about the possibility (however remote) of transformation effects, you
don't want to minimize.

You forgot this one: if the server doesn't support HTTP compression

thenchange to one that does ;-)

or
if you're optimizing for UAs that don't accept-encoding:gzip, the 20k
of additional data transfer might justify it.

Thats fair enough.

there are other tradeoffs too..using a style sheet MAY help if you are
constantly sending similar style information.

Using more javascript subroutines if you constantly do similar things
all over the code.

--
Jorge.

[David Mark]

On Nov 19, 6:09*pm, Gregor Kofler <[e-mail]:

David Mark meinte:

Nobody, but nobody, uses that stupid p,a,c,k,e,r. *What makes you
think I use it?

Your penchant for jQuery makes you a prime contender.

I see. I could cleverly deflate all of that incompetent code that
didn't belong in my application in the first place to lighten the
impact of my incompetence. That could work!

[Jorge]

On Nov 19, 11:04*pm, Thomas 'PointedEars' Lahn <[e-mail]>
wrote:

>
OK, so how do you suggest to debug a one-liner that is the result of the
minifying of, say, 500+ LOCs? *And even if you could do that *always*, I
seriously doubt you can look at one example of p,a,c,k,e,d code junk and
tell me at once which identifier in it means which in the original code,
(...)

minified !== obfuscated: JSMin: http://fmarcia.info/jsmin/test.html

--
Jorge.

[Thomas 'PointedEars' Lahn]

David Mark wrote:

Thomas 'PointedEars' Lahn wrote:

>David Mark wrote:

>>Thomas 'PointedEars' Lahn wrote:
David Mark wrote:
Thomas 'PointedEars' Lahn wrote:
>David Mark wrote:
>>The answer to "when to minify" is: right before you start
>>testing the script. [...]
>Right. And when the test fails, you go fix the bug ... wait a
>minute, *you can't*.
And why on earth not?
Well, let's say testing shows that there's an error in line 42 of
the minified code that you want to fix. You could attempt to
beautify the minified code again and then compare with the original
non-minified code, but, to begin with, how can you know that even
the lines numbers are the same then?

[...]

>>For one, save the original (obviously.)

When you can't be sure whether the error that occurred in the minified
code also occurs in the original code in the first place, or the
problem is the result of the minifying instead, saving the original
code is not of much help when finding a problem in the minified code.

Perhaps you are just snake-bit,

Sorry, I don't follow.

but I have never found such an error.

That does not mean anything.

Before testing, I run the code through JSLint and then the YUI
"minifier." Invariably, the code runs exactly as before. If it ever did
not, I would find the problem easily enough. Thanks for your concern
though.

>>For two, who debugs by line number?

OK, so how do you suggest to debug a one-liner that is the result of
the minifying of, say, 500+ LOCs? And even if you could do that
*always*, I

What difference does it make how many lines of code there are (if you are
not debugging by line number?)

The debuggers that I have encountered so far work line-based (e.g., set a
breakpoint on or go to line #n, not statement #n). There are a few that can
beautify the code before debugging to make debugging easier (among them
Venkman), but not all.

>seriously doubt you can look at one example of p,a,c,k,e,d code junk
and

Nobody, but nobody, uses that stupid p,a,c,k,e,r.

Experience and Google hits disagree. There are 1'620 Google hits for
'"p,a,c,k,e,r" javascript", 1'930 for '"p,a,c,k,e,d" javascript'
as of today.

What makes you think I use it?

I did not imply that. You deem yourself to be too important.

>tell me at once which identifier in it means which in the original
code, because obfuscation is one result of this kind of minifying.

Again, there is no need to track down bugs in the minified code. If
there ever were, perhaps I would get a new minifier.

You cannot know that. You said before that you tested the *minified* code.
But that code differs from the original code. So you cannot know (until it
is too late) that minifying caused you additional problems.

>Then we have the issue of semicolon insertion or parenthesizing that
needs to be done explicitly in minified code but not in the original
code. And probably I have forgotten something else.

I already covered that (JSLint.) (The semicolons, etc., not whatever you
forgot.)

JSLint has problems of its own, as has been demonstrated recently. Suffice
it to say that even JSLint cannot recognize when parenthesizing or explicit
semicolon insertion was necessary in the minified version of the analyzed
code, because that is not only a matter of syntax, but also of semantics.
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

[Thomas 'PointedEars' Lahn]

Gregor Kofler wrote:

David Mark meinte:

>Nobody, but nobody, uses that stupid p,a,c,k,e,r. What makes you
think I use it?

Your penchant for jQuery makes you a prime contender.

Aren't you confusing David with, uhm, somebody else?
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>

[Gregor Kofler]

Thomas 'PointedEars' Lahn meinte:

Gregor Kofler wrote:

>David Mark meinte:

>>Nobody, but nobody, uses that stupid p,a,c,k,e,r. What makes you
think I use it?

Your penchant for jQuery makes you a prime contender.

Aren't you confusing David with, uhm, somebody else?

Definitely not. Should I have added a ;-) then?

Gregor

[Thomas 'PointedEars' Lahn]

Gregor Kofler wrote:

Thomas 'PointedEars' Lahn meinte:

>Gregor Kofler wrote:

>>David Mark meinte:
Nobody, but nobody, uses that stupid p,a,c,k,e,r. What makes you
think I use it?
Your penchant for jQuery makes you a prime contender.

Aren't you confusing David with, uhm, somebody else?

Definitely not. Should I have added a ;-) then?

Ahh, there:

| (X) TypeError: this.ironyDetector is not a function
| File: stressed/usenet.js
| Line: 42
\\// 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>