57 replies
19h22m
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
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-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...
Or filtered down to just Svelte vs some common React libs: 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)
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!
(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/
If it's not just charts, here's another canvas-based drawing lib: https://konvajs.org/docs/sandbox/20000_Nodes.html (and its React tie-in: 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.
The cunningham's-law-optimal way is to not ask, surely. Either that or the some programmers equivalent of the "death drive".
Indeed, the canvas is basically inevitable, but it's a bespoke chart that has both temporal and non-temporal data in it (not sure what the terminology should be, but imagine plotting market expectations of interest rates in future and what expectations were historically displayed relative to current levels - but repeated ~200 times), so the existing chart libraries aren't particularly helpful and can get in the way of being able to click on stuff.
Anecdotally I find that programmers are very good at writing charts for the kinds of data they understand (time series, time series of their stock options, etc), but even the "generic" (e.g. grammar of graphics) libraries can still struggle with simple combinations of those domains.
Obviously you can just treat the charting library as a black-box for which you derive coordinate transformations and make things appear in the right place but not a great bus-factor for that kind of code.
I use https://github.com/leeoniya/uPlot for sparklines and so on, very fast.
Cool. That sounds like a fun project to work on! If it's not super secret stuff, I hope your company will do a write-up about it afterward.
I could see it happen as a carrot-and-stick for hiring perhaps, let's see.
No, it is not a lot of cells in a table. It is something a Windows95 era PC had no problem doing in something like Delphi Builder. And you find it acceptable that it slows down, if an M2 Max throttles down? Even a throttled down M2 Max is supposed to be 1000x (obviously an exageration, because I am to lazy to apply Moore's Law more rigorously on a Sunday morning) faster than an Intel 486DX. Where did all the compute power go? Are we really using the right tools for our jobs?
I would recommend you actually try this, because it's not as true as you would like to believe.
I am very much pro-"make things fast" but let's not pretend that old machines didn't randomly hiccup on things all the time as well.
Well. If it was bearable then, with 2x powerful pc, it should be much better.
I think all software is a balance of factors, from performance to ease of use to DX to maintainability, cost, etc.
I don't think most tables need to be as peformant as possible, especially when a slow render is still measured in sub-seconds.
That level of performance is totally fine for many use cases. If you have a special need for large datasets, yes, you should pay more attention to how that's optimized.
But for your average bog standard web app, I think any framework will be just fine, performance wise, on any 10 ish year old device. If it's slow, it's more likely because of ads, tracking, large media, poor caching, distance from a CDN, etc. Especially since React these days is typically rendered to HTML during the build anyway and then rehydrated for interactivity later.
React isn't a performance optimization to begin with, but a DX improvement and architecture abstraction lib (vs vanilla or jQuery). It makes some apps much easier to write and maintain across generations of low cost developers. The performance is a small sacrifice, but it's usually not even noticeable.
For performance critical apps, probably you'd just bypass the DOM anyway and draw to canvas instead, and offload all the heavy processing to wasm.
Yeah, compared to the 90s, our computers and modems are much faster and used less efficiently. But there are billions more users and millions more developers of various skill levels now, and that's just a tradeoff we get for mass adoption. It's no longer just a tool for elites, but just another tool in the office, and often times a race to the bottom like anything else in business (in terms of React devs being low cost commodities). A small React team can put together a functional app much quicker and cheaper than with vanilla, at the cost of some usually negligible performance. Probably a good tradeoff for most apps.
If you're talking about web apps in general, compared to desktop or CLI apps, then yeah, I agree that it's a bit of a shame this is what won the desktop platform wars. At least on mobile we have native apps (which often feel much faster than anything web based), so there's that at least.
In general I agree with your sentiment. But here we are in a browser environment so we should compare performance to a raw HTML table. And then complain if the raw HTML is still slower than Delphi on win95 because HTML tables have been around since back then :D
React is also considerably slower than svelte in this benchmark in selecting, clearing, adding and creating rows and also uses a lot more memory.
For a lot of apps React is fast enough but you're definitely starting at a non-negligible performance disadvantage compared to faster frameworks.
I don't know that a 15 millisecond difference in rendering performance is going to matter to anyone =/ The memory usage is in megabytes too. It's not much. For sure React is slower on paper, but in most cases it's a non-issue. Nobody chooses React for its performance benefits anyway, but because of its huge ecosystem of libs and developers. In most cases it's fast enough.
The fact that it's fast enough on your 2000$ machine doesn't really tell us much.
I was using the numbers from the benchmark, which wasn't my machine, and was sometimes throttled down.
I agree that React is fast enough for a lot of things without worrying too much about performance.
I've also worked on several apps where we had to work really really hard to get decent performance out of React and the resulting code was ugly and brittle.
I don't know what GitHub projects uses but we have ~200 tickets in it and it absolutely chugs. Even typing text into new entries will regularly hang for multiple seconds every few words.
It's defective because the browser's find feature does not work.
I suspect Bloomberg terminals fit that bill.
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
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).
The real reason to have bloomberg, other than data, is actually the chat.
OTC (things that don't trade on exchanges) markets are a lot closer to ebay or facebook marketplace than many realise, for example, e.g. you ask for a price, possibly haggle a bit, say you want it, behind-the-scenes people scurry off and actually make it happen.
When you first activate your terminal bloomberg send you an email congratulating you on joining "the exclusive club" (this is exaggerated, they want you to feel special, but there's truth to it).
As well as all that bloomberg is technically also still (iirc) one of the largest private computer networks.
Unfortunately possibly quite the opposite for many, although no first-hand experience.
Wait, so inside Bloomberg there's like a huge IRC/Discord chat room for all the world's finance people? How does anyone keep up with that kind of volume? I can't even stay on top of my own company's Slack.
No it's more like whatsapp i.e. DM and group chats.
I'll lay odds the core language is FORTRAN or COBOL.
Famously huge FORTRAN code base going back to the 80's, although they were wrapping it in C++ and Javascript when I worked there in the aughts.
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.
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.
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.
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 :(
I have bad news for you, nobody who works with a system more than casually, likes random UI changes. NOBODY. Younger people are often more tolerant to these distractions, because they are often more curious. But when you have used a tool for some longer time, and suddenly it looks or behaves different, that erodes trust. That forces the user to turn of the mental autopilot and to proceed with care. Which A/B tests will report as increased engagement of the users. And there is our vicious cycle.
Note, how a scheduled update with release notes does the opposite. It increases trust, because it tells you what is going to happen and then it happens. (Hopefully)
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.
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.
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!
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.
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.
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.
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.
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.
I also like svelte. I’ve not used it for anything serious yet though for one reason: lack of libraries.
What you describe is a valid concern. I like keeping it more “vanilla” with svelte but any time I run into an issue of “Do I spend the next 2 hours building this, or just vet and pull in a library?” I’m left with the former option.
At this point in my life I’m not that interested in spending more time than I have to get something done.
So.. I just use react. No customer cares about 35kb vs 8kb or whatever people seem to optimize for. Even businesses in a developing country have 50-100mbps connection, and honestly most customers (even tech corps) don’t care about this stuff.
You can use any vanilla HTML/css/js libraries with Svelte, and those far outnumber React’s.
React can handle dense interfaces with a lot of elements but you have to be very careful with memoization and it's extremely easy to accidentally introduce significant performance regressions if something in your memoization chain breaks.
The application linked here is only showing 270 cells at once. I think even the slowest framework can handle that...
It's when you get to thousands/tens of thousands of data points that things can really slow down without good optimizations, especially if you're modifying the DOM or manipulating SVGs (as opposed to drawing to Canvas, typically).
But isn't that exactly the point of such UI libraries? To provide those optimizations. Because the easy case, I can do myself.
Yes...? I think maybe there are some threads getting mixed up here? There are some sibling/cousin threads discussing performance more in depth. My post you replied to is just pointing out that 300 cells isn't really enough to measure any sort of meaningful performance.
Removed the word "literally" (riffed too enthusiastically there) because my point was that's its already a bit slow, will only get slower as more things are added, and the code is already ugly despite being basically conventional/boring react.
The data I'm displaying also is quite deep and results in the creation of a lot of DOM elements (i.e. its visual rather than tabular). It noticeably chugs a bit even when the actual changes to be displayed are relatively small.
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.
No, those people are not using email, they are using what Google tells them what email is. A poor imitation of email.
* basically the only people from your bubble use
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.
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.
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.
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)
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.
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.
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/ [2] https://www.nngroup.com/articles/ui-accelerators/
Here you go I hacked the page into React so you can see performance.
https://static.crowdwave.link/index.html
And the source: https://static.crowdwave.link/sveltetest.zip