I have a table, each row can spawn a model with additional information. Is there a best practice for displaying tons of information like this?

I've considered the following options:

  1. Save all information as JSON and leave in html element for JS to populate the modal with when clicked.
  2. Render a separate modal for each table row and tie them with ids
  3. Use AJAX to fetch the necessary data to populate the modal when clicked.

The issues I foresee with each (respectively) are as follows:

  1. This leaves a metric crap ton of data floating around inside html tags. Leaving JSON in a data attribute seems hacky to me.
  2. This becomes computationally expensive when I have 200 table rows and custom svgs and data in each modal.
  3. Probably the best option, but I balk at querying multiple tables in a massive database for each row when I could get everything needed in a single query on page load.

So there you have it. In the grand scheme of things, what is the best way to get, save, and render a ton of data? Where is the threshold (quantity) for this sort of "optimization" to even matter?

1 Answer 1


Which one fulfills the requirements of your project? I know, "they all do because they all show a modal, duh". But there are other constraints, such as how much load you expect, how well your servers / architecture will scale, etc. It's a matter of figuring out which option fits best into those constraints.

If you are worried more about database load, then 1 or 2 are probably the best bet. Note that going that route means you shove a whole lot of data into the page, creating a huge page for the client to download. That could be a horrible user experience.

On the flip side, if you need a better user experience, 3 means you load less up front and only get the information a client wants when they want it. That means more requests to your server and more calls to the database, but a potentially much faster initial response from your server.

Each one is a trade-off, usually server load for processing on the client machine. If you aren't sure what will work, test test test!

Test on different clients that you support. The decision you make will be very different if you are only supporting top of the line desktops with insanely fast internet connections vs. supporting toaster phones with spotty internet connections.

Test with expected loads. If your database is sitting idle most of the time you can probably go with 3. If your database or web servers crumble under the load, you need something else.

As programmers (and humans), we are notoriously bad at guessing where the bottlenecks will be. Experience helps us get better at it, but testing will be much better.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.