Wev Development MashUp

In the last weeks I've been reading about a good bunch of interesting Web Development topics, so I think I'll put up here a list of links and some comments

First and foremost, some JavaScript fun. Years ago, when I first discovered prototype.js, I had a real great time thinking about how some of the functionality was coded and reading through the source code. I've had a similar or even better feeling when reading this nicely laid out version of underscore.js source code. It's one really worth learning experience. The chaining-wrapped objects thing is pretty interesting, and you come across with pretty interesting code fragments like this:

  var _ = function(obj) {
    if (obj instanceof _) return obj;
    if (!(this instanceof _)) return new _(obj);
    this._wrapped = obj;
  };

bear in mind that the "this instanceof _" comparison is used to check whether _ has been invoked as a function or as a constructor.

Another thought-provoking javascript snippet that I've found recently is this one:

var toStr = Function.prototype.call.bind( Object.prototype.toString );
toStr([]) // [object Array]​​​​​​​​​​​​​​​​​​​​​​​​​​​

Think that the result, is just like this quite simpler to understand code:
Object.prototype.toString.call( param )

I'm not sure how I ran into this excellent presentation about advanced jQuery stuff.

This article in InfoQ about how to speed up Web Applications has been a nice finding. Going further on the topics mentioned there, I also came across this guide.

Performance on the client side leads us to another interesting topic, Repainting and Reflow. This is one of the best articles on the topic that I've could find. One of the main rules to minimize reflows is avoid creating and appending DOM elements in a loop. In those cases we should append the elements to a "root" Node that has not been appended to the DOM yet, and then append the "root" node when all the children nodes have been appended to it. Sometimes we don't have a new root node, cause we want to append the new nodes to an already existing node (think of adding several li's to an existing ul). For cases like this, Document Fragments come really handy.

In my last toy project, I've found myself using CSS classes like "editBt", "saveBt" in order to identify elements in a html structure and bind javascript behaviour to them (these html were sort of templates/widgets, I would have multiple instances of them on the same page, so that's why I couldn't use an ID to identify them). I was not feeling much comfortable using CSS classes for this, so looking around the web I found several articles [1], [2] proposing an interesting alternative, data-attributes. It makes pretty good sense to me, we should use css classes only for presentation (layout and theme), not for semantics, and using them to identify the element as a "Save Button" is quite more on the semantic side. This said, one could think that data attributes should be a better way to implement microformats than CSS classes. The answer is No, as the HTML specification says custom data attributes are only to be used privately (privately in the sense of the current application) and microformats are devised for external use.
If you want to stick to css classes rather than using data attributes, the idea proposed here looks quite good to me, name those classes with a "js-" prefix, to make it clear that they have nothing to do with presentation and are being used just as javascript hooks.

That interesting article that I've just mentioned, takes us to another related topic about which I've been pondering lately, how we should better name our CSS classes. It should be obvious to anyone that using class names like "blueText" is clearly not the way to go, and we should use something that not so openly states the style being applied. However, it can be confusing to decide how semantic our CSS class names should be. The W3C and the html5 spec

but authors are encouraged to use values that describe the nature of the content, rather than values that describe the desired presentation of the content.

encourage us to use semantic names. Well, the article makes some great points against going too far with that, and I can agree in most of them. If you want to create CSS classes to be reused in multiple projects, you should not taint them with content information that is specific to one particular project.
Furthermore, my view is that as we use CSS classes for structure and layout, its semantics should be based on that, on presentation, and not on the content of the elements to which they'll be applied. I think this sentence in the jQuery UI documentation stands on this side:

The jQuery UI CSS Framework provide semantic presentation classes to indicate...

Let's look at some of the names used for jQuery UI CSS classes:
ui-widget-header, ui-widget-content...
well, these names are semantic in term of presentation, they are telling us that an element is a header or the associated content, but is not telling us what goes inside. We could store there a piece of news, or a book review or whatever... so we're not tied to specific contents.

Update, 2013/03/03: This post seems quite aligned with what I claim above

If a class name is used to describe the content, that class can only be used where that content exists, but when a class name describes a visual pattern, it can be used in many more places. The more abstract the visual pattern, the more reusable the class.