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!

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.

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!

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!

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!

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!

An In House, Yep Nope Like, JS Loader

Two days ago I've submitted a JavaScript loader to 140byt.es since this loader, once minified, fits into 136 bytes. The reason the entry is 140 in the site is that I've left on purpose /**/ to easily spot where you should put JS files to load.

And That's Not It

Once we have an Array, we have also .concat(), and once we have concat, we have the ability to decide, inline, what should be in the menu:

var
  menu = [].concat(
    // starter
   'onrefusedbeef' in window ?
      'caprese' : 'salami',
    // main course
    (function(window){
      return !!window.bigAppetite;
    }(this)) ?
      [
        'pasta',
        'salad',
        'bred'
      ] :
      'salad',
    // dessert
    ['coockies'].concat(
      this.extraCalories ?
        ['chocolate', 'sour cream'] :
        [] // nothing to add
    )
  )
;

// check the menu, chef
alert(menu.join("\n"));

You can play with different kind of menus, simply polluting the case with whatever i needed.

this.bigAppetite = true;
this. onrefusedbeef = null;
this.extraCalories = true;

The cute part about .concat() is the ability to pass empty arrays, when no extra value should be added to the list, just one element at the time, as example strings, or a list of elements, with the ability to create nested list thanks to nested [].concat().
In few words, Array#concat() suites perfectly with a list of files to include

Real JS Use Cases

Assuming we don't have partial shims in every single file, assuming we want to bootstrap whatever intakes to have a normalized environment, and do nothing otherwise, here an example:

// to loadvar
  OK = [],
  toLoad = OK.concat(
    Object.create ? OK : 'es5-sham.js',
    OK.forEach ? OK : 'es5-shim.js',
    Function.bind ? OK : 'bindOnlyShim.js',
    window.JSON ? OK : 'json2.js',
    [ // library list
      'lib.js',
      'main.js'
    ]
  );

// check this out
alert(toLoad.join("\n"));

In most modern browsers above snippet will alert only main files while in many Android browsers, the list will have Function#bind() only shim included, since everything else is there so Array extras are not needed. In older browsers we'll have Array extras, only after Object extras so that Array extras could use ES5 way to define extras ... in few words, the key here is to have scripts aware of their own dependencies instead of include partial shims all over and over ... this is because this little loader loads one script per time and this is ideal when scripts are ordered by dependencies.

All Together

Here how the script will look like, as last tag in your document body, in order to have exactly what you need, in exactly the order you need it.

<!DOCTYPE html>
<html>
<body>
<!-- everything you need -->
<script>
!function(b){

// extra functions, test, variables here
// it's a closure !

function c(){if(d=e.shift())a=b.body.appendChild(b.createElement("SCRIPT")),a.onload=c,a.src=d}var K=[],e=K.concat(

  Object.create ? K : 'es5-sham.js',
  K.forEach ? K : 'es5-shim.js',
  Function.bind ? K : 'bindOnlyShim.js',
  window.JSON ? K : 'json2.js',
  [ // library list
    'lib.js',
    'main.js'
  ]

),a,d;c()}(document);
</script>
</body>
</html>

Best Practices For Best Performance

• do not repeat mini/partial/shims/polyfills per each file, do not try to make every file stand alone. In this way you serve, and load, only what's needed
• decide statically, if necessary, dependencies in a logical order. If a file is shimming everything, and you want to trust that file, put that before any other that might try to put a shim if the library is not under your control so that file will use the already shimmed function you trust. As example, if any library contains a tiny JSON parser, put the official JSON polyfill before that file if needed. Same is for any library that tries to shim Array extras, put es5-shims before, and of course, only if needed
• aggregate everything that cannot be left out, unless your library is 2 Mb gzipped, or unless you have lazy loaded stuff ... but for everything else, really, there's no need to serve 100 tiny files, put them together as part of your library
• put main app logic a part and forget DOMContentLoaded or $(window).ready(), since this tiny loader works when the body and everything else is on the DOM ... did I tell you to put the loader at the very end of the page? :-)

Enjoy!

My Personal Github Flow

I've created many repositories in my programming history, starting from the good old Google Code, passing through Mercurial HG and svn, ending up using on daily basis the awesome Github.
There is something I've spotted every time I've created a new repo, I needed a way to do always the same thing ... but better each time!
The very latest case is the callerOf utility, something that small and already demanding usual/common stuff such:

• a meaningful and organized structure, instead of files in the wild
• an easy way to test for browsers and often nodejs too
• a simple build process per each target, able to combine them all at speed light
• a linter for those projects that could be widely adopted and linters are so annoying ... where was I ... right ...
• thanks to the same folder structure, an already prepared .gitignore, together with the .npmignore
• a LICENSE.txt file, in my personal experiments and libraries always Mit Style
• a Makefile able to help me combining all these tasks
• last, but not least, an almost fully prepared, and basic, package.json file with main info to publish
• optionally, the usage of .travis.yaml for the awesome Travis CI service

About Travis

Today I've maden a donation to help those guys maintaining the project. The email as soon as something goes wrong is a great way to be notified about problems. I've worked in many enterprise environment where this is the default, most basic configuration, to be instantly notified and be able to fix ASAP or revert instantly and a free service working all the time doing this for all those Open Source projects cannot be ignored, and applauded from Developers indeed.
All major programming languages are supported plus it's not that difficult to configure and it's based, if node.js is supported, to the simple npm test command: awesome!
I won't tell you how much I've donated 'cause it does not matter as long as you donate something to these good fellas, right?

I Might Not Need Travis, But ...

The basic way I've configured my gitstrap, this is the silly name I've chosen for the repo with most basic structure, forces me to build and run tests before being able to push. OK, OK ... is not that if I don't build and run tests I cannot push, I mean, it could simply be the README.md edited and not necessarily code, but to know if my code/library is working, I necessarily need to make and, in that case, be sure that everything is green.
In few words, the moment I push some code I am pretty sure Travis CI will be still green but if something goes wrong with one of the node.js versions, the test, the server, whatever, really, I'll be still notified and able to react.
The classic scenario is a pull request proposed without testing, mybe looks good, only Travis will tell you if it really does, right? ... oh well, feel free to enforce whoever sble to edit even online to run tests ... if you manage :)

What I Think Is Essential

In my cases these are the most basic dependencies, able to make my workflow freaking fast and robust enough too.

• wru testing framework for node.js and web via make test, already configured in latter case inside a handy index.html eventually published via gh-pages through make pages
• polpetta, in order to be able to automate the inclusion of the same test for both web and node.js in a ctrl+click and make web shortcut
• JSHint to eventually enforce the usage of a linter, through make hint shortcut
• UglifyJS

All above projects can be simply included in the current folder via make dependencies, not distributed via npm since these are not really part of the project, except the test, where in this case a tiny overhead of 130Kb for wru testing library isn't really a problem for anyone, right? :)

This Is gitstrap

Really a sort of github boilerplate for JS related projects, something already organized and ready to go, something you can simply:

curl -s https://raw.github.com/WebReflection/gitstrap/master/new >~/gitstrap && bash ~/gitstrap && rm ~/gitstrap

Following instructions here, or if you prefer a manual installation:

git clone git://github.com/WebReflection/gitstrap.git project-name
cd project-name
rm -rf .git
make dependencies
git init
git add .
git commit -m "gitstrap in"
git remote add origin git@github.com:yourname/project-name.git
git push -u origin master

After this, don't forget to update Makefile and package.json with the right name, specially if you are planning to push to npm, as well as the README.md.
I might decide to automate this procedure too pretty soon and any extra task or contribution will be more than welcome. Right now I think this is enough.

About Files And Folders

Right, this is where I explain what the hack is that structure ... let's start from the top:

build/

This folder will contain all versions of the same projects, if the project would like to be compatible with nodejs, web or generic JS engine, AMD loader based on define logic and stuff.

Yes, A Different Automated File!

After all discussion on "how should a file be to be compatible with all the mess out there" I've realized that exporting JS is really a matter of env, so if everything else is more or less the same, why on earth pollute all possible projects with that exporting nonsense? You need AMD? You get AMD ... You need node.js? You get node.js ... and same is for generic env, is really that easy!
Please note that all builds generate a .max version of the file, those I've just linked, and a minified version too, with the exception of node.js, since I don't believe in packed server side code that much :-)

index.html

This is used to generate the test page in gh-pages, so that once the pages have been generated, the test folder will contain those tests and launched through the index.html file.

Makefile

The most important thing to edit here is the name of the project and the main file, or the list of files to use. These can be different per build, if needed, or just the same for all of them. You decide!

LICENSE.txt and other files

Have been explained already :-) Modify the name in the license, modify the license too, if necessary, and that's pretty much it. You need to edit where necessary to go with your own project.

src/

Here is where your source files should go. If the build shoul dhave different targets, as example for node or amd, I think is good to prefix or suffix them with these names. The main used as example is what the project will export, just an empty object.

template/

This might look weird but it's actually what will be used, as file, before and after each build. These files could be empty too, it does not really matter, but it's handy to have them to easily generate AMD, node.js exports, or generic closures to use before and after the generic code reused across targets.

test/

Here the big deal, where the .test.js file will be in charge of running wru against whatever test is present in the folder, as long as there is a counter part in the src too. This should make the possibility to test in isolation easier. Bear in mind node.js needs to require() but the browser can load things in pieces so both built version and other files will be included and tested, if tests are in place.

As Summary

The aim of this repo is to make at least my life easier, and you can see already in all my github repos that the structure is already like this, and every project is a partial clone of the other with tiny improvements over the Makefile and some automation maybe not necessary anymore, as it was this good old builder once in python, then in nodejs, and finally obsolete in latter repos :)
Have fun with you extra ultra cool best library ever!

Jokes A Part ...

... is really that easy to start from the scratch or abandon everything, but that's not, by any meaning, an evolution, is rather a reboot.
Unfortunately, written software cannot reboot that easily, and we all know that, except few exceptions where is really needed and we call that refactoring!
Refactoring is needed when everything is not under reasonable control or performance anymore, refactoring puts everything on hold until it's completed ... you know that ;)

Focus On Reality

We really should never loose focus on what we are really trying to do, really trying to improve, and for who, if needed, and beside our own self thoughts.
If the rest of the world is doing something in a way, we have really few chances to change that way quickly and easily because we decide that way is wrong, right?
We need to be able to propose the best change able to improve that de-facto reality rather than thinking that we are able to improve everything simply imposing our own superior reality ... right ? The moment we'll impose blindly our own meaning of "best way ever", without even analyzing what's good out there, we are doing everything wrong, IMHO!

Graceful Enhance ... Everything!

Really, I think this is generally speaking the best way to go on and, probably, the only way to go too, since everything else has historically failed already so ... why try again?
Understand developers needs inside their libraries too, and not only patterns they used, is, as example, a good starting point.
I am expecting this to be a sort of JS improvements constitution for the most used programming language in the world, accordingly with the biggest open source community, at least in github ...

For A Better JS Future

1. do not break what has been widely adopted already, unless that's really bad in terms of security
2. try to stick with the already available and standardized syntax, allowing partial or full polyfills because of graceful OS, Environment, Browsers, Engines, whatever! migration
3. involve as many developers as possible (public survey over internal survey) rather than provide already decided internal decisions based in already decided internal pools nobody ever heard about out there

Three points, since everything else is reasonable already and done in a good way ... still!

Why Is This Important

I think these points are more or less everything I wished following es-discuss mailing list, really ... from time to time, I have experienced these situations, absolutely unexpected:

1. ES4 failed because it was braking the web, we have transpilers now, so everyone should use them instead of JS because of new unsupported syntax (transpilers break the web!)
2. if that library does that, and everyone likes that, and that library is not the old Prototype.js or another one nobody here heard about, that library is wrong and that behavior should be different
3. we don't want internals/private pools saying that what the rest of the world thinks is needed is wrong, we can have a much bigger audience through public surveys.

Latter one was the most frustrating experience, personally speaking, trying to follow and contribute in that mailing list with parallels, private, things behind the scene, I could not stand by since either you are public, being the ML public and telling the world you are, or you are not, and you can have, in that case, all pointless, useless, irrelevant, pools you can think about, without bothering the rest of the world with your results!

About That, I Apology because I know that specific case had, again, best intentions, but my point is that surveys should be public too because if 3 developers cannot represent the entire community, neither can 300 behind the same company, or just a couple. There are many more of us out there, I'd love to see the possibility to participate every time a decision about an API should be made!

Thank you for listening!

JavaScript Modules, Maybe

So, you might know already, but ES guys are talking these days about modules and things, as usual, went out of control since everyone wants its own best module version, ever!

Current Status

Synchronous, asynchronous, AMD, require() ... apparently these are all right for some use case, but wrong for some other.
It looks like JS cannot do synchronous modules ... wait what?

why browsers can't since browser have synchronous require since the very beginning? <script> tag anybody?

This was me after reading few times JS cannot do sync. Turned out, sync script is in HTML specs, not JS one, but wasn't this about JS indeed, where JS on browser never had this real problem and is simply envious of node.js module loader simplicity?

How About Facing Reality

... where in every language, requiring dependencies has always been synchronous because nobody ever cared about that latency, right? And did anyone even bothered using asynchronous file reading to include modules?
Not even node.js does that, the most async-centric env I personally know!
As summary, since this is a browser only problem, what I would expect is the ability from browsers engine to pause in a non blocking way the client until the file has been loaded. You know what I mean? F# does that so that's not an impossible reality ...
How cool would that be and how "free from browsers limits" the specification of the next module loader in a programming language would be?
The answer seems to be that JavaScript is not an HTML/W3C matter but is limited because of HTML/W3C implementors, those browsers ...

It Doesn't Matter, Had Module!

Developers are concerned that TC39 might not have real use cases and the funny part is that an evangelist of everything you know about the web as @paul_irish is had his self some concern about TC39 choices in term of real-world cases.
Meanwhile, AMD does not seem to be an answer, neither the preferred choice, but regardless we have these scenarios:

• those who write for the web and go AMD
• those who write for node.js and go require
• those who will probably add all this crap regardless, and with all due respect for the dev who wrote that with best intentions, even if testing only on web or only node.js (and again, the point is not about the snippet but the fact it should be everywhere in the JS world, you got what I mean, I am sure!)

In few words, Domenic's suspects are already a reality: nobody is even caring/following about what's going on in this discussion!
Lazy developers will simply realize at some point nothing works anymore and will go strike blaming the corrupted system, the conspiracy agains the World Wide Web, the fact nobody told them it was going to disappear or change even after 5 years of warnings about deprecations in console, etc etc ... right?
Wrong, they'll just use what worked for them 'till that day without problems and they will still think that you should not break what's in already, which is one of my favorite parts about ES5, the best update ever, if only every browser was there already, it would be a better JS world for everyone, isn't it?

Decoupling Import From Loading

How insane would that be? A semantic syntax that works in any platform, no matter how the platform loads stuff, the build process behind, or the fact you might wrap this way and do what you think is best, even improving upfront your static analysis ... right?
So here a beta repository called remodel, something you might want to git clone git://github.com/WebReflection/remodule.git to run eventually node node_modules/wru/node/program.js test/remodule.js and see that all tests are passing already.

Wait, What

So that project is about having import like syntax available even in ES3

// ES.next modules syntax
import {a} from "something"

// remodule
imports("a").from("something");

You are following, right?

// ES.next modules export
module.exports.a = "whatever";

// remodule
modules("something", {
  a: "whatever"
});

So, kinda yes, the missing part of all this mess is that a module should be able to register itself if we would like to static analyze it and make the logic work everywhere in both sync and async environments, right?

// ES.next modules export
module.exports = {
  what: "ever"
};

// remodule
modules("exports", {
  what: "ever"
});

// remodule backward compatible
modules("exports", module.exports = {
  what: "ever"
});

Latter example is about loading that file with current require or without it ... unfortunately modules function should be there but that's easy to fix, right?

What Else

modules("test", {
  a: "this is a",
  b: "this is b",
  c: "this is c"
});

With above code, we might be able to export the test module, regardless the position in the filesystem or the package manager, and do funny things such:

var test = imports('*').from('test');
JSON.stringify(test);
// {"a":"this is a","b":"this is b","c":"this is c"}

Cool? we just imported whatever the module exported itself ... there's really nothing to worry about, as @benvie might spot out, the this is safe too, is the exported object.

var a = imports('a').from('test');
a; // "this is a"

Well, it's straight forward to get that we can import just one thing from a module, right? Behind the scene, the module must be imported once, and never again, but we can grab a property as needed instead of the whole thing, right? ... and more!

var arr = imports('a', 'c').from('test');
// same as
var arr = imports(['a', 'c']).from('test');

// same as, once Array comprehension is in ...
var [a, b] = imports('a', 'c').from('test');

We can specify multiple properties out of a single module ... cool, uh? And more!

var aliased = imports({
  a: 'A',
  c: 'b'
}).from('test');

// in a real world scenario ...
var $ = imports({
  jQuery: '$'
}).from('jquery').$;

Yep, aliases are there too, so that you can actually test everything for real in this file.

So ...

what I've done there, is not even in charge of loading synchronously or asynchronously anything ... I mean, that should be your build process in charge of making things work and instantly available once needed, right? I mean, the Web/DOM part, I get it, modal spinners all over instead of a frozen tab so annoying for the user, but why nobody simply came out with a library in charge of this? Why ES6 modules will break browsers, using all those reserved words unusable in older browsers, will break node.js logic, being incompatible with the exported module, and will probably be never adopted in fact by anybody?
I am still dreaming about web improvements where stuff that gets out is what's really needed and most likely already used out there. Improved? Better? Sure! Pointless? No, thank you!

JavaScript EventTarget

