Web Reflection

ES6 Harmony Collections Fast Polyfill

2012-01-18T01:10:00.003+01:00

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

On EventEmitter In node.js

2012-01-16T17:51:00.010+01:00

Today I had a whole node.js session and I have spent a bit of time looking at current EventEmitter implementation.
I have twitted already that it sucks as it is, and while it's really trivial to implement the same for any browser, I believe many mistakes have been made about the API. Here the list:

on() is a shortcut for addListener but there is no off() as removeListener's shortcut (inconsistent)
add/removeListener is not DOM friendly, we cannot reuse an EventEmitter in the browser without double checking if those methods exist
removeAllListeners() accepts no arguments and cleans up the whole emitter but there is no way to retrieve all listeners via listeners() passing no arguments (again, inconsistent)
there's no possibility to use handleEvent property, as already defined in the EventListener, once again objects are not reusable between client and server
no duplicated checks for both addListener and removeListener, this is totally inconsistent against DOM EventTarget plus I found it kinda hilarious since there is also a max number of listeners allowed defined via setMaxListeners method ... if we add same listener twice, it's fired twice ... a non-sense for those coming from the web. We also need to removeListener twice or more 'cause we have no idea if same listeners has been added by mistake twice so ... it's just screwed up, removing a specific listener may be not enough and there is no easy way to check if the listener has been removed or not
there is no interface to define events plus the single argument is not a DOM Event like, not even an object with data property and at least a type that points to the event name ... once again, not possible to reuse anything on DOM world

Why All Of This Is Bad

node.js is bringing a lot of non JavaScripters and non browser friendly JS developers into its community and this is the good part. What is absolutely bad is that if node.js won't be minimally aligned with the rest of the code in the browsers out there our life as "one language everywhere" will become harder than ever.
I have personally created wru which runs in all browsers and many server side JS environments but what I would like to avoid is to write twice any sort of test because of weirdly implemented APIs.
If it's about shortcutting, as example, on() and off() are more than welcome but why on earth the long version should be addListener rather than addEventListener?
Why events passed as objects since ever in client JS should be passed as string with optional extra data as second argument?
Where are defaults control over events fired across more listeners?
Why on earth handleEvent is not supported and a listener can be only a function which most likely will require a bind to something else?
Why is it possible to erase all listeners without even knowing "who set them where" but it's not possible to retrieve all of them so that at least we could act accordingly with the event name following some rule rather than "just remove them all" ?

I hope somebody will agree with me, considering flakey points I have already described and changing or improving ASAP this EventEmitter API ... it would be sooooooo coooool to be aligned in both worlds for at least the most used pattern/procedure ever in JS world, don't you say? Thanks for your attention.

Y U NO use libraries and add stuff

2012-01-15T16:40:00.006+01:00

This is an early introduction to a project I have been thinking about for a while.
The project is already usable in github but the documentation is lacking all over the place so please be patient and I'll add everything necessary to understand and use yuno.

Zero Stress Namespace And Dependencies Resolver

Let's face the reality: today there is still no standard way to include dependencies in a script.
If we are using a generic JS loader, the aim is to simply download files and eventually wait for one or more dependency in order to be able to use everything we need.
The require logic introduced via node.js does not scale in the browser due synchronous nature of the method itself plus the sandbox not that easy to emulate in a browser environment.
The AMD concept is kinda OKish but once we load after dependencies, there is no way to implement a new one within the callback unless we are not exporting.
I find AMD approach surely the most convenient but still not the best one:

we cannot implement a provide like procedure, whenever this could be handy or not
it's not clear within the module code itself, what we are exporting exactly

Specially the last point means that AMD does not scale properly with already combined code because AMD relies in the module/folder structure itself ... so, cannot we do anything better than what we have so far?

The yuno Concept

Directly out of a well known meme, yuno logic is quite straightforward:

automagically resolved path, you point once to yuno.js file in your page and you are ready to go
compatible with already combined files (smart builder coming soon)
yuno.use() semantic method to define dependencies, if necessary
yuno.use().and() resolved callback to receive modules AMD style once everything has been loaded
yuno.add() standard ES5 way to define new namespaces, objects, properties, or constructors ( so no extra note in the documentation is needed )
cross referenced dependencies automagically resolved: if two different scripts needs same library, this will be loaded once for both
external url compatible, because you may want to include a file from some known CDN rather than put all scripts in your own host ( speed up common libraries download across different libraries that depend on same core, e.g/ jQuery )
modules, namespaces, or global objects, cannot be reassigned twice, which means if we are adding twice same thing we are doing it wrong, but if we are not aware of other script that added same thing before we have a notification
something else I may decide to add after this post

Here some example:


// define a jQuery plugin
yuno.use(
  "jQuery",
  "extraStuff"
).and(function (jQuery, extraStuff) {
  yuno.add(jQuery.fn, "myPlugin", {value:function () {
    // your amazing code here
  }});
  // we may opt for just this line
  jQuery.fn.myPlugin = function () {};
  // in order to export our plugin
  // however, the purpose of yuno is to have
  // a common recognizable way to understand
  // what the module is about
  // plus the "add" method is safer
});

Let's imagine that extraStuff contains similar code:


// define extraStuff
yuno.use(
  "jQuery"
).and(function (jQuery) {
  yuno.add(jQuery.fn, "extraStuff", {value:function () {
    // your amazing code here
  }});
});

Both plugin and extraStuff needs jQuery to be executed ... will jQuery be loaded twice? Nope, it's simply part of a queue of modules that needs to be resolved.
As soon as it's loaded/added once, every module that depends on jQuery will be notified so that if the list of dependencies is fully loaded, the callback passed to and will be executed.

Y U NO Add

Modules are only one part of the proposal since we may define a script where no external dependency is needed.


// note: no external dependency, just add
yuno.add(this, "MyFreakingCoolConstructor", {value:
  function MyFreakingCoolConstructor() {
    // freaking cool stuff here
  }
});
// this points to the global object so that ...
MyFreakingCoolConstructor.prototype.doStuff = function () {
  // freaking cool method
};

The yuno.add method reflects Object.defineProperty which means for ES5 compatible browsers getters, setters, and values, are all accepted and flagged as not enumerable, not writable, and not configurable by default.
Of course we can re-define this behavior but most likely this is what we need/want as default in any case ... isn't it?
For those browsers not there yet, the Object.defineProperty method is partially shimmed where __defineGetter/Setter__ or simply the value property will be used instead.
Bear in mind this shim may change accordingly with real needs but so far all mobile browsers should work as expected plus all Desktop browsers except IE less than 9 ... not so common targets for modern web sites.
Last, but not least, yuno logic does not necessarily need the add call so feel free to simply define your global object or your namespace the way you want.
However, as I have said before, the add method is a simple call able to make things more robust, to speedup and ensure notifications, and to use a standard, recognizable pattern, to define our own objects/functions being sure nobody did before thanks to defaults descriptor behavior which is not writable and not configurable indeed.

To DOs

This is just an initial idea of what the yuno object is able to do but few things are in my mind. On top of the list we have the possibility to shortener CDN calls via prefixes such "cdn:jQuery", as example, in order to use most common CDNs to load widely shared libraries.
Last, but not least, the reason I am writing this is because I am personally not that happy with any solution we have out there so if you are willing to contribute, please just leave a comment, thanks.

Introducing ObjectHandler

2012-01-10T00:29:00.004+01:00

since the discussion about a better Function#bind will probably never end, and since a must have dependency would be the ES6 WeakMap which is in any existent shim leak prone due lack of control via ES5+, I have proposed another way to solve the problem.

ObjectHandler IDL Like


/**
 *  interface ObjectHandler implements EventListener {
 *      void                handleEvent(in Event evt);
 *      void                remitEvent(in Event evt);
 *      attribute   Object  events;
 *  };
 *
 *  @link   http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-EventListener
 */
var ObjectHandler = {
  handleEvent: function handleEvent(e) {
    var
      events = this.events,
      type = e.type
    ;
    if (events.hasOwnProperty(type)) {
      events[type].call(this, e);
    }
  },
  // it could be called removeEvent too, as you wish
  remitEvent: function cancelEvent(e) {
    e.currentTarget.removeEventListener(
      e.type, this, e.eventPhase === e.CAPTURING_PHASE
    );
  }
};

Above object is an Abstract implementation. In JavaScript we can borrow methods so whatever "class" would like to implement above behavior should extend the object or borrow those two methods and specify an events property.

Examples

Let's say we have a UI Class which aim is to react to certain events ... let's call it button:


function UIButton(parentNode) {
  // add the node
  this.el = parentNode.appendChild(
    parentNode.ownerDocument.createElement("button")
  );
  // add quickly events to the node
  for (var key in this.events) {
    // add the listener ... 
    // NOTE: nothing to bind, no duplicated entries either
    this.el.addEventListener(key, this, false);
  }
}

// extends the class
Object.defineProperties(
  UIButton.prototype,
  {
    // implements ObjectHandler
    handleEvent: {value: ObjectHandler.handleEvent},
    remitEvent: {value: ObjectHandler.remitEvent},
    events: {value: {
      // only once thanks to remitEvent
      click: function (evt) {
        alert("only once");
        this.remitEvent(evt);
      },
      // some decoration on actions
      mousedown: function (evt) {
        this.el.style.border = "1px solid black";
      },
      mouseup: function (evt) {
        this.el.style.border = null;
      },
      // recicle mouseup behavior
      mouseout: function (evt) {
        this.events.mouseup.call(this, evt);
      }
    }}
  }
);

// example on window load
this.onload = function () {
  new UIButton(document.body);
};

Got it? Events property is simply an object shared through the prototype with properties name that are exactly the equivalent of DOM events name ... easy!

Pros

memory safe, nothing to bind, trap as bound, and stuff like this ... all instances will share same logic and bind is not even needed, aka: problem solved
events are defined in a single place, easy to find, maintain, extend
events are recycled, as it was as example for mouseout, though the instance
most UI frameworks need the instance rather than the DOM node, to behave accordingly
ObjectHandler can be used same way for "ObjectTarget", those listeners/able JS implementations, in order to uniform an event driven approach
no risk to bind twice, no risk to remove the wrong callback, bound or not, it's the instance that makes the deal, not inline functions so it's less error prone
performances in therms of both memory footprint and operation per each instance ... once again, no need to bind all methods to the instance itself ... what is in events is basically bound automatically through a single entry point, defined in ObjectHandler, for every single use case

Cons

... no idea, I cannot find any and I just like this solution over the Function#bind improvements since it's both cross platform, whenever addEventListener is present, but it can be recycled for any other no DOM use case as long as the event will have a currentTarget property that points to the current instance ( I will write an example/proposal soon ... OK? )

As Summary

The main problem with proposal is adoptions and I would like to know UI Framework users feedbacks. Ideally this way to handle events could become a de facto standard dropping the redundant and massive usage of Function#bind for cases where the focus should be for the instance and not for the callback.

Improving Function.prototype.bind

2012-01-04T23:09:00.014+01:00

There are a couple of things I have never liked that much about Function#bind and this post is about proposing a pattern hopefully better than common one.

At The End Of The Function

A common argument about parentheses around inline invoked functions is that developers can easily recognize them.


// considered ambiguous
var someThing = function () {
  return {};
}();

// considered not ambiguous
var someThing = (function () { // note the parenthesis
  return {};
}()); // note the parenthesis

// exact same behavior of latest one
// but considered slightly ambiguous
var someThing = (function () { // note the parenthesis
  return {};
})(); // note the parenthesis

The parentheses version apparently wins but, specially when no assignment is needed, I believe these are even less ambiguous:


-function(){
  alert("OK");
}();

+function(){
  alert("OK");
}();

!function(){
  alert("OK");
}();

Of course if there is an operator that function will be executed, why on earth anyone would do that otherwise?
Anyway, the problem with all of these human friendly syntax pattern recognition strategies, is that the context of the function, or the whole code behavior, could be polluted/changed via bind or call or apply so we need in any case to scroll 'till the end to better understand what is going on inside the function and what is returned, exactly.


// ES3 example
var something = (function(){
   // this could be global object or something else
   return this.doSomeStuff();
}.bind(unexpectedObject)); // or call for other cases

// ES5
var something = (function(){"use strict";
   // if there is a this reference
   // we need to reach the end to understand
   // what is it
   return this.doSomeStuff();
}.bind(unexpectedObject));

The summary is that bind, used inline, is more like a yoda condition rather than a developer friendly helper so the first point is that bind, as it is, forces the developer to always check the end of the function to know if this has been executed inline or it has been bound to a different context, as well as yoda conditions forces the developer to read "upside down" a statement.
Last, but not least, of course if it's just about bind, parentheses are not helping at all ... still scroll 'till the end


// perfectly valid, not even executed
// but still important to know
// what will be the context for future calls
var something = function(){
   return this.doSomeStuff();
}.bind(unexpectedObject);

Team Speaking

Ok, agreed, a function bigger than 10 lines is not that good and should be split and blah blah blah ... point is that sometimes function have to be big since these provide us a way to create private variables and methods ... ok?
Also if that was "the good part", I mean just putting parentheses around, there is some conflict with the fact that functions should not be that long ... I mean, how can we mistake whatever happened in 10 lines?
The truly good part could be done by developers, specially those that work in a team.
The first good rule is to write a bloody single line comment at the very first line, this would just solve everything:


var something = function () {
  //! executed inline, returns object

  ... the rest of the code ...
}();

var somethingElse = function () {
  //! bound to variable obj

  ... the rest of the code ...
}.bind(obj);

var somethingCrazy = function () {
  //! bound to obj + executed inline

  .. the rest of the code ...
}.bind(obj)();

-function(){
  // bound to obj
}.bind(obj)();

Got it? Nobody would ever complain about these little helps ... isn't it? But since we are all lazy devs, the second helper is function declaration rather than function expression.


function impossibruToConfuse(){}

var something = impossibruToConfuse.bind(obj);
var something = impossibruToConfuse();
var something = impossibruToConfuse.call(obj);

With a single line to read I believe the problem is solved ... isn't it? Still ways to improve.

Unable To Retrieve Same Bound Function

The second most annoying thing ever, something that leads inevitably to uncomfortable patterns, is the inability to retrieve an already bound function through the same object.
In my humble opinion, was a freaking design mistake indeed to create a new bound object per each bind call since I believe nobody in this world ever used this "feature".


function task(){}

// Y U NO THE SAME !!!
task.bind(window) === task.bind(window);
// false ....

If the function is the same it means it has same context, inner and outer scope of the other function bound to the same object.
If we bind twice the same object we are doing it wrong 'cause most likely we never meant/need two different bound callbacks/objects for that task ... isn't it?

An Error Prone Logic

The most basic fail of this logic is about listeners, both DOM listeners or self implemented listeners, extremely common in an always more asynchronous driven language as JavaScript is.


generic.addEventListener("stuff", stuff.bind(obj), false);

// how many times have you seen this later on?
generic.removeEventListener("stuff", stuff.bind(obj), false);

Above example won't work as expected ... of course it won't work as expected ... developers expect the same function/object, instead they have a new one.
This approach forces developers to store temporarily the bloody bound function to some private, global, variable or property.


obj._boundStuff = stuff.bind(obj);
generic.addEventListener("stuff", obj._boundStuff, false);

// ... later on ...
if (obj._boundStuff) {
  generic.removeEventListener("stuff", obj._boundStuff, false);
}

Remember how lazy we are so that parentheses became one of the good parts of JavaScript since a line of comment was too boring? Now look again at latest example and think how many times you have done something similar ...

A Clever Object.prototype.boundTo

With ES5 we are so lucky to be able to pollute global constructors without influencing for/in and as long as our implementation is not obtrusive and, most important, makes sense.
I came up with this proposal in order to solve at least latest problems described before: a lazy boundTo method


!function (Object) {

  // (C) WebReflection - Mit Style License

  var // private scope shortcuts
    BOUND_TO = "boundTo", // or maybe "asContextOf" ?
    defineProperty = Object.defineProperty,
    bind = defineProperty.bind || function (self) {
      // simple partial shim for "not there yet" ES5 browsers
      var callback = this;
      return function bound() {
        return callback.apply(self, arguments);
      };
    }
  ;

  defineProperty(
    Object.prototype,
    BOUND_TO, {
      value: function (callback, remove) {
        // only the very first time
        // two private stacks are created
        // and related to the current object
        var
          cbStack = [],
          boundStack = [],
          self = this
        ;
        // overwrite the inherited BOUND_TO method
        // with the one we actually need
        defineProperty(
          self,
          BOUND_TO, {
            value: function boundTo(callback, remove) {
              var
                i = cbStack.indexOf(callback),
                callback = i < 0 ?
                  boundStack[
                    i = cbStack.push(callback) - 1
                  ] = bind.call(callback, self)
                  :
                  boundStack[i]
              ;
              // falsy values accepted
              // except null or undefined
              // so it's true by default
              if (remove == false) {
                cbStack.splice(i, 1);
                boundStack.splice(i, 1);
              }
              // returns bound callback in any case
              // handy to remove listeners and clean stacks
              // in one single operation
              return callback;
            }
          }
        );
        // only the first time, invoe the overwritten method
        // use directly latter one every other time
        return self[BOUND_TO](callback, remove);
      }
    }
  );
}(Object);

How above snippet is supposed to be used? Here a basic example:


generic.addEventListener("stuff", obj.boundTo(stuff), false);

// ... later on ...
generic.removeEventListener("stuff", obj.boundTo(stuff, 0), false);

// bear in mind that ...
obj.boundTo(stuff) === obj.boundTo(stuff);
// always ... unless we release explicitly the bound function/object
obj.boundTo(stuff, false) !== obj.boundTo(stuff);
// since once removed, the new obj.boundTo call will create a new one

Pros

No need to check, no need to store the bound version, memory leaks safe, no need to do anything extra except calling the method through, and this is needed, the same function.
The semantic is straight forward and rather than a yoda condition we have a clear operation that means: return the function created to bind this object as context.
Last, but not least, even if the function was not bound, everything should work as expected, as long as the removeListener generic method has been implemented properly ( checking if the callback/object was attached already )

Cons

Not really, but the function has to be the same. It must be said that two apparently identical functions could be just a copy and paste in two completely different outer scopes. This means that there is no bullet proof way to understand if a function written twice is similar to another one since it is not possible to understand surrounding scopes and it would be silly to do this even on the JS engine level. I am talking about another, unfortunately, common mistake:


// wrong examples ... does not work as expected

generic.addListener("whatever", function () {
  return this.whatever;
}.bind(object), false);

// followed by ...
generic.removeListener("whatever", function () {
  return this.whatever;
}.bind(object), false);

// or in this proposal case ...

generic.addListener("whatever", object.boundTo(function () {
  return this.whatever;
}), false);

// followed by ...
generic.removeListener("whatever", object.boundTo(function () {
  return this.whatever;
}), false);

// ... but this is not how JavaScript works ...

Memory speaking, the very first time we use this strategy we create two extra arrays able to speed up operations through indexed function and and bound version per each object. This is inevitable in any case and it's almost exactly the same we do when we address once the bound function.
Once the object has been Garbage Collected, related private arrays will have a reference count equal to zero so the memory should clean up automatically without problems and including all functions bound to that object.

As explained in the example, it is possible in any case to release explicitly bound functions so we can feel like the memory usage is under control.

Why No Arguments

The combination of arguments could be such big number that this technique won't be interesting anymore, specially regarding performances.
It does not really make sense to over complicate such basic, most needed, scenario but if you think this is the biggest impediment, then the name should simply be asContextOf so that no ambiguity would be shared with bind native signature.

Update - Preserving Private Methods

Another reason to chose my proposal is the ability to bind proper private methods without using the current instance to store the bound method anywhere ... follow the es-discuss ML to know more but here the stupid, basic, proof of concept:


// stupid useless example ... just as concept
var Counter = (function () {
  // private
  function increase() {
    this.clicks++;
  }

  function Counter() {
    // none out there should be able to retrieve the bound function
    document.addEventListener("click", this.boundTo(increase), false);
  };
  Counter.prototype.clicks = 0;
  Counter.prototype.destroy = function () {
    // so that only this class scope can control things and nobody else
    document.removeEventListener("click", this.boundTo(increase), false);
  };
  return Counter;
}());

As Summary

I am pretty sure this simple lazy created proposal would be ideal for many frameworks and projects but if I am missing something or if you have any improvement to suggest, I will be more than happy to listen to you.
Enjoy simplicity over semantic, this is yet another KISS and YAGNI proposal from this blog.

Learning From 2011

2011-12-30T14:26:00.011+01:00

It's time to summarize at least few mistakes or epic fails of the year, hoping the next one will try to follow a better direction.
I won't mention anything related to war, politic, Berlusconi, or fashion related stuff, other more prepared than me will do via pictures or posts, all I gonna talk about is the field I am concerned about: web and mobile web oriented technologies and facts.
The order is completely random, so grab a mug of coffee, take few minutes, and read 'till the end, forgetting for once tl;dr philosophy ;)

The Partially (Multi)? Touch Device Case

This has been the most annoying fact of the year: vendors going out with freaking powerful mobile devices with touch or multi touch capable screen/hardware not exposed through the browser and only available for native apps.
We are not talking about potentially "dangerous" technologies as WebGL could be, we are talking about the most basic thing able to break 140% the user experience.
If a user plays a native game or use a native map, as classic Map application could be, she will naturally use at least a finger, or more, to interact with the screen. Interaction does not mean scroll the page and nothing else, interaction means full control of what the user is doing with the screen.
As soon as the user surf the web, the browser pretends to know what the user would like to do on the screen without giving web developers any control over those actions.
The inconsistent behavior comes when the viewport meta tag is used to block, as example, the zooming in and out gesture because the whole layout has been developed for a static viewport that should not change.
In this case, only few vendors ( Apple ) or browsers ( Opera Mobile ) got it right, any other vendor with a WebKit based browser got it wrong. Here a few examples:

IE9 Mobile Epic Fail

IE9 is a great browser, compared with all other previous version, and it's freaking fast. This is true for both desktop and mobile phones but in latter case, IE9 is an epic fail when it comes to User Interaction.
There is no bloody way to intercept a user moving a finger on the screen, and standard W3C Touch Events are not supported.
You may think: oh well, I gonna use mouse events then ... and you are wrong, these are not fired until the user release her finger so ... forget about it, no "scroll" hacks will work as expected there ... also why on earth when everybody else is disabling JS actions during scrolling, IE9 Mobile fires it all the time?

Sad part is that Microsoft is investing a lot into HTML5, but if the most basic thing as Touch Events are, is not there, no reason to have the fastest mobile Canvas implementation because no game will be interactive, and no web app can be created as desired.
Hopefully IE10 will simply follow W3C exposing both Touch and TouchList in a meaningful way ... please don't screw this or few developers will even consider to write software for this browser, thanks.

webOS 2 Sad Fail

I have upgraded few minutes ago my Pre 2 to webOS 2.4.4 ... and I was expecting more from this update. My Palm Pre 2 exposes correctly multi touches through the system, but the web browser does not expose them and this is freaking annoying. Same IE9 behavior and at least at the end of 2011 I was expecting such simple browser update able to bring my Palm to the next level: User Interaction Through The Web ... FAIL.
The good old native Google Maps application for webOS 2.0.X is gone. This app was working like a charm and it was exposing multi touches through the multi touches capable screen ... now I have a slower and flicking version of Bing maps that is not even able to render pinch/spread without loosing the position on the screen since everything gets stuck truly easily.
Now, I have no idea why this happened and why somebody wasted time to do this ... it's just worse than before and the browser still does not expose multi touches ... come on guys, this phone did not deserve to die like this.

Ultra Powerful ... "broken" Androids

It does not matter if we have 16 cores in our expensive smart phone when developers life is made harder for no reason ... with most recent Android phones we could create any sort of web application but here again, no-f*cking-body exposes TouchList via browser except few tablets out there.
OK, still better than nothing, as it is for IE9 Mobile, FF Mobile ( I will come back later to this one ), or webOS browser, but how comes 3rd parties browsers such Opera Mobile are able to bring TouchList and expose multi touches through the multi touches capable screen and native browsers are all lacking of this basic feature?
You don't even want to know how we managed to bring multiple touches in android devices, all you need to know is that is basically a hack and it requires a native application wrapper and this is, in my opinion, ridiculous!
Nowadays, all users with a friend that uses an iPhone, will consider the multi touch web app broken in its android: come on, I use two fingers in other things why I cannot do the same in this web site/application?

FireFox Mobile Fail

I don't know where to start with this browser ... I mean, guys, this is not Desktop, this is a touch screen. If you decide that the user cannot even scroll a paragraph horizontally because your freaking cool settings or bookmark view has to show up instead, you should create your own device and make the phone 3 times larger: 1/3 for the actual screen, 2/3 for your things nobody expect to appear during navigation.
About touches, at least most recent version implements touch events but performances are still too bad compared with native browsers or Opera Mobile, and the fact settings or bookmarks show up when we touch close to the edge of the screen, plus the fact AFAIK there is no way to avoid this, make this browser not suitable for full screen web games/apps based on canvas: slow and unusable ... please fix/drop this!

UpdateIt must be said that latest FF mobile brings better canvas performances and apparently it exposes a not so fast WebGL. I dd not know this the moment I wrote this post so FF Mobile is definitively already going to the right direction.

iOS Gesture Events VS Others

These are not standard and nobody should care. The moment we can rely in TouchList and multi touches exposes through this interface, the problem is solved 'cause we can implement by our self any gesture we want.
No need to wait 'till on spread/pinch are implemted and documented, just please give us TouchList and take your time after to do things properly. TouchList has been already defined ... that's all we need so far, thanks!

The Curious Case of Opera Mobile

Opera did weird things this year ... it switched from partial ES3 support to full ES 5.1 support ... what the hell guys, congratulations! Still there is no way to understand numbers of this browser (again: Opera Mobile, NOT Mini) .
Today, I can say Opera Mobile is one of the fastest and most capable browsers I have been dealing with but the lack of many CSS3 features have been the arrow in the knee together with the fact Opera could have been the Phone Gap Like software of the year while they focused on ... I guess something else.
Don't give up guys, Opera Mobile is amazing and people may chose to download it as soon as most common HTML5/CSS3 things are working as expected and also you may expose freaking cool stuff without necessarily follow W3C, giving web developers the possibility to distribute applications directly through your browser as native wrapper ( and fallback to Webkit for iOS ) .
Opera has always been pioneer, and it's time to be pioneer on mobile too because on desktop I am afraid to tell you it's hard to compete. Firefox, Chrome, and Webkit Nightly, are really advanced and I believe bigger teams, what we are missing is a not so fragmented browser that works as expected in as many devices as possible because what I have seen with all webkit versions I have worked with this year was painful, hard, inconsistent, and WTF development oriented.
Last, but not least, If there is not SQL Database, don't put a native useless Database function on the global scope or shims are screwed and if you don't expose SQL Database, at least expose Indexed DB or shims are screwed.

Android Whatever

While many developers think that Android is an Operating System, I am every day more convinced that Android is a Super Kernel that has almost nothing to do with the Operating System itself.
There are too many damn versions of Android, and even same major versions do not guarantee anything.
Every device must be tested a part because every device, with every vendor specific gotcha, software, or extra cool stuff, may behave differently. Funny enough, while I was thinking this is true for the webkit based browser only, there are many exceptions device specific that do not work as expected even natively ... oh, come on, don't call it OS!
If we think about Windows, almost every piece of hardware is supported. Then we have the classic crapware every single vendor puts by default in its own distributed piece of hardware ... fair enough, at least most basic things gonna work as expected in all of them ... right?
With Android, the most basic free version has almost nothing. Cyanogenmod is the basic example, once you install it, you gonna scream for apps you expect to be there and it comes up you need the specific Gapp package ( Google Applications ).
Same thing with Kindle Fire, based on the very basic version of Android so common apps available for other tablets may not work or may not be there.
This means we can trust only a truly basic set of functionalities that are hopefully working in all distributions out there but you know, this is IT, expectations are rarely matching reality.
The performances tuning per each device is another problem, as problematic are performances of the same app through the browser compared with those through the native layer.
If you wrap your single touch full page canvas game into phone Gap, as example, you will realize how freaking fast it is compared with the same exact code through the browser ... why that? Security layer is off plus bound stuff is limited compared with the whole browser application ... fair enough? No it's not. The moment I realize it is possible to force HW accelerated rendering via native wrapper but it's not possible to do the same via browser I start screaming ... let us develop through the web or stop telling us you support standards because if these are limited intentionally then those not supported are developers themselves.

Mobile Web Apps Too Limited

