My JavaScript book is out! Don't miss the opportunity to upgrade your beginner or average dev skills.

Saturday, March 30, 2013

Yet Another Reason To Drop __proto__

I know it might sound boring but I really want to put everything down and laugh, or cry harder, the day TC39 will realize __proto__ was one of the most terrible mistakes.

A Simple Dictionary Attack

ES6 says that Object.create(null) should not be affected anyhow from Object.prototype.
I've already mentioned this in the 5 Reasons You Should Avoid __proto__ post but I forgot to include an example.
You can test all this code with Chrome Canary or Firefox/Nightly and the most basic thing you need to know is this:
var n = Object.create(null);
n.__proto__ = {};

for (var k in n) console.log(k); // __proto__ !!!
Object.keys(n); // ["__proto__"] !!!
Got it? So, __proto__ is enumerable in some browser, is not in some other but it will be in all future browsers. Let's go on with examples ...
// store values grouped by same key
function hanldeList(key, value) {
  if (!(key in n)) {
    n[key] = [];
  }
  n[key].push(value);
}
// the Dictionary as it is in ES6
var n = Object.create(null);
Above code simply does not need to be aware of any problems except in older environment that won't work as expected. If the key is __proto__ instead of storing the value there will be most likely an error or the object will inherit from an empty array the moment n[key] = [] will be executed.
In few words, I believe you don't want to fear security and logic problems every single time you set a property to a generic object ... am I correct?
Now imagine some library such underscore.js, has the most common and generic way to create an object from another one, copying properties ...
function copy(obj) {
  var result = {}, key;
  for (key in obj) {
    if (obj.hasOwnProperty(key)) {
      result[key] = obj[key];
    }
  }
  return result;
}

// or if you want ... 
function extend(a, b) {
  for (var key in b) {
    if (b.hasOwnProperty(key)) {
      a[key] = b[key];
    }
  }
  return a;
}
Now guess what happens if you would like to copy or extend that list we had before, where __proto__ will be own property for the n variable and the loop is not checking the key as it should ... the object a, or the new one, will automatically extend an Array and break completely its own expected behaviors ^_^
This is nothing an explicit Object.setPrototypeOf() could cause ... moreover...

Real World Performance Impact

Every utility such lo-dash or underscore should now do this kind of check per each loop if these would like to be considered safe:
function copy(obj) {
  var result = {}, key;
  for (key in obj) {
    if (
      obj.hasOwnProperty(key) &&
      key !== '__proto__'
    ) {
      result[key] = obj[key];
    }
  }
  return result;
}
Now try to investigate in your real-world daily code how many times you change __proto__ compared with how many times you loop over properties ... I give you a test case to compare performance and remember: mobile matters!

Really Hard To Debug

Being a special property in the Object.prototype and not just a function you could wrap and keep under control, in a new scenario where any object could be instanceof anything at any time, the inability to intercept __proto__ calls and changes before it happens will be a painful experience in terms of debugging ... what was that instance before? Most likely, you'll never know ^_^
It must be said some engine makes that descriptor.setter reusable but this is not the case of current V8, as example, neither the case for all mobile browsers out there today.

A Stubborn Decision

What's driving me crazy about this property and all problems it brings, is that regardless there is a possible "speccable" Object.setPrototypeOf() alternative that would not suffer from anything I've described in all these posts, and just as reminder there is already a spec'd and widely available Object.getPrototypeOf() in ES5, TC39 will go on and make the problem a standardized one ^_^
I haven't been able to reason against them regardless examples and reasons ... but you could have fun trying too before it's too late!

Friday, March 29, 2013

Simulating ES6 Symbols In ES5

Symbols, previously known as Names, are a new way to add real private properties to a generic object.
// basic Symbol example
var BehindTheScene = (function(){
  var symbol = new Symbol;

  function BehindTheScene(){
    this[symbol] = {};
  }

  BehindTheScene.prototype.get = function(k) {
    return this[symbol][k];
  };

  BehindTheScene.prototype.set = function(k, v) {
    return this[symbol][k] = v;
  };

  return BehindTheScene;

}());

var obj = new BehindTheScene;

obj.set('key', 123);

