4

We all know Jquery has tons of benefits it has to offer. If you have used Jquery in enterprise, what was your "learning" experience?;

what needs to be taken into consideration from backward compatibility, conflict with existing javascript, CSS class structures, performance, jquery size / Caching, additional plugins etc to improve and leverage the benefits of Jquery?

Thanks.

3 Answers3

7

I have been using Jquery in many enterprise projects for about 18 months and I have had almost nothing but success.

The fact Jquery is renamable to anything via the $.noConflict() function pretty much takes care of conflicts with existing scripts.

Its interaction with (good) CSS is a lifesaver in terms of simplifying what you have to think about in terms of DOM, etc.

Performance is usually great, though occasionally some Jquery wheels are worth reinventing for narrow uses where performance is poor with Jquery (you'll know these when you see them). Though passing in the element to search with is often a solution to this (e.g., $(".SubItem",knownParentElement) instead of $(".SubItem") ). Moreover, in most cases when Jquery is doing more work than necessary, the benefits of having readable code that is going to work 95% identically cross browser far outweighs a few extra ms here and there.

Size, especially with the minified version, is well worth the weight, it will simplify and probably reduce your overall code in complex apps.

Cache issues can be bypassed by keeping the Jquery version in the file name (rather than renaming it jquery.js or something), so that it is always loading the version you expect.

And as far as Plugins, oftentimes they are huge timesavers, and usually good quality (esp the ones from Jquery directly). Though sometimes they are a swiss army knife and it's easier to build your own butter knife if that's all you need...

To sum up: I heart Jquery!

jwl
  • 10,268
  • 14
  • 53
  • 91
1

Please check jquery-standards-and-best-practice for more information.

Community
  • 1
  • 1
MRG
  • 3,219
  • 1
  • 26
  • 35
1

The first thing to consider is that you will probably want to include a specific, known, tested, non-beta version of jQuery into your deployment instead of linking to some website. This will ensure that if they have access to your webapp, they can get to the javascript. Unfortunately by taking on this task, you are now subscribing to the maintenance and upkeep of that library. For example, if there is some security flaw that get's released, you may need to redeploy an update to your app just to include the latest copy of jQuery or some plug-in. The maintenance of this is probably minimal, but it should definitely be on somebody's spreadsheet somewhere because it will eventually happen. This is not a problem unique to jQuery, but really any "external library" generally speaking.

If by backward compatibility you mean "with browsers" you don't really have to worry too much about it since most of that is done for you by the library itself. If by backward compatibility you mean with existing javascript deployed to production that is a case-by-case basis.

As far as integration goes, we have found jQuery to be a terrific compliment to ASP.net development. It's a very natural fit because it allows you to apply an extra layer of functionality very easily while still leveraging a lot of the existing UI controls and not having to reinvent the wheel with new ones just to conform to some "jQuery protocol".

Size? jQuery is probably the MOST lightweight and effective framework that packs a whopping punch in my opinion. Kudos to the devs, because when it comes to "bang for the buck" that is really where jQuery shines.

See also this article on asp.net+jquery.

slf
  • 22,595
  • 11
  • 77
  • 101