I really hope I won't need to write a similar post at the end of 2012 but I am not sure there will be many progresses here ...
W3C is slow, plus it may waste their/our time. Web SQL Database is an example, something I loved screwed by dependencies free purist.
I have talked about Web SQL many times and right now I don't care about this specific topic, all I care is about moving forward.
Time to agree and promote such interface to drop it after 2 years is not the way to go.
Time to replace such interface with another one limited, slower, and not widely adopted as IndexedDB is, still not the way to go.
We need a database, please put it there one ASAP and drop 50Mb per domain/tab limit.
No fools guys, if the logic behind the Web is that user must explicitly agree give the user full control.
If a web application requires more than 50Mb give the user the possibility to increase the database.
All native apps do not care about how much space is used, these simply informs the user through system settings how much stored data there is. Google Earth, as example, even maps, these are heavy memory applications that do not ask every 5 megabytes if more space can be allowed ... this was another epic fail.
Once the user accepts the fact this web application would like to use the storage, create a way to simplify the task able to verify how much data is being stored and stop asking!
From UX perspective is like accepting an explicit file upload/manipulation and while the file is being loaded into ram asking every 200Kb if the user would like to increase the memory allocation for that file ...

What If Every Web Page Asks For Space

Nothing, same is for "what if every native app takes 4 gigs of space" ... either space is available or it's not possible ... is that easy ... but again, with an easy to access indicator and a limit that goes far beyond 50Mb the problem should not exist. User can clean the cache, or enable more space but it must be easy, as easy should be for web apps developers to understand the available space because if the device is full already, the 50 Mb limits is pointless in any case plus there are ways to trigger memory consumption behind the scene and fill up gigs of disk space/SSD ... once again, this ask on demand every time is an epic fail, imho.
FYI, the behavior I am talking about is in iOS, where Android asks only once if the disk access is allowed, then it silently fails after we reach the 50Mb limit.

Native VS Web App

Every browser is based on a native web view or similar concept, which means every browser could expose anything. I would like to be able to record user voice via web, to decode it via audio tag, to create real time video chat, to replace all native applications and to forget Android, iOS, webOS, blackberry, Symbian, MeeGo, Windows, whatever SDK ... I want to leave the SDK power to much more complicated things and I would like to be able to do most basic things via browser, all those things that the user could do with native apps, performances a part.
The gap between native and web app should be performances and nothing else indeed ... right now is: all possible nasty access to everything on native side, things that few users are rarely aware of, and almost no access to any functionality through the browser.
No idea if Chrome OS solved this but if it did, I am pretty sure it did with in-house solution, same Windows 8 will do, and this is annoying at least until a jDevice library will come out able to make all these private API consistent across all platforms ... as summary, why Mobile Web App development has to be so hard is a complete mystery to me: is it about your own markets? Fine, then stop selling us your browser is promoting Standard Mobile Web development because this sounds, so far, like a big lie.

Patent Oriented Development

When I heard that Apple patented a slide to unlock the screen I did not feel like "they are so advanced" ... I rather felt like "is anyone trying to patent my finger" ?
I move horizontally my thumb since ever and nowadays I know there is a patent for that and this is bad.
A natural movement should never be patented ... the graphic used to guide the movement could eventually be a patent but the way I do things not.
I don't want a patent to hold a fork, I don't want a patent for the position I use to sleep in a mattress, whatever weird sofa, or a chair, I don't want to do unnatural movements to unlock a touch screen.
What the hell is going on here ... if I use my nose to unlock my old android device I don't have to pay the patent indirectly, right?
Is this what is patent about? Yes, it is.
Patents are about intellectual property of whatever but the problem is that patents are expensive, are not necessarily predictable, and all these patents are doing is to block future development on top of it, unless is not the same company.
Patents are a sort of creativity barrier because if a company invents a generic something, nobody will even try to improve that invention due basic patent behind the original.
Example, I use my right hand to hold the phone and when I am talking with someone I put my right thumb on the right side of the phone.
If there is a button there, it's annoying, while if I have to swipe from left to right ... well, it's still annoying.
Will I ever implement a swiping gesture from right to left to unlock the screen because usually the way I hold the phone is with my right finger on the right side and it's more convenient to me to swipe the other way round as it is convenient for all left hand users? Nope, I don't even want to remember that thing exist, I have to create something completely new being careful that what I am doing does not touch the other patent ... cool, uh?

Hardware Patents

Same concept could be applied for hardware ... was that thing perfect? Yes, I pay the patent. Was that thing not perfect? No, I have to create something new ... even if based on laser(disc), the reason we all waited so much for new standards after the CD.
This happened with Compact Discs, and it brought us DVD first and Blu Ray after. In the meanwhile, another standard better than CDs but a bit less capable than Blu Ray died ... fair enough, we have new hardware for all these technologies but how comes in the hardware field the patent problem is not so strong as it is for the Software one?
3D TV, all vendors are making one, as well as CD players, DVD players, and Blu Ray players ... nobody cares about patents here, at least not the way we all do when it comes to Software.
I don't have any answer for this but I believe patents should be re-evaluated in their meaning because in the fastest field ever, as technology/software is, something that last for 10 years is too much and price to pay is too much as well as too much is the time between the patent pending and the patent applied status.

ES6 Focus

I have talked about this as well ... it's about what's truly needed today, at least in the Mobile Web Development, and the JavaScript.Next focus, often completely abstract over not-so-needed topics as syntax sugar and boring classes.
iOS5 brought massive performances boost to all Apple devices but even having the fastest and complete browser out there, Safari Mobile cannot do miracles when it comes to performances.
The side effect of not having performances oriented techniques in JavaScript and DOM world is that average web developers are not able to create cool stuff without draining the battery or being slightly fast only with most recent mobile devices.
The need for performances in this Mobile era should be priority number one for W3C and a possible ES 5.2 milestone, after that take even 5 years to improve syntax with all sugar you want, if necessary, at least we can push Mobile Web Development to its limit in the meanwhile while many new proposals won't bring anything interesting, as far as I can read, performances speaking.
We can deal with the fact protected and private variables are absent or different in JS, what we cannot deal with anymore is that a proper and fast 3D API is not available, that Parallels are not available, that WebWorkers are useless when it comes to move data back and forward, that postMessage requires a window.open which require a click which is too slow but cannot be faked ontouchend or window.open won't work anymore because not explicit ... that IndexedDB does not provide native way to join data and speed up queries, that DOM manipulation is slow, that we don't control repaints and/or reflows, that binary Arrays are still slow, that Structs like classes/objects are missing, that CSS3 is bringing logic in the view with lack of control ... etc etc ...
I don't care if Proxy are in the browser, if these are 2X slower than good old JS on mobile, you know what I mean? We need more performances now and more APIs finalized to have access to hardware layers only SDK can expose without granting any better usage than an experienced web developer.

WebGL Partial Fail

First of all this is not yet a standard, regardless the effort of the kronos group, which means browsers like Internet Explorer will never adopt this ... fair enough if we can shim through Silverlight but here comes the second point: WebGL, as well as Silverlight, are not available for mobile.
Apple exposed it for Adds only, where adds are most likely those responsible for bad Web performances, generally speaking, due massive usage of Flash or arguable usage of automations to bring canvas Adds able to slow down all netbooks and tables out there .... congratulations, I'll never get this choices ... WebGL not for developers but for designers of adds only ... can I say brilliant?
Too few mobile devices are exposing WebGL if not none of them while basically every mobile device has a GPU compatible with Open GL 2.0 ES
Still experimental, true, and already available mainly for Chrome browser where Webkit, as well as Firefox, could do the same or truly similar. The direction WebGL is taking is not good at all and I can't wait to see cool demonstrations able to run with all WebGL capable browsers ... so far, not many of them ... and this is bad.
Sony enabled WebGL in its latest version of Android, still about fragmentation, so I am expecting at least every other vendor to bring WebGL in our current devices already capable ... it was a massive fail to drop it for the whole 2011, cool things may have been experimented already on devices plus typed Arrays could have been used more even for non WebGL related tasks.

CSS3 Partial Fail

As mentioned before, CSS3 are becoming the most messed part of the whole Web stack, mobile and/or desktop. Examples with counters to change dynamically text via :after selector ... is it just me? I mean ... dafuq is that?
Internet Explorer dropped the most misunderstood proprietary feature as expression was and webkit is introducing any sort of unmanageable logic inside CSS3? ... counters? webkitTransitionEnd withou webkitTransitionStart? No way to trigger properly transitions if not without asynchronous rendering? Lots of hacks to make them work cross platform with control through JS for something written in CSS?
CSS3 is bringing MVC in Web world without the C and if we would like to create robust behaviors/interactions/applications that make sense, programming speaking, we should forget the case where the user has no JavaScript because CSS3 is becoming indirectly strongly dependent on JavaScript for many reasons ... why not bring standard DOM method to control states via JS, rather than control partially what is supposed to happen via CSS3 only? I don't get it, I have seen cool stuff, but I have not seen cool stuff adopted cross browser and I am not seeing cool stuff easy to handle via JS and/or vice-versa.
CSS3 needs notification into the JS world or we gonna have Photoshop like power without tools to control what we are doing.

As Summary

I have more things to say, and more I forgot but I thought a rant on 2011 was needed at least to check, in one year, what happened, what improved, and what did not change at all.
I hope all people that are doing hard work on daily basis to promote a better web won't take anything I wrote personal and will simply consider the point of view of somebody that works with all these things on daily basis so ... it's my personal feedback, on what I think should change ASAP and specially for mobile web development.

Happy New Year Everybody

Coercion Performances

2011-12-21T18:31:00.005+01:00

There are cases where JS coercion may be wanted/needed/necessary, at least logically speaking.

A classic case is a list of primitives, e.g. strings, or numbers, and a check we would like to perform without creating a new function each time.


// recycled function
function alreadyThere(value) {
  // wanted coercion, no cast needed
  return value == this;
  // shitty code, logically speaking
  // one cast per iteration
  return value === "" + this;
}

var listOfNames = ["Me", "You", "Others"];

// the pointless check
listOfNames.some(
  // the recycled callback
  alreadyThere,
  // the *passed as object* this
  "You"
); // will be true

Now, for above specific case anyone would use an indexOf but this is not the point.
The point is that in some case we may want to do more complicated stuff and compare the result with this


// know if word was already in the dictionary
function alreadyThere(value) {
  return value.toLowerCase() == this;
}

// convert the check once per iteration
listOfNames.some(
  alreadyThere,
  "yoU".toLowerCase()
); // still true

It's About Optimizations

The whole point is to try to perform as less runtime computations as possible.
Following this logic, we may decide to lower-case all items in the list once, and never again, but unfortunately this will require duplicated amount of RAM used per each collection.
The String#toLowerCase() is fast enough for a not so frequent check so why bother the RAM?
The optimization is also to avoid this.toLowerCase() per each entry of the dictionary.
The concept here is again simple, avoid duplicated entries in a generic list of chars, but things may be similar with numbers.

Performances

I have created a specific test able to understand performances gap between coercion and cast per iteration.
Surprising Google Chrome seems to be able to optimize in core once per iteration the cast, resulting almost twice as fast as competitors.
Specially on mobile, the in core coercion seems to be faster, sometimes almost twice as fast as the cast per iteration is.

JIT Oriented Development ?

I believe we should code logically, rather than trust JIT optimization. What I mean is that performances test are always welcome but we all know that better logic and algorithms are always winning in therms of performances and maintainability. In this specific case, specially where mobiles suffer the most, I would never suggest to do the cast per iteration: first of all because only one engine seems to be able to optimize such cast, but we don't know if a more complex object/scenario would perform that well, secondly because if I see a cast per each loop iteration I start smelling laziness all over the place ... the boxing/unboxing has always been a well known problem performances speaking, so how can a developer approve a logic similar to (String)alwaysSameObject per each iteration?

As Summary

Tools such JSLint should just do their business in these cases ... coercion is wanted/needed/logical, and unless every browser will show such gap in common tasks against coercion, I will rarely promote a cast per iteration ... and you know what? I believe that gap in Chrome, is a missed optimization in Chrome itself.

Please, Give Us Back noSuchMethod !

2011-12-13T21:13:00.021+01:00

For those who don't know what __noSuchMethod__ is here the quick summary: it was a bloody handy non-standard method able to provide a fallback whenever we invoked an object method that did not exist.


var o = {};
o.__noSuchMethod__(function (name, args) {
    alert(name); // "iDoNotExist"
    alert([].slice.call(args)); // 1,2,3
});
o.iDoNotExist(1, 2, 3); // will produce above alerts

A Bit Of Background

Well, if you are patient enough, you may consider to read this never-ending post in Mozilla mailing list.
The reason that post is called Proxies: get+fn vs. invoke is because Proxy supposes to be the new way to go able to bring us much more power than we probably ever need ... but hey, this is welcome, while what is not welcome, is that Proxy may not be implemented first, which means browsers vendors should have waited to remove __noSuchMethod__ 'cause right now we may not have a pseudo equivalent, and second, but surely not less important, , Proxy does not provide the same functionality.

The Minified Theory Against The Practice

The main argument from @BrendanEich is that JavaScript has properties only so that o.fn() is the equivalent of o.fn.apply(o).
While this is true with any normal object, this is totally different with __noSuchMethod__.
The equivalent of __noSuchMethod__ for that operation, and behind the scene, is:

is there a property in o or its __proto__ called fn ?

yes, proceed as usual as if it was o.fn.call(o) and throw error if that property was not callable
no, is there a __noSuchMethod__ callback to burn instead of throwing an error due undefined property?

yes, perform the current operation: nsm_callback.apply(o, arguments)
no, throw an error since property was undefined and obviously not callable

Got it? The equivalent of o.fn() in an environment where __noSuchMethod__ was supported is potentially different from o.fn.apply(o) ... I am 100% sure Brendan knows this before and better than me and this is the reason I don't really get his strongest point.
Once again, o.fn() may be the equivalent of nsm_callback.apply(o, arguments) and not o.fn.apply(o).

The Inexistent Theory Against The Practice

If above "reason" was not enough, I have read even worst in the same thread. I am sorry guys, but sometimes you must be realistic and understand that if a developer does, as example, this:


// de-context fn from o and invoke it
(o.fn)();

// exact equivalent of
var fn = o.fn; // GETTER, no invokation
// and after ...
fn()
// this is a problem? we have same with missing bind then ...

rather than this:


// invoke fn through o as default context
o.fn();
// can we see the difference?

it means that developer has much bigger problems than __noSuchMethod__ inexistent ambiguity, that developer does not even know that __noSuchMethod__ exist ... come on!
Going on and on, another point is that get should be all we need to simulate the __noSuchMethod__ behavior through proxies ... but this is completely misleading!

A Getter IS A Getter

Is that trivial ... if we access a generic object property we are doing nothing different from invoking a getter with such object as property context.


o.whatever;
// look for "whatever" property name in o
// if found returns the "whatever" associated value


o.whatever.call
// nothing change, THIS IS NOT AN INVOKE
// look for "whatever" property name in o
// if found returns the "whatever" associated value
// since the value was a function, the call method is usable
// if whatever was not defined, the call method won't exist

Nobody should ever even consider to use property accessor and expect a __noSuchMethod__ behavior ... that property did not exist, what kind of method would you expect to look for?
call is a property of the Function.prototype so following the accessor/getter logic, nothing is ambiguous here.
Accordingly, lattest example is simply an inexistent mistake that hopefully no developer would ever do ... but you know, shit happens, then we learn, then hopefully we don't repeat same shit.

Other Programming Languages

When it comes to PHP, they perfectly managed to make the behavior not ambiguous through the __call magic keyword in classes definition but no, we decided that in JavaScript we cannot even think to put an invoke to make the life easier and completely NOT ambiguous for all of us ... do we?
I still cannot understand where and what is the ambiguous part if we have an explicit invoke declaration ... maybe something a bit harder to solve behind the scene for these poor JS engines? It could be ... should we all limit JS because of this? I don't think so.

Think About Libraries APIs Migrations

I give you the most basic example, the most used JS library with a fake getter and setter behavior: jQuery.


// jQuery simulation of getters and setters behaviors

// the getter
$("body").html(); // return string with content

// the setter
$("body").html("whatever
");
// set the string with content

If you want, specially for chainability reasons through the simulated setter, the fact html is a method is convenient for the library but this library is stuck forever behind these two methods.
jQuery, at current ECMAScript status, will never be able to switch gradually to real getters and setters ... why that? A simple example:


$("body").html; // returns the string in jQuery 3000

$("body").html(); // shows a "deprecated warning"
// ... and returns the "html" getter

// implementation example
function setInnerHTML(node) {
  node.innerHTML = this;
}
Object.defineProperty($.fn, "html", {
  get: function () {
    return this[0].innerHTML;
  },
  set: function (html) {
    this.each(setInnerHTML, html);
  }
});

// the deprecation warning
$.fn.__noSuchMethod__(function (property, args) {
  if (property in this) {
    console.log("Warning: " + property + " is not a method anymore");
    if (args.length) {
      // invoke the setter
      this[property] = args[0];
      // preserve behavior
      return this;
    } else {
      // invoke the getter
      return this[property];
    }
  } else {
    throw "Y U NO READ DOCUMENTATION";
  }
});

That's it, we can migrate from two different APIs implementing getters and setters whenever we had a similar behavior and bringing gracefully users to the new usage ... no wa can't!

It Is Not About jQuery

I don't even use jQuery so don't get me wrong, this is not my battle here ... the point is that for another private project I am working on I would like to educate developers to use properties correctly but I understand developers may already got use to invoke methods as if it is normal, even when they are simply looking for a getter behavior.


var o = {
  whatever:"cool bro",
  __noSuchMethod__: function (property, args) {
    console.log("we got a bro-blem here, " +
      "don't invoke if you want a getter");
    return this[property];
  }
};

// so that 
o.whatever === o.whatever();

Secially last line of code is apparently impossible to reproduce with Proxies, those that suppose to be the new and best way to go, those that give us control on things rarely needed until now, those that made JS.Next group decide that __noSuchMethod__ was evil and it had to be abandoned.
I really hope that JS.Next will not be non-developer expectations behaviors driven because guys, somebody tries to do cool things with this cool language, and if the reason you drop something is because we are all morons, as example misunderstanding the difference of a referenced property through parenthesis ... oh well ... good luck kkfuture JavaScript ...

How To Solve This

Please put an invoke or even better an invokeProperty, preserving invoke for when the object itself is used as if it was callable, in the current Proxy specifications so that who knows what is doing, can keep doing it and who never even bothered with this stuff, won't be affected at all.
Thank you for listening.

Create a JS builder with node.js

2011-12-12T19:19:00.012+01:00

A very good and common practice with JS projects bigger than 100 lines of code is to split code in different files.
Benefits are clear:

smaller pieces of code to maintain
swappable portions for experiments and/or improvements or new features, as example including for a build magic2.js and get it, rather than change drastically magic.js and follow the repository logs
better organization of the code, and I'll come back on this in this post
possibility to distribute bigger closures, as example the jQuery approach
create ad hoc builds including or excluding portion of the library, specially suitable for specific version of the code that must be compatible with IE only

Solutions All Over The Place

There are really tons of solutions able to make the described build process easy to use and easy to go. As example, I have created my own one and I am using it with basically every project I am working with: the JavaScript Builder.
However, this builder requires a couple of extra technologies such Python and Java ... but aren't we using simply JavaScript?
So why not an easy to create guide on how to build your code via JS only?
This is what this post is about, and I hope you'll find useful.

How To Structure Your Project

If all files are in the same directory is not easy to find the right file immediately since these could be many. A good solution I came up with is folder related structure with both namespaces and private keywords paths.
Here an example on how I would structure this library ( and please ignore the library itself )


var myLib = (function (global, undefined) {"use strict";

  // private scope function
  function query(selector) {
    return document.querySelectorAll(selector);
  }

  function Wrapper(nodeList) {
    this.length = nodeList.length;
    this._list = nodeList;
  }

  // a prototype method of the Wrapper "class"
  Wrapper.prototype.item = function item(i) {
    return this._list[i];
  };

  // public static query method
  query.asWrapper = function (selector) {
    return new Wrapper(query(selector));
  };

  var // private scope variables
    document = global.document,
    slice = [].slice
  ;

  // the actual object/namespace
  return {
    query: query,
    internals: {
      Wrapper: Wrapper
    }
  };

}(this));

The code should be easy enough to understand. The object used as namespace for myLib has a couple of methods, few private variables and functions and something exposed through the internals namespace.
It does not matter what the library does or how good/badly is structured, what matters is that our folder structure should be smart enough to be able to scale with any sort of allowed JS pattern ... OK?

The Folder

Well, to start with, let's say our source code should be inside an src folder so we can add other folders for tests or builds beside in the same hierarchy.


dist
src
tests
builder.js

We'll see the builder.js later, in the meanwhile, let's have a look into the src folder:


dist
src
    intro.js
    outro.js
    var.js
    function
        Wrapper.js
        query.js
        Wrapper
            prototype
                item.js
        query
            asWrapper.js
tests
builder.js

The distinction will be much cleaner once you read above list through your editor or even your shell ... query and files are well distributed but bear in mind this is only the first example.
Let's see what we are going to write into each file ?

src/intro.js


var myLib = (function (global, undefined) {"use strict";

src/function/query.js


  // private scope function
  function query(selector) {
    return document.querySelectorAll(selector);
  }

src/function/Wrapper.js


  function Wrapper(nodeList) {
    this.length = nodeList.length;
    this._list = nodeList;
  }

src/function/Wrapper/prototype/item.js


  // a prototype method of the Wrapper "class"
  Wrapper.prototype.item = function item(i) {
    return this._list[i];
  };

src/function/query/asWrapper.js


  // public static query method
  query.asWrapper = function (selector) {
    return new Wrapper(query(selector));
  };

src/var.js


  var // private scope variables
    document = global.document,
    slice = [].slice
  ;

src/outro.js


  // the actual object/namespace
  return {
    query: query,
    internals: {
      Wrapper: Wrapper
    }
  };

}(this));

Got it?

Structure Rules

every part of the scope can be distributed
each file can or cannot be compatible as stand alone with a parser because to test the library we need to build it first ( eventually with automations )
function declarations should be included in a dedicated folder called function accordingly with the nested level
var declaration per scope could be included in a folder var accordingly with the nested level. Do not create a var folder per each function where you define variables 'cause if you need it it means the function is too complex. Split it in sub task and do not define 100 variables per a single function: closures are the only exception.
nested closure must be named in order to be able to define nested closure structure following previous rules. Every minifier will be able to remove function expression names, included named closures, while not every developer would like to deeply understand the whole code to recognize why the nested closure was useful. A classic example is the inclusion inside our own closure of an external library that uses its own closure. in this case name that closure so you know were to look for the library inside your folder structure.
function prototypes should be placed inside a prototype folder, inside the function folder.
We don't need to reassign an object when we want to pollute the function prototype so please stop this awkward common practice ASAP: MyFunction.prototype = { /* THIS IS WRONG */ } and use the already available prototype object defined by default in every ECMAScript standard and per each function declaration or expression.
If your argument is that the code will be bigger, use the outer scoped variables definition to address the prototype once and reuse this reference within the prototype folder. This approach will make your life easier once you get use to work with structured and distributed JavaScript files.

Specially about last example, we could have set a shortcut to the Wrapper.prototype object in the var.js file and reuse the reference inside Wrapper.
The structured folders will always help you to find references in the library thanks to the lookup that you, as well as the code, have to do.


    // in the var.js file
    WrapperPrototype = Wrapper.prototype,

    // in the Wrapper/prototype/item.js file
    WrapperPrototype.item = function item(i) { ... };

The Order Partially Matters

In ECMAScript 3rd or higher edition function declarations are always available at the very beginning of the scope. I really don't know why these are so much underrated in daily basis code ... the fact these are always available means we can reference their prototype at any moment in our code:


var internalProto = (function () {

    // address any declaration made in this scope
    var WhateverPrototype = Whatever.prototype;
    return WhateverPrototype;

    // even if defined after a return!!!
    function Whatever() {}
}());

alert(internalProto); // [object Object]

Now, the above code is simply a demonstration about how function declarations work ... I am not suggesting a return in the middle, and declarations after, all I am saying is that the order of things in JavaScript may not be relevant, and function declarations are a perfect example.
Another example is the usage of variables ... if a function, as declaration or as expression, reference a variable defined in the outer scope nothing will break unless we are invoking that function before the referenced variable has been defined.

This are really ABC concepts we all should know about JS before even claiming that we know JavaScript ... OK?
Is really important to get these points because to simplify ASAP the builder file we need to rely in these assumptions.

The builder.js File

It's time to create the magic file that will do the job for us in possibly a smart way so that we can cover all edge cases we could think of.
This is the content of builder.js file, in the root of our project


// @name        builder.js
// @author      Andrea Giammarchi
// @license     Mit Style License

// list of files to include
var
  scriptName = "myLib", // the namespace/object.project name
  fileList = [
    "intro.js",    // beginning of the closure
    "var.js",      // all declared variables
    "function/*",  // all declared functions
    "function/Wrapper/prototype/*", // all methods
    "function/query/*", // all public statics
    "outro.js"     // end of the library
  ],
  fs = require("fs"),  // file system module
  out = [],            // output
  alreadyParsed = []   // parsed files for visual feedback
;

// per each file in the list ...
fileList.forEach(function addFile(file) {
  // if the file contains a wild char ...
  if (file.charAt(file.length - 1) == "*") {
    // read the directory and per each file found there ..
    fs.readdirSync(
      __dirname + "/src/" + file.slice(0, -2)
    ).forEach(function (file) {
      // if the file type is js
      // and the file has not been defined explicitly
      // in the original list
      if (
        file.slice(-3) == ".js" &&
        fileList.indexOf(file) < 0
      ) {
        // call this same function providing the whole path
        addFile(this + file);
      }
       // the path is passed as context to simplify the logic
    }, file.slice(0, -1));
  // if the file has not been included yet
  } else if (alreadyParsed.indexOf(file) < 0){
    // put it into the list of already included files
    alreadyParsed.push(file);
    // add the file content to the output
    out.push(fs.readFileSync(__dirname + "/src/" + file));
  } else {
    // if here, we are messing up with inclusion order
    // or files ... it's a nice to know in console
    try {
      console.log("duplicated entry: " + file);
    } catch(e) {
      // shenanigans
    }
  }
});

// put all ordered content into the destination file inside the dist folder
fs.writeFileSync(__dirname + "/dist/" + scriptName + ".js", out.join("\n"));

// that's it

The reason there are so many checks if a wild char is encountered is quite simple ... the order may not matter but in some case the order matters.
If as example a prototype property is used runtime to define other prototype methods or properties, this cannot be pushed in the output randomly but at the very beginning, example


// src/function/Wrapper/prototype/behavior.js
WrapperPrototype.behavior = "forEach" in [];

// src/function/Wrapper/prototype/forEach.js
WrapperPrototype.forEach = WrapperPrototype.behavior ?
  function (callback) {[].forEach.call(this._list, callback, this)} :
  function (callback) { /* a shim for non ES5 compatible browsers */ }
;

Being file 2 strongly dependent on file 1, the list of files could be written as this:


  fileList = [
    "intro.js",    // beginning of the closure
    "var.js",      // all declared variables
    "function/*",  // all declared functions
    "function/Wrapper/prototype/behavior.js", // precedence
    "function/Wrapper/prototype/*", // all methods
    "function/query/*", // all public statics
    "outro.js"     // end of the library
  ],

When the wild char will be encountered and the behavior passed to the forEach, this will be simply ignored since it has been pushed already in the previous call.
Same concept could happen if a specific file must be parsed runtime at the end:


  fileList = [
    "function/Wrapper/prototype/behavior.js", // precedence
    "function/Wrapper/prototype/*", // all methods
    "function/Wrapper/prototype/doStuff.js" // after all
  ],

I believe these are already edge cases most of the time but at least now we can better understand what the builder will do.

How To Use The Builder

In console, inside the project folder where the builder.js is:


node builder.js

That's pretty much it ... if you try to open dist/myLib.js after above call you will find your beautiful library all in one piece and ready to be minified, debugged, and tested.
If the process does not take long time you may bind the builder to the Constrol+S action with a potential sentinel able to inform you if any problem occurred, as example checking if the output has been polluted with some redundant file logged through the process.

As Summary

All these techniques may be handy for many reasons. First of all it's always good to maintain a structure, rather than a single file with thousands of lines of code, and secondly once we understand how the process work, nothing can stop us to improve, change, make it ad-hoc for anything we may need such regular expressions to strip out some code before the output push or whatever else could come up for some reason at some point.
The minification can be done the way you prefer, as example adding this single line of code at the end of the process assuming you have a jar folder with, as example, google closure compiler.


require('child_process').exec(
  ['java -jar "',
    __dirname + "/jar/compiler.jar",
  '" --compilation_level=SIMPLE_OPTIMIZATIONS --language_in ECMASCRIPT5_STRICT --js "',
    __dirname + "/dist/" + scriptName + ".js",
  '" --js_output_file "',
    __dirname + "/dist/" + scriptName + ".min.js",
  '"'].join(""),
  function (error, stdout, stderr) {
    if (error) console.log(stderr);
  }
);

Enjoy your new builder :)

On JSON Comments

2011-12-06T01:30:00.006+01:00

Another active exchange with @getify about JSON comments and here my take because tweets are cool but sometimes is hard to tell everything you think in 140 bytes ...

Kyle Facts

JSON is used on daily basis for billion of things and configuration files are one, surely common, way to use JSON ( just think about npm packages for node.js ).
His frustration about the fact JSON does not allow comments is comprehensible, and he even created an online petition about allowing comments in JSON specs ... but are comments really what we need?

Just A Side Effect

JSON is extremely attractive as standard, first of all because it's available and widely adopted by basically any programming language in this world, even those that never had to deal with a single JavaScript interlocutor, secondly because it's both simple to parse, and easy to read for humans.
After all, what can be so wrong about comments inside such common serialization standard?
Aren't comments just as easy to parse as white spaces?
The problem is, in my opinion, that we are mixing up an easy process to serialize data, much easier compared to what PHP serialize and unserialize functions do, with the possibility to describe it.
I have always seen JSON as a protocol, rather than a YAML substitute, and as a protocol I expect to be as compact as possible and as cross platform as possible.
Specially about the latter point:

that's annoying to port to every single language

Precisely, what we should understand is that if JSON became so popular without needing comments, maybe the fact today we would like to use it as a "descriptive markup" does not reflect anymore the success, the adoption, and possibilities this standard brought to all these languages?

Improve The Standard

Thanks gosh software is not always stuck behind immutable standards or patents ... and neither is JSON.
If the need for comments is such big topic, define another standard able to combine the good old one with a new one.
If this new standard is truly what developers need, every JSON implementor will spend few hours to test and optimize the well defined standard in order to accept comments, isn't it?
I mean ... RFC 4627 was not meant to be the final solution, that was a Crockford proposal universally adopted.
To create a new standard able to extend RFC 4627 should not be a big problem ... or maybe ...

JSON Is Not A JavaScript Thing

The JSON serialization looks just like JavaScript ... but not JavaScript only.
Other programming languages use curly brackets and squared brackets to define lists and objects ( Python and others ) ... the fact JSON has been accepted so well is probably because the design of the format was indeed already widely adopted, it was not a JS thing, and never should be.
What's the deal here, is define a standard for JSON comments.
Let me better explain this point ...

I am a JS developer and I edit my JSON files via my JS editor ... fair enough ... I want to communicate my data to a server side service, let's say Python.
Python would like to be able to parse my data and produce a file compatible with ... Python, of course.
Does it mean that Python at that point should keep comments in a JavaScript standard? And why that, since the format used to exchange data was already somehow evaluable via Python and right now not anymore due some double slash in the file?


# this is PYTHOOOOOOOOOON
o = {"test": "data"}
o.get("test") # data

Will the renewed JSON work as well?


# still python
o = {"test": "data"} // and some WTF
o.get("test")

>> SyntaxError: invalid syntax

Well done ... making JSON with comments a JS thing python, as other languages, need extra effort to parse data.
What will happen once Python uses the json library?


import json

jsonh.loads(theReceivedData);

Should it print data with python compatible comments or with JS compatible comments so that data is not directly usable anymore for any python application, storing it as example in a file.py or a database ?
And once the renewed JSON has been transformed into Python valid syntax, wouldn't this file not be usable anymore from all others programming languages due possible syntax errors ?

Not That Easy

I like JSON as it is, except few broken implementations quite common even on browsers, because it's about creating a bloody piece of text many other languages can understand basically on the fly.
No need to remember which comment style has been saved with that version of JSON, no need to parse back and finally, no need to ask every single programming language that is using JSON as protocol to update their legacy ... that just worked, and it will aways work for what it was meant: transfer data, not transfer JS like code without functions and/or functions calls only ...
What we are doing, we as JavaScript developer, is to abuse JSON as if it's a piece of our JS code, polluting today with comments, and who knows what else tomorrow.
The right way to go, still in my opinion, would be, once again, to enrich, propose, create, a new standard that allows comments and why not, other features.
As example, what I always found annoying is that in PHP we can unserialize preserving the class, so that we can serialize objects states ... where is this in JSON?
Nowhere, indeed I have spent in my past few hours trying to enrich this protocol ... did it work? Was it interesting ? Probably not, except for my last attempt that is 100% based on current JSON and it's about optimizing bandwidth and performances ... that worked better, accordingly with JSONH github status, still I was not expecting every other that never had this problem to adopt that approach ... you know what I mean?

Still Valid JSON

If it's about writing comments, next snippet is perfectly valid JSON string. All we need to do is to use the replacer in a proper way:


{
  "@description": "something meaningful",
   "property": "value",

  "@description": "something else",
  "other": "other value"
}

// parse above text via JSON
console.log(JSON.parse(aboveText, function (key, value){
  if (key.charAt(0) != "@")
    return value;
}));

Here we are with our object, comments manually written on the original JSON, and every language able to parse them

Array extras and Objects

2011-11-30T20:28:00.015+01:00

When Array extras landed in JavaScript 1.6 I had, probably together with other developers, one of those HOORRAYYY moment ...
What many libraries and frameworks out there still implement, is this sort of universal each method that supposes to be compatible with both Arrays and Objects.

A Bit Messed Up

What I have never liked that much about these each methods is that we have to know in advance in any case if the object we are passing is an Array, an ArrayLike one, or an Object.
In latter case, the callback passed as second argument will receive as second argument the key, and not the index, which simply means we cannot trust a generic callback unless this does not check per each iterated item the second argument type, or unless we don't care at all about the second argument.
In any case I always found this a bad design. If we think about events, as example, it's totally natural to expect a single argument as event object and then we can act accordingly.
This let us reuse callbacks for similar purpose and maintain a DRY code.

Need For An Object#forEach

All implementation of each, and as far as I know with the only exception of jQuery which makes things even more complicated since we generally have to completely ignore the first argument in this case, have some natural confusion inside the method.
If you take the underscore.js library, as example, you will note that there are two aliases for the each method, each itself and forEach, so it's more than clear for me that JS developers are clearly missing an Array#forEach like method in order to iterate with objects, rather than lists.
It must be also underlined that all these methods are somehow error prone: what if the object we are passing has a length property that does not necessary mean it points to the length of items stored via index as if it was an Array?
You may consider this an edge case, or an anti pattern, then you have to remember that functions in JavaScript are first class objects.
Probably all these methods will nicely fail indeed with functions, passed as objects, whenever you decide that your function can be used as object too.


var whyNot = function (obj) {
  /* marvelous stuff here */
  this.calls++;
  return this.doStuff(obj);
};
whyNot.calls = 0;
whyNot.doStuff = function (obj) {
  /* kick-ass method */
};

// the unexpected but allowed
whyNot = whyNot.bind(whyNot);

whyNot.length; // 1
whyNot[0];        // undefined

By design, the length of any function in JavaScript is read-only and means nothing, in therms of Array iteration, it simply means the number of arguments the function defined during its declaration/definition as expression.

WTF

Whenever above example makes sense or not, I am pros patterns exploration and when a common method is not compatible with all scenarios, I simply think something went wrong or is missing in the language.
Thanks gosh JS is freaking flexible and with ES5 we can define some prototype without affecting for( in ) loops but hopefully simplifying our daily basis stuff.
Remember? With underscore or others we still have to know in advance if the passed object is an Array, an ArrayLike, or a generic object ... so what would stop us to simply chose accordingly?


// Array or ArrayLike
[].forEach.call(genericArrayLike, callbackForArrays);

// generic object to iterate
{}.forEach.call(object, callbackForObjects);

An explicit choice in above case is the fastest and most reliable way we have to do things properly. A DOM collection, as well as any array or arrayLike object will use the native forEach, but we can still recycle callbacks designed to deal with value, key and objects, rather than value, index, and this is the little experiment:

Object extras

The concept of each callback is exactly the same of original, native, Array callbacks, except things are based on native functions available in all ES5 compatible desktop and basically all mobile browsers, and easy to shim with all others too old to deal with JS 1.6 or higher.

Here a couple of examples:


var o = {a:"a", b:"b", c:""};

// know if all values are strings
o.every(function (value, key, object) {
  return typeof value == "string";
}); // true

// filter by content, no empty strings
var filtered = o.filter(function (value, key, object) {
  return value.length;
}); // {a:"a",b:"b"} // original object preserved

// loop through all values (plus checks)
o.forEach(function (value, key, object) {
  object === o; // true
  this === o;    // true
  if (key.charAt(0) != "_") {
    doSomethingWithThisValue(value);
  }
}, o); // NOTE: all these methods respect Array extras signatures

// map a new object
var mapped = o.map(function (value, key, object) {
  return value + 1;
}); // {a:"a1",b:"b1"} // original object preserved

// know if a value contains "a"
o.some(function (value, key, object) {
  return value === "a";
}); // true

The reason reduce and reduceRight are not in the list is simple: which one would be the key to preserve, the first of the list? There is no such thing as "predefined for/in order" in JavaScript plus these methods are more Array related so out of this experiment.

As Summary

Once minified and minzipped the gist weights about 296 bytes which is ridiculous size compared with any application we are dealing with on daily basis.
Specially forEach, but probably others too, may become extremely handy and ... of course, using the Object.keys method internally, this is gonna be compatible with Arrays too but hey, the whole point was to make a clear distinction ;)

[edited]

The Misleading Signature

I don't know how many times I have spoken with jQuery developers, just because they are common, convinced that native Array#forEach was accepting the value as second argument.
I always considered inverted signatures, whatever API it is, bad for both performances, no possibility to fallback into some native method, and learning curve, where new comers learn than a generic each method must have the index as first argument.
Bear in mind whenever we loop we are most likely interested into the value of that index or key, so this value should be the first, and if you need the only one, argument passed through the procedure.
A completely ignored first argument is, once again and in my opinion, a bad design for an API: stuck without native power, teaching arguments order is not relevant.
Well, specially latter point is true if we have named arguments, but in JS nothing have been planned so far, and in ES6 the way we gonna name arguments is still under discussion.

Have fun with JS

About Felix's Style Guide

2011-11-27T15:26:00.017+01:00

Style guides are good as long as these are meaningful and a bit "open minded" because if one style is recognized as anti pattern then it must be possible to update/change it.

The Felix's Node.js Style Guide is surely a meaningful one, but I hope it's open minded too.

Why This Post

Because I write node.js code as well sometimes and I would like to write code accepted by the community. Since developers may go too religious about guides I don't want explain all these points per each present or future node.js module I gonna write ... I post it once, I will eventually update it, but it's here and I can simply point at this any time.

Style Guide Side Effect

As happened before with the older one or the linter, a style guide may mislead developers and if they are too religious and unable to think about some point, the quality of the result code may be worse rather than better.
I have talked about JSLint already too much in this blog so ... let's bring the topic in track and see what Felix may re-consider.

Quotes

Current status: Use single quotes, unless you are writing JSON
A common mistake for JavaScript developers, specially those with PHP, Ruby, or other scripting languages background, is to think that single quotes are different from double quotes ... sorry to destroy this myth guys but in JavaScript there is no difference between single and double quotes.
Once you get this, you must think that if by standard definition JSON uses double quotes there is no reason to prefer single quotes over double.
What should this difference tell us, that one is JSON and one is JavaScript for node.js? Such assumption is a bit ridiculous to me since JSON is JavaScript, nothing more, nothing less.
More over, I am not a big fan of HTML strings inside JS files because of separation of concerns, and I'll come back on it, but in English, as well as in many other languages, the single quote inside a string is quite common, isn't it?
Accordingly, are you really planning to prefer 'it\'s OK' over "it's OK"?
And if the suggested editor, in the guide itself, is one with supported syntax highlight, shouldn't we simply trust the highlighted string in order to recognize it, rather than distinguish between JSON and non JSON strings?
Shouldn't we write comfortably without silly rules, as Felix says in another point, so that we can chose whatever string delimiter we want accordingly with the content of the string?
Last, but not least, for those convinced that in HTML there is any sort of difference between single and double quotes, I am sorry to, once again, destroy this myth since there is no difference in HTML between quotes ... so, once again, chose what you want and focus on something else than distinction between JSON and non JSON strings ...

Variable declarations

Current status: Declare one variable per var statement, it makes it easier to re-order the lines. Ignore Crockford on this, and put those declarations wherever they make sense.
If there is one thing that I always agreed with Crockford is this one: variable declared at the beginning of the function, with the exception for function declarations that should be before variable declarations, and not after.
The reason is quite simple: wherever we declare a variable, this will be available at the very beginning of the scope so which place can be better than the beginning of the scope itself to instantly recognize all local scope variables rather than scrolling the whole closure 'till the end in order to find that name that completely screwed up the whole logic in the middle because is shadowing something else inside or outside the scope ?
Is that easy, I don't want to read potentially thousands of lines of code to understand which variable has been defined where, I want a single bloody place to understand what is local and what is not.
The only exception to this rule may be some temporary variable, as is the classic i used in for loops, or some tmp reference still common in for loops


// the exception ... in the middle of the code

for (var i = 0, length = something.length, tmp; i < length; ++i) {
    tmp = something[i];
    // do something meaningful 
}

Chances that above loop will destroy our logic because of a shadowed i or tmp reference are really rare and we should use meaningful variables name.
As summary, there are only advantages on declaring variables on top, and until we have no let statements it is only risky, and dangerous for our business, to define variables in the wild.


// how you may write code
(function () {
  return true;
  var inTheWild = 123;
  function checkTheWild() {
    return inTheWild === 123;
  }
}());

// how JS works in any case
(function () {

  // function declarations instantly available in the scope
  function checkTheWild() {
    return inTheWild === 123;
  }

  // any var declaration instantly available as undefined
  var inTheWild;

  return true;

  // no matters where/if we assign the value
  // the inTheWild is already available everywhere
  // with undefined as default value
  // and before this assignment
  inTheWild = 123;
  
  // shadows should be easy to track
  // top of the function is the right place to track them
}());

Constants

Current status: Constants should be declared as regular variables or static class properties, using all uppercase letters.

Node.js / V8 actually supports mozilla's const extension, but unfortunately that cannot be applied to class members, nor is it part of any ECMA standard.
I could not disagree more here ... the meaning of constant is something immutable and the reason we use constant is to believe these are immutable.
Why on earth avoid a language feature when it provides exactly what we need? Don't we want more reliable code? And what about security?
Neither in PHP we can define an object property and this does not mean we should avoid the usage of define function, isn't it?
Use const as much as you want unless the code does not have to run cross platform ( browsers included ) and if you want to define constants with objects, use the JavaScript equivalent to do that.


function define(object, property, value) {
    Object.defineProperty(object, property, {
        get: function () {
            return value;
        }
        // if you really want to throw an error
        // , set: function () {throw "unable to redefine " + property;}
    });
}

var o = {};
define(o, "TEST", 123);
o.TEST = 456;
o.TEST; // 123

I have personally proposed cross platform ways to do the same without or within objects themselves.
As we can see there are many ways to define constants and if the argument is that const is not standard it's a weak one because nobody is planning to remove this keyword from V8 or SpiderMonkey, most likely every other browser will adopt this keyword in the future but if that won't happen, to find and replace it with var only when necessary is a better way to go: security and features, we should encourage these things rather than ignore them, imho.

Equality operator

Current status: Programming is not about remembering stupid rules. Use the triple equality operator as it will work just as expected.
No it doesn't because coercion is not about equality only.


alert("2" < 3 && 1 < "2");

Programming IS about remembering rules, that's the reason we need to know the syntax in order to code something ... right?
Coercion must be understood rather than being ignored and rules are pretty much simple and widely explained in the specs, even more simplified in this old post of mine.
If any of you developers still do this idiotic check you are doing it wrong.


// WRONG!!!!!!!!!!!!!
arg === null || arg === undefined

// THE SAFER EXACT EQUIVALENT
arg == null

You should rather avoid undefined equality in any piece of code you wrote, unless you did not create an undefined reference by yourself.
As summary, a good developer does not ignore problems, a good developer understands them and only after decide which way is the best one.
Felix is a good developer and he should promote deeper knowledge ... this specific point was really bad because it's like saying "avoid regular expressions because you don't understand them and you don't want to learn them".

Extending prototypes

Current status: Do not extend the prototypes of any objects, especially native ones
Read this article and stick an "it depends" in your screen. Nobody wants to limit JS potentials and Object.defineProperty/ies is a robust way to do things properly.
Sure we must understand that even a method like Array#empty could have different meanings ... e.g.


var arr = Array(3);
// is arr empty ?
// length is 3 but no index has been addressed

If we pollute native prototype we must agree on the meaning or we must prefix our extension so that nobody can complain if that empty was good enough or just a wrong concept.


// a meaningful Array#empty
Object.defineProperty(Array.prototype, "empty", {
  value: function empty() {
    for (var i in this) return false;
    return true;
  }
});

alert([
  [].empty(),       // true
  Array(3).empty(), // true
  [null].empty()    // false
]);

Conditions

Current status: Any non-trivial conditions should be assigned to a descriptive variable
I often write empty condition on purpose and to both avoid superflous re-assignment and speed up the code.


// WRONG
object.property = object.property || defaultValue;

// better
object.property || (object.property = defaultValue):

// RIGHT
"property" in object || (object.property = defaultValue);

Why on earth would I assign that ? Same I would not do it if the condition is not reused at least twice.


if (done.something() && done.succeed) {
    // done.something() && done.succeed useful
    // here and nowhere else in the code
}

Accordingly with the fact spread variable declarations are a bad practice, I cannot think about creating flags all over the place for these kind of one shot checks.

Function length

Current status: Keep your functions short. A good function fits on a slide that the people in the last row of a big room can comfortably read. So don't count on them having perfect vision and limit yourself to ~10 lines of code per function.
I agree on this point but JavaScript is all about functions.
I understand the require approach does not need a closure to surround the whole module, being this already somehow sandboxed, but cross platform code and private functions or variables are really common in JS so that a module may be entirely written inside a closure.
A closure is a function so as long as this point is flexible is fine to me, also as long as the code is still readable and elegant ... I can already imagine developers writing 10 lines of functions using all 80 characters per line in order to respect this point ...

... now, that would be lame.

Object.freeze, Object.preventExtensions, Object.seal, with, eval

Current status: Crazy shit that you will probably never need. Stay away from it.
Felix here put language features together with "language mistakes".
With "use strict" directive, the one Felix should have put at the very beginning of his guideline, with statement is not even allowed.
eval has nothing to do with Object.freeze and others and these methods are part of the ES5 specification.
It is true you may not need them, to define them as something to stay away from, specially from somebody that said there are no constants for objects, is kinda limitative and a sort of non sense.
Learn these new methods, and use them if you think/want/need.

And that's all folks

JSONH New schema Argument

2011-11-26T12:52:00.003+01:00

The freaking fast and bandwidth saver JSONH Project has finally a new schema argument added at the end of every method in order to make nested Homogeneous Collections automatically "packable", here an example:


            var
                // nested objects b property
                // have same homogeneous collections
                // in properties c and d
                schema = ["b.c", "b.d"],
                
                // test case
                test = [
                    {   // homogeneous collections in c and d
                        b: {
                            c: [
                                {a: 1},
                                {a: 2}
                            ],
                            d: [
                                {a: 3},
                                {a: 4}
                            ]
                        }
                    }, {
                        a: 1,
                        // same homogeneous collections in c and d
                        b: {
                            c: [
                                {a: 5},
                                {a: 6}
                            ],
                            d: [
                                {a: 7},
                                {a: 8}
                            ]
                        }
                    }
                ]
            ;

The JSONH.pack(test, schema) output will be the equivalent of this string:


[{"b":{"c":[1,"a",1,2],"d":[1,"a",3,4]}},{"a":1,"b":{"c":[1,"a",5,6],"d":[1,"a",7,8]}}]

How Schema Works

It does not matter if the output is an object or a list of objects, as well as it does not matter if the output has nested properties.
As soon as there is an homogeneous collection somewhere deep in the nested chain and common for all other levels, the schema is able to reach that property and optimize it directly.
Objects inside objects do not need to be the same or homogeneous, these can simply have a unique property which is common for all items and this is enough to take advantage of the schema argument that could be one string, or an array of strings.

Experimental

Not because it does not work, I have added tests indeed, simply because I am not sure 100% this implementation covers all possible cases but I would rather keep it simple and let developers deal with more complex scenario via manual parsing through the JSONH.pack/unpack and without schema ... this is still possible as it has always been.
Let me know what you think about the schema, if accepted, I will implement it in Python and PHP too, thanks.

On Complex Getters And Setters

2011-11-25T21:41:00.007+01:00

A common use case for getters and setters is via scalar values rather than complex data.
Well, this is just a programmer mind limit since data we could set, or get, can be of course much more complex: here an example


function Person() {}
Person.prototype.toString = function () {
    return this._name + " is " + this._age;
};
// the magic identity configuration object
Object.defineProperty(Person.prototype, "identity", {
    set: function (identity) {
        // do something meaningful
        this._name = identity.name;
        this._age = identity.age;
        // store identity for the getter
        this._identity = identity;
    },
    get: function () {
        return this._identity;
    }
});

With above pattern we can automagically update a Person instance name and age through a single identity assignment.


var me = new Person;
me.identity = {
    name: "WebReflection",
    age: 33
};

alert(me); // WebReflection is 33

While the example may not make much sense, the concept behind could be extended to any sort of property of any sort of class/instance/object.

What's Wrong

The problem is that the setter does something in order to keep the object updated in all its parts but the getter does nothing different than returning just the identity reference.
As summary, the problem is with the getter and the reason is simple: from user/coder perspective this may not make sense!


me.identity.name = "Andrea";

alert(me); // WebReflection is 33

In few words we are changing an object property, the one used as identity for the me variable, leaving the instance of Person untouched ... and semantically speaking this looks wrong!

A Better Approach

If the setter aim is to update a state there will be only a well known amount of properties to re-assign before this status can be updated.
In this example we would like to be sure that as soon as the identity has been set, the instance toString method will produce the expected result and without relying an external reference, the identity object itself.


// listOfNames and listOfAges are external Arrays
// with same length
for (var
  identity = {},
  population = [],
  i = 0,
  length = listOfNames.length;
  i < length; ++i
) {
  // reuse a single object to define identities
  identity.name = listOfNames[i];
  identity.age = listOfAges[i];
  population[i] = new Person;
  population[i].identity = identity;
  // out of this loop we want that each 
  // instanceof Person prints out
  // the right name and surname
}

// we cannot do it lazily in the toString method ...
// this will fail indeed
Person.prototype.toString = function () {
  return this._identity.name + " is " + this.identity._age;
};

Got it? It's basically what happens when we use an object to define a property, more properties, or to create inheriting from another one: properties and values are parsed and assigned at that moment, not after!


var commonDefinition = {
  enumerable: true,
  writable: true,
  configurable: false
};

var
  name = (commonDefinition.value = "a"),
  a = Object.defineProperty({}, "name", commonDefinition),
  name = (commonDefinition.value = "b"),
  b = Object.defineProperty({}, "name", commonDefinition)
;
alert([
  a.name,  // "a"
  b.name   // "b"
]);

As we can see if the property assignment would have been lazy the result of the latest alert would have been "b", "b" since the object used to define these properties has been recycled ... I hope you are still following ...

A Costy Solution

There is one approach we may consider in order to make this identity consistent ... the one that stores an identity with getters and setters.


// the magic identity configuration object
Object.defineProperty(Person.prototype, "identity", {
    set: function (identity) {
        var self = this;

        // do something meaningful
        self._name = identity.name;
        self._age = identity.age;

        // store identity as fresh new object with bound behavior
        this._identity = Object.defineProperties({}, {
            name: {
                get: function () {
                    return self._name;
                },
                set: function (name) {
                    self._name = name;
                }
            },
            age: {
                get: function () {
                    return self._age;
                },
                set: function (age) {
                    self._age = age;
                }
            }
        });
    },
    get: function () {
        return this._identity;
    }
});

What changed ? The fact that now we are able to pass through the instance and operate through the identity:



me.identity.name = "Andrea";

alert(me); // Andrea is 33

Cool hu ? ... well, it could be better ...

A Faster Solution

If for each Person and each identity we have to create a fresh new object plus at least 4 functions, 2 for getters and 2 for relative setters, our memory will fill up so quickly that we won't be able to define any other person identity soon and here comes the fun part: use the knowledge gained by this pattern internally!
Yes, what we could do to make things slightly better is to recycle the internal identity setter object definition in order to borrow maximum 4 functions rather than 4 extra per each Person instance ... sounds cool. uh?


function Person() {}
Person.prototype.toString = function () {
  return this._name + " is " + this._age;
};

(function () {

  var identityProperties = {
    name: {
      get: function () {
        return this.reference._name;
      },
      set: function (name) {
        this.reference._name = name;
      },
      configurable: true
    },
    age: {
      get: function () {
        return this.reference._age;
      },
      set: function (age) {
        this.reference._age = age;
      },
      configurable: true
    },
    reference: {
      value: null,
      writable: true,
      configurable: true
    }
  };

  Object.defineProperty(Person.prototype, "identity", {
    get: function () {
      return this._identity;
    },
    set: function (identity) {
      // something meaningful
      this._name = identity.name;
      this._age = identity.age;

      // set the reference to the recycled object
      identityProperties.reference.value = this;

      // define the _identity property
      if (!this._identity) {
        Object.defineProperty(
          this, "_identity", {value: {}}
        );
      }
      Object.defineProperties(
        this._identity,
        identityProperties
      );
    }
  });

}());

var
  identity = {},
  a = new Person,
  b = new Person
;

identity.name = "a";
identity.age = 30;
a.identity = identity;

identity.name = "b";
identity.age = 31;
b.identity = identity;

alert([
  a,  // "a is 30"
  b   // "b is 31"
]);

So what we have there? A lazy _identity definition, good for those scenario where some getter or setter may never been invoked, plus a smart recycled property definition through a single object descriptor, and performances boosted up N times per each instance since no multiple different functions are assigned per identity properties getters and setters and no extra objects are created runtime ... arf, arf .. are you still with me ?

As Summary

Some JS developer keep asking for standard ways to do these kind of crazy stuff without realizing that few other programming languages are that flexible as JavaScript is ... it's maybe not that simple to find better, optimized, in therms of both memory consumption and raw performances, patterns to cover weird scenario but what we should appreciate is that with JS we almost have, always, a way to simulate something we did not even think about until the day before.
Have fun with JS ;)

Differential Background Scrolling

2011-11-21T03:19:00.003+01:00

A quick one about this technique quite common in Flash sites but rarely seen on Web.
Have a look at the example first so you can understand what I am talking about ... got it ?

What Is This About

Let's say we have a background, a big massive graphic background surely not suitable for mobile phones, due data roaming, but maybe cool for desktop and fast ADSL.
The background-size CSS property is able to let us decide if the image used as background should fit the whole element or only a portion of it.
In this case the image should fit, by default, the whole height of the document with an auto width in order to let the browser adjust the scale.
A differential scrolling is visible the moment we scroll the page ... please resize the window into a smaller one if you are in an HD monitor and start scrolling the page.
At the very beginning, the default height of the image is 100%, as body background, and with some padding in order to let space for few important image parts such the header, with clouds and enough space for a H1 tag, and the bottom, with the stylish logo of this game from elderscrolls.com, the one which page inspired this little experiment. Bear in mind no code has been even read from that website ... I have seen the effect, I have used it many times ages ago via ActionScript, I decided to do something similar for most advanced browsers, and here is ...

The Code


(function (document) {
 // (C) WebReflection - Mit Style Licence
 var
  ratio = .85, // 0 to 1 where 1 is 100%
  
  // shortcuts
  styleSheets = document.styleSheets,
  documentElement = document.documentElement,
  ceil = Math.ceil,
  scroll = "scroll",
  scrollHeight = scroll + "Height",
  scrollTop = scroll + "Top",
  body, sHeight, sTop, y, last
 ;
 styleSheets = styleSheets[styleSheets.length - 1];
 // redefine the rule for the height
 styleSheets.insertRule(
  "body{background-size:auto " + ceil(
   ratio * 100
  ) + "%;}",
  styleSheets.cssRules.length
 );
 // get the rest of the ratio
 ratio = 1 - ratio;
 // attach a scroll listener
 addEventListener(scroll, function (e) {
  if (body || (body = document.body)) {
   sHeight =  documentElement[scrollHeight] ||
      body[scrollHeight];
   sTop =   documentElement[scrollTop] ||
      body[scrollTop];
   y = ceil(
    ratio * sHeight * sTop / (sHeight - innerHeight)
   );
   // this avoid some redundant assignment
   // hopefully creating less flicking effect
   if (last != y) {
    body.style.backgroundPosition = "center " + (last = y) + "px";
   }
  }
 }, false);
 // you may want to try this for Chrome Browsers
 //documentElement.style.WebkitTransform = "translateZ(0)";
}(document));

The Problem

Many of them ... to start with the fact this technique does not scale as showed in this example since for mobile phones, or generally speaking smaller screens, it does not make sense to use such big image: use media queries for this.
Opera 12 is almost there but something goes terribly wrong during background reposition ... it's screwed up by N pixels even if the rest of the logic works and no error is shown on console.
Firefox Nightly goes quite well but it is still flicking a bit while Safari, and even better WebKit Nightly, are the smoothest in this Mac.
The disaster is Chrome Canary, which is not able to handle this background repositioning.
You can see the effect if you scroll fast in both inspiration site and my experiment and, as commented out in the code, the only way to make it better is to force HW acceleration in the whole document 'cause in the body only the background looks broken ... it's really cool to see how DOM is able to mess up with GPUs, isn't it?

