if you are going to have more than 100 or so items, i would recommend creating a DB to store the information. that way, you can later re-group on the fly as needed, for example by place, by rating, by name, by age, etc...
you can then use html to show the DB's data on the web.
typically this is done with php>html (semantic) -or- php>JS>html (ajax).
if you say "The next page", that seems to imply the first combo, since ajax can all run at once without reloading. it's a balancing act: searching local data is going to be faster than searching remote data, but sometimes there's too much data to load it all up-front. a phone book fits in JS, no problem, but google's index? not even slightly.
the DB itself can create the specific selections, you simply turn the result list into something people want to look at and use.
that have a VERY simple query interface. the problem is death by variety more than nothing to eat.
now, most browsers themselves include a powerful DB (webSQL or indexedDB), but those are pretty complex beasts and you don't need them for the task described.
you can do it client side if you have say, less than 2MB of data in whole. if it's really good/rare data people might wait upfront for 5-10MB of JSON, if they are going to see several views once it loads up. after that, it's time to buy a webplan that includes a DB so you can dish out result lists instead of full tables. This is slower each time than client-side searching, but quicker upon page landing.
and of course, just for confusion, most pro sites these days use hybrids: you store all the data server side, but deliver 5 pages of results on a search, letting the client paginate/re-order those results as needed, lowering traffic on the server and enabling instant table resorts...