grep, find, sed, awk are powerful and fast, but their APIs are hard to memorize and sometimes very awkward; so that’s why I use some tools that are slower but are way more user friendly.
Haters gonna hate, and there is definitely a hidden cost on using theses tools (you won’t learn the standard ones); but there is also a huge benefit on the ease of use.
I spent the past week optimizing the startup performance of a Firefox OS web app. While analyzing the profile and timeline data I realized that the DOMEvent “message” was causing a considerable delay – That “message” is actually based on David Baron’s setZeroTimeout function, which is used a few times along the codebase; So I had the idea to use a resolved Promise and check if it was going to change anything and I was impressed with the performance gains! So I decided to search if anyone else got into the same results, but couldn’t find anything and decided to write this post.
Will try to be brief, so it might not be clear unless you are experienced, will add more references at the end to make things clearer and maybe revise this subject later… - Time is a very limited resource nowadays.
JavaScript is a dynamic (and confusing), language, the way inheritance and typeof and instanceof works is not clear to most developers:
// JSWTF
typeof [1, 2] // 'object'
typeof null // 'object'
typeof 'foo' // 'string'
typeof new String('foo') // 'object'
'foo' instanceof String // false
new String('foo') instanceof String // true
new String('foo') instanceof Object // true
And things gets way more complicated when you have objects that come from different documents/frames/workers (they are created using different constructors, so instanceof doesn’t work)… So because of that I started to avoid typeof and instanceof and ended up realizing how cleaner the code becomes when you avoid type checking.
PS: I know that we can use Object.prototype.toString.call() for type checking, I’m mainly saying that most type checks are a bad idea, doesn’t matter what is the implementation.
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.
I believe that methods should be named as verbs, to make it clear that they perform actions.
new XMLHttpRequestdoesn’t fire the request,new HTMLDivElement()shouldn’t append it to the document, … – Elliott Sprehn
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.