As Summary

Nothing much to add to this post, it was just a quick example over a cool effect but as it is, since ever, in this Web field, almost everything went terribly wrong :D
Have fun with CSS and graceful JS enhancements!

Few JavaScript Patterns

2011-11-12T13:02:00.014+01:00

Just to be clear and once again, JavaScript can emulate:

classes
public and public static methods or properties
private and private static methods or properties
public and private constants
protected methods
... you name it ...

// duck typing ( maybe all you need )
var me = {name: "WebReflection"};

// basic class
function Person() {}
Person.prototype.getName = function () {
    return this.name;
};
Person.prototype.setName = function (name) {
    this.name = name;
};

// module pattern + private properties / methods
function Person(_name) {
    function _getName() {
        return _name;
    }
    return {
        getName: function () {
            // redundant, example only
            return _getName();
        },
        setName: function (name) {
            _name = name;
        }
    };
}

// private shared methods via this
var Person = (function () {
    function Person() {}
    function _getName () {
        return this.name;
    }
    function _setName (name) {
        this.name = name;
    }
    Person.prototype.getName = function () {
        return _getName.call(this);
    };
    Person.prototype.setName = function (name) {
        _setName.call(this, name);
    };
    return Person;
}());

// private shared method Python style
var Person = (function () {
    function Person() {}
    function _getName (self) {
        return self.name;
    }
    function _setName (self, name) {
        self.name = name;
    }
    Person.prototype.getName = function () {
        return _getName(this);
    };
    Person.prototype.setName = function (name) {
        _setName(this, name);
    };
    return Person;
}());

// public static
function Person() {
    Person.TOTAL++;
}
Person.TOTAL = 0;

// private static / constant
var Person = (function () {
    var TOTAL = 0;
    return function Person() {
        TOTAL++;
    };
}());

// public constant
function Person() {}
Object.defineProperty(Person, "RACE", {
    writable: false,    // default
    configurable: false,// default
    enumerable: true,
    value: "HUMAN"
});

// public inherited constant
function Person() {}
Object.defineProperty(Person.prototype, "RACE", {
    writable: false,    // default
    configurable: false,// default
    enumerable: true,
    value: "HUMAN"
});

// protected method
function Person() {}
Person.prototype.getName = function () {
    return this instanceof Person ?
        this.name :
        throw "protected method violation"
    ; 
};
Person.prototype.setName = function (name) {
    this instanceof Person ?
        this.name = name :
        throw "protected method violation"
    ; 
};

// generic protected methods
Function.prototype.protectedVia = function (Class) {
    var method = this;
    Class || (Class = Object);
    return function () {
        if (this instanceof Class) {
            return method.apply(this, arguments);
        }
        throw "protected method violation on " + (
            Class.name || Class
        );
    };
};
function Person() {}
Person.prototype.getName = function () {
    return this.name;
}.protectedVia(Person);
Person.prototype.setName = function (name) {
    this.name = name
}.protectedVia(Person);

// private shared variables
function Person() {}
Person.prototype.getName = function () {
    return this.name;
};
(function (PersonPrototype) {
    var changes = 0;
    PersonPrototype.setName = function (name) {
        changes++;
        this.name = name;
    };
    PersonPrototype.howManyChangedName = function () {
        return changes;
    };
}(Person.prototype));

// getters / setters on public property
var person = Object.defineProperty({}, "name", {
    get: function () {
        return this._name;
    },
    set: function (_name) {
        this._name = _name;
    }
});

// getters setters on public property via prototype
function Person() {}
Object.defineProperty(Person.prototype, "name", {
    get: function () {
        return this._name;
    },
    set: function (_name) {
        this._name = _name;
    }
});

// getters / setters on private property
var person = Object.defineProperty({}, "name", (function () {
    var _name;
    return {
        get: function () {
            return _name;
        },
        set: function (name) {
            _name = name;
        }
    };
}()));

// singleton
var me = {name: "WebReflection"};

// singleton via anonymous __proto__
// plus private properties
var me = new function () {
    var _name;
    this.getName = function () {
        return _name;
    };
    this.setName = function (name) {
        _name = name;
    };
};

// generic singleton cross browser
Function.prototype.singleton = (function () {
    function anonymous(){};
    function create(Class, args) {
        anonymous.prototype = Class.prototype;
        Class.apply(
            Class.__singleton__ = new anonymous,
            args
        );
        return Class.__singleton__;
    }
    return function singleton() {
        return this.__singleton__ || create(this, arguments);
    };
}());

// generic singleton ES5
Function.prototype.singleton = (function () {
    function create(Class, args) {
        Class.apply(
            Class.__singleton__ = Object.create(
                Class.prototype
            ), args
        );
        return Class.__singleton__;
    }
    return function singleton() {
        returh this.__singleton__ || create(this, arguments);
    };
}());

// per function private singleton
var Person = (function () {
    var instance;
    return function Person () {
        return instance || (instance = this);
        // or ... ot be more than sure ...
        return instance || (
            (instance = true) && // avoid infinite recursion
            (instance = new Person)
        );
    };
}());

// generic factory
Function.prototype.factory = (function () {
    function anonymous() {};
    return function factory() {
        anonymous.prototype = this.prototype;
        var instance = new anonymous;
        this.apply(instance, arguments);
        return instance;
    };
}());

// generic factory ES5 + ruby style
Function.prototype.new = function factory() {
    var instance = Object.create(this.prototype);
    this.apply(instance, arguments);
    return instance;
};

Function.prototype.notifier

2011-11-08T23:33:00.007+01:00

There are way too many ways to stub functions or methods, but at the end of the day all we want to know is always the same:

has that function been invoked ?
has that function received the expected context ?
which argument has been passed to that function ?
what was the output of the function ?

Update thanks to @bga_ hint about the output property in after notification, it made perfect sense

The Concept

For fun and no profit I have created a prototype which aim is to bring a DOM like interface to any sort of function or method in order to monitor its lifecycle:

the "before" event, able to preventDefault() and avoid the original function call at all
the "after" event, in order to understand if the function did those expected changes to the environment or to a generic input object, or simply to analyze the output of the previous call
the "error" event, in case we want to be notified if something went wrong during function execution
the "handlererror" event, just in case we are the cause of an error while we are monitoring the original function

The reason I have chosen an addEventListener like interface, called in this case addListener, is simple: JavaScript works pretty well with event driven applications so what else could be better than an event driven approach?

Basic Example


var nFromCharcode = String.fromCharCode.notifier({
    before: function (e) {
        if (e.arguments.length > 2048) {
            throw "too many arguments";
            e.preventDefault(); // won't even try to execute it
        }
        // in case you want to remove this listener ... 
        e.notifier.removeListener("before", e.handler);
    },
    after: function (e) {
        if (e.output !== "PQR") {
            throw "expected PQR got " + e.output + " instead";
        }
    },
    handlererror: function (e) {
        testFramework.failBecause("" + e.error);
    }
});

// run the test ...
nFromCharcode(80, 81, 82); // "PQR"
nFromCharcode.apply(null, arrayOf2049Codes); // testFramework will fail

The notifier itself is a function, precisely the original function wrapper with enriched API in order to monitor almost every aspect of a method or a function.
The event object passed through each listener has these properties:

notifier: the object create to monitor the function and notify all listeners
handler: the current handler to make the notifier remove listener easier
callback: the original function that has been wrapped by the notifier
type: the event type such before, error, after, handlererror
arguments: passed arguments transformed already into array
context: the "this" reference used as callback context
error: the optional error object for events error and handlererror
preventDefault: the method able to avoid function execution if called in the before listener
output: assigned only during "after" notification and if no error occurred, handy to compare expected results

I guess there is really nothing else we could possibly know about a notifier, and its callback, lifecycle, what do you think?

The Code

As Summary

I have also a full test coverage for this notifier and I hope someone will use it and will come back to provide some feedback, cheers!

On User Agent Sniffing

2011-10-31T20:52:00.009+01:00

Oh well, who was following me on twitter today is already bored about this topic (I guess) but probably other developers would like to read this too so ...

What Is UA Sniffing

UserAgent sniffing means that a generic software is relying into a generic string representation of the underlying system. The User Agent is basically considered a unique identifier of "the current software or hardware that is running the app".
In native applications world UA could be simply the platform name ... where if it's "Darwin" it means we are in a Mac platform, while if it's Win32 or any other "/^Win.*$/" environment, the app reacts, compile, execute, as if it is in a Windows machine ... and so on with Linux and relative distributions.

The "Native" Software Behavior

If you have an hybrid solution, example those solutions not allowed anymore but called Hachintosh not long time ago, your machine has most likely Windows Starter capable Hardware but it's running compiled Objective-C language. How reliable you think this machine is? Every software will consider it a Mac Hardware capable machine.
Should these applications optimize for non Mac hardware? I don't think so .... I mean, that machine was not classified in first place as Mac capable machine, it was the user/hacker that decided to do something "nasty" so that if something does not work ... who does really care?
Do you really want to provide support for that "random machine in the system"?
I still don't think so ... also, if you know performances and provided hardware has reached certain levels in that environment, do you even want to waste time optimizing things for a Netbook user?
I think reality is that you just create software for the target, or those targets, you want to support and nothing else, isn't it? ... but of course new unexpected comers are, hopefully, welcome ...

The Old Web Behavior

UA sniffing has historically been a bad practice in the world wide web (internet). At the very beginning there was only a major and supported browser, Internet Explorer, and this had something like 80% or more of market share. All developers, browsers vendors, and users with a different browser where most likely redirected into a page that was saying something like: "Your browser is not supported. Please come back with IE!"
Even worst, this was happening on the server side level ... "why that"? Because websites where created, and tested, entirely in Internet Explorer as unique target for any sort of online business.
Was that a good choice? Today we can say it wasn't but back at that time it was making sense on business level.
How many apps we know that work only on Windows or only on Mac? Many of them, and we are talking about only two platforms.
At least at that point we had a server side degradation into a non service completely useless for not targeted browsers but ... hey, that was their business, and if they wanted to use ActiveXObject because many things where not possible in other browsers, how can we blame these companies? "Everywhere or nothing"? A nice utopia that won't bring you that far in real world .... nothing, I repeat, nothing works 100% as expected everywhere.
The dream is to reach that point but stories like Java, .NET VS Mono, Python itself, and of course JavaScript, should ring a little bell in our developers mind ... we can still go close though, at least on the Web side!

The Modern Web Behavior

Recently things changed quite a lot on web side and only few companies are redirecting via server side User Agent sniffing. We have now something called runtime features detections, something that supposes to test indeed runtime browser capabilities and understand, still runtime, if the browser should be redirected or not into a hopefully meaningful fallback or degraded service.

Features Detections Good Because

Well, specially because the browsers fragmentation is massive, FD can tell us what we need from the current one, without penalizing in advance anybody.
The potential redirection or message only if necessary, informing the user his/her browser is not capable of features required to grant a decent experience in the current online application/service.
FDs are also widely suggested for future compatibility with new browsers we may not be able to test, or recognize, with any sort of list present in our server side logic, the one that is not directly able to understand if the current browser may run the application/service or not.
Of course to be automatically compatible with newer browsers is both business value, as "there before we know", and simplified maintenance of the application/logic itself, since if it was working accordingly with certain features, of course it's going to work accordingly with newer or improved features we need.
As summary, runtime features detections can be extremely valuable for our business ... but

Features Detections Bad Because

Not sure I have to tell you that the first browser with disabled JavaScript support will fail all detections even if theoretically capable ... but lets ignore these cases for now, right?
Well, it's kinda right, 'cause we may have detected browsers with JS disabled already in the server side thanks to user headers or specific agent ... should I mention Lynx browser ? Try to detect that one via JavaScript ...
Back to "real world cases", all techniques used today for runtime features detections are kinda weak ... or better, extremely weak!
I give you an example:


// the "shimmable"
if (!("forEach" in []) || !Array.prototype.forEach) {
    // you wish this gonna fix everything, uh? ... 
    Array.prototype.forEach = function () { ... };
}

// the unshimmable
if (!document.createElement("canvas").getContext("2d")) {
    // no canvas support ... you wish to know here ...
}

Not because I want to disappoint you but you gonna be potentially wrong in both cases ... why that?
Even if Array.prototype.forEach is exposed and this is the only Array extra you need, things may go wrong. As example, the first shim will never be executed in a case where "forEach" in [] is true, even if that shim would have solved our problem.
That bug I have filed few days ago demonstrated that we cannot really trust the fact a method is somewhere since we should write a whole test suite for a single method in order to be sure everything will work as expected OR we gonna write unit, acceptance, integration, and functional tests to be sure that a bloody browser works as expected in our application.
Same is valid for classic canvas capability ... once we have that, do we really test that every method works as expected? And if we need only a single method out of the canvas, how can we understand that method is there and is working as expected without involving, for the single test, part of the API that may not work but even though we don't care since we need only the very first one?
I am talking about drawImage, as example, in old Symbian browsers, where canvas is exposed but drawImage does not visually draw anything on the element ... nice, isn't it?

You Cannot Detect Everything Runtime

... or better, if you do, most likely any user has to wait few minutes before the whole test suite becomes green, specially in mobile browsers where any of these tests take ages burning battery life, CPU clocks, RAM, and everything else before the page can be even visualized since we would like to redirect the user before he can see the experience is already broken, isn't it?

IT Is Not Black Or White

... you think so? I think IT is more about "what's the most convenient solution for this problem", assuming there is, generally speaking, no best solution to a specific problem, since every problem can be solved differently and in a better way, accordingly with the surrounding environment.
So how do we brainstorm all these possible edge cases that cannot obviously be solved runtime in a meaningful, reliable way?

I want provide same experience to as many users as possible but thanks to my tests I have already found user X, Y, and Z, that cannot possibly be compatible with the application/service I am trying to offer.
If I detect runtime everything I need for my app, assuming this is possible, every browser I already know has no problems there will be penalized for non updated, low market share, problematic alternatives.
If I sniff the User Agent with a list of browsers I already know I cannot possibly support due lack of unshimmable features, how faster will be on startup time every other browser I am interested on?

Best Solution Now

If you ask me, today and specially on mobile side, we have 3 categories of browsers:

those almost there
those not there yet
those will never be there

In a business logic you don't even want to waste time for the third category ... "money for nothing", as Mark Knopfler would say.
You also do not want to penalize most interesting browsers categories due massive amount, size and computation logic speaking, of features detections ... I mean, we know those browsers are crap and a minority, the server side User Agent sniffing would be the most suitable solution ever providing any sort of possible fallback or info, if there is no budget for that fallback.
But what about the second category?
Well, it depends ... if the second category has a decent market share you may try to support it and let it pass all your tests but at which price?
If the whole application has to be different for that single browser, and it shares less than 10% of the global market share, reflected into 1% of your users, do you really want to spend all possible effort to make it work?
I would say it makes sense only if this browser has few, shimmable, problems ... otherwise the best place for this browser would be directly the server side, don't you think?
About the first category ... well, it's still about guessing, hoping, praying, that things go as expected but at least for these browsers we can run all our tests against them and be sure that things are at least similar.
I am not talking about pixel perfection, that is bad as well in most of the Web related cases, I am talking about providing a decent experience in your Web application/software/page that strongly relies into JavaScript and that without it cannot possibly work.

As Summary

Few things must be re-considered in the current Web era. Kangax already explained that things today are different, regarding native prototype pollutions and specially via Object.defineProperty and the non enumerable flag but for years we have been all convinced that extending those proto was absolutely something to avoid.
Well, as I agree with Juriy about latter topic, I am still a problem solver that does not exclude any possibility, including User Agent sniffing, when it comes to solve a real world problem, rather than have fantasies about ideals that unfortunately do not reflect reality on our daily basis web development role.

Just think about it ;)

JS getCSSPropertyName Function

2011-10-25T21:51:00.003+02:00

I was re-checking @LeaVerou talk at jsconf.eu looking forward to see mine there too to understand how to improve and specially what the hell I have said for 45 minutes :D

Lea made many valid points in her presentation but as is for supports.property case, you never want to go too deep into a single point of your talk so ... here I come.

getCSSPropertyName Function

This function aim is to understand if the current browser supports a generic CSS property. If property is supported, the whole name included prefix will be returned.


var getCSSPropertyName = (function () {
    var
        prefixes = ["", "-webkit-", "-moz-", "-ms-", "-o-", "-khtml-"],
        dummy = document.createElement("_"),
        style = dummy.style,
        cache = {},
        length = prefixes.length,
        i = 0,
        pre
    ;
    function testThat(name) {
        for (i = 0; i < length; ++i) {
            pre = prefixes[i] + name;
            if (
                pre in style || (
                    (style.cssText = pre + ":inherit") &&
                    style.getPropertyValue(pre)
                )
            ) return pre;
        }
        return null;
    }
    return function getCSSPropertyName(name) {
        return cache.hasOwnProperty(name) ?
            cache[name] :
            cache[name] = testThat(name)
        ;
    };
}());

The function returns a string or null, if no property has been found.


// enable HW acceleration
var cssPropertyName = getCSSPropertyName("transform");
if (cssPropertyName != null) {
    node.style.cssText += cssPropertyName + ":translate3d(0,0,0);";
}

Please feel free to test this function and let me know if something went wrong, thanks ;-)

My BerlinJS Slides

2011-10-20T21:25:00.006+02:00

It was a great event today at @co_up in @berlinjs meet-up and here are my sides about wru which accordingly with today meeting means where are you, directly out of SMS syntax.

Enjoy ;)

Playing With DOM And ES5

2011-10-20T07:32:00.002+02:00

A quick fun post about "how would you solve this real world problem".

The Problem

Given a generic array of strings, create an unordered list of items where each item contains the text of the relative array index without creating a singe leak or reference during the whole procedure.
As plus, make each item in the list clickable so that an alert with current text content occur once clicked.

The assumption is that we are in a standard W3C environment with ES5+ support.

The Reason

I think is one of the most common tasks in Ajax world. We receive an array with some info, we want to display this info to the user and we want to react once the user interact with the list.
If we manage to avoid references we are safer about leaks. If we manage to optimize the procedure, we are also safe about memory consumption over a simplified DOM logic ...
How would you solve this ? Give it a try, then come back for my solution.

The Solution

Here mine:


document.body.appendChild(
  /* input */["a","b","c"].map(
    function (s, i) {
      this.appendChild(
        document.createElement("li")
      ).textContent = s;
      return this;
    },
    document.createElement("ul")
  )[0]
).addEventListener(
  "click",
  function (e) {
    if (e.target.nodeName === "LI") {
      alert(e.target.textContent);
    }
  },
  false
);

Did you solve it the same way ? :)

Do You Really Know Object.defineProperty ?

2011-10-19T01:05:00.007+02:00

I am talking about enumerable, configurable, and writable properties of a generic property descriptor.

enumerable

most likely the only one we all expect: if false, a classic for/in loop will not expose the property, otherwise it will. enumerable is false by default.

writable

just a bit more tricky than we think. Nowadays, if a property is defined as non writable, no error will occur the moment we'll try to change this property:


var o = {};
Object.defineProperty(o, "test", {
  writable: false,
  value: 123
});
o.test; // 123
o.test = 456; // no error at all
o.test; // 123

So the property is not writable but nothing happens unless we try to redefine that property.


Object.defineProperty(o, "test", {
  writable: false,
  value: 456
});
// throws
// Attempting to change value of a readonly property.

Got it ? Every time we would like to set a property of an unknown object, or one shared in an environment we don't trust, either we use a try/catch plus double check, or we must be sure that Object.getOwnPropertyDescriptor(o, "test").writable is true.
writable is false by default too.

configurable

This is the wicked one ... what would you expect from configurable ?

I cannot set a different type of value
I cannot re-configure the descriptor

Fail in both cases since things are a bit different on real world. Take this example:


var o = Object.defineProperty({}, "test", {
  enumerable: false,
  writable: true,
  configurable: false, // note, it's false
  value: 123
});

Do you think this would be possible ?


Object.defineProperty(o, "test", {
  enumerable: false,
  writable: false, // note, this is false only now
  configurable: false,
  value: "456" // note, type and value is different
});

// did I re-configure it ?
o.test === "456"; // true !!!

Good, so a variable that is writable can be reconfigured on writable attribute and on its type.
The only attribute that cannot be changed, once flagged as configurable and bear in mind that false is the default, is configurable itself plus enumerable.
Also writable is false by default.
This inconsistency about configurable seems to be pretty much cross platform and probably meant ... why ?

Brainstorming

If I can't change the value the descriptor must be configurable at least on writable property ... no wait, if I can set the value as not writable then configurable should be set as false otherwise it will loose its own meaning ... no, wait ...

How It Is

writable is the exception that confirms the rule. If true, writable can always be configurable while if false, writable becomes automatically not configurable and the same is true for both get and set properties ... these acts as writable: false no matters how configurble is set.

How Is It If We Do Not Define


// simple object
var o = {};

// simple assignment
o.test = 123;

// equivalent in Object.defineProperty world
Object.defineProperty(o, "test", {
  configurable: true,
  writable: true,
  enumerable: true,
  value: 123
});

Thanks to @jdalton to point few hints out.

As Summary

The configurable property works as expected with configurable itself and only with enumerable one.
If we think that writable has anything to do with both of them we are wrong ... at least now we know.

The Missing Tool In Scripting World

2011-10-16T13:49:00.003+02:00

Few days ago I was having beers with @aadsm and @sleistner and we were talking about languages and, of course, JavaScript too.
That night I have realized there is a missing process, or better tool, that could open new doors for JavaScript world.

The Runtime Nightmare

The main difference between scripting languages and statically typed one is the inability to pre optimize or pre compile the code before it's actually executed.
Engineers from different companies are trying on daily basis to perform this optimization at runtime, or better Just In Time, but believe me that's not easy task, specially with such highly dynamic language as JavaScript is.
Even worst task is the tracing option: at runtime each reference is tracked and if its type does not change during its lifecycle, the code could be compiled as native one.
The moment a type, an object structure, or a property changes, the tracer has to compile twice or split the optimizations up to N exponential changed performed in a single loop so that this tracer has to be smart enough to understand when it's actually worth it to perform such optimization, or when it's time to drop everything and optimize only sub tasks via JIT.

Static Pros And Cons

As I have said, statically typed languages can perform all these optimizations upfront and create, as example, LLVM byte code which is highly portable and extremely fast. As example, both C and C++ can be compiled into LLVM.
There is also a disadvantage in this process ... if some unexpected input occurs runtime, the whole logic could crash, be compromised, or exit unexpectedly.
Latter part is what will rarely happen in scripting world, but it can be also a weak point for application stability and reliability since things may keep going but who knows what kind of disaster an unexpected input could cause.

What If ...

Try to imagine we have created unit tests for a whole application or, why not, just for a portion of it (module).
Try to imagine these tests cover 100% of code, a really hard achievement on web due feature detections and different browsers behaviors, but absolutely easy task in node.js, Rhino, CouchDB, or any JS code that runs in a well known environment.
The differential Mocking approach to solve the web situation requires time and effort but also what JS community is rarely doing, as example, is to share mocks of same native objects in both JS and DOM world. This should change, imo, because I have no idea how many different mocks of XMLHttpRequest or document we have out there and still there is no standard way to define a mock and listen to mocked methods or properties changes in a cross platform way.
Let's keep trying imagine now ... imagine that our tests cover all possible input accepted in each part of the module.
Try to imagine that our tests cover exactly how the application should behave, accordingly with all possible input we want to accept.
It's insane to use typeof or instance of operator per each argument of each function .... this will kill performances, what is not impossible is to do it in a way that, once in production, these checks are dropped.
Since with non tested input we can have unexpected behaviors, I would say that our application should fail or exit the moment something untested occurs .... don't you agree?
How many less buggy web apps we would have out there ? How much more stable and trustable could we be ?
The process I am describing does not exist even in statically typed languages since in that case developers trust unconditionally the compiler, avoiding runtime misbehavior tests ... isn't it ?

The Point Is ...

We wrote our code, we created 100% of code coverage and we created 100% of expected inputs coverage. At this point the only thing we are missing to compile JavaScript into LLVM is a tool that will trace, and trace only, the test while it's executed and will be able to analyze all cases, all types, all meant behaviors, all loops, and all function calls, so that everything could be statically compiled and in separate modules ... how great would this be if possible today?

Just try to imagine ...

Object.prototype.define Proposal

2011-10-15T14:27:00.004+02:00

Somebody may think that defineProperties is boring and I kinda agree on that.

The good news is that JavaScript is flexible enough to let you decide how to do that ... and here I am with a simple proposal that does not hurt, but can make life easier and more intuitive in modern JS environments.

Unobtrusive Object.prototype.define

How To

Well, the handy way you expect.
The method returns the object itself, so it is possible to define one or more property runtime and chain different kind of definitions, as example splitting properties from method and protected properties from protected methods.


var o = {}.define("test", "OK");
o.test; // OK

Multiple properties can share same defaults:


var o = {}.define(["name", "_name"], "unknown");
o.a; // unknown
o._a; // unknown

Methods are immutable by default and properties or methods prefixed with an underscore are by default not enumerable.


function Person() {}
Person.protoype.define(
  ["getName", "setName", "_name"],
  [
    function getName() {
      return this._name;
    },
    function setName(_name) {
      this._name = _name;
    },
    "unknown"
  ]
);

// by convention, _name property is not enumerable

var me = new Person;
me.getName(); // unknown

me.setName("WebReflection");
me.getName(); // WebReflection

for (var key in me) {
  if (key === "_name") {
    throw "this should never happen";
  }
}

Last, but not least, if the descriptor is an object you decide how to configure the property.


var iDecide = {}.define("whatIsIt", {
  value:"it does not matter",
  enumerable: false
});
for (var key in iDecide) {
  if (key === whatIsIt) {
    throw "this should never happen";
  }
}

100% Unit Test Code Coverage

Not such difficult task for such tiny proposal.
This test simply demonstrates the proposal works in all possible meant ways.

As Summary

We can always find a better way to do boring things, this is why frameworks, in all sizes and purposes, are great to both use or create. Have fun

about JS VS VBScript VS Dart

2011-10-13T07:23:00.010+02:00

You can take it as a joke since this is not a proper comparison of these web programming languages.


                                JS      Dart    VBScript
types                           √       √       sort of
getters and setters             √       √       √
immutable objects               √       √       √
prototypal inheritance          √
simulated classes               √
"real" classes                          √       √
closures                        √       √       
weakly bound to JS                      √       √
obtrusive for JS (global)       may be  √       √
obtrusive for JS (prototypes)   may be  √
operator overload                       √
cross browser                   √
real benefits for the Web       √       ?       ?

If you are wondering about JS types, we have both weak type and strong type, e.g. Float32Array.
When StructType and ArrayType will be in place then JS will support any sort of type.

about that post

2011-10-13T06:18:00.007+02:00

I have been blamed and insulted enough so I removed the possibility to comment and I also invite you again to do not stop reading the title of a generic post here or anywhere around the net.

I would like to summarize few parts of that post:

on real world we should use the proper flag in order to generate files where only necessary parts of the library is included
...
I agree that at this stage can be premature to judge the quality of Dart code, once translated for JavaSript world
...
Google is a great company loads of ultra skilled Engineers
...
n.d. I have proposed a fix for Dart code
...
you may realize how much overhead exists in Dart once this is used in non Dart capable browsers
...
Was operator overload the reason the web sucks as it is?
...
everything 2 up to 10 times slower for devices, specially older one, that will never see a native Dart engine in core
...
Not Really What We Need Today
...
What are the performances boost that V8 or WebCL will never achieve ?
...
What is the WebCL status in Chromium ?
...
Where is a native CoffeeScript VM if syntax was the problem ?
...
Doesn't this Dart language look like the VBScript of 2011 ?

You can understand the whole post is not about the number of lines, it's indeed about what this extra layer means today for the current web.

I beg you to please answer my questions, any of them, so that I can understand reasons behind Dart decision.

I have also always admired Google and its Engineers, and I am asking, after GWT and Dart, why many of them seem to be so hostile against JavaScript, the programming language that made Google "fortune" on the web ( gmail, adsense, and all successful stories about Google using massively JavaScript )

Thanks for your patience and please accept my apologies since I followed the blaming mood rather than ignore it or better explain what I meant.

All of this is for a better web or a better future of the web, none of this should fall down into insults.

What Is Wrong About 17259 Lines Of Code

2011-10-12T07:34:00.022+02:00

Is the most popular, somehow pointless, and often funny gist of these days.

It's about Dart, the JavaScript alternative proposed by Google.

Why So Many Lines Of Code

The reason a simple "Hello World" contains such amount of code is because:

the whole library core is included and not minified/optimized but on real world we should use the proper flag in order to generate files where only necessary parts of the library is included
whoever created such core library did not think about optimizing his code

What am I saying, is that common techniques as code reusability do not seem to be in place at all:


// first 15 lines of Dart core
function native_ArrayFactory__new(typeToken, length) {
  return RTT.setTypeInfo(
      new Array(length), 
      Array.$lookupRTT(RTT.getTypeInfo(typeToken).typeArgs));
}

