Multithreaded

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

When I’m developing in JavaScript I primarily use Firefox to display the results as it has really good tool support for debugging code and inspecting the resulting page. Every now and then I cross-check in IE 6 to make sure things are still working.

I was very surprised the other day to find that when I took all the style settings I was applying to DOM elements created in JavaScript out of the JS code and put them in a separate style sheet, that all the style formatting disappeared when viewing things in IE. It took a good half-hour of hair-pulling, google searches and referencing the dozen or so books I have available on web development before I finally stumbled across a fragment of code which pointed me in the right direction. I had been setting the class name of the new elements using:

domNode.setAttribute("class", "classname");

which works perfectly well in Firefox. However, IE seems to completely ignore this (although the DOM inspector from the IE web development toolbar showed the class apparently being set). The code I came across showed this instead:

domNode.className = "classname";

After converting my JavaScript to use this form, lo and behold my styles were correctly applied in both browsers. This is the kind of thing which I have come across a lot since starting to work with JS - it is really hard to find answers to some really basic things like this. One thing that is clear is that most of the books and other literature is approaching JavaScript from the point of view of HTML and CSS designers, not people coming from a background of software development in languges like Java, C++ and C.

I’m displaying text inside boxes by creating div’s with a 1 pixel border. To ensure the text clipped to the size of the box I wanted I set “overflow: hidden” and “max-height: 1.2em” and it all worked just fine in Firefox. However, in IE6 the box would stretch to show all the text. A bit of playing around has led me to discover that setting “height: 1.2em” instead of max-height works in both browsers.

Now I just need to get to grips with the DOCTYPE declarations. Using HRML 4.01 transitional without a DTD URL means the fonts aren’t the right size in IE6 (for “font-size: smaller”) but if I add the DTD to put IE into standards compliant mode then FF loses it.

I think I need to read this http://www.alistapart.com/stories/doctype/ quite thoroughly.