The JavaScript typeof Operator Problem

TL;DR don't even try to normalize or shim newer typeof via code: you simply can't!

Whenever it was a mistake or not to consider typeof null == "object", many libraries that tried to normalize this operator failed to understand that null is not the only problem.

The JS Polymorphism Nature

We can borrow methods for basically everything but primitives values, such booleans, numbers, and strings, do not accept indeed any sort of property or method attached runtime.

var s = "hello";
s.greetings = true;
alert(s.greetings);
// "undefined"

However, we can still use methods through call() or apply():

function isGreetings() {
  return /^(?:ciao|hello|hi)$/.test(this);
}
alert(isGreetings.call("hello"));
// true

The only way to find a method in a primitive value is to extend its own constructor.prototype:

String.prototype.isGreetings = function () {
  return /^(?:ciao|hello|hi)$/.test(this);
};
alert("hello".isGreetings());
// true

What Happens When We Invoke A Method

In ECMAScript 3 up to 5.1, when "use strict" directive is not in place, any primitive value will be temporarily converted into an object, where only null and undefined will be converted into the original global object.

alert(function () {
  return this === window;
}.call(null));

// ... and here a tiny winy problem ...
alert(function () {
  return this ? true : false;
}.call(false)); // true
alert(function () {
  return Boolean(this);
}.call(false)); // true
alert(function () {
  return !!this;
}.call(false)); // true

Back to the previous chapter, a situation like this might mislead as well:

function setAsGreetings() {
  this.greetings = true;
  alert(this.greetings); // true
}
var s = "hello";
setAsGreetings.call(s);
alert(s.greetings); // undefined

Why This Is A Problem

Try to imagine this really simple piece of code:

function whichType() {
  return typeof this;
}
// guess what ... 
alert([
  whichType.call(null),     // "object"
  whichType.call(false),    // "object"
  whichType.call(true),     // "object"
  whichType.call("hello"),  // "object"
  whichType.call(123),      // "object"
  whichType.call(undefined) // "object"
].join("\n"));

Now you can play adding "use strict" to the very beginning of the whichType function.
Doing the same with an argument, rather than context injection, will produce the same output, regardless the function has or not the strict directive.

function whichType(o) {
  // pointless "use strict";
  return typeof o;
}
// guess what ... 
alert([
  whichType(null),     // "object"
  whichType(false),    // "boolean"
  whichType(true),     // "boolean"
  whichType("hello"),  // "string"
  whichType(123),      // "number"
  whichType(undefined) // "undefined"
].join("\n"));

What If You Want Use new String/Number/Boolean

It's not only about context injection and the typeof this, it's also about the ability to use collections of the same type as we need.
As example, let's imagine we have a list of unique IDs, and we would like to flag them, relate them, or use them, as objects.

var ids = [
  "a",
  "b",
  "c"
];

// an easy way to mirror strings as objects
var flagged = ids.map(Object);

// check if a generic input/id exists ...
var i = ids.indexOf("b");

// ... and check if it has been used/touched already
if (-1 < i && !flagged[i].touched) {
  flagged[i].touched = true;
  alert("touched");
}
// once again ... but it will never happen
if (-1 < i && !flagged[i].touched) {
  flagged[i].touched = true;
  alert("touched");
}

With above example we might use the variable ids to simply filter existent and not existent input, and mirror these ids through they respective objects and eventually reuse these objects as we need, concatenating them, recycling them, etc etc ... I know, above example is not such common use case, right? But of course it's not since we have so many problems with typeof and nobody in JS world has ever suggested to use, when necessary, these constructors in a useful way...

typeof In JS.Next

Since explicit should superset implicit behaviours, ECMAScript 6 and code under "use strict" directive will react like this.

function app(s) {"use strict";
  alert(type.call(s));
}

function type() {"use strict";
  return typeof this;
}

app("primitive");         // "string"
app(new String("object"));// "object"

This is actually awesome since we can always tell if that string/object has been created using new Constructor or not ... which leads with less ambiguous code and the possibility to use objects as primitives whenever we find a case were it's needed.

function setGreetings() {
  this.greetings = true;
}
var s = "hello";
setGreetings.call(s); // pointless
s.greetings; // undefined

// but if we want ...

s = new String(s);
setGreetings.call(s);
s.greetings; // true !!!

As summary, knowing in advance how an object has been created, will let us understand if whatever property/method changed or attached to a generic this will make sense or not ... unless these operations are not simply used internally during the temporarily lifetime of that possible object ... where again we might need to know if we have to clean up after or not ... that's what I call control, isn't it?

... And No Polyfill Will Do

Bad news here is ... there is no way to replicate the new and correct behaviour of the next typeof operator.
If we remove "use strict" directive from the latter example's type() function, we'll notice that the result will be "object" in both cases ... no matter how we pass the original argument.

Reasonable + Inconsistent = Fail

If your only concern is that typeof null should produce the string "null", you might realize that o === null is all you need, rather than creating and calling a function every time you want/need to understand the type of an object.
As we have seen before, when null is used as context, the typeof could return "object" in any case.
When latter case happens, the check against the triple equality operator will fail as well.
If null is not the only problem, just consider that if an engineer created a variable using new String(text) rather than using just text there must be a bloody reason: either the engineer does not know JavaScript OR, most likely, decided to use the possibility offered by an object that is wrapping a primitive value.
If you use a framework that does this wrapping by default there's only one thing to do: change framework!
Strings are immutable while Objects are always freshly baked ... since a list of strings as objects cannot even use Array#indexOf unless you don't hold and/or compare via Generic#valueOf() every time the list content, the amount of pointless RAM and CPU used to work with these kind of wrappers does not scale ... full stop.
If you never use new String and believe that nobody else will as well, your logic might be screwed in any case by the fact that newer browsers might implement a proper typeof and make your code/logic weak when the original constructor has been used as wrapper.

How To Migrate, How To Not Fail

Unless both your code and your environment is frozen by respective versions, and it does not matter if it's client or server side, you cannot basically trust your own code because one day, in some browser, it might act differently.
If you need typeof so much and your code is for 3rd parties development, you might decide to create two slightly different versions of your code or simply normalize the old typeof behavior forgetting then returning "string" when you don't actually know if the developer meant string or new String.
A feature detection like this one could help:

var NEW_TYPEOF = function(){
  "use strict";
  return typeof this == "string";
}.call("");

To simplify above code you might trust the generic strict directive behaviour, through undefined, via this snippet:

var USE_STRICT_COMPATIBLE = function(){
  "use strict";
  return !this;
}();

Followed by the rarely seen check:

var USE_STRICT_ENABLED = function(){
  return !this;
}();

Above check does not simply tell us if the the browser can handle the strict directive, it also tells us if we are already under use strict.
If we wrap everything in our own closure we might not care in any case ... so, back to the topic, we might understand through these checks if we are under strict directive but what we cannot normalize in any case is something like:

function borrowedMethod() {
  alert(yourTypeOfShim(this));
}
borrowedMethod.call("fail");
borrowedMethod.call(new String("fail"));

In ECMAScript 3rd Edition latest snippet will return "object" while in ES5 and strict directive it will return "string".
If your normalizer is "so cool" that transform any instanceof String into "string", then you might realize that same code run under strict in ES5 will return "object" so either both ways, and as summary, your function is not reliable.
Can we say now there's more mess than before? Oh well ...

Doesn't Matter, Had Type

If you wanna have a function that will never be able to compete with the real power of ES6 or "use strict" typeof operator, you might end up with something like this:

function type(o) {"use strict";
  var type = typeof o;
  if (type == "object") {
    if (!o)
      type = "null"
    ; else if (
      o instanceof Boolean ||
      o instanceof Number ||
      o instanceof String
    )
      type = typeof o.valueOf()
    ;
  }
  return type;
}

However, all you gonna have in this case is a function that removes a new feature from the next version of JavaScript.
I have aded this script just to give you a chance if you wanna believe that using methods across primitive wrappers does not make sense ( subclassing anybody ? at that point you gonna have another problem ... oh well, again ... )

input.focus() ... something really annoying!

new libraries, new add-ons, new engines, new browsers, but still the bloody focus event directly in the onload one ... any chance we will go a step forward?

What is wrong with focus

The main usage of this strategy is to force via JavaScript the focus of the main input field and it is usually on the top of the page.
It could be a search input, a la Google, or it could be a generic log-in. It could be a blog post title, or it could be a comment ... whatever it is, it should NOT act like this!
Try to imagine you have a slow connection (I am still with mobile usb pen) or try to imagine you are using your A Grade browser mobile phone with still, a not that fast connection (I am still using my Android, iPhone is the same).
Since these magic-focused fields are usually at the beginning of the page and since the page will take more time to be downloaded, 90% of the time this automatic feature messes up my user and password or my searched keyword. Too often I have to correct or change back the field, specially when I need to log-in into my on-line banking service, where my actions are faster than page download. Am I that fast? OK, Android first model with its pretty keyboard let me type faster than how I could do with iPhone or second Android generation, but the main problem is that if there is an image, for example, or generally speaking just content after main focused input, the onload event will be fired too late and it will be completely useless and inefficient, rather than being an help for the user.

How could we solve the problem

In my opinion, it is the most simple thing ever. Assuming that the theoretically helping focus will be only one per page, if the site would like to make sense, all we need is a little manager able to understand if the input received focus before the onload event:

<form name="f" action="/search">
    <input name="q" onfocus="fff=1" />
</form>

fff will be a global variable which name is absolutely irrelevant and which aim will be to stop the generic onload event to force focus in that input.

<body onload="if(!this.fff)document.f.q.focus();">
    <!-- ... the rest of the page ... -->
</body>

With a zero effort + stress strategy that will not increase more than a couple of bytes our page, users will have more control over their fields. This simple trick could be used for every textarea, input, select, or button in the page making the auto focus really helpful in those case user has a fast connection or is lazy and does not want to point the focus automatically, rather than quick posts via mobile or slow connections.

Another Way Without Changing Every Layout

I agree that probably nobody will ever change every page layout adding an inline onfocus event for each field, so here I am with a better solution that should be widely copatible with every kind of device.

(function(){
// A WebReflection Anti Stress Idea
function onclick(e){
    var target = (e && e.target) || event.srcElement;
    if(/^(input|select|textarea|button)$/i.test(target.nodeName)){
        window.fff = true;
        if(document.detachEvent)
            document.detachEvent("onclick", onclick);
        else
            document.removeEventListener("click", onclick, false);
    }
};
if(document.attachEvent)
    document.attachEvent("onclick", onclick);
else
    document.addEventListener("click", onclick, false);
})();



// as body or window event
onload = function(){
    if(!this.fff)
        document.getElementById("main-input").focus();
};

Above snippet does not require both onReady or onload events so it should work just adding it inside the head tag. It is so simple, now let's see how people will react 8)