« The Web Control HTML 5 Left Out| Main | How many Christmas Presents Could you give Away? »
The Web App that's not a Web App
I have to admit getting a few chuckles in over the past month.
A month or two ago, I introduced my hobby site, hn-books. Basically I took the hacker site I usually visit, found out what books hackers recommend to each other, put them in one spot. Now I'm going through them and reading all the good ones and reviewing them.
Fun stuff, but the really enjoyable part, at least professionally, is the response I got to the way the site was designed.
Several people complimented me on the speed of the app -- great query time! Very responsive! Nice speed on the database times!
I appreciate that. App speed was so important to me that I decided not to make it an app.
You see, my design goal was to see how much interactivity I could put into the application -- without actually adding any kind of server. So although it looks like you are doing things and the server is responding, it's all just the web page.
Take, for instance, the main page. It looks like you are able to click buttons on the right of the screen and sort/filter by the format of the book, the types of questions the book answers, or the skill level. And you can -- but what's really happening is that the static list is being sliced and diced. There is no server call involved.
Or take a random book detail page. About half-way down you'll see a section titled "the buzz". This appears to be an almost-real-time display of conversations about this book on Slasdot, HackerNews, Reddit, and more. Pretty powerful data-mining capabilities in that little tabbed box -- you can even watch related videos.
But none of it involve a server. Just a bit of sleight-of-hand and some Google API calls.
There's a section for related books -- if you like this book you might also like this other one. And a place for finding books that answer similar questions.
All static.
Finally, the piece de resistance, the "Answer Questions" page. Here's a page where you can pick a question to answer, pick the books that you think help answer the question, order the books by your own criteria, add a personal greeting, and send the link to a friend.
Surely that involves some persistence on the server, right? I mean, how could you store a personalized list of preferences and books to share without, well, storing it somewhere?
Not at all. It's all done using query string magic, which means there's a limit to the number of books you can select and the message, but in all practicality you never reach the limit. Over a hundred folks have used it, and so far nobody has reached the limit. If you don't see the limit, it doesn't exist.
And that's a key point: it doesn't matter to the user at all how the site is constructed. All they care about is content, speed, and features -- in that order. So while it may appear to be a classic app, and people may think of it like a classic app, it really doesn't matter.
So when I get compliments on the speed and flexibility of the site, I have to smile. Yep, it's a pretty fast site. Couldn't get any faster, actually -- because there's nothing but page loads and some light javascript going on.
Makes me wonder how much farther I could push it.
Leave a comment