When to minify?

[Thomas 'PointedEars' Lahn]

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

 

[David Mark]

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.

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]

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.

 

[David Mark]

David Mark meinte:


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]

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

 

[Thomas 'PointedEars' Lahn]

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.


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.

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.

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.

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

 

[Thomas 'PointedEars' Lahn]

David Mark meinte:

Your penchant for jQuery makes you a prime contender.

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


PointedEars

 

[Gregor Kofler]

Thomas 'PointedEars' Lahn meinte:

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

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

Gregor

 

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn meinte:

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

 

[David Mark]

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.

Perhaps you have had bad luck.

That does not mean anything.

In the original context it did.

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.

The debuggers I have always used show you the code in question. Some
better than others. For IE, you need Visual Studio (or InterDev or
whatever.)

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.

And what are those hits? Scripts by nobodies? See how many hits you
get for userAgent.

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



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.



JSLint has problems of its own, as has been demonstrated recently.  Suffice

Not related to this. (!) Yeah, there is some new superfluous message
about creating functions in a loop. I've seen it and I actually re-
factored a loop to shut it up. So what?

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.

You seem to have it backwards. Run JSLint first and it will tell you
where you mistyped. End of story.

 

[Thomas 'PointedEars' Lahn]

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.

Perhaps you have had bad luck.
ACK

That does not mean anything.

In the original context it did.

In *no* context does it mean anything that *you* did not found such an
error. It may be there nevertheless.

The debuggers I have always used show you the code in question. Some
better than others. For IE, you need Visual Studio (or InterDev or
whatever.)

As for "whatever", Microsoft Script Debugger is for free, and sufficient for
IE debugging. If you don't think so, name things you think are required for
debugging MSHTML-based scripts that it does not provide.

And what are those hits? Scripts by nobodies? See how many hits you
get for userAgent.

Your evaluation of the authors of these scripts is irrelevant to the
falseness of your statement that nobody uses p,a,c,k,e,[rd]. The record shows.

Not related to this. (!) Yeah, there is some new superfluous message
about creating functions in a loop. I've seen it and I actually re-
factored a loop to shut it up. So what?

There are more problems than this.

You seem to have it backwards. Run JSLint first and it will tell you
where you mistyped. End of story.

Rather the reverse. It is the (lack of) quality of minifiers that is in
question here, which JSLint cannot help with. You can run JSLint before
minification and you can run it after minification, but you can't be sure
that the minifier kept the semantics of your code while minifying
white-space in it.

Please trim parts you are not referring to.


PointedEars

 

[Eric B. Bednarz]

Your evaluation of the authors of these scripts is irrelevant to the
falseness of your statement that nobody uses p,a,c,k,e,[rd]. The record shows.

I’d very much agree.

Rather the reverse. It is the (lack of) quality of minifiers that is in
question here, which JSLint cannot help with. You can run JSLint before
minification and you can run it after minification, but you can't be sure
that the minifier kept the semantics of your code while minifying
white-space in it.

I tend to agree, but what is the lack of quality in minifiers precisely,
and why? Maybe I’m naive, but if you enforce avoiding automatic
semicolon insertion first, it shouldn’t be too hard to write a parser
that distinguishes at least comments, JScript CC, strings and regular
expressions (as long as the parser doesn’t use the latter itself for the
task in its native language); and once that’s automated, you could
always test against the production code.

 

[dhtml]

David Mark wrote:
Thomas 'PointedEars' Lahn wrote:
David Mark wrote:
The answer to "when tominify" 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 probablyI
have forgotten something else.

How to debug minified files? Use an alternate file.

I recently explained how I build and minify[1].

All code that is minified gets QA'd as minified. There is legacy code
that is not minified. Aside from that, all the new stuff gets built,
then minified.

CSS and js files are build from src -> build -> deploy.

deploy contains:
1) unminified, combined files
2) minified, combined files

This allows us to turn off minification on a per-request basis using a
request param "?nomin=1".

So, by default, the QA'd stuff is minified. When there is a JS-related
bug, it can be easily debugged using nomin=1. If the bug goes away by
that alone, then there is a missing semicolon or something.

Intelli-j catches missing semicolon. It catches assignment to
undeclared and other things. Good autocomplete, too.

[1]http://groups.google.com/group/comp.lang.javascript/msg/
794faf37a6ede59b?dmode=source

Garrett

 

