Reference: Posts

Here’s a short little description of how to use labels, breaks, and continues to cut down on loop iterations and speed up your code.

Just a quick reminder that you can drastically cut down on loop iterations by using the break and continue commands, and that there is an option to label loops to allow nested loops to stop their parents from iterating.

Well crap. 1) I love the mad4milk guys (makers of moo.fx, moo.ajax, moo.dom, prototype.lite). 2) their new framework looks AWESOME. 3) as always, their libraries are SUPER TINY.

But damn, now I have to learn something new, and maybe rewrite a bunch of crap. This is the problem with javascript. Still, when Prototype + Scriptaculous is 100K, you gotta admire their ability to crank something out in under 20K that will get you nearly the same thing.

The Mad4Milk team (the minds that brought the world moo.fx) have unleashed a brand new, very impressive Javascript library out onto the web - MooTools.

mootools is a very compact, modular, Object-Oriented javascript framework. Its unique design makes it extremely crossbrowser, easy to use, and a snap to extend with your own code. It comes with a choice of more than fifteen scripts, plugins and addons, including Effects (moo.fx) Ajax (moo.ajax), Dom Navigator (moo.dom), Drag and Drop, Sortable lists, cookies Manager and many more.

There aren’t any demos of the functionality quite yet (as of the date of this post), but you can download the first release of thise powerful little tool.

You can also check out what Jonathan Snook has to say about it, having already downloaded and worked with it a bit. He’s also created a simple tutorial on using the new library to create a drag-and-drop example.

via ajaxian (surprise):

Mike West has put some time into analyzing and understanding one of the more sticky issues in Javascript: scope.

Scope is one of the foundational aspects of the JavaScript language, and probably the one I’ve struggled with the most when building complex programs. I can’t count the number of times I’ve lost track of what the this keyword refers to after passing control around from function to function, and I’ve often found myself contorting my code in all sorts of confusing ways, trying to retain some semblance of sanity in my understanding of which variables were accessible where.

He has published his explorations as an article in Digital Web Magazine. In it he deals with the basics of scope; the this keyword in method calls, constructors, function calls and event handlers; the apply() and call() methods; and Prototype’s bind() extension to Function.

The article is illustrated throughout with code examples and includes a list of useful references at the end. A good addition to the family of online Javascript resources.

via ajaxian - note that closures are one big cause of memory leaks…

Morris Johns has gone though and written a detailed explanation of closures by example:

If everything seems completely unclear then the best thing to do is to play with t e examples. Reading an explanation is much harder than understanding example
My explanations of closures and stack-frames etc are not technically correct - they are gross simplifications intended to help understanding. Once the basic idea is grokked, you can pick up the details later.

Final points:

• Whenever you use function inside another function, a closure is used.
• Whenever you use eval() inside a function, a closure is used. The text you eval can reference local variables of the function, and within eval you can even create new local variables by using eval(’var foo = ‘
• When you use Function() inside a function, it does not create a closure. (The new function cannot reference the local variables of the function calling Function()).
• A closure in JavaScript is like keeping a copy of the all the local variables, just as they were when a function exited.
• It is probably best to think that a closure is always created just on entry to a function, and the local variables are added to that closure.
• A new set of local variables is kept every time a function with a closure is called (Given that the function contains a function declaration inside it, and a reference to that inside function is either returned or an external reference is kept for it in some way).
• Two functions might look like they have the same source text, but have completely different behaviour because of their ‘hidden’ closure. I don’t think JavaScript code can actually find out if a function reference has a closure or not.
• If you are trying to do any dynamic source code modifications ( for example: myFunction = Function(myFunction.toString().replace(/Hello/,’Hola’)); ), it won’t work if myFunction is a closure (Of course, you would never even think of doing source code string substitution at runtime, but…).
• It is possible to get function declarations within function declarations within functions - and you can get closures at more than one level.
• I think normally a closure is the term for both the function along with the variables that are captured. Note that I do not use that definition in this article!
• I suspect that closures in JavaScript differ from those normally found in functional languages.

I’ve been out of town for two weeks, so I’m just now catching up on all my javascript reading. Here’s the first of what will no doubt be a flurry of posts today.

I found this linked to via ajaxian. It’s a great article on object oriented practices using javascript. A lot of what Jonathan Snook goes over in his article on Objectifying Prototype is taken care of for you using Prototype.js’s Class.create methods and Object.extend methods. I highly recommend reading up on these functions (linked to at the bottom of the article). But this overview is really a great primer for writing class based javascript. | Read the rest »

I just found this Encytemedia post on Prototype inheratance that’s totally worth the read. Additionally, at the end he (Justin Palmer) points to Dean Edward’s Base script that provides an interesting alternative.

…All that has since changed. Thanks to the persuasion of The Javascript MacGyver, Sam replaced the Object.prototype bits in favor of Object.extend and Object.inspect. With this decision, however Prototype’s inheritance scheme can be messy, and it’s certainly hard to read if you don’t spend time trying to really figure out what’s going on.

Unlike almost every other programming environment, javascript has one big drawback: you have to deliver it to the client. This can result in a big payload of code you’re dropping on your user and there isn’t a whole lot you can do about it.

You can lazy load the javascript so it’s only on demand. You can optimize your code as best you can so that functionality that’s not really needed isn’t present, and other functionality is written as succinctly as possible. You can set up your server to deliver the javascript g-zipped if the browser supports it.

But one simple thing you can do is just delint your code - remove all the tabs and comments and line breaks. It makes for unreadable files, but you just keep a marked up version and a compressed version. For example, Andy Lottmann took the prototype library and knocked it down from 55K to 35K or so. | Read the rest »

Hey gang,

As part of my previous post on ajax frameworks, I went ahead and created a page here on the libraries I use and why. I link to the download (the version I use, which usually is the released version but in some cases not; I also talk about what’s different when this is the case) and documentation.

I’d love to hear back from you about libaries you like and why. I’ll add them to the page.

via ajaxian

Particletree has posted two parts in a series for designers trying to develop site structures that will use Ajax for some of their functionality - “A Designer’s Guide to Prototyping Ajax”. | Read the rest »

via ajaxian: read the full article

The DOM can be a painful beast at times. When you ask for the childNodes of an element, most of the time you’re just wanting the element nodes only and you’d like to completely ignore the text nodes. Using Prototype, you could write something like the code below:

element = $(element);
element.cleanWhitespace();
$A(element.childNodes).each(function(element) {
  element.setStyle({color: '#ccc'});
});

That would be a quick fix, but remember, we’re not supposed to be repeating ourselves. | Read the rest »