modisposition

There are cases where JS coercion may be wanted/needed/necessary, at least logically speaking. A classic case is a list of primitives, e.g. strings, or numbers, and a check we would like to perform without creating a new function each time . // recycled function function alreadyThere(value) { // wanted coercion, no cast needed return value == this; // shitty code, logically speaking // one cast per iteration return value === "" + this; } var listOfNames = ["Me", "You", "Others"]; // the pointless check listOfNames.some( // the recycled callback alreadyThere, // the *passed as object* this "You" ); // will be true Now, for above specific case anyone would use an indexOf but this is not the point. The point is that in some case we may want to do more complicated stuff and compare the result with this // know if word was already in the dictionary function alreadyThere(value) { return value.toLowerCase() == this; } // co...

A common use case for getters and setters is via scalar values rather than complex data. Well, this is just a programmer mind limit since data we could set, or get, can be of course much more complex: here an example function Person() {} Person.prototype.toString = function () { return this._name + " is " + this._age; }; // the magic identity configuration object Object.defineProperty(Person.prototype, "identity", { set: function (identity) { // do something meaningful this._name = identity.name; this._age = identity.age; // store identity for the getter this._identity = identity; }, get: function () { return this._identity; } }); With above pattern we can automagically update a Person instance name and age through a single identity assignment. var me = new Person; me.identity = { name: "WebReflection", age: 33 }; alert(me); // WebReflection is 33 While the example may not make muc...

Update more than a person asked me more details and here I am: The workshop will be Thursday 19th of May on Track 3 and from 9am to 5pm. Registrations open at 8am and to be sure everything I have written is correct, please double check the schedule . This time is not about my uncle, this time is about my workshop in Warsaw, during Falsy Values Event , and this is its description: Massive rumours behind buzz words such HTML5 and ES5, the latest updated specification about JavaScript programming language, have surely increased confusion about where is JavaScript today, and how this language should be in the future. Unfortunately, we all know that many users are still trapped behind really outdated browsers and their relative JS engines. This could lead us to be stuck with old coding patterns and style but here I am to show most recent performances oriented techniques that could make the transition to this new specification less painful and efficient Size matters: code size oriented tech...

In this year I have done more tests than ever over all these tiny and shiny portable devices and I'd like to share with the Web community the result of my experiments at the end of this 2010. " why not before xmas, ffs? " ... because whatever you bought as present for you or your relatives, will hopefully be updated soon with latest systems and related browsers :) The Dedicated WebKit ... Nightmare! As ppk mentioned already in Front Trends conference, we have basically only 5 browsers in our desktop PCs/Macs/Linuxes machines. Much more fun comes when we think we are dealing with a single browser, a generic WebKit based one, and we discover that there's no browser similar to another one, every bloody device has its own implementation with few exceptions represented by Safari Mobile, almost the same in iPad, iPod, and latest iPhone. WebKit and CSS(3) Even if the CSS engine is basically the same for every single specific implementation, the number of supported, and ...

When I read tweets like this one I cannot avoid a quick comment but the reason I am posting, is simply to explain that every time we write a web page/application, we are dealing with at least 4 different layers. Moreover, this post is complementary for few slides I have introduced at front-trends, specially regarding the " avoid classic OOP emulation when not necessary " point. Layer #1: JavaScript Libraries We all know the DOM is a mess, and this is most likely the reason we chose a JS library rather than deal directly with possible problems we can have when we develop an x?HTML page. Even if many developers don't care, I keep saying that every millisecond gained in this first layer, the page itself, is important. Moreover, if we have a good understanding of the JavaScript programming language, we can easily realize that all these " Java Pretending Style Frameworks " emulating classic inheritance and OOP are not easier to maintain neither faster for what we...

