When to minify?

[Thomas 'PointedEars' Lahn]

Re: When to minify?

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]

Re: When to minify?

On Nov 19, 4:46 am, Thomas 'PointedEars' Lahn <PointedE...@we b.de>
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]

Re: When to minify?

Jorge wrote:

On Nov 17, 9:32 pm, Michael Wojcik <mwoj...@newsgu y.comwrote:

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

Re: When to minify?

Jorge wrote:

On Nov 17, 9:32 pm, Michael Wojcik <mwoj...@newsgu y.comwrote:

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

Re: When to minify?

Michael Wojcik wrote:

Jorge wrote:

>On Nov 17, 9:32 pm, Michael Wojcik <mwoj...@newsgu y.comwrote:

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

Re: When to minify?

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, <f806at$ail$1$8 300dec7@news.de mon.co.uk>

[Jorge]

Re: When to minify?

On Nov 19, 5:45 pm, Michael Wojcik <mwoj...@newsgu y.comwrote:

Jorge wrote:

On Nov 17, 9:32 pm, Michael Wojcik <mwoj...@newsgu y.comwrote:

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]

Re: When to minify?

On Nov 19, 7:14 pm, Thomas 'PointedEars' Lahn <PointedE...@we b.de>
wrote:

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

ROTFL

--
Jorge.

[Jorge]

Re: When to minify?

On Nov 19, 7:19 pm, Thomas 'PointedEars' Lahn <PointedE...@we b.de>
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]

Re: When to minify?

On Nov 19, 1:19 pm, Thomas 'PointedEars' Lahn <PointedE...@we b.de>
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]

Re: When to minify?

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]

Re: When to minify?

On Nov 19, 5:04 pm, Thomas 'PointedEars' Lahn <PointedE...@we b.de>
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]

Re: When to minify?

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]

Re: When to minify?

Jorge wrote:

On Nov 19, 5:45 pm, Michael Wojcik <mwoj...@newsgu y.comwrote:

>Jorge wrote:

>>On Nov 17, 9:32 pm, Michael Wojcik <mwoj...@newsgu y.comwrote:
>>>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]

Re: When to minify?

On Nov 19, 6:09 pm, Gregor Kofler <use...@gregork ofler.atwrote:

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!