React is very sluggish when updating many elements at once, for not very large values of "many". With some regularity, I've debugged React+MobX jank issues where a bigger update, such as switching from one panel to another, takes upwards of 200ms on a mid- or low-range machine.
None of this is perceptible on our beefy dev boxes, which is why I think people disregard it, and why the modern webapp experience is so miserable for the average person.
1. Performance is very very rarely a contributor to a product success. Users prefer more features over more performant app all the time (both directly when asked and indirectly by what products they choose).
2. Rendering/client computation speed is rarely a contributor to real and perceived performance. It's almost always the async calls - how many you have, and how long they take. It's almost always a waste of effort to try and make your framework render at half the time when 99% of your lag is a database call.
3. Framework performance is rarely a contributor to the speed of your rendering. It's most often a problem with how you structured your app. You can structure your app poorly in any framework. (I would hazard a guess that in your panel switch example a differently structured React+MobX solution would not have the problem you described)
4. There are only very few scenarios where the rendering speed between frameworks makes a perceptible difference (usually when talking about large tables or similar scenarios), in all other cases it's a difference of a few milliseconds.
2. True, it depends on the type of app. For anything that is a type of "editor" - website builder, word processor-like thing, kanban board - you operate on a data model that you save in the background. Async calls are fairly unimportant for the overall feel there.
3. To me it's hard to untangle. The reigning paradigm is declarative UI, for great reason. It's so much saner than any manual updates. But this encourages a design where you don't think about what DOM updates will really happen after an action, and this is where the problem lies. A big part of it is also the DOM model and layout. In the extreme, you have a declarative UI library like ImGui which doesn't have any VDOM, it just rerenders every frame, and it's insane how quick it does it. I haven't been able to bring it to its knees, it just maintains 60FPS constantly, with a lot of frame time to spare.
4. It's not hard for me to believe this. I didn't say other frameworks are better. Could be that the whole DOM diff approach is the culprit, or the slowness of DOM updates and relayouts.
Most of my successful work has been specifically outperforming the competition in a way that makes users choose our product. Performance is an orthogonal feature that improves all other features, and even changes what your clients can do with your system, as in making new workflows viable.
> A 2017 Akamai study shows that every 100-millisecond delay in website load time can hurt conversion rates by 7%
> 10 years ago, Amazon found that every 100ms of latency cost them 1% in sales
Also misleading to imply a linear relationship. There will be a marginal cost, but no reason to assume constant.
You're not amazon
That said, having a performant website is nice, both for developer experience and for users.
I have to say I pick solid because it's so damn fast (okok, and because it has an API which is React-like but without the crap doesn't make sense or an extra custom runtime just because)
I close sites all the time when they fail to work quickly. I have aborted orders on sites midway through when the interaction became sluggish enough that I wasn't confident in the value of the product anymore.
This statement reminds me of those Gordon Ramsay shows where a restaurant owner says "the customers like my food!" when it's obviously subpar. The fact is that the customers that didn't like the food politely go away and don't come back.
Your other points get more directly at framework performance versus other performance concerns. I have fewer opinions about those.
Products almost never compete on performance, and the biggest, most popular ones are almost always the slower ones.
Regardless of your anecdotal evidence, there is a reason why this sentiment is prevalent in the industry - because PMs and devs who thought otherwise were quickly outcompeted by those that moved faster and released more features.
Both Google and Amazon have researched this topic and the results are readily available. First link I found: https://www.thinkwithgoogle.com/marketing-strategies/app-and...
Why do you think there some much time and effort going into improving performance of computing in general. Facebook Lite, android go, GPU's, cpu improvements, 5g, etc.
The important caveat is that once it's fast enough the gains are marginal.
But if you are still at the stage in product development where adding features will increase your addressable market by tens or hundreds of percents (which doing things like ‘supporting multiple European languages’ or ‘adding google login’ can do) then those performance gains are not where engineering investment needs to go.
I use Vim and I use VSCode. There is little debate about which has better performance and which has more features. It's also easy to see which has more users.
Based off how slow every SaaS service is in the B2B space, performance isn't important in all scenarios.
Site performance is much more API based, and that’s the same regardless of frontend. React has more library solutions to optimize the UX though, as it’s the most mature and popular.
Exactly. And those API calls are going out over the network. The caller has to serialize the request into text, the API implementation has to deserialize the text into values that can be passed to a local implementation function and then the API implementation has to take the result and serialize it into the return. Finally the caller has to process the result.
That's the simple case. Things get even more involved when you start using HTTPS to secure the data in transit on the channel and using OAuth to secure the access to the API. What appears to be a simple API call turns into a lot of back-and-forths with multiple servers - with all the network latency that entails. Then developers complain their website is slow. Gee, I wonder why!
And this isn’t just about 100 ms here or there. The frequency with which clicking a button takes seconds to have any observable effect is quite high. Coupled with modern UI trends where interactive elements aren’t clearly distinguished, sometimes users can’t tell a laggy button from a not-a-button.
I suspect a massive UX study bias here. Are people looking at telemetry to try to see whether users who completed some flow are happy? Those users (a) completed the flow, so they didn’t give up and (b) are likely enriched in those users who would use your site no matter what. The marginal users of poorly-functioning websites aren’t in the data set!
You might as well say, having users is very very rarely a contributor to a product success. We're over two+ decades into the 21st Century and we're still pushing a 20th Century mindset?
Why Lord? Why?
These two things are not even remotely the same thing.
Having users is a path to monetisation but having a high performant app no one uses is not.
In fact, if you have users despite performance, it suggests you have a home run product that can be optimised for performance.
Again, you can’t optimise your way to user growth.
These two things are also not the same. You start with "having users" and assume they're willing to pay and will stick around. You compare that to "having a high performance app no one uses" - explicitly limiting the scenario with an unrelated caveat that no one uses it.
A better comparison would look only at having users vs. a high performance app, which has too little information, or having users that aren't willing to pay vs. a high performance app that no one uses, which leave you in the same boat.
I said explicitly “path to monetisation” not “assume they’ll pay and stick around”.
I hope you’ll agree that it’s easier to find a subset of users that will pay when your superset of all users is large vs a super(?)set of zero.
Do users explicitly care about how many milliseconds somethings takes? No definitely not
Do they care if the application feels slow ? Yes absolutely
Do faster experiences subconsciously feel better ? Yes
Does that subconscious feeling, impact metrics like sales or conversion ? Yes it does
So people do explicitly justify usage decisions with performance, all the time. Agreed that overall features win out but it's often the case that multiple products end up with broadly comparable sets of features and struggle to gain a persistent advantage there. Once you reach that point, perf can be a competitive advantage.
Yet this is what all the JS people were saying in 2014 - 2015 when everything started to become SPA. They argued this is what the users want. That's been used to justify all this stuff for a very long time if you're on Twitter. When it gets traction within Twitter it leaks into orgs. It's the same argument that's used now for all the SSG,SSR,hydration,edge and whatever other buzzword.
The internet is miserable because of all these React sites. I know first hand because my wife has a Chromebook. Yet developers won't listen because they think 6x cpu slow down is good enough to test with on their $4000 Mac book pro.
If users really don't care that much about performance then why aren't we just rendering html and sending new html on every interaction. That's much easier to do, performs pretty well from a CPU/Memory standpoint.
We've taken on a lot of complexity over the years in defense of the users. The argument I go back to is what is "good enough" and the developers/product/design I've worked with don't know what this word means.
I
Server rendering can carry less of a payload to the FE but you aren't sending unnecessary data.
This is absolutely true!
I would say that some frameworks make it easier to make mistakes. For example, Angular can be highly performant...but the automatic change detection kills performance. But wait, you can fix that! Just make your components use OnPush Change detection! ...which is not...the default? Why? In any Corporate app that displays complex UIs you absolutely need to be using it everywhere. but yet.
Personally, I think it is to make it easier for beginners who don't understand why their observables are not showing content on the page but it is still annoying to set it in every component or hunt it down. This is a small part of why we turned to using nx and generators with configurations that add it by default.
https://infrequently.org/2023/02/the-market-for-lemons/#shri...
We have a React+Redux search page where clicking checkboxes takes about that long to update the checkbox, on our good developer machines.
I won't rule out we did something wrong (this page was pretty early in our React understanding), but we've also not managed to fix it due to how much is on that page.
It was all redux’s magic and simplicity was making almost the entire thing rerender on every keystroke. Of course it was the developers fault, but it’s so easy to end in that situation that I blame the tools because to me when you shoot yourself in the foot that many times you start to ask yourself if what you have is a footgun.
I see this claim a lot and I'm curious what this is based on, can somebody drop some links to further reading?
I'm averaging a 15-30 second TTI on the most js-heavy sites.
N.B. No one is using the app from their mobiles. iPad and computers only.
Our reasons for choosing React when there are so many alternatives: prior knowledge, ergonomics, easy onboarding, ecosystem.
Actually, why aren’t web-components a thing, that’s another story. But componentization is why React creates clean code.
The reasoning I get all the time is "Why would you want to do that? That's stupid".
It's just so much nicer honestly. I'm not a react fan at all but that's one thing I miss about it.
Honestly, if anything I find react's modularity story much weaker than the competition. In react there's no page-wide state and the story around styling components with CSS is a huge mess.
In comparison, Svelte components feel much more modular & self contained because the styles are embedded with the component in a standard way.
90% of the users use shitty hardware. Everything is sorta sluggish on their computers - they boot up slowly, the bunch of crapware in autorun take their sweet time to load & phone home, their wifi us overburdened with devices. Most of the software experience is sluggish for them. They don't care if their web app is sluggish too.
Anecdotally, those 90% of users are not happy about their experience, they just tolerate it.
If you are forced to use an app with bad performance (say Teams) you cope. Humans are great at coping. Maybe you turn it off and back on again periodically, or alt tab to something else while it's showing a spinner.
It's true performance isn't a major selling point but IMO that's because most software products are not sold to users. They are packaged with other products, part of monopolies and imposed to users by others.
I buy video games where performance undoubtedly matters. Apart from that, most software I use, I didn't choose, and I'm pleasantly happy when it's not garbage (Outlook, IDEA) and annoyed when it is (Teams, Facebook). In either case, performance wasn't a contributor to my choice: I didn't have a choice.
All the sluggish steps led them to the usage of the web app they need to use, and they need it to be fast. At least, faster than rest of the crap so far. Heck, they may spend rest of the day with this app..
$250 in an Android phone can get you a SD 695 5g these days. IT's not fast per say but it absolutely doesn't suck.
Most users have no idea how to remove any of it. Or, worse, they'll enable all of the preinstalled antivirus programs because they want their computer to be safe. And it gets worse. I visited my parents once and noticed something weird on my dad's macbook air. Turned out he'd gone out and bought Norton antivirus to install on it (!?). Norton installed a chrome extension which replaced the banner ads on every website he visited with their own ads. I manually deleted the extension from chrome, but norton put it right back again after chrome restarted.
If you don't believe me, use performance counters and measure it. Your website runs way slower on your users' computer than you think it does.
But the point I was making was that the average computer has actually gotten pretty good. Most users use near-latest chrome, most laptops have gotten much quicker.
And that’s before noting that the average cell phone in the US has BETTER js performance than the average computer. Most US mobile users have a modern iPhone that is faster in single core performance than some 10th gen laptops.
We still get <100ms page delivery with server side rendering and lightweight JavaScript DOM overlays. Our React infested competitors, not so much to the point their clients have been shitposting on twitter about it.
And we actually can debug our product!
React is like nearly any other tool, use it well, and it's great. Well optimized React is lightweight to the client and a joy to test and debug. That said, Web Components are even better, but I'm guessing that's science fiction to you.
Most React applications do not end up like that in the real world. They turn into poorly architected over complicated nightmares, particularly on sprawling apps which is the reality in the corporate space. Not everyone is building hyper-focused single function tools which can be crammed in an SPA type framework. And the users suffer for this.
One of the finest turds I've seen recently is my electricity company's meter reading facility which is an over-engineered react interface for a single web form with two fields and a confirmation box. The whole thing pulls 590k down to do that and takes 5 seconds for the initial page load on an M1 MacBook Pro. That's the real end game for most people. The only reason it's like that is because the people who built it don't know how to do it any other way.
And lets be honest about Microsoft: they do everything from a front end or user interface perspective and randomly discontinue bad ideas about 5 years down the line. Like Silverlight, most of WPF, bits of ATL and MFC, an entire mobile phone platform that got rewritten. And their competing framework WinUI 3 doesn't even work properly. Their own O365 web platform is a fine example of where this turns into a buggy mess. I bet react is dead to them within 2 years on one of their schizophrenic switcharoos. The only reason they're into it now is to capture some market from Electron.
1) MSFT has already used React for far longer than 2 years.
2) They have basically never used the technologies you mentioned (WPF, Silverlight, WinUI). They offer them as UI toolkits that run in their Windows environment and that’s it. Their failure to market and support these technologies is independent of what they do for their own development strategy.
3) They bought GitHub and effectively own electron now. Many of their biggest apps are on electron (Teams, VS Code, Azure Data Studio).
2. Yes they have. Half their developer tools were rewritten in WPF, they offered huge stacks including CRM on top of Silverlight and a huge chunk of windows 11 front end is WinUI.
3. Teams fucking sucks. VS Code is heading in the same direction. I've never used Azure Data Studio.
Huh? Those are Microsoft's biggest apps? Not, MS Word, the NT Kernel or ... windows 11? The XBox operating system project? Outlook express? Visual Studio? ... Github?
I'll grant that Electron is used by a few teams at microsoft. But I'd be surprised if even 1% of microsoft's engineers worked on products built with electron.
I don't love Microsoft, but it's for the best they adopt a well known and rounded framework like React, rather than try to invent yet another of their own frameworks, like the ones you mentioned. I don't know why this has anything to do with Electron, since their React push is for their front end frameworks for their main corporate product, Office365 (or whatever it's called today).
Both are not exactly light tho
I don’t have any numbers, just some anecdotal experience like the above.
It is not just speed. The UI of many sites suck too. Amazon, GoDaddy, for example.
Then there are ads. We don’t see ads in between content anymore. It is content within ads these days.
I am thankful that we can do so much online these days. But the experience could be better
But JIRA main performance issues in my experience are caused by badly sized servers for the level of use.
Jira is a 20 years old piece of software. I'm sure today's engineers do their best with the constraints they have. And I'm sure the 2002 engineers did their best with this period's assumptions and solutions.
I hate Jira as a product, but please don't attack people like that, have you never had to work on a product you're not 100% satisfied with? :/
I stand by what I said.
>I’m sure todays engineers do their best with the constraints they have.
There are two real constraints in the software engineering world: time and money (especially when we’re talking about an issue tracker, a wiki and a repo + CI\CD pipeline).
That Jira and confluences performance remains … not very good, suggests that the engineers are unwilling to, or unable to advocate for, spending the time and money to address this.
I find performance suffers mostly when media assets, advertisments, marketing and tracking scripts etc. come into play. The frontend rendering rarely makes a dent at that point.
But in most cases, front-end technology isn't the limiting factor.
No really. It is a B2B company that sells an idea to large orgs. "Know what is happening for everything and where you will be in a month.
It is not "Enable your workers to work more efficiently".
Jira simply doesn't really care about the average dev or such. In fact, most orgs use such a wildly configured version that it is pretty absurd.
Let me give you an example: Most companies have a workflow: To Do > In Progress > Testing > Done.
Foundationally, Testing and In Progress are tasks done by different operators. Jira doesn't, out of the box, conceptualize who tested a ticket and who developed it. It is all one field. You don't have seperate pointing for testing and development so you can't track QA capacity (Which is helpful to a team but not to overall planning as it just causes rushed QA). You don't have historical views of prior sprints "What was that Ticket I worked on last sprint?" (because that means nothing for forward velocity other than the final number) I could go on..but it all leads back to an absurd UI focused purely on projects and velocity above helpfulness. (And don't get me started on Jira's absurd take on SCRUM) Honestly, I'm kinda shocked no major software company has not just built their own and knocked Atlassian out of the park. I'm sure tracking velocity of other companies would be highly...helpful for Google/MS.
It's more or less one of those enterprise software packages that will be depended upon in larger orgs, because "nobody ever got fired for choosing $VENDOR". That sort of software tries to do a bit of everything, provide lots of features and customizability, sometimes at the expense of being more complex, bloated and slow.
Most people working on their own projects, when fully in control of the decision of what software they want to pick to best suit their own direct needs, might settle on something like Trello or even Kanboard instead. Personally, I self-host OpenProject because its features are a nice fit for my needs, even if it's still a bit sluggish (Rails app, limited hardware resources). Honestly, the performance of Kanboard was blazing fast when compared to anything out there - which is in no small part thanks to how focused and minimalist it is, which in some cases will be exactly what you'll want.
As another good example, I'd also put something like the Oracle database in same category: there will be many projects out there developed around it, as well as lots of knowledge, training, as well as entire professions built around it. But most people won't necessarily reach for something like Oracle XE for their own personal projects, they'll instead pick something like PostgreSQL or MySQL/MariaDB, because both of those are a little bit simpler to get started with and keep running, while still provide sufficient functionality.
This is an anecdote, but recently I launched all of the mentioned database options one after another in containers, for some testing. Oracle took around 10-20 minutes to start up an de usable. MySQL took about 5-10 minutes to become available for connections. PostgreSQL needed just 2 minutes. That's even before I get into how much data Oracle created in a container volume meant for data persistence (an order of magnitude more than MySQL or PostgreSQL).
I experienced similar behavior when setting up my own trial/testing license of Jira because I needed to do some integration dev work - with the resources given to it, I found it to be pretty sluggish and creating new issues took multiple seconds, which does get annoying when you also want to edit some of the fields, or have to do it often as a part of your work. Though I don't have exact numbers for that, I'm afraid.
Then i noticed a stark differences in attitude in the 2 studies I did at uni. One was more plain compsci. The other more web/mobile design and development. The later paid absolutely 0 attention to optimisation. Whether it was speed, download size or anything of the sort. The former treated an inneficient slution as invalid or at least graded lower. (Note this was in Beligum)
First time I started paying more attention to this where it wasn't when it wasn't in the context of being a budget constraint student was when I did a temporary IT support stint at a gigantic international pharma company and the software was so sluggish it was....insane. Dozens of people at our facility staring at a slugish webinterface waiting at every action and doing loads of those for every ticket. It was so infuriating I tried to make a browser plugin to prefill stuff with comon defaults the moment they were available knowing I'd never use it beyond those 3 months. Years of time must've been wasted staring at little loading circles because management did not use the software.
Then when I made native software for a manufacturing industry niche where i was told some suggested db retrieval and prerendering optimisations and such weren't worth the time....And sure. These were lowwage foreign workers using it, it didn't hamper much at all and our time was expensive. Maybe the business wouldn't get the money out of it....but then i ventured to production and notice more than a hundred people pulling the same actions many times a day thousands of times a year ....and see them waiting split seconds or multiple seconds depending on the actions that counted up to combined wasted minutes, hours, days, weeks and I realised what a load of bollocks it was.
Additionally when I helped extend various ERP's I realised the old ones were faaar from great but the move to web based interfaces really didn't do us much favours.
Then I come home and try to help my various layman family members on their comparatively slower windows and android devices and it becomes veeery apparent that this is not just a professional software issue. Slugish UI libraries on slugish frameworks on a slugish OS with various other slugish apps.
Coming home to a fast pc running Linux and using stuff i write in my free time using C++ or rust or even just various native apps on windows feels like such a extremely stark contrast.
My conclusion is that users won't care enough up to a certain point as studies show However I do believe that what those studies don't show is that for a good part this is because it's the default for many of them. They think this is just what tech is and all those countless small waittimes behind actions is normal.
Nngroup used to publish analyses of the state of usability, but I don’t think they have done one recently.
The old ones always showed progress, and that’s also what I would expect talking about the average situation.
Average progress doesn’t mean there are no shitty situations and we should always strive to improve, I just think claims like this are not helpful as they are used to make blanket statements about nuanced situations.
Unless you can back them up of course, and I would still love to see the data if anyone can find it.
I think it almost always comes down to one thing: Can people achieve the thing they want to achieve in a somewhat efficient way?
If the answer is yes there is lots of tolerance for all sorts of crap before people experience it in a negative way.
That means managing the experience. As example a multi minute upload process can be totally fine if handled properly, a .5s delay on an input can make it unusable. My point being; reality is a lot more nuanced than the blanket "it all sucks, and performance is everything" statement, and personally I don't think it's helpful. Unless we can actually look at metrics and assess their importance and how we can address them.
Don't get me wrong; we should absolutely keep trying to improve, especially crafting well made usable interfaces that are a delight to use. Performance is certainly very important, but it's not the be all end all of user experience and atm wrongly used to justify silly points why [my fav framework] is so much better than React.
The day they disable it, I’m not using it anymore.
Hyperbole. Web apps would not be so ubiquitous and popular for solving business problems if your claim was true.
But yeah, I guess you're not waiting in line at the bank anymore.
However almost certainly ubuitity is one measure or factor in an item's usefulness. I'd also claim Usefulness inversely correlates with miserableness in the mind, but perhaps not in practice :P depending on how boring or miserable useful things are.
In general, I think usefulness overrides miserableness simply because the willingness to do useful things, despite miserableness, is clearly tolerated and performed all across human economies and societies through time. all just depends on definitions