5 ms·

I work have built some dense UI for certain types of fixed income (bonds and swaps) trading, looking to move it all to svelte because react cannot handle the qu

by mhh__ 2y ago

I work have built some dense UI for certain types of fixed income (bonds and swaps) trading, looking to move it all to svelte because react cannot handle the quantities of data (and if even if it could the code is unbelievably ugly). Something I've been banging on about for a while is the following: Programmers and designers keep trying to rebuild instagram in every domain, pretty UIs, regular UIs, "simple" UIs. This is great when every interaction might be an onboarding, but can be really limiting and stupid in an environment where people are actually paying attention. A proxy I like to use for the above distinction is whether the users are paid more than the programmers

ChrisMarshallNY 2y ago
I suspect Bloomberg terminals fit that bill.
- mhh__ 2y ago
  avg salary of a bloomberg user is lower than some people might think because there are a lot of support staff who have bloomberg. As for the UI: I wish more things were like bloomberg, but bloomberg itself can be slightly hobbled by wanting to lay everything out as a table all the time when a custom chart designed by a creative domain-expert would be almost as useful.
  - defrost 2y ago
    There's two clear points to be made: * Why change to something that's "almost as useful" .. that's a downgrade. * Pretty is often the enemy of Consistent. On that second point, it doesn't have to be .. but it can take a great deal more effort to have data presentation that's both creative and consistent and dense. The domain goals here are rapid navigation of dense infomation across tens of thousands of companies, timespans, portfolios, groupings, comparisons, etc. With a good interface the user quickly finds the desired scope and view and automatically eye tracks to the wanted figures. It's not an interface for pretty board room presentations (although in an organisation that promotes based on merit in the ditches most senior staff would be familiar with a Bloomberg Board) - it's a daily driver for engine room. I'm not defending this specific interface, just highlighting what is common to many similar domain tools.
    - mhh__ 2y ago
      > Why change to something that's "almost as useful" .. that's a downgrade. To clarify: There would be two modes, for example, when looking at the prices of options you might want to see the shape of the smile (e.g. equivalent to the markets view of a certain probability distribution), but when trading a specific option you want to know everything about it down to exact prices. it's not about pretty-ness, indeed some of these charts can be completely incomprehensible, but rather density. Our UIs should be more than just Excel-but-not-in-Excel!
  - throwaway2037 2y ago
    > there are a lot of support staff who have bloomberg. Much less than people think. It costs about 25K USD per year per terminal. There might be one shared terminal in a whole middle or back office.
- solardev 2y ago
  I'd never heard of those until your post, and had to look up a Youtube about what they were: https://www.youtube.com/watch?v=2ee-x6IXWK8 https://www.youtube.com/watch?v=2ee-x6IXWK8 That's super fascinating. There's an entire industry that runs off these things, on their totally custom UI, showing everything from stock tickers to news headlines to maps? That must be a fun project to work on (except probably the finance users don't like random UI changes, lol).
  - pokepim 2y ago
    lol this is probably most famous financial tool on the market. No wonder we have so many new software tools being created daily since some people don’t do basic market research.
    - solardev 2y ago
      I work in UI, but never in finance. I don't even own a stock (is that even the right word?) and have never invested. Anyway, I wish I got to encounter this system earlier in my career... would've loved to experiment with a UI like that! News ticker under a real time map that you can use to drill down to specific regions to see what's going on? It's fascinating. And it looks like their map is using some sort of serverside raster tiling where even simple arrows have to be redrawn on different zoom levels... just random things I'd be eager to try to improve.
      - tionate 2y ago
        A bit off topic but it may be worth looking into investing a little (maybe basic index ETFs as suggested by the FIRE movement). You can fairly quickly get to a point where your investments go up (or down, but more often up) more in a day than your monthly income.
        solardev 2y ago
        Yeah, at 40, it's probably (way past) time I start looking into things like that, lol. But first I have some massive debts to pay off first :(
