Test Two

Test Two

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque risus nulla, porttitor nec libero sodales, porta vulputate tortor. Morbi id condimentum dolor. Cras imperdiet dolor nec elementum pharetra. Fusce tincidunt turpis nunc. Integer sodales lobortis fermentum. Morbi vitae accumsan sem. Sed et nibh sit amet risus iaculis sagittis. Pellentesque viverra sagittis tellus, at dapibus odio cursus quis. Nam egestas viverra nibh, sit amet rutrum quam viverra lobortis. Suspendisse sagittis et velit scelerisque tempor. Pellentesque tempus, dui a blandit congue, leo sem ultricies ante, et luctus metus justo non tortor.

Test One

Test One

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque risus nulla, porttitor nec libero sodales, porta vulputate tortor. Morbi id condimentum dolor. Cras imperdiet dolor nec elementum pharetra. Fusce tincidunt turpis nunc. Integer sodales lobortis fermentum. Morbi vitae accumsan sem. Sed et nibh sit amet risus iaculis sagittis. Pellentesque viverra sagittis tellus, at dapibus odio cursus quis. Nam egestas viverra nibh, sit amet rutrum quam viverra lobortis. Suspendisse sagittis et velit scelerisque tempor. Pellentesque tempus, dui a blandit congue, leo sem ultricies ante, et luctus metus justo non tortor.

You may remember reading my post from a few weeks called jQuery Introduction, where I mentioned my new discovery of this incredibly powerful library and discussed some very basic uses of it.At the end of the day, when the rubber meets the road, jQuery is an incredibly powerful library, which has its uses far beyond pop-up windows and quirky little effects that most professional designers agree are better left out. The practical uses include the execution of web services (also mentioned in my initial article), data and content delivery, and user experience enhancements (to things such as forms) that add value in the eyes of the end user.There's been a lot of discussion lately across Twitter and on several blogs about the efficiency of jQuery. jQuery is JavaScript, and JavaScript add's overhead--that isn't being debated. Marc (who I have great respect for) has stood up in defense of the library, and rightfully so. There's been a lot of discussion on his blog (Putting the Brakes on SharePoint with jQuery – Or Not, and Putting the Brakes on SharePoint with jQuery – Or Not (Some More)) regarding the issue, but as opposed to clogging up his comments too much, here's my general thoughts on the issue. Marc hit the nail on the head when he said that "[as] developers, we owe it to our clients to do things as efficiently as we can given the tools at our disposal." This is the main point in this whole debate over the practicality of jQuery. People, "developers", are using it in inefficient ways. Blaming improper and inefficient use of the library on the library itself is a bit like yelling at the airline because it snowed and your flight got canceled. It's not their fault, but it makes you feel better and gives you an outlet to point blame at. In this case, the only people to blame are the people who call themselves "developers" but lack the acumen to develop efficiently. jQuery is easy to integrate, no question there; its ease of use (in basic applications) is putting it in reach of people that maybe shouldn't be using it (in my opinion). One example that's been floating around was using jQuery to change the alernating shade color on a SharePoint list. Using jQuery to find every row in a table and manually append a "style" tag to it with a background color is just obserd--and this is a perfect example of what we're talking about here. To the "developer", it's a 2 line jQuery call, but on execution it's applying that 2 line call to every row in your table. On the flip side, you could use 2 lines of CSS to rewrite the class of the row and be done; no redundant processing, significantly less overhead--the practical way. The "developer" should know that. So how much additional overhead do these techniques add to SharePoint and other web applications? Is that overhead value add, or a complete waste of resources? Again, it's the job of the developer to make things efficient, but at the end of the day you have to consider the usability as well as the performance. Is adding a library of 17 lines of minified JavaScript going to really burden my load time? Granted that's a bad measure because it's not the presence of the library, but rather how you use it--but at the end of the day, if the inclusion of that library adds a few miliseconds to my load time but increases the usability and user experience with forms or content delivery, I think that's a valid trade off. Do we need to use every bit of RAM and network bandwidth available, no, but we're also a high-speed world now. Gone are the days of dialup (for the most part), and technologies, methods and techniques that were unreachable just 5-10 years ago now are. Everything costs something--that dynamic form, that clean login box, that chromeless window--they all cost overhead, resources, money, but it's up to you to implement the functionality you want in a way that performs to the satisfaction of your clients; and poor execution by the developer doesn't mean the library is flawed, overused, or inefficnent.