modisposition

You might think this must be a joke, well no , this is a partial lie behind the "use strict"; directive. Roots Of The Hack // global "use strict"; function strict() { "use strict"; // top of the function return { // invoked inline withStrict: function(){ return this; // undefined }(), // invoked inline too withoutStrict: Function("return this")() }; } // the test var really = strict(); really.withStrict; // undefined really.withoutStrict; // global, BOOOOM! The Good News I have been blaming since ever the fact that use strict makes impossible to retrieve the real global object ensuring nobody in the closure redefined window or global by accident so that code is more reliable. Well, now we have the possibility to return it again when it's needed for security reasons or to be sure is the right one. // a classic code for Rhino, node, and Web var G = typeof window !== "undefined" ? window : global

This is a tiny post about a tiny utility, something Modernizr like , but actually much simplified , like about 330 bytes minzipped. Of course the power is kinda limited, but for most common things such requestAnimationFrame or CSS transition it should be more than enough. Basic Example You can find more in the experimental.js repository but here a couple of examples: // check if present and use it if (experimental(window, "requestAnimationFrame", true // optional third flag to assign the found property )) { // in this case attached directly to the global // so we can just use it all over requestAnimationFrame(callback); } else { setTimeout(callback, 10); } Another example, discovering the right string for transition: var TRANSITION = experimental(body.style, "transition"); alert(TRANSITION); // mozTransition // webkitTransition // oTransition // msTransition // or just transition If you are wondering about pure CSS, it's easy to add a tiny extra

We can't wait to get this year rolling. I guess we don't have to wait long . . . we are going to New Zealand/Australia tomorrow and we've got a new record coming out with sonic partners Sacred Bones on March 5th.  Come and get into the groove.  Love, Us

If you think Object.defineProperty() is not widely adopted, here the list of browsers that support it, together with Object.create() and Object.defineProperties() . Desktop Chrome 7+ Firefox 4+ Safari 5+ Opera 12+ IE 9+ Mobile Android 2.2+, 3+, and 4+, stock browser Android 4.1+ Chrome Android and Symbian Opera Mobile Android Dolphin Browser Android Firefox iOS 4+, 5+, and 6+, Safari Mobile iOS Chrome Browser Windows Phone 7+ IE9 Mobile Windows 8+ RT and Pro webOS stock Webkit browser Chrome OS Firefox OS I believe Blackberry supports them without problems with their advanced browser I believe updated Symbian too but I could not test this Server node.js Rhino/Ringo JSC BESEN and others I could not test too Except where I have stated differently, I have manually tested everything in this list but you can try by your self in kangax es5 compat table . Please note that even if Object.f

The proper title for this post could have easily been something like JavaScript Inheritance Demystified or slightly less boring as The Untold Story About JavaScript Objects ...well, thing is, I don't really want to alarm anyone about this story and as a randomly improvised storyteller, let's move forward, and see where it goes, starting from where it all began ... Elementary, My Dear Watson! The very first thing we might want to do, in order to make our research, discovery, and piece of programming history useful, is creating a couple of shortcuts that will let us easily analyze the code and the current story: // retrieve the first inherited prototype var $proto = Object.getPrototypeOf; // retrieve all own properties, // enumerable or not, ES5 stuff ! var $props = Object.getOwnPropertyNames; Why do we need that? Because almost everything is an instanceof Object in JavaScript world, which simply means, and we'll see this later on, that Object.prototype is inherited all

I can't believe it, every time some cool pattern comes into games, __proto__ makes everything pointless, in a trusted meaning of a generic property! Previously, in Internet Explorer One of the biggest and most known WTFs in IE is the fact that Object.prototype properties are not enumerable. While is possible to define such properties in ES5, this is the classic good old IE only scenario we all remember: for(var key in {toString:"whatever"}) { alert(key); // never in IE } As simple as that, all native properties in the main prototype were considered {toString:true}.propertyIsEnumerable("toString") === false because indeed, these were not enumerating (just in case: enumerable properties are those that should show up in a for/in loop) The Same Mistake With __proto__ If Not Worse That's correct, the moment you play with this property name things start falling a part same old IE way or even worst. alert( {__proto__:"whatever"}. propertyIsE

I believe we all agree that Google Closure Compiler is one of the most advanced tool we have for JavaScript development: fast parsing with pretty printed or minified output with warnings about possible problems or errors type checks analysis before it was cool, as example via java -jar compiler.jar --jscomp_warning=checkTypes --compilation_level=SIMPLE_OPTIMIZATIONS ~/code/file.js creation of source map for an easier debugging experience with the real, minified, code best raw compression ratio, death code elimination, and more with @compilation_level ADVANCED_OPTIMIZATIONS I also believe the latter point is a trap for developers and projects: unable to scale and capable of many headaches and shenanigans. If you want to know why, here a list of the top 5 facts I always talk about, when some developer comes to me telling the solution to all problems is advanced optimizations. 1. Incompatible With ES5 Every current version of a browser is compatible with ES5 features but the tool that

There are several UMD ways to define a module with zero dependencies but I believe that's quite an overhead so here an alternative: // please read next example too // which seems to be better for AMD tools (this.define || Object)( this.exportName = exportValue ); Update with a nice hint by @kentaromiura where the other side of define could be just a function and not a new function as initially proposed. Another update suggested by @unscriptable that should not break AMD tools, neither CommonJS, neither global Rhino or window, still leaking a couple of properties that should be reserved for module stuff anyhow. var define = define || Object, exports = this.exports || this // * ; define( exports.module = {} ); Nice one, and if you are wondering why this.exports is needed, is because RingoJS apparently does not follow a de-facto standard as this as module exports is for other CommonJS implementations. Even Better If you don't want to pollute the scope at all: (t

While examples used in this post are implemented in JavaScript, concepts discussed here about getters are, in my experience, universally valid. No matter if we are programming client or server, getters can be full of wins and if you think getters are a bad practice because of performance keep reading and you might realize getters are a good practice for performance too. As summary, this entry is about getters and few patterns you might not know or ever thought about but yeah, is a long one so ... grab a coffee, open a console if you want to test some snippet and enjoy! Update JavaScript allows inline runtime overload of inherited getters so that properties can be redefined as such, when and if necessary. This is not possible, or not so easy, with Java or other classical OOP languages. This update is for those thinking this topic has been already discussed somewhere else and there's nothing more to learn about ... well, they might be wrong! ;) What Generally speaking, a getter i