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…


Naming methods, properties and objects

Clear and descriptive names can increase a lot the readability and the understanding of a certain API or application, in some cases it can be a decisive factor on the success of a project.

I will share a few rules that I started following on the past years after reading many books and blogs about development, discussing with co-workers about it and mostly by experience. Most of the rules may seem dumb/obvious to a seasoned developer, but it is really impressive how many APIs from well-known libraries commit some huge mistakes and I think that a lot of people still don’t care about it as much as they should… I try to follow these rules as much as possible since I believe they contribute a lot for the quality and maintainability of my code but some people may not agree with my naming conventions and sometimes rules should be bent[1] or even ignored, take it as an advice not as a something “set in stone”.

Read more…


Why most JS devs don’t understand OOP

I don’t remember exactly when I had this “insight” but it was probably 1-2yrs ago, not really groundbreaking but may help some people see things with a different perspective…

Front-end JavaScript developers usually have a hard time trying to understand how Object Oriented Programming (OOP) works and how they can apply it to their work. I’ve seen some people saying that it’s because of the way prototypical inheritance works but I don’t think it is the main reason for that.
Read more…


JS-Signals: Custom event/messaging system for JavaScript

I’ve just released a new open source project called JS-Signals. It’s an event/message system similar to pub/sub and DOM2 Events but that doesn’t rely on strings to broadcast/subscribe to events, it has also some extra features that usually aren’t available on the other systems.

JS-Signals was heavily inspired by Robert Penner’s AS3-Signals but it is NOT a direct port, which means it has a different implementation and features. I’ve also stolen borrowed a few ideas from Joa Ebert fork ;).

Make sure you read the comparison between the different event systems and the usage examples.

Download it and get more info at http://millermedeiros.github.com/js-signals/.

Ideas and contributors are welcome!