jQuery
Wednesday, June 24th, 2009For years now I’ve tried as much as possible to stay away from writing anything approaching a UI. This goes back to a product I’d built a prototype for at Borland when a junior product manager type was invited to a demo. I remember the guy turned up (barefoot, for some reason) and proceeded to demand that the UI be re-written as a wizard – that being the trendy paradigm at the time. I told him that that model wasn’t appropriate for my project (it would have been like having clippy the paper clip replace command mode in vi) and a bit of an argument broke out. We eventually did it my way, promising to “investigate” a wizard approach later (yeah right) and I left the company about a month after release and the product eventually died. I realised at that point that because the UI was the point of contact most people had with the code all the idiots would focus on that and demand to have their input as a way of making their mark. Form that point on I tried to keep to back end processing – databases, messaging, parsing, compiling; that kind of thing. And because the back end is generally regarded as the tougher discipline than the UI, it pretty much worked out. But now that kind of split is going the way of other specializations (I know a TV news sound guy who hasn’t worked worked for 5 years because the sound guy and cameraman were combined. Now of course the reporter often does the sound and the camera as well so there are two specialisms gone). Nowadays most development is based around a web site, and the specializations of front end and back end development are also going. Now you have to be able to do both. Not design, thankfully, of the world would be full of very ugly websites. But all the code that makes the thing work is often done by one person – Javascript and CSS on the client, JSP or PHP or whatever in the middle and Java, PHP or whatever on the back end. So I’ve been brushing up on Javascript (I once wrote a Javascript engine for a web browser so I used to know it quite well) and CSS and HTML and things. And I’ve got to say it’s not so bad. The guy who has to deal with the idiots is usually the designer and everything else is hidden from view. And all of this is really just a preamble to the point of all this, which is that I’ve recently discovered jQuery and it rocks. It does such a great job of abstracting out the interface to the HTML code from Javascript that it is actually a pleasure to develop with. For those who do not know it, it is a Javascript library that uses an xpath-type query language to access HTML elements in a declarative manner (by class name, type, id or a combination of each, and optionally taking into account the parent objects in the selection too, so you can select all radiobuttons that are children of a div with a certain id, for example), and allows operations to be performed on each matching result, often with a lot of built in convenience methods. So if, for example, you want to make a div appear when a button is pressed, you can write a handler for the button click that select the div and call show(’slow’) on it to make the div appear expanding slowly in the middle of the page. Which is all very cool. If I have a problem with jQuery it is that the mapping from the usual Javascript objects to the jQuery ones (for example, using the show method instead of accessing the style directly) isn’t too well documented. I’d guess that a lot of people started out using jQuery and never had to transition. So I’m going to try and create some tutorials for old-timers like me who know what they need to do but need some hints on the new way. So watch this space.
[ad]