andrewstuart 2y ago
>> react literally cannot handle the quantities of data Presented at fact but I’m not sure this is universally correct. I don’t see why the application that is linked here couldn’t be done in react.
- moomoo11 2y ago
  Yep not true at all lol. I’ve built extremely complex UIs with react with solid performance. Just need to know react better, I guess.
  - mhh__ 2y ago
    Would you say all that useMemo (et al) was a productive use of your time? One of the things I like about svelte is that it seems to encourage code to be naturally fast rather than deal with a load of abstraction leakage (very productive abstraction leakage, but still) everywhere Dan Abramov's favourite UI is apparently spotify, I think it shows in the things react seems to be designed for. I dropped the word "literally" from my original comment as I didn't think before I wrote (classic), now I think it's a fair comment.
    - moomoo11 2y ago
      I was using mobx at the time. It was a very complex app UI with lots of data and streams. This was like 4+ years ago. I mean I don’t personally care about the semantics that much as much as the business results. The commenter said react isn’t a good choice and that was my disagreement. And Spotify isn’t exactly a “tough” UI compared to something data intensive.
      - mhh__ 2y ago
        The main reason why I want to stop using react is actually precisely that I feel massively distracted from delivering business value when using it (although still better off than without it entirely obviously). JSX is quite fantastic for some things but I have found it to be fairly annoying when it comes to laying out data that has a very clear pattern to it (personally not a huge fan of functional style here) As for spotify, that was also the point I was trying to make i.e. React was made so facebook can ~~poison the minds of the youth~~ help people share stories, Svelte being made by someone who did dataviz for NYT really shows. Should say at this point that despite my love of Svelte in principal I still would actually probably build an app that used a react-like framework to glue svelte components together as I'm not a huge fan of a lot of the aspects of svelte that have scope wider than a component.
solardev 2y ago
> looking to move it all to svelte because react literally cannot handle the quantities of data I have nothing against Svelte, but how much data are you showing on screen, exactly? Here's an example table with 100,000 cells (100 rows * 1000 columns per row) that seems fine, from a common React UI kit: https://mui.com/x/react-data-grid/virtualization/#column-virtualization https://mui.com/x/react-data-grid/virtualization/#column-vir... It seems fast on my computer normally (M2 Max), slow but usable when the CPU is throttled down 4x, and too slow after that. But that's a lot of cells. Here's a performance comparison, btw: https://krausest.github.io/js-framework-benchmark/2024/table_chrome_127.0.6533.72.html https://krausest.github.io/js-framework-benchmark/2024/table... Or filtered down to just Svelte vs some common React libs: https://share.cleanshot.com/LlFXtNx9p6y4kMvqXgc7 https://share.cleanshot.com/LlFXtNx9p6y4kMvqXgc7 (lower numbers are faster; React is generally just a little slower than Svelte, except when it's swapping 2 rows in a big table... then it's 8x slower)
- mhh__ 2y ago
  Amongst other things, the primary expense is lot of visual elements in a very dense chart that ideally would be ticking with the market in ~real time and allow more than one on the screen. A lot of it probably should be a canvas but there's a good amount of interactivity on the chart itself so moving it all over might be expensive. You obviously can bludgeon that into react but it's at the point where the diffing does seem to be non-trivially expensive and requires a bunch of nursing in the code which is frankly an insane waste of time in 2024. React is completely fine for big tables, especially if they don't actually change very much. I will also note that in turn this started out as a d3 project, react was much much faster than d3. Edit: Completely forgot to mention memory consumption. We have beefy machines so it's not really a critical problem but think of the poor caches!
  - solardev 2y ago
    (Not that you're asking for advice, but hope you don't mind me sharing some anecdotal experience...) When we had to do similar things, we found that it was much much much faster to take all that sort of stuff out of the DOM and put it into Canvas. You can still wrap React around it for the UI and controls and data passing and all that, but the actual rendering need not involve the VDOM or even the real DOM at all. With ChartJS we were able to get it to show tens of thousands of individual data points in a time-series scatterplot, each datapoint interactive and real-time, with no noticeable lag. And it was super easy to integrate into our React app. https://www.chartjs.org/ https://www.chartjs.org/ If it's not just charts, here's another canvas-based drawing lib: https://konvajs.org/docs/sandbox/20000_Nodes.html https://konvajs.org/docs/sandbox/20000_Nodes.html (and its React tie-in: https://konvajs.org/docs/react/Intro.html https://konvajs.org/docs/react/Intro.html) Not trying to discourage you from exploring Svelte if you want to, but it might be less work to just use an existing optimized drawing lib. Regardless of the JS framework used, the DOM is going to be much slower than a Canvas.
