This is a quick one already discussed during my recent workshop in Warsaw, a concept rarely considered or adopted from JS developers. What Are Polyfills If we are updated enough to know ECMAScript 5th Edition, we probably know all possible shims and fallbacks for Array extras as well (e.g. Array.prototype.forEach ). Polyfills are simply snippets able to bring features already available for most recent browsers into those not updated yet. Why Polyfills If we develop with present and future in mind, we can take advantage of most recent techniques and solutions in order to both speed up via native support, where available, and maintain our application just stripping out code once all target browsers support them natively ... isn't this cool ?! Polyfills Side Effects The most common side effect of a polyfill is performances impact . The Array::forEach is already a good example of decreased performances. If we think about a forEach, it's nothing different than a classic for loop , e...
There are way too many ways to stub functions or methods, but at the end of the day all we want to know is always the same: has that function been invoked ? has that function received the expected context ? which argument has been passed to that function ? what was the output of the function ? Update thanks to @bga_ hint about the output property in after notification, it made perfect sense The Concept For fun and no profit I have created a prototype which aim is to bring a DOM like interface to any sort of function or method in order to monitor its lifecycle: the "before" event, able to preventDefault() and avoid the original function call at all the "after" event, in order to understand if the function did those expected changes to the environment or to a generic input object, or simply to analyze the output of the previous call the "error" event, in case we want to be notified if something went wrong during function execution the "handlerer...
OK, I know, the well known sqlite3 module is cool and all the glory to it ... well, it didn't work in my case :( The Why node-gyp is great but it's not as portable and does not scale as I'd like to. If you try to use sqlite3 via npm in Arch Linux ARM , as example, even if the native sqlite library is there and usable that won't work ... moreover ... What really bothers me is that node-gyp does not update within the system as any other system package would do. You need to rebuild, recompile, re-do everything, even if you distributed a specific linux version that trust the package manager for updates and does not want to bother users with build tasks. This is quite common in embedded hardware and related Linux distro so I've asked myself: why on earth I cannot simply pacman -Syu once in a while and just have automagically built for me the latest version of sqlite3 , the one the whole system is using and trusting anyhow, together with any other update including...
Comments
Post a Comment