Putting the Brakes on SharePoint with jQuery – Or Not (Some More)
eshupps 10:01am, Dec 29 from TweetDeck “Sigh – Nobody listens. #jquery isn’t small or efficient. It’s still thousands of lines of javascript behind the scenes people!”
Actually, Eric, because I’m listening, I feel another need to respond! In my previous response (Putting the Brakes on SharePoint with jQuery – Or Not) to the views on jQuery you expressed in Putting the Brakes on SharePoint with JQuery, I tried to respond to your empirical testing of jQuery techniques with SharePoint. However, with a tweet like to one above, I get a little ornery. You’ve got a lot of people following you and probably listening to you and this type of absolute statement isn’t really useful.
jQuery is one of the shiny new pennies on the scene: no debate. As I pointed out in my prior post, nothing comes for free. The ease of implementation that jQuery provides requires overhead, and that overhead means some bytes down the wire. I continue to say that the bytes down the wire are the only overhead imposed on the server itself. This *can* be a good thing, as certain processing can be distributed from the server to client machines.
The choice to use jQuery for any given task should be an informed one. Yes, you will be sending “thousands” of lines of JavaScript (that’s 4376 un-minified, commented lines of JavaScript in jquery-1.3.2.js, or 19 minified, commented lines in the jquery-1.3.2.min.js version – what does number of lines mean, anyway?) to the client browser, just like SharePoint itself does with core.js and lots of other JavaScript files, as needed.
So what do words like “small” or “efficient” even mean, really? In comparison to what? I started programming in 16kb. Does that mean anything bigger is bad? No way, baby, I love having gigabytes of RAM available. But that doesn’t mean that I should use them all to add a fade in effect to some text. As developers, we owe it to our clients to do things as efficiently as we can given the tools at our disposal. This is always limited by things like time, money, skills, available software tools, requirements, etc.
jthake 10:08am, Dec 29 from Tweetie “@eshupps jquery is going to still b used regardless of warnings compared 2 dev :-( mainly due to speed to implement & availability of devs”
“Warnings” is the wrong word here. “Knowledge” would be good. We need to understand the tools that we use. Period. jQuery is useful if you want to improve the user experience on the client side in certain situations. “Development” (I continue to get a kick out of the fact that anything other than Visual Studio-based code isn’t considered development. Is this a Microsoft thing?) also has its time and place.
We’ve all seen bad code written in C# for SharePoint. Whether it doesn’t dispose of objects properly, or it reads and writes directly into the SQL database or whatever, the same type of “warnings” are important.
The question is how we, and I mean each of us individually, not we collectively – there’s no one answer – can make good decisions when we try to solve specific business problems with the technology we have at our disposal.
I was actually referring to the posts and tweets that espouse the glory of JQuery because it only requires a few lines of code to perform complicated functions. The truth of the matter is that those few lines of code require hundreds of lines of javascript to be processed in the background. This adds to the page render time, regardless of whether it’s performed on the server or the client. A slow page that is slow because of a bunch of client-side code is still slow and users don’t really care about the technical details – they just blame SharePoint for being slow. As is so often the case, it’s not the reality of the situation but the perception that counts, and lots of people have the perception (not entirely unfounded) that SharePoint is slow.
I spend a lot of time helping clients optimize the performance of SharePoint. In most cases the client doesn’t understand the implications of what they’re doing – they see a shiny new penny and want to use it. I’m not saying there’s anything technically wrong with JQuery or any other technology but that folks, especially those with limited development skills, don’t realize the implications of what they’re doing. I feel that there is a lot of talk about the cool things JQuery can do but not much discussion on its impact in performance-sensitive situations, so I’m throwing my hat in the ring as the Devil’s advocate.
At the end of the day, it’s not about whether or not you should use it but HOW you use it that is important.
you have helped me on ms’s site..
i agree with your comment. what is small?
most sites today would kill my 14kbs dialup from 10 years ago. i’m pretty sure our market can handle 4000 lines of code since that isn’t a whole lot when looking at libraries, classes etc that users might be calling beyond just jquery or any code.
I think the biggest debate here is, as Marc pointed out… what really is “efficient”. Is 10 lines of code when 2 will do considered inefficient, or is adding user experience enhancements when they’re not 100% required considered inefficient?
I’m sorry, but I don’t consider 17 lines of minified JavaScript a complete waste and burden to add some decent user experience and improve the user experience. Now I’m a little biased because of two reasons (which are somewhat tied together). I mainly work on an internal corporate environment. When you’re not on a public facing network and have complete control over every asset connecting to your environment, adding a little overhead isn’t really a worry. In addition, the benefits of operating on such an environment are also a huge hindrance; as our company restricts server access to a very select few. As a result, and Marc will testify to this, I’ve spent a lot of time understanding jQuery and the work Marc has done with integrating jQuery with SharePoint web services. In some of our applications this is the only real option we have.
Is jQuery overused; some may say yes, but I stand by my comment in Marc’s first blog post on this issue. The real question is whether people are using it correctly or not. 17 lines of minified JavaScript is nothing in today’s modern broadband world–period. Now if you’re calling 200 jQuery operations, or doing something silly like Eric mentioned in his article (using jQuery to set the alternating shade color instead of 2 lines of CSS), you are being inefficient. It is your responsibility as a developer (as Marc pointed out) to be smart, integrating decent user experience with the tools available, as efficiently as possible.
Eric’s posts always seem to bash jQuery, then defend them by saying he’s just complaining that people don’t use it correctly. To complain about the library itself isn’t the answer. jQuery is efficient, it is powerful, the flaw is how people use it. My $0.02 (probably all it’s worth) is to address that. Instead of complaining about jQuery, how about you show people how to use it correctly?
Event product (atleast the software products) is having its own negative effects if the standards and smartness are not applied it. Sharepoint is also not a exception to this. Since AJAX has impressed everyone, people try to do some things in AJAX where UX is hevily required. Even if the jQuery is not available still they do it in Javascript, whic is again time consuming. As said by others, it is upto the developers to think smart on applying various tools to their requirement. Even SharePoint is not anyway exception to this. jQuery helps developers to develope something fast, but again it is upto developers how efficiently to use it.
Michael,
I don’t read Eric’s comments as bashing the jQuery library – just as trying to deflate the hype and point out that it isn’t a panacea. It has to be used appropriately – which you seem to agree upon.
My own concern is less about about the size of the file – although there are lots of files that are ‘only small’, and they all add up (SharePoint is a particular offender on this point!) – but rather the render time. JavaScript changing pages is great if used lightly. It can also be very slow. I’ve seen several sites where the page loads, and then things visibly change as the JavaScript runs (usually vanishing, and causing contents to shift).
Again, appropriateness. jQuery is good – but doesn’t cure all ills. I think everyone actually agrees on that. However, we may well be working is different environments with different constraints.
It’s time to get ornery.
In your first response, you tactfully state that conditions of Mr. Shupps’ experiment resulted in “a highly unrealistic test”. In the first comment in response to your article, he replied, “I was very careful to point out that my tests were subjective and did not reflect a real-world scenario; I was simply trying to make a point regarding overuse of client-side technologies.”
For this debate about the efficiency of jQuery to be of any value, we need to at least agree on how the tests should be set up. I think you were politely (and correctly) saying that his test is not subjective, it is plain *wrong*. “No loading on a server is going to give you a realistic read”. Precisely.
Until someone can perform a real, controlled test that consistently and clearly shows some major performance degradation due to use of jQuery, these arguments about efficiency are, in my opinion, nothing more than a reflection of the prevalent “server-side only” bias of .NET developers.
Okay, when it comes down to it with jQuery:
1) You are pushing more data over the wire
2) You are increasing page render time
A developer uses jQuery because (choose one or many here):
1) He/She doesn’t know HOW to write real code
2) He/She isn’t allowed to write real code
3) He/She can modify jQuery without recompile
4) It’s faster than writing real code
5) He/She found some cool library out there that makes the end users ooh and ahh
I think jQuery is cool and great when used properly. What is wrong with cautioning people to use some restraint here? The noise from jQuery is deafening. I always appreciate Eric’s perspective as one who HAS to write performant Enterprise grade SharePoint applications where how well it works is more important than how pretty it is. He’s trying to inform and help. Personally, I don’t look forward to going back and fixing some junior dev’s jQuery mess because they couldn’t figure out any other way to do it.
Mark:
I have a feeling that this is going to degrade into a religious war. I can only take phrases like “real code” as being inflammatory. Script is code, too. It’s just a different kind of code.
I’m going to *try* to take the high road on this: How can we come up with a better way to educate folks about when to or when not to use client side code? There are clear use cases when it ought to be used (server-side code can’t respond to user actions without a postback) and clear use cases where it should not. Can we work together on some sort of decision tree?
M.
Sorry Marc,
Was not trying to be rude with the “real” code comment… should have phrased better… jQuery has nothing to do with SharePoint. It’s a script that doesn’t know antyhing about the SPObject model, or what’s going on underneath. It’s not compiled and doesn’t take advantage of any sort of CAS policy. That’s what I was referring to. Not trying to start any religious wars. Just being too lazy to expand on what I meant.
Mark
Hi Mark,
I do a lot of coding on the server side using the SPObject model and there are a lot of things you can do in jQuery which would be EXTREMELY painful on the serverside.
A small example is the “cascading dropdown columns in a list ot Doc Lib” e.g. Country –> State –> City.
Can you guess how difficult it is to implement this using SPObject model? damn… you have to write a very very painful field control, trust me.
I implemened it using Marc’s jQuery script very quickly.
http://spservices.codeplex.com/wikipage?title=%24%28%29.SPServices.SPCascadeDropdowns&referringTitle=Documentation
Same thing goes for http://spservices.codeplex.com/wikipage?title=%24%28%29.SPServices.SPArrangeChoices&referringTitle=Documentation
Writing a serverside component/field control for these requirements is most definitely a “over kill” as Marc has mentioned.
Javascript is not always bad, some people just dont know how to use it properly :).
And those “few more bytes across the wire” caused by the jQueries are usually a fraction of “huge number of bytes” cause by usual page postbacks caused by the normal serverside components/events (e.g. in cascading dropdowns).
Cory,
I can’t speak for the rest of the .NET development community but if you’ve followed any of my presentations at conferences or previous blog posts you would know that I spend a great deal of time trying to educate developers on how to write performant code. Most of that time is invested in helping to optimized server-side code. Quite frankly, I couldn’t care less where the code runs. What I do care about is when developers do things without thinking about the ramifications. Everything you add to a page, whether it runs on the server or the client, adds to the overhead and increases render time. Period.
I think there’s a lot of value in this discussion, but still feel it needs to be less of us vs. them and more a discussion of how do we educate the end user. Many people (some involved in this discussion) still fail to see the real, practical and strategic uses of jQuery and similar technologies. The work Marc has done with the SharePoint web services library is a prime example of what you can do with the technology, but I still see people referencing light boxes and slide shows as the core uses of the library. Mark re-clarified his comments, but I still resent the statement about how it’s not “real code” that was basically said with the tone that if it’s not server side it doesn’t matter. Those of us who use jQuery don’t use it because it’s quick, easier than coding from scratch, or because we don’t know how–in fact I’d argue the opposite. In my opinion, strategic and efficient use of the tools available makes you a better developer; and helps you to offer better rates and services to your clients.
I will agree with the general consensus that no matter where you put the code (client side, server side, jQuery or .NET) you’re adding overhead–that’s never been questioned. What hasn’t been discussed (at least that I’ve seen) is the trade off between adding a second to a load time, and avoiding subsequent page load altogether. A couple years ago, I would have redirected a user to a second page for a login form, today I can use a jQuery chromeless popup. Is that popup going to add a fraction of a second to my initial page load time? Absolutely, but that fraction of a second is an acceptable trade off in my opinion for not loading an entire page when the user clicks the login button. That’s maybe not the best example, but it’s one that’s easy to explain. That said, I stand by my original statement that it is the developer’s job to use his/her technical acumen to make the right decisions. We can debate over and over whether jQuery is value add or a waste of overhead, but at the end of the day we call ourselves developers and that title comes with certain expectations–writing efficient code is one of those expectations.
jQuery is col for interface based stuff, but not as much for backend stuff … unfortunately it’s difficult to do async stuff in Sharepoint (OK for webparts, custom pages, no for default pages)