Namespaces are Old School

Let’s start with an overly simplified/generalized and mostly wrong history of the JS community during the past decade.

Let’s go back in time 12 years, to the distant year of 2000. JavaScript is being mostly used for form field validation, analog clocks and mouse trails. Nobody really cared about namespace cluttering, all the code resided on the global scope. This is considered the dark age of JS.

Now let’s fast forward 5 years, to the the first stage of the JavaScript Renaissance (2005-2007); libraries like jQuery, Mootools and Prototype.js are getting extremely popular, AJAX is the buzzword of the moment. Augmenting native prototypes was a very common practice and no caution was taken into consideration, the rule of thumb was easy development and brevity. Larger projects started being developed by more people and best practices started to appear. Sometime around this period closures became a popular way of hiding information and IIFE became the De facto standard. Namespaces also became really popular.

Now back to 2012. Everybody knows that augmenting built-in native objects is a bad thing, specially host objects. Polluting the global namespace is also considered a bad practice and many people avoid it as much as possible. It is not uncommon to see people adding their own application code into objects that they don’t own, proving that they don’t really understand why they shouldn’t have globals to begin with, but at least we are moving towards the right direction. <rant>Polluting any namespace is a BAD thing, not only the global scope, you should NOT put your application code into the $ object…</rant> Script loaders and package managers are becoming more popular each day, node.js is the buzzword of the moment and Harmony might become a reality and provide a native module format.

OK, no more history… Let’s see some code.

Read more…


RequireJS 2.0 Delayed Module Evaluation and Google Maps

The RequireJS behavior changed from version 1.0 to 2.0. Now module dependencies are only loaded after a explicit require() call or if it is on the dependency tree of some of the require‘d modules. That means that the module factory (define callback) won’t execute unless it is needed. That is a huge win for many reasons, less work for the JS engine and code has the same behavior before and after build. It also makes it possible to create alias to complex modules without triggering a download.

On my current project I have ~15 JS widgets that can be placed on any page and the amount of JS required by each widget is small so it makes sense to bundle all the JS into a single file for production (<30KB minified + gzipped excluding jQuery) instead of loading things on demand (a single request have better perf results than multiple requests in many cases).

I will show a very simple technique I used on the project to create an alias to the Google Maps API since I think it can be useful to other people as well in different contexts.

Read more…


AMD-Utils: Math Utilities

This post was going to be about the Math utilities present on AMD-Utils. Some of them are essential to my day-to-day work and simplify the code structure a lot.

I was going to explain how to use them (which is very easy) but most importantly, why they are useful and when to use them. But instead of publishing it as a post I decided to update the docs and add all the info there so everything is centralized.

I recommend that you try to understand these methods and which kind of problems they try to solve. They are all very trivial to implement but of an extreme usefulness depending on the kind of project you are building. I also think that some of them changed the way I approach some kinds of problems. I use them so much that it’s hard to imagine coding something complex without something similar (I coded the methods clamp/loop/lerp/norm a million times).

So jump over to the docs and understand how to (ab)use these helpers. Even if you are not using amd-utils you can check the source code and implement it by yourself or extract the methods. Most of them are common knowledge but I feel that not that many people know how to use them properly or outside of the regular context, that’s why I thought some explanation would be helpful.

Docs: http://millermedeiros.github.com/amd-utils/math.html


RequireJS plugins

One of the greatest advantages of the AMD module format over the other standards is that it supports loader plugins, which can be used to load other kinds of resources besides JavaScript, it can be a really useful feature and a nice way to abstract some simple behavior, it increases the loader flexibility a lot…

I just pushed to Github all my RequireJS plugins - if you don’t know it yet, RequireJS is an awesome script loader which can improve code organization a lot if used properly - so far I have plugins for loading images, JSON files (automatically parses JSON response), JSONP / asynchronous scripts (like Google Maps) and also script files without appending the “.js” file extension (useful for dynamic scripts). I will create new plugins as needed.

Watch the project on Github & fork it. Please use the Github issues to report bugs and also for features request.



amd-utils : modular JavaScript utilities

Last week I decided to split some of my personal JavaScript code into individual modules to provide an easy way of loading only what is really necessary and increase code reuse between multiple projects/libraries. The purpose isn’t to replace Dojo, jQuery, YUI, Mootools, etc, but to provide modular solutions for common problems that aren’t solved by most of them and to avoid using a full library when you only need a small subset of features.

The project is on github and I will keep adding new features as needed, there is still a lot of stuff to be ported from my legacy JS/PHP/AS3 code and also to be coded from scratch…
Read more…