This is very clever, I just tried it and was impressed.

Streak, thanks for sharing all your clever technical hacks, I always enjoy reading them.

I'm confused as to whether this webapp implements its own search box, or if it is somehow intercepting input into the browser's search box. Could someone shed some light?

We implement our own search box, we just made it look like the browser's search box to try to minimize confusion.

Surely disguising your search box as the browser's search box is merely adding to the confusion?

Also, presumably it isn't always identical to the browser search box - you're going to have trouble with all combinations of browsers and colour schemes and skins etc.

I second this and don't think this is an elegant solution. This is kind of a leaky abstraction - you are pretending to have many rows on the screen but you are unable to hide the fact that you don't because you are breaking the in-page search. You will never be able to fix this in all, maybe not even in most cases - your search box looks nothing like my Opera search box. But it does not stop with in-page search - you are probably breaking select all, printing, scroll bars and what about zooming? And what if I change my keyboard shortcut for in-page search or use the menu to invoke it?

All that aside in my opinion the mistake is to allow the user to have »hundreds of thousands of rows« on the screen - real or virtual - in the first place. What a waste of time to scroll through that. I would just offer filters that almost immediately update the set of matching rows and display the first few and maybe highlight the match in each row. When the user scrolls to the bottom you can load more rows either automatically or by pressing a button.

The user will understand what is going on, is encouraged to filter instead of randomly scrolling through thousands of rows and everything from in-page search to printing works just as expected. And last but not least it is probably much simpler than your solution. (And the user is still able to scroll through all rows and in almost all cases they will stop way before the page size becomes a problem for the browser besides you are using an old phone, but whoever attempts to scroll through thousands of rows on a phone probably deserves the result.)

>we only actually render the rows that you see and simply reuse those rows and change their contents

What warranted this extra load onto your database instances, as opposed to loading all rows on the client? Do they usually have a million tasks?

Sorry, it could have been clearer. When we say "render" we mean actually output HTML. We do load all the data onto the client.

This is nothing: you should see the wizardry in their in-gmail application.

Their app looks neat. Isn't it susceptible to gmail changes breaking functionality?

I think disguising your search box is only going to be more confusing. Giving the user a clear and obvious search box is a better design, IMHO.

Streak, you always amaze me with your clever technical solutions. Your Gmail application is equally as impressive, thanks for sharing this will no doubt come in handy one day.