Well, for some values of “better.” Rails has built-in pagination. This is convenient. It was also clear to me even on cursory inspection that it wasn’t being terribly sophisticated about how it was doing things. That’s OK – if you’re presenting 100 rows in pages of 20, who cares how optimized the code is?
But sometimes you’re presenting hundreds of thousands of rows, so it’s nice to have a better solution, at the cost of a bit more work. Part of being a developer is knowing when it’s smart to trade off more work against some other value (like saving those CPU cycles). Enter I Will Paginate which showed up on Err The Blog this morning. Using nicked PHP code, it uses a more scalable technique that should work better in most situation.
Is this the end of the pagination debate? Nope. If you know exactly what your database backend is, you can probably do even better, provided you don’t mind coupling the database implementation decision closely to your code (and giving up portability). Knowing whether that’s a smart thing to do is another one of those reasons that developers get paid to actually think.
