modisposition

After @szafranek hint and suggestion, wru landed almost at the end of this Wikipedia List of unit testing frameworks page. If you use this tweet size hand made imperfect script in the wikipedia page console: a=q="querySelectorAll",[].map.call(document[q](".mw-headline,.wikitable"),function(v,i){i%2?a=v.textContent:o[a]=v[q]("tr").length},o={}),o You gonna see that JavaScript is third when it comes to number of test frameworks ... and not sure that's good, anyway, here a quick description of mine. About wru You can find most info in github page itself but essentially wru is a generic purpose, environment agnostic, JavaScript tests framework compatible with both client and server, where client means every bloody browser, and server means Rhino, node.js, and recently phantom.js too. To be really fair, wru is not exactly a unit test framework since it does not provide by default anything related to mocks or stubs. However, wru is so tiny and unobtru...

With " Sizzle event", the challenge about libraries will move from the coolest/fastest selector engine into the coolest/fastest way to use it for library purpose. Since Sizzle will be just one of them, thanks to our natural behavior ( read: re-create the wheel ) it is possible that there will be more selector engines around the net. So, why we could not create our own library that does just what we need and nothing else, maintaining a decent size and performing like a jaguar :D ??? Here a truly basic example about how to create your own library, basing it over a generic selector engine or generic library (or just its engine, if you prefer one) // our wonderful library constructor function myQuery(){ // just in case we prefer another name for the constructor // this code is "name proof" var callee = arguments.callee; return this instanceof callee ? this : callee.prototype.init.apply(new callee, arguments) ; }; // add some...

A common pattern to develop JavaScript libraries is to use different behaviours inside methods, and based on browser, or browser plus its version. For about 80% of cases, these behaviours are Internet Explorer dedicated. This approach is good enough, otherwise we could not have a wide variety of libraries to choose, but is this way to develop libraries the best one? These are some pro concepts: libraries could be usually merged into a single file, so we can add only one script tag, and for every browser libraries maintenance or improvements are focused into one, or more, constructor, function, or method The expected result is, usually, a method that is capable to understand which browser is running them, and what to do for that specific case. // common libraries development pattern function myGorgeusLib(){}; myGorgeusLib.prototype.sayHello = function(){ if(self.attachEvent) attachEvent("onload", function(){alert("Hello")}); else if(self.addEventLis...

Comet is a particular technique to interact asyncronously with the client. Instead of perform a lot of calls using Ajax (polling) the server is able to send to client, whenever it wants, a generic response. Unfortunately in the PHP world there's no simple way to implement this kind of technique and I'll write more posts to explain better how to implement this library and what is generally possible to do, or not possible yet, with Comet idea inside a dedicated PHP environment. At the moment, the only thing you can do is read documentation inside JavaScript and PHP files (truly few lines) and test the first basic example, a server side clock in less than 30 lines of mixed code. As last information, Phomet comes with all necessary to be optimized on client, and its final result is about 1.57Kb on client, and ridiculously 4.52 Kb on server, comments included :) Here is the download , unpack them into your localhost, and go into phomet folder to view the first demo. Compatibility? I...