The Fat Client is Dead

I don’t think anyone will argue against the point that a lot of applications that were traditionally desktop-based are now moving on to the web. Google has proved that you can make very rich, very responsive, and very good web applications; GMail, Google Maps, Calendar, Docs & Spreadsheets, Reader, etc. are all applications I use regularly. While some of them may not have all the features of their fat counterparts, the fact they they work anywhere with a ‘net connection and a browser makes up for it (for certain uses).

I am a firm believer that the fat client is dead, or at least dying. We are switching to an online world and the OS is being replaced by the browser. It’s really just a matter of bandwidth and latency before almost every application will move online. Things dealing with really large input can’t currently work well online but that’s just a matter of time. Serious photo editing applications for instance, would need a lot of bandwidth; every time I press the shutter on my camera I make a 10MB RAW file, and it’s not uncommon to have at around 100 photos in a shoot–uploading a gigabyte of photos to process and sort through right now isn’t feasible but with more bandwidth it would be. I think that in the next several years we might see Internet access regulated like telephone service is now, and anyone who wants a high speed connection will be able to get one–and pretty much anybody with a computer will.

Mobile phone applications are also going more web-based. Apple seems to be ahead of the curve on this one, as a lot of things for the iPhone are web applications. Some people would say that it’s too early to make that jump, as web access on the cellular networks currently isn’t very good (EDGE is too slow), but this is also what they said when Apple stopped shipping computers with floppy drives and when they switched everything to USB, etc. and those really worked out in their favour.

It’s also getting much easier to build good web applications. Things like Ruby on Rails and Google Web Toolkit are providing developers with the groundwork they need to really hit the ground running here. I built a full web app using Rails in about a month–which also included the time to learn Rails, making mistakes, doing things inefficiently, going back and fixing them, etc. I’ve also worked with Apache Struts in the past, and this application would have taken at least 2-3x the time to implement using Struts. I don’t have any real first hand experience with GWT yet (I intend to remedy that soon), but from what I’ve heard and read it really helps make something with the feel of a desktop application.

One of the biggest issues with web applications has been that they go away when the network does: on a plane, during an outage, etc. Google once again came in here with a solution–Google Gears, which lets these web apps store some data locally and let you use them offline. I haven’t seen anything really interesting using it except for Google Reader (which was the first public use of it) and now Google Docs, but I keep hearing (unconfirmed) rumours that we’ll see it integrated into GMail soon.

The other big issue that’s always brought up is data privacy. I don’t believe that this is quite as big of an issue as people think it is, as all the companies providing these services have everything to lose and nothing to gain by snooping in on your data or selling it. They’re equally as concerned with data leaks; Google gets a lot of flack about the amount of data they have, but I know that they take data privacy very seriously–a lot of effort goes in to keeping everyone’s data secure. Nevertheless, there will be institutions that will never trust their data in anybody else’s hands–I think that the providers will sell a “black box” to these places so that they can run their own internal-only instance and keep their data on site, much like Google does with their search appliance now.

I think it’s a very dangerous proposition for an new development to not consider a web UI. Personally, I think a lot of effort is currently being wasted on fat clients in companies around the world. Eventually the writing on the wall be become evident and most of that effort will be tossed out in favour of a web UI in the coming couple of years (again, not for every application, but for a lot of them). The argument to this is often that certain things are hard to do on the web, but with the current suite of tools out there it’s usually not as hard as it might seem, and if it is hard, getting it done could be a competitive advantage. Switching to primarily web-based applications can also reduce a company’s IT costs; managing application installs on workstations is dirty work, by moving to web-based applications much of this work can be eliminated.

No comments yet

Posting Frequency Plugin

Now, several weeks after it was supposed to be done and posted, I finally finished version 1.0 of my posting frequency plugin for WordPress.

The options screen is still terribly ugly, and the default colours come from the colour scheme for this site (but are configurable).

So, if you’re running WordPress, try it out.

Go ahead, try this at home

On October 5th, Google Code Search was unleashed upon the world. People have found many uses for it so far, like finding things that people don’t want found, or finding other security bugs. Now, some people have been known to find some entertainment or humour in off searches (I wouldn’t know anything about that). So, in that vein, what would make good code searches?

I thought to search for common comments that developers might use to warn people of ugly, hackish, or otherwise complicated but working code.

• “professional driver” “closed course”
  One of my favorites, but only 5 hits.
• “don’t try this at home” / “do not try this at home”
  About 100, and 20 respectively; who’d have thought that programmers would prefer the slightly shorter one?
• “trained professional”
  Again about 100 hits.