obj.key; // undefined
obj.get('key'); // 123
In few words symbol makes possible to attach properties directly without passing through a WeakMap. A similar behavior could be obtained indeed via WeakMaps:
// similar WeakMap example
var BehindTheScene = (function(){
  var wm = new WeakMap;

  function BehindTheScene(){
    wm.set(this, {});
  }

  BehindTheScene.prototype.get = function(k) {
    return wm.get(this)[k];
  };

  BehindTheScene.prototype.set = function(k, v) {
    return wm.get(this)[k] = v;
  };

  return BehindTheScene;

}());

var obj = new BehindTheScene;

obj.set('key', 123);

obj.key; // undefined
obj.get('key'); // 123

Why Symbols

To be honest I am not sure but these somehow bring some magic to the object rather than wrapping magic around it, as it is for the WeakMap example, so at least performance should be better ... right? Well, the current shim VS shim says that indexOf() is faster than an implicit toString(): check this test out by yourself ;)
In any case it looks like private symbols will be a better way to go than WeakMap when all we would like to have is a private property. Symbols can be used as Enums too, being unique as any other object is.

Simulating Symbols In Current ES5 JavaScript

As easy as this:
var Symbol;
if (!Symbol) {
  Symbol = (function(Object){

    // (C) WebReflection Mit Style License

    var ObjectPrototype = Object.prototype,
        defineProperty = Object.defineProperty,
        prefix = '__simbol' + Math.random() + '__',
        id = 0;

    function get(){/*avoid set w/out get prob*/}

    function Symbol() {
      var __symbol__ = prefix + id++;
      defineProperty(
        ObjectPrototype,
        this._ = __symbol__,
        {
          enumerable: false,
          configurable: false,
          get: get, // undefined
          set: function (value) {
            defineProperty(this, __symbol__, {
              enumerable: false,
              configurable: true,
              writable: true,
              value: value
            });
          }
        }
      );
    }

    defineProperty(Symbol.prototype, 'toString', {
      enumerable: false,
      configurable: false,
      writable: false,
      value: function toString() {
        return this._;
      }
    });

    return Symbol;

  }(Object));
}
A very basic example here:
var sym = new Symbol;
var o = {};
o[sym]; // undefined

o[sym] = 123;
console.log(o[sym]); // 123
for (var k in o) {
  console.log(k); // nothing at all
  // there is nothing to for/in
}
delete o[sym]; // true
Of course, you can try also the very first example, the one with a shared, private, symbol variable, that will simply work as expected :)
Bear in mind, regardless being a hack, this script does not actually cause any problem to any other script or library you are using today but it needs ES5 compatible browsers such all mobiles plus all desktops and IE9 or greater.

Tuesday, March 26, 2013

5 Reasons You Should Avoid __proto__

Update: when you've done with this post, there's even more in comments and the newer one: Yet Another Reason To Drop __proto__
Too many discussions without real outcome about __proto__ magic evilness or feature. It's time to understand why using it is, today, a bad idea.

__proto__ Is NOT Standard (yet)

TC39 refused to standardize this property because of the amount of problems it brings. Apparently will be part of ES6 but is not there yet.
__proto__ is a silent, non spec'd, agreement. What's the problem? Keep reading ;)

__proto__ Could NOT Be There

The silent non standard agreement sees __proto__ as configurable property of the Object.prototype.
As example, try this in some environment:
(this.alert || console.warn)(
  delete Object.prototype.__proto__
); // false or true ?
The outcome is migrating from false to true. As example, current Chrome has a non configurable descriptor, while Canary has a configurable one. Same is for latest node.js, Firefox, and who know who else.
Having a property configurable means you cannot trust it's going to work because anyone could have decided to remove it ... why ...

__proto__ Makes null Objects Unpredictables

Theoretically, this is all you need to create one or more objects that inherits from null
var Dict = Object.create.bind(Object, null);

var dictionary = Dict();
dictionary[property] = 1;
if (otherProperty in dictionary) {
  // do stuff
}
// or
if (dictionary[someOtherThing]) {
  // do stuff
}
We cannot trust, as example in Chrome, that any property can be set there because if for some reason the property name is __proto__, that object inheriting null will completely be unusable/screwed.
Using hasOwnPropertyDescriptor() is not even an option since objects that inherit from null do not inherit these methods from Object.prototype.
The extra silent agreement here is that Object.create(null) should return objects that are not affected anyhow by any property from Object.prototype and __proto__ ain't any exception!

__proto__ Is NOT Secure

Since any bloody object could be modified directly or deeply anywhere in the middle of its prototypal chain, you can consider all your instances somehow exposed to any sort of attack.
Bad news is: you cannot redefine __proto__ to prevent this, at least you cannot in current version of Chrome and mobile browsers:
function ProtoSafe() {}
Object.defineProperty(
  ProtoSafe.prototype,
  '__proto__',
  {
    get: function () {
      return ProtoSafe.prototype;
    },
    set: function () {
      throw 'immutable';
    }
  }
);
Error: cannot redefine property __proto__

__proto__ Influences Your Logic

This is last point but actually still important. In ES3 it has never been possible to redefine inheritance over an already created instance and this has never been a real problem.
Polymorphism has always been possible through mixins and borrowed methods but again, no way an object could suddenly be any sort of instance with such lightweight casting unable to ensure any desired behavior.
What I mean, is that using [].slice.call(arguments) has a meaning: if there is a length in the used object, create an array with indexes filled from 0 to that length - 1.
This is different from generic.__proto__ = Array.prototype; because the length could be missing and the resulted object behavior be unexpected, broken, or again unpredictable.

Still A Cheap Way To Cast

This is the only advantage and the reason some library adopted __proto__ without even thinking about it: performance boost, compared to a whole slice, are a win, and specially in mobile and DOM libraries where results are always threat as ArrayLike objects.

Object.setPrototypeOf(object, proto) To The Rescue!

In ES5 all Object things are managed through the Object constructor so why not having a method in charge of the __proto__ behavior, since Object.getPrototypeOf(object) is already available?
Here some advantage:
  1. no way a property can destroy an object, the obj[propName] check against propName !== '__proto__' won't be needed anymore: performance!
  2. cheap casting still available so not a performance issue
  3. standardizing Object.setPrototypeOf(object, proto) can bring new possibilities such Object.freezePrototype(object) in order to ensure immutable inheritance when and if needed

A Cheaper Example

If you want to ensure TC39 will ever consider to drop this property in favor of better methods in the Object, here what you should stick in your library that is using proto:
var setPrototypeOf = Object.setPrototypeOf || function(o, p){
  o.__proto__ = p;
  return o;
};
It's cheap and performance, again, are as good as before!

Sunday, March 17, 2013

Some Repo News

Well, I don't always post about updates, changes, or new repos here, so here a quick and dirty post on things I've been tweaking, creating, or fixing, recently.

DOM4

This 100% test covered polyfill is awesome! Combined with some basic utility makes DOM manipulation life really easy. As example, this is how you can shuffle last to first one a list of li:
var li = document.querySelectorAll('ul.shuffle li');
li[0].before(li[li.length - 1]);

// or even better!
var ul = li[0].parentNode;
ul.prepend(ul.lastChild);
Pretty cool stuff from W3C!

experimental.js

The most compact and easy way to retrieve experimental features, or standardized, now supports CSS prefixes too.
var JSkey = experimental(
  window,
  'requestAnimationFrame'
  // optionally explicit, 'js'
);
// JSkey is the string
// webkitRequestAnimationFrame
// mozRequestAnimationFrame
// others too or
// requestAnimationFrame

// forcing JS assignment
if (!experimental(
  window,
  'requestAnimationFrame',
  true // force assignment
)) {
  window.requestAnimationFrame = function(cb){
    return setTimeout(cb);
  };
}

// now available in all browsers
requestAnimationFrame(daFunction);


var CSSkey = experimental(
  document.documentElement.style,
  'transform',
  'css'
);
// -webkit-transform
// -moz-transform
// or
// transform

require-updated module

Have you ever needed a module that updates automatically as soon as it's edited in node.js world? This module is meant to provide the most recent version of a module, of course if this is required in the wild rather than once at the top of the JS program.

polpetta