function native_ListFactory__new(typeToken, length) {
  return RTT.setTypeInfo(
      new Array(length), 
      Array.$lookupRTT(RTT.getTypeInfo(typeToken).typeArgs));
}

ListFactory is nothing, I repeat, nothing different from an Array and since the whole core is based on weird naming convention, nothing could have been wrong so far doing something like:


// dropped 4 lines of library core
var native_ListFactory__new = native_ArrayFactory__new;

Please note methods such Array.$lookupRTT and bear in mind that Dart does not work well together with JavaScript libraries since native constructors and their prototypes seem to be polluted in all possible ways.

Not Only Redundant Or Obtrusive Code

While I agree that at this stage can be premature to judge the quality of Dart code, once translated for JavaSript world, is really not the firt time I am not impressed about JavaScript code proposed by Google.
Google is a great company loads of ultra skilled Engineers. Unfortunately it looks like few of them have excellent JavaScript skills and most likely they were not involved into this Dart project ( I have been too hard here but I have never really seen gems in google JS libraries )


// line 56 of Dart core
function native_BoolImplementation_EQ(other) {
  if (typeof other == 'boolean') {
    return this == other;
  } else if (other instanceof Boolean) {
    // Must convert other to a primitive for value equality to work
    return this == Boolean(other);
  } else {
    return false;
  }
}

// how I would have written that
function native_BoolImplementation_EQ(other) {
  return this == Boolean(other);
}

Please note that both fails somehow ..


native_BoolImplementation_EQ.call(true, new Boolean(false)) // true
// so that new Boolean(false) is EQ new Boolean(true)

... while if performances were the problem bear with me and look what Dart came up with ...

124 Lines Of Bindings

Line 80 starts with:


// Optimized versions of closure bindings.
// Name convention: $bind_(fn, this, scopes, args)

... and it cannot go further any different from what you would never expect ...


function $bind0_0(fn, thisObj) {
  return function() {
    return fn.call(thisObj);
  }
}
function $bind0_1(fn, thisObj) {
  return function(arg) {
    return fn.call(thisObj, arg);
  }
}
function $bind0_2(fn, thisObj) {
  return function(arg1, arg2) {
    return fn.call(thisObj, arg1, arg2);
  }
}
function $bind0_3(fn, thisObj) {
  return function(arg1, arg2, arg3) {
    return fn.call(thisObj, arg1, arg2, arg3);
  }
}
function $bind0_4(fn, thisObj) {
  return function(arg1, arg2, arg3, arg4) {
    return fn.call(thisObj, arg1, arg2, arg3, arg4);
  }
}
function $bind0_5(fn, thisObj) {
  return function(arg1, arg2, arg3, arg4, arg5) {
    return fn.call(thisObj, arg1, arg2, arg3, arg4, arg5);
  }
}

function $bind1_0(fn, thisObj, scope) {
  return function() {
    return fn.call(thisObj, scope);
  }
}
function $bind1_1(fn, thisObj, scope) {
  return function(arg) {
    return fn.call(thisObj, scope, arg);
  }
}
function $bind1_2(fn, thisObj, scope) {
  return function(arg1, arg2) {
    return fn.call(thisObj, scope, arg1, arg2);
  }
}
function $bind1_3(fn, thisObj, scope) {
  return function(arg1, arg2, arg3) {
    return fn.call(thisObj, scope, arg1, arg2, arg3);
  }
}
function $bind1_4(fn, thisObj, scope) {
  return function(arg1, arg2, arg3, arg4) {
    return fn.call(thisObj, scope, arg1, arg2, arg3, arg4);
  }
}
function $bind1_5(fn, thisObj, scope) {
  return function(arg1, arg2, arg3, arg4, arg5) {
    return fn.call(thisObj, scope, arg1, arg2, arg3, arg4, arg5);
  }
}

function $bind2_0(fn, thisObj, scope1, scope2) {
  return function() {
    return fn.call(thisObj, scope1, scope2);
  }
}
function $bind2_1(fn, thisObj, scope1, scope2) {
  return function(arg) {
    return fn.call(thisObj, scope1, scope2, arg);
  }
}
function $bind2_2(fn, thisObj, scope1, scope2) {
  return function(arg1, arg2) {
    return fn.call(thisObj, scope1, scope2, arg1, arg2);
  }
}
function $bind2_3(fn, thisObj, scope1, scope2) {
  return function(arg1, arg2, arg3) {
    return fn.call(thisObj, scope1, scope2, arg1, arg2, arg3);
  }
}
function $bind2_4(fn, thisObj, scope1, scope2) {
  return function(arg1, arg2, arg3, arg4) {
    return fn.call(thisObj, scope1, scope2, arg1, arg2, arg3, arg4);
  }
}
function $bind2_5(fn, thisObj, scope1, scope2) {
  return function(arg1, arg2, arg3, arg4, arg5) {
    return fn.call(thisObj, scope1, scope2, arg1, arg2, arg3, arg4, arg5);
  }
}

function $bind3_0(fn, thisObj, scope1, scope2, scope3) {
  return function() {
    return fn.call(thisObj, scope1, scope2, scope3);
  }
}
function $bind3_1(fn, thisObj, scope1, scope2, scope3) {
  return function(arg) {
    return fn.call(thisObj, scope1, scope2, scope3, arg);
  }
}
function $bind3_2(fn, thisObj, scope1, scope2, scope3) {
  return function(arg1, arg2) {
    return fn.call(thisObj, scope1, scope2, arg1, arg2);
  }
}
function $bind3_3(fn, thisObj, scope1, scope2, scope3) {
  return function(arg1, arg2, arg3) {
    return fn.call(thisObj, scope1, scope2, scope3, arg1, arg2, arg3);
  }
}
function $bind3_4(fn, thisObj, scope1, scope2, scope3) {
  return function(arg1, arg2, arg3, arg4) {
    return fn.call(thisObj, scope1, scope2, scope3, arg1, arg2, arg3, arg4);
  }
}
function $bind3_5(fn, thisObj, scope1, scope2, scope3) {
  return function(arg1, arg2, arg3, arg4, arg5) {
    return fn.call(thisObj, scope1, scope2, scope3, arg1, arg2, arg3, arg4, arg5);
  }
}

I really don't want to comment above code but here the thing:

Dear Google Engineers,
while I am pretty sure you all know the meaning of apply, I wonder if you truly needed to bring such amount of code with "optimization" in mind for a language translated into something that requires functions calls all over the place even to assign a single index to an array object

No fools guys, if you see functions like this:


function native_ObjectArray__indexAssignOperator(index, value) {
  this[index] = value;
}

you may realize how much overhead exists in Dart once this is used in non Dart capable browsers.
These browsers will do, most likely, something like this:


try {
  if (-1 < $inlineArrayIndexCheck(object, i)) {
    native_ObjectArray__indexAssignOperator.call(object, i, value);
    // or object.native_ObjectArray__indexAssignOperator(i, value)
  }
} catch(e) {
  if (native_ObjectArray_get$length.call(object) <= i) {
    native_ObjectArray__setLength.call(object, i + 1);
  }
  try {
    native_ObjectArray__indexAssignOperator.call(object, i, value);
  } catch(e) {
    // oh well ...
  }
}

rather than:


object[i] = value;

Early Stage For Optimizations

This is a partial lie because premature or unnecessary optimizations are all over the place. 120 lines of binding for a core library that will be slower not only on startup but during the whole lifecycle of the program cannot solve really a thing, isn't it?

The Cost Of The Operator Overload

This is a cool feature representing other 150 lines of code so that something like this:


1 + 2; // 3

will execute most likely this:


// well not this one ...
function ADD$operator(val1, val2) {
  return (typeof(val1) == 'number' && typeof(val2) == 'number')
      ? val1 + val2
      : val1.ADD$operator(val2);
}

// but this
ADD$operator(1, 2); // 3

// with recursive calls to the function itself if ...
ADD$operator(new Number(1), new Number(2));

I am sure we all can sleep properly now that operators overload landed on the web, a feature that works nice with matrixes and vertexes as shortcut for multiplication is finally able to slow down every single addiction.
Did we really need this? Was operator overload the reason the web sucks as it is?
If so, I can't wait to see PHP moving into the same direction directly in core!

Which Problem Would Dart Solve

I am at line 397 out of 17259 and I cannot go further than this right now but I think I have seen enough.
I have heard/read about Dart aim which apparently is "to solve mobile browsers fragmentation".
Of course, mobile browsers, those already penalized by all possible non performances oriented practices, those browsers with the lower computation power ever, will basically die if there is no native Dart engine ... everything 2 up to 10 times slower for devices, specially older one, that will never see a native Dart engine in core and that for this reason will have to:

download the normal page ignoring the script application/dart
download via JavaScript the whole Dart transpiler
once loaded, grab all script nodes with type application/dart
translate each node into JavaScript through the transpiler
inject the Dart library core and inject every script

From the company that did not close the body tag in its primary page in order to have fastest startup/visualization ever, don't ya think above procedure is a bit too much for a poor Android 2.2 browser?
Bear in mind mobile browsers are already up to 100 times slower on daily web tasks than browsers present on Desktop.

Not Really What We Need Today

I keep fighting about what's truly needed on the web and I have said already surely not a new programming language ( and also ... guys you had already GWT, isn't it ? ).
I would enormously appreciate if anyone from Google will explain me why Dart was so needed and what kind of benefits can it bring today.
I can see a very long therm idea behind but still, why we all have to start from the scratch breaking everything we published and everything we know about web so far ?
Why this team of 10 or 30 developers did not help V8 one to bring StructType and ArrayType and boost up inferences in JavaScript ?
Why Dart ? What are the performances boost that V8 or WebCL will never achieve ? What is the WebCL status in Chromium ?
Where is a native CoffeeScript VM if syntax was the problem ?
... and many more questions ... thanks for your patience.

update ... I have to ask this too:
Doesn't this Dart language look like the VBScript of 2011 ?
Wasn't VBScript an Epic Fail ?

Taking The Bat-Formula To The Next Level

2011-10-09T12:45:00.005+02:00

When you wake up on Sunday morning with upside-down stomach and batcode in mind, you may realize it's time to rest a bit.


with (/*Bat*/Math) Array(16).join(
  pow(/*JOK*/E/*R*/, cos, E/*vil*/)
) + "batman";

The output is the same produced by the original bat-formula:


'NaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNNaNbatman'

Have a nice Sunday.

A Better is_a Function for JS

2011-10-09T11:48:00.007+02:00

In 2007 I have posted about get_class and is_a functions in JavaScript in order to simulate original PHP functions.

Well ... that was crap, since a much simpler and meaningful version of the is_a function can be easily summarized like this:


var is_a = function () {
  function verify(what) {
    // implicit objet representation
    // the way to test primitives too
    return this instanceof what;
  }
  return function is_a(who, what) {
    // only undefined and null
    // return always false
    return who == null ?
      false :
      verify.call(who, what)
    ;
  };
}();

... or even smaller with explicit cast ...


function is_a(who, what) {
  // only undefined and null
  // return always false
  return who == null ?
    false :
    Object(who) instanceof what
  ;
}

An "even smaller" alternative via @kentaromiura


function is_a(who, what) {
  return who != null && Object(who) instanceof what;
}

Here a usage example:


alert([
  is_a(false, Boolean),   // true
  is_a("", String),       // true
  is_a(123, Number),      // true
  is_a(/r/, RegExp),      // true
  is_a([], Array),        // true
  is_a(null, Object),     // false
  is_a(undefined, Object) // false
]);

As twitted few minutes ago, an alternative would be to pollute the Object.prototype:


Object.defineProperty(Object.prototype, "is_a", {
  value: function (constructor) {
    return this instanceof constructor;
  }
});

// (123).is_a(Number); // true

However, this way would not scale with null and undefined so that per each test we need to check them and this is boring.
Finally, I would not worry about cross frame variables since via postMessage everything has to be serialized and unserialized.

implicit require in node.js

2011-10-06T11:36:00.004+02:00

playing with Harmony Proxy I came out with a simple snippet:

The aim of above snippet is to forget the usage of require ... here some example:


module.sys.puts("Hello implicit require");

var fs = module.fs;
fs.stat( ... );

It's compatible with nested namespaces too and if there are non JS chars in the middle ... well:

var Proxy = module["node-proxy"];

bind, apply, and call trap

2011-10-05T12:27:00.003+02:00

quick one out of ECMAScript ml


var
    // used to trap function calls via bind
    invoke = Function.call,
    // normal use cases
    bind = invoke.bind(invoke.bind),
    apply = bind(invoke, invoke.apply),
    call = bind(invoke, invoke)
;

What Is It

This is a way to trap native functions method in a handy way. Used in a private scope, it can address these methods once so that we can rely nobody can possibly change them out there for some script injection and only if we are sure the script has been loaded at the very beginning.

How To Use Them

Here few examples:


// secure hasOwnProperty
var hasOwnProperty = bind(invoke, {}.hasOwnProperty);
// later on
hasOwnProperty({key:1}, "key"); // true
hasOwnProperty({}, "key");  // false

// direct slice
var slice = bind(invoke, [].slice);
slice([1,2,3], 1); // 2,3
slice(arguments); // array

// direct call
call([].slice, [1,2,3], 1); // 2,3
// direct apply
apply([].slice, [1,2,3], [1]); // 2,3

// bound method
var o = {name:"WebReflection"};
o.getName = bind(
    // the generic method
    function () {
        return this.name;
    },
    // the object
    o
);
o.getName(); // WebReflection

That's pretty much it, except if we don't trust native Function.prototype, we should not trust anything else as well so maybe it's good to use these shortcuts just because they are handy ;)

Dear Brendan, Here Was My Question

2011-10-03T09:17:00.010+02:00

I had the honor to personally shake the hand of the man that created my favorite programming language: Brendan Eich!

I also dared to ask him a question about ES6 and I would like to better explain the reason of that question.

I have 99 problems in JS, syntax ain't one

I don't know who said that but I completely agree with him.
Here the thing: one of the main ES6 aim is to bring new, non breaking, shimmable, native constructors such StructType, ArrayType, and ParallelsArray.
We have all seen a demo during Brendan presentation and this demo was stunning: an improvement from 3~7 to 40~60 Frames Per Second over a medium complex particles animation based, I believe, on WebGL.

These new native constructors are indeed able to simplify the JS engine job being well defined, known, and "compilable" runtime in order to reach similar C/C++ performances.

These new constructors can also deal directly behind the scene, without repeated and redundant "boxing/unboxing" or conversion, with canvas, I hope both 2d and 3D, and images.

All of this without needing WebCL in the middle and this is both great and needed in JS: give us more raw speed so we can do even more with the current JS we all know!

Not Only Performances

The harmony/ES6 aim is also to enrich the current JavaScript with many new things such bock scopes, let, yeld, destructured and any sort of new syntax sugar we can imagine.
It is also planning to bring a whole new syntax for JavaScript so that the one we known won't be recognizable anymore.

I Have Been There Already

I am Certified ActionScript 2.0 Developer and back at that time, Adobe bought Macromedia and before Macromedia changed the ActionScript language 3 times in 3 years and a half: insane!!!
The best part of it is that everything that was new and not compatible anymore with ActionScript 1, syntax speaking, was possible already before and with exactly same performances: the SWF generator was creating AS1.0 compatible bytecode out of AS2.0 syntax

AS 2.0 was just sugar on top indeed but it was not enough: in order to piss off even more the already frustrated community, ActionScript changed again into something Javaish ... at least this time performances were slightly better thanks to better engine capable to use types in a convenient way.

It must be said that at that time JIT compilers and all ultra powerful/engineered tricks included in every modern JavaScript engine were not considered, possible, implemented ... "change the language is the solution" ... yeah, sure ...

Rather than bring the unbelievable performances boost that V8 Engine, as example, brought to JavaScript in 2007, performances boost that keep improving since that time and almost in every engine, they simply changed the whole nature of the language breaking experience, libraries, legacy, and everything that has been done until that time: this was the Macromedia option, the one that failed by itself and has been acquired, indeed, by the bigger Adobe.

Back in these days, the ActionScript 3.0 community is simply renewed and happy ... now, try to imagine if tomorrow Adobe will announce that ActionScript 4 will be like F#, a completely different new syntax, that most likely won't bring much more performances, neither concrete/real benefits for the community or their end users.

Is this really the way to go? Break potentially everything for the sake of making happy some developer convinced that -> is more explicit or semantic than function ?

CoffeeScript If You Want

As somebody wrote about W3C, why even waste time rather than focus on what is truly needed ?
Didn't CoffeeScript or GWT teach us that if you want a language that is not JavaScript you can create your own syntax and if the community is happy it will adopt the "transformer" in their projects ?
Didn't JavaScript demonstrate already that its flexibility is so great that almost everything can be recompiled into it ?
Emscripten is another example: legacy C/C++ code recompiled out of its LLVM into JavaScript ... how freaking great must be this "JavaScript toy" to be capable of all of this ?
We all know now how to create our own syntax manager, and many developers are using CoffeeScript already and they are happy ... do they need ES6 sugar? No, they can use CoffeeScript, isn't it? Moreover ...
The day ES6 will be CoffeeScriptish the CofeeScript project itself will probably die since it won't make sense anymore.
The day ES6 will be CoffeeScriptish all our experience, everything written about JS so far, all freaking cool projects created, consolidated, and used for such long time demonstrating these are simply "that good" won't be recyclable anymore.
Also, how should we suppose to integrate for cross browser compatibility, the new JS for cooler browsers, and the old one for "not that cool yet" browser?

Continuous Integration

SCRUM teaches us that sprints should be well planned and tasks should be split down in smaller tasks if one of them is too big.
What I see too big here is an ECMAScript milestone 6 which aim is to include:

the performances oriented constructors, the only thing truly needed by this community now
the block scoped let, generators, destructured stuff + for/of and pseudo JS friendly sugar that can be implemented without problems in CoffeeScript
the class statement, over a prototypal language we all love, plus all possible sugar and shortcuts for the function word, once again stuff already possible today but if truly needed, replicable via CoffeeScript

Is it really not posible to go ES 5.3 and bring what's needed with as much focus as possible on what's needed so that the community can be happy as soon as possible and think about what's not really needed after?

Wouldn't this accelerate the process ?

As Summary

Mr Eich, it's your baby, and I am pretty sure you don't need me to feel proud of it. It's a great programming language a bit out of common schemas/patterns but able to survive for years revolutionizing the World Wide Web.
It's also something "everything can fallback into" and I would rather create a Firefox extension able to bring CoffeeScript runtime in every surfed page as long as we can have intermediate releases of these engines, bringing one step a time all these cool features but prioritizing them accordingly with what is missing.

I thank you again for your answer, which summary is: "we are already experimenting and bringing these features in SpiderMonkey ..." and this is great but we are talking about meetings, decisions, and time in the meanwhile to agree about everything else too, specially new syntax.

I am pretty sure that following one step a time we can already have a Christmas present here since I don't see how StructType and ArrayType can be problematic to implement, and eventually optimize later, in every single engine.

These constructors should be finalized in some intermediate specification of the ECMAScript language, so that everybody can commit to it, and every single body would be gradually happier about JavaScript each half year.

In 2013 most likely new powerful CPU/GPU will be able to handle heavy stuff we are trying to handle now ... so it's now that we would like to be faster and it's now that we need these constructors.

I have also shimmed down these constructors already so that incremental browsers upgrades will make these shims useless but performances will be increased whenever these are applied ... a simple example:


var Float32Array = Array, // better shimmed
    Int32Array = Float32Array
    ....

I use similar code already and on daily basis: it does not hurt much, it works today everywhere, and it goes full speed where those constructors are available.

A whole new syntax incompatible with current specifications could be good and evil at the same time plus it will take ages before every engine can be compatible with it ... we all know the story here.

I am pretty sure I am saying nothing new here and I do hope that Harmony will bring proper harmony between what we have now, what we need now, and what we would like to have tomorrow, using projects like CoffeeScript if we really can't cope, today, with this beautiful unicorn.

Thank you for your patience

Me At JSConf.EU 2011

2011-10-02T11:53:00.006+02:00

About my JSConf.EU Talk.

Here my JSConf EU 2011 Slides, and here again the speaker rate (only if you have seen the talk, pls).

update I forgot to mention lazy features detection oject proposal!

Thanks everybody, it has been a great week end :)

RIA VS OS

2011-09-28T20:14:00.008+02:00

... have you ever thought about it ? I did few times in my 11+ years of RIA centric career!
Even if it's like comparing potatoes with tomatoes I'd like to share my thoughts about it, would you mind ?

What we always laughed about OS

the blue/gray screen with an incomprehensible error message

the Message Box with some rant about some memory address failure

the unresponsive OS due some broken application able to make everything else stuck regardless the number of CPU and thread the OS can handle

the "quit program" explicit action that does not quit the program

any sort of security issue

the change/update that requires a system reboot

What we are always "scared about" online

the white screen due some JS/CSS failure for the current browser

the forgotten alert or console.log inside some try catch with some rant about generic error message (or even worst, the unmanaged error)

the unresponsive DOM/web page due some broken piece of JavaScript able to make everything else stuck regardless the number of CPU and WebWorkers the Browser can handle

the "close window/tab" explicit action that takes ages due some greedy onunload operation

any sort of security issue

the change/update that requires a page reload

We are all in the same field

Architecture matters, experience matters, performances matter, investigations matter, code quality matter, unit tests matter, UX is essential, and UI only attractive.
This is the software development world, no matters which language, no matters which customer, no matters which company ... isn't it? So why things keep being the same in every software field ?

Delivery, delivery, delivery !

The main reason many applications out there, web or not, will rarely be that good.
The scrum purpose is to make theoretically well organized baby steps and the agile often utopia due constant, drastic, changes you may want to face during an already planned task while you are implementing the task itself.
The time ? The worst enemy when it comes to quality. As I wrote in September 2009 we are loosing software quality due temporary solutions that last forever, decisions made without real world use cases to consider and everything else web developers are complaining, as example, about W3C decisions.
Is W3C that bad ? I think it's great, and I think we should all appreciate the Open Source effort we can read, support, or comment, on daily basis as is for JavaScript future if you are tough enough to face people proud by default about their decisions ... they can understand, they can change their mind.

The direction ?

Too much new stuff in too short time that could imply future problems when it comes to maintainability and backward compatibility, the day somebody will realize: "something went terribly wrong here!"
The legacy code that blocks improvements, the country or corporates stuck behind old, deprecated, un-secure, old pseudo standard that are causing them more damage than saving.
Is everything going to produce cheap with screwed up quality? Well, this is apparently the tendency about clothes, cars, and something I always wondered about: if your Master/Phd is from the most expensive and qualified institute in this world, how would you feel to work underpaid in some emerging country able to provide everything you have been instructed for in 1/10 of your salary and with much higher units per months ?
Either that institute won't be worth it anymore, or you gonna feel like everything you learned did not really make sense.
This is a potential side effect of out sourcing too, the cheap alternative to a problem that many times is not truly solved, simply delegated and delivered with lower quality but respecting, most of the time, the deadline that once published will make max 70% of customers happy, loosing 30% until they'll face same problems with next "brand" they decide to follow.

Dedicated to

All those persons out there that do their best in daily basis believing in their job, whatever it is.
All those persons underpaid still able to put best effort and provide results regardless the country/economy situation.
All those workers that would like to have more time to do things better, and all those Open Sources/Standards Maker that should be more distant from this frenetic delivery concept, and a bit more focused on doing things properly and able to last much longer ... we would not need so many changes, software speaking, if things were already great and this is what I have always tried to do with all my old projects, often forgotten, still working after 5 or more years of untouched code, and under newer versions of the same programming language.
I had more time back at that time, and things are still working.
I am missing products like the original Vespa, out of Italian company that can still run in your city street and with 30 years on its shoulder: can your cheap scooter, software, architectural decision, do the same?

About Me At JSConf EU

2011-09-26T19:22:00.007+02:00

~~I know I am not in the list of speakers page yet, but I am actually in the official schedule already.~~

It's about jsconf.eu and my talk on Sunday morning at 10:45 entitled ...

Buzz It For Real !

... the tortuous road to Mobile HTML5 Apps

For the very first time in my life I will not represent just myself during a conference. This time I will talk about few ideas, problems, and solutions, we have faced during the "still in beta" development of our Mobile HTML5 Applications.

I will talk about some problem completely ignored by majority of HTML5 developers providing concrete real-world examples, and solutions, over tested code.

I know Sunday comes after the first conference party and I hope you, as well as me, won't be too drunk to follow my talk :D

Of course a SpeakerRate page was a must have so see you there and enjoy the conference!

An Introduction to JS-Ctypes

2011-09-17T08:04:00.008+02:00

Update

If you have time follow the whole story in es-discuss mailing list while if you don't have time here the quick summary:
js-ctypes purpose is different from JS.next typed structs/arrays so it looks like it was my mistake to compare tomatoes and potatoes.
I bet everybody else in this world could have compared these two different beasts due identical name, look, and similar usage.
If ctypes are not used outside JS these are not JIT optimized in any case so now we know why performances are so slow compared with JS code.

On new Struct({literal:pairs}) VS new Struct(literal = pairs) there is still no answer and even if it's obviously possible to avoid an object creation per each created instance, recycling a single object and refreshing its properties same as we could do with properties descriptors and Object.defineProperty I have pointed this out in that way on purpose since I can already see a massive usage of that unoptimized pattern and I would like to know that engines are able to optimize that pattern Just In Time or tracing it.

More questions, "flames", and answers about this topic in the link I have already posted at the very beginning.

A few days ago I had a quick chat with Ben Green about statically defined JavaScript structs.
He reminded me "somebody wrote something about faster JS objects" and I remember I saw it as well but I could not find the bloody source until I crashed again into Brendan Eich blog, more specifically the My TXJS talk post.

JavaScript Binary Data

The slide I am talking about is at page 14:


const // the statically defined and typed structs
         Point2D = new StructType({x:uint32, y:uint32}),
         Color = new StructType({g:uint8, g:uint8, b:uint8}),
         Pixel = new StructType({point: Point2D, color: Color}),
         // the static collection
         Triangle = new ArrayType(Pixel, 3);

new Triangle([
    {point: {x:0, y:0}, color: {r:0, g:0, b:0}},
    {point: {x:5, y:5}, color: {r:10, g:10, b:10}},
    {point: {x:10, y:0}, color: {r:20, g:20, b:20}}
]);

"Mind Blown!" as first reaction, then I decided to investigate a bit more during the evening in order to bring some better feedback and have a better understanding of this concept ... but how did I do that?

js-ctypes and Mozilla

Even if landed and approved only recently in JS.next, ctypes have been available in Firefox since version 4.
I like the fact Mozilla keeps surprising me as one of the most advanced environment when it comes to JavaScript world but before getting too excited, we'd better keep reading this post.

The (ideal) Purpose

Dave Mandelin in Know Your Engines slides enlightened us describing how things get faster behind the interpreted JavaScript scene. As scripting language developers we would like to do not care at all about details such "do not change variables type" but as I have asked during falsy values conference: "what about objects and their properties?"
JS-Ctypes seem to be the "ideal kick asses performances" trick we all were waiting for: an explicit, yet scriptish, way to describe well known structures in order to make the engine able to optimize and compile these structures runtime and boost up performances.
This concept is not new at all in programming world.

Cython

From Wikipedia:

Cython is a programming language to simplify writing C and C++ extension modules for the CPython Python runtime. Strictly speaking, Cython syntax is a superset of Python syntax additionally supporting:
- Direct calling of C functions, or C++ functions/methods, from Cython code.
- Strong typing of Cython variables, classes, and class attributes as C types.
Cython compiles to C or C++ code rather than Python, and the result is used as a Python Extension Module or as a stand-alone application embedding the CPython runtime

I do believe it comes natural to compare js-ctypes to Cython and I am pretty sure initially this was the exact purpose of the Mozilla extension or, at least, Mozilla folks idea.
Ironically this is the same reason js-ctypes are not available by default in Firefox and others except via extensions.


// if not in an extension, deprecated but
// the only way to bring js-ctypes inline in a web page
netscape.security.PrivilegeManager.enablePrivilege('UniversalXPConnect');

// import ctypes
Components.utils.import("resource://gre/modules/ctypes.jsm");

