Does it really matter if you use ASP.NET MVC, Struts 2, Yii, or Rails? Well it might, but for many websites these modern frameworks are just as competitive as the next. Use the stack that is most appropriate for your customer’s situation and is the best choice at the time. Since this is the real world, it will probably change a couple of years in the future.

Leverage Community Extensions

Each framework out there has libraries of modules, extensions or plugins that enhance functionality and provide features that would you otherwise would need to write yourself. If it exists, and it’s in good shape, don’t write it yourself, leverage existing extensions that are appropriately licensed for your project.

Future Proof your URLs

It no longer makes sense to have a web site with extensions, be it .html, .php, .jsp, or .whatever you can think of. Arstechnica even created their own .ars, for no reason that I could tell. Yes the web started with .html because websites were simply serving static files, but that is no longer relevant anymore.

If you build a website with .jsp as the suffix to all URLs, and then a couple of years later your boss wants to re-write the website in python, does that mean you change all URLs to be .py, and setup mass url re-writing schemes to handle the old URLs? No, this would be a nightmare. Protect your future self by completely leaving the actual technology used to build the website outside of the URL.

Another bonus is that these URLs also end up being more SEO friendly!

Use a JavaScript Framework (maybe)

If you are building an AJAX heavy website such as GMail or Facebook, use a JavaScript framework. This is not relevant for many sites that simply use JavaScript to provide some enhanced functionality, but for websites that are heavily dependent upon JavaScript and simply cannot function without it.

I’m not talking about jQuery or Prototype, while those are good libraries that abstract the differences between browsers and provide easy to use functions, they are not built as a comprehensive framework. I’m suggesting you use a framework like JavaScriptMVC, SproutCore, or Spry. These frameworks can be used in tandem with jQuery, but go much farther in helping you organize and control your JavaScript code.

Watch a demo video of what JavaScriptMVC can do for you.

Checkout the demo

/* create object */
function DragNDropList(selector){
  this.list = $(selector);
  this.sortInput = jQuery('#sort_order');

  /* store values */
  this.list.children('li').each(function(){
    var li = jQuery(this);
    li.data('id',li.attr('title')).attr('title','');
  });
  /* sortables */
  var obj = this;
  this.list.sortable({
    opacity: 0.7,
    update: function(){
      obj.submit();
    }
  });
  this.list.disableSelection();
}

/* worker function */
DragNDropList.prototype.submit = function(){
  var sortOrder = [];
  this.list.children('li').each(function(){
    sortOrder.push(jQuery(this).data('id'));
  });
  this.sortInput.val(sortOrder.join(','));
  this.request();
}

DragNDropList.prototype.request = function(){
  var obj = this;
  jQuery.ajax({
    success: function(data){
      $("#status").text('Saved');
    },
    error: function(){
      $('#status').text('Failed to save sort order').show();
    },
    data: 'sort_order=' + obj.sortInput[0].value,
    dataType: 'json',
    type: 'post',
    url: '/site/update'
  });
};

// init drag-n-drop lists
var list1 = new DragNDropList('#list1');
var list2 = new DragNDropList('#list2');

The world needs better JavaScript documentation.

Let’s help others and help ourselves by writing and promoting quality JavaScript documentation.

Performance can be increased because your user is going to download the jQuery file from Google’s CDN network and not from your server. Also, it could be even faster if the user visited another website that also uses Google’s hosted jQuery. If that is the case then your user won’t need to download it again and will use the exactly same cached version.

There are two ways to do this.

The fastest and simplest is to link directly to the Google’ hosted jQuery file:

<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"></script>

The second approach has more features but there is a slight delay while the jsapi loads the correct version of jQuery. If you want the absolute best performance use the first version.

1) Signup to get your own API key

2) Add the following code to your layout:

<script type="text/javascript" src="http://www.google.com/jsapi?key=INSERT-YOUR-KEY"></script>
<script type="text/javascript">
google.load("jquery", "1.4.2");

  google.setOnLoadCallback(function() {
    // Put you init code here instead of using $(document).ready()
  });
</script>

You can also specify the latest version of the 1.4 branch:

google.load("jquery", "1.4");

I foresee a new framework will be created to make developing fully interactive AJAX applications as easy as it is to write current MVC applications. Current frameworks like Ruby on Rails and Symfony provide everything you need to develop a modern application without having to build plumbing infrastructure; however, they do not provide nice components for interactive applications. In addition to a robust server core, this new framework will have a client side JavaScript component that simplifies the process of building interactive web 2.0 applications. Some critical components would be:

• Form Validation. Libraries do exist to validate forms in JavaScript, but they don’t integrate with the server side form validation. In this new framework you won’t have to write form validation code twice.
• Paginated Lists. Almost all web applications have at least one page where data needs to be searched and listed with pagination. We need to have this same functionality in JavaScript to skip a full page reload and provide local caching of the results.
• Animation Library. While script.aculo.us and jQuery have made simple animations and visual effects much easier to do, I believe we can go even farther. Web applications also need to gain that fluidity and soft animations that desktop applications such as Exposé have had for a couple of years.

I also see huge resources being directed towards mobile development because ALL current generation smart phones are built for an incredible web browsing experience. As home users have switched from desktop computers to laptop computers in the last few years, people will slowly start switching to hand-held devices for their primary communication and Internet needs. Most likely this will have one primary effect: web frameworks will have a mobile optimized version of the site done automatically. Little to none developer intervention will be required as only resolution, text sizes, and layouts will be modified for the mobile version.

