The current design of zcash_client_backend doesn’t provide a direct transaction-listing capability because this is left up to the backing data store; in the case of WebZjs, this should be an API that is provided directly by the in-memory wallet backend.
The reason for this choice is that storage backends vary dramatically in terms of what the best approach is to query them, and trying to flatten this down to a common interface in zcash_client_backend is almost always going to produce a user experience that has fewer features than accessing the storage layer directly permits. For any given application, the storage layer is not something you’re going to swap out, so the top-level API should expose direct access to that layer. For example, in Zashi, we access the backing SQLite database directly from the app to provide the transaction list, and can use SQL queries to filter and reorganize that data for the best user experience.
The interfaces in zcash_client_backend provide all the functionality that is needed to enable scanning the chain, creating transactions, and so forth. But it is not currently (and may never be) intended to provide a comprehensive solution for data access in itself.