• (here)?\ t?here\ be\ dragons\ (here)?
  Only 50 hits for this one–but, like the the ‘professional driver’ one, it has more colour and I like it.
• “do as I say, not as I do”
  It shows 19 hits, but a quick check shows that most of them look like they’re just quotes.

I can’t think of any other good ones right now, add a comment if you come up with any.

1 Comment

XFN Graph v1.3

Almost 14 months since the previous release, a new version fo XFN Graph has been released to the world.

A lot of ‘under the hood’ changes with this one, as I refactored almost everything to make it much easier to work with. The spider porition is now multi-threaded, so it spiders sites much faster now. I’ve also replaced the default JGraph visualization library with Prefuse; part of doing that was refactoring things so that new libraries can be easily plugged in. This time there are also proper binary packages for Windows & OS X, in addition to the cross-platform JAR and source packages. I also set up a Java Web Start file for it, so you can try it out without downloading.

In addition to the major changes, there were a number of smaller ones which I won’t go into, but I’ll close with a freshly generated graph centered on this page. Notice how much the XFN network has grown since I made the first image back in March 2005.

3 Comments

New Design

Unless you’re reading this with a feed reader, or are a first time visitor, you’ve probably noticed that I changed the site design (again). This is the third major design since I launched GeoffHolden.com back in October 2004; three designs in two and a half years isn’t too bad.

I’m pretty happy with this one (for now anyways). It has several new features that the old design didn’t have:

• It actually expands to use the whole browser width.
• It adds the categories/tags features that I didn’t use/build into my theme before.
• It’s much easier to add a new header image with this design (drop an unprocessed photo into a directory and the server takes care of the rest the first time it’s loaded).
• The embedded gallery theme is done much more cleanly this time. (Now that I have a proper understanding of how they work, as opposed to the hack-job I did last time)
• The photo gallery now uses JavaScript and does the paging on the client-side. So the entries per page is based on window width, and changing pages doesn’t require a reload.

5 Comments

Java’s Future

There’s been a lot of talk about Java lately, mostly because JavaOne is currently underway in San Francisco, but it’s got me thinking about Java’s future, should it have one.

When Java was released in the early 90’s, it got itself a bad name, applets where overused, slow, and usually useless. The niche that was once filled by these applets has long been taken over by Flash now.

Java has made huge inroads on the server-side. Java Server Pages and similar frameworks have made it one of the top web application platforms today. So, the language touted as ‘write once, run anywhere’ has been more successful on servers where the environment can be controlled, as opposed to what it was originally designed for.

This leads to the question ‘why hasn’t Java been successful on the desktop?’ One reason is that Java applications were slow and ugly. Fair enough, but the key here is ‘were’; Swing looks a lot better than it used to (and much better than AWT ever did). Improvements in the JVM (both Sun’s and IBM’s) have given Java applications the ability to approach the speed of applications written in native languages. Does this mean that all Java applications are now fast? Of course not; Java lowers the barrier to entry for somebody to create a GUI application; unfortunately this means that a number of applications are poorly written. Java builds in a lot of safeguards that make it easier to make an application work, but that doesn’t help you make it good. In a language like C++, the barrier is much higher but that forces people to think and learn more about what they’re doing. Now, don’t get me wrong, lowering the barrier like this is a good thing overall–it may very well be the thing that saves the music industry by helping to cut out the record companies, but that’s a topic for another post on another day.

Another issue that always comes up is that Java applications don’t feel like native ones. This is something else that’s gotten a lot better in the last couple of years. A few lines of code in a Java application will tell it to use Windows-style widgets on Windows systems and OS X ones on a Mac. That brings you very close to the feel of a Windows application (things like drag & drop take a bit more work), and it brings you 80% of the way on the Macintosh. There are a few more things you have to do to make Java feel ‘right’ on the Mac, like making the menu go to the top of the screen, using the default menus, etc. but it can be done. I’ve written an application that, with a single JAR file, feels like a Mac app on a Macintosh, feels like a Windows app on Windows, and also runs well on Linux. Is it ‘write once, run anywhere’? Not quite, the GUI elements needed to be tweaked on the different platforms, but everything else works fine.

So, now that the speed and the feel can be taken care of, we deal with the other major issue, which is probably the biggest issue–deployment. This has always been a big issue for Java… you have to get the JVM on the system before the applications can run. There are a few issues here, the first of which is that the JVM is large–you can’t expect everybody to download it. Getting distribution rights from Sun used to also be tricky or impossible, so you couldn’t just include it on the CD with your application and OEMs couldn’t include it on all PCs. That has changed in the last couple of days; Sun is now going to allow OEMs to apply for a license to redistribute, they’re also going to allow Linux distributions to include it. They’ve also stated that they will open source Java when they decide on a way to do it that won’t risk fragmenting the language.