[Thomas 'PointedEars' Lahn]

How to debug minified files? Use an alternate file.

That is not how proper QA works.

I recently explained how I build and minify[1].
[...]

Which is not how proper QA works.


PointedEars

 

[dhtml]

How to debug minified files? Use an alternate file.

That is not how proper QA works.

I recently explained how I build and minify[1].
[...]

Which is not how proper QA works.

As I said, "All code that is minified gets QA'd as minified."

You've quoted too little of what I wrote. You replied as if I had
written something else.

That is dishonest.

Garrett

 

[Thomas 'PointedEars' Lahn]

That is not how proper QA works.

I recently explained how I build and minify[1].
[...]

Which is not how proper QA works.

As I said, "All code that is minified gets QA'd as minified."

You've quoted too little of what I wrote. You replied as if I had
written something else.

That is dishonest.

Thin ice, very thin ice. People like you who easily call other's (my)
code "crap" and them (me) names just because of the delusions of an
obviously incompetent troll like Laurent Vilday[1], should be very
careful with telling others how to behave properly on Usenet.

I might have been unintentionally too careless when reading and
quoting; if so, I apologize for that.

However, none of this changes the fact that your approach at QA is
inherently unreliable, as you are testing and using completely
different code than you have written. Trimming of documentation
comments for brevity in production script code is excusable;
automatically having identifiers renamed, for example, is not.


PointedEars
___________
[1] <news:[email protected]>

 

[dhtml]

dhtml wrote:
Thomas 'PointedEars' Lahn wrote:
David Mark wrote:
[...]
Which is not how proper QA works.

As I said, "All code that is minified gets QA'd as minified."

You've quoted too little of what I wrote. You replied as if I had
written something else.

That is dishonest.

Thin ice, very thin ice. People like you who easily call other's (my)
code "crap" and them (me) names just because of the delusions of an
obviously incompetent troll like Laurent Vilday[1], should be very

Whose calling who names?

You got a code review.

Your response is to call the code reviewer "incompetent."

The bugs are valid and you are "calling names." You're reply was that
the code was "a bit outdated." (copyright 2008)

jQuery or Prototype (what you would call "junk") are better than your
"DHTML" function.

Regarding your posts, Gerard Talbot, Matt Kruse, JR Stockton have
expressed similar negative sentiments. Regardless, my opinion is based
on what I think, not because of "Laurent Vilday".

It is prefereable to focus on technical discussion. When Sometimes,
civil discussion is interrupted with "that is what you do not
understand" or "I am not here to reiterate the discussion for you," and
it becomes preferable to cease participation in the discussion with that
person. This is where you get the last word. Few people might actually
think you've proven something.

Usually inappropriate negative comments or sentiments in my posts are
witheld. Other c.l.js subscribers self-censor, too.

However, none of this changes the fact that your approach at QA is
inherently unreliable, as you are testing and using completely
different code than you have written.

No, that is not true.

That is not what I wrote.

You apparently assumed that I am testing and using completely different
code than I have written. You then replied based on that assumption.

You throw 'test' around casually. Test means a few things:

1) Unit tests. All library code (widgets, lower level code) is tested.

2) Functional tests. QA does this. A coworker and I are setting up
Selenium-RC for the company. Functional testing will change drastically.

The build process is run on every build. All developers have Tomcat on
their machine. I've set up the JS build/deploy tasks using in our front
end build.xml file (we have many build files)

So, when I get a bug, I fix it, and run ANT js_deploy. This builds the
js and minifies it, copying the unminified and the minified files to the
deploy directory.

I debug the issues uncompressed. When I'm done, I can remove the
"nomin=1" parameter from the URL, if I want to check that, and it works.
I don't check in code that I haven't run.

Intelli-j catches missing semicolons, highlighting the line. It would be
hard to miss.

Trimming of documentation

comments for brevity in production script code is excusable;
automatically having identifiers renamed, for example, is not.

You can make all the rules up you like,

We minify and it has all the benefits mentioned.

If those reasons don't make sense, you can read the "high performance"
book Douglas Crockford recommended. (I'm inclined to include that in the
next rev I make of the FAQ, along with other planned changes (toFixed)).

Garrett

 

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote:
dhtml wrote:
Thomas 'PointedEars' Lahn wrote:
David Mark wrote:
[...]
Which is not how proper QA works.
As I said, "All code that is minified gets QA'd as minified."
You've quoted too little of what I wrote. You replied as if I had
written something else.
That is dishonest.

Thin ice, very thin ice.  People like you who easily call other's (my)
code "crap" and them (me) names just because of the delusions of an
obviously incompetent troll like Laurent Vilday[1], should be very

Whose calling who names?

I am calling those names who have come to deserve it.

You got a code review.

No, I did not. I got a bashing, and you know it.

Your response is to call the code reviewer "incompetent."

As indicated by the "analysis", if it deserves to be called that.

The bugs are valid

There are bugs, and there are things that are perceived as bugs. For
example, using the comma operator instead of the semicolon, or the
firstChild issue, are *not* bugs. As for the latter, it should be
obvious that this method was never intended to handle MSHTML's
pecularity of removing some whitespace child node from the DOM (it
might be in the future). The bug is not in the method, but in the
DOM, as we have discussed ad nauseam already, and you know it.

and you are "calling names."

For good reason. When and if, how often, has Laurent Vilday ever
posted anything constructive or helpful and not ad hominem in this
newsgroup?

You're reply was that the code was "a bit outdated."

*In part*. And by this I was explicitly not only referring to
dhtml.js or all my script libraries, but to my whole Web site. I have
no problem to admit that they are in part outdated. Some parts are
more up-to-date than others.

That does not mean anything for the method I have recommended to the
OP, for it is definitely not outdated. And I have been referring them
to dhtml.js solely for this particular purpose! And then the troll
came and ripped the whole script apart. And then came you, and
finally tried to rip me as a person apart. Proportionality of
responses?

(copyright 2008)

The version that is currently online has a build version of
2008011717. I'm sure you can figure out when it was last updated, and
you can read the diff to find out what exactly was updated then.

jQuery or Prototype (what you would call "junk") are better than your
"DHTML" function.

If so, I am sure you can point out in which regards they are better.
Then we can discuss your views. Everything else I am just going to
ignore, for it is not constructive, highly subjective, and thus a
waste of time.

Regarding your posts, Gerard Talbot, Matt Kruse, JR Stockton have
expressed similar negative sentiments.

So what? Other people who I consider a lot more competent in matters
of ECMAScript and DOM scripting, have expressed rather positive
sentiments.

Regardless, my opinion is based on what I think, not because of "Laurent Vilday".

If that were so, you had added constructive comments to the
destructive review. You didn't, quite the opposite. For PointedEars
bashing is much easier, isn't it?

It is prefereable to focus on technical discussion. [...]

Pot, kettle, black.

Usually inappropriate negative comments or sentiments in my posts are
witheld.

Not this time at least, quite the opposite.

Other c.l.js subscribers self-censor, too.

Of those you mentioned above, though, I find it hard to believe. To
begin with, if Mr. Stockton really self-censored himself, how much
hatred and xenophobia would his postings exhibit then if they were
*not* self-censored? You can begin by just counting how many times he
diminished the (arguably unfortunate for programmers) US-American date
format as "FFF" ("Fred Flintstone Format"), and US Americans (and
infrequently the French) as a whole just because of their origin, or
how many times he called me a Nazi or compared me to the Nazis just
because he assumes that I am German. Then show me just one instance
where I ever have said such a thing or have called other's code just
"crap" without giving reason before or after. So much for self-
censorship.

No, that is not true.

Well, you are testing two different pieces of code, are you not?

That is not what I wrote.
[...]

Fair enough. I am working a similar process.

You can make all the rules up you like,

We minify and it has all the benefits mentioned.

It also has some drawbacks already mentioned.

If those reasons don't make sense, you can read the "high performance"
book Douglas Crockford recommended.

What would that accomplish? Another authority you tell me I would
have to yield to? Nobody's perfect, not even Douglas Crockford. He
may provide valid reasons in the book, but if there are valid reasons
in favor of minifying that outweigh the valid reasons against it, it
is not unlikely that I can find out for myself (for example, by
reading here).

Nuff said.


PointedEars

 

[Logos]

Martin Rinehart meinte:


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

Short answer: When people complain to you that your website takes too
long to load

I'll second Gregor as well - combining commonly used files in a
library is the best solution for speed as browsers are generally set
to only do 2 or 4 concurrent downloads from a site at once. And gzip
will speed up your DL times, tho it may wind up being even slower on
the client if they have an old machine or lots of other things chewing
up their CPU time.