I finally got tired of the flex frontend I build for my music database - mjuzique.dk - a while ago. My flex skills are, mainly due to a lack of interest, pretty limited, so instead of trying to fix the bugs and incorporate my new ideas, I thought it would be better to just redo the frontend using good old html and javascript.
Basically the thing is just one page with a list of my private music collection, and of course I need some kind of search to make it easier finding things.
I realized though, that I couldn't think of one good reason, why I should have to make server roundtrips ( postback, ajax etc.) for each search, when I already had all the data right there rendered to the site. Most computers these days probably have a lot more available ressources than my poor old server anyway, so why not let the client do the work?
I came up with what I chose to call inline searching (I should probably begin using flashier names for my ideas like Unicorn or Connecticut). The idea is very simple actually; Insted of the usual SQL like search, I use javascript to traverse the already rendered data, and based on a regular expression with the input criteria, I know whether to show or not show the current row.
While I was at it I decided to also build in a highlight feature, showing where the match was found in each row... just for the fun of it.
At the moment the list contains ~1440 items, which of course means traversing the same amount of rows in the rendered table. It doesn't seem like that much, but I was still rather curious to see how it would perform. The result was indeed satisfying, after having tested using both IE7, IE8, Chrome and Firefox on four different computers. I honestly doubt it could have been a lot faster using serverside searching, and it actually doesn't use as much CPU ressources on the clientside as expected.
I will probably write more about the hurdles I ran into and the other features like the last.fm integration later on...