Bear in mind above code will not work online. In order to test ctypes in Firefox we need to accept privileges risks offline ( file://ctypes.test.html ).
The reason is simple: rather than decouple the power of ctypes from the ability to use compiled libraries or dll, Mozilla put everything into a single module making its usage basically pointless/impossible for Web applications: big mistake!

A Reasonable Shim

It's about 3 years or more I am writing examples and proposals in this blog about "strict typed JavaScript" but this is not the case.
If we want to shim in a good way js-ctypes we should actually forget the type part or performances will be extremely compromised per each bloody created object.
Unit test speaking, once we are sure that Firefox runs all our cases, we'd better trust nothing bad will happen in all shimmed browsers.


try {
    netscape.security.PrivilegeManager.enablePrivilege('UniversalXPConnect');
    Components.utils.import("resource://gre/modules/ctypes.jsm");
} catch(ctypes) {
    // a minimal ctypes shim by WebReflection
    this.ctypes = {
        ArrayType: function ArrayType(constructor, length) {
            var name = (constructor.name || "anonymous") + "Array";
            return Function("c", "".concat(
                "return function ", name, "(o){",
                    "var i=(o||[]).length;",
                    length ? "if(i!=" + length + ")throw 'wrong length';" : "",
                    "if(!(this instanceof ", name, "))",
                        "return new ", name, "(o);",
                    "this.length=i;",
                    "while(i--)",
                        "this[i]=new c(o[i]);",
                "};"
            ))(constructor);
        },
        StructType: function StructType(name, fields) {
            for (var key, current, proto = {}, init = [], i = 0; i < fields.length; ++i) {
                current = fields[i];
                for (key in current) {
                    if (current.hasOwnProperty(key)) {
                        init.push("this['" + key + "']=o['" + key + "']");
                        proto[key] = null;
                    }
                }
            }
            return Function("p", "".concat(
                "function ", name, "(o){",
                    "if(!(this instanceof ", name, "))",
                        "return new ", name, "(o);",
                    init.join(";"),
                "}",
                name, ".prototype=p;",
                "return ", name
            ))(proto);
        }
    };
}

To make things even faster, I have adopted an "inline compiled JS" technique so that each defined struct will do most basic tasks per each instance creation.
Following an example about js-ctypes usage:

// as is for native cnstructor, no need to "new"
const Point2D = ctypes.StructType(
    "Point2D",  // the struct name
    [           // the struct description
        {x: ctypes.int},
        {y: ctypes.int}
    ]
);
        
// a struct can be used to define a collection of same type
const Segment2D = ctypes.ArrayType(
    Point2D,    // the value type
    2           // the length
);

// if length is specified, this must match during construction
        
// if no length is specified any amount of elements can be created
const Line2D = ctypes.ArrayType(Segment2D);
        
// no need to invoke all constructors
// as long as the Array/Object structure
// matches the defined one
var line = Line2D([
    [
        {x: 0, y: 0},
        {x: 10, y: 10}
    ], [
        {x: 10, y: 10},
        {x: 20, y: 20}
    ], [
        {x: 20, y: 20},
        {x: 30, y: 30}
    ]
]);

Even if geometrically speaking above example does not make much sense, being a line by definition represented by infinite number of points, I am pretty sure you got the logic.

Still NOT JS.next

The struct definition is slightly different from the one shown by Brendan Eich but at least the ArrayType signature seems to be similar.
If what Brendan showed is actually true, we will not have a way to define statically typed getters and setters.
Not that a function per each get/set can improve performances, but I consider this a sort of limit over other statically typed programming languages.

10X Slower

Surpriiiiiiiiiiiseeeeeee!!! Even Firefox Nightly performs like a turtle on steroids over statically typed collections and here the test you should save in your desktop and launch via file protocol.
If you see the alert, ctypes have not been loaded ... but if you test in on Firefox via file protocol and you allow the module, you will not see any alert but an actual benchmark of three different types of collections:

a generic Array of Objects
a typed collection of typed objects
an Int32Array implementation over int values with an object creation per each loop iteraction

I don't know what's your score ( and I could not manage to test it via jsperf ) but at least in my MacBookPro numbers are 110ms for ctypes VS 19 or 16 for other two tests.

What The Fuck Is Going On

Pardon my french but I could not describe in a better way my reaction ... however, I have an idea of what's happening there ...

Slow Binding

If ctypes are checking and transforming runtime all values in order to provide nicely written Errors somebody screwed up the speed boost idea here. I would rather prefer to see my browser implode, my system crash, my MacBook explode than thinking every single bloody object creation is actually slower than non statically defined one!
"check all properties, check all types, convert them into C compatible structs, bring them back to JS world per each index access" ... I mean, this cannot be the way to make things faster.
The operation could surely be more expensive in therms of Struct and List definitions but for fuck sake these cannot be trapped behind the scene: these must be instantly available as hidden pre compiled/pre optimized objects and if some assignment goes wrong just exit the whole thing!

Static Is Not For Everybody

Let "week end hobbyists" use JS as they know but give JS the native power of C. Don't try to save poor JS kids/developers here, you either bring this power in or you don't.
Any application that will screw an assignment over a statically typed collection or struct does not deserve a place in the web, as well as any sort of broken C code cannot be compiled or it will kill the execution if something goes wrong runtime.

I am not joking here, think about those developers that actually know what they are doing and forget for once the "too easy to use" concept: we all desire to handle statically typed code via JS and we expect a massive performances boost.

Double Memory Consumption

The typed part of JavaScript seems to ignore a little detail: every object will require both non statically typed structure, {x: Number, y: Number} plus its statically typed equivalent: Point2D.
I am not sure engines can optimize that much here and thinking about mobile platforms I wonder if TC39 team is actually thinking "Desktop only" ... WebCL seems, once again, a much better alternative than ctypes here 'cause if all these operations will mean higher memory footprint and slower interaction we are in a no-go specification that should never land in JS world.
We really can implement by ourself strict type checks so either ctypes bring something powerful and fast or I can see already a lot of effort, implementation speaking, for zero income, real use cases speaking.


const Point2D = ctypes.StructType(
    "Point2D",  // the struct name
    [           // the struct description
        {x: ctypes.int},
        {y: ctypes.int}
    ]
);

// how it is now in ES.next too
var p = new Point2D(
    {x: 123, y: 123} // why on earth!
);

// how it should be in ES.next
var p = new Point2D(
    // no object dependeny/creation
    x=123,
    y=123
);

Above example is just one out of millions way to better initialize a statically typed structures. Since JS.next will bring new sugar in any case, unless these objects used to initialize a structure will be completely ignored/discarded runtime, creating holes in therms of object reusability, the creation of a complementary object per each static instance is a non-sense.
In few words, no need to overcomplicate engines when these will be already compatible with named defaults function arguments, isn't it?

As Summary

C could land into JavaScript but it must be done properly. A too hybrid solution could bring double problems and all I have tried to do in this post is collaborate with the initiative bringing thoughts and tests.
I hope this part will be specified and implemented properly, removing the "native dll binding" we don't need on te web, neither we do for node.js modules.
Sure it's a nice have, but once we can write proper modules based on statically typed structs and collections, there won't be such big need of pre-compiled C stuff and all cross platform problems at that point will be solved on browser engine level, rather than on JS specific C module side.
Any sort of thoughts and/or clarification will be more than appreciated but right now all I can say is: avoid this extension, don't try to screw with native system libraries, don't use this extension thinking it will bring more efficient, fast, powerful, code into your app.
Thanks for your patience

My New Programming Language

2011-09-10T10:03:00.023+02:00

yeah, you read it correctly ... we all need another better programming language because everything we've done until now sucks.

What Sucks

the fact we don't learn by mistakes, which means all of us should instantly try to create a new "secretly open source programming language" so that the rest of the world can only endure it once it's out, rather than contribute to make it better/needed as it's happening since at least 5 years with JavaScript in all possible, and truly open, channels

the fact Java, .NET, and all others failed ... 'cause we are still looking for a new programming language in these days where C++ X11 has been approved while C never died

the fact we keep thinking that performances are possible only with compiled languages forgetting that better algorithms, better practices, better tools to develop and track leaks, memory consumptions, CPU/GPU cycles, can make any software fast enough or ...

... the fact new standards are coming to help us with performances, as is for OpenCL, and new techniques are already available to speed up common tasks, as is for Statically Typed Collections

the fact we are blaming JavaScript because is the most used programming language and as is for "the most used whatever thing" out there more people will complain about it and even more people will enjoy it ( e.g. the unbelievable growing speed of node.js community and all latest server side JS related projects )

the fact if a programming language is part of the scripting group it's considered a toy regardless the fact any sort of application out of billions is working right now out there without major security, performances, or design problems

the fact that compiled programming language developers are not necessarily superior or more skilled than scripters ... the world of Software would be perfect otherwise and the Web as we know it, the good one, would not exist

the fact that if a programming language is appreciated and used by senior professionals as well as week end hobbyist must mean that language is weak and it needs to be substituted

the fact that experience is a key, and with a new language it will be completely lost and all sort of inevitable problems or solutions will not be instantly available to the community

the fact that if it's possible to translate this new fantastic language into JavaScript for backward compatibility, everything new this language will bring tomorrow was already possible today

As Summary

Looking forward for the revolution and looking forward to forget that OpenCL even existed.
Let's hope at least all Operating Systems companies will agree, let's hope it will be the universal language we have been dreaming about since ever ... let's hope ... and sorry for this surely not needed rant.

Update A must read post from BrendanEich who is apparently sharing my point of view with more technical reasons.
Alex Russel also on Google & the Future of JavaScript gives us something more about what's going on there, nice one.

OS X Lion Automator And Mobile NOKIA Maps

2011-08-27T11:38:00.005+02:00

When I have read this article about Making Desktop Webapps in Lion my first thought was "cool!" instantly followed by "what about an experiment with Mobile NOKIA Maps WebApp?" ... and here I come :)

m.maps.nokia.com

is the beta project I am working on right now together with a bounce of HTML5 geeks :P in order to bring the mature NOKIA Maps experience on Android 2.2+, iOS4+, and others already supported or "coming soon" devices.
Optimized for mobile but still usable with Desktop Chrome or Safari browser, the web app is quite "cute" seen in iPhone or other medium and small screens and this experiment was about bringing same "cuteness" on my Mac Mini as well: partially successful!

Lion Automator And WebPopup Limits

Unfortunately it is not possible to customize that much the popup browser user agent and I am not even sure what kind of engine is used there ...
With iPhone UserAgent the version exposed is 3 and Webkit 430+.
When it comes to iPad UserAgent the version is 4 while with Safari UA the version is the current one.
GeoLocation API does not seem to work, and the cache seems to be cleaned every time the app is closed.
Unfortunately these limits make the current beta less cool than usual, specially because every time the app is closed the storage seems to be reset which means last position is not shown next time, history and suggestions do not show off and even more annoying the routing "home to place" is not available due missing location.

Grab The Desktop App For OSX Lion

I have prepared everything you need to launch m.maps.nokia.com in your OSX Lion so you can give it a try.

Mobile NOKIA Maps For Automator and if necessary extract its content and click on the .app file.

I swear I did nothing different from what Andy Ihnatko described in its article, except changing the icon with the one downloaded automatically on iPad if you pin the website to your home screen.

If you are in OSX Lion give it a try and play around but bear in mind this beta offers much more on your smartphone ;)

Simulate Script Injection Via Data URI

2011-08-24T20:35:00.004+02:00

Well, not only downloads on the fly, the data uri works for almost everything ( only iOS 5 beta does not want to work with inline data uri AUDIO sources .... but this is another story ... ) ... so ...

How To Simulate Script injection

Let's say you want a test but you don't want to bother a server. However, you want to be sure the test is asynchronous and it simulates the server.


var

    head = document.getElementsByTagName("head")[0],

    script = document.createElement("script")

;

head.insertBefore(script, head.lastChild);

script.src = "data:text/javascript;base64," + btoa(

    "alert('Hello World')"

);

How To Simulate JSONP

Same trick, isn't it? ... except:


script.src = "data:text/javascript;base64," + btoa(

    "callback(" + JSON.stringify(dummyData) + ")"

);

How To Drop Server Requests

well, this is the tricky one ...

Surely there is some job to do in the createResponse() function but ... hey, we can stop bothering servers now ;)

wru, unit tests have ever been that easy

2011-08-21T19:34:00.003+02:00

Do you remember my good old wru project? It has been refactored, readapted for both client and server side environment such node.js and Rhino and, most important, it landed in github ;)

Please spend few minutes to read the documentation and you'll realize why I chose this title for this post.

Have fun with JavaScript Unit Tests!

Overloading the in operator

2011-08-20T10:39:00.007+02:00

In all its "sillyness", the CoffeeShit project gave me a hint about the possibilities of an overloaded in operator.

The Cross Language Ambiguity

In JavaScript, the in operator checks if a property is present where the property is the name rather than its value.


"name" in {name:"WebReflection"}; // true

However, I bet at least once in our JS programming life we have done something like this, expecting a true rather than false.


4 in [3, 4, 5]; // false

// Array [3, 4, 5] has no *index* 4

The Python Way

In Python, as example, last operation is perfectly valid!


"b" in ("a", "b", "c") #True

4 in [3, 4, 5]         # True

The behavior of Python in operator is indeed more friendly in certain situations.

value in VS value.in()

What if we pollute the Object.prototype with an in method that is not enumerable and sealed? No for/in loops problems, neither cross browsers issues since if it's possible in our target environment, we do it, otherwise we don't do it ... a fair compromise?

Rules

if the target object is an Array, check if value is contained in the Array ( equivalent of -1 < target.indexOf(value) )

if the target object is an Object, check if value is contained in one of its properties ( equivalent of for/in { if(object[key] === value) return true; } ).
I don't think nested objects should be checked as well and right now these are not ( same as native Array#indexOf ... if it's an array of arrays internal arrays values are ignored and that's how it should be for consistency reason )

if the target object is a typeof "string", check if value is a subset of the target ( equivalent of -1 < target.indexOf(value) ).
The Python logic on empty string is preserved since in JavaScript "whateverStringEvenEmpty".indexOf("") is always 0

if the target property is a typeof "number", check if value is a divisor of the target ( as example, (3).in(15) === true since 15 can be divided by 3)

I didn't came out with other "sugarish cases" but feel free to propose some.

Compatibility

The "curious fact" is that in ES5 there is no restrictions on an IdentifierName.
This is indeed different from an Identifier, where in latter ReservedWord is not allowed.
"... bla, bla bla ..." ... right, the human friendly version of what I've just said is that obj.in, obj.class, obj.for etc etc are all accepted identifiers names.
Accordingly, to understand if the current browser is ES5 specs compliant we could do something like this:


try {

    var ES5 = !!Function("[].try");

} catch(ES5) {

    ES5 = !ES5;

}



alert(ES5); // true or false

Back in topic, IE9 and updated Chrome, Firefox, Webkit, or Safari are all compatible with this syntax.

New Possibilities

Do you like Ruby syntax?


// Ruby like instances creation (safe version)

Function.prototype.new = function (

    anonymous, // recycled function

    instance,  // created instance

    result     // did you know if you

               // use "new function"

               // and "function" returns

               // an object the created

               // instance is lost

               // and RAM/CPU polluted

               // for no reason?

               // don't "new" if not necessary!

) {

    return function factory() {

        

        // assign prototype

        anonymous.prototype = this.prototype;

        

        // create the instance inheriting prototype

        instance = new anonymous;

        

        // call the constructor

        result = this.apply(instance, arguments);

        

        // if constructor returned an object

        return typeof result == "object" ?

            // return it or return instance

            // if result is null

            result || instance

            :

            // return instance

            // in all other cases

            instance

        ;

    };

}(function(){});



// example

function Person(name) {

    this.name = name;

}



var me = Person.new("WebReflection");

alert([

    me instanceof Person,       // true

    me.name === "WebReflection" // true

].join("\n"));

Details on bad usage of new a part, this is actually how I would use this method to boost up performances.


// Ruby like instances creation (fast version)

Function.prototype.new = function (anonymous, instance) {

    return function factory() {

        anonymous.prototype = this.prototype;

        instance = new anonymous;

        this.apply(instance, arguments);

        return instance;

    };

}(function(){});

cool?

Do Not Pollute Native Prototypes

It does not matter how cool and "how much it makes sense", it is always considered a bad practices to pollute global, native, constructors prototypes.
However, since in ES5 we have new possibilities, I would say that if everybody agrees on some specific case ... why not?
for/in loops can now be safe and some ReservedWord can be the most semantic name to represent a procedure as demonstrated in this post.
Another quick example?


// after Function.prototype.new

// after Person function declaration

Object.defineProperty(Object.prototype, "class", {

    enumerable: !1,

    configurable: !1,

    get: function () {

        return this.__proto__.constructor;

    }

});



var me = Person.new("WebReflection");



// create instance out of an instance

var you = me.class.new("Developer");



alert([

    you instanceof Person,   // true

    you.name === "Developer" // true

].join("\n"));

I can already see Prototype3000 farmework coming out with all these magic tricks in place :D
Have fun with ES5 ;)

CoffeeShit, The CoffeeScript Parody

2011-08-19T17:53:00.005+02:00

    ... because script happens!

This silly project does not want to offend the CoffeeScript creator neither any CoffeeScript user, hoping both have sense of humor :D

About

Every cult movie has one or more parodies ... well, every cult technology as well (or at least it should)!
This idiotic project is on github with a better explanation, a suite of unit tests, and both source code and the partially manually minified one ( manually because I have discovered a nice bug with closure compiler and eval there ... )

About The Name

You can check the library by yourself and realize I have used all worst possible practices in order to simulate a different syntax within the one allowed by JavaScript.
Such pile of shit I wrote to mimic an excellent project as CoffeeScript is could not have a better name, imo.
If you feel insulted by this idiotic experiment please let me know and I'll do my best to let people try it under a different name.

Example


// CoffeeScript

square = (x) -> x * x

fill = (container, liquid = "coffee") ->

    "Filling the #{container} with #{liquid}..."

mood = greatlyImproved if singing

eat food for food in ['toast', 'cheese', 'wine']

winner = yes if pick in [47, 92, 13]

speed ?= 75



// CoffeeShit

square = 'x'['->']('x * x')

fill = ['container', 'liquid = "coffee"']['->'](

    'Filling the #{container} with #{liquid}...'

)

mood = greatlyImproved.if(singing)

'eat(food)'.for('food').in(['toast', 'cheese', 'wine'])

winner = yes.if(pick.in([47, 92, 13]))

'speed'['?='](75)

Many more in the landing page, even more inside unit tests file.

As Summary

I really could not resist :D
This post aim is to let you write some comment, have fun with CoffeeShit!

HTML5: How To Create Downloads On The Fly

2011-08-18T15:10:00.009+02:00

this is a quick one I have implemented already in fuckn.es in the create angry memory button logic ...

The New Download Attribute

Hopefully soon, most updated browser will implement the download attribute in hypertext links (aka: <a> tag)
The quick summary is this one:

The download attribute, if present, indicates that the author intends the hyperlink to be used for downloading a resource. The attribute may have a value; the value, if any, specifies the default filename that the author recommends for use in labeling the resource in a local file system.

And this is a basic example:


click here to

<a

    href="resource234.txt"

    download="license.txt"

>

    download the license

</a>

What Is Download For

Well, I am pretty sure you have read at least once in your life this kind of extra info beside a link:
right click to download the content and "Save As ..."
Moreover, I am pretty sure you have created at least once in your server a page able to force a generic file download.
All these instructions and server side headers/files may disappear thanks to this new attribute, also because there's no such thing as "right button" on touch screens, neither in some newer device pointer.
If the file is meant to be download, it will ... cool?

Create Downloads On The Fly Via JavaScript

When I have read about it, I have instantly realized the potentials of this attribute combined with inline data uri scheme.

Only HTML5 ?

Nope! Please note that many browsers let us already practice this technique. Some may open the file in a new blank page while some other may download directly the file as is for Chrome and the CSV example.
As graceful degradation, the "right click" procedure will still do the trick.

Downlaod Canvas As Image Example

First example is a classic one: how to save a canvas snapshot as image via "click".


// basic example

function createDownloadLink(canvas, name) {

    var a = document.createElement("a");

    a.download = name;

    a.title = "download snapshot";

    a.href = canvas.toDataURL();

    return a;

}



// some paragraph in the page

document.querySelector(

    "p.snapshot"

).appendChild(createDownloadLink(

    document.querySelector("#game"),

    "snapshot" + (-new Date) + ".png"

));

When the user will tap/click on the link, the browser will simply start the download. No server side involved at all!

Save A Page As PDF

Thanks to this technique we may use same trick to produce a PDF file out of whatever web page.


// basic example

function createPDFLink(fileName) {

    var doc = new pdf();

    // whatever content you want to download

    var a = document.createElement("a");

    a.download = fileName;

    a.title = "download as PDF";

    a.href = doc.output('datauri',{"fileName":name});

    return a;

}



// some paragraph in the page

document.querySelector(

    "p.saveaspdf"

).appendChild(createPDFLink(

    "document-" + document.title + ".pdf"

));

Of course if the page content changes we can replace the old link with a freshly new created one.

Save Table As CSV

Well, another classic here, the csv format out of a table. This is a basic but working example ;)


<script>

// really basic example

function tableToCSV(table) {

    for (var

        header = table.querySelectorAll("tr th"),

        rows = table.querySelectorAll("tr td"),

        hlength = header.length,

        length = hlength + rows.length,

        result = Array(hlength),

        i = hlength,

        j;

        i < length; ++i

    ) {

        j = i % hlength;

        j || result.push("\n");

        result.push(rows[j].innerHTML);

        ++j % hlength && result.push(",");

    }

    i = 0;

    while (i < hlength) {

        result[i] = header[i].innerHTML + (

            ++i < hlength ? "," : ""

        );

    }

    return result.join("");

}

this.onload = function () {

    var a = document.body.appendChild(

        document.createElement("a")

    );

    a.download = "table.csv";

    a.href = "data:text/csv;base64," + btoa(

        tableToCSV(document.querySelector("table"))

    );

    a.innerHTML = "download csv";

};

</script>

<table>

    <tr>

        <th>name</th>

        <th>age</th>

    </tr>

    <tr>

        <td>Dan</td>

        <td>33</td>

    </tr>

    <tr>

        <td>John</td>

        <td>32</td>

    </tr>

</table>

Most likely we can test already above example even if the name won't probably be the chosen one.
For safe base64 encode, compatible with UTF-8 pages, have a look at this script ( base64.encode() and base64.decode() ).

Compatibility

Different developers asked already about compatibility.
As I have said before, we need to differentiate between "download" attribute compatibility AND inline data uri link compatibility.
In the first case I don't know browsers that will force the download with the specified name yet, but I'll update this section as soon as I know someone.
In the latter case, IE9, Chrome, Firefox, Safari, Webkit based, and Opera seem to be already compatible.
The main problem/limit I have spotted in fuckn.es is the size of the data uri, in certain cases we may need a decent/fast machine otherwise we may end up killing RAM and CPU performances.
IE8 is compatible as well except IE8 has limited data uri for CSS images, as example, and I expect same limit for this technique.
Bear in mind when all browsers will be compatible, we will still have data stream limit problem, or better, really big files has to be parsed on the fly in one shot, no "download progress" possibility.

As Summary

... now you know ... ;)

JSONH And Hybrid JS Objects

2011-08-17T15:00:00.004+02:00

I have already described JSONH and now I also have the proof that it's as safe as native JSON is but on average 2X faster than native JSON operations with both small (10 objects), medium (100 objects), and massive (5000 objects and not a real world case, just a stress test to see how much JSONH scales) homogenous collections.
Wherever it's not faster it's just "as fast" but the best part is that it seems to be always faster on slower machines ( mobile ).
Moreover, the 5000 objects stress example shows that JSONH.stringify() produces a string with 54% of original JSON.stringify() size so here the summary: JSONH is faster on both compression and decompression plus it produces smaller output

yeah but ... what About Hybrid Objects

To start with, if you don't recognize/understand what is an homogenous collection and ask me: "what about nested objects?", all I can do is to point you out that Peter Michaux explained this years before me.
Have a look there and please come back after the "aaaaahh, got it: right!"

Hybrid Objects

Nowadays JSON is used everywhere but not everywhere with homogeneous collections. A simple example to screw up JSONH possibility is an object like this:


// result of a RESTful service, Ajax, query

// once again about generic articles: book!

var result = {

    category: "books",

    subcategory: "fantasy",

    description: [

        {

            title: "The Lord Of The Rings",

            description: "Learn about the darkness"

        }, {

            title: "The Holy Bible",

            description: "Learn about both light and darkness"

        },

        // all other results out of this list

    ]

};

If we receive an object with one or more properties containing an homogeneous collection, as is description in above example, we may already decide to use JSONH advantages.

JSONH On Hybrid Objects

It's that easy!


// before we send/store/write data on output

result.description = JSONH.pack(result.description);

print(JSON.stringify(result));

If the client is aware about the fact one or more specific property is an homogeneous collection, to obtain the original object we can do this:


// stringifiedResult as XHR responseText

var obj = JSON.parse(stringifiedResult);

obj.description = JSONH.unpack(obj.description);



// or simply via JSONP callback

data.description = JSONH.unpack(data.description);

For the same reason JSONH is faster than JSON, this operation will grant us less bandwidth to both send or receive objects, and faster conversion performances.

As Summary

I am willing to think soon about a possible schema able to describe homogeneous collections properties out of an object ... a sort of JSONH "mapper" to automate the procedure on both server side and client side and any suggestion will be more than welcome.
At least so far we know already how to adopt this solution :)

Last Version Of JSON Hpack

2011-08-16T16:00:00.007+02:00

Update

created github repository with (currently) JavaScript, PHP5 and Python versions.

Update after quick chat on twitter with @devongovett who pointed out there is a similar standard called JSONDB I have created a JSONH(Flat) version. It looks slightly faster on mobile so I may opt for this one rather than Array of keys at index 0.
The whole array is flat and it changes from [{a:"A"},{a:"B"}] to [1,"a","A","B"] where the empty collection would be [0] rather than [[]].

Also more details here on how to JSONH Hybrid JS Objects.

A while ago I proposed a homogeneous collections optimizer nick named JSON.hpack.

What I wasn't expecting is that actually different projects and developers adopted this technique to shrink down JSON size.

Basic Advantage Of JSON.hpack

Gzip and deflate work really good with repeated chunks of strings and this is why homogeneous collections have really good compression ratio there.
However, gzip and deflate compression does not come for free!
If we compress everything on server side we can easily test the CPU overload compared with uncompressed data.
Via JSON.hpack we can still serve small or huge amount of dynamic and static data without necessarily use realtime compression.

Basic Notions On Compressors

There is no ideal algorithm yet for compressed data, any of them has pros and cons.
A really good compression ratio may cost a lot and the algorithm is efficient if at least decompression is fast. 7-Zip is one example, it takes more than normal zip to create a single file, but final ratio is usually much better and decompression extremely fast.
An incremental compressor as GIF is is both fast to encode and fast to decode. However, it's average compression ratio is really poor compared with PNG, which again is not fast as GIF to encode, but almost as fast as GIF to decode and capable of bringing much more complex data inside.
On the client side we may like a truly fast compressor in order to send data to the server where more horses power can decompress in a reasonable time. Still servers have not unlimited resources.

My Latest Improvements Over JSON.hpack

On the web is all about network layer latency, completely unpredictable specially in these smartphones/pads days.
We also need to consider high traffic, if things go really well, and most important mobile platforms computation power, basically the equivalent of a Pentium 3 with a GeForce card from 2001.

Which Is The Best Compromise

The original version of JSON.hpack is able to understand which compression level is the best one for the current collection of objects. Unfortunately this is slow both on the server side and even more on the client side.
In my opinion an intermediate layer as JSON.hpack is should bring advantages as fast as possible in both client and server.
I probably failed the first time because I was more focused on coolness rather than efficiency.
As example, if it takes 3X CPU load to save 5% of bytes compared with the most basic compression ratio, something is wrong because it's simply not worth it.
As summary, the best compromise for the latest version of this compressor is to be freaking fast with small overhead and providing a good average compression ratio.

Welcome JSONH

In a single call this object is able to pack and unpack homogeneous collections faster than native JSON and specially on mobile platforms.

How Is It Possible

To be honest I have no idea and I was surprised as well. All I could think about is the fact that JSONH makes data flat which means no recursions per each object in the original list.
This seems to boost up performances while packing and make JSON.parse life easier while unpacking.
The extreme simplification of the algorithm may have helped a lot as well.

JSONH Source Code

now on github!
~~And I had no time to create the equivalent C#, PHP, and Python version~~.
In any case you can see how simple is the logic and I bet anybody can easily reproduce those couple of loops in whatever programming language it is.
The minzipped size is 323 bytes but advantages over network calls can be massive. As example, if we check the console and the converted size in the test page, we can see the JSONH version of the same collection is 54% smaller ... and for a faster stringify and parse? ... it cannot be that good, isn't it :)

JSONH Is Suitable For

any RESTful API that returns homogenous collections

gzip on the fly costs too much due high traffic

map applications and routes, [{"latitude":1.23,"longitude":5.67},{"latitude":2.23,"longitude":6.67}]
will be [["latitude","longitude"],1.23,5.67,2.23,6.67]

any other case I am not thinking about right now

As Summary

It is good to take old projects created a while ago and think what could be done better in current days. It's both about re-thinking with different skills and experience over real world cases. I am not sure I made everybody happy with this latest version but I am pretty sure I won't ask client or server side to be slower than native JSON + native gzip compression since at that point all advantages will be simply lost.
This revisited version of JSONH is surprisingly faster, smaller, and easier to implement/maintain than precedent one so ... enjoy if you need it ;)

Once Again On Script Loaders

2011-08-14T17:05:00.008+02:00

It's a long story I would like to summarize in few concrete points ...

