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