This is about the W3C EventTarget interface, something standard in the DOM side, but still confusing in the JavaScript one where EventEmitter in node.js, or many other kind of constructors, are simply simulating what has been there for years, and standardized across all browser engines.

Now In JavaScript Too

Correct, I have implemented, written, and re-writtem this shit so many times that I have decided to "unofficialize" the already, well described, interface.

So, here the repository, something you can install in node via npm install event-target and checking examples on how to use it. Cool? I hope so :-)

Only thing that does not make much sense in a non DOM environment is the capture extra argument, something ignored from 90% of the web, something that can be really useful with the DOM but I could not think about any concrete utility in a pure JS world way. Cool thing is: anyone can extend, wrap, or improve, this EventTarget library: enjoy!

Opera Mobile Is The Best Browser!

I really do not understand why the Web keeps ignoring this browser which is able to provide the best browsing experience out of old hardware too!
It's not me saying that, there are all test you might want to double check or try by yourself.

• Opera Mobile VS Chrome mobile, a browser available only in latest hardware, and Safari Mobile for iOS 6, and we all know how good is the hardware here. Here the result, with Opera Mobile scoring more than anything else
• Hardware Acceleration, something possible on canvas you might want to test in this old prototype of a map, the same I have presented at Front Trends in 2010
• multi touches, so that an interaction with more modern UI based on gestures could work without problems. Here the tesla experiment

In Android 2.X Too

This is the part I love the most about this browser ... I mean, if you assume you have best hardware ever under the hood it's easy to be cool, right?
I am looking at you Chrome and Safari Mobile, and I am leaving Firefox Mobile outside this challenge since, unfortunately, it never competed against stock browsers, in terms of performance. They are getting better, and have to, with Firefox OS, but in an Android 2.3 ... not sure where they are :(
I have a Galaxy Ace, an Android 2.3 phone, that scores with Opera Mobile 406 plus 12 bonus points.
Basically, if all web apps out there would support Opera Mobile, people should not spend more to update their hardware because there is a browser that is kicking every other browser asses in term of performance!

Symbian Too

Correct, good old NOKIA phones could be up to date without problems simply using Opera Mobile, no need to spend that much to get a Windows Phone there, if the problem is the browser you can have touches and multi touches plus extreme performance boost simply downloading and using by default Opera Mobile: as easy as that!

Definition Of Best Browser

A browser that is able to bring to the user every possible modern feature, without requiring HardWare or Operating Systems updates. This would be, in my opinion, the best browser in the world, the missing piece we all have and somehow keep ignoring, in this web scenario.

Why Is That

I start thinking Opera Mobile team has a really bad marketing support. I cannot believe my stock browser scores 200 against 406 in Opera Mobile and there's no usage percentage in global stats about this browser if not about the Opera Mini version, a completely different beast?
Wha the hell is going on? Why aren't we all developing for this browser too? It's also the easiest to test since available in many platforms ... so, as summary, when I think about any HTML5 product that does not support Opera Mobile is kinda lame, while if it does not support Opera Mobile at its best, using all features that are available, usually twice as those available by default stock browser and in a really performant way, we should rethink our priorities, also because once again, this browsers is available in multiple platform so it should be the preferred target, rather than the least considered one. This usually means profit too so ... I am just saying, and thank you for listening!

The Difficult Road To Vine Via Web

One of the coolest and most rumored app of these days looked so fun, and conceptually simple, that I could not resist to challenge myself trying to reproduce it via HTML5 and all possible experimental things I know that are working these days for both desktop and mobile.

Wine

This is the name I have chosen for this experiment, and this is the very first warning: it does not work as it should, is not the equivalent, it cannot substitute the native App: too bad, but probably the reason vine team didn't even try to propose such broken experience.

Well, Something Is Working!

Guess who's this idiot with a Koala hat in a leaving room:



That's correct, "it's a me" through the wine experimental project and a Chrome browser. But let's talk a little bit about technologies I have used, OK?

• Client (in order of dependencies)
  • experimental.js and Queue
  • HTML5 getUserMedia({video:true, audio:maybe})
  • Recorderjs for the maybe and Canary only audio stream.
  • something else such XMLHttpRequest and FormData, but these aren't important
• Server (in order of importance)
  • node.js
  • polpetta
  • ffmpeg
  • gifsicle

If you want to know how to install the environment and play with the project, once again, the repository explaining how to :-)

How Does It Work

Well, you launch the server, you connect to that page, you press the video up to 6 seconds. If you release your finger or your pointer, it stops recording. when the top bar is filled up, each frame will be rendered as image and sent to the server, together with the audio, where some magic happens and the result is a video in mp4, ogv, and webm formats, plus a nice fallback as animated gif so that every single body can see again those 6 seconds, nice? Now, time to talk about all possible problems I had during its development ...

Everything You Know About getUserMedia() Is A Lie

This has been the biggest headache during the creation of this prototype.
All articles I have read, included this excellent one in HTML5 Rocks, which is marking the article valid for Opera and Firefox too, do not work ... really, as simple as that: that stuff does not work!

The Right Way To Attach A Stream

In my proudly created spaghetti code I ended up with a Frankenstein monster such:

function attachStream(media, stream) {
  try {
    // Canary likes like this
    media.src = window.URL.createObjectURL(stream);
  } catch(_) {
    // FF and Opera prefer this
    // I actually prefer this too
    media.src = stream;
  }
  try {
    // FF prefers this
    // I think it should not be needed if the video is autoplay
    // ... never mind
    media.play();
  } catch(_) {}
}

So, the most advanced browser is apparently behind the schedule because Firefox Nightly and Opera Next just refuse to work through the URL.createObject() approach.
However, I found Firefox behavior a non-sense because of the required play(), completely against the logic behind the autoplay video attribute.

Bad News Is ...

my code ain't gonna work for long time neither, things are changing, so keep reading and smile ^_^

AudioContext and AudioStream Is Nowhere!

