1 Is aliasing builtin globals such a great idea?

For the most part these suggestions are all quite good. I would personally be hesitant about aliasing some of the builtin global variables (such as document) though.

Whilst it may have a benefit in the size of the minified script, it could also defeat developers who are searching the source code, expecting to find “that document.getElementById” call they were looking to work on. Unless they know that document is regularly aliased and what it is aliased to, this practice could make their job harder (the job of their search tools at least).

Also, it feels counter-intuitive to me. You would be purposely introducing non-standard names for the globals. I would expect this to add to the (time) cost of adding new developers to the project as they are forced to cope with using new names for well-known/commonly-used variables.

From my own (server-side) experience – I once changed a common local variable that was “standard to me” in projects I work on. For months I caught myself instinctively mis-typing “db.CreateCommand()” where I meant to type “Connection.CreateCommand()”.

Perhaps I’m too shielded from the world of .js these days, I spend the vast majority of my time in serverside logic where the size of the source files doesn’t matter anywhere near as much but I certainly wouldn’t ever want to be futzing with the names of my builtins there.

Also – on the “single return point” issue, I always use a single return point regardless (and if I am returning anything, the variable I will be returning is always named “output”). It makes code so much more readable and easy to follow if you can be 100% certain that – as long as no exception is raised – execution begins at the start and will continue to the end of every method.

posted at 12:46 pm on July 20, 2010 by craigfowler

2 Is it worth it?

Not creating lots of global variables, and structured code without eval (evil) in general is a good idea. But I don’t like the idea of having obfuscated code in production.

First of all, I don’t like having to think about code that might not be compatible with the minifier you’re using. I don’t like extra restrictions, and I don’t want to think about them while coding, and I don’t want to stress about differences between production and a live environment.

Secondly, even though at the company I work at, we test our code quite a lot, there are always minor bugs that show up in production because of unforeseen combinations of factors. They should’ve been killed in production, but in practice they aren’t. It’s really useful if the code is actually readable so debugging is faster and easier.

With gzip and relatively fast internet, the amount of code saved is that minor that I conclude there’s not enough reason to minify. Unless you’re using a library that has proven to work as a minified version, like jQuery or Prototype.

posted at 05:36 pm on July 20, 2010 by Blaise.Kal

4 Minification as part of the build procedure

blaise and atk:

Remember, you should never have to look at/debug your minified code. If you need to fix a bug then you fix it in your development source code (laid out by your organisation’s standards, full of useful documentation and comments and the like) and then re-minify it. If a new developer comes into the project then you give them access to that source code, not just the minified script.

The best possible solution of course is to make the minifcation step part of your automated build procedure (you’re using an automated build procedure right?). That way if you need to do anything, you don’t just start hacking at the production code. Instead you work with the development copy and build it into a new production copy. This also works well if your are using a version control system ‘properly’:

Branch » fix » build » test » merge.

I like to think of minified JavaScript as I think of compiled binary executables and libraries. It’s not meant to be human-readable. If I want to change a binary then I edit the source code and rebuild/recompile to create a new binary. It’s the same with minified js.

posted at 06:08 am on July 21, 2010 by craigfowler

5 ternary instead of if else

The if..elseif example could be reduced further from 133 to 95 bytes by replacing the elseifs with a ternary structure:

function getValueFor(data){ return firstCondition(data) ?1 :secondCondition(data) ?2 :thirdCondition(data) ?3 :4;
}

posted at 07:03 am on July 21, 2010 by kae

6 Good for SEO too?

I like the content of this article and believe that squeezing every available byte out your page has many benefits across the board. With the feature-rich online applications these days, some pages can get bloated with necessary JavaScript libraries and associated files. Any reduction in your production environment filesize is a help to your end users.

We are currently investigating the effect of overall file size on SEO ranking and may use this technique to further optimise file sizes for (hopefully) increased effect.

Thanks

posted at 10:39 am on July 21, 2010 by Website Design Goucestershire

7 Is 5 bytes worth it?

Maybe I completely misunderstood your point at the end, but are you saying that your refactoring amounted to a 5 byte saving when minified and gzipped? Is that really worth it?

posted at 07:48 am on July 22, 2010 by skilldrick

8 Minifier serves the developer, not the other way a

I’m all for best practices, but some of the code changes suggested in the article make the code harder for others to understand and maintain. Not everyone is a javascript ninja like Nicholas. After factoring in the effects of gzip, the savings don’t seem worth the extra maintenance cost.

posted at 11:28 am on July 22, 2010 by rroelofs

9 What is the cost-benefit of this?

How much time did it take to refactor the code, in order to save a whopping 5 bytes in the gzipped file?

posted at 11:11 pm on July 22, 2010 by mvaughan