Ask HN: UI Design for Financial Trading

#1

Post by strongvigilance » Tue, Sep 10, 2019, 8:12 AM UTC

I work as a financial futures trader, and the main software I use for order management and viewing market data is being discontinued in favour of a new version.

The old software* has been around since the early 2000s, and is a Windows application written in c++. The newer one has a C++/Linux backend, but the UI is basde on Javascript/HTML5/Chromium.

Having tried the new software, the UI performance is appalling - it feels slugggish, much like playing a video game on an underpowered PC, so seeing a generally too low framerate, which at key points drops even lower. Is this likely to be due the technologies used? I don't know much about UI coding, but would've assumed that a C++ application would perform better than one based on Javascript and Chromium.

  * https://www.tradingtechnologies.com/trading/xtrader-platform/

  ** https://www.tradingtechnologies.com/trading/tt-platform/

Re: Ask HN: UI Design for Financial Trading

#2

Post by thedevindevops » Tue, Sep 10, 2019, 9:04 AM UTC

I'd have thought Pytho with its lauded graphing libraries (more often used in science fields) would lend itself to this sort of thing well?

Re: Ask HN: UI Design for Financial Trading

#3

Post by strongvigilance » Tue, Sep 10, 2019, 9:25 AM UTC

thedevindevops wrote: post #2

I'd have thought Pytho with its lauded graphing libraries (more often used in science fields) would lend itself to this sort of thing well?

Not really sure, as it's not my field, but the graphics requirements are not about "drawing" - more about rapidly updating multiple grids of numbers without any lag.

Re: Ask HN: UI Design for Financial Trading

#4

Post by dr3amerOk » Tue, Sep 10, 2019, 9:28 AM UTC

res

Re: Ask HN: UI Design for Financial Trading

#5

Post by kasey_junk » Tue, Sep 10, 2019, 1:21 PM UTC

It’s possible but unlikely. The most likely reason is just bad code.

I’ve seen trading web ui that were as fast as native TT going back lots of years.

The most likely reason is that the ui designers do not understand the problem domain & therefore underemphasized refresh latency for something else.

Re: Ask HN: UI Design for Financial Trading

#6

Post by strongvigilance » Tue, Sep 10, 2019, 3:16 PM UTC

kasey_junk wrote: post #5

It’s possible but unlikely. The most likely reason is just bad code. I’ve seen trading web ui that were as fast as native TT going back lots of years. The most likely reason is that the ui designers do not understand the problem domain & therefore underemphasized refresh latency for something else.

Interesting - so do you think it would be possible to have a JS/HTML5 app refresh at 60FPS?

Re: Ask HN: UI Design for Financial Trading

#7

Post by uptown » Tue, Sep 10, 2019, 3:57 PM UTC

For updating grids, you can achieve very fast performance using batched transactions:

https://medium.com/ag-grid/how-to-test-for-the-best-html5-gr...

If that's not fast enough, there are canvas based grid which can improve the refresh rates faster. Hypergrid is a canvas based grid, though it's not the easiest to work with:

https://github.com/fin-hypergrid/core

JPMorgan has release Perspective, which demonstrates streaming updates using WebAssembly:

https://perspective.finos.org/

Really comes down to your specific situation what approach is best.

Re: Ask HN: UI Design for Financial Trading

#8

Post by kasey_junk » Tue, Sep 10, 2019, 4:39 PM UTC

strongvigilance wrote: post #6

kasey_junk wrote: post #5

It’s possible but unlikely. The most likely reason is just bad code. I’ve seen trading web ui that were as fast as native TT going back lots of years. The most likely reason is that the ui designers do not understand the problem domain & therefore underemphasized refresh latency for something else.

Interesting - so do you think it would be possible to have a JS/HTML5 app refresh at 60FPS?

Not an expert on what is possible in that space these days but FPS is actually not that important in trading guis because you don’t need the whole canvas to refresh like you do in something like a shooter.

You don’t have to redraw a lot of things on each event because ladders and the like are mostly static while graphs are only dynamic in the tails.

Without observing your specific use case it is impossible to know what is causing your perception of lag, but I’d be shocked if it was bare refresh rate.

I’d guess their crappy code is just pissing off and not doing anything for big stretches of time because it isn’t good.

Re: Ask HN: UI Design for Financial Trading

#9

Post by srijanshetty » Wed, Sep 11, 2019, 3:47 PM UTC

I've personally written grids that update in real-time and handle millions of updates over the course of a day. The stack was based on React as the frontend, websockets as the delivery mechanism and Java on the backend and it scaled fine.

So, IMHO, it's mostly a bad architecture or a sub-optimal design

Re: Ask HN: UI Design for Financial Trading

#10

Post by clausok » Thu, Sep 12, 2019, 7:17 AM UTC

As someone who used xtrader a lot in the past, I'm a little sad to see it get claimed by the web-based movement. That was some really fine software.

To get a sense of the tradeoffs taking place that leave you with a noticeably slower UI, see here: https://www.forbes.com/sites/tomgroenfeldt/2019/02/12/openfi...

PSA: It may be a good idea to hire a programmer and customize your software. TT has a nice API. If you have idiosyncratic workflows or views, or if you just want a few particular things to be faster, it's not too hard to use this API to make the tradeoffs and optimizations that work best for your own supplemental UI screens. We did this with a F# + WPF UI where the fill feed and responsiveness was just as snappy as TT's own UI (the old, c++ one).