Correct, another myth of these HTML5 days is the audio stream. Nightly is able to expose it inside the stream but I could not manage to retrieve it and handle buffers in and out. Nightly has also another really annoying problem, the redundancy of the microphone recording the audio itself ... a noise you'll spot if you don't mute manually your computer speakers.
I had to video.muted = true in order to avoid such disturbing noise, something present in Canary too but if the volume is not 100% is much less easy to reach that point. Canary seems to be more clever here! Opera does not seem to work neither with this audio stuff.
The best one seems to be Apple Safari browser: nothing works but they have the best documentation!

Surely It's Me

I might have done something wrong, but if browser vendors keep implementing and changing standards behind the scene how can this be developers fault?
Here an example, I ask how come getUserMedia() is so much NOT available?
The answer was this one!

Because Microsoft recently scuttled ongoing standardization efforts with a surprisingly valid counterproposal I'm afraid.

DAFUQ?!

I love all efforts from Microsoft, Firefox OS, Chrome OS, if any, and all others trying to propose standards ... but I don't understand any vendor that is trying to kill a reasonable one until the best proposed one ever will be rolled out ... I mean, can I haz that meow?

Until Things Are Usable

I feel like somebody is having fun screwing standards from time to time and every abandoned proposal that looks good to developers has the same destiny:

• stick forever in some library because in those days, that was the behavior
• make the new proposal not powerful regardless, since it came out of a hybrid, not perfect one, that everyone probably already adopted, as it is for localStorage and WebSQL, things that just work as developers need to do more, things still there, just randomly there
• fragmented on the Desktop, fragmented on the mobile more than ever and where on mobile, updates do not basically exist. On mobile, we keep changing Hardware generations, and not software!
  iOS here is a partially lovely exception, able to update longer, but my iPad 1 is stuck behind iOS 5.X, you know what I mean ... right ?

I really feel Christian Heilmann when he says that what matters is reachability and everything else is a futile discussion.
I probably have same feelings, better summarized, as web developer, in this personal thoughts:

It does not matter if it's touchstart or pointerEventDown event guys, what's important is that it f*#$!(in works when a person put a finger in his device screen and this person bought that device thinking is touch-able ... YES, THE BROWSER TOO!

Also, because people don't, and should, ever care about software, that's our problem, and should never be people limitation with the hardware and the software they like, they use, they need, they want ... but we keep smiling, right? ^_^

The Web Has Never Been This Broken

And this is the beautiful lie behind HTML5: it's utopia that never worked in reality!
Articles and examples that work only for this browser, the thing we have complained about for years about IE thinking "dude, if you don't know how to create a site don't write it works only for IE you lamer"!
Problem is, we are not going anywhere even on mobile, where guess what, platform fragmentation is growing much more than desktop one. On Desktop we have 3 OS Families, Windows, OSX, and Linux generic distro (I feel you Gentoo, Fedora, Redhat, Ubuntu, Debian, Kubuntu guys ... sorry to group you there).
On mobile, we have newcomers all over so iOS, Android 2.2/1.3/3.0/3.1/4.0/4.0.1/4.1/4.2 and here you have the coolest device ever, and Firefox OS plus that sneaky Opera Mobile, I mean mobile, not mini, the best, fastest, most updated, browser ever for both Symbian and Android 2.X!

Wasn't This About Wine?

Right ... you are right, I stop here wining about the fact that indeed, Opera Mobile is the only mobile browser able to work, even in Android 2.3, regardless low performance it just look and feel OK there, so if you want to try this you can try with Opera Mobile and enjoy the project.
Chrome Mobile doesn't getUserMedia(), so doesn't FirefoxOS, neither anything else I could try (come on, you are not trying with a windows phone, right? They killed the current standard proposing something else ... cooler, but more to wait for!).
So, the end of this story is that I have created a project which aim is to simulate a native App, and I miserably failed. Not because performance were not good, since once again it works via Opera Mobile in my Galaxy Ace, an Android 2.3 smartphone really simple, really functional, really usable thanks to a decent battery life due to low hardware specs, so ... again, it's not a performance issue, and you can test it, it's more about mistakes, rush, and wrongly accepted proposal from those that are deciding standards ... for good, sure, but if WebSQL was universally available, cross browser/platform speaking, how much more we, web developers, could have we done?
Think about it, that could have been the best thing ever to build No-SQL concept on top, but never something like this about IndexedDB:

Because this technology's specification has not stabilized, check the compatibility table for the proper prefixes to use in various browsers. Also note that the syntax and behavior of an experimental technology is subject to change in future version of browsers as the spec changes.

And this after at least 2 years ... now ask yourself honestly if current getUserMedia() was already available cross browser, how many creative things could have been created already?

At Least These!

• web based alarm systems, video can be captured into canvas, canvas can scan images, canvas can detect suspicious movements comparing diffs between previous image and current one in a place that supposes to be quite
• no need to call the specialist that will install the expensive hardware, the cable, the camera, and everything else, if we can program quadcopters via node.js, JavaScript is good and fast enough to monitor the house, the garage, the entrance, and tell you everywhere you are in the world, what's going on plus, if you need to, it can send you pictures while quadcopting around :D
• create a Skype like application without needing Skype at all ... OK, Skype offers an amazing service and we cannot even think to compete on web, but still ...

End Of The Rant

I am pretty sure John Resig, who's already using Vine since the very beginning, would actually agree with this Web situation .. or maybe not, since his story-rock API main goal was to uniform all this mess ... but should we keep relying third parts API rather than awesome, ultra skilled, exceptional people, in charge of the future of the Web?

Anyway, Wine Works With...

So once you have installed everything, all you have to do is to start polpetta in that folder and connect through these browser to that address: Chrome Canary, Firefox Nightly, Opera Next, Opera Mobile, or any other browser you think should support this app, and it will not ... keep smiling!!!! ^_^

Thanks for your understanding, I am developing web mobile since 2009, since Android 1.5, and the thing is: it never got truly better, it just kept changing and fragmenting!
Probably the reason I love my job, and the constant challenge it offers on daily basis but I'd like to do more there ...

Resurrecting The With Statement

You might think this must be a joke, well no, this is a partial lie behind the "use strict"; directive.

Roots Of The Hack

// global
"use strict";

