modisposition

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

He traveled along the path of self denial through pain, through voluntary suffering, and conquering of pain, through hunger, thirst and fatigue. He travelled the way of self-denial through meditation, through the emptying of the mind of all images. Along these and other paths did he learn to travel. He lost his Self a thousand times and for days on end he dwelt in non-being. But although the paths took him away from Self, in the end they always led back to it. Although he fled from Self a thousand times, dwelt in nothing, dwelt in animal and stone, the return was inevitable; the hour was inevitable when he would again find himself, in sunshine or in moonlight, in shadow or rain and was again Self and he again felt the torment of the onerous life cycle.

I know you already hate the title, but that's how I called one paragraph of my precedent post: Better JavaScript Classes . This post is mainly dedicated for both libraries authors, and those Classic OOP Developers that still think JavaScript should be used in a classic way. _super or parent Are Problematic! It's not just about performances, where " the magic " may need to replace, wrap, and assign runtime everything in order to make it happens, it's about inconsistencies, or infinite loops, or hard debug, or disaster prone approach as well, since as I have already said instances have nothing to do with _super/parent .... so, how are things? Thanks for asking! Real OOP Behavior It's the ABC, and nothing else, if we call a parent/super inside a method, this method will execute with a temporary self/this context. This means that the instance will be still: an instanceof its Class only that method will be executed, it is possible to call other super/parent accord

Update This post continues here, in the JavaScript _super Bullshit one. In my precedent post I have discussed about few common JavaScript errors, included the classic new Class() call to retrieve a runtime created function, populating its prototype. While my suggestion is both semantic and reasonable, I am pretty sure nobody on earth will ever implement that native Function wrapper , and this is the reason I am posting again, this time hopefully with a better suggestion. JavaScript Class Abstract Concept It's extremely hard to understand for those with classic OOP background but JavaScript has no Classes , just objects, where functions are first class objects but still objects! Assumed this, we can try in any case to think about a JavaScript Class as a " function which aim is to create instances of function itself ". What Is Wrong Right Now What I argued about in my precedent post is that this statement is too often unconsidered: // try with Mootools or some other libr

... I won't write any introduction, but I'll let you comment, OK? for loops (plus ++i) for(i = 0; i < 10; i++){} // global i defined for(var i = 0; i < something.length; i++){} // cache the length if it won't change during the loop // associate once only under certain conditions to speed up for(var i = 0; i < 10; ++i) {} // there is absolutely nothing wrong in above loop Few people told me something like: " doode, if you use ++i at the end you need to write i < 11 'cause i will be 1 inside the loop " ... basically the for loop has been rarely understood, let me try again: // directly from C language, 1972 for( // optional inline declaration, coma accepted for more vars ; // optional condition to verify // if undefined, it loops until a break is encountered // this condition is performed BEFORE the first loop // if false, the loop will never be executed ; // optional POST operation, it will never be executed // if

As discussed in my new year Ajaxian post , the Flash Player could provide some truly good info about the current user. I have tried before to create a sort of "perfect bridge" to actually drive ActionScript directly via JavaScript. Unfortunately, the layer added by the ExternalInterface is not light at all and things would move so slowly that it won't be worth it. While in my post comments I have showed an example about how it is possible to export info from ActionScript to JavaScript, what I am describing right now is a sort of "general purpose bridge" to bring, statically and stateless, whatever info we need/want from whatever ActionScript 2.0 file/library we like, starting from the root. Basic Example <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" /> <title>AS2Bridge

First off, thanks to all who came out to our shows within the last 2 weeks, we had a blast playing. Some news is that though we recorded an LP and more's worth of material in October (LP will be out in March, leftover songs will be put on a cassette, also to be out in March) we are going to be recording 5 or so more brand new songs in early February. We've been writing up a storm and were really happy with how these jams are coming out. Some other good news is that our friend Nick from the talented band Seasick is turning 25 on March 12 and to celebrate his quarter of a century of life he is throwing a smashing birthday show with the likes of PISSED JEANS, RIVAL MOB, SOCIAL CIRKLE, RATIONAL ANIMALS, SEASICK and yours truly. We are super excited to play this show and it should be a fucking blast. Mark your calendars. We have a show coming up this Saturday the 16th of January at good ol' Tommy's Tavern in Greenpoint, Brooklyn. We are playing with some great bands and ther

The most famous and W3 friendly technique to serve an SWF has been described in this excellent A List Apart Article ages ago. Unfortunately there are few problems with that technique, and being Flash Player still widely adopted, plus nobody has created yet a HTML5 friendly Satay method, here I am with this proposal/suggestion. Satay Problems There are at least a couple of problems with the good old Satay method: double SWF request , performed by almost every browser SWF impossible to cache , due necessary queryString for each different SWF so that classic c.swf will be required for each call Object Tag Behavior The Satay method is based over the assumption that an object tag, with a forced type, will help the browser to recognize the SWF. At the same time, if Flash Player is not present or it has been disabled, Satay trick allows us to provide an alternative content inside the Object itself. What we should be aware is that Internet Explorer won't execute any script tag inside

Something every web developer should do, is test whatever Web related stuff into new generation devices such netbooks , low cost notebook, old PCs and/or smart phones . If a non techie user surfs a website and the latter one horribly slows down his " device ", in the most common case, and specially if the website is " famous ", this user will blame its wonderful piece of technology, rather than the infamous designer/developer that created the problem. This happened recently, as example, in Hotamail and with the latest Sherlock Holmes Flash banner. The Solution Is Simple Starting with the fact that Junior Flash developers are as responsible as advertisement hosts, unable to filter proper banners from annoying one , if a company would like to provide these heavy computation banners it should simply make a little investment as a whatever Atom CPU based device is (even just an all in one motherboard is enough!). Even better, it could recycle a generic good old Pent