A blog about design, code and some other stuff

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…

CSS was meant to style academic documents and simple sites (eg. wiki, blogs) where the cascade and descendant selectors makes a lot of sense. Unfortunately many sites we build nowadays are way more complex than that, and what used to work on simple projects doesn’t scale very well. We need to find smarter ways to code CSS to avoid the common issues and re-think the way we do our work. We should learn from the experience of other devs working in different domains, and apply into our own domain. Things like separation of concerns, modularity, encapsulation, DRY can (and should) be applied to large scale CSS projects as well. The main problem is that most people who are good at CSS doesn’t necessarily have a Computer Science background, most of them started as designers and learned CSS by themselves (that was my case…). That’s the main reason why I’m writing this post.

I won’t get into too much details/examples but will try to explain briefly each concept. Some of the SOLID principles are open to multiple interpretations on the CSS context - since we are shoehorning the concepts - that’s one of the reasons why I decided to not give detailed examples. I also think we should understand the idea and not be tied to a specific implementation.

Read more…

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…

I started using node.js to write build scripts since last year and even wrote a post about it before. The main reason why I decided to write my build scripts in plain JS is because I want them to be flexible and easy to edit. (Use the language you and your team are familiar with).

On this post I will try to cover some issues and the main reason why I’m not using a tool like grunt, buildr.npm, smoosh and gear on my projects. I’ll focus on Grunt since it is the most popular node.js build tool out there but the issues are present on other build tools as well (written in JS or not).

A couple days ago I sent a few tweets about it:

somehow I feel that @gruntjs is making the same mistakes as Ant. I would rather call JS methods instead of setting config options…

— Miller Medeiros (@millermedeiros) August 1, 2012

it would also make more sense to just run `node grunt mytask` instead of global install, would work better on windows. /cc @gruntjs

— Miller Medeiros (@millermedeiros) August 1, 2012

now I had a “crazy” idea for a project. A node.js adapter for Ant so you can call any task as a JS method passing JSON configs. #notdoingit

— Miller Medeiros (@millermedeiros) August 1, 2012

TL;DR; Build scripts should be real scripts and not configuration files.

Read more…

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