RapidWeaver 3.6: Picking Nits

As much as I respect and enjoy RapidWeaver as a product, there are some areas in which the software could still use improvement in the new version. Fortunately, RapidWeaver recently saw a 3.6.1 update that resolved a couple of the issues I was going to write about, so that was a welcome surprise.

Inconsistent Performance

iWeb is not one of my favorite Apple products, but one thing it has going for it is performance. It can open and save my website (100+ MB) in mere seconds, sometimes nearly instantaneously. RapidWeaver is another story. In fact, this is my biggest complaint about RapidWeaver, and, if this one problem was fixed, I’d be satisfied. The simple truth is that loading and saving large documents in RapidWeaver is a pain, and the new version shows no significant improvements in this area.

To test performance, I ran these tests 3-6 times, depending on application crashes and tester errors. I then averaged the numbers. The only open applications were Pages, RapidWeaver, and Activity Monitor. The test computer has a 2.16 GHz Core 2 Duo processor and 1 GB of memory. The document is 122 MB.

Here are the averages of opening my site in RapidWeaver 3.5 and RapidWeaver 3.6:

RW 3.6 only shows real improvement in CPU usage here. RapidWeaver 3.5 suffered two application crashes in this test, and version 3.6 suffered zero. Anecdotally, I’ve had version 3.5 take up to two minutes to load my site document on several occasions.

Here are the numbers for saving:

Note that version 3.6 is actually more resource-hungry that 3.5 in saving the same document. Neither version crashed while saving. Annoyingly, my computer becomes basically unusable during the saving process, and, again, I’ve encountered numerous occasions where RapidWeaver 3.5 has taken much longer to save a file than these numbers show.

FInally, take a look at RapidWeaver’s overall memory usage. This is memory usage while completely idle:

While using RapidWeaver, it gradually consumes more and more resources. Unfortunately, after quitting, those resources sometimes stay tied up, leaving the computer in a state where performance is going to be generally poor – forcing a restart to reclaim that memory.

This is my biggest complaint about RapidWeaver, and again, I would be happy if performance was the only big issue the Realmac team tackled for version 3.7. I don’t know how many other RapidWeaver users share this opinion, but fantastic new features can be tarnished when the most basic tasks – loading and saving – are aversive experiences.

Other Issues

I really only have a few additional complaints about RapidWeaver 3.6. The inability to create tables within the application is a pain. (The tables in this post are screenshots of Pages.) Not all included themes take advantage of the Theme Styles I praised in the previous post. All new themes have flexible color settings while many of the older themes do not. It would also be nice if user’s could link to hosted images rather than embedding them into the blog file. Finally, there is still no easy way to set a site’s default font. If I want my blog to be in a different font, I would either have to edit the css file or change the font one entry at a time.

That’s really it as far as criticism goes. RapidWeaver is a very nice application with just a few small issues. For me, performance is the biggest issue, and, if that could be resolved, RapidWeaver 3.6 would be a near-perfect application for my purposes.

In the next post about RapidWeaver, I’ll share some info about competing products, useful add-ons, and buying advice for version 3.6.

Update: You can in fact link to images in the blog editor. You just have to use “img src=” bracketed by < >. (I was making a mistake!)