modisposition

Just slides I have showed today here @ nokia for a tech talk, hope you'll enjoy them, cheers Update Here you can find the updated version of the Object.forEach proposal: gist 2294934 Main changes are about some inconsistent behavior in Safari, not it should work without problems. Thanks to @medikoo for his hint. ... rock'n'roll ...

I'll try to make the point short and simple, starting with the tl;dr version: if you create a polyfill and during features detection you realize this cannot work, drop it and let other libs deal with it. Broken Object.defineProperty This is just one case really annoying. Bear in mind I am not talking about " making perfect polyfills ", this is almost impossible most of the case, I am talking about broken runtime even if you did not really do anything that special. It was the case of Object.defineProperty shimmed through es5-shim code ... this library is good but that method, as many others, are simply broken. I was trying to add a setter/getter in IE < 9 and shit happened, more specifically a thrown exception happened ... the repository itself explains that this method and others should fail silently ... so it's OK for the developer to know about it and avoid trusting these methods ... This Is Not OK If I check if Object.defineProperty is there and this is al...

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 ...

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 c...

Update Yes, I did it: getters and setters for IE < 9 and other browsers After my early Hooorrayyyy! about compatible IE , I have been experimenting a bit more on how to solve the JSObject to VBVariant and vice-versa assignment and the result was an horrendous monster loads of potential memory leaks and performances implications for the already slow bounce of browsers such IE8, 7, and 6. Since limitations were also too many, as described in this even earlier attempt from dojo framework , I have realized that VBScript was simply a no-go , or better, probably the wrong answer to the question: how can I have cross-browser getters and setters? The jQuery Hybrid Answer Back in 2009, James Padolsey described the jQuery framework as a sort of getters/setters simulator API, comparing the semantic and beauty of non-standard Spidermonkey __defineGetter__ and __defineSetter__ , against jQuery coding style, where many "methods" could be considered as getters or setters. // get t...

... where JS++ is simply metaphoric, in the meaning of "empowered JS" :) Here the slides I have showed last friday during another team meeting, enjoy!

In my latest posts I have talked about current situation for JavaScript " Classes ". In Good Old And Common JS Errors I have introduced a misconception of a generic "Class" function which is usually not able to produce instanceof Class , considering Classes in JS are functions indeed. In Better JS Classes I have explained how to write a meaningful Class factory , avoiding the _super pollution over each extended method, while in the JS _super Bullshit I have explained why the _super/parent concept does not scale with JavaScript prototypal inheritance model. More than a dev, Mr Crockford included, agreed that in JavaScript the classical pattern does not fit/scale/produce expected results, and even worst, it could cause "disasters" during a session and slow down overall performances (and about this topic I have already said that web developers should stop to test their stuff with powerful CPU, read Macs! Buy a bloody Atom based device as I have done and af...

Update If after this post and its comments you are not convinced yet, have a look into with: Some Good Example one. Every reference to this post is purely casual ... no it's NOT! It's time to talk about the fuss around the innocent with statement, and why somebody decided it's bad or it should not be part of next JavaScript. Extends the scope chain for a statement Extended chains are probably what we love more about JavaScript libraries ... $("stuff") .more() .again() .somethingElse() ; but for some sadistic reason we decided that we don't like native extended chains in our code ... with(stuff){ more() again() somethingElse() }; Bad Examples And Bad Usages Every time I say that with statement has nothing bad, somebody perpetually points out this bloody post ... OK, from Yahoo! ... so what? Honestly, I could post thousands of bad examples and point my finger into this or that library, function, method, evaluation, etc etc ... it's like th...

This is just a quick one. One of the worst decision about ES5, after the one to remove arguments.callee when "use strict" is present, is the missed default reference to the global object. Probably the most secure trick to retrieve the native window in JavaScript is this one: // wherever we are var global = function(){return this}(); // while window, could be simply a variable // assigned somewhere else in this scope I have already talked about this, and I am still against some ES5 "feature" which aim is probably the one to make JavaScript as fast as possible, regardless all code that will break if "use strict" is present in the generic scope. Another non-sense is to allow a this in a context where there is no this. Rather than an error, ES5 will point refer this to undefined . Are you kidding me? this is a special keywords related to the context and you are telling me a context is undefined? so I guess open() , as example, should throw an error there, s...