Skip navigation
2011

I thought I'd explain why I wrote a (very simple) DOM framework to handle RichFaces mobile compatibility - and why we didn't use jQuery Mobile, or any of the other mobile web frameworks. The RichFaces Mobile Showcase was recently modified to give users a way to run their existing JSF based applications on mobile browsers. So this is the typical case of converting an existing application for the mobile web...

 

To get an idea of our existing web app, the RichFaces Mobile Showcase receives around 50,000 visits on a monthly basis, so this is a well reviewed application and it is a constant reference point for any JSF developer.

Screen Shot 2011-11-28 at 2.59.58 PM.PNG

 

I think jQuery (or any other DOM framework for that matter) has its place and there are times when it makes sense to use it. But when doing mobile development, jQuery is not the answer. Its main strengths are for desktop based browsers and inconsistencies between older ones. If you look at the jQuery source, you will see all the hacks and workarounds that are performed when checking for each browser and features therein. And even though the IE6 specific jQuery code doesn't actually run on a mobile browser, you are still carrying this bloat around with you.

 

Bottom line: jQuery is not a framework created for mobile environments - just like JSF, it was created for desktop environments.

 

Brian LeRoux of PhoneGap fame, explains this in the first couple of minutes here:

http://mobile.minutewith.com/pages/20110126

 

To truly get an optimized mobile web application - which runs as close to the metal as possible, you should understand and work with the core DOM APIs to get the best performance on a per app basis. Of course, there were other issues to deal with as JSF rewrites the markup and doesn't allow the data-* passthrough attributes, so that just fueled the fire to roll our own approach.

 

Today, jQuery minified is sitting at 94KB and if you couple that with jQuery Mobile at 82KB, you have 172KB for your user to download.

 

If you try to roll your own for your specific project needs, as we did with the RichFaces Mobile Showcase, you could end up with:

rf-mobile.css 5KB

slidfast.css 1.5KB

slidfast.js 1.6KB

A whopping total of a little over 8KB! (after minification). This little home grown framework is not perfect by any means, and I'm not begging you to include it in your project. All I'm saying is that it gets the job done and works for our target browsers.

 

If you take it a step further and focus on today's modern browsers which use features such as document.querySelectorAll() instead of document.getElementByID() and completely remove the desire to care about compatibility issues with older browsers, then the performace would be even better.

 

It all comes down to performance vs. ease of development, and in this case, I chose both . I'm not saying one way is better than the other and I think all the folks writing these frameworks are doing a great job. As Brian mentioned in his podcast, I just like to mess with my co workers and make fun of jQuery It always gets a heated conversation going...