Posts Tagged ‘javascript’

« Older Entries

Pass that Interview 2: Understanding Recursion

March 1st, 2010

Recursion is one of the most misunderstood concepts in software development. Truthfully, in modern software development it has been almost completely replaced by iterative control structures (loops). In front-end UI-layer development, it is very rarely used. However, it's very common that you'll be asked questions about recursion during an interview. Why? I compare it to airlines hiring Air Force and Navy fighter pilots. No, they're never going to need to barrel roll a commercial jet-liner but the fact that they understand and know how to do it makes them more complete pilots. Similarly, understanding concepts such as recursion opens up new ways of thinking for engineers.

In its most simple terms, a recursive function is a function which returns a call to itself. Naturally, one has to be careful with this type of construct as it's easy to create an infinite loop. A typical recursive pattern involves breaking a problem into smaller pieces (such as searching a large data set) rather than performing a process multiple times as in iteration.

A common interview question may involve implementing a factorial function using recursion. Let's take a quick look at how we could do this:

function fact(x) {
    if(x > 1) {
        return x * fact(x-1);
    } else {
        return 1;
    }
}

By including a call to itself in the return, the program builds up and subsequently tears down a call stack. Rather than looping over an operation, we're breaking the problem into smaller pieces until it's simply returnin the value we passed in.

Drawbacks of Recursion

Now that we have an understanding of how to create a basic recursive function, we need to be able to discuss the drawbacks of this approach. First, in most programming language, the loop control structures (for, while, etc.) are optimized for speed and will (in the vast majority of cases) be faster.

Second, the memory overhead for allocating all of those functions can grow massively; especially in dynamic languages like Javascript. In our above example, if a user called fact(200) we would incur the overhead of creating 200 function instances in memory. You can see that for large operations this will get very heavy.

Stand Out

For the most part in front-end development, you won't be delving deeply into recursion; but armed with this basic understanding of the topic, you'll stand out from other candidates who aren't familiar with a wide array of software engineering concepts.

Comments »

Posted in briancrescimanno.com

Tags:

Pass that Interview 1: Mimic a Class in Javascript

February 10th, 2010

