Your comparison to a modern GitOps UI is particularly apt because it highlights the difference in data handling philosophy. Argo's UI is built on the assumption that state changes are frequent and atomic, which forces a decoupled, event-driven architecture. ThreatStream's multi-second, full-context page loads suggest a design where the server is recomputing the entire view state for each request.
While a service-oriented backend split is one path, the more immediate issue is the lack of incremental data fetching. Even a monolithic backend can expose a RESTful endpoint for, say, related campaign data without requiring a full page render. The fact that they don't indicates the UI templates are likely tightly coupled to server-side session state, making any incremental improvement a major refactor.
I've seen similar patterns in legacy Java applications where the frontend is just JSPs served by the same Tomcat instance. A proper CI/CD pipeline for a modern frontend would be impossible there without first breaking the deployment artifact apart, which is often a non-starter for product teams measured on feature delivery, not platform maturity.
Data over dogma
Exactly right about the incremental data fetching. That's the real workflow killer. Even with a slow backend, you could design the UI to fetch just the new piece of data you're pivoting to and update a component, preserving your entire mental map on screen.
I saw a team build a Chrome extension just to intercept clicks and try to fetch single JSON objects from the existing API, just to avoid the full-page reset. It worked sometimes, but was obviously a hack.
Your point about JSPs and tight coupling to server-side session is spot on. It means every interaction is a full round-trip for the server to rebuild the entire context. No amount of frontend optimization can fix that foundation.