Multithreaded

I latched on to dojo early in my Ajax career (that would have been, oh, say 4 months ago). The approach the dojo developers take to modularity, classes and so forth appealed to the Java programmer in me. It made things familiar enough to get a handle on easily. Plus, I went to see Dylan Schiemann present a workshop and was impressed by the depth of his knowledge.

However, as I started to work seriously on our application, I began to get the feeling that I was missing something fundamental about JavaScript by hiding it behind the familiar constructs of classes, inheritance and encapsulation in the form that I am used to. Because real work (you know, the stuff that pays the bills) came up I needed to pause what I was doing with JavaScript, but in the meantime, I began to take a close look at HTML and CSS design. In my spare minutes I re-developed our company website to use the ideas I was learning from Andy Budd and others about separating content from presentation, making the design flexible to handle different screen sizes and printers, and things like using CSS for rollovers rather than JavaScript actions.

Then, last month, I came across jQuery for the first time. The first thing that impressed me was the documentation. It’s not 100% comprehensive, but it’s a lot better than dojo’s documentation and good enough to get going straight away. The other thing that struck me, however, was the different focus it has. Using dojo, I felt as if I was using a programming language first and DOM stuff second. I’m not saying that that is the fault of dojo, but its efforts to make things more Java-like meant I didn’t need to break out of my mental model. Also, jQuery has the feel of a second wave of toolkit, building on the lessons learned from things like dojo and protoype.

jQuery most definitely focuses on the DOM first. It provides a lean, but well-formed set of constructs to search and manipulate DOM trees. The searching bit uses CSS selector strings (or XPath, but I like the CSS) which are now more familiar to me. My own focus has now shifted and I’m seeing the client-side application as primarily visual elements with behaviour attached, rather than application behaviour with views attached as I had been. I can see pretty clearly now how this fits in with an MVC-style and how I can connect it up with the messaging system we wrote earlier to reflect changes in our business domain objects.

A bonus is the large number of plugins that exist for jQuery, written by third parties. I am making use of the drag and drop features of the Interface plugin and already I am seeing a big reduction in the amount of code I am having to write to get things done.

Throughout the 25 years or so that I have been writing software I’ve looked at a lot of different languages. I’ve always believed that even if a language was not practical to use for whatever sort of problem I was trying to solve at the time, it is still valuable to be pushed into thinking about things in a different way. I’m starting to feel that JavaScript and jQuery are causing me to think in new ways

Technorati Tags: jquery, programming, javascript, Web2.0

Or at least it is what programming is becoming. If anything defines Web2.0 for me then it is the idea of moving the software into the web itself (hey, the network is the computer!) Web 1.0 was about getting users to interact with websites. The websites, by and large, were (and mostly still are, for that matter) islands. The user needed to hop from island to island to do several things, sometimes copying the data by hand to get something done, e.g. taking a post-code from an address on ons site and copying it into the search box on streetmap or similar. If you were lucky, the website designer had done this simple sort of stuff for you.

Now, however, it is becoming possible to use the APIs which a lot of sites, such as Flickr, Technorati, Amazon, Yahoo!, Google and so on, are providing to produce actual applications. Those sites are building core services that others can create richer applications on. The basic stuff is being pushed down the stack just as with any programming language libraries and frameworks. The system is evolving.

This is heralding a fundamental shift in the nature of programming. These APIs will become standardized over time so I won’t be tied to Flickr to hold my photos, or Google for my maps. Standards groups will form to create abstract APIs and these web service provider will either conform to them or wither. This is the network effect in action.

These APIs are programming language independent. They are mostly specified in XML or JSON and libraries exist for every mainstream language to make calls in those formats. The new applications will be on the web themselves, or be rich, desktop, connected applications. The ‘connected’ app is a powerful idea. Let me use the power of my computer running a proper desktop application talking to a variety of data sources on the web. The iTunes Store is like this. The blog software (ecto) that I’m using to write this does this. It’s nice.

The biggest immediate problem such an application face is what to do when a service that it relies on is unavailable. In theory, any application is like this, but we have become used to the reliability and availability of desktop machines, local databases, etc, that such a failure can be taken as fatal and a small amount of downtime tolerated until the problem is rectified. Web services are not so highly available at the moment. It could be that the service itself is down, or that the network has failed somewhere between us and them. The standardization of APIs might mean that I can fall back to a different mapping service if my main service is down, but what about if I want to get to my photos?

Another reason I like the idea of connected desktop apps is that there is the opportunity to cache data locally so that if I am totally disconnected from the net then I can still work and things will synchronize when I re-connect. (This sounds great, but something I’ve learned over the years is that synchronization is hard to do and few implementations do it well. Maybe there is the opportunity for a web service to do it right and make it easy?) Alternatively, because my ’stuff’ is all on the web as well, if I don’t have access to my desktop or laptop then I can still get to the data and functionality I need via a web browser.

We’re still in the early stages of all of this. The Web2.0 crowd are as small (but growing) band of pioneers and it will be down to us to experiment, innovate and resolve these issues before the whole idea can become as mainstream and embedded as, say, object orientation is now that even languages like Basic support it. It is, as always, an exciting time to be a programmer.

Technorati Tags: programming, Web2.0