I might need a reality check here because this is feeling weird.
I'm currently building a web-based application to store JVM threaddumps. This includes a JS-based frontend to efficiently sort and filter sets of JVM threads (for example based on thread names, or classes included in thread traces). Or the ability to visualize locking structures with d3, so you can see that a specific class is a bottle neck because it has many locks and many threads are waiting for it.
I'm doing that in a Ruby/Vue application because those choices make the app easy. You can upload a threaddump via curl, and share it with everyone via links. You can share sorted and filtered thread sets, you can share visualizations with a mostly readable link. This is good because it's easy to - automatically - collect and upload thread ddumps, and it's easy to collaborate with a problematic locking situation.
So, I'd call that a fairly heavy web-based application. I'm relying on JS, because JS makes my user experience better. JS can fetch a threaddump, cache it in the browser, and execute filters based on the cached data pretty much as fast as a native application would. Except you can share and link it easily, so it's better than visualvm or TDA.
But with all that heavywheight, fast moving web bollocks... Isn't it natural to think about web latency? To me it's the only sensible thing to webpack/gulp-concat/whatever my entire app so all that heavy JS is one big GET. It's the only sensible thing to fetch all information about a threaddump in on GET just to cache it and have it available. It's the only right thing to do or else network latency eats you alive.
Am I that estranged by now by having worked on one low-latency, high-throughput application by now? To avoid confusion, the threaddump storage is neither low-latency, nor high-throughput. Talking java with 100k+ events/s and < 1ms in-server latency there.