I strongly feel as if the developer community at large need to take another hard look at server-side rendering of business UIs and the benefits this approach can bring.

Consider what you could do if you had a cloud-only multiplayer game engine with all players just receiving a low-latency video stream of their interface and local events being piped back up the same connection, but with some business application built on top. The ability to say that you no longer have a client-server contract and it's all just one big server implementation drops a massive number of design constraints and immediately makes the security and client interface to the system a trivial affair.

Obviously, the downsides with the above are the latency, bandwidth, and additional load seen at the server in order to render client views. But, these are really the only downsides, and none of them are extraordinarily complex in terms of technical resolution. Latency is probably the only hard constraint that cannot be resolved by simply increasing an existing resource. The other 2 can be resolved with More Money™. Everything else is upside from here.

Sounds like like Stadia.

In reality, however, some Bloomberg users struggle daily with inaccurate data, lack of documentation, manual (slow) help on trivial issues, and poor performance when running analytics. It is more like a bloated GUI app pretending to be a terminal, worst of both worlds.

The terminal is extremely slow most of the time and constantly crashes. I agree it is very secure and the software is designed for power users (mouse almost never needed), but it isn’t exactly a marvel of engineering. It’s basically a giant piece of legacy code.

>The terminal is extremely slow most of the time and constantly crashes

Ok your comment is mindboggling to me. Having used Bloomberg for nearly 10 years, not only for the front-end but the back-end API I can tell you it is the most stable piece of software I've ever seen. Not once, not one single time has it crashed in those 10+ years for us. The API is even more impressive- to my knowledge we never even experience a single missed query or randomly dead data stream over all those years.

The terminal is expensive as hell, but they deliver on the cost.

Also just by the fact of how it's used, saying it constantly crashes and assuming it's just like that and traders are ok with that all day long? Whatever experience you seem to have must be an extreme outlier.

>It’s basically a giant piece of legacy code.

Eh I think that's silly. You even say it's designed for the power users, which is absolutly right. That's the only reason you think it's legacy. Are you telling me everything behind and their back-end is not extremely advanced? It has to be to support the amount of data that is flowing through them at every second in data that HAS to be fast & accurate.

> Having used Bloomberg for nearly 10 years, not only for the front-end but the back-end API

Maybe you know the answer to a question I’ve been asking for years: is there any way to authenticate the data you receive over the API? Bloomberg requires credentials to prove you have a subscription but I’ve long wondered about the security/integrity of the data flowing the other direction. What mechanism stops a bad actor from slightly altering or delaying Bloomberg API data as a way to manipulate the markets?

Once you have a few terminals at your firm, Bloomberg will provide a dedicated router + tunnel on top off the regular security. The bad actor would likely need to be internal to Bloomberg, and at that point there is nothing you can do.

I'm assuming you are speaking about BBDL (Bloomberg Data License). My assumption was the API client used SSL and certificate verification to prevent man-in-the-middle attacks. I'll admit I never verified this. I imagine this is easy to verify -- just do a connect w/ a 2-liner BBDL client script and examine the network.

Adding my data point: as a user of the terminal since 2005 I don't ever remember it crashing. Regarding the API (.Net) the only trouble I've had was when I was using a BlockingCollection to keep my simultaneous requests under the Desktop API limit of 128 and I still received a "too many requests" error -- but I trust Bloomberg's throttling software more than my own so I didn't complain.

Disagree. For power-users, maybe, but the average person cares about simplicity and accessibility. The mean Facebook user doesn't care about latency.

> The mean Facebook user doesn't care about latency.

They do, they just don't know it, yet. If you showed them two versions of Facebook, one which was their normal latent mess, and one which had half the latency, they'll take the less-latent version every single time.

Don't assume that people don't care - they definitely do, they just don't have a choice.

The average person does not use bloomberg. These things cost $20k+ per year per person. You don't randomly hand them out to everyone at your firm.

Plus it's not like they are just handed out and you're on your own. A nice man or woman in a suit will spend many hours sitting beside you teaching you everything you want to know. And anytime you are confused you press the help key twice and you are connected with someone who will take you through step by step what to do. And this isn't outsourced IT support. It's a person in New York who knows the product really well.