Question

We’ve built an AJAX website which uses JQuery UI extensively.
we have 30+ homemade JQuery UI widgets (which are loaded dynamically).
we use the JQuery native widgets all over : Dialog, slider, datepicker.
we use JQGrid – latest version which is built css-wise on top of JQuery.
Our website consists of a skeleton and roughly 20 pages.

i thought of a few issues that may lead to a future mess and as we have some time on our hands for clean-ups i wanted to ask for some advice.

1. CSS class naming: For now the our widgets’ css naming is separated from the jquery UI theme (we don’t use jquery UI’s classes for titles / header and such). what are the pros & cons of this approach?
2. Include We have many many css and js includes (is there a recommended dependency injection plugin?)
3. Less CSS i read about this script-like css approach. our system is medium-sized but growing by the day which could be unreadably complicated. should we migrate?
4. Custom CSS widgets: lets say we have 4 different dialogs on our website. what is the best approach for creating 4 different look&feel jquery UI dialogs?

Thanks a lot,

Answer 1

I’m in exactly the same boat as you, but I think we took divergent paths. Perhaps some of my thoughts can help you project.

My app (for marketing automation) is setup with Jquery UI Tabs, so I was able to do a main index page with what I call the “init” file that does includes. One spot for management, one spot for changes which greatly simplifies things. I debated doing some sort of autoloader or conditional loads based on what elements I need, but I came to the conclusion that caching is my friend, and to do that I just need to take the “hit” of loading all the files up front. That being said, I have done some combining of smaller scripts into one larger JS file to reduce the amount of HTTP hits. It’s a large app that uses a ton of jquery and CSS yet loads no slower than other major sites like a CNN or ESPN….in fact, I think it’s faster than the sites that use a ton of goofy flash and video.

I chose to use Themeroller extensively (and the associated Jquery UI naming scheme) and actually to leverage themeroller styles for my custom elements. The disadvantage is that it locks you into very consistent style, which can be troublesome if you have a client who wants elements all different colors (yes, I’m dealing with that right now, as a matter of fact) But, then again, everything can be overridden in CSS and there’s incredible strength knowing that I can rebrand the entire app for my client simply by uploading a different themeroller theme. It’s what helps my app stand out in the industry, and it has allowed me to make the rebranding process incredibly profitable.

I chose not to minify or do something like less CSS based on my experience working for a major international bank. There, I worked on a site that was hit about 2 million times per day, and I actually recommended that we go that route. The request moved up the chain of command and some people who are far more experienced than I am decided against it. Why? Simplicity. While they could have dropped over a terrabyte of data transfer a day simply by doing a minification, they decided that in the SVN scheme they used doing minification and then rapid updates could cause confusion amongst the team. Plus, with the volume of hardware we all throw at our apps, very few sites (even large ones) really gain that much from doing the extra work. Sure, we all want our app to be the slickest. But the analysts reasoned that the extra time spent migrating to a new scheme and minifying would be better spent doing other features. I concur. So, simply turn on gzip compression, ensure that your CSS is streamlined (this is a great site for that) and go with it. Problem solved. Don’t forget, caching is again going to help after the initial load.

I broke my own rule about trying to fully leverage Jquery UI’s core and went with Qtip for dialogs. They’re more powerful, much more mature, and can be styled individually at will. Until Jquery UI gets a little further along on their dialog scheme, I’m personally holding off. I strongly recommend checking it out.

Finally, one thing that has really helped my app is extensive use of DataTables as a grid. I deal with a ton of data in my app–with one client, over 5 million possible records. DataTables not only makes it really easy to present data, but I can “pipeline” the loads via Ajax to give the user an incredibly fast query experience. As with most grids, it gives me sorting, paging, filtering, and ordering with just a few lines of code. And, more than anything else I’ve done, DataTables has set my application apart from the crowd. I definitely recommend taking a look at it.

Good luck.