Convergence, again…

I’ve just had a really interesting conversation with a collegue about the future of the web and traditional desktop software. While he comes from a very different background to me – mainframe software, then server/client software with a team of 500 developers – he does see the value of the web, and in particular web applications. However, rather than web apps replacing traditional desktop apps, he sees more of a convergence of these technologies. That way we get the best of both world. For example, here are some thoughts that were batted between us:

  • The use of CSS within desktop software (.exe’s) to control presentation
  • The development of a psuedo-browser, which would look like an app, but without all those unneccessary (and potentially dangerous, data-wise) extra buttons such as back, refresh etc
  • Solving the problem of maintaining state (perhaps using the browser-app mentioned above)
  • Storing of data on the cleint to allow uninterrupted working when offline (some people aren’t always connected to the internet, you know!)
  • Synchronisation of client and server data through a web app
  • Load-on-demand code for web apps, particularly JavaScript, to save huge files being downloaded unneccessarily

However the really interesting bit for me is that when I showed him a really cool web app (built with loads of AJAX) he wasn’t impressed. After all, desktop software has been doing that for years – it’s only webheads like me who get impressed by this stuff. Many people, especially people who are used to powerful desktop software and are unaware of how cuttong-edge this type of stuff is for browsers, would shrug their shoulders and say “so what?”.

Where a web app really sets itself apart from a desktop app is in a few key areas: presentation, speed of development, platform-independence and the fact it doesn’t need a fast computer to run. Where it fails to deliver is in giving uninterrupted working when offline, really powerful processing of data (although arguably this could be handled by the web server), communication with the local client and that age-old problem of state.

But I reckon they are solvable, don’t you? At any rate, it’s going to be fun working all this lot out.

Update: Anil says it better than I could, and raises a few other ideas as well

Nearly, but not quite…

There’s been a few of these things recently, articles that show and explain something really cool, but fail in just one area. Yesterday it was the degradable JavaScript that wasn’t unobtrusive, today it’s a neat suggestion list. While the system seems to be really good (and quick), it doesn’t validate, partly because of the use of a proprietary atribute of “SUGGEST”. Like this:

Which is a shame. Perhaps the use of class=”suggest”, in a similar manner to the way I did it for Refresher function would be better.

Still, it’s pretty cool. And cool things are the bees knees, as we all know.

Under the hood…

I was very pleased to see that Barclays is getting on the CSS bandwagon. However, all is not well in code-land. Look under the hood and a case of divitis can clearly be seen, with a rash of divs and not-very-semantically-marked-up mark-up.

So, while it’s good that they have made the effort, it’s a shame it couldn’t be done a bit better. After all, it’s not like they don’t have the money…