So, do I think Java has a future? I do. I believe that it’ll remain a strong force on the server, but I also think that it may be nearing it’s time to shine on the desktop as well.

No comments yet

Gallery Lightboxed

If you’re into fancy web tricks/layouts/etc. and you haven’t already, check out Lightbox JS v2.0. It’s a neat little script that lets you link to images and have them display on top of your current page, without having to navigate away.

I’ve been meaning to try to integrate it into my photo gallery for some time now, and finally sat down and did it this evening. So, if you try to browse through my gallery now, and click on the thumbnail of an image, the full size version will load over the current page. I didn’t enable it for the random photo on the sidebar though, as lightbox needs around 110kb of JavaScript to operate, and I think that’s a little heavy for my page (my 12kb CSS file is big enough as it is), but if you follow a link titled ‘Photo Gallery’ while on a slow connection, you should be ready to wait for a little bit.

Update: I’ve made a few more changes to my Lightbox integration. I removed all the fancy effects, and made te necessary changes to my gallery theme to enable the use of the lightbox ‘previous’ and ‘next buttons’. As a result, I’ve cut that 110kb of JavaScript down to only 24kb.

1 Comment

White space is not “stealing our bandwidth”

I just read yet another article about how extra white space in HTML code is wasting bandwidth. I have several issues with these articles, the first of which is that people actually believe them.

Here are what I think are the main issues:

1. Most large sites use HTTP Compression. This means that for all text files (HTML, CSS, JavaScript, etc.) the server is compressing the file before sending it “down the wire”, where your browser will decompress it. GZip is a respectable compressor and will remove almost all redundancies in these files.
2. Even if there wasn’t any compression, that whitespace is useful for debugging and then for updates/upgrades, etc. You wouldn’t write all your C/C++/Java code with no extra spaces/newlines because the compile time would be a few milliseconds faster, would you? No, because it would get too difficult to update the file properly.
3. The articles always ignore the benefits of your browser cache. Sure Google’s logo image could be more compressed by making it a PNG, but chances are that people who use Google (is there anybody online who doesn’t?) use it multiple times a day, the cache means you likely only download that image once. There are also issues with PNGs and some browsers, for instance older versions of Opera and pre-Tiger Safari will attempt to adjust the colour of PNG files if there is no colourspace info embedded (which would enlarge the file as well). Someone like Google wouldn’t want the colours of their logo changed on certain browsers.
4. The argument for using CSS shorthands is somewhat debatable, so feel free to ignore this point. They will make the file smaller (before and after compression), and don’t signifigantly decrease readability. I don’t generally use them because I tend to be more explicit when writing CSS rules. The other reason is that I don’t trust them–getting the same set of CSS rules to work across all browsers is tricky enough without using shorthands.

No comments yet

Visual Upgrades

As you or may not notice as you’re reading this, I’ve made a few minor updates to the style of this site. I wanted to give the site a little more style, pizzazz, panache, and might I even dare to suggest cachet? (Oh, it’s got cachet, baby! It’s got cachet up the yin-yang!)

Now, as a warning, if you happen to be using IE the page might look slightly worse than before–the round corners will be far less smooth than they should be. The solution to this is proper PNG transparency support (look to any other current brower, or wait for IE 7)

The first of the updates was the banner image up top. It looks much like it did when there was no image, but it has some background texture now (an image of a hard drive, from stock.xchng).

The other update was a slight gradient in all the other blue boxes. Barely noticible in a short post, but in a longer one you can see how it darkens as you move down the page. This gradient is why I had to change how I did my corners, they used to be 100% opaque images with both the blue and grey. Now, because I don’t know which shade of blue will be at the bottom of a post, they only contain the grey and the rest is transparent. In sensible browsers the PNG alpha transparency works great, but in IE I had to fall back to the binary transparency of a GIF. And before somebody trys to inform me of the AlphaImageLoader workaround to getting transparency to work in IE, I’ve already tried it. It fails when you have to use background-position, but was otherwise working OK.

1 Comment

XFN Graph v1.2

I just finished the relase of XFN Graph v1.2. This version removes the text labels on all the links, opting for a colour-coded approach. Maybe the choice between the text and the colours will be an option in a future version.
Here’s the list of what’s changed:

• Added a more visual representation of what the links are.
• Added Help.
• Made the spider follow frames as belonging to the same site.
• Fixed a bug whereby some sites didn’t get spidered because they were marked as visited but not spidered.
• Fixed issue with rel=”me” links that were not being spidered.

No comments yet