function strict() {
  "use strict"; // top of the function

  return {
    // invoked inline
    withStrict: function(){
      return this; // undefined
    }(),

    // invoked inline too
    withoutStrict: Function("return this")()
  };

}

// the test
var really = strict();

really.withStrict;    // undefined
really.withoutStrict; // global, BOOOOM!

The Good News

I have been blaming since ever the fact that use strict makes impossible to retrieve the real global object ensuring nobody in the closure redefined window or global by accident so that code is more reliable.
Well, now we have the possibility to return it again when it's needed for security reasons or to be sure is the right one.

// a classic code for Rhino, node, and Web
var G = typeof window !== "undefined" ? window : global;
// then we need to use G

// with this hack
var global = Function("return this")();
// that's it, is the window or the global object

The Funny News: With Statement Is Back

So, we are able to deactivate the "use strict" directive in the global scope, right?
How about bringing back something that would throw an error otherwise in a strict context as with(){} is?

"use strict";
Function("with({test:123}){ alert(test) }")();
// 123

It Works!!! Awesome, we can use a with statement always be executed through Function which, differently from eval, evaluates in the global scope.

With Great Power Come Great Shenanigans

The reason number one for abandoning the with(){} statement is its ambiguity, together with the ability to pollute by mistake the global scope.
However, there were few things impossible to represent without that statement, and few of them have been proposed as the monocle mustache behavior.

array.{
    pop()
    pop()
    pop()
};

path.{
    moveTo(10, 10)
    stroke("red")
    fill("blue")
    ellipse(50, 50)
};

this.{
    foo = 17
    bar = "hello"
    baz = true
};

A Mustache Like With statement

Latter snippet is not able to pollute the global context, neither it changes context, plus it can interact with the outer scope. OK, it is not possible to implement automagically the latter one, but we can still avoid context and global context pollution ensuring a proper this value, and throwing errors if some variable does not belong to the mustached object.
How? Reactivating the "use strict"; directive again inside the non strict code: how crazy is that?

function With(o) {
  // needs a block, a function
  // can simulate that properly
  return function (f) {
    // deactivate during evaluation the strict directive
    return Function(
      // it is possible to use the with statement now
      "with(this){return(" + ("" + f).replace(
        // but we want to reactivate strict env inside
        "{", "{'use strict';"
      // avoid global context pollution
      // forcing a different this
      ) + ").call(this)}"
    ).call(o);
  };
}

So, let's see compared with previous examples, right ?

With(array)(function(){
    pop()
    pop()
    pop()
});

With(path)(function(){
    moveTo(10, 10)
    stroke("red")
    fill("blue")
    ellipse(50, 50)
});

With(this)(function(){
    foo = 17
    bar = "hello"
    baz = true
});

Does it work nested too ? Yes!

With({test:{key:"value"}})(function(){
  alert(test); // [object Object]
  With(test)(function(){
    alert(key); // "value"
  });

  // change the property
  test = 456;

  // by accident pollute the global scope
  not_defined = "oops?"; // throws an error ^_^

});

After that, removing the error at the end, the original object would shave the number 456 as test property.
In few words, we can have a secured with(){} statement behavior without the possibility to hurt the generic surrounding scope anyhow, except for those death browser without the strict directive, of course :D

Performance, Use Cases, etc

Yes, I believe the performance problem we know about that statement is still there, but with less problems to take care due strict behavior and a global environment. I would actually say that performance could be optimized with this technique, because no scope and context are implicit or modifiable anyhow, but I am not the right person to tell you what the hell happens in that case inside a JS engine :D
Use cases might be tests related, DOM related, since there things are slow in any case, or quick API prototyping due implicit return this nature of the hack: you decide :-)

Last Improvement

If you would like to adopt the technique but you want to be able to bring other local variables in that mustached block, you can use this version of the same function:

// The Strictly Monocle With Statement
function With(o,a) {
  return function(f) {
    return Function(
      "with(this){return(" + ("" + f).replace(
        "{", "{'use strict';"
      ) + ").apply(this,arguments)}"
    ).apply(o,a);
  };
}

With latest piece of code we can bring in that function whatever we need in this way:

With(
  document.body, // the implicit context
  [ // arguments to pass
    jQuery,  // jQuery
    window._ // lo-dash
  ]
)(function($, _){
  // le the magic happens
});

// or simply
With({},[1, 2])(function(a, b){
  alert([a, b]); // 1,2
});

:) Thanks for reading!

experimental.js

This is a tiny post about a tiny utility, something Modernizr like, but actually much simplified, like about 330 bytes minzipped.
Of course the power is kinda limited, but for most common things such requestAnimationFrame or CSS transition it should be more than enough.

Basic Example

You can find more in the experimental.js repository but here a couple of examples:

// check if present and use it
if (experimental(window, "requestAnimationFrame",
  true // optional third flag to assign the found property
)) {
  // in this case attached directly to the global
  // so we can just use it all over
  requestAnimationFrame(callback);
} else {
  setTimeout(callback, 10);
}

Another example, discovering the right string for transition:

var TRANSITION = experimental(body.style, "transition");
alert(TRANSITION);
// mozTransition
// webkitTransition
// oTransition
// msTransition
// or just transition

If you are wondering about pure CSS, it's easy to add a tiny extra step such:

function toCSSProperty(JS) {
  return JS
    .replace(
      /([a-z])([A-Z])/g,
      function (m, $1, $2) {
        return $1 + "-" + $2;
      }
    )
    .replace(
      /^(?:ms|moz|o|webkit|khtml)/,
      function (m) {
        return "-" + m;
      }
    )
    .toLowerCase()
  ;
}
var CSS_TRANSITION = toCSSProperty(
  TRANSITION
);

As we can see, it's easy to grab new features following the almost de-facto rule about checking properties with prefixes too in objects.
Bear in mind this is not as powerful sa Modernizr, neither it offers any yep/nope mechanism to download on features test library, got it? :)

Online Test

I have created an idiotic page which aim is to test experimental.js against most common objects, here an example.

redefine.js - A Simplified ES5 Approach