doctorpangloss 2y ago
> Programmers and designers keep trying to rebuild instagram in every domain, pretty UIs, regular UIs, "simple" UIs. Well, Instagram is basically the only application people use, along with e-mail, YouTube and TikTok. Some people use Spotify, and fortunately no one is trying to copy its design, so I feel like the programmers and designers are onto something.
- funcDropShadow 2y ago
  > Well, Instagram is basically the only application people use, along with e-mail, YouTube and TikTok No, those people are not using email, they are using what Google tells them what email is. A poor imitation of email.
- The_Colonel 2y ago
  * basically the only people from your bubble use
steve_taylor 2y ago
I love Svelte and agree with you about performance, but its built-in CSS management has some showstopper bugs that are more likely to become apparent the bigger your app gets. If you use :global to target elements in child components (which is inevitable), you’ll run into specificity issues caused by Svelte not removing CSS after components stop rendering. Apparently it’s “by design”, i.e. it’s too hard for the Svelte maintainers to figure out and/or cleaning up would hurt them in benchmarks. I guess it’s OK if you use something else for CSS such as Tailwind.
candu 2y ago
It's always worth thinking about who the audience / userbase of your UI is, and whether they'd benefit from an expert user interface [1] or not. Sometimes, they would (e.g. the "users paid more than the programmers" rule of thumb, but also: various technical disciplines, most anything used for professional-grade work). Sometimes, they wouldn't - or perhaps some would and some wouldn't (so perhaps you're looking for a simple base UI with some accelerators [2]). IMHO the issue is that many products fall into this last camp - where a well-designed simple UI is called for, but also accelerators could greatly help a small but important subset of power users - but we treat the power users as though they don't exist. [1] https://www.nngroup.com/articles/testing-expert-users/ https://www.nngroup.com/articles/testing-expert-users/ [2] https://www.nngroup.com/articles/ui-accelerators/ https://www.nngroup.com/articles/ui-accelerators/
art0rz 2y ago
At $dayjob I work on a very dense UI for a financial institution. Think Bloomberg terminal in React and RTK. It's extremely customizable and had lots of elements updating multiple times per second (charts, graphs, enormous tables, etc.) with realtime data coming through over a websocket. We do very little actual performance tuning and mostly just follow best practices. I don't think React is to blame for your performance issues.
- korm 2y ago
  If seeing how common `eslint-disable-next-line react-hooks/exhaustive-deps` is any indication, people just don't bother with best practices. Not to mention the majority of people I interview or hire don't know anything about CSS performance, they learn on the job. They'll happily add 1000 box shadows in a view if it's in the design. Also OP is looking to move an existing React UI to Svelte, why not try Preact first instead of an entire rewrite? Or even Inferno or million.dev? If they did and they're insufficient, I don't even believe the browser's DOM is the right technology for that UI then.
dhruvrajvanshi 2y ago
Instead of a rewrite, why not try using AgGrid? It's a pure JS grid library that's really fast and it's got react bindings. It's even got a batch update API. I doubt that naively rewriting the app in Svelte is gonna give you the perf boost you're looking for.
devjab 2y ago
I’m not going to discourage your move to svelte, but we do solar data from over a thousand plants and over a million inverter datapoints supplying literal fuckton of data every minute. We combine this with financial data from over 20 countries and budgeting from so many companies we’ve had to buy so many BC365 instances it’s ridiculous that we even use BC365. We present all of it, along with hundreds of tools in a react frontend. It has various backend services, from external to internal in c++, C#, Go, Typescript and Python We don’t have performance issues with react. I’m not sure I’d really recommend react as such, with the way the ecosystem is leaning more and more into Next, but I doubt that its react itself which is giving you performance issues. I think you should look into how you’re loading and unloading data.
mst 2y ago
May also be worth a look at Solid and things the same author has built on his dom-expressions library (I've been thinking about using his mobx-jsx for example) - a more React-ish experience but with a compilation strategy that seems to've been written with a similar aesthetic and set of trade-offs in mind to Svelte. (Svelte is awesome, mind, I compare the two to compliment them both)
deleted 2y ago
[deleted]
andrewstuart 2y ago
Here you go I hacked the page into React so you can see performance. https://static.crowdwave.link/index.html https://static.crowdwave.link/index.html And the source: https://static.crowdwave.link/sveltetest.zip https://static.crowdwave.link/sveltetest.zip

by mhh__ 2y ago

ChrisMarshallNY 2y ago

I suspect Bloomberg terminals fit that bill.

mhh__ 2y ago
avg salary of a bloomberg user is lower than some people might think because there are a lot of support staff who have bloomberg. As for the UI: I wish more things were like bloomberg, but bloomberg itself can be slightly hobbled by wanting to lay everything out as a table all the time when a custom chart designed by a creative domain-expert would be almost as useful.
- defrost 2y ago
  There's two clear points to be made: * Why change to something that's "almost as useful" .. that's a downgrade. * Pretty is often the enemy of Consistent. On that second point, it doesn't have to be .. but it can take a great deal more effort to have data presentation that's both creative and consistent and dense. The domain goals here are rapid navigation of dense infomation across tens of thousands of companies, timespans, portfolios, groupings, comparisons, etc. With a good interface the user quickly finds the desired scope and view and automatically eye tracks to the wanted figures. It's not an interface for pretty board room presentations (although in an organisation that promotes based on merit in the ditches most senior staff would be familiar with a Bloomberg Board) - it's a daily driver for engine room. I'm not defending this specific interface, just highlighting what is common to many similar domain tools.
  - mhh__ 2y ago
    > Why change to something that's "almost as useful" .. that's a downgrade. To clarify: There would be two modes, for example, when looking at the prices of options you might want to see the shape of the smile (e.g. equivalent to the markets view of a certain probability distribution), but when trading a specific option you want to know everything about it down to exact prices. it's not about pretty-ness, indeed some of these charts can be completely incomprehensible, but rather density. Our UIs should be more than just Excel-but-not-in-Excel!
- throwaway2037 2y ago
  > there are a lot of support staff who have bloomberg. Much less than people think. It costs about 25K USD per year per terminal. There might be one shared terminal in a whole middle or back office.
solardev 2y ago
I'd never heard of those until your post, and had to look up a Youtube about what they were: https://www.youtube.com/watch?v=2ee-x6IXWK8 https://www.youtube.com/watch?v=2ee-x6IXWK8 That's super fascinating. There's an entire industry that runs off these things, on their totally custom UI, showing everything from stock tickers to news headlines to maps? That must be a fun project to work on (except probably the finance users don't like random UI changes, lol).
- pokepim 2y ago
  lol this is probably most famous financial tool on the market. No wonder we have so many new software tools being created daily since some people don’t do basic market research.
  - solardev 2y ago
    I work in UI, but never in finance. I don't even own a stock (is that even the right word?) and have never invested. Anyway, I wish I got to encounter this system earlier in my career... would've loved to experiment with a UI like that! News ticker under a real time map that you can use to drill down to specific regions to see what's going on? It's fascinating. And it looks like their map is using some sort of serverside raster tiling where even simple arrows have to be redrawn on different zoom levels... just random things I'd be eager to try to improve.
    - tionate 2y ago
      A bit off topic but it may be worth looking into investing a little (maybe basic index ETFs as suggested by the FIRE movement). You can fairly quickly get to a point where your investments go up (or down, but more often up) more in a day than your monthly income.
      - solardev 2y ago
        Yeah, at 40, it's probably (way past) time I start looking into things like that, lol. But first I have some massive debts to pay off first :(

andrewstuart 2y ago

>> react literally cannot handle the quantities of data Presented at fact but I’m not sure this is universally correct. I don’t see why the application that is linked here couldn’t be done in react.

moomoo11 2y ago
Yep not true at all lol. I’ve built extremely complex UIs with react with solid performance. Just need to know react better, I guess.
- mhh__ 2y ago
  Would you say all that useMemo (et al) was a productive use of your time? One of the things I like about svelte is that it seems to encourage code to be naturally fast rather than deal with a load of abstraction leakage (very productive abstraction leakage, but still) everywhere Dan Abramov's favourite UI is apparently spotify, I think it shows in the things react seems to be designed for. I dropped the word "literally" from my original comment as I didn't think before I wrote (classic), now I think it's a fair comment.
  - moomoo11 2y ago
    I was using mobx at the time. It was a very complex app UI with lots of data and streams. This was like 4+ years ago. I mean I don’t personally care about the semantics that much as much as the business results. The commenter said react isn’t a good choice and that was my disagreement. And Spotify isn’t exactly a “tough” UI compared to something data intensive.
    - mhh__ 2y ago
      The main reason why I want to stop using react is actually precisely that I feel massively distracted from delivering business value when using it (although still better off than without it entirely obviously). JSX is quite fantastic for some things but I have found it to be fairly annoying when it comes to laying out data that has a very clear pattern to it (personally not a huge fan of functional style here) As for spotify, that was also the point I was trying to make i.e. React was made so facebook can ~~poison the minds of the youth~~ help people share stories, Svelte being made by someone who did dataviz for NYT really shows. Should say at this point that despite my love of Svelte in principal I still would actually probably build an app that used a react-like framework to glue svelte components together as I'm not a huge fan of a lot of the aspects of svelte that have scope wider than a component.

solardev 2y ago

> looking to move it all to svelte because react literally cannot handle the quantities of data I have nothing against Svelte, but how much data are you showing on screen, exactly? Here's an example table with 100,000 cells (100 rows * 1000 columns per row) that seems fine, from a common React UI kit: https://mui.com/x/react-data-grid/virtualization/#column-virtualization https://mui.com/x/react-data-grid/virtualization/#column-vir... It seems fast on my computer normally (M2 Max), slow but usable when the CPU is throttled down 4x, and too slow after that. But that's a lot of cells. Here's a performance comparison, btw: https://krausest.github.io/js-framework-benchmark/2024/table_chrome_127.0.6533.72.html https://krausest.github.io/js-framework-benchmark/2024/table... Or filtered down to just Svelte vs some common React libs: https://share.cleanshot.com/LlFXtNx9p6y4kMvqXgc7 https://share.cleanshot.com/LlFXtNx9p6y4kMvqXgc7 (lower numbers are faster; React is generally just a little slower than Svelte, except when it's swapping 2 rows in a big table... then it's 8x slower)

mhh__ 2y ago
Amongst other things, the primary expense is lot of visual elements in a very dense chart that ideally would be ticking with the market in ~real time and allow more than one on the screen. A lot of it probably should be a canvas but there's a good amount of interactivity on the chart itself so moving it all over might be expensive. You obviously can bludgeon that into react but it's at the point where the diffing does seem to be non-trivially expensive and requires a bunch of nursing in the code which is frankly an insane waste of time in 2024. React is completely fine for big tables, especially if they don't actually change very much. I will also note that in turn this started out as a d3 project, react was much much faster than d3. Edit: Completely forgot to mention memory consumption. We have beefy machines so it's not really a critical problem but think of the poor caches!
- solardev 2y ago
  (Not that you're asking for advice, but hope you don't mind me sharing some anecdotal experience...) When we had to do similar things, we found that it was much much much faster to take all that sort of stuff out of the DOM and put it into Canvas. You can still wrap React around it for the UI and controls and data passing and all that, but the actual rendering need not involve the VDOM or even the real DOM at all. With ChartJS we were able to get it to show tens of thousands of individual data points in a time-series scatterplot, each datapoint interactive and real-time, with no noticeable lag. And it was super easy to integrate into our React app. https://www.chartjs.org/ https://www.chartjs.org/ If it's not just charts, here's another canvas-based drawing lib: https://konvajs.org/docs/sandbox/20000_Nodes.html https://konvajs.org/docs/sandbox/20000_Nodes.html (and its React tie-in: https://konvajs.org/docs/react/Intro.html https://konvajs.org/docs/react/Intro.html) Not trying to discourage you from exploring Svelte if you want to, but it might be less work to just use an existing optimized drawing lib. Regardless of the JS framework used, the DOM is going to be much slower than a Canvas.

doctorpangloss 2y ago

> Programmers and designers keep trying to rebuild instagram in every domain, pretty UIs, regular UIs, "simple" UIs. Well, Instagram is basically the only application people use, along with e-mail, YouTube and TikTok. Some people use Spotify, and fortunately no one is trying to copy its design, so I feel like the programmers and designers are onto something.

funcDropShadow 2y ago
> Well, Instagram is basically the only application people use, along with e-mail, YouTube and TikTok No, those people are not using email, they are using what Google tells them what email is. A poor imitation of email.
The_Colonel 2y ago
* basically the only people from your bubble use

steve_taylor 2y ago

I love Svelte and agree with you about performance, but its built-in CSS management has some showstopper bugs that are more likely to become apparent the bigger your app gets. If you use :global to target elements in child components (which is inevitable), you’ll run into specificity issues caused by Svelte not removing CSS after components stop rendering. Apparently it’s “by design”, i.e. it’s too hard for the Svelte maintainers to figure out and/or cleaning up would hurt them in benchmarks. I guess it’s OK if you use something else for CSS such as Tailwind.

candu 2y ago

It's always worth thinking about who the audience / userbase of your UI is, and whether they'd benefit from an expert user interface [1] or not. Sometimes, they would (e.g. the "users paid more than the programmers" rule of thumb, but also: various technical disciplines, most anything used for professional-grade work). Sometimes, they wouldn't - or perhaps some would and some wouldn't (so perhaps you're looking for a simple base UI with some accelerators [2]). IMHO the issue is that many products fall into this last camp - where a well-designed simple UI is called for, but also accelerators could greatly help a small but important subset of power users - but we treat the power users as though they don't exist. [1] https://www.nngroup.com/articles/testing-expert-users/ https://www.nngroup.com/articles/testing-expert-users/ [2] https://www.nngroup.com/articles/ui-accelerators/ https://www.nngroup.com/articles/ui-accelerators/

art0rz 2y ago

At $dayjob I work on a very dense UI for a financial institution. Think Bloomberg terminal in React and RTK. It's extremely customizable and had lots of elements updating multiple times per second (charts, graphs, enormous tables, etc.) with realtime data coming through over a websocket. We do very little actual performance tuning and mostly just follow best practices. I don't think React is to blame for your performance issues.

korm 2y ago
If seeing how common `eslint-disable-next-line react-hooks/exhaustive-deps` is any indication, people just don't bother with best practices. Not to mention the majority of people I interview or hire don't know anything about CSS performance, they learn on the job. They'll happily add 1000 box shadows in a view if it's in the design. Also OP is looking to move an existing React UI to Svelte, why not try Preact first instead of an entire rewrite? Or even Inferno or million.dev? If they did and they're insufficient, I don't even believe the browser's DOM is the right technology for that UI then.

dhruvrajvanshi 2y ago

Instead of a rewrite, why not try using AgGrid? It's a pure JS grid library that's really fast and it's got react bindings. It's even got a batch update API. I doubt that naively rewriting the app in Svelte is gonna give you the perf boost you're looking for.

devjab 2y ago

I’m not going to discourage your move to svelte, but we do solar data from over a thousand plants and over a million inverter datapoints supplying literal fuckton of data every minute. We combine this with financial data from over 20 countries and budgeting from so many companies we’ve had to buy so many BC365 instances it’s ridiculous that we even use BC365. We present all of it, along with hundreds of tools in a react frontend. It has various backend services, from external to internal in c++, C#, Go, Typescript and Python We don’t have performance issues with react. I’m not sure I’d really recommend react as such, with the way the ecosystem is leaning more and more into Next, but I doubt that its react itself which is giving you performance issues. I think you should look into how you’re loading and unloading data.

mst 2y ago

May also be worth a look at Solid and things the same author has built on his dom-expressions library (I've been thinking about using his mobx-jsx for example) - a more React-ish experience but with a compilation strategy that seems to've been written with a similar aesthetic and set of trade-offs in mind to Svelte. (Svelte is awesome, mind, I compare the two to compliment them both)

deleted 2y ago

[deleted]

andrewstuart 2y ago

Here you go I hacked the page into React so you can see performance. https://static.crowdwave.link/index.html https://static.crowdwave.link/index.html And the source: https://static.crowdwave.link/sveltetest.zip https://static.crowdwave.link/sveltetest.zip