
Ask HN: UI Design for Financial Trading - strongvigilance
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.<p>The old software* has been around since the early 2000s, and is a Windows application written in c++. The newer one<i></i> has a C++&#x2F;Linux backend, but the UI is basde on Javascript&#x2F;HTML5&#x2F;Chromium.<p>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&#x27;t know much about UI coding, but would&#x27;ve assumed that a C++ application would perform better than one based on Javascript and Chromium.<p><pre><code>  * https:&#x2F;&#x2F;www.tradingtechnologies.com&#x2F;trading&#x2F;xtrader-platform&#x2F;

  ** https:&#x2F;&#x2F;www.tradingtechnologies.com&#x2F;trading&#x2F;tt-platform&#x2F;</code></pre>
======
uptown
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...](https://medium.com/ag-grid/how-to-test-for-the-best-html5-grid-
for-streaming-updates-53545bb9256a)

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](https://github.com/fin-hypergrid/core)

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

[https://perspective.finos.org/](https://perspective.finos.org/)

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

------
clausok
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...](https://www.forbes.com/sites/tomgroenfeldt/2019/02/12/openfin-
builds-an-os-for-traders-on-high-performance-html5/#28bfd2f837be)

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

~~~
strongvigilance
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!

~~~
clausok
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](http://fssnip.net/5I)), I knew I had found my native
language.

------
srijanshetty
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

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

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

~~~
kasey_junk
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.

------
thedevindevops
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?

~~~
strongvigilance
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.

------
dr3amerOk
res