If you think Object.defineProperty() is not widely adopted, here the list of browsers that support it, together with Object.create() and Object.defineProperties().

• Desktop
  • Chrome 7+
  • Firefox 4+
  • Safari 5+
  • Opera 12+
  • IE 9+
• Mobile
  • Android 2.2+, 3+, and 4+, stock browser
  • Android 4.1+ Chrome
  • Android and Symbian Opera Mobile
  • Android Dolphin Browser
  • Android Firefox
  • iOS 4+, 5+, and 6+, Safari Mobile
  • iOS Chrome Browser
  • Windows Phone 7+ IE9 Mobile
  • Windows 8+ RT and Pro
  • webOS stock Webkit browser
  • Chrome OS
  • Firefox OS
  • I believe Blackberry supports them without problems with their advanced browser
  • I believe updated Symbian too but I could not test this
• Server
  • node.js
  • Rhino/Ringo
  • JSC
  • BESEN and others I could not test too

Except where I have stated differently, I have manually tested everything in this list but you can try by your self in kangax es5 compat table.
Please note that even if Object.freeze() and others might not be supported, create, defineProperty, and defineProperties are, as it is for example in Android 2.2 stock browser.
As summary, unless you are not so unfortunate you have to support that 8% (and dropping) of IE8 market share, there are really no excuse to keep ignoring JavaScript ES5 Descriptors.
Update the build process now updates tests automatically in the repository web page.

Descriptors Are Powerful

Things we can improve using ES5 descriptors are many, including new patterns we never even thought were possible since most of them might result not implementable in many other programming languages.
This is as example the case of the inherited getter replaced on demand with a direct property access, a pattern discussed in The Power Of Getters post, a pattern described from jonz as:

Right now this syntax seems like obfuscation but the patterns it supports are what I've always wanted, I wonder if it will ever become familiar.

Descriptors Are Weak Too

Not only the syntax might look completely not familiar for everything that has been written until now in JavaScript, but current specifications suffer inheritance problems. Consider this piece of malicious code:

Object.prototype.enumerable = true;
Object.prototype.configurable = true;

And guess what, every single property defined without specifying those properties, both false as default, will be enumerable and deletable so for/in loops and trustability will be both compromise.
Even worst, if Object.prototype.writable = true comes in the game, every attempt to define a getter or a setter will miserably fail.
I don't think we are planning to write this kind of code to ensure desired defaults, right?

Object.defineProperties(
  SomeClass.prototype, {
  prop1: {
    enumerable: false,
    writable: false,
    configurable: false,
    value: "prop1"
  },
  method1: {
    enumerable: false,
    writable: false,
    configurable: false,
    value: function () {
      return this.prop1;
    }
  }
});

Not only the moment we would like to assign a getter, we are trapped in any case, since we cannot have both writable and get, even if inherited, but above code has been always written in JS such:

SomeClass.prototype = {
  prop1: "prop1",
  method1: function () {
    return this.prop1;
  }
};

OK, this way will enforce us to use Object#hasOwnProperty() in every loop and does not guarantee that those properties won't change in the prototype, but how about having the best from both worlds?

redefine.js To The Rescue

This tiny library goal, which size once minzipped is about 650 bytes, is to use the power of ES5 descriptors in an easier, memory safe, and more robust approach.

redefine(
  SomeClass.prototype, {
  prop1: "prop1",
  method1: function () {
    return this.prop1;
  }
});

That's pretty much it, an ES3 alike syntax with ES5 descriptors and the ability to group definitions by descriptor properties.

redefine(
  SomeClass.prototype, {
  prop1: "prop1",
  method1: function () {
    return this.prop1;
  }
}, {
  // we want that prop1 and method1
  // can be changed runtime in the prototype
  writable: true,
  // we also want them to be configurable
  configurable: true
  // if not specified, enumerable is false by default
});

As easy as that, that group of properties will all have those descriptor behavior and everything is safe from the Object.prototype, you have 50 and counting tests for the whole library that should cover all possibilities with the provided API.

More Power When Needed

What if we need to define a getter inline? How to not have ambiguity problems since the value is accepted directly? Like this :)

redefine(
  SomeClass.prototype, {
  get1: redefine.as({
    get: function () {
      return 123;
    }
  }),
  prop1: "prop1",
  method1: function () {
    return this.prop1;
  }
}, {
  writable: true,
  configurable: true
});

That's correct, redefine can understand developers intention thanks to a couple of hidden classes able to trivially remove ambiguity between a generic value and a meant descriptor, only when needed, as easy way to switch on ES5 power inline.
Wen we need a descriptor? We set a descriptor!
If the descriptor has properties incompatible with provided defaults, latter are ignored and discarded so we won't have any problems, as it is as example defining that getter with writable:true as specified default.

Much More In It!

There is a quite exhaustive README.md page plus a face 2 face in the HOWTO.md one.
Other 2 handy utilities such redefine.from(proto), a shortcut of Object.create() using descriptors and defaults as extra arguments, and redefine.later(callback), another shortcut able to easily bring the lazy getter replaced as property pattern in every developers hands, are both described and fully tested so I do hope you'll appreciate this tiny lib effort and start using it for more robust, easier to read and maintain, ES5 ready and advanced, client and server side projects.
Last, but not least, redefine.js is compatible with libraries such Underscore.js or Lo-Dash, being an utility, rather than a whole framework.

Have You Met Empty ?

The proper title for this post could have easily been something like JavaScript Inheritance Demystified or slightly less boring as The Untold Story About JavaScript Objects ...well, thing is, I don't really want to alarm anyone about this story and as a randomly improvised storyteller, let's move forward, and see where it goes, starting from where it all began ...

Elementary, My Dear Watson!

The very first thing we might want to do, in order to make our research, discovery, and piece of programming history useful, is creating a couple of shortcuts that will let us easily analyze the code and the current story:

// retrieve the first inherited prototype
var $proto = Object.getPrototypeOf;

// retrieve all own properties,
// enumerable or not, ES5 stuff !
var $props = Object.getOwnPropertyNames;