Javascript, unlike most object-oriented programming languages, does not have the concept of Classes. Instead, Javascript uses a model in which objects are created, cloned, and enhanced by creating copies of the objects (it's loosely based on the Prototype pattern). There is a lot of power in this Prototypal system and people like Douglas Crockford have shown how Prototypal inheritance can be implemented in Javascript. This type of work is really cool; unfortunately it's not generally well-known or well-understood and many developers wish to use Javascript to simulate the more familiar Classes & objects as seen in languages like Ruby and Java.

Due to this simulation being common practice, the following has become a fairly common interview question:

How do you create a class in Javascript?

The answer is a bit wonky; but pretty simple to follow:

» Read more: Pass that Interview 1: Mimic a Class in Javascript

Comments »

Posted in Development

Tags:

My Impressions of Google Web Toolkit (GWT)

February 8th, 2010

Recently I've been asked several times for my opinion on the Google Web Toolkit (GWT)  and I've given much the same response each time. Now, it's easier to consolidate my thoughts and share them with everyone via my blog.  I want to preface this post by stating, as I always do, that I have not taken a "deep-dive" look at GWT and, due to my stance below, I haven't seen a reason to do such research.  I also want to state up-front that I don't believe there's any inherent flaw in GWT that prevents me from using it; nor do I think it's "bad technology." Finally, I've done my best to not allow my general distaste for Java influence my opinion of GWT.

I do not believe that GWT offers a unique value proposition as a platform that establishes any advantage over other Web development platforms such as traditional HTML and CSS or Adobe Flex. Additionally, there are some clear areas in which GWT lags behind these counterparts. » Read more: My Impressions of Google Web Toolkit (GWT)

Comments »

Posted in Development

Tags:

How Self-Executing Anonymous Functions Work

September 24th, 2009

In my recent post on creating a jQueryUI widget, I referenced the concept of self-executing anonymous functions. I've actually had a few questions come up at the office lately about how they work, so I figured turning it into a blog post might not be a bad idea. It's an important concept in Javascript many don't know about. Others know how to use them, but don't really understand how or why they work. Today I'll cover step-by-step how to go from a traditional function to a self-executing anonymous function; hopefully it will be clear at the end how these things work.
» Read more: How Self-Executing Anonymous Functions Work

Comments »

Posted in Development

Tags:

Create a Basic jQueryUI Carousel Widget

September 17th, 2009

One of the topics that was of great interest at #jqcon was jQueryUI and it's impressive widget library.  What didn't receive as much attention was how exactly to go about creating widgets that are compatible with jQueryUI.  In this first of a series of articles in jQueryUI development, we'll cover the basics of creating a simple jQueryUI widget.  In future articles, we'll look at how to pair widgets together using the Publisher / Subscriber (pub/sub) pattern.

This carousel is probably not quite robust enough to be deployed to production and I urge you to avoid copying and pasting this code into your live site. This basic carousel aims to teach you how to build one yourself as well as how to build a jQueryUI widget.

Create the Basic HTML Markup

To begin, we need a basic page and some photos thumbnails to work with. The thumbnails, as you'll see later, can be any size you choose and our carousel will expand to fit them. Note especially that we're only including some basic shell markup.  There are a few good reasons for this decision: First, it keeps our basic document clean and free of extraneous markup. Second, it is far less work for people implementing our widget—and fewer potential points of error in their process.

<div id="slide">
    <div>
         <img src="img/carousel/0_10.jpg" width="78" height="29" alt="" />
    </div>
    <div>
         <img src="img/carousel/0_11.jpg" width="78" height="58" alt="" />
    </div>
    <div>
         <img src="img/carousel/1_6.jpg" width="78" height="58" alt="" />
    </div>
    <div>
         <img src="img/carousel/1_4.jpg" width="78" height="58" alt="" />
    </div>
    <div>
         <img src="img/carousel/0_9.jpg" width="78" height="58" alt="" />
    </div>
</div>

For demonstration purposes, I've chosen the Cupertino theme available for download from the jQueryUI ThemeRoller application. You can choose any theme you desire—or create your own. Also, you can see I've created a reference to a  carousel.js file. We'll create this file as we continue.

Create the basic framework of a jQueryUI plugin

Now that we have our basic structure in place for the carousel, we can begin to create the javascript that will control the animation and interaction. jQueryUI provides a great construct called $.widget() that will encapsulate all of the functionality of the widget within a single namespace and construct. Let's start by creating a basic widget:

» Read more: Create a Basic jQueryUI Carousel Widget

Comments »

Posted in Development

Tags:

Quick Javascript Tip: Pass an Options Hash

July 13th, 2009

A quick Javascript tip that I pass along in a lot of code reviews is to make use of an options object as a hash to pass a large number of parameters to a function without writing each one individually.  For example:

function doSomething(id, someParameter, anArgument, optionC){ };

vs.

function doSomething(id, options){ };

By encapsulating the 3 additional parameters into an options object and passing them individually, you make for cleaner code.

A quick caveat is to check the options object to ensure that all of the necessary properties exist before running your function.

Comments »

Posted in Development

Tags:

Workaround: Form Submit Method Doesn’t Fire Submit Event

May 14th, 2009

Recently I've become even more frustrated than I've been in the past with the disparity between Javascript Events and Javascript Event Methods.  This time it was specifically related to form submission.  Currently, despite the specification stating otherwise, browsers do not fire a submit event when a form is submitted via the submit() method.  Of course, this means if you have an event listener tied to that submit event (say, for form validation) it will never happen because the event hasn't been fired.  However, we can work around this limitation using a little Javascript magic!

Essentially, we can overcome this limitation by using the dynamic nature of Javascript to our advantage.  Even methods that are "native" to the browser can be extended by wrapping them.  As usual, there are some differences between browsers we have to account for.  Most notably, Firefox and other browsers that adhere to the DOM Level 2 Specification support reading and writing to the HTMLFormElement object.  IE, naturally, does not allow this so we have to take a more direct approach. In the example code, we use Prototype's Element#fire method which only allows for custom events. However, you could replace that by generating a standard event manually.

function fakeSubmit(event) {
    var target = event ? event.target : this;
    /* Fire a submit event */
    $(target).fire("form:submit");
    /* Call the real submit function */
    this._submit();
}

if(window.HTMLElement){
    /* DOM-compliant Browsers */
    HTMLFormElement.prototype._submit = HTMLFormElement.prototype.submit;
    HTMLFormElement.prototype.submit = fakeSubmit;
} else {
    /* IE does not expose it's HTMLElement object or its children
        Let the document load so all forms are accounted for */
    document.observe("dom:loaded", function(){
        for(var i=0; i<document.forms.length; i++){
            document.forms[i]._submit= document.forms[i].submit;
            document.forms[i].submit = function(event){
                var target = event ? event.target : this;
                $(target).fire("fake:submit")
                /* Call the real submit function */
                this._submit();
            }
        }
    });
}

With this in place, we can simply watch for our fake:submit event to fire and act upon it.  As I said previously, you could generate the submit event and fire it manually if you want to stick to using standard events--but this solution takes some of the cross-platform issues out of the way for you.

Edit: I've updated this code to fix a bug in IE6.

Comments »

Posted in Development

Tags:

Motion Easing Equations for Script.aculo.us

November 20th, 2008

Animation and motion are becoming more and more commonplace in modern web application design.  It's no surprise then that many Javascript frameworks provide sets of tools that allow you to easily add this motion to your application.  MooTools and jQuery both integrate a set of easing equations to improve upon the look of linear animation.  Script.aculo.us, however, lags behind in that while it does provide some functions to help the animation appear more "natural," it lacks a truly elegant solution.

Quick Link: View a Demo

Back in 2003, Robert Penner wrote a book on animation using Flash and with that book released a set of "easing equations" that could create natural-looking motion in Flash.  These equations attempt to model real-world motion behavior on the screen; and they do a remarkably good job of it!  So well, in fact, that both MooTools and jQuery have adapted Robert's easing equations into their animation libraries.  After searching in vain for a while to find an implementation of these equations using Script.aculo.us, I decided the best thing to do was create my own--not an overly easy task since Robert's equations were not directly compatible with the "Script.aculo.us way" of handling animation.

Today I'm releasing easing.js for Script.aculo.us 1.8.  I consider this version to 0.8 of this plugin since it does not succeed in porting the entire range of equations from Robert's original set.  The missing equations are:

  • EaseInBounce
  • EaseInOutBounce
  • EaseInElastic
  • EaseOutElastic
  • EaseInOutElastic

The elastic functions should be fairly simple to port over; I simply haven't done them at this point.  The bounce functions, however, were originally written by Robert in such a way that they don't have easily identified counterparts in the Script.aculo.us world.  I will continue my efforts; but I do hope that in the true spirit of open source that others can contribute and improve upon my work.  Ultimately, I hope to submit this to Thomas for inclusion in the Script.aculo.us distribution.

I have provided a quick demo of each effect which is also included in the download package for your convenience.  Please feel free to provide any feedback in the comments.  I hope you find this contribution useful in your projects!

Download easing.js for Script.aculo.us 0.8

Comments »

Posted in Development, Releases

Tags:

Prototype Basics: Creating a Javascript Class

September 24th, 2008

Javascript is, by it's nature, not an object oriented language.  However, everything in Javascript is an object.  So what you have are using objects to write procedural code; a truly intriguing concept.  It brings to light that having objects does not make a language object oriented.  Today I want to talk about the other two important concepts of object-oriented programming in Javascript--classes and inheretance.

In object-oriented programming, a Class is used to define an object; that is, it defines what characteristics an object has (its properties) and what it can do (its methods).  Javascript does not allow for either of these concepts in its native implementation (though we can work around this limitation with some clever programming that I'll cover in another article).  Today I want to look at how the Prototype library provides an easy way for developers to create and extend classes and objects of those classes.

We're going to start with creating a basic class.  Most tutorials at this point degenerate into some silly example involving a car, or an animal.  Given that I'm trying here to provide some real world perspective, I want to look at something we might actually try to implement.  In this case, we'll use a photo viewer.  We want to set up a viewer that can be passed a photo and display it.  Then, we'll use inheretance to extend the class to allow for effects.

Creating a Basic Class

var PhotoViewer = Class.create({
    initialize: function(){
    }
});

There are two important things to note in this example:

  1. The Class.create() method is a prototype method that sets up a class for us.  The primary benefit we get from this is that the class can extend another class (which we will do shortly).
  2. When a new object of this class is created, it will automatically call its initialize method.  In Prototype, initialize is the class constructor.

Now we need to add some methods to our class:

var PhotoViewer = Class.create({
    initialize: function(){
        this.photoContainer = $('container');
    },

    showPhoto: function(url){
        var imgEl = new Element("img", {src: url});
        this._show(imgEl);
    },

    _show: function(imgEl){
       this.photoContainer.update(imgEl);
    }
});

So now we've created our first class using Prototype.  The showPhoto() method is a public method that can be called from outside the object.  A URL for an image is passed into it and a new image element is created using that URL.  The _show method is a "private" method that cannot (in this case, should not) be called from outside the object.  It handles the displaying of the element.

Note that Javascript has no concept of public vs. private methods; therefore users could technically call this method wherever they see fit.  The _methodname convention is sometimes used to denote that a class should be considered private by developers and thus not called.

Extending a Class

Now that we have created our basic PhotoViewer class, let's create a class called AdvancedPhotoViewer that extends PhotoViewer to add animation to the image loading.

var AdvancedPhotoViewer = Class.create(PhotoViewer, {
    initialize: function($super){
        $super();
    },
});

There are again two important new concepts introduced here:

  1. Notice that the Class.create() method now has two arguments, the first is the parent class.  By defining a parent class, our class now has access to all of the properties and methods of its parent.
  2. The $super() method calls the method within the parent class that has the same name as the method in the child class.  By calling $super() in the initialize method of our AdvancedPhotoViewer, we call the initialize method of the parent class.  Were we not to call $super() on a method that has an identically named method in the parent class, the method would overwrite the parent method (which there are many times you want to do, which is why this is left for you to decide whether or not you wish to perform all of the tasks from the parent method first). You will see an example of this in a moment.

Now we want to add some animation using Scriptaculous.  We want the element to begin hidden and then appear using a fade-in transition.  For this, we can override the _show() method to call our animation rather than simply calling update():

var AdvancedPhotoViewer = Class.create(PhotoViewer, {
    initialize: function($super){
        $super();
    },

    _show: function(imgEl){
        /* Notice we don't call $super as we want to override the original method */
        this.photoContainer.insert(imgEl.hide());
        new Effect.Appear(imgEl, {fps: 50, duration: 0.5});
    }
});

As you can see, we've added code which will cause the element to fade in rather than simply appearing.  Notice also that even though we never explicitly created it within the AdvancedPhotoViewer class, we can access the this.photocontainer property because we called the parent constructor that defines it.

So there you have it; a brief tutorial on creating and extending classes using Prototype. I hope you found this tutorial helpful. Please feel free to post any questions you may have in the comments section.

Comments »

Posted in Development

Tags:

Which JS Framework is “The Best”

June 27th, 2008

After my recent tutorial was posted on NETTUTS, I found the feedback filled with comments such as:

Jquery is the best and can be used to do all of this stuff plus more.

and

Yeah, I agree NETTUTS should only go away from jQuery when it can’t perform something

Reader Tim commented:

Nice. but which is best? Scriptaculous, Mootools, jQuery, or Dreamweaver CS3 built in apps?

What amazes me is not the sentiment so much as it's the nearly religious zeal with which these people are dedicating themselves to a code library.  So I wanted to take a moment to examine the question without that same type of bias--Which JS Framework really IS "the best?"

To attack this problem, we should first really define what "the best" means.  After all, if some code library is worth this type of devotion, I want to be pretty damn sure that it's the best!  So what does it mean to be the best Javascript library?  Here are some thoughts:

  1. It's the smallest
  2. It's the fastest
  3. It provides the most functions
  4. It provides the strongest application structure
  5. It provides a plugin system
  6. It provides clean methods to implement Object-Oriented Programming
  7. It integrates with a powerful back-end development platform
  8. It provides easily maintainable and extensible code.
  9. It's the most widely adopted by the biggest sites

That list was literally written in 30 seconds off the top of my head; I'm sure the true criteria to establish which Javascript library is the best is a far longer list.  That said, we'll use these 9 criteria.   What do we notice about these requirements?  If you answered that some of them lie in nearly direct opposition to each other (such as 1 and 3) you're right.  If you answered that some of them can compensate for weaknesses in other areas (for example, 5 or 8 and 3) you're also right.  Even with a short list of 9 requirements, we know two things:

  1. No one library is going to meet all of these criteria
  2. Not all of the requirements are always requirements

If you're busy debating which Javascript framework is "best," you're fighting a religious war that cannot be won; simply put--no one Javascript library can be objectively defined as "the best."

Gee, thanks Brian.  But which should I use?

In my opinion, for every project, you should evaluate which library makes the most sense to use.  It is certainly reasonable to have a preference (for example, you may feel that jQuery works for about 75% of all the project work you do) and that's great.  You may even find areas of overlap where you continue to use your preferred framework simply because it makes sense. For example, if you know prototype very well but are less experienced with jQuery, you may want to choose to use Prototype in the interest of speeding development even if based solely on the requirements of the project jQuery would be a "better" choice.

My personal opinions

Since you're reading my blog, I will give you what I consider to be my reasonably well-informed personal opinions of the libraries I have worked with and when they make sense:

The library I'm most experienced with is Prototype.  The primary reason is that it is the library we have standardized on here at AutoTrader so I work with it extensively on a daily basis.  My feelings on Prototype are that it is a great library that provides a lot of great functionality, is for the most part reasonably quick (with some notable exceptions).  Both jQuery and MooTools have their roots in Prototype, so moving between those 3 libraries are probably easier than moving to and from others.  For general development, my familiarity with Prototype makes it my first choice.  The biggest thing Prototype has going for it is its implementation of classes and inheritance easing the transition for those very familiar with object oriented programming.

For everything I like about Prototype, I dislike Script.aculo.us.  The way its implemented seems silly to me (creating a new object for each effect is how you execute the effect?) and it doesnt "fit" well with Prototype's code style.  It lacks an implementation of Robert Penner's easing equations which make its animations look less impressive.

I have a strong love of jQuery; it's incredibly small, incredibly fast, and very much follows the paradigm of "get out of the way."  The plugin architecture is fantastic, and the jQuery UI library is great--fully integrated with the jQuery style of coding and integrates everything I'd expect from a fully-featured animation library.  These guys have taken the concept of dereferencing objects to an extreme level--and it can make jQuery code difficult to read at times when you have one line that chains 35 methods.  That said, once you understand its power; its actually quite elegant.

MooTools is another great library, and if you're looking to do a lot of heavy animation work, I'd even suggest it over jQuery.  MooTools began as an animation extension to Prototype that evolved into its own library--but their heavy focus has always been on providing the fastest, smoothest animations of any library.  Obviously its not limited to only animation work; but that's certainly where the bulk of its strength lies.

I'd also like to mention SproutCore--if your goal is to build a fully functional application within a web browser that relies less on Ajax and animation and more on solid application architecture, SproutCore appears to be an excellent choice.  I have far less experience with it than other libraries, but from what I've seen, it's MVC implementation is quite impressive!

I'll refrain from in-depth comments on other libraries with which I have no experience--but there are certainly a multitude of choices out there!

Always remember to take your requirements for the library into account on a project-by-project basis--and don't be afraid to work with multiple frameworks.  It only makes you that much more valuable to an employer!

Comments »

Posted in Development

Tags: