Libraries and Frameworks

The past few weeks I’ve been implementing a stock trading interface for cell phones.  I thought I’d give jQuery Mobile a whirl.  It looked quite nice in the demos, at least, and I was curious.

jQuery Mobile promises that the pages will look app-ey, and will work on iPhones, Androids and Windows Phone 8 devices.  This turns out to be true.  It works.

The main idea with jQM (as the kids today call it) is that you generate very standard HTML, and then you point jQM at the HTML.  jQM then transforms the HTML into…  more complicated HTML.  This usually means that an element is turned into an element with three divs nested outside it, and four s inside it.  Or something.  To get the proper styling and rounded corners and everything nice.

And it works.  You write a minimal web page with s, and as by magic, it turns all app-ey.

After working with it for a week or so, I had most of the stuff working.  You could enter orders and get real-time quotes.  But there were niggling bits that were just ugly. 

iPhone would “flash” the address bar on page transitions.  The only way to make it stop doing that is apparently to not use elements.  So I generated  (nested) elements that I instrumented from Javascript to do the right thing.  Success!

Then I discovered that if I put in a jQM dialogue box, it doesn’t just display it — it ejects the previous page from the browser, so that if you hit the “cancel” button, it reloads the previous page.  That just doesn’t work on complicated order entry pages, where the user may be in the middle of something.  So I wrote my own dialogue popup thing.  Success!

jQM keeps three “pages” in the DOM at all times, so that it can do fancy transitions.  This means that if you have elements that use document.getElementById(), they may stop working if you’re unlucky enough that any of the pages happen to have elements with the same ID in them.  So either rewrite all the code to use “class” instead of “id”, or alter the page cache to prune selected pages from the DOM so that this doesn’t happen.  So much.  Er…  success?

So this is what I’m bitching about:

When you start working with a new library, you usually doesn’t have a very good overview of what it provides, so you write un-idiomatic code.  As you get more confident in how it works, your code grows better, clearer, shorter and more idiomatic. 

With frameworks like jQuery Mobile, you start off with something that looks like the demo app, totally idiomatic.  Then you discover that it doesn’t quite do what you need, so you add more and more hacks to get around the framework.  The code grows less and less idiomatic, and uglier and bigger and more complicated.

It’s like there’s a separate tribe of Frameworkers that put all their effort into making the Demo App like two lines of code.  If you want to do something a teensy bit outside of what was intented, you end up writing 10x as much code as you would have done without the framework.

It’s pretty annoying.  By this point, the remaining bits of jQM that I’m actually using is pretty small.  I’ve mainly crabbed a lot of the (quite pretty) CSS declarations, and use some of the page transitions stuff, and the rest is hand-rolled.  The code would probably get shorter if I ejected jQM completely.


One thought on “Libraries and Frameworks”

Leave a Reply