Generally speaking, companies don't want you to download their entire catalog. They don't want competitors to be able to analyze it easily like that.

And if a store is selling books, it might have hundreds of thousands of them. No, it's not a good experience to transfer all that to the client, with all the bandwidth and memory usage that entails.

▲

zeroq 4 days ago | parent [-]

That's really weak argument.

If it's one their website the competitors can write a simple crawler and create that catalog.

And you don't have to send every single field you have in your database. Once the user selects a category you can send a metadata that enable the client to scaffold the UI. Then you cache the rest while user interacts with the site.

Barnes and Nobles - according to their FAQ - has 1 million unique items in their catalog. But they also have tons of different categories. A single book cover weights around 30kb.

I'll leave it as an excercise to figure out how much data you can fit into 30kb to make usable filtering system.

btw: opening their front page downloads 12.1MB already.

	▲	crazygringo 4 days ago \| parent \| next [-]
		> I'll leave it as an excercise to figure out how much data you can fit into 30kb to make usable filtering system. Into 30kb? That's just 300 items at 100 bytes each. So not a lot?
	▲	what 4 days ago \| parent \| prev [-]
		>I'll leave it as an excercise to figure out how much data you can fit into 30kb to make usable filtering system. Not even 1 bit per item in the Barnes and nobles catalog? So not much.