It's been a while!

It truly has been a while since I have posted anything here. To be quite honest, I have immersed myself in so much JavaScript best practices, new patterns, performance optimization, etc, that I have highly neglected this blog!

Since my last few posts, I have increased in my JS knowledge IMMENSELY, and that is no joke. I am w3schools certified (link to cert) *with excellence*. I got 69 of the 70 questions right! Woo hoo!

I have studied very carefully presentations, books, papers, etc from various JS gurus, Nicholas Zakas, Douglas Crockford, John Resig, etc. I actually printed out the current ECMAScript specification and read it on a flight to Las Vegas for a team meeting.

I am not joking when I say this, JavaScript is one of my biggest passions. If I could do nothing but analyze problems and engineer solutions in JavaScript all day long, I would do it!

Unfortunately, there isn't really that great of a job market that I can find. I don't have any degrees as of yet, and the area I live in really kind of prevents me from finding any solid JS jobs, and it'd be REALLY hard for me to relocate.

Members on my team at work think I'm really good at JS, and I think I'm pretty good, too. I'd like to be able to focus solely on that, as it is easily my biggest strength, but it's really hard to do that right now.

I'll keep it as a hobby, and maybe one day, I'll find a JS engineering job to call my home.

In other news, I am going to check out Dojo. I've been using jQuery for a very long time now, and I'm interested to dive into another JS library. I like what Dojo brings to the table. I haven't had a chance to dive into the source just yet, but at face value, it promises to offer some really neat functionality.

I am in the process of checking out the repository for the source now (it's huge). I like to dive into source code when I'm picking something new up.

I also purchased a book called Mastering Dojo: JavaScript and Ajax Tools for Great Web Experiences to read over the next few days.

I'm excited to really dig in and learn some new stuff!

Optimizing your jQuery code - fragment caching rules

jQuery 1.4 really introduced a lot of cool shit. One thing in particular is the internal caching of elements. When used properly, this can drastically increase your application's performance!

A good example is one I'm currently doing. Currently, I'm working on an admin page that allows a manager to go in and add/edit/remove options, details, and other data that are used by another application front-end for our tech support partners.

I'm doing the modification via AJAX, so when they click on an option, it will grab all the details for that option, and display them, so they can be edited. I'm caching everything grabbed and holding it locally, so I only have to do one AJAX call per option.

When they click the edit button, I'm having the innerHTML of the cells of that row turn into input fields for them to type the new, edited data, and then save when they hit update, reverting back to a regular text-filled cell.

As you can tell, I will be inserting a lot of inputs.

jQuery 1.4 introduced a new way to add elements to your page.

The old way (1.3.2) was something like

or

Something like that.

Now with jQuery 1.4, you can do

This is similar to the second example, the object passed as the second parameter is an attribute object.

What makes 1.4 really awesome, though is that if you use the method of $("<input>") either with an attribute object or going $("<input>").attr(), it will cache the fragments it creates when making these.

So, when you're adding multiple elements, you're basically getting a clone of the cached fragment, and not having to recreate an entirely new element.

The speed and performance boost from this is crazy, and I'd definitely recommend messing around with it.

JavaScript libraries are good, but be aware...

So, I've been using jQuery for a while now, and I have absolutely no complaints. Looking back at when I first began using it, my code started to get more efficient, but then I realized that, in using jQuery, I was able to do things in less typed code, but was actually adding MORE things for the browser to do. If you're going to use a jQuery wrapped object more than once, and you're not chaining jQuery commands, save it to a variable.



is super inefficient. Everytime you go $("#tbody"), you're initializing a new jQuery object..

This could be chained by going:


You do add an additional .end() call, which isn't as bad as the first example.

If you didn't want to do this, you could save the initialized object to a variable:




In this example, jQuery is only initialized around the tbody once. This is a very simple example, but I think you get the point. In a large application, CPU cycles matter! Efficiency is key. Building good coding habits is never a bad thing.

Sometimes the DOM IS better.

I've been working with jQuery a lot lately, and, for the most part, it has never given me any issues.

I have noticed lately, though, that when it comes to using any append/remove/find function in the jQuery library, if it is on items that have a lot of data, jQuery has serious performance issues.

The example I ran into today was, I have a drop down that has a lot of users in it.  It's somewhere around 4,000 options.

I normally find the selected option's text using


This takes about 2 seconds or so for jQuery to do.  I believe it's because jQuery's find method isn't optimized for large traversal like that.

I wound up making a quick jQuery extension lgtext(), which is simply:



This worked A LOT faster than jQuery.  In fact, it was pretty much an instant return.

The jQuery appendTo method only has a few milliseconds in lag time, so I left it in.  It's enough to notice a slight pause, but not enough for it to really affect production.

jQuery's .remove() is also very slow on this select field, taking about 2 seconds to complete as well.

To combat this, I created my own extension, lgremove():



This works perfectly, and is also an instant completion.

These are the only issues I've ever had with jQuery, so that should say something about the library.

It is pretty solid.

Just to clarify, the 2 seconds of lag time was in Chrome.  I was too scared to see how many times longer it would be in IE...

For you jQuery veterans out there, is there a better way for me to approach this using the built in jQuery methods?

Let's keep it DRY, folks.

If there's one thing I've come to love more than anything else in programming, it's the concept of DRY (Don't Repeat Yourself).

Seems like common sense, doesn't it?  I mean...really -- DUH!

As common sense as it may seem, there are a lot of people out there who do repeat themselves.  In fact, I used to be one of them!  I have been spending a little extra time lately sitting down and seeing what I can functionalize because what may initially seem like added work from the tried and true copy-paste method, can actually save you a ton of time not only in later stages of development, but also in instances where you need to debug and make additions to your applications.

Let's look at the run down on DRY coding in JavaScript and why it's useful.

As any programmer with even a little bit of experience can tell you, requirements for projects are normally constantly changing.  It's because of this constant change that the DRY style of programming really shines.  As the criteria change, if you weren't using DRY methods of coding, you would have to make changes in multiple locations.  Keeping it DRY allows you to make a single change and be done with the modification.

Let's face it-- everybody hates debugging.

Imagine you're debugging an application that's a few thousand lines in code. You spend an hour or so on it and finally find the issue that's been causing it all.  You tried to call the getElementById method of documnet, which is undefined.

Too bad you copied/pasted this functionality into about ten different places...

Now imagine that you utilized a functionalized method in those ten places.  You find the error sooner because you're digging through less lines of code, and when you find it, you only correct it in one place and then you're done!  The same goes for making changes to that functionality.  You make the addition in one place and you're done!

A really good way to implement DRY programming is by creating or using pre-built JavaScript libraries.

Using a JavaScript library, you utilize reusable, functionalized code that can really decrease dev time, increase performance and make your code look a lot cleaner.

There are some really good libraries out there.

Some ones you may want to look into are (in no particular order):

jQuery

MooTools

YUI

Prototype

vxCore

I use jQuery.  It was the first library I stumbled upon and it's suited my needs perfectly.  Each library has its strengths and its weaknesses, so be sure to check them all out before deciding which one to use.

John Resig also wrote a very good blog about Building A JavaScript Library

The concept of DRY can easily be adapted to any programming language.  The reason I chose to talk about it in JavaScript is because that is the language I am most familiar with, but the logic is sound in any language that can utilize functionalized code.

Do you have any good examples of DRY programming?  All languages welcome!