A few days ago, an Enterprise App user asked me if lazy loading is better than pagination. My answer: Totally! Pagination is an old, so called, web 1.0 solution. At that time, no AJAX where possible at all.
It's not very usable to have a lot of 1, 2, 3, 4, 5, 6, ..., 100 links. Lazy loading (á la Vaadin's way) not only is easier to use but to understand for the end user. If a user sees a scroll bar, she will understand that scrolling that thing will cause the rows to... well, scroll. No need for further explanation about it (is there any explanation to make?). Chances are that pagination will cause most novice users to get lost, at least at the first time they use the software.
Sometimes scrolling through the entire data set is certainly necessary and pagination could make that task a pain in the neck. I think pagination is OK if we have, let's say, seven pages at most (tanks Miller). If the number of pages is uncertain at design or development time, I would definitely try a different approach. Nevertheless, if the target client devices allow it, I will go with lazy loading.
I don't know why the heck I still used pagination for that much time. I think I just get used to use pagination for every table. DisplayTag could be guilty, but even DisplayTag can be configured to use new appealing delectable lazy loading.
Some of you will argue "Google uses pagination". I must admit there are situations where pagination makes a lot of sense. I can't imagine an almost infinite page with all the results of a Google search. Also, I feel very comfortable reading online books in a paginated user interface. But a lot of debate is happening out there. Even Google itself prefers view-all search results.
Another great thing about lazy loading, specially (but not exclusively) when used in tables, is that it is a good way to get your web applications to appear more modern, more web 2.0. Just note how Facebook, Twitter and other heavyweights use lazy loading to show their data. Go ahead, modernize your web apps by using some lazy loading.