Comment by 10000truths

4 years ago

I mostly agree with you, but I don’t mind minification when appropriate, as it can serve a functional purpose with tangible end-user-friendly benefits (less downloaded over the network = faster response times).

But if you want to be friendly to the tinkerers, you could always host both the *.js and *.min.js versions, and have the webpage just pull the latter - anyone who wants the unminified source can remove the “min” part from the URI, while the majority of end users will still benefit from pulling the minified js.

13 comments

10000truths

Reply
throwaway2214  4 years ago

minified js is not greatly smaller than gzipped js, I think the whole minification thing is a swing and a miss and now we have to deal with source maps and shit, and build pipelines and etc

    $ ls -la
    -rw-r--r-- 1 jack 197609 330905 May  4 22:56 watch.js
    -rw-r--r-- 1 jack 197609 152172 May  4 22:55 watch.min.js

    $ gzip watch.js
    $ gzip watch.min.js
    $ ls -la
    -rw-r--r-- 1 jack 197609 43690 May  4 22:56 watch.js.gz
    -rw-r--r-- 1 jack 197609 32507 May  4 22:55 watch.min.js.gz

  • MrDOS  4 years ago

    Of surprise to no one, Brotli does better on both:

        $ ls -l *.js
    -rw-r--r--  1 mrd  staff  330904  5 May 01:04 watch.js
    -rw-r--r--  1 mrd  staff  152172  5 May 01:10 watch.min.js
    $ brotli watch.js
    $ brotli watch.min.js
    $ ls -l *.br
    -rw-r--r--  1 mrd  staff  34461  5 May 01:04 watch.js.br
    -rw-r--r--  1 mrd  staff  27122  5 May 01:10 watch.min.js.br

    If I were serving this content, and if my web server and all of my target browsers supported Brotli, I'd be somewhat more content to ship an un-minified + Brotli-compressed file than an un-minified + gzip'd one. I'm sure it's some rule of thumb stuck in my head from the Web 2.0 era, but a JavaScript payload in excess of 40KB crosses some warning line in my head. (Probably 40KB / ~4KB/s throughput on a good dial-up connection = 10s transfer time, about the longest you'd want to wait for even a pretty spiffy page to load.)

    • MrDOS  4 years ago

      > I'd be somewhat more content to ship an un-minified + Brotli-compressed file than an un-minified + gzip'd one.

      Whoops, typo: I meant to say that I'd be somewhat more content to ship an un-minified + Brotli-compressed file than a minified + gzip'd one. That is, I'd be more happy to serve the 34.4KB watch.js.br than the 32.5KB watch.min.js.gz.

  • jseban  4 years ago

    > and now we have to deal with source maps and shit

    Yeah minification is only really for obfuscation. The small and unpredictable difference is absolutely not worth the ridiculous complex "solution" of source maps. Just the fact that your debugger really doesn't work right, is a deal breaker in and itself, not to mention all the time spent configuring and fighting with webpack.

    I don't think any form of "compilation" i.e. bundling, transpiling, minification etc is needed at all. Javascript can already dynamically load (additional) code files when needed, I don't understand why you need to bundle it in the first place.

    I don't buy that the http request overheads are so big that it motivates all this complexity, and in the average case a user don't use every single page of the application anyway, so by bundling everything you are always serving "too much", compared to just dynamically loading additional code.

  • lifthrasiir  4 years ago

    Gzipped JS is generally much smaller than minified JS, but minified-then-gzipped JS is even more so. The minification (assuming gzip) doesn't make a much difference in this case only because the input file is not that large at all and compression algorithms have a natural bias for larger inputs. You can (rightly) claim it is bad to have a JS file large enough that the minification makes a difference after all, but you'd be moving a goalpost then.

  • selcuka  4 years ago

    True, but it also removes the comments and the whitespace, leading to slightly better performance and memory usage. There are also less bytes to gzip on the server side.

    • Cthulhu_  4 years ago

      Slightly, but is it enough to warrant the extra steps?

      I don't think the difference is significant enough in this case.

      That said, I do think there should be an alternative to minification+gzipping, like e.g. a compiled version of JS that is more optimized than a browser's own JIT compiler can do. Mind you, that might up being a larger package than the JS source code.

      1 reply →

kevincox  4 years ago

A discoverable version would be to include source maps that link to the original as well. That way a browser console will automatically pull up the original.

klabb3  4 years ago

People measure minification in byte size (unfortunately I guess you're charged by CDNs by that metric too?). In reality everything text based compresses really well over the wire. In either case, importing tons of libs left and right is going to vastly out-size any minification, yet most fe devs are very liberal with dependencies.

Minification strips comments too though, which may be undesirable in many cases.

operator-name  4 years ago

That's simply not a very well followed (and thus discoverable) standard. Especially for hand crafted code, minifying functions and variable names only obfuscates what is written and minifying whitespace often only has minimal benifits.

In practice this seems to be a lost cause, and links to alternatively hosted source code is more common. Sadly this makes is simple to introduce subtle, harmful differences between the source and what is hosted.

monocasa  4 years ago

It's hard to guess that extra assets exist on the server if they aren't being pulled down by the site itself.

Seems better just to have premassaged source available in a repo somewhere, or called out on the page itself for a downloaded archive.