2014.04.13

Constructors should not cause side effects

Going to talk about something simple that took me a while to figure out I was doing it wrong. Don’t know when I realized it was a big mistake, I just know that it is something I’ve been trying to avoid for a while.

To begin, I’m not the first one to get into this conclusion. Many people before thought about the same thing, it is even one of the JSLint rules (“Do not use ‘new’ for side effects”). The thing is, I don’t think most people know the reason why this should be avoided; so let me explain why.

Constructors are not verbs

I believe that methods should be named as verbs, to make it clear that they perform actions.

new XMLHttpRequest doesn’t fire the request, new HTMLDivElement() shouldn’t append it to the document, … – Elliott Sprehn

Read more…


2014.01.12

Callbacks, Promises, Signals and Events

Sometimes I get involved in discussions on twitter and Facebook related to development. This week I ended up sending a link to an old(ish) twitter thread explaining when to favor Promises/Callbacks and when to use Signals/Events for asynchronous operations. I think this topic deserves further explanation.

Read more…


2013.03.05

Mout & Modularity

Discussions about modularity are recurrent. Some people say that each function should be a separate module/file/package; others say that methods should be contained by a package and grouped by similarity/concerns; and there is still a 3rd group that thinks that a single namespace is the way to go. I will try to explain the design decisions that influenced the creation and current structure of moutjs and why single function packages are not always the best solution.

Read more…


2012.02.03

Keep your modules and functions small

This post is about a very simple thing that I’ve been doing since I started to code (by coincidence) and that I feel that increases a lot the readability and organization of my code. Some people may not agree with it but for me it makes total sense and was also documented by some experienced developers like Uncle Bob on his great book Clean Code. I tend to think that a single approach may not be the best one for everybody - since every person thinks on a different way - but I’m pretty confident that this advise will be good to a lot of people and that it will increase the overall quality of the code.

The rule is simple, split larger functions/classes into smaller specialized ones, period. It will not only increase the readability but it will also make the code more reusable since it will be easier to override the default behavior if needed (especially if extending a class or reusing a 3rd party lib). I will try to explain how and give a basic example.

Read more…


2012.01.16

Signal Emitter

When I released JS-Signals I decided to create a document explaining the difference between different kinds of Observers and the possible pros and cons of each pattern, and as you can see on the document every approach has its pros/cons and depending on the scenario the recommended approach might change.

Before coding JS-Signals I was using a very basic EventEmitter “class” that could be used to listen/dispatch arbitrary events but ever since I released JS-Signals I almost didn’t used arbitrary events anymore (because of the benefits of using a Signal), but a couple weeks ago I had to propagate changes on my model classes to the UI and the changes are coming from many different inputs, so the easiest way to keep everything in sync was to dispatch events every time my model objects updated with a new value. In that case it is way easier to use a string ID for the event type than to create a new Signal object manually for each value, since the project was already using Signals everywhere I decided to code a simple EventEmitter that would use JS-Signals internal mechanism (so I could use the advanced features if needed) but still allow arbitrary event types.

Read more…