Mad libs

There is no doubt that JavaScript libraries have changed the way we work.

Posted September 5 2010
JavaScript, Opinion, Web
No comments
Comments closed
Tweet this article

There is no doubt that jQuery and other Javascript libraries (such as the less pop­ular MooTools) have changed the way that the web-based user inter­faces are con­structed. They have made client-side engi­neering (once a term I never heard) pos­sible. They have removed the need to address dif­fer­ences in the doc­u­ment object model and holes in the imper­fect imple­men­ta­tions some browsers (cough-IE!) employ. They have made event han­dling much simpler.

For all those con­tri­bu­tions, Javascript libraries like jQuery are lim­ited. Take a look around the web at some of the user inter­faces that have been built using jQuery. A good example is the Cover Flow inter­face. For me, Cover Flow is of ques­tion­able use. Apple intro­duced Cover Flow as an view in the MacOS Finder quite a while ago (and later on the iOS devices), but I have never used it. How­ever, it is a fetching bit of eye-candy, and there seems to have been quite an interest in dupli­cating this inter­face on the web. Per­form a Google Search for “javascript cover flow” and you’ll see what I mean. I found no less than 6 dif­ferent imple­men­ta­tions of the Cover Flow inter­face in Javascript, mostly making use of jQuery. And they’re all terrible.

If there’s one thing that jQuery really needs help with, it’s with effects. Heck, you still cannot ani­mate simple things like colors. That’s a glaring over­sight in what is oth­er­wise a very com­plete package of tools. Granted, there is a lot of work being done with jQuery. Many devel­opers have cre­ated plug-ins or add-ons or other wid­gets using jQuery as a base, and many of them are quite useful. But at some point you really have to draw the line between building a UI that is simple and effec­tive and building an online expe­ri­ence that requires some high-end ani­ma­tion. For the latter, you need Adobe Flash.

Or do you? Enter UIZE, a JavaScript frame­work I had never heard of until one of my coworkers sug­gested it as a pos­sible solu­tion to an inter­esting problem. A client came to use with a request for a microsite. This microsite will be highly inter­ac­tive, with ani­mated tran­si­tions, an inter­ac­tive demo, video pre­sen­ta­tions… you know, the usual. The example web­sites we were pro­vided as the basis for their thinking were all Flash-based web­sites. So, of course, we went about drafting a pro­posal for a Flash-based web­site. Then came this request: “we want to be able to dis­play the site on an iPad.” I imagine I’m not the only devel­oper to hear this request recently. We’re all going to be hearing it more often in the future.

Ulti­mately, my coworker and I deter­mined that we could achieve every­thing the client wanted to do, with the excep­tion of really sophis­ti­cated vector ani­ma­tion, with a com­bi­na­tion of video and dynamic HTML pow­ered by a com­bi­na­tion of jQuery and UIZE.

UIZE (pro­nounced “U-ize”) is a bit dif­ferent from what I think of as a JavaScript library. This is why I am making the dis­tinc­tion between libraries and frame­works. UIZE looks nothing like jQuery. It is, in fact, huge. The full inven­tory of UIZE frame­work files is over 4 MB in size, although the cus­tomary page load is rel­a­tively minor. Whereas jQuery pro­vides tools for han­dling many aspects of the DOM and ele­ment style, UIZE is very spe­cific. It’s built for cre­ating ani­ma­tion and inter­ac­tion, and it’s very very good. Take a look for your­self at the many UIZE exam­ples and you’ll get a sense of what this frame­work is capable of providing.

There are a few caveats to using UIZE. First, and again, it is very spe­cific. This is not for gen­eral client-side engi­neering. Where jQuery works as an exten­sion of the JavaScript lan­guage, UIZE is more like a set of black boxes that gen­erate high quality effects and inter­ac­tions for par­tic­ular cases. Or, as I described to my coworker, UIZE is voodoo. Second, and because it’s voodoo, it takes a while to under­stand what UIZE does and how it works. Con­tributing to this dif­fi­culty is the doc­u­men­ta­tion. While I often con­sider jQuery to be the stan­dard for having excel­lent docs, the UIZE doc­u­men­ta­tion is not pro­vided in a friendly format, has holes, and lacks examples.

For­tu­nately, UIZE “does not extend native objects”, meaning UIZE and jQuery can coexist peace­fully in the same web page. And, like jQuery, UIZE is open source, free to use, and (most amaz­ingly) sup­ports mobile devices. All of the UIZE exam­ples work on an iPhone. This one advan­tage makes UIZE worth the effort to under­stand and implement.

This is an great time for client-side engi­neering on the web. Javascript libraries and frame­works have really given us the power to create rich user expe­ri­ences without Flash. As Flash moves away from simple effects and becomes a plat­form for high-end ani­ma­tion and appli­ca­tion devel­op­ment, resources like jQuery and UIZE bring us back to cre­ating web­sites that don’t use Flash as a crutch. That makes them more search­able, more acces­sible, and allows devel­opers to easily sup­port more devices.