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.
About Me

- Matthew Maxwell
- Experienced Web Developer using C#, ASP Classic (VBScript) and ASP.NET, MySQL, T-SQL, and other SQL variants, JavaScript (W3Schools Certified and very well versed in jQuery and learning Dojo), and XML. Heavy interest in JavaScript, framework creation on various language platforms, and keeping up with the best industry-accepted practices.
Blog Archive
Thursday, February 11, 2010
Wednesday, February 10, 2010
Tuesday, January 26, 2010
Ternary Operation in JavaScript
Ternary operations in JavaScript are really awesome.
It's essentially an if/then block, but on one line.
An example would be:
In this example, y would be "howdy".
You can read ternary operations as
y = ( comparison ) ? if it's true, use this value : otherwise, use this value ;
This is a very simple example, but you can see the power behind this.
An example in jQuery could be...
Again, this is a very simple example, but you get the point.
One word of advice, though: never use ternary operations if the values to be set are true/false:
Instead, just use the comparison:
It's essentially an if/then block, but on one line.
An example would be:
In this example, y would be "howdy".
You can read ternary operations as
y = ( comparison ) ? if it's true, use this value : otherwise, use this value ;
This is a very simple example, but you can see the power behind this.
An example in jQuery could be...
Again, this is a very simple example, but you get the point.
One word of advice, though: never use ternary operations if the values to be set are true/false:
Instead, just use the comparison:
Labels:
beginning javascript,
javascript
Monday, January 25, 2010
jQuery 1.4 and native JSON support
I was reading a post by Yehuda Katz (http://www.twitter.com/wycats), and saw how jQuery 1.4 now uses native JSON support, which is available in a lot of more current browsers (IE8, FF 3.5, Chrome 2), and when JSON support is not available, it falls back on its previous JSON parsing.
In a video by Paul Irish (http://www.twitter.com/paul_irish), he states that jQuery 1.4 will now validate the JSON (if native JSON support is not available) and throw errors if the JSON response is not valid JSON, just as native JSON parse would throw errors.
Both of these things are awesome. I am pretty excited about that.
I have been guilty of using malformed JSON simply because I could get away with it.
Now, a great standard is being pushed to the forefront!
I am going to be taking it a step further and ensure that all the JSON I use throughout my apps are valid JSON (even objects I'm passing to jQuery functions).
I'm doing this for a few reasons. One reason is consistency. I like having consistent organization and standards in my applications. This is a must at my job because different members of the team may have to go in and edit my code. If I have a consistent style of programming, they'll be able to easily go in and make changes.
Another reason is, it's just good practice. If I do ALL my JSON in valid JSON format, then I won't even have to go "oh, this is an AJAX call, my response should be valid JSON", I'll just be doing ALL my JSON in valid format, and not have to worry about it.
What are your thoughts about this?
In a video by Paul Irish (http://www.twitter.com/paul_irish), he states that jQuery 1.4 will now validate the JSON (if native JSON support is not available) and throw errors if the JSON response is not valid JSON, just as native JSON parse would throw errors.
Both of these things are awesome. I am pretty excited about that.
I have been guilty of using malformed JSON simply because I could get away with it.
Now, a great standard is being pushed to the forefront!
I am going to be taking it a step further and ensure that all the JSON I use throughout my apps are valid JSON (even objects I'm passing to jQuery functions).
I'm doing this for a few reasons. One reason is consistency. I like having consistent organization and standards in my applications. This is a must at my job because different members of the team may have to go in and edit my code. If I have a consistent style of programming, they'll be able to easily go in and make changes.
Another reason is, it's just good practice. If I do ALL my JSON in valid JSON format, then I won't even have to go "oh, this is an AJAX call, my response should be valid JSON", I'll just be doing ALL my JSON in valid format, and not have to worry about it.
What are your thoughts about this?
Labels:
jQuery 1.4,
JSON
Friday, January 15, 2010
JavaScript console
At my company, I am required to support different browsers because a lot of employees here like to use their preferred browser; we support IE6+, FF2+, and Chrome. Let me start by saying I love Chrome and I love FireFox. They both have different aspects about them that are amazing.
I love Chrome because it's just really good quality. Google has never really produced any bad products to my knowledge. They're always working to be on the cutting edge and they do a damn good job at it. The V8 engine in Chrome is fan-effing-tastic.
Firefox is a well-rounded browser that has the ability to be customized out the ying-yang. It's Firebug plugin is absolutely amazing. There are also some other plugins I use that are really cool.
One thing that make Chrome and Firefox even better is the fact that they both adhere to web standards! What a concept, right? Haha.
Another thing I love about them is the fact that they have a JavaScript console, which has proved to be a priceless commodity.
IE, however, does not...unless you install something like debugbar (which is a very heavy IE plugin).
I took some time and actually created a console (written completely in JavaScript) that works across all browsers. I can throw different commands at the console, and even have a mode set up to take and interpret JavaScript commands. I use this console in a newer application I'm going to release as an actual event log for my app. It's pretty light weight, and I have added the ability for it to email my team a timestamped log of all events/responses from the application.
I have it self-truncating at 500 rows currently, just to ensure the log doesn't get overly massive.
I just bought my own website (www.matthewcmaxwell.com) and will be setting that up in the near future. When I do, I'll be putting my JavaScript console up there for you to download and try out.
Here's a small pic (bad quality, I know)
I love Chrome because it's just really good quality. Google has never really produced any bad products to my knowledge. They're always working to be on the cutting edge and they do a damn good job at it. The V8 engine in Chrome is fan-effing-tastic.
Firefox is a well-rounded browser that has the ability to be customized out the ying-yang. It's Firebug plugin is absolutely amazing. There are also some other plugins I use that are really cool.
One thing that make Chrome and Firefox even better is the fact that they both adhere to web standards! What a concept, right? Haha.
Another thing I love about them is the fact that they have a JavaScript console, which has proved to be a priceless commodity.
IE, however, does not...unless you install something like debugbar (which is a very heavy IE plugin).
I took some time and actually created a console (written completely in JavaScript) that works across all browsers. I can throw different commands at the console, and even have a mode set up to take and interpret JavaScript commands. I use this console in a newer application I'm going to release as an actual event log for my app. It's pretty light weight, and I have added the ability for it to email my team a timestamped log of all events/responses from the application.
I have it self-truncating at 500 rows currently, just to ensure the log doesn't get overly massive.
I just bought my own website (www.matthewcmaxwell.com) and will be setting that up in the near future. When I do, I'll be putting my JavaScript console up there for you to download and try out.
Here's a small pic (bad quality, I know)
Monday, December 14, 2009
How I replaced eval for dynamic initialization
So, I've been trying to steer clear of JavaScript eval() as much as possible ever since I learned how horribly inefficient it is.
On a recent project I did, titled "Shark Tank", I decided to create the application on the premise that there would be one "landing" page, and the rest would all happen via AJAX.
Well, I needed to have certain things happen on page initialization, and I try to keep my JS all in one spot at the top of the page, and not scattered throughout the page.
So, in my links table on my database, I had the columns "FriendlyName", "URL", "Initializer"
FriendlyName would display the friendly name, i.e. "Add a Lead", URL would be the actual url "add.asp", and the Initializer would be a string literal of the initialization function, which was housed somewhere in my namespace, i.e. "BAMPIT.Add.Initialize"
I started off trying to figure out how to do this without eval, but ran out of time on my deadline, so I just decided to go with eval in order to get the app out on time. Using eval on a string literal to call a function name isn't TOO bad, but I wanted to do this without eval.
So after thinking on it for a while, I came up with a way to do it 100% dynamically, and without eval.
I would personally add this to a namespace or change the function name to avoid potential conflicts with anything.
The function basically starts at the window object and drills down the namespace until it reaches the function you want to execute, and then executes the function.
As always, criticism and comments are always welcome.
On a recent project I did, titled "Shark Tank", I decided to create the application on the premise that there would be one "landing" page, and the rest would all happen via AJAX.
Well, I needed to have certain things happen on page initialization, and I try to keep my JS all in one spot at the top of the page, and not scattered throughout the page.
So, in my links table on my database, I had the columns "FriendlyName", "URL", "Initializer"
FriendlyName would display the friendly name, i.e. "Add a Lead", URL would be the actual url "add.asp", and the Initializer would be a string literal of the initialization function, which was housed somewhere in my namespace, i.e. "BAMPIT.Add.Initialize"
I started off trying to figure out how to do this without eval, but ran out of time on my deadline, so I just decided to go with eval in order to get the app out on time. Using eval on a string literal to call a function name isn't TOO bad, but I wanted to do this without eval.
So after thinking on it for a while, I came up with a way to do it 100% dynamically, and without eval.
I would personally add this to a namespace or change the function name to avoid potential conflicts with anything.
The function basically starts at the window object and drills down the namespace until it reaches the function you want to execute, and then executes the function.
As always, criticism and comments are always welcome.
Labels:
eval
Wednesday, December 2, 2009
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.
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.
Labels:
efficiency,
jquery
Subscribe to:
Posts (Atom)