Update some point has been made more clear, thanks to Dmitry Soshnikov for suggestions. Forget the global undefined Too many developers relies into undefined variable in ES3, and all they should do is to set undefined = true on global scope and see if the application or all unit tests break or not. I am going to demonstrate how simple is, at least in ES3, to redefine by mistake the global undefined. // inside whatever closure/scope function setItem(key, value) { this[key] = value; } // later in the scope, setItem may be reused // through call or apply for whatever object setItem.call(myObject, myKey, "whatever value"); // if for some reason the first argument used as context // is undefined, the "this" will point to the global context // if for some reason the second argument used as key // is undefined, the accessor will cast it as undefined string // the result of latter call with these two // common or simple conditions // is the quivalent of: window.undefin...

just a quick post about ES5 Object.create performances. While in More ES5 Friendly Patterns paragraph I have described how to use new ES5 features to create instances in a better way, I have never tested directly performances against classic ES3 pattern. The Benchmark Logic Pretty simple, create a new object with a " privileged property " plus an inherited one. The test prototype looks like this object: var proto = {toString:function () { return this.name; }} The assumption is that somehow the object should be able to return it's name, which is not shared via prototype. ES3 Game I hope I don't have to explain this piece of code: function F(name) { this.name = name; } F.prototype = proto; To test above classical pattern, all we need is to confirm this behavior: var o = new F("instance"); alert(String(o) === "instance"); ES5 Game Using an updated browser, it should be possible to replicate ES3 behavior via this piece of code: var o = Object....

We have dozens of best practices to improve performances. We also have common practices to accomplish daily tasks. This post is about the most used JavaScript ArrayLike Object, aka arguments , and its performances impact over basic tasks. Why arguments While it's natural for JavaScripters to use such "magic" variable, as arguments is, in many other languages everybody knows it does not come for free and it is rarely used. <?php function myFunc() { // function call for each execution // rarely seen in good PHP scripts $arguments = func_get_args(); } ?> One clear advantage in PHP, Python, and many others, is the possibility to define a default value for each argument. <?php class UserManager extends MyDAL { public function exists($user='unknown', $pass='') { return $this->fetch('SELECT 1 FROM table WHERE user=? AND pass=?', $user, $pass); } } ?> This approach may brings automatically developers to code as ...

As usual, as soon as I decide it's time to go to sleep, somebody :P has to post a stunning benchmark about a selector matcher ... did I shut down? No, I had to read the entire source code of the library, and this is my quick summary, but consider I am tired ... NWMatcher , A Selector Monster First of all, I did not know or remember this project and I must congrats with Diego Perini for different reasons. The first one is that Diego used almost all best and unobtrusive technique to make it as reliable as possible, which is good, the second one is that Diego introduced something new to achieve its goal: create a Ferrari matcher via pre- compiled functions. About NWMatcher It is a lightweight stand alone library (so far, but already namespaced) which aim is to standardize some common DOM related task. The initial aim was to create a faster way to understand if a node matches a specific selector, something truly useful with event delegation. About The Technique To make things as fas...

