I’ve been doing a little work at home with jQuery and jQuery Mobile recently; at the jobby job we use ExtJS widgets and components. Comparing the two has me thinking. Each of these javascript libraries represents a different philosophical approach to developing web applications.
jQuery Mobile is an extension of the jQuery library, and similarly Ext JS components are based on the Ext Core library. Both core libraries do similar things. They normalize browser differences in event handling and XmlHttp request implementations; they add to or extend the core browser document object model; they provide a means to create custom events and subscribe to these events with handlers; and they provide an API to create custom components or plugins. They approach things slightly differently. jQuery focuses on a xpath/CSS selector based API for working with DOM elements. Ext has this feature too, but also creates some base classes to supplement javascript’s core objects. Ext1 also extends some of the core javascript objects (like String and Array) to provide additional functionality. Beyond this though, the libraries diverge.
Ext is component based. The goal of the library is to provide the developer with reusable application components that can be wired up with data access objects which, to a certain degree, simulate a database or an object store in javascript. The dataobjects are configured to communicate with your server application via XmlHttp request. This approach is also used by libraries like Sproutcore. Components include toolbars, forms, various navigational tools, panels, modals, dialogs, charts, etc. The components can be used independently on a given HTML page, but they are often brought together into a complete application that works much like a desktop application that lives in a browser. The default themes provided with Ext look very much like a Windows XP era desktop application.
jQuery has some ui components as well, but the scope is limited. jQuery UI basically extends HTML with a few extra niceties like date picking components, tabbed navigation, sliding selectors (imagine a volume control) and so on. These components aren’t really designed to be bolted together into an application. Instead they enhance an existing HTML interface. This underscores the differences in philosophy.
I think of jQuery’s approach as an enhanced, interactive document approach – where each web page is just that, a page of information. The page can be used (or at least read) without javascript enabled and, more importantly, be discovered and interpreted by search engines. Netflix.com is a good example of this pattern.
Ext embraces an application approach. The web page, the HTML document, is a host for a complete software application written in javascript2. The application doesn’t function (or even exist) if the browser doesn’t have javascript enabled. The application is effectively invisible to search engines. Gmail is a good example of this kind of application, so are Apple’s old Mobile Me applications (soon to be replaced with iCloud apps, I suppose).
These approaches can be combined. Google+ and Facebook have document centric “core” functionality like news feeds, but advanced features like “chat” and contact management are application-like modules that are welded onto the document base.
Combined or not though, I think these are the two ways of thinking about client side architecture of web applications. Each method has its tradeoffs.
The enhanced document approach
You get
- Search engine visibility, and likewise the possibility to support older browsers or javascript disabled or inhibited browsers
- Separation of concerns: The design and HTML/CSS implementation of that design can be largely, if not completely, separated from the interactivity
- Complete design control
- Shallow learning curve
- The ability to create a simple page/application first, then add features as they are discovered or needed.
- Lightweight JS and interaction model – for example a simple web page can be made highly interactive with a small amount of custom JS supported jQuery. The full Ext library is rather large.
You lose
- Enhanced interactivity. Powerful widgets like data grids and the like must either be manually integrated, built custom, or done without.
- Speed of prototyping and development. With a toolkit like Ext or Sproutcore, there’s probably already a widget that’s pretty close to what you need. The widget might be used as-is in a prototype, and extended for the real application.
The application approach
You get
- Speed of prototyping and development
- A reasonably good look and feel (if not UI design) “out of the box”
- Advanced features that resemble “real” desktop software (this can be very important in, say, a corporate setting)
- Easier division of server side and client side development. For example, an Ext developer can build an entire application powered by dummy JSON data, while the Java developer builds out a RESTful server application to support it. They only need to agree on the data api.
You lose
- Time due to high learning curve
- Design flexibility
- Integration of legacy or third party client side components may be difficult or impossible.
- Search engine visibility
- Libraries, components, and custom javascript tend to be large and complex with these sorts of applications
- Performance can be poor on slower machines
I imagine a seasoned jQuery developer reading this and thinking “but I just downloaded a data grid plugin for jQuery…”; there’s an Ext developer somewhere thinking “I just wrote my fifth custom Ext theme, it’s not that big of a deal…”. All true. These lists are just big executive level3 ways of thinking about the two approaches.
The next time I have to make a big decision about which approach to take with some new development, I’ll probably use this list (or a list like it) as my guide. The next time I have to convince a room full of wolves developers to take an approach, I’ll definitely make a big list on a big white board.
I’m working on a small personal project now in which I’m taking the enhanced document approach. This approach has allowed me to work pretty quickly by banging out the required features using standard HTTP type web application methods (forms, links, and redirects) while planning for more advanced features down the road. Also, because I’m forced somewhat to keep things simple, it’s allowing me to target desktop browsers and mobile browsers at more or less the same time (because I completely control the design) which is pretty cool too.
