PIcking Your Javascript Mobile Framework: Part 14 – jQUery

What can be said about jQuery that sounds even remotely interesting? The whole world is using this framework, by far the oldest in our list.

jQuery started small. The most famous “thing” about it is the dollar sign, $. It’s what popularized the framework, as it made selection of elements in an HTML page extremely easy.

It’s not that it was hard before, but the W3C spec for HTML and DOM is a terrifying mess of incoherence. Let’s just look at selectors.

If you want an element with a specific ID in a page, you ask the function getElementById(). It takes the ID as argument and returns the element with that ID.

If you want an element with a specific class, you ask for getElementsByClassName(). You have to spell it just so, with the uppercase N or you will get an error or, worse, nothing. Instead of an element, you get a list of elements. You get a list of elements even if there is just one element. If there is no element, you get back an empty collection.

If you want an element by its tag name, you call getElementsByTagName(). Sadly this one only works for the root element (the document), while the other two work from any element on down.

As a developer, you constantly have to worry about the spelling, and about what kind of thing you’ll get back, and which elements take what function.

In jQuery, you simply use $. $ works its magic in a hidden fashion, and always gives you back what you wanted. $(‘input’) returns all the elements that have the tag input. $(‘.footer’) all the elements that have the class footer, and $(‘#onlyone’) the element with ID onlyone. You can chain the requests and for instance ask for the first row in the table with class ’employees’: $(‘table.employees’).(‘tr’)[0]

From there jQuery grew. It created widget sets, utilities, way to deal with modal windows (not as ugly as the built-in alert and prompt), etc. But it was never an MVC framework.

That’s true for the Todo implementation, as well. In this case, jQuery asks a few projects for help: Handlebars is used for templating, while Director for routing.

Considering the nature of the thing, no surprise that the structure of the code is incredibly simple: there is the index.html file, and a single app.js file that contains the entire application logic. Require is not used (but would presumably improve performance by a factor).

All in all this works fine for the simple application we are looking at. The single controller/model becomes unwieldy fairly quickly, but there is nothing preventing the app from being split into more pieces.

Sadly, though, jQuery has no guidance on how that should occur. In fact, the whole point of this series is to find some framework that gives that guidance and makes it painless to structure things in a way that is idiomatic and automatic.

Add a Comment

Your email address will not be published. Required fields are marked *