Update - Now We Do Right Thanks everybody for your tests and contributions. For those interested about why we were doing wrong please read both post and comments but for those just interested about the best way so far to serve correctly one or more font-face, this is the hack: @font-face { // define the font name to use later as font-family font-family: "uni05_53"; // define the font for IE which totally ignores local() directive src: url(../font/uni05/uni05_53.eot); // use local to let IE jump this line and // redefine the src for this font in order to let // other clever browser download *only* this font rather than 2 src: local("uni05_53"), url(../font/uni05/uni05_53.ttf) format("truetype"); } You can test directly this technique in my HTML5 Prime Directives Test Page Credits Paul Irish for its Bulletproof @font-face syntax Mikuso, comments, for his suggestions about server configurations, instantly followed by Weston...

In this same blog I talked different times about Singleton Pattern , in latter link " poorly " implemented in PHP 5. I say poorly, because being Singleton a pattern, there are many ways to implement it and via PHP 5.3 things are more interesting. There are several ways to define a Singleton class and to extend it, being able to automatically create another one that will follow that pattern. Here is my implementation, which is extremely fast, logic, and simple as well. <?php // Singleton :: The WebReflection Way namespace pattern; // this is just a pattern ... // so no new Singleton is allowed // thanks ot abstract definition abstract class Singleton { // note, no static $INSTANCE declaration // this makes next declaration a must have // for any extended class // protected static $INSTANCE; // @constructor final private function __construct() { // if called twice .... if(isset(static::$INSTANCE)) // throws an Exception ...

While I was creating a stand alone implementation of the LSSP described in my last HTML5 sessionStorage project , I did some test and bench as every Agile developer should do. Well, what I have discovered, is that apparently Internet Explorer could perform some common task better than any other browser, at least in my good old Intel Centrino 1.6 Ghz. I have created a benchmark page able to freeze my Firefox 3.5.2, to ask me if I would like to continue an Array.join execution with an average score that points out my Internet Explorer 8 wins with a score under 300 milliseconds against Chrome, Firefox and Safari. As summary, is my Centrino dead or there's something we all did not consider about JScript engine? P.S. Opera 10 beta 2 seems to score about 130 milliseconds as average, good stuff!

Array.forEach(document.all, function(node, i, all){ // vice-versa project }); well, there are few things I can say here, and first one is: please, if interested, help me! The second one is my vision, a web where rather than criticisms, there is more collaboration to obtain good overall performances improving code quality. This is not my old JSL project, this is a new groove, a new project, a non library , something I hope you will all appreciate. But, if not, I am here to discuss about it :) vice-versa project Have fun with Web Development! Update Implemented a TaskSpeed test file for vice-versa project. Here first results ordered by average. browser Pure vice Moo qoox dojo YUI AVG Dom versa Tools doo -------------------------------------------------------------------- Safari 4 198 114 392 205 246 410 260.83 Chrome 1 251 273 589 279 336 692 403.33 Opera 10 215 206 764...

Update now it works with Internet Explorer 7 and 8 with O3D plug-in enabled. Today, via ajaxian , I discovered the new Google O3D project and as a nerd first, and a developer after, I instantly read the API. Few seconds and I spot this: Use the V8 engine OK, OK, whatever code you read there will not instantly work ... you have to understand the library and how to retrieve the dreamed eval function to make JavaScript execution possible inside the extremely fast V8 engine. Obviously V8 integration is great with FireFox and other browsers, but a bit different in Internet Explorer. This limitation is about the DOM manipulation, something that would make IE a good browser, but everything else, executed via V8 engine and without browser engine references , will perform 5 to 100 time faster. Function creations, optimized loops, numbers, string manupulation, etc etc ... if we could use a little plugin to fully integrate V8 inside Explorer, we could all forget nowadays benchmark because it w...

It is an extremely common task and one of the most used prototype in libraries and applications: Array.prototype.slice The peculiarity of this prototype is to create an Array from an Array like Object such arguments, HTMLCollection, other kind of lists as jQuery results. Every browser, except Internet Explorer, allows direct calls via native prototype obtaining, obviously, best performances. In IE, we have different ways to make this task possible, and these ways are mainly classic loops, or the isArray check to know when it is possible to perform the native call or not. isArray = (function(toString){ return function(obj){ return toString.call(obj) === "[object Array]"; }; })(Object.prototype.toString); Even using a closure, above function could slow down performances, specially in those libraries where Array conversions are performed almost everywhere. As we all know, Internet Explorer behaves weird "sometimes", and one of the weirdest things is tha...

Few days ago I wrote a post about this argument , proposing an alternative "best option" way to use an injected parent in each method. As soon as more developers read my post, more sparkles came out from the fire: true classical inheritance simulation via missed methods in the chain, exception during methods execution that could trap the temporary injected parent, and other interesting stuff again. At the end of all these tests, benchmark, and libraries evaluation, I decided to step backward about my proposal, making things simple, logic, and extremely fast (as much as possible). My Conclusions if we inject a parent, we have to change and/or wrap the original method, adding noise in the execution and inevitably more operations to perform (read: less performances) for each inherited metod, even if it is the same of the parent one, we need to add functions and code which means more RAM and less portability more we over-mess the simple JavaScript inheritance stack, less control ...