Posts

Showing posts from January, 2012

ES6 Harmony Collections Fast Polyfill

Well, just in case you read RSS and you missed my tweet ... everything you need to know in github repository . Have fun with Harmony Collections

On EventEmitter In node.js

Today I had a whole node.js session and I have spent a bit of time looking at current EventEmitter implementation. I have twitted already that it sucks as it is, and while it's really trivial to implement the same for any browser , I believe many mistakes have been made about the API . Here the list: on() is a shortcut for addListener but there is no off() as removeListener's shortcut (inconsistent) add/removeListener is not DOM friendly, we cannot reuse an EventEmitter in the browser without double checking if those methods exist removeAllListeners() accepts no arguments and cleans up the whole emitter but there is no way to retrieve all listeners via listeners() passing no arguments (again, inconsistent) there's no possibility to use handleEvent property, as already defined in the EventListener , once again objects are not reusable between client and server no duplicated checks for both addListener and removeListener, this is totally inconsistent against DOM Event

Y U NO use libraries and add stuff

Image
This is an early introduction to a project I have been thinking about for a while. The project is already usable in github but the documentation is lacking all over the place so please be patient and I'll add everything necessary to understand and use yuno . Zero Stress Namespace And Dependencies Resolver Let's face the reality: today there is still no standard way to include dependencies in a script. If we are using a generic JS loader, the aim is to simply download files and eventually wait for one or more dependency in order to be able to use everything we need. The require logic introduced via node.js does not scale in the browser due synchronous nature of the method itself plus the sandbox not that easy to emulate in a browser environment. The AMD concept is kinda OKish but once we load after dependencies, there is no way to implement a new one within the callback unless we are not exporting. I find AMD approach surely the most convenient but still not the best one: w

For the record...

We unfortunately had to cancel the show this Friday January 13th at Union Pool. But, you should all still go check out Call of the Wild and Organs, two amazing NYC bands. Our next New York show is not until March 7th @ 285 Kent Ave We'll see you there.

Introducing ObjectHandler

since the discussion about a better Function#bind will probably never end, and since a must have dependency would be the ES6 WeakMap which is in any existent shim leak prone due lack of control via ES5+, I have proposed another way to solve the problem. ObjectHandler IDL Like /** * interface ObjectHandler implements EventListener { * void handleEvent(in Event evt); * void remitEvent(in Event evt); * attribute Object events; * }; * * @link http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-EventListener */ var ObjectHandler = { handleEvent: function handleEvent(e) { var events = this.events, type = e.type ; if (events.hasOwnProperty(type)) { events[type].call(this, e); } }, // it could be called removeEvent too, as you wish remitEvent: function cancelEvent(e) { e.currentTarget.removeEventListener( e.type, this, e.eventPhase === e.CAPTURING_PHASE ); } }; Above ob

Improving Function.prototype.bind

There are a couple of things I have never liked that much about Function#bind and this post is about proposing a pattern hopefully better than common one. At The End Of The Function A common argument about parentheses around inline invoked functions is that developers can easily recognize them. // considered ambiguous var someThing = function () { return {}; }(); // considered not ambiguous var someThing = (function () { // note the parenthesis return {}; }()); // note the parenthesis // exact same behavior of latest one // but considered slightly ambiguous var someThing = (function () { // note the parenthesis return {}; })(); // note the parenthesis The parentheses version apparently wins but, specially when no assignment is needed, I believe these are even less ambiguous: -function(){ alert("OK"); }(); +function(){ alert("OK"); }(); !function(){ alert("OK"); }(); Of course if there is an operator that function will be executed, why on earth