Some minor clean up and some big plan ahead, makes it the very first fully node.js web server with simplified configurations, as it is now, but extended to stream, gzip, and caching with ETags and all other common techniques to avoid the usage of a web server on top of it at all.
No idea how much this will take but I am willing to provide some good shit by the time node v1 is out, after next, 0.12, release.
If you don't know what is polpetta yet, considered it's the easiest way to have CGI like behavior in node.js in any folder and that it has been tested in all possible environments with excellent performance, even Raspberry PI, pcDuino, RK3066 modules, as well as Amazon server (not in production, I need those adds-on first).
This update is more about telling you that things are being improved and the project is everything but dead and the require-updated module has been created for polpetta indeed ;-)

gitstrap environment

While many keep struggling with node updates and the inability to run grunt, this or that dependency, gitstrap keeps being slightly improved making my git flow every day easier. Travis, wru tests, a proper Makefile, easy customization, I know I should probably spend a bit more time documenting or describing various "how-to" but I believe if you know very basics about bash and make, you don't need much from me there ;)

redefine.js

Not only a simplified, more secure, and battle-tested utility for ES5 engines (node.js, Rhino, others) and browsers (all mobile plus all desktops but IE8), now a simplified way to create Classes too.
Bringing the most useful part from the poo.js experiment, redefine.js now supports extend, to simplify inheritance in a semantic way, mixin as it will be in ES6, statics for constructors properties and public methods, and all other redefine powerful features like lazy property assignment, defaults for descriptors, and all other things needed for a Class based env, when and if needed!

CircularJSON Update

With support for non resolved paths when the extra flag is passed through .stringify(data[, receiver[, space[, DO_NOT_RESOLVE]]]).
The result will be similar to other parsers where the circular reference will have simply the word [Circular] in it.

You are welcome :) and see you soon!

Thursday, March 14, 2013

Solving Cycles, Recursions, And Circulars References In JSON

CircularJSON is my next level take on @getify thoughts about recursive-safe JSON.stringify() operation, going further than what @izs proposed with his json-stringify-safe module which aim, and purpose, can be summarized in his reply:
This module is useful for the use case I'm using it for. If it's not your cup of tea, well, GOOD NEWS! There are a lot of cups with a lot of different flavors of tea in them.
Thanks man, what you probably don't know is that actually, there are no concrete, safe, performant, solutions to that problem ... oh well, now there is one!

CircularJSON

My fully tested, 650 bytes, portable and cross platform solution, is based on same isaacz logic: the usage of JSON.stringify(data, receiver)
In few words, if you consider safe the native JSON, you can consider safe CircularJSON too in both serialization and deserialization.
Despite what you might think about recursive serialization, there's no magic behind and all tests can prove that CircularJSON is simply safe and working as you expect.

How Can Be That Safe

THe logic behind is based on native JSON behavior where the receiver and the reviver functions are all CircularJSON uses in order to work.
For the end user, same JSON API is preserved and it works as expected so nothing is different, except circular references are recreated during parse operation.
Once again, not a rewritten parser, neither a RegExp based solution, CircularJSON is the simplest solution to the most common circular, recursion, repeated object, problem.

How About Performance

This is tricky, and you can test performance via node test/benchmark.js and compare results in your machines and with your node version.
Generally speaking, performance is about twice as slow as regular JSON but only with never repeated data.
That's correct, as soon as there are repeated objects in the serialization and deserialization process, CircularJSON goes faster until being faster than JSON when there are more repeated objects in the stream.
I am obviously excluding cycles and circular references from the game since we all know JSON will simply fail, don't we?

Why Solving Circular References

First of all, because we are developers. If there are circular references it probably means we needed them, right? As summary, in my opinion, any attempt to get rid of circular references because of serialization is a failure for the simple fact that once deserialized, we canot have that reference back anymore.
THere could be cases we need circular references and as PHP, as example, solved them since ever through serialize() and unserialize() function, we might want to do the same via JavaScript: why not?!

Do Not Mix Shit!

While @izs thinks I am a moron noob, Kyle insinuated something could go wrong ... well, GOOD NEWS IS, they are both wrong as long as you don't use CircularJSON.parse() with data that has been encoded with JSON.stringify() and of course, the same is valid the other way round: do not .parse() via JSON what has been encoded via CircularJSON ... it's like using JSON to decode PHP serialized strings or vice-versa ... you know what I mean?

Welcome To Other Languages

As the fact it has been implemented in multiple programming languages helped JSONH to be that successful, and before, of course, JSON protocol itself, once many other programming languages in both client and server will be able to be compatible with circular references this project could be more widely adopted, specially to those that do not use node.js as server side solution.
Long story short, you are welcome, and thank you in advance, for any other language implementation you might want to push in this repository. Enjoy!

Monday, March 04, 2013

Breaking Array Extras

Every now and then somebody comes out with this problem:
How do I stop an iteration such forEach() ?
Well, there are at least a couple of ways to do that ...

Dropping The Length

The first tacky way to stop executing a function is to drop the length of the array. Every extra receives the initial ArrayLike object as third parameter so a function like this should be safe enough:
function forEachAndBreak(value, i, arr) {
  if (someCondition(value)) {
    arr.length = 0;
  }
}

someArray.forEach(forEachAndBreak);
Bear in mind, this will affect the initial array too so if this is not desired, a copy is needed:
someArray.slice().forEach(forEachAndBreak);

Cons: Still Looping

Even if this trick works as expected, there is something we don't see behind the scene: the loop is still going on. If you ever wrote some array polyfill, you might have heard that the for loop should verify that i in arr is true, before invoking the function or handling the value at that index since the Array might be a sparse one, where some index might be missing. The same happens with native arrays, you might try this and be stuck for a while: Array(0xFFFFFF).forEach(alert). It does not matter if that alert will never be called, the engine is looping through the whole length and verifying each index.

Using Some

This is the most common way to prevent the problem.
[1,2,3].some(function (value, i, arr) {
  alert(i);
  if (value === 2) {
    return true;
  }
});
Above will alert only 0 and 1 and the loop will be terminated as soon as true is returned. To quickly test this, let's use again that horrible, gigantic, Array ...
var a = Array(0xFFFFFF);
a[1] = 2;
a.some(function(v){if(v === 2) return true});
You'll notice that this time the return is immediate, there's no reason to wait after the first result.
In few words, Array#some() is way better than forEach() in all those situations where we would like to break the loop at any time: we just return true when we want to, no need to return anything in all other cases.

Array#every() Is NOT The Opposite Same

THe thing you might confuse about every is that you always need to return something while this is not the some() case. As we have seen, we return only when/if we want to break.

Finding The Index Or The Value: The Outer Scope Way

Another common pattern is to use this approach to actually find the index, something Array#indexOf() cannot achieve when the condition is more complicated than just a simple === comparison. Using an external variable can help here:
var index;
if (array.some(function (value, i) {
  if (complicatedCheckAgainst(value)) {
    index = i;
    return true;
  }
})) {
  doComplicatedStuffWith(array[index]);
}
Analogue situation with the value, so that we can directly retrieve what we are looking for if needed. However, this is kinda less common/used pattern since with the index we might splice or do more operations than just getting the value;

Finding The Index: The RegExp Way

This is quite tacky but fast enough and suitable when the extra argument is not used: I am talking about the context.
var index = array.some(function (value, i) {
  if (complicatedCheckAgainst(value)) {
    return this.test(i);
  }
}, /\d+/) && +RegExp['$&'];
if (index !== false) {
  doComplicatedStuffWith(array[index]);
}
Above pattern can be handy for inline operations:
[].some.call(body.childNodes,flagIt,reNum) !== false &&
(body.childNodes[RegExp['$&']].flagged = true);
Whenever it makes sense or not, we can reuse that function and that reNum in different situations and inline, without needing to create an outer variable. Latter point is indeed the main advantage, reusability without knowing the outer scope. This could be achieved creating something similar via a closure, but that would be probably boring...

Array#findIndex

It looks like TC39 will talk about a method ilke this too, so here what I believe would be a draft candidate:
(function(AP){
AP.findIndex || (
  AP.findIndex = function(fn, self) {
    var $i = -1;
    AP.some.call(this, function(v, i, a) {
      if (fn.call(this, v, i, a)) {
        $i = i;
        return true;
      }
    }, self);
    return $i;
  };
);
}(Array.prototype));
Enjoy!