Lastly I see tools and libraries around 2D and 3D drawing elements. Most likely these libraries would be rendering to a Canvas or a WebGL element but something better could be created. Both of these are young standards right now that show a lot of promise on delivering the ability to draw pixels directly in a native HTML web page. While they will be used first in simple computer games, I am very interested to see what libraries are created to facilitate these elements being used appropriately inside next generation web applications.

What do you think the next 5 years will bring?

When developing an application you must learn Rule #1 Facebook is the gatekeeper. Everything you do, be it HTML, CSS or JavaScript, is restricted by Facebook. Only the commands, functions, CSS properties, HTML tags etc. that Facebook allows are permissible. If you have an error in your HTML such as an unclosed tag or if you try to use a CSS property that does not exist, Facebook will render a very nice message saying you made an error.

Rule #2 The never ending cycle. The Facebook platform is constantly changing and APIs that you are using in your application could disappear one day without any notice. It’s the life of a Facebook application, working one instant, inexplicably broken the next. Be prepared for irregular maintenance just to keep your application working.

A Facebook Application lives in the world of Facebook and while it might initially seem like you’re developing a standard web application you are not. Rule #3 You’re application is on the Facebook web. It’s not a regular web application which is a very slight but critical distinction. Facebook has used their powers as the gatekeeper to make modifications to the web. Some HTML tags are allowed, some are not. JavaScript has been altered to remove a lot of its power and replace only some of them with Facebook specific functions and even CSS has restrictions. Don’t expect existing code to function when placed in the Facebook web.

Additional Caveats

• You cannot include any external JavaScript or style sheet files, they must be included in-line. This is so Facebook can parse them and allow only approved commands. Yes it enhances the security of the social networking site as a whole, but it will slow down your development time.
• Facebook will filter, compile, and drastically alter your original code. Clicking view-source on a Facebook page with your application will show your JavaScript code mushed into awkward Facebook functions.

Do you see that it’s a bit of a battle of you against the mighty Facebook? Don’t sweat too much, other developers have persevered and with a few wounds and time you can build and maintain a successful Facebook application. Good luck!

UpcomingHoliday.com is an application that tells you what and when your next federal holiday is. Currently it’s available for people in: Australia, Canada, France, Germany, India, Nigeria, United Kingdom and United States.

WebGL is technically a JavaScript binding to OpenGL ES 2.0. If you already know OpenGL ES and JavaScript, you should be able to pick it up pretty quickly. If you know JavaScript but not OpenGL and are in a web development career, I encourage you to look into WebGL because it could be one key component of interactive web applications in the future.

Lets say you have a web application that needs to track how long an AJAX request took. If you were writing it in Ruby, PHP or Python you’d have a timer object that you can start() and stop() and a seconds() method to get the number of seconds that passed between calling the first two methods.

To build this in JavaScript we first create our constructor:

Timer = function() {
  var seconds_passed = 0;
}

Here we are creating a Timer object with a private seconds_passed variable. To create this object we we simply create a new timer:

var elapsed_timer = new Timer();

This timer object now needs some public methods. We can attach a public method by using this.method_name:

Timer = function() {
  var seconds_passed = 0;

  this.start = function() {
    // implementation here
  }
}

Our Timer class now has a start() function. Additional public methods can be added in the same way.

To add a private method, don’t define it with the this keyword but instead create a regular function inside the class:

Timer = function() {
  function increment() {
    // implementation of private method here
  }
}

Now we have a Timer object with a public start method and a private increment method. The rest of the class is fairly simple, so lets jump to the finished solution.

Complete Example

Timer = function() {
  var timeout_id = null;
  var seconds_passed = 0;

  this.start = function() {
    increment();
  }

  this.stop = function() {
    clearTimeout(timeout_id);
    timeout_id = null;
  }

  this.seconds = function() {
    return seconds_passed;
  }

  function increment() {
    seconds_passed++;

    timeout_id = window.setTimeout(
      function() {
        increment();
      }
      , 1000
    );
  }
}

var elapsed_timer = new Timer();
elapsed_timer.start();

// do some stuff

elapsed_timer.stop();
alert(elapsed_timer.seconds());

There you have it. A simple JavaScript timer to keep track of time.

I recommend Firebug, which is a JavaScript debugger, a real-time HTML, CSS, DOM, and JavaScript editor, and a network monitor.

Logging

One of the most useful features are the logging functions through console.log which can simply be used to output a string or object:

console.log('Testing log output: ', myObject);

This will output your message and the full object available for inspection in the Firebug console tab. In addition to console.log, there is also console.warn, console.error, and more. See the Firebug documentation for more info.

Be careful to remove the statements from your code before deploying it, because your users won’t have Firebug installed, and JavaScript will then fail when it tries to output to the console object. Also, you certainly don’t want users to see your debug output.

console.log in action

Breakpoints

Pausing scripts to investigate the system at a current point in time can be very valuable in solving bugs. To use the breakpoint feature click just to the left of a JavaScript line. This will set a breakpoint and make a red dot appear.

You can also add a conditional breakpoint by right clicking on a line number. Now the program will only pause under your specified condition.

Setting a breakpoint

JavaScript Errors

Firebug will print out JavaScript errors with the corresponding file and line number. An absolute must for any JavaScript development.

A JavaScript Error

Those are the key feature I use most often, but there are many more JavaScript features in Firebug, including stack traces, watching expressions, profiling and viewing events.

Download Firebug now.