Hallo,
Naja, es geht auch z.b., um den Kontext. Da wo die null ist, wird ein Objekt erwartet, da wo NaN ist, eine Zahl. typeof getElementById(...) muss immer 'object' ergeben und nicht mal dies oder jenes.
typeof dient also dazu herauszufinden, was erwartet wird oder was irgendwo stehen könnte? Hmm, das weiß man doch...
typeof benutzte ich eigentlich immer um rauzufinden, ob ein Wert definiert ist.
Ob etwas überhaupt definiert ist prüfe ich, wenn überhaupt nötig, mit if(sth!==undefined)
...
Wenn ich herausfinden möchte ob ein Objekt einen Wert hat, prüfe ich auf null und dabei möchte ich auch keine Typkonvertierung. Die, wie wir ja schon mal diskutiert haben, auch ihre Fallstricke hat.
typeof braucht man dafür aber nicht. Die Existenz eines Objekts prüft man am besten mit if(o)
... da stört die automatische Typkonvertierung nicht, es sei denn, man hat Variablen, die tatsächlich auch mal einen anderen truthy Wert als ein Objekt enthalten können, aber das wäre ein Spezialfall und m.E. bad practice.
Ausserdem muss ja auch der Vergleich obj !== null funktionieren und das geht nur, wenn null ein Objekt ist.
Wieso? Das geht auch sonst. null ist ja kein Objekt. Es steht nur manchmal da, wo auch ein Objekt stehen könnte, das ist alles. Wie gesagt, es ist kein Problem, dass statt eines Objektes auch mal null zurückkommt; das ist ganz gut so. Deswegen muss typeof noch lange nicht behaupten, dass null auch ein Objekt ist.
Gruß, Don P