How to get a smaller code
This month I’d like to explain some examples of how the code I write ends up being small in production. There are various code quality metrics related to the lines of code per file, or even per function. And while everyone agrees that a 50k loc file containing your core logic is generally a bad smell, minifiers will love it and it’s a great middle step while creating your production build. So how do you get there? That… depends.
No really, it depends. It depends on your project. It depends on your team members. It depends on deliverable requirements.
For example, I’ve written a JavaScript parser that consists of two classes, each its own file. One class uses the other class and only a single function is exposed for the whole project as a module. The project uses a strict style guide where using any method on that inner class happens with a specific variable name. This way the tooling can recognize that if foo.bar() is being called, this foo was in fact my other class and not some random core JavaScript API. Next it processes the file with a parser. It renames the object structure (Foo.prototype = { ... }) and eliminates that object wrapper. It renames all the keys of this object to some prefix and replaces the colon with an assignment. Finally it puts a semi-colon at the end of each declaration. To illustrate: Foo.prototype = { a: function(){..}, b: 15 }; becomes foo_a = function(){ ... }; foo_b = 15;.
Since I’m using a strict style guide I can replace all the usages of that class in the other file by simply looking for foo.*. With a parser I can make sure I’m looking at variables and not a piece of comment or unrelated code. When I find it, I’ll rename foo.bar() to foo_bar(). Likewise for all the this.bar() inside the class self I’ll rename it to foo_bar(). This way all the occurrences of the methods and properties of the class get renamed to local function/variables. We do this for the other class too, which only has to concern itself with this.xxx() since it’s not used anywhere else.
This process leaves me with two ugly files with only local functions and variables, everything namespaced. I concatenate them, put it all in the same scope, and hand it off to a minifier. There are some special cases that make sure stuff is properly exported and state is dealt with and that’s that; performance increase as well as a much smaller size than I’d get when minifying prototype based structures.
Another example is a project that heavily uses modules and was relying on a project called “browserify” to create a neat package. Don’t get me wrong, browserify sure has its place, but to me the results are excruciating to look at. The ideal situation for a minifier would be everything in the same scope as local functions and variables. So to do this move all the imports to the top of the file, where they ought to be. Any exports are grouped together at the bottom of a file. Add some markers in comments to recognize the core of each file. A simple regex script to cut them out and put them all together in a big giant scope and then hand it off to a minifier.
The key here is again a strict style guide and in particular a naming convention where you name (module) local vars and functions quite explicitly and export them in the same way. So you’d end up with something like helper.js containing function helper_makeNice(){} and later exporting module.exports = {helper_makeNice: helper_makeNice};. You import it the same way; helper_makeNice = require('./helper').helper_makeNice;. Everything in the code will just use helper_makeNice so the code will still work when you cut away the imports and exports and put everything in the same scope.
Again, this won’t work for every project. Some are better suited than others. Some team members can handle java-esque naming conventions better than others. But if the requirements are small, you can go small.
I’m Peter and I do JS1k. It’s a JavaScript golfing competition where you have to create a complete JavaScript application in 1024 bytes. This years competition started in February and runs till mid may. Next time I’ll try to get deeper into how to build a JS1k demo. But in the mean time you should give it a shot yourself. You may not win but you’ll have fun building a demo. And that is fine too.
