modisposition

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()); // tru

I have talked about this already in both JSConfEU and QCon - London and I have also blogged a couple of times about this problem that many developers keep ignoring ... The Unexpected Input In JSConfEU I have showed with my slides this picture: which is simply the reason most of the so called mobile websites won't work as expected. Why that? Because "ontouchend" in window , the most pointless feature detection ever, will produce a positive result and if you decide which event should be attached to the document or any DOM node relying this check, the moment the device that exposes touch events BUT has a trackpad, mouse, or any other alternative pointer device connected, it will fail, it won't work, it will look broken! A Hybrid Solution We could make the assumption that if the user is using fingers, the user will keep using fingers ... while if the user chooses the alternative pointer, there shouldn't be a case where fingers are again on the screen. For this kin

Update ... regardless this rant is still valid ... I have updated for both Web and node my es6-collections following stricter currently available specs. This is happening right now, or better, since this race started a while ago between alternative browsers and the idea of bringing JavaScript every-bloody-where ... On Engines Fragmentations This happens since ever in vehicles engines and we can all see the difference in themes of both prices and CO2 emissions. Every major car/motorbike engine manufacturer is competing against others. N times the amount of money spent, N times the number of patents slightly different and potentially able to make better engines production slower/farer due patents lifecycle. Almost zero joined effort ... same studies over and over with of course different solutions, and these are always welcome, but rarely a shared effort between teams able to bring the 0 emissions, ecologic and usable engine we are all dreaming about ( look at all these prototypes with

I know what's right I got just one life. Thanks to everyone who came to see us in Europe.  We're blazing a trail through America & Canada next week.  Come and dance if you wanna. NC

I have finally implemented and successfully tested the IndexedDB fallback for Firefox so that now every browser, old or new, should be able to use this interface borrowed from localStorage API but made asynchronous. Asynchronous Key/Value Pairs The main purpose of this asyncStorage API is to store large amount of data as string , including base64 version of images or other files. As it is, usually, values are the bottleneck, RAM consumption speaking, while keys are rarely such big problem. However, while keys are retrieved asynchronously and in a non-blocking way, but kept in memory, respective values are always retrieved asynchronously in order to do not fill the available amount of RAM for our Web Application. Database Creation/Connection Nothing more than ... asyncStorage.create("my_db_name", function (db, numberOfItems) { // do stuff with the asyncStorage }); Storing An Item As it is for localStorage, but async asyncStorage.create("my_db_name", function (d

Programming with queues is basically what we do in any case: it does not matter if we write code in that way, we simply think in that way. This means that our logic flow is generally distributed in tasks where "on case X" we apply "logic/procedure Y" .. isn't it? The Good'ol GOTO The goto statement has been historically criticized, as well as the switch one, and in both cases is about entry and exit points in a generic workflow. Nowadays, we can say the GOTO is not needed anymore thanks to functions, where rather than thinking " when this case occurs, goto this instruction " we call the required function in charge of that specific task providing arguments or context as we go. We may then agree that GOTO is not really a must have while functions are, with all the power and flexibility we might need, and specially in JavaScript. On Block-Scope JavaScript has theoretically no block-scope concept, at least until very latest versions of ECMAScript whe