Three Ways To Include A Script In Your Page

First of all, you may not need loaders at all.
Most likely you may need an easy to go and cross platform build process, and JSBuilder is only one of them.

The Most Common Practice

This way lets users download and visualize content first but it lets developers start the JS logic ASAP as well without mandatory need to set DOMContentLoaded or onload event.


<!doctype html>

    <head>

        <!-- head content here -->

    </head>

    <body>

        <!-- body content here -->

        <script src="app.minzipped.js">/* app here */</script>

    </body>

</html>

The "May Be Better" Practice

I keep saying that a web application that does not work without JavaScript should never be accessed by a user. As example, if a form won't submit without JavaScript what's the point to show it before it can possibly work? If your page strongly depends on JavaScript don't be afraid to let the user wait slightly more before the layout is visualized. The alternative is a broken experience as welcome. Accordingly, use the DOMContentLoaded listener over this ordered layout:


<!doctype html>

    <head>

        <!-- head content here -->

        <script src="app.minzipped.js">/* app here */</script>

    </head>

    <body>

        <!-- body content here -->

    </body>

</html>

If you don't trust the DOMContentLoaded listener you can combine both layouts:


<!doctype html>

    <head>

        <!-- head content here -->

        <script src="app.minzipped.js">/* app here */</script>

    </head>

    <body>

        <!-- body content here -->

        <script>initApp();</script>

    </body>

</html>

The Optional "defer" Attribute

We can eventually try to avoid the blocking problem using a defer attribute. However, this attribute is not yet widely supported cross browser and the result may be unexpected.
Since this attribute is basically telling the browser to do not block downloads, in the very next future it could be specified both on head script or before the end of the body.
Everything I have said about possible broken UX is still valid so ... use carefully.

The Loading Practice

Classic example is twitter on mobile browsers and any native application with a loading bootstrap screen. Also Flash based websites use this technique since ages and users are used to it.
If the amount of javascript plus CSS and assets is massive, both precedent techniques will fail.
The first one will fail because the user doesn't know when the script will be loaded plus it's blocking so the page won't respond. Bye bye user.
The second approach will result into a too long waiting time over a blank page ... bye bye user.
This loading approach will entertain the user for a little while, it will be lightweight, fast to visualize, and it can hold the user up to "5 seconds" with cleared cache ( and hopefully much less next time with cache but if more we should really think to split the logic and lazy load as much as possible ).


<!doctype html>

    <head>

        <!-- head content here -->

        <!-- most basic CSS -->

    </head>

    <body>

        <!-- most basic content -->

        <!-- "animated gif" or loader spin -->

        <script src="bigstuff.minzipped.js">/* code */</script>

        <!-- optional BIG CSS -->

    </body>

</html>

This page should be as attractive as possible and no interaction that depends on JavaScript should be shown.

Why Scripts Loaders

Because an articulated website may have articulated logic split in different files.
The main page may rely into jQuery, commonLogic, mainPageLogic.
Any sub section in the site may depend on jQuery, commonLogic, subSectionLogic, adHocSectionLogic, etc.
The build approach will fail big time here because every page will contain a different script to download in all its variants.
Moreover, thanks to CDN some library can be cached cross domain, including as example jQuery from that CDN.
In this scenario a script loader is the best solution:


$LAB

    .script("http://commoncdn.com/jquery")

    .script("commonLogic.js")

    .wait()

    .script("subSectionLogic.js")

    .wait()

    .script("adHocSectionLogic.js")

    .wait(function () {

        // eventually ready to go

        // in this section

    })

;

Above example is based on LAB.js, a widely adopted library I have actually indirectly contributed as well solving one conflict with jQuery.ready() method.

script() and wait()

LAB.js has been created with performances in mind where every script will be pre downloaded as soon as it's defined in the chained logic.
The wait() method is a sort of "JS interpretation break point" and it's really useful when a script depends on another script.
Let's say commonLogic is just a set of functions while subSectionLogic starts with a jQuery.ready(function () { ... }) call, LAB.js will ensure that latter script won't be executed until jQuery is ready ... got it?
LAB.js size once minzipped is about 2.1Kb and the best way to use it is to include LAB.js as very first script in whatever page.
AFAIK LAB.js is not yet hosted in any major CDN but I do believe that will happen soon.

Preload Compatibility

LAB.js uses different techniques to ensure both pre downloads and wait() behavior. Unfortunately some adopted fallback looks inevitably weak to me.
As example, I am not a big fun of "empty setTimeouts" solutions since these are used as workaround over unpredictable behaviors.
~~One of these behaviors is the readyState script property that on "complete" state may have or may have not already interpreted the script on "onreadystatechange" notification.~~
If we have a really slow power machine, as my netbook is, the timeout used to decide that the script has been already parsed may not be enough.
I don't want to bother you with details, I simply would like you to understand why I came out with an alternative loader.
Before I reach that point I wanna show an alternative technique to get rid of wait() calls.

Update
It looks like few setTimeout calls will be removed soon plus apparently the setTimeout I pointed out has nothing to do with wait: my bad.
In any case I don't fancy empty timers plus LAB.js logic is focused on cross browser parallel pre-downloads and for this reason a bit more bigger in size than all I needed for my purpose.

Avoiding wait() Calls

JavaScript let us successfully download and parse scripts like this without problems:


function initApplication() {

    jQuery.ready(function () {

        // whatever we need to do

    });

}

Please note that no error will be thrown even if jQuery has not been loaded yet.
The only way to have an error is to invoke the function initApplication() without jQuery library in the global scope.
In few words, we are not in Java or C# world where the compiler will argue if some namespace is accessed in any defined method and not present/included as dependency before ... we are in JavaScript, much cooler, isn't it? ;)
Accordingly, if the current page initialization is wrapped in a single function we could simply use a single wait call at the end.


$LAB // no direct jQuery calls in the global scope

    .script("http://commoncdn.com/jquery")

    .script("commonLogic.js")

    .script("subSectionLogic.js")

    .script("adHocSectionLogic.js")

    .wait(function () {

        initApplication();

    })

;

The potential wait() problem I am worried about is still there but at least in a single exit point rater than distributed through the whole loading process ... still bear with me please.

The Namespace Problem

The generic init function can be part of a namespace as well. If we have namespaces the problem is different 'cause we cannot assign my.namespace.logic.init = function () {} before my.namespace object has been defined.
In this case we either create a global function for each namespace initialization/assignment or we impose a wait() call between every included namespace based file.

yal.js - Yet Another ( JavaScript ) Loader

Update
yal.js now on github

As written in yal.js landing page I have been dealing with JS loaders for a while.
This library created a sort of "little twitter war" between me and @getify where Kyle main arguments were "why another loader?" followed by "LAB.js has better performances".

Why yal.js

It's really a tiny script that took me 1 hour tests included plus 20 minutes of refactoring in order to implement a sort of "forced preload" alternative ( which kinda works but I personally don't like and neither does Kyle ).
yal.js is just an alternative to LAB.js and we all like alternatives, don't we?
The main focus of yal.js is being as small and as cross browser as possible using KISS and YAGNI principles.

No Empty Timers Essential Script Logic

yal.js is based on script "onload" event which behavior is already defined as standard and it's widely compatible.
If not usable in some older browser, the more reliable "loaded" state of readyState property is used instead. This state comes always after the "loading" or "complete" one.
I could not trigger any crash or problem wit this approach and together with next point no need to use unpredictable timers.

Simplified Wait Logic

In the basic version of the script any wait() call will block other scripts. These won't be pre downloaded until the previous call has been completed.
However, if we consider we may not even need wait calls:


yal // no direct jQuery calls in the global scope

    .script("http://commoncdn.com/jquery")

    .script("commonLogic.js")

    .script("subSectionLogic.js")

    .script("adHocSectionLogic.js")

    .wait(function () {

        initApplication();

    })

;

yal will perform parallel downloads same way LAB.js does and, being yal just 1.5Kb smaller, performances will be slightly better on yal rather than LAB.js
Also for my bad experience with "complete" state, I feel a bit more secure with the fact that when wait() is invoked in yal.js, everything before has been surely already interpreted and executed ( but please prove me wrong if you want with a concrete example I can test online, thanks )

Just What I Need

For my random and sporadic personal projects yal.js fits all my requirements. I do not use the forced parallel downloads and I don't care. I have asked Kyle to be able to grab a subset of LAB.js getting rid of all extra features surely useful for all possible cases out there but totally unnecessary for mine. Unfortunately that would not have happened any soon so I created the simplest solution for all I personally needed.

As Summary

I am actually sorry Kyle took my little loader as a "non sense waste of time" and if that's what you think as well or if you need much more from a loader, feel free to ignore it and go happily with LAB.js
Also I am not excluding that the day LAB.js will be in any major CDN I will start using it since at that point there won't be any overhead at all and cross domain.

Finally, in this post I have tried to summarize different techniques and approaches to solve a very common problem in this RIA era, hope you appreciated.

How To JSONP A Static File

2011-08-13T09:11:00.017+02:00

Update I have discussed this object a part and I agree that the url could be used as unique id as well.
In this case the server should use the static url as unique id:


StaticJSONP.notify("http://cdn.com/static/article/id.js",{..data..});

So that on client side we can use the simplified signature:


StaticJSONP.request(

    "http://cdn.com/static/article/id.js",

    function (uid, data) {

    }

);

The callback will receive the uid in any case so that we can create a single callback and handle behaviors accordingly.
The script has been updated in order to accept 2 arguments but, if necessary, the explicit unique id is still supported.

Under the list of "incomplete and never posted stuff" I found this article which has been eventually reviewed.
I know it's "not that compact" but I really would like you to follow the reason I thought about a solution to a not so common, but quite nasty, problem.

Back in 2001, my early attempts to include callbacks remotely were based on server side runtime compilation of some JavaScript data passed through a single function.


<?php // demo purpose only code



// do something meaningful with server data



// create runtime the output data

$output = '{';

foreach ($data as $key => $value) {

    $output .= $key.':"'.$value.'"';

}

$output .= '}';



echo 'jsCallback('.$output.')';



?>

Above technique became deprecated few years ago thanks to the widely adopted JSON protocol and its hundreds of programming languages native/coded implementations.
Moreover, above technique became the wrong way to do it thanks to a definitively better solution as JSONP has been since the very beginning.
Here an example of what JSONP services do today:


<?php // still demo purpose only code



echo $_GET['callback'].'('.json_encode($data).')';



?>

JSONP Advantages

The callback parameter is defined on the client side, which means it can be "namespaced" or it can be unique per each JSONP request.
If we consider the first example every script in the page should rely into a single global jsCallback function.
At that time I was using my code and my code only so problems like conflicts or the possibility that another library would have defined a different jsCallback in the global scope were not existent.
Today I still use "my code and my code only" :D when it comes to my personal projects, but at least I am more than ever aware about multiple libraries conflicts the primordial technique may cause, even if all these libraries are my own one.

JSONP Disadvantages

Well, the same reason that makes JSONP powerful and more suitable technique, is the one that could make JSONP the wrong solution.
If we still consider the first code example, nobody could stop me to be "really smart" and precompile that file into a static one.


// static_service.js by cronjob 2011-08-14T10:00:00.000Z

jsCallback({category:'post',author:'WebReflection',title:'JSONP Limits'});

While precompiled static content may be or may be not what we need for our application/service, it is clear that if no server side language is involved the common JSONP approach will fail due limitations of "the single exit point" any callback in the main page depends on: the jsCallback function.

Advantages Of Precompiled Static Files

The fastest way to serve a file from a generic domain is a static one.
A static file can be both cached into disk memory, rather than be seek and retrieved each time, or directly into server RAM.
Also a static file does not require any programming language involved at all and the only code that will be executed will eventually be the one in charge of serving the file over the network, aka: the HTTP Server.
The most common real world example about static files is represented by a generic CDN where the purpose is indeed to support as many requests per second as possible and where static files are most likely the solution.
The only extra code that would be eventually involved is the one in charge of statistics on the HTTP Server layer but every file can be easily mirrored or stored in any sort of RAID configuration and be served as fast as possible.

Another real world example could be a system like blogger.com where pages do not necessarily need to be served dynamically.
Most of the content in whatever blog system can be precompiled runtime and many services/blog applications are doing it indeed.

Same is for any other application/service that does not require real times data computations and different cron job behind the scene are in charge of refreshing the content every N minutes or more.
If we think about any big traffic website we could do this basic analysis:


# really poor/basic web server performances analysis



# cost of realtime computation

1% of average CPU + RAM + DISK ACCESS per each user

# performances

MAX_USERS = 100;

AVERAGE_MAX_USERS = 100;



# cost of a threaded cron job

20% of average CPU + RAM + DISK ACCESS per iteration

# cost of static file serving

0.1% of CPU + RAM + DISK ACCESS per user

# performances

MAX_USERS_NOCRON = 1000;

MAX_USERS_WHILECRON = 800; # MAX_USERS_NOCRON - 20%

AVERAGE_MAX_USERS = 900;

If we consider that we may chose to delegate the cronjob to a server a part behind the intranet and the only operation per each changed static file will be a LOCK FILE $f EXCLUSIVE, WRITE NEW CONTENT INTO $f, UNLOCK FILE $f EXCLUSIVE so that basically only the DISK ACCESS will be involved, we can even increase AVERAGE_MAX_USERS to 950 or more.
I know this is a sort of off topic and virtual/conceptual analysis but please bear with me, I will bring you there soon.

Static Content And RESTful APIs

There is a huge amount of services out there based on JSONP. Many of them requires realtime but many probably do not. Specially in latter case, I bet nobody is implementing the technique I am going to describe.

A Real World Example

Let's imagine I work for Amazon and I am in charge of the RESTful API able to provide any sort of article related data.
If we think about it, a generic online shopping cart article is nothing more than a group of static info that will rarely change much during the day, the week, the month, or even the year.
Do online users really need to be notified realitme and per each request about current user rating, reviews, related content, article description, author, and any sort of "doesn't change so frequently" related to the article itself? NO.
The only field that should be as much updated as possible is the price but still, does the price change so frequently during the lifecycle of an Amazon article? NO.
Can my infrastructure be so smart that if, and only if, a single field of this article is change the related static file could be updated so that everybody will receive instantly the new info? YES.
... but how can do that if JSONP does not scale with static files ?

My StaticJSONP Proposal

The only difference from a normal JSONP request is that passing through the callback call any sort of library should be able to be notified.
Being the client side library in charge of creating the requested url and having the same library knowledge about what is going to be received and before what is going to ask, all this library needs is to be synchronized with the unique id the static server file will invoke. I am going to tell you more but as quick preview, this is how the static server file will look:


StaticJSONP.notify("unique_request_id", {the:response_data});

Server Side Structure Example

Let's say we would like to keep the folder structure as clear as possible. In this Amazon example we can think about splitting articles by categories.


# / as web server root



/book/102304.js # the book id

/book/102311.js

/book/102319.js



/gadgets/1456.js

/gadgets/4567.js

A well organized folder structure will result in both better readability for humans and easier access for most common filesystems.
Every pre compiled file on the list will contain a call to the global StaticJSONP object, e.g.


// book id 102311

StaticJSONP.notify("amazon_apiv2_info_book_102311",{...data...});

The StaticJSONP Object

The main, and only, purpose of this tiny piece of script that almost fits in a tweet once minzipped (282 bytes) is to:

let any library, framework, custom code, be able to request a static file

avoid multiple scripts injection / concurrent JSONP for the same file if this has not been notified yet

notify any registered callback with the result

Here an example of a StaticJSONP interaction on the client side:


var

    // just as example

    result = [],



    // library 1

    client1 = function (uri, uid, delay) {

        function exec() {

            StaticJSONP.request(uri, uid, function (uid, evt) {

                result.push("client1: " + evt.data);

            });

        }

        delay ?

            setTimeout(exec, delay) :

            exec()

        ;

    },



    // library 2

    client2 = function (uri, uid, delay) {

        function exec() {

            StaticJSONP.request(uri, uid, function (uid, evt) {

                result.push("client2: " + evt.data);

            });

        }

        delay ?

            setTimeout(exec, delay) :

            exec()

        ;

    }

;

// library 1 does its business

client1("static/1.js", "static_service_1", 250);

// so does library 2

client2("static/2.js", "static_service_2", 250);



setTimeout(function () {

    // suddenly both requires same service/file

    client1("static/3.js", "static_service_3", 0);

    client2("static/3.js", "static_service_3", 0);

    

    setTimeout(function () {

        alert(result.join("\n"));

    }, 500);

}, 1000);

It is possible to test the live demo ... just wait a little bit and you will see this alert:


// order may be different accordingly

// with website response time x file

client1: 1

client2: 2

client1: 3

client2: 3

If you monitor network traffic you will see that static/3.js is downloaded only once.
If the response is really big and the connection not so good ( 3G or worse than 3G ) it may happen that same file is required again while the first request is not finished yet.
Since the whole purpose of StaticJSONP is to simplify server side life any redundant request will be avoided on the client side.

The Unique ID ...

StaticJSONP can be easily integrated together with normal JSONP service.
As example, if we need to obtain the list of best sellers, assuming this list is not static due too frequent changes, we can do something like this:


// this code is an example purpose only

// it won't work anywhere



// JSONP callback to best sellers

JSONP("http://amazon/restful/books/bestSellers", function (evt) {

    // the evt contains a data property

    var data = evt.data;



    // data is a list of books title and ids

    for (var i = 0, li = []; i < data.length; i++) {

        li[i] = '<a href="javascript:getBookInfo(' + data[i].id + ')">' + data[i].title + '</a>';

    }



    // show the content

    document.body.innerHTML = '<ul><li>' + li.join('</li><li>') + '</li></ul>';





});



// the function to retrieve more info

function getBookInfo(book_id) {

    StaticJSONP.request(

        

        // the url to call

        "http://amazon/restful/static/books/" + book_id + ".js",



        // the unique id accordingly with the current RESTful API

        "amazon_apiv2_info_book_" + book_id,



        // the callback to execute once the server respond

        function (uid, evt) {

            // evt contain all book related data

            // we can show it wherever we want

        }

    );

}

Now just imagine how many users in the world are performing similar requests right now to the same list of books, being best sellers ...

Unique ID Practices

It is really important to understand the reason StaticJSONP requires a unique id.
First of all it is not possible, neither convenient, to "magically retrieve it from the url" because any RESTful API out there may have a "different shape".
The unique id is a sort of trusted, pre-agreeded, and aligned information the client side library must be aware of since there is no way to change it on the server side, being the file created statically.
It is also important to prefix the id so that debugging will be easier on client side.
However, the combination to generate the unique id itself may be already ... well, unique, so it's up to us on both client and server side to define it in a possibly consistent way.
The reason I did not use the whole uri + id info on StaticJSONP request method is simple:
if both gadgets/102.js and books/102.js contains a unique 102 id there is no way on the client side to understand which article has been required and both gadgets and books registered callbacks will be notified, one out of two surely with the wrong data.
It's really not complicated to namespace a unique id prefix and this should be the way to go imho.

Conclusion

It's usually really difficult to agree unanimously to a solution for a specific problem and I am not expecting that from tomorrow everyone will adopt this technique to speed up server side file serving over common "JSONP queries" but I hope you understood the reason this approach may be needed and also how to properly implement a solution that does not cause client side conflicts, that scales, that does not increase final application size in any relevant way, and it's ready to go for that day when, and if, you gonna need it. Enjoy

Please Stop Reassigning For No Reason!

2011-08-08T17:03:00.046+02:00

I swear it is was a short one but a must write and yes, once again, since I keep seeing this kind of mistake everywhere!
This is not about JavaScript, this is about programming whatever language you want ... if you do this, you are doing it wrong!

The Problem

JS Engines developers are desperate! They are even posting how to help JIT compilers to go faster and developers seem to be so lazy that even most basic good practices are avoided.

Performances a part, this pattern can be also dangerous, specially in this ES5 era where getters and setters are extremely common, specially on mobile browsers where nobody cares about IE gap.

I am looking at you only if you are still writing something like this in your code:


window.whatever = window.whatever || {

    /* the whatever it is, object, function, anything */

};

where window is just the generic object example.

OMG, What Can Be Wrong ...

Everything! Any object property could be a native or user defined setter. In this case above technique is invoking the potential setter passing through the potential getter.
This simply means that:

accordingly to the task, we are asking N extra computations or function invokes for no reason

the setter may accept something different from what the getter returns. If this is true, result could be an error, rather than a "smart assignment"

if the setter was set already and it was a lazy re-assignment logic, we are avoiding lazy assignment features/logic requiring it's execution instantly and, once again, without any reason

if the object has getter only the operation will throw an error while setting

No getters or setters? It does not matter since in this way any property has to be retrieved and, if present, has to be reassigned to itself.

How JavaScript Engines Work

Thanks for asking. Let's imagine every object refers behind the scene to a stack of strings representing the list of properties. This stacks is used to know if object.hasOwnProperty("propertyName") or if "propertyName" in object is present. Once decided if the object can access the propertyName, a sort of -1 < objectProperties.indexOf("propertyName") procedure, the property has to be retrieved and eventually unboxed. Once this part is complete, the reassignment does not care much about the same property. Here comes the propertyName to propertyValue procedure which most likely will "erase" the older reference to reassign the new one. Even if the engine is truly smart, all possible checks/logics about memory address for the value and property name for the object has to be executed.
If you don't believe me you can simply check the Webkit engine Object source code and compare operations needed to set and get VS JSObjectHasProperty, basically just a call to jsObject->hasProperty rather than a whole logic moved via JSObjectGetProperty plus JSObjectSetProperty, and of course, invoking hasProperty as well.

How To Do The Same Better And Faster


"whatever" in window || (window.whatever = {

    /* the whatever it is, object, function, anything */

});



// eventually easier to shortcut via minifier

var key = "whatever";

key in window || (window[key] = {

    /* the whatever it is, object, function, anything */

});



// eventually easier to use but requires potentially extra memory

// 'cause the assignment has to be created in any case

// and it can't be ignored as it could be with precedent examples

function setDefault(object, key, value) {

    key in object || (object[key] = value);

    // here we can play with the returned value

    // I chose the function itself but it can be anything

    // or nothing if you prefer

    return setDefault;

}



setDefault(

    window, "whatever", {}

)(

    window, "somethingElse", function(){}

)(

    window, "howCoolIsIt", "very cool!"

);

The reason it's better is simple: no setters or getters invoked plus no redundant+superfluous operations performed over *reassignment*. Above snippet will simply invoke JSObjectHasProperty and jsObject->hasProperty so that the whole setter logic will be executed only if necessary and in any case no getter logic will ever be involved ... got it?

It Does Not Work

Oh ... Really? Most likely it's a browser bug you should file ASAP and even most likely a new feature not there yet. The in operator should always work as expected indeed with or without inheritance involved.


var o = Object.defineProperty({}, "test", {

    enumerable: false,

    writable: false,

    configurable: false,

    value: "OK"

});



alert("test" in o && o.test); // ... guess what ...

// OK

Since defined properties respect the in operator, nobody blocks us to define them using same pattern.


"prop" in object || Object.defineProperty(

    object, "prop", descriptor

);

I Have To Do Refactoring

Good, so start with this RegExp to search the evil code in all your failes:


/([$_0-9a-zA-Z]+(?:\.[$_0-9a-zA-Z]+|\[[$_0-9a-zA-Z]+\]))\s*=\s*\1/

    .test(fileText)



// or suggested by @joseanpg

/([$\w]+(?:\.[$\w]+|\[[$\w]+\]))\s*=\s*\1(?:[\s\|&,;]|$)/m

and modify accordingly. The replace RegExp requires unfortunately the end of the assignment so it may be weak.

I Kill A Kitten Each Time I Read That

This is what happens if you don't start now with the right way so, please, THINK ABOUT KITTENS!

Update On Alternative Ways

As @diegoperini pointed out in this tweet another way to avoid the setter is:


window.propertyName || (window.propertyName = {

    /* the whatever value */

});

However, above technique still invokes the getter, either defined by the user or behind the JavaScript scene ( in core ).
My first suggestion avoids "empty getters" so even if this latter technique may be considered a better approach, it can still suffers or imply side effects.

Update On False Positives
As Diego pointed out the "prop" in obj may result into a false positive if obj.prop is assigned but it is falsy. I consider this really an edge case and even such pattern will be error prone if the value is truish but not the expected one.


this.prop || (this.prop = {});



// now imagine before

this.prop = true;



// bye bye library

There is actually no easy or fast enough way to compare two clones runtime in order to understand if the assigned object is the one expected. Also at that point this extra overhead would be unnecessary since re-assignment will be just faster.
At the end of the day it's up to us to be as safe as possible still preserving common sense and good programming logic but don't tell me I am talking about premature optimizations because all I am talking about is logic over a pattern that is similar in size with the one I am suggesting but it's completely different in therms of required operations and destroyed possibilities.

We should never abuse bad practices behind the "premature" flag!

Update With Benchmark

As asked via comments, I have created a jsperf benchmark. Please bear in mind the used test is not a real use case while described problems are still the same I have been talking about in this post.
JIT compilers may optimize repeated code and this is most likely what happens with the commonPattern approach.
I love the fact the benchmark basically proves me wrong, when getters and setters are not involved on JS side, because it's kinda illogical accordingly with browsers implementations.
Said that, if anybody from Chrome development would be so kind to comment why re-assignment is faster than just in it would be really nice.

Conclusions

100000 VS 2000000 ops for non real cases are not so useful to analyze but what should be underlined is that specially with getters and setter the in operator is both faster and safer cross browser and cross platform.

As example, there is only one proper way to shim Array.isArray.
If we use return typeof obj.length == "number" rather than toString.call(obj) == "[object Array]"we will surely go faster but we will do it totally wrong as well.

Last note about Webkit, we have to deal with it since it has the majority of mobile browsing market share. Special case is webOS which implements V8 rather than JSC but still, don't be blind in front of millions, just understand side effects the common pattern could cause against the right way to know if a property has been set already.

bit.ly bookmarklet

2011-08-01T15:18:00.003+02:00

bit.ly offers a proper sidebar bookmarklet but you need to sign in so, if you are really lazy and you want an easy way to shorten whatever page you are visiting, drag and drop next link into bookmarks and click it once whenever you want.

bit.ly shortener

enjoy :)

About JavaScript apply arguments limit

2011-07-29T14:24:00.004+02:00

Just a quick one from ECMAScript ml ... it is true that browsers may have a limited number of arguments per function. This may be actually a problem, specially when we use apply to invoke a generic function that accepts arbitrary number of arguments.

String.fromCharCode

This is a classic example that could fail with truly big collection of char codes and here my suggestion to avoid such limit:


var fromCharCode = (function ($fromCharCode, MAX_LENGTH) {
    // (C) WebReflection - DO THE FUCK YOU WANT LICENSE
    return function fromCharCode(code) {
        typeof code == "number" && (code = [code]);
        for (var
            result = [],
            i = 0,
            length = code.length;
            i < length; i += MAX_LENGTH
        ) {
            result.push($fromCharCode.apply(null, code.slice(i, i + MAX_LENGTH)));
        }
        return result.join("");
    };
}(String.fromCharCode, 2048));

// example
alert(fromCharCode(80)); // P
alert(fromCharCode([80, 81, 82, 83, 84])); // PQRST

The revisited version accepts directly an array and performs the call ceil(codes.length / MAX_LENGTH) times.
Performances impact will be irrelevant while bigger Arrays will be parsed, hopefully, without problems.
If we still have problems we should never forget that userAgents may have a limited amount of available RAM so ... split the task or the operation or stream it.

As Summary

It's not that difficult to apply same concept with whatever function may suffer the apply and number of arguments limits: just define a maximum amount of arguments, in this case 2048, so that the task will be distributed without problems.

because shit happens

2011-07-28T09:11:00.011+02:00

When you spend half week of holidays recovering because of a dislocated shoulder, when you come back and spend 1 month recovering after a shoulder surgery, or for any other smaller or bigger shitty situation life could offer us, there is now a customisable way to express our anger: fuckn.es !

100% Embedded HTML5 Application

One project that always fascinated me is py2exe, an utility able to convert whole python applications into a single executable file.
This concept is similar in OS X Applications, where everything is transparently contained in a single file.
I have tried to reproduce a similar concept with this stand alone web page application where the manifest is hilariously the only external dependency, totally superfluous but necessary for mobile devices.
In any case, fuckn.es is a portable, "copy and paste source ready to go", cross platform tiny app, where rather than #! /bin/sh at first line, the user should simply double click it and run within a (modern) browser.
All images, sounds, and obviously CSS, HTML, and JavaScript are included. This surely avoid advantage of self updated web apps but nobody could stop me to implement a simple JSONP call to the website to compare versions:


// current version
var current = "0.0.1";

// update notification example
JSONP("http://fuckn.es/?v=" + current + "&fn", function(latest) {
    if (latest != current) {
        if (confirm(
            "New version " + latest + " available.\nWant to update?"
        )) {
            location.herf = "http://fuckn.es";
        }
    }
});

Mobile Oriented Navigation

While the app works in both Desktop and Mobile browsers, latter are surely more friendly with the implemented navigation / interaction.
The whole app can be managed with touches and gestures:

touch the body to see the anger in action (one up to three seconds)

tap one of the top buttons to access internal sections

swipe sections to change them or tap other sections for faster tab scrolling

scroll sections if these do not fit on the device screen

interact with fields by selecting them, no need to explicitly apply changes

tap again the current opened section to close it and eventually see changes applied

All of this is surely experimental but it was fun to create such mobile friendly interface that is usable through mouse and trackpad as well .... you know, specially on Mac we are getting used to act via gestures and I am pretty sure this website won't be the first one that interact more like an iPad app on bigger screens.

Current and future HTML5 capabilities

fuckn.es tiny app is based on many HTML5 concepts such File API, Audio, more related to the audio element, CSS3, and soon coming Web Storage to make changes persistent. I did not bother myself to make a fully cross browser app since one of these days all major browsers should support these features, including the input with capture microphone, right now usable to customise the audio providing a valid source.

JSONP Based Setup

The whole logic is based in a single fucknes function call, passing an object such:


fucknes({
    color: "#F00",
    background: "#333",
    text: "OMG",
    audio: [
        "base64encodedSource1",
        "base64encodedSource2",
        "base64encodedSourceN"
    ],
    image: {
        "00": "base64encodedImage00",
        "10": "base64encodedImage10",
        "11": "base64encodedImage11",
        "30": "base64encodedImage30",
        "31": "base64encodedImage31",
        "60": "base64encodedImage60",
        "61": "base64encodedImage61"
    }
});

The same concept is used to restore a previous or custom state file via record section and soon I will put an extra input able to JSONP online a custom configuration. Of course this app makes sense if people will start customise and distribute angers all over the net :)

Inline Download

As soon as W3C committed the link download property I have thought: how cool is that, I can create a base64 version of a text or whatever it is and set the filename into the download property ... and this is what I have done. There are no browsers yet compatible with the download property so right now if we create a snapshot of the current configuration we need to "right click" and save as, the result will be a text/plain file directly decoded for us by our browser.
This is the first time I see such technique to avoid big post or redirect to the server in order to download something for the client and as solution it seems pretty damn cool, isn't it?

No Server Code Involved At All

The last cool part is that the whole app can be used within the html file itself, there is no need of the server side and once these apps will be able to run in a trusted mode, same as native apps do, through the FileReader API, the Web SQL Storage or similar, and all next generation JS features, we can truly, and eventually, think of creating native like applications using exactly what we know already: no 3rd parts frameworks or application involved ( phonegap, Qt, appcelerator, etc )

As Summary

This little website has been one of the most stupid and futuristic personal projects I have ever made. It was simply fun from the beginning till the end, the silly represent your anger idea and the everything in one place with no server needed implementation.
It took a little while during my spare time and even this post has been prepared in different moments but eventually I have been able to activate my german PayPal account and the host finally worked as expected after DNS changes ( my fault here, I did it wrong ).
I hope you can at least appreciate the idea and why, have a little laugh or contribute with some customisation.
What's next? It could be face recognition to put anger through our camera snapshots or who knows what else ... stay tuned, and have fun ;)

Random Rant On CSS3 Transitions

2011-07-11T21:39:00.005+02:00

Update
Thanks to @gregersrygg for his link and hints, this is a hackish way to solve the problem apparently cross browser and trustable ... still a hack!


// this save one char, how cool is that!
!function(document){
    
    // (C) WebReflection (As It Is) - Mit Style
    
    // we all love function declarations
    function redraw() {
        
        // clientHeight returns 0 if not present in the DOM
        // e.g. document.removeChild(document.documentElement);
        // also some crazy guy may swap runtime the whole HTML element
        // this is why the documentElement should be always discovered
        // and if present, it should be a node of the document
        // In all these cases the returned value is true
        // otherwise what is there cannot really be considered as painted
        
        return !!(document.documentElement || 0).clientHeight;
    }
    
    // ideally an Object.defineProperty
    // unfortunately some engine will complain
    // if used against DOM objects
    document.redraw = redraw;
    
}(document);
// tested with Opera, Firefox, Chrome, WebKit

... at the end of the day, nothing changed about this post because the summary is still that we do not have an official/standard way to do things properly and we need to use hacks to simplify our daily tasks.

so here the summary: there is no fucking way to use CSS3 transitions properly!

The Problem

We put everything on the DOM and we let nodes come in and out all the time or we are screwed!
CSS3 transitions are freaking cool and freaking painful at the same time.
The classic scenario is to pollute the whole DOM once or many times with our random appended/inserted HTMLElements.
The goal is to keep the DOM as clean as possible still being able to let things land on the DOM in our desired way.

setImmediate bullshit

Rather than improve the single setTimeout(callback, 0) classic case, the classic hack that supposes to make things work as expected and at the same time the classic timeout rarely stored as integer to clearTimeout later does not scale.
This is the reason vendors/HTML5 people/whoever decided to add another unshimmable function: setImmediate, which supposes to be used the same way "setTimeout with zero delay" is commonly used.
If vendors screw a bit up the same way FireFox did, where somebody pushed in some release a requestAnimationFrame without thinking about the counterpart clearRequestAnimationFrame, setImmediate becomes useless as well as setTimeout 0 is if nobody takes care of clearTimeout or clearImmediate function.

The Problem, Once Again

We appendChild a node with margin-left: -100px, a transition property equal to margin, and we add the className that supposes to put the margin-left: 0.
To solve this we need to appendChild the node then abstractly wait for the browser to paint and after, eventually, set the new class.


var div = document.body.appendChild(
    document.createElement("div")
);
div.style.marginLeft = "-1000px";
// now we want the transition to marginLeft = 0 ... HOW?????

If by CSS3 above div has transition margin monitored, the only way to trigger the transition is to set a random timeout expecting that the browser renders in the meanwhile ... caus if it does not happen, we won't simply see it.

Why It Is So Hard

Unfortunately is most likely Web Developers fault, in the meaning that browsers are doing everything possible to optimize callbacks.
What we think is synchronous is just a matter of asynchronous, impossible to control, redraw actions behind the scene, where of course if we change 3 times classes to the same node browsers just consider last status and that's what they draw.

The Missing API

The more we have illusion of powerful features the more we screw up our architectures and layouts .... there's not much to do here except a bloody synchronous document.redraw() method, something that supposes to tell the engine: hey, I wanna you to consider the current layout so that after I can change it and you can consider these changes.

Will it be too hard for the CPU/GPU? Who cares, I mean, with all uncontrolled and theoretically optimized redraws/repaint operations we have every N milliseconds, how can a developer choice hurt so much?

mozAfterPaint

About Events, the cool part is that we can create them on JavaScript side and dispatch them whenever we want. Now, this paragraph notification is something we cannot fire in a meaningful way but it supposes to tell us ... exactly what? No idea, because the problem is that I do not want to control the status of the DOM via unpredictable setTimeout behavior, I wanna be able to tell the browser that status is OK now, would be so kind to draw the whole fucking thing for me, please?

As Summary

I hate lack of power under the HTML5 is for developers flag, I see setImmediate as a joke that I will be forced to use at some point for who knows which reason, but I still miss the possibility to properly control all these CSS3 transitions power via JavaScript, and once again, messing up between the view, and the controller.

Told'ya it was a rant!

Online Base 64 Converter

2011-07-05T21:23:00.003+02:00

Update apparently I am more than late since datauri.com does similar stuff ... oh well, better two options than nothing, right? Thanks @mathias for the update.

Right, you may think this is the most useless thing ever but actually embedded content is freaking cool and this is the reason I have created a truly simple page in 3site.eu/base64.

What The Hack Is That

Nothing truly special, you choose a file, you get its representation in base64 compatible with inline data url.

Best Available Option

... is converting data accordingly with your browser: who better than a browser can know how to understand inline data? Chrome or any other HTML5 Enabled Browser should work offline without problems, but if you are masochist and stubborn, it may fallback into server side encoding. Latter case may be dropped as soon as my cheap space in my cheap website will suffer too many requests so ... did I say already use a decent browser?
And that's all folks :)

JavaScript Hypertext Preprocessor

2011-06-24T17:13:00.008+02:00

well, the doctor said I can remove the tutor that was blocking my painful dislocated shoulder so here I am to test a "writing session" under pain killers from my bed!
With such post title you may think that doctor was a shrink ... well, I let you figure it out after reading ;)

About Hybrid Programming Languages

We all know CoffeScript, right? As well as Traceur Compiler ... right? These are what I call Hybrid Programming Languages, or better, those kind of pseudo representation of the programming language we use, in this case still JavaScript, passing through a more abstract, enhanced, "improved" syntax (Coffee) or language features (Traceur) .

About PHP And JavaScript

If you follow me since years you may have noticed how many times I have tried to make PHP more JavaScriptish. JavaScript like Object class is the first example from 2008, while [js.php] A JavaScript Object Like PHP Class was surely a better attempt, thanks to new PHP 5.3 features, as well as PHP JavaScript like Number class, this time based on PECL operator overloads.

I Am Not Alone

What I could not expect is that such "wanna write PHP as if it is JavaScript" topic is an obsession for many other developers such Tantek Çelik with his CASSIS or Stoyan Stefanov via JavaScript-style object literals in PHP.
As somebody commented already in one or more related posts, "why on earth do not use simply node.js ?".
Well, if node.js had even half of PHP hosts support, I am pretty sure many of us would have already solved this problem ... unfortunately node.js is "not that ready yet" and for some reason hosters prefer whatever version of PHP rather than a faster and more fashionable node.js.

JHP: JavaScript Hypertext Preprocessor

The name JHP is not new for me. I have used the same name many months before projects like php.js were announced.
While latter project aim is to bring to JS functionalities from PHP, I have revolutionized a bit my own concept of JHP trying to bring into native PHP world all JS possibilities ... here some example:


// $Object and $Function
$o = $Object();
$o->name = 'JHP';
$o->toString = $Function(function ($self) {
    return $self->name;
});
echo $o; // JHP

$Object->prototype->toString->call($o); // [object Object]

$me = $Object();
$me->name = 'WebReflection';
$me->hasOwnProperty('name'); // true

$o->toString->call($me); // WebReflection
$o->toString(); // JHP

$f = $o->toString;
$f($me); // WebReflection

// $String
$str = $String('abc')->concat('d', 'ef', $String('g'));
echo $str; // abcdefg

echo $Object->prototype->toString->call($str); // [object String]

// $String is an object
// so it's possibe to define properties (this is a getter)
$Object->defineProperty($str, 'name', (object)array(
    // just recicle the method inherited from $String->prototype
    'get' => $str->toString,
    // set propeties
    'enumerable' => false,
    'writable' => false,
    'configurable' => false
));

echo $o->toString->call($str); // abcdefg
// invoking $str->name as getter
// passing then through $str->toString callback

$a = $Array();
$a->push(1, 2, 3);
echo $a->length; // 3

$a->forEach(function ($value, $i, $arr) {
    echo $value.PHP_EOL;
});

// uh, and require as well ...
$require('sys')->print('Hello World');

XMLHttpRequest Example

This is just what's already possible to extend some global.


// sync only ... well, it's PHP
$XMLHttpRequest = $Function();
$XMLHttpRequest->prototype->open = $Function(function ($self, $mode, $uri, $async = false) {
    $self->_uri = $uri;
    $self->_mode = $mode;
});
$XMLHttpRequest->prototype->send = $Function(function ($self, $data = null) {
    // actually with curl we may emulate post, get, etc ...
    $self->responseText = file_get_contents($self->_uri);
});

$xhr = $XMLHttpRequest();
$xhr->open('get', 'http://webreflection.blogspot.com/', false);
$xhr->send();
echo $xhr->responseText; // this blog ... somehow

$Array, $Boolean, $Function, $Number, $Object, $String

This is almost all I have so far and everything is absolutely in a prototype/experimental status.
This is why I have not created a repository yet, also because this project was abandoned but just recently I have read the post from phpied.com so I thought ... well, why not talk a bit about my good old experiments as well? Maybe there is something to learn, surely there is a lot to improve, also thanks to latest PHP SPL and ... well, I let you decide what to do with this folder well forgotten in my good old netbook. You tell me if it makes sense, if you like the idea, and accordingly with feedbacks I will eventually consider to re-think from the scratch the whole pile of code in order to make it better, faster, usable, etc etc ... ok?

What's Missing

First of all ... to refactor everything, since at the beginning I remember I was trying to obtain a fresh new environment, or better, its globals, but I trapped myself without bringing the possibility to reuse current globals in a proper way.
Said that, the thing that I have never even started to do, as example, is a Narcissus based parser able to transform for me all JavaScript into JHP, bringing via use all nested scopes so that everything will be automatically available and we can really write JS and deploy on a PHP host ... this sound cool, uh? Well, let me tell you something, PHP is not that bad but such alien cannot surely be fast ;)
Last, but not least, the require uses eval and I hate eval, even if it's damned handy in some case.

How To Test / Where Is JHP

Well, it's here: have fun with JHP!

ES5 and use strict

2011-06-05T19:05:00.015+02:00

Update
There was another article about it which has less examples but more complementary points or descriptions.
Moreover, that page links to a specific use strict compatibility page, right now green only with Firefox Aurora and Google Chrome Canary.
However, another page shows more use strict cases as well and Canary seems to miss one check while Webkit Nightly shows all green YES. Opera Next is not there yet while IE10 surprisingly scores all of them except Function declaration in statements.
Well done guys!

on page 233 of the ECMAScript 5th Edition we can read details about "use strict" activation and what it means for our code.
Somebody believes this ES5 feature can help developers to write less errors ... well, I think not everything is that good as it looks.
This post is about all those points with concrete examples.

No OctalIntegerLiteral or OctalEscapeSequence

Base 8 has not many use cases on daily JS tasks. As example, to obtain the number 8 in base 8 we can write something like 010 where:


alert(010 === 8);

The problem is that 01 is not enough to force the engine to consider that number a base 8 and it will be interpreted as 1 indeed. Fair enough, I personally don't give a hack about base 8 so this does not hurt, it's just slightly simplified numbers parsing.
Same story for OctalEscapeSequence, no "octal magic" anymore.

No Global Variables

If our closure has a reference not defined in the outer scope, there is no global variable but a ReferenceError.


(function(){"use strict";
    for(i = 0; i < 2; i++) {
        // never executed due "i" ReferenceError
    }
}());

Above example is a classic one ... or better, a classic for newcomers with PHP or Python background, as example, where local variables are implicit and global one should be explicit.
While Python has a sort of implicit scope lookup with classes, PHP introduced closures only recently (well, 5.3 which should be right now the default minor version in every bloody server).
Since after 1 day of JavaScript development you should have got it (use var for local scope variables) I do believe this is more a limit, rather than a feature.
First of all, the current situation is quite naif since FireFox does not throw anything, it just stop working, while other browsers may nicely ignore this "feature".
Moreover, the moment we want to define a global reference we need to have in our closure a safe reference to the global context or we are simply screwed.
The second part of this point is that if the reference has been defined as writable:false, aka read only as undefined is, a TypeError should be thrown.


(function(){"use strict";
    undefined = 123;
    // throw TypeError
}());

Funny enough, if we have nested scope that relies in undefined but the outer one has something like:


(function(){"use strict";
    var undefined = 123;
    // other nested functions
}());

nothing will happen, undefined is still not trustable.

Safer arguments and eval

... but wasn't eval evil? Anyway, in the forth point of use strict specifications we have errors whenever we try to reassign arguments or eval.
Fine for eval, but a kinda common arguments trick won't be usable anymore.


// this will not work anymore
(function (context){"use strict";
    arguments = [].slice.call(arguments, 1);
    // some operation with arguments as Array
    outerCallback.call(context, arguments);
}());

Goodbye arguments caller and callee

Once again, arguments.callee is gone. Moreover, arguments.callee.caller is done as well but in this case it's not about the caller property, the whole callee concept is gone.


(function anonymous(){"use strict";
    alert(anonymous.caller); // throws TypeError
    arguments.callee;            // throws TypeError
}());

They call it "graceful migration", I call it WTF. If arguments is still there and it's a bloody object similar to an Array, why this object should throw an error with an undefined property?
OK, it's about migration, but actually what use strict introduced here is caller and callee as new reserved words, at least for properties of arguments or whatever function ... well done ...

arguments indexes

Whenever you have noticed or not, if you change a named argument value the arguments object will be affected at the same time. Here a basic example:


// before
(function (a, b){
    var c = a;
    a = b;
    b = c;
    alert([].slice.call(arguments));
    // b, a
}("a", "b"));

// after
(function (a, b){"use strict";
    var c = a;
    a = b;
    b = c;
    alert([].slice.call(arguments));
    // a, b
}("a", "b"));

To be honest, whenever it helps or not, I wonder who the hell ever used the first dynamic shared arguments indexed property value case on any sort of logic code ... was it an ES3 gotcha? Well, in such case I agree, it does not make fucking sense so ... thanks, I am sure somebody in this world will have problems about this new entry.
However, somebody that does not know JavaScript and programming principles as well may have problems ( nothing personal man, you just did it wrong 'till now ).
Sarcasm a part, it's good to have this clarification on specs.

Bindings and arguments

For strict mode functions, if an arguments object is created the binding of the local identifier arguments to the arguments object is immutable and hence may not be the target of an assignment expression. (10.5).

Well, if you get anything different form what I have said already about redefining the arguments reference/object, please do not hesitate to wake me up in the middle of the night while I am on vacations since seriously I cannot figure out what's this point about.

Unique Object Property Name

With ES3 we could have done something like:


(function (){
    var o = {
        one: 1,
        one: 2
    };
    alert(o.one); // 2 ???
}());

Now, since properties order is not granted at all even in a classic for(var key in obj){} loop, this point is about being not ambiguous and do the right assignment once. As summary, with use strict above example will produce an error: property name "one" appears more than once in object literal.
Once again, if you ever tried to assign same property more than once ... well, I can just say it's good they made this less ambiguous but I do believe this won't improve anybody code quality (being a mistake every Unit Test would have spot in any case).

arguments and eval as reserved identifiers

It's just like that, an argument cannot be called eval or arguments otherwise we gonna have a SyntaxError.


(function (){"use strict";
    function testEval(eval){}
    function testArguments(arguments){}
    var o = {
        get test(eval) {}
        set test(eval) {}
    };
}());

All cases will throw an error so, once again, hwew ES5 is introducing partial reserved keywords and this is wrong, imho.

Strict eval

I am not sure I got the next point, but here some behavior:


var evil = (function anonymous(){"use strict";
    return function (o_O) {
        var result = eval(o_O);
        alert(b);
        return result;
    };
}());

evil("function b(){}");
// function b(){'use strict';}


// example 2
var evil = (function anonymous(){"use strict";
    var a = 123;
    return function (o_O) {
        var result = eval(o_O);
        alert(b());
        return result;
    };
}());

evil("function b(){return a}"); // 123

Apparently eval has been maden a bit safer but I can see its evil nature all over the place without problems. Kinda good that function defined through eval inside a strict function are automatically strict as well so I guess this point is about strict inheritance through evaluation.

Strict this

There are different behaviors completely changed and it's not all about undefined === this.
Actually, it's not about this as undefined at all, it's about not changing the reference to something different.
There is a classic trick to obtain the global object in the most secure possible way:


var global = function(){return this}();
alert(global); // [object Window]
                     // [object global] in node.js

Above example is the equivalent of this function:


function Global() {
    return this;
}

window == Global.call() == Global.call(null) == Global.call(undefined);
// true

Untill now, the this reference has always been changed into the global object if the context was null or undefined.
Moreover, the reference has been changed into a proper object reference with primitives values such boolean, number, and string.


// ES3
function previousHello() {
    // primitive converted into new Primitive
    // e.g. this reference is a new String(s)
    alert("Hello " + this); // Hello World

    // we can add properties to new String
    this.test = 123;
    alert(this.test);       // 123
}
var s = "World";
previousHello.call("World");
alert(s.test);              // undefined
// since properties cannot be attached to a primitive

I don't remember I have ever defined properties runtime when the callback was about primitives values.
To me is like using objects as trash bin since nothing can be possibly reused after the function has been invoked.
This is what is changed in ES5 and use strict, there is no magic anymore when call or apply are used.
A primitive value will be primitive, an undefined one will be undefined and null will be null.
Here the test case:


// ES5
function sayHello() {"use strict";
    alert("Hello " + this); // Hello World
    this.test = 123;
    alert(this.test);       // undefined
}
sayHello.call("World");


function nullThis() {"use strict";
    alert(this); // null
}
nullThis.call(null);


function undefinedThis() {"use strict";
    alert(this); // undefined
}
undefinedThis.call();
// same as
undefinedThis.call(undefined);

It must be said that all these changes make life easier for engines behind the language since call and apply are widely used and all those checks about the context type and its eventual convertion are gone.
At the same time I would have reserved null as only exception to retrieve the global context since we have no more any safe way to do it and this is in my opinion bad.

More greedy delete

While before we could have tried to delete variables, and without success:


(function test(a){
    var b = "b";
    delete a;
    delete b;
    delete test;
    alert([a, b, test]);
    // a,b,function test(){...}
}("a"));

We cannot do this kind of mistake anymore since a SyntaxError will occur.


(function test(a){"use strict";
    var b = "b";
    delete a;
    delete b;
    delete test;
    alert([a, b, test]);
}("a"));
// SyntaxError
// applying the 'delete' operator to an unqualified name

The fact this was not possible was clear in ES3 specs but ,,, hey, now we know it better.
Only object properties with a configurable option equal to true can be deleted and nothing else.

TypeError on delete

Even if a property is not writable, we can still delete it since it is considered a configuration option.


(function test(a){"use strict";

    var o = Object.create(null, {
        deletable: {
            value: 123,
            configurable: true,
            writable: false,
            enumerable: true
        }
    });
    alert(o.deletable); // 123
    // o.deletable = 456; // Error: read-only

    // bye bye property
    delete o.deletable;
    alert(o.deletable); // undefined

    // free to manipulate
    o.deletable = 456;
    alert(o.deletable); // 456

}());

To seal/froze the property and to avoid delete operation all we need to do is to mark it as not configurable.


(function test(a){"use strict";

    var o = Object.create(null, {
        deletable: {
            value: 123,
            configurable: false,
            writable: false,
            enumerable: true
        }
    });

    delete o.deletable;
    // Error: property o.deletable is non-configurable
    //        and can't be deleted

}());

Since to be able to set properties as non configurable we need ES5 already, I think this was a mistake in the use strict rules because I would expect the same behavior for something introduced in ES5 as well as Object.defineProperty is.

Goodbye with statement

Whenever you like it or not, the with statement is gone.
I seriously do not want to spend more than I have done already about it so ... forget it, be happy about the choice and shut up or Mr Crockford and all minifiers will come out the dark wardrobe and punch you in the face.

Reserved arguments and eval identifiers

Everything else about use strict is related to arguments and eval keywords.
These cannot be used in function expressions, declarations, as variables, these cannot be reassigned, these must be used exclusively for what these are ... got it?

Summary

ES5 introduced use strict to let developers be familiar with things that will disappear soon in the next version of JavaScript.
I am not happy about many choices, specially regarding the caller property which was a must have for debugging and introspective purpose but ... hey, engines are not clever enough to activate these things when necessary but these engines are able to swap runtime a totally different behavior between a non strict function and a strict one.
In few words we still do not have full JavaScript potential here because of this transition that is apparently revolutionary behind the scene, surely not the best present ever for all developers that got JavaScript and used few tricks when necessary to improve their application logic and, why not, security.
Well ... deal with "use strict" and put it there by default or shut up for all new version of JavaScript ... this is the way in any case.

Partial Polyfills

2011-06-03T12:31:00.003+02:00

This is a quick one already discussed during my recent workshop in Warsaw, a concept rarely considered or adopted from JS developers.

What Are Polyfills

If we are updated enough to know ECMAScript 5th Edition, we probably know all possible shims and fallbacks for Array extras as well (e.g. Array.prototype.forEach).
Polyfills are simply snippets able to bring features already available for most recent browsers into those not updated yet.

Why Polyfills

If we develop with present and future in mind, we can take advantage of most recent techniques and solutions in order to both speed up via native support, where available, and maintain our application just stripping out code once all target browsers support them natively ... isn't this cool ?!

Polyfills Side Effects

The most common side effect of a polyfill is performances impact. The Array::forEach is already a good example of decreased performances.
If we think about a forEach, it's nothing different than a classic for loop, except we can reuse a function and eventually inject a different context.
As summary, while the code size will be reduced and all "Array loops gotcha" resolved nicely, old browsers already slower will be even slower due simulated native behavior implemented through JavaScript.
The second most important side effect is that sometimes we cannot possibly reproduce the new native behavior via old JavaScript, which means we are compromising logic and potentials of our application in order to support "not there yet" browsers.

Partial Polyfills

Once we have defined a "full specs simulated" polyfill we can forget problems and use it whenever we want. Unfortunately, we have to agree with all other external libraries as well, libraries that would like to be dependencies free and that most likely will re-implement or re-check over and over if that polyfill is present or not.
On the other hand, there are many situations were we do not need the full implementation of a missed feature and in these cases the advantage of a partial polyfill will result in reduced and safer code.

What Is A Partial Polyfill

Let's take the classic Array.prototype.indexOf as example and check the size and the "complexity" of the full spec proposal in MDC ... done?


// our main library closure
(function () {

// all we may need to indexOf
var indexOf = [].indexOf || function (value) {
    for (var i = this.length; i-- && this[i] !== value;);
    return i;
};

// wherever we need ...
var index = indexOf.call(arrayLikeObject, value);

// end of our main closure
}());

If we deal with properly defined arrays, arguments, or DOM collections, and if we use indexOf simply to avoid duplicated entries in a generic stack, ask yourself if it makes sense to implement the full specs there rather than those two lines of JS showed above.
As somebody noticed, that snippet is more similar to Array.prototype.lastIndexOf, due reversed loop, but why bother if our indexOf use case is specific?
Why pollute the global Array.prototype causing potential problems for other libraries?
Why make the "search into array" routine more expensive for already slower browsers?
In few words we can reuse few extra bytes in every closure we want to obtain a simplified indexOf behavior compatible with every browser, isn't it ?!

Why Safer

Unless we are not sure 100% that the Array.prototype.indexOf has been replaced with a full specs version and since we may lazy load extra code that may be greedy or change again that prototype, we can address that callback and use call as much as we want being sure that no library will ever change our expected performances and/or behavior.

Why Smaller

Not only we can copy and paste those two lines of code in many places without impacting code size, we can also take advantage of most popular minifiers, able to make each call smaller.


// minified indexOf through prototype
a.indexOf(b);

// minified addressed indexOf
x.call(a,b);

Last, but not least, using call we can automatically use by default the indexOf with objects and every other ArrayLike variable.

Conclusion

There are many cases where we may need one or more ES5 feature but not all of them will be used 100% of their potentials. A partial polyfill can ensure better performances and easier access in the private scope.
Surely we may avoid this technique if by default we normalize all behaviors but once again, we all know we don't like much core functionalities dependencies that may be broken or extremely slow for what we need in our specific cases.

Web Reflection

ES6 Harmony Collections Fast Polyfill

On EventEmitter In node.js

Why All Of This Is Bad

Y U NO use libraries and add stuff

Zero Stress Namespace And Dependencies Resolver

The yuno Concept

Y U NO Add

To DOs

Introducing ObjectHandler

ObjectHandler IDL Like

Examples

Pros

Cons

As Summary

Improving Function.prototype.bind

At The End Of The Function

Team Speaking

Unable To Retrieve Same Bound Function

An Error Prone Logic

A Clever Object.prototype.boundTo

Pros

Cons

Why No Arguments

Update - Preserving Private Methods

As Summary

Learning From 2011

The Partially (Multi)? Touch Device Case

IE9 Mobile Epic Fail

webOS 2 Sad Fail

Ultra Powerful ... "broken" Androids

FireFox Mobile Fail

iOS Gesture Events VS Others

The Curious Case of Opera Mobile

Android Whatever

Mobile Web Apps Too Limited

What If Every Web Page Asks For Space

Native VS Web App

Patent Oriented Development

Hardware Patents

ES6 Focus

WebGL Partial Fail

CSS3 Partial Fail

As Summary

Coercion Performances

It's About Optimizations

Performances

JIT Oriented Development ?

As Summary

Please, Give Us Back __noSuchMethod__ !

A Bit Of Background

The Minified Theory Against The Practice

The Inexistent Theory Against The Practice

A Getter IS A Getter

Other Programming Languages

Think About Libraries APIs Migrations

It Is Not About jQuery

How To Solve This

Create a JS builder with node.js

Solutions All Over The Place

How To Structure Your Project

The Folder

Structure Rules

The Order Partially Matters

The builder.js File

How To Use The Builder

As Summary

On JSON Comments

Kyle Facts

Just A Side Effect

Improve The Standard

JSON Is Not A JavaScript Thing

Not That Easy

Still Valid JSON

Array extras and Objects

A Bit Messed Up

Need For An Object#forEach

WTF

Object extras

As Summary

Please, Give Us Back noSuchMethod !