Ask HN: UI Design for Financial Trading | Hacker News Reader

Ask HN: UI Design for Financial Trading

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/

View on HN

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.

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).

Interesting - I have looked into the API, though TT tech support believe they can fix the issues I'm seeing. Any reason for choosing F#/WPF over C#/Winforms?

And agree 100% on Xtrader - very strange business decision to discontinue a 15 year old piece of software than thousands of users are willing to pay $1200 per month for!

re WPF vs winforms: consensus recommendation would be WPF. But for something you're building for yourself, WPF has a lot of complexity that you may not get much benefit from. If you decide on WPF, don't use xaml! Separating dynamic UI into a static markup language is a complexity disaster that will cost you a lot of time. (Note that google results are dominated by xaml answers, so if you want code-only answers it's best to search github.)

Best approach may be a third option, at least as a prototype. Use Excel, with a RTD server that connects to TT. Uninstall the Bloomberg Excel Tools add-in and use direct calls into BBG's own RTD server, i.e., =RTD("BLOOMBERG.RTD","","VGA INDEX", "LAST_PRICE") instead of BDP(...) for market data (~100x faster), and you can get to an 80% solution very quickly.

re F# vs C#, I had used C# for a decade before switching (after I had a vacation ruined because of a multi-threading bug in our position-sizing model. Multi-core parallelism is much easier in F# due to default immutability). If you play around with the F# REPL you'll pretty quickly find out whether the language fits your mind well or not. For me, as soon as I read this code (http://fssnip.net/5I), I knew I had found my native language.

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

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.

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.

res

Reply on news.ycombinator.com