Why do we need that? Because almost everything is an instanceof Object in JavaScript world, which simply means, and we'll see this later on, that Object.prototype is inherited all over!

Well, Almost!

Since Object.prototype is an object, there's no way this can be called as a function, right?
No doubts Object inherits at some point its own prototype but who added apply, bind, call, constructor, length, name, and that funny toString behavior in the middle?

Not Function !

That's correct, Function has nothing to do with that. Function actually inherited those properties and redefined some behavior such name and length.
Is the Object constructor instanceof the Function one ? Yes! Is the Function object instanceof Object ? Yes again and trust me: there's no real WTF!

Object instanceof Function; // true
Function instanceof Object; // true

The First Object Ever: null

This is the prototype of the prototypes, if we check $proto(Object.prototype) the result will be null indeed.
As summary, the very number one object to inherit from, possible in fact as Object.create(null) instance too, is this reserved static keyword everybody ever complained about because it returns "object" instead of "null" under typeof null inspection.
Can we start seeing that being the mother and the father of everything we use in JS world, "object" is kinda the best typeof we could possibly expect?

There Are Two Suns!

This is the lie we all believed until now, Object.prototype is where everything inherits from ... well, brace yourself, an hidden Empty object is part of this game!
Chicken or egg, who came first? You cannot use much philosophy in programming, you have to solve stuff and give priority or order to the chaos represented by requirements and/or implementations about specs, right? :D
So here the chain you have always wondered about:

null <
  Object.prototype <
    Empty <
      Function
      Object

Wait a second ... how can Object.prototype then exists before Object is even created ?
So here the secret about JavaScript, the elephant Classic OOP guys keep ignoring in the room: Object.prototype is just an object that's inheriting from null!
The fact we call it Object.prototype is because that's the only way to reach it via JavaScript but here how you could look at the story:

null: the omnipotent entity, the origin of everything,
      the daily Big Bang that expands on each program!

  prototype: like planet Earth,
             the origin of all our user definable problems

    Empty: the supreme emptiness of everything,
           meditation over "dafuq just happened"!

      Function: somebody has to do actually something concrete:
                the slave!

      Object: somebody has to take control of everything:
              the privileged king!

Are we done here? ... uh, wait, I knew that!

"The time has come," the Object said,
"To talk of many things:
Of keys and __proto__ and magic things
Of prototype and kings
And why that Empty is boiling hot
We show that pigs have wings."

The Object.prototype we set!
As prototype itself!

Object.prototype = prototype;

The instanceof Operator

As shortcut, instanceof is freaking fast compared with any user definable interaction with the code.
In few words, if you want to know if ObjA.prototype object is in the prototype chain of objB, you better objB instanceof ObjA rather than ObjA.prototype.isPrototypeOf(objB), I mean .. really, check performance here!

So, once we get the pattern followed by instanceof, it's easy to do the math here:

Object instanceof Object
// means
Object.prototype.isPrototypeOf(Object)

Remember the hierarchy? Object inherits from Empty, and Empty inherits from prototype so, of course Object inherits from prototype, it's transitive!

Object instanceof Function
means
Function.prototype.isPrototypeOf(Object)

Again, Object inherits from Empty so obviously Function.prototype, which is Empty indeed, is one of the prototype of Object ^_^

Who Defined The prototype Behavior?

This is the tricky one ... so, prototype is not even invocable and as such it cannot be used as constructor. Actually, neither can Empty, since it cannot be used as constructor too ... so new Empty will throw, watch out!
In fact, Empty introduces the [[Call]] paradigm, inherited by all primitive constructors such Array, Object, Function, Boolean, but is not inheritable from user defined objects, or better, you need to create a function(){} object to have that special behavior inherited from Empty and the prototype inherited from Function.

Empty.isPrototypeOf(function(){}); // true

Which prototype Behavior ?

Well, this is the main point about instanceof and isPrototypeOf(), the prototype behavior defined in the Function object, the only object adding that prototype property defining its behavior in the program!

$props(Empty)
["apply", "bind", "call", "constructor", "length", "name", "toString"]

$props(Function)
["length", "name", "prototype"]
// could be more in other engines

The Last Troll Ever!

It's clear that Empty introduced the constructor property too and guess what happened there?

"The time has come," the Empty said,
"To talk of many things:
Of constructor and new toString
Of call, bind, apply and kings
And why that caller is boiling hot
We show that pigs have wings."

The Empty.constructor we set!
The Function we just let

So that Function.prototype(aka:Empty).constructor === Function is true :)
Last, but not least, if you think as "Empty function" Empty is fast, just check this bench and realize that it could be the slowest function ever invoked!
So, here is the story of the root of all amazing things we can enjoy on daily basis in this Internet era, could you imagine?

JS __proto__ Shenanigans

I can't believe it, every time some cool pattern comes into games, __proto__ makes everything pointless, in a trusted meaning of a generic property!

Previously, in Internet Explorer

One of the biggest and most known WTFs in IE is the fact that Object.prototype properties are not enumerable.
While is possible to define such properties in ES5, this is the classic good old IE only scenario we all remember:

for(var key in {toString:"whatever"}) {
  alert(key); // never in IE
}

As simple as that, all native properties in the main prototype were considered {toString:true}.propertyIsEnumerable("toString") === false because indeed, these were not enumerating (just in case: enumerable properties are those that should show up in a for/in loop)

The Same Mistake With __proto__ If Not Worse

That's correct, the moment you play with this property name things start falling a part same old IE way or even worst.

alert(
  {__proto__:"whatever"}.
    propertyIsEnumerable(
      "__proto__"
    ) // this is false !!!
);

Not only enumerability, but also the hasOwnProperty(key) is gone!

var o = {};
o.__proto__ = 123;
o.hasOwnProperty("__proto__");
// false !!!

Do Not Use Such Mistake

Even if part of new specs, __proto__ is showing off all its anti pattern problems we all laughed about when it was IE only.
As a property, we should not have any special case, able of these kind of problems, while we should all keep using Object.statics() function that works internally, rather than on property name level.
So now you know ;)