Live data from Hacker News

React is holding me hostage

emnudge.dev

401–410 of 553 posts

Re: React is holding me hostage

#401
post #313

Earlier quoted context omitted.

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

The continued popularity of Slack and GitLab is an illustration that frontend performance alone is not the defining factor of success.

Not to mention Jira.

Re: React is holding me hostage

#402

Earlier quoted context omitted.

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

React/competitor performance that people use to compare frameworks is about rendering performance. E.g. React takes 100ms longer to rerender 10,000 elements (random numbers for the example). In these situations the actual real world difference will be negligible. 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…

Not exactly true about "performance is more API based". Everything adds up. 400ms here, 700 there. Websites can be slow even before api calls are triggered or on the middle of them, or while the results from api responses are presented.

Re: React is holding me hostage

#403

Earlier quoted context omitted.

> it is worse when the user can instantiate arbitrary components (say for a knowledge graph editor or a geospatial intelligence tool) that ‘listen’ to event changes. Your application is effectively "anything can modify anything", which is the previous step to "anything modifies anything", I/E big ball of mud. React's answer to that is "keep all the state in a small component" (small ball of mud) or "keep the state in…

I'll push back on that. In those two applications I joined failing projects that really were a "big ball of mud" and got them working. I didn't just figure out a working solution to the async updating problem, I became intimately familiar with seductive non-solutions. The problem with the discussion about React is that 99% of the use cases of React don't need to be an SPA . If it's possible to SSR your application yo…

SPAs exist because of the developer experience and user experience, the support for complexity is an added bonus.

Everything can be done with SSR, but some things are terrible with SSR (oh, you need real-time updates? have some meta http-equiv refresh header, and observe the beauty of the page going blank and re-rendering every second).

Before you ask about the developer experience: it's about having developers that can focus their brainpower into animations and interaction design without having the expectations of having to know SQL.

Re: React is holding me hostage

#404
post #292

Earlier quoted context omitted.

Performance of frameworks is often irrelevant for products/applications. 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 m…

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

Absolutely agree. Thank you btw for bringing up some of the recent history. People forget so easily

Re: React is holding me hostage

#406

Earlier quoted context omitted.

Performance is obviously important, to suggest otherwise is just silly. 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 imp…

> The important caveat is that once it's fast enough the gains are marginal. Based off how slow every SaaS service is in the B2B space, performance isn't important in all scenarios.

Marginal performance (i.e. 100 ms to 10 s per action, not multiple minute delays) is somewhat important to end users and matters only if they can switch easily. End users typically have little to no say in choosing the business software, especially after it's already bought.

Re: React is holding me hostage

#407

Earlier quoted context omitted.

I might not as well say that. I in fact said something completely opposite - that users don't care about performance. Hence more features->more users.

That's just simply not true though... 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

All the (dozens and hundreds) milliseconds add up and the sum of it is perceived easily

Re: React is holding me hostage

#409
post #197

Earlier quoted context omitted.

> the modern webapp experience is so miserable for the average person. I see this claim a lot and I'm curious what this is based on, can somebody drop some links to further reading?

It feels like a myth to me as well. We, tech nerds, value "optimized" solutions, "beautiful" code. We buy top-notch hardware, remove bloatware, because we really care about our tools and craft. 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.…

All good except of the last sentence.

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

Re: React is holding me hostage

#410

Earlier quoted context omitted.

I'll push back on that. In those two applications I joined failing projects that really were a "big ball of mud" and got them working. I didn't just figure out a working solution to the async updating problem, I became intimately familiar with seductive non-solutions. The problem with the discussion about React is that 99% of the use cases of React don't need to be an SPA . If it's possible to SSR your application yo…

SPAs exist because of the developer experience and user experience, the support for complexity is an added bonus. Everything can be done with SSR, but some things are terrible with SSR (oh, you need real-time updates? have some meta http-equiv refresh header, and observe the beauty of the page going blank and re-rendering every second). Before you ask about the developer experience: it's about having developers that…

4 letters. HTMX.

Or look at https://www.phoenixframework.org/ to see what a web framework would look like if real-time updates mattered. (That said I do find that simple IoT applications like a volume knob for my smart speakers in party mode or that can toggle my lights do work well with websockets + mobx + React.)

As for DX, I think waiting for "npm run start" to get out it's own way is a large enough decrement that I don't have to get into all the many problems w/ JS build systems.

I will grant that React is nice for an animation-heavy UI and I play video games enough that I appreciate such things. Another thing I like about React vs similar competitors is that the rendering model is flexible enough to enable things like react-three-fibers which is another reason for me not to invest in Vue, Svelte and things like that.

As for user experience isn't it the dark truth that Google and Facebook want "as many UI redraws as possible?" Let's face it, the honest clickthrough rate on ads is indistinguishable from zero but when you visit some site like anandtech it is by no means accidental that the layout rerenders endlessly because each rerender is a chance that a click on a link is transmogrified into a click on an ad. It's covert click fraud and is a large enough decrement and between that and the endless staring at spinners and waiting things to load any possible increment in user experience is at best hypothetical.

(e.g. in another window I have a completely SSRed app that uses HTMX. It uses zero spinners, runs as fast or faster than a desktop app, and never has the UI move around mindlessly. I grant it would be cool if it had some more animation but would I trade that for rock solid responsiveness?)

Post reply on HN