Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Yep. And nowadays you can deploy apps really close to users so latency is really low. If you have <100ms you don't really notice the latency.


But... 99% of insert-startup-product-built-on-React (or honestly, any framework) is typically super slow (for whatever reason that might be). Sluggish, not super responsive, laggy UI, however you want to describe it. A far cry from the snappiness of desktop apps from 25+ years ago.

Something or some collection of people are doing something wrong, somewhere in the chain. So isn't this just yet another way to further entrench the modern state of meh-ness in performant UI?


Your statement is very broad. Might be the startup culture and lacking technological expertise, no?

Was insert-startup-product-built-on-.NET fast 15 years ago, for example?

Not trying to be controversial, just wondering.

I agree that a product built by clueless developers stringing together random libraries or bad custom code in React would create slow products.

In your spirit, I might argue that thinking "reactively" and client-centric tends to lead to unneeded requests.

Developing without meaningful API contracts or basic CS skills also makes it easy to unintendedly blow up network payloads.

Caching is hard though.

Have you worked on bad PHP applications that reload on every interaction without caching?


As someone who has had the misfortune of working on poorly tuned WordPress and Drupal websites in a former life I can confirm this is an issue of culture, not and axiom of whether SPAs are intrinsically faster or slower.


manual network state sync between frontend and backend is the root cause of that


> A far cry from the snappiness of desktop apps from 25+ years ago

So apps without network latency are faster? Huh.


People notice the difference of < 10ms in input delay on a command line. I am pretty sure humans notice stuff >= 10ms, <= 100ms. It is perhaps the expectation, that is different. People do not expect websites to react immediately, like when they are typing a command in a terminal emulator.


> And nowadays you can deploy apps really close to users so latency is really low.

That sounds like blindly throwing money at the software architecture problem you created for yourself. Supposedly SPAs became popular because your line of reasoning was embarrassingly absurd, in the sense that you do not mitigate the penalty of a network call by microoptimizing the cost of a network call.


Proximity is only part of the equation. If a user has a slow router or a busy corporate firewall to go through their timings can be far higher than 100ms even if the server is a few miles away.


A no-op API call to FastAPI takes more than that. Even when running on localhost. And FastAPI is one of the better contestants.


If fast api didn't use pydantic (the slowest library in that space), I'm sure it might be more deserving of the name :D

Microbenchmark to compare with typedload (which I wrote) and apischema https://ltworf.github.io/typedload/performance.html

Note that pydantic and apischema use .so files, while typedload is just pure python code.


A no-op localhost call takes more than 100ms??


On my mobile i5 10-gen it's 23 ms.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: