Why do we have newlines in minified JavaScript?

Question

I know about a similar question but it is a tiny bit off from what I am asking here, so please don't flag it as a duplicate.

When you see the production version of jQuery, why is there a newline after a while? I downloaded a copy and deleted all the newlines (apart from the licence) and it still worked. (I ran the entire unit test suite against my changes on Mozilla Firefox, Google Chrome and Opera.)

The problem. In Google Chrome's "view source"

I know three newlines (not counting the license) is not going to slow it down a lot, but still, doesn't every tiny bit help?

I have assigned myself a small challenge, to squeeze every little bit of performance out of my JavaScript code.

You ran the **entire** unit test suite against your changes? — mgnoonan, Apr 17 '12 at 15:14
@AnishGupta what he means is, you said "and it still worked". How can you be sure that *everything* still works? Did you run the unit tests? — Alex Turpin, Apr 17 '12 at 15:22
Is your question specifically about the jQuery production library, or in general? FWIW, jQuery 1.7.2's line lengths are 32412 and 32770 each, so this _almost_ looks like a case of staying below 2^15 characters. — Phrogz, Apr 17 '12 at 15:23
I guess that answers my question. :) The unit tests are here: https://github.com/jquery/jquery/tree/master/test — mgnoonan, Apr 17 '12 at 15:25
@AnishGupta in *all* the browsers? JavaScript is tricky, as you have to run the tests in each specific browser you want to support, in order to test each JS implementation. — mgnoonan, Apr 28 '12 at 23:19

score 27 · Accepted Answer · edited May 23 '17 at 12:17

27

jQuery currently use UglifyJS to minify their source code. In their build script, they specifically set the max_line_length directive to be 32 * 1024:

The documentation for UglifyJS has this to say on the max-line-len directive;

--max-line-len (default 32K characters) — add a newline after around 32K characters. I’ve seen both FF and Chrome croak when all the code was on a single line of around 670K. Pass –max-line-len 0 to disable this safety feature.

edited May 23 '17 at 12:17

Community

1
1

answered Apr 17 '12 at 15:30

Matt

74,352
26
153
180

6

@AnishGupta what don't you get? They WANT the newlines. They configured their minify script so it would PUT the newlines there. – Alex Turpin Apr 17 '12 at 15:35
1

@AnishGupta because like Matt and others said, lines that are too longs can cause problems in certain browsers. – Alex Turpin Apr 17 '12 at 15:43
@AnishGupta glad you do :) Don't forget to consider accepting Matt's answer as the answer to your question if it helped you – Alex Turpin Apr 17 '12 at 15:49
9

Is this true for the most recent version of FF and Chrome? – Eric Apr 19 '12 at 23:20

score 15 · Answer 2 · answered Apr 17 '12 at 15:26

15

To cite the Closure Compiler FAQ:

The Closure Compiler intentionally adds line breaks every 500 characters or so. Firewalls and proxies sometimes corrupt or ignore large JavaScript files with very long lines. Adding line breaks every 500 characters prevents this problem. Removing the line breaks has no effect on a script's semantics. The impact on code size is small, and the Compiler optimizes line break placement so that the code size penalty is even smaller when files are gzipped.

This is relevant to any minification programs in general.

answered Apr 17 '12 at 15:26

katspaugh

17,449
11
66
103

Thanks for answering. I didn't know that. EDIT: Weird, I written this a while ago but it is only showing up now??? – Anish Gupta May 14 '12 at 15:21
1

The message must've been stuck between the firewall and proxy. – katspaugh May 15 '12 at 04:34
1

Never knew firewalls and proxies could be so stupid. PBFAP. Also, does anyone know of an example? I'm really skeptical that someone could write a firewall so bad that it corrupts files (and get paid from people still using it). – Camilo Martin Jul 27 '12 at 02:18

score 5 · Answer 3 · edited Jun 20 '20 at 09:12

The lines (excluding the license) are all around 30k characters in length. It could be to avoid bugs where some Javascript parsers die on extremely long lines. This probably won't happen on today's browsers but maybe some older or more obscure ones have such limits.

(Old answer below, which might also be applicable, just not in this case)

This might be because JSMin, a popular Javascript minifier will retain line feeds in the output under certain conditions. This is because in Javascript line feeds are significant if you leave out semicolons, for example. The documentation says:

It is more conservative in omitting linefeeds, because linefeeds are sometimes treated as semicolons. A linefeed is not omitted if it precedes a non-ASCII character or an ASCII letter or digit or one of these characters:
\ $ _ { [ ( + -
and if it follows a non-ASCII character or an ASCII letter or digit or one of these characters:
\ $ _ } ] ) + - " '

Other minifiers might have similar rules.

So this is mostly a precaution against accidentally removing a line feed that may be necessary, syntax-wise. The last thing you want is that your minified JS won't work anymore because the minifier destroyed its semantics.

Regarding »I know three newlines (not counting the license) is not going to slow it down a lot, but still, doesn't every tiny bit help?«: When your server uses gzip compression the difference will likely be moot anyway.

But why doesn't jQuery delete the newlines in the production version — Anish Gupta, Apr 17 '12 at 15:13
These rules don't seem to be relevant in where [jQuery 1.7.2.min is split](http://code.jquery.com/jquery-1.7.2.min.js); the first is between `G=function(` and `a)` and the second is between `var a=f` and `.clean(arguments);` — Matt, Apr 17 '12 at 15:19
Why should they? The production version will most likely be automatically generated without a human looking over it. — Joey, Apr 17 '12 at 15:20

Why do we have newlines in minified JavaScript?

3 Answers3

Linked

Related