4 ms·

The actual load per page was around 1-5mb, so even when doing remote mobile testing in areas with low speed internet it wasn't an issue (although its definitely

The actual load per page was around 1-5mb, so even when doing remote mobile testing in areas with low speed internet it wasn't an issue (although its definitely one of the main reasons to switch to a real react site when scaling the product)

neya 6y ago
I disagree. How did 1-5mb become an acceptable size to ship to your users? That's actually quite a lot. In a slow connection, this isn't even going to load anything except a blank screen for such a long time.
- Aeolun 6y ago
  A desktop app quickly runs to 200mb. Why do we think it is so unreasonable for a full app on the web to take even 5% of that amount?
  - dlhavema 6y ago
    If you're talking a user downloading it with mobile data, it's gonna take a while before it can setup and show anything. I think someone else said there are other optimizations that happen when you shop production code.
  - JanisL 6y ago
    Because there's a LOT of people out there who have slow mobile data or poor signal strength. I think assuming that everyone everywhere has extremely fast internet is a bad assumption. Also there's an enormous amount of bloat in package sizes now, I don't think this really should be as bad as it currently is.
    - andratwiro 6y ago
      I agree 100%, in the use case I mentioned we were looking to either prove or disprove product hypothesis with real users fast so efficient code wasn't a priority, but rather to confirm wether what we were about to develop was valid.
  - tenaciousDaniel 6y ago
    You download a desktop app exactly once. You download a web app (almost) every time you navigate to the site.
    - AndriyKunitsyn 6y ago
      This is, generally, not true for a web app with a caching service worker.
    - Aeolun 6y ago
      I don’t know what your caching settings are, but my users download the app exactly once, and then only again if I push any update (or their browser cache randomly decides to clear itself, don’t really have any control over that). Aside from that, they use the app literally their entire workday, so spending 5 seconds loading the thing isn’t going to hurt anyone.
- vosper 6y ago
  I think they’re talking about testing prototypes exported from the design app, not what they’d necessarily ship as a finished product?
  - andratwiro 6y ago
    Yeah testing is its intended usage, but on the initial phases of the product we did use it as the finished product clients were paying for. It can be slightly hacked around to add user authentication & analytics, so if you are handling a small amount of users its a really efficient way to iterate fast.
- andratwiro 6y ago
  The idea of these tools is to allow teams to test a wide array of hypothesis to then have data-backed flows that make sense to code efficiently. The size is an unfortunate trade-off for testing speed. Of course the initial users will experience a slow product, but the idea is to discover faster what a useful product looks like without investing development resources.
- BackBlast 6y ago
  I'm an efficiency freak, so I understand what you're saying. But let us be realistic. I just loaded www.amazon.com - 17.8 MB transferred when it finally stopped. Arguably one of the most successful websites in the world. A 5MB asset size for most sites is perfectly acceptable.
  - neya 6y ago
    Yeah, I agree with you for the most part. And this argument comes up a lot. The difference is we're not Amazon yet. We don't have the same levels of user engagement, loyalty and whatever metrics that makes Amazon a success. To the end users, we're not as popular, one slow page load translates to a lost potential customer which when aggregated to even a few 100 potential customers could make or break a startup.
deleted 6y ago
[deleted]

neya 6y ago

I disagree. How did 1-5mb become an acceptable size to ship to your users? That's actually quite a lot. In a slow connection, this isn't even going to load anything except a blank screen for such a long time.

Aeolun 6y ago
A desktop app quickly runs to 200mb. Why do we think it is so unreasonable for a full app on the web to take even 5% of that amount?
- dlhavema 6y ago
  If you're talking a user downloading it with mobile data, it's gonna take a while before it can setup and show anything. I think someone else said there are other optimizations that happen when you shop production code.
- JanisL 6y ago
  Because there's a LOT of people out there who have slow mobile data or poor signal strength. I think assuming that everyone everywhere has extremely fast internet is a bad assumption. Also there's an enormous amount of bloat in package sizes now, I don't think this really should be as bad as it currently is.
  - andratwiro 6y ago
    I agree 100%, in the use case I mentioned we were looking to either prove or disprove product hypothesis with real users fast so efficient code wasn't a priority, but rather to confirm wether what we were about to develop was valid.
- tenaciousDaniel 6y ago
  You download a desktop app exactly once. You download a web app (almost) every time you navigate to the site.
  - AndriyKunitsyn 6y ago
    This is, generally, not true for a web app with a caching service worker.
  - Aeolun 6y ago
    I don’t know what your caching settings are, but my users download the app exactly once, and then only again if I push any update (or their browser cache randomly decides to clear itself, don’t really have any control over that). Aside from that, they use the app literally their entire workday, so spending 5 seconds loading the thing isn’t going to hurt anyone.
vosper 6y ago
I think they’re talking about testing prototypes exported from the design app, not what they’d necessarily ship as a finished product?
- andratwiro 6y ago
  Yeah testing is its intended usage, but on the initial phases of the product we did use it as the finished product clients were paying for. It can be slightly hacked around to add user authentication & analytics, so if you are handling a small amount of users its a really efficient way to iterate fast.
andratwiro 6y ago
The idea of these tools is to allow teams to test a wide array of hypothesis to then have data-backed flows that make sense to code efficiently. The size is an unfortunate trade-off for testing speed. Of course the initial users will experience a slow product, but the idea is to discover faster what a useful product looks like without investing development resources.
BackBlast 6y ago
I'm an efficiency freak, so I understand what you're saying. But let us be realistic. I just loaded www.amazon.com - 17.8 MB transferred when it finally stopped. Arguably one of the most successful websites in the world. A 5MB asset size for most sites is perfectly acceptable.
- neya 6y ago
  Yeah, I agree with you for the most part. And this argument comes up a lot. The difference is we're not Amazon yet. We don't have the same levels of user engagement, loyalty and whatever metrics that makes Amazon a success. To the end users, we're not as popular, one slow page load translates to a lost potential customer which when aggregated to even a few 100 potential customers could make or break a startup.

deleted 6y ago

[deleted]