5 ms·

yes, from reading the docs, there's a websocket. Making a 'server call' on each interaction is also what web apps used to do before SPAs were a thing. And in m

yes, from reading the docs, there's a websocket. Making a 'server call' on each interaction is also what web apps used to do before SPAs were a thing. And in many cases it's what SPAs do as well. Of course, it depends what counts as an 'interaction', but that's been the case since JavaScript existed.

quechimba 3y ago
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.
- tomas789 3y ago
  A no-op API call to FastAPI takes more than that. Even when running on localhost. And FastAPI is one of the better contestants.
  - LtWorf 3y ago
    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 https://ltworf.github.io/typedload/performance.html Note that pydantic and apischema use .so files, while typedload is just pure python code.
  - paulddraper 3y ago
    A no-op localhost call takes more than 100ms??
  - folmar 3y ago
    On my mobile i5 10-gen it's 23 ms.
- Solvency 3y ago
  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?
  - moritzwarhier 3y ago
    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?
    - zdragnar 3y ago
      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.
  - dustingetz 3y ago
    manual network state sync between frontend and backend is the root cause of that
  - paulddraper 3y ago
    > A far cry from the snappiness of desktop apps from 25+ years ago So apps without network latency are faster? Huh.
- onion2k 3y ago
  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.
- zelphirkalt 3y ago
  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.
- roqi 3y ago
  > 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.
roqi 3y ago
> Making a 'server call' on each interaction is also what web apps used to do before SPAs were a thing. One of the reasons behind the popularity around webapps was that they would no longer need to make 'a server call' on each interaction. > And in many cases it's what SPAs do as well. I feel you're grossly misrepresenting what SPAs do. SPAs do calls to send and receive data, not to fetch server-side rendered content.
- motogpjimbo 3y ago
  > One of the reasons behind the popularity around webapps was that they would no longer need to make 'a server call' on each interaction. Ironically, many modern SPAs are significantly slower than the traditional apps they replaced. Try using Twitter's webapp on a non-premium phone, for example. Sometimes it's regrettable that the webdev truck has no rear-view mirror.
  - heavyset_go 3y ago
    Hell, try using the Twitter web app on something with 8GB of memory or that's older than 5 years old.
  - kokanee 3y ago
    The entire internet is slower because it's being squeezed to oblivion for monetization and tracking purposes. No matter what technology you choose to render HTML with, your company is going to have a slew of systems for injecting 3rd party scripts, running A/B tests, collecting analytics that include recording user sessions, etc etc. Back "before SPAs" we just weren't doing as much crap in the browser.
    - jraph 3y ago
      Tracking doesn't help but modern frontend development practices lead to slowness. Rerendering and recomputing too much (ever encountered these chains of map() and filter() in render()?), many API calls, huge icon sets, huge custom fonts, CSS frameworks and JS frameworks, huge dependency trees with many instance of the same lib running sometime in several versions, big bundles... This heaviness in the name of convenience and branding is not free, it forces people to ditch perfectly fine hardware, which has a high environmental cost... not directly paid by people funding the code). One of my pet peeves is managed text inputs, where render() is called each time you type a character, for a whole component tree if you are not careful and you happen to pass the content to some parent for some reason. Typing a message in Mattermost on the PinePhone is painful for this reason, there's just no reason typing should be slow even on slow hardware but managed component is considered good practice. Making people buy newer / powerful and making people wait and using too much energy should be considered bad practice.

quechimba 3y ago

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.

tomas789 3y ago
A no-op API call to FastAPI takes more than that. Even when running on localhost. And FastAPI is one of the better contestants.
- LtWorf 3y ago
  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 https://ltworf.github.io/typedload/performance.html Note that pydantic and apischema use .so files, while typedload is just pure python code.
- paulddraper 3y ago
  A no-op localhost call takes more than 100ms??
- folmar 3y ago
  On my mobile i5 10-gen it's 23 ms.
Solvency 3y ago
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?
- moritzwarhier 3y ago
  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?
  - zdragnar 3y ago
    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.
- dustingetz 3y ago
  manual network state sync between frontend and backend is the root cause of that
- paulddraper 3y ago
  > A far cry from the snappiness of desktop apps from 25+ years ago So apps without network latency are faster? Huh.
onion2k 3y ago
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.
zelphirkalt 3y ago
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.
roqi 3y ago
> 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.

roqi 3y ago

> Making a 'server call' on each interaction is also what web apps used to do before SPAs were a thing. One of the reasons behind the popularity around webapps was that they would no longer need to make 'a server call' on each interaction. > And in many cases it's what SPAs do as well. I feel you're grossly misrepresenting what SPAs do. SPAs do calls to send and receive data, not to fetch server-side rendered content.

motogpjimbo 3y ago
> One of the reasons behind the popularity around webapps was that they would no longer need to make 'a server call' on each interaction. Ironically, many modern SPAs are significantly slower than the traditional apps they replaced. Try using Twitter's webapp on a non-premium phone, for example. Sometimes it's regrettable that the webdev truck has no rear-view mirror.
- heavyset_go 3y ago
  Hell, try using the Twitter web app on something with 8GB of memory or that's older than 5 years old.
- kokanee 3y ago
  The entire internet is slower because it's being squeezed to oblivion for monetization and tracking purposes. No matter what technology you choose to render HTML with, your company is going to have a slew of systems for injecting 3rd party scripts, running A/B tests, collecting analytics that include recording user sessions, etc etc. Back "before SPAs" we just weren't doing as much crap in the browser.
  - jraph 3y ago
    Tracking doesn't help but modern frontend development practices lead to slowness. Rerendering and recomputing too much (ever encountered these chains of map() and filter() in render()?), many API calls, huge icon sets, huge custom fonts, CSS frameworks and JS frameworks, huge dependency trees with many instance of the same lib running sometime in several versions, big bundles... This heaviness in the name of convenience and branding is not free, it forces people to ditch perfectly fine hardware, which has a high environmental cost... not directly paid by people funding the code). One of my pet peeves is managed text inputs, where render() is called each time you type a character, for a whole component tree if you are not careful and you happen to pass the content to some parent for some reason. Typing a message in Mattermost on the PinePhone is painful for this reason, there's just no reason typing should be slow even on slow hardware but managed component is considered good practice. Making people buy newer / powerful and making people wait and using too much energy should be considered bad practice.