My JavaScript book is out! Don't miss the opportunity to upgrade your beginner or average dev skills.

Sunday, November 03, 2013

dumb.min

This is a needed explanation of a tweet of mine that has been mostly and instantly mistaken (just read through all comments):
this keeps bugging me: can we all please stop putting .min suffix when it comes to save bytes and use .max instead when size doesn't matter?
I've already posted about this a while ago but haven't seen much feedback/changes after that so here again trying to explain this matter only.
As spoiler, please don't take it personal or get offended by the abused dumb word, I am the first one that used and probably still use somewhere the .min suffix, aright?

Logically Speaking

So here the thing: we all use automations in order to create minified version of our files and if we don't we should. There are tons of easy to use tools out there, repositories such gitstrap that works with Makefile or grunt that could watch all files and keep building for us ... pick an option, create your own one, do whatever, and at the end create the build folder.

The dumb.min.js Output

Since we use automations, there's no reason on earth to provide to our users 4 extra bytes for a script, css, anything minified that is there to be served as fast as possible.
I mean ... the purpose of minification is to serve the minimum possible amount of bytes per each request, right? Where even headers and file names matter per every single network request, right?
Then .min is a name for developers that want to feel cool they are serving the minified version, throwing 4 extra bytes to every user, in every page, and for everything that uses such suffix conventions ... for who's supposed to be convenient?
The user? No! The bandwidth? No! The semantic? ...

dumb semantic

You now open any website that uses a CDN to load a common library. Let's choose jQuery, one of the most popular, right?
You go in the download page and there is no link to any CDN that does not end up with .min ... now ask yourself: who is that dumb that would ever serve the full, uncompressed, non gzipped/deflated version, of any CDN library? Develoeprs to debug? Good, they are 1% of the traffic of that website ... so is this how we do things? Penalizing the default use case in favor of dumb laziness?
What do you expect from a CDN in first place if not the best available and performant options to serve the file?

... and mootools-yui-compressed.js ...

When I've read this page I thought "this must be a joke".
Seriously, check all that Google CDN list. Actually, what does not contain .min is really not minified at all! There are developers out there serving Prototype 1.7 with comments and moreover, the gold medal for the best anti-pattern naming convention for a minified file goes to that mootools one. How about we put the date, and the list of all authors and the license name of both YUI and MooTools in there?</sarcasm>
140byt.es offers entire scripts in a tweet size, and we think naming something with 15 extra pointless-for-purpose chars as -yui-compressed is good for anyone out there?
Bear in mind this is not a real/concrete issue in using MooTools library itself, as explained later on, but a matter of logic that once applied everywhere, makes things look weird (aka: "something went terribly wrong at some point on the internet").
In this latter case, even automations could be improved and use -yc or something else if really needed (as if the tool used means different library behavior ... hopefully no, otherwise drop that tool!)

... plus min.map.js ...

If it was about having a convention able to tell the browser where to look for the file I would re-thinnk this ... but as you can see in Microsoft CDN all files need to have the equivalently named one with the map suffix so once again, who's gonna benefit from this dumb convention somebody created one day and nobody ever thought it wasn't that clever?

Quoting @craigpatik
...min.js, ...min.css, ...min.svg — one of those pieces has useful meaning; the other is redundant.

Not CDNs Fault

Absolutely not, it's entirely developers fault because their automation most likely will create those files with those names.
Still using jQuery as example, but many libraries are like this, the task to create distribution files is like:
distpaths = [
  "dist/jquery.js",
  "dist/jquery.min.map",
  "dist/jquery.min.js"
]
How utterly simple would be to have any of these variant instead ?
distpaths = [
  "dist/jquery.max.js",
  "dist/jquery.map",
  "dist/jquery.js"
]

// or ...
distpaths = [
  "dist/jquery.source.js",
  "dist/jquery.map",
  "dist/jquery.js"
]

// or ...
distpaths = [
  "dist/jquery.src.js",
  "dist/jquery.map",
  "dist/jquery.js"
]

// or ...
distpaths = [
  "dist/jquery.yo-mama-can-build-scripts-too.js",
  "dist/jquery.map",
  "dist/jquery.js"
]

What Will We Gain Doing So

So, it's not that suddenly anything will go twice as fast or any user will ever notice that, it's just a pure semantic, logic, sense sake and that feeling of "doing it right" that might show new comers on the web that we are not so silly that to serve less bytes we automatically put 4 extra on top just because ... no: we discussed about it, we thought about it, and we choose the best option available not going too far with extreme non-sense optimization as "dropping the whole name" would be, simply applying common sense and logic to the chosen pattern.

Otherwise, it's like thinking that to distribute an executable we need to use program.compiled.exe as name ... we don't, we know that's already the compiled version of an executable, same is for served files, in 2013 they should be by default optimized, and the source one, eventually available for developers purpose.

Once again, not a big deal. We can all sleep during the night keeping things in this way but every time you'll setup a build script again, maybe you'll drop that dumb repeated .min and do things logically in every single layer of your stack.

a bit of Math

Here I've quickly found some jQuery CDN related stats and I am pretty sure the amount of website using this library is more than "just 16000" but if we take that and multiply by 4, we have 64000 pointless extra bytes for jQuery only. Now, assuming every site will have some extra plugin or script, and some extra CSS, let's say a minimum of 4 total files, we'll have a minimum of 256000 pointless bytes on the air nobody needs, wants, uses. If we multiply these bytes for the extra space a name could take in any filesystem, the extra 4 bytes every single CDN request url will transport ... etc etc ... you see?

As conclusion, and even if 4 bytes aren't an issue in a singular case, can we all agree that if the whole internet uses .min in every (probably minified too) HTML file to refer external resources, there is an absurdly redundant amount of pointless data which aim is concretely unknown for everybody?
Thanks for your time and your possible, future, collaboration.

1 comment:

alex said...

s/\.max/\.orig/g

".orig.js" extension is already used quite widely, see https://login.anosrep.org/include.orig.js vs https://login.anosrep.org/include.js