4 ms·

Hey do you have some details on how do do this? I'm having some trouble figuring out how to do this from web app. Am I supposed to use the JSX details in the ha

Hey do you have some details on how do do this? I'm having some trouble figuring out how to do this from web app. Am I supposed to use the JSX details in the handoff pane along with the Framer react library? It seems like an incredibly useful feature and would really like to take a look.

andratwiro 6y ago
You need to have a pro account to use the desktop version and make the export, and as we speak they are refactoring this version to include it in the web version. On the – non Beta – Desktop version, it works as a single folder file (pretty sizeable, +150mb) that you can host anywhere, and renders the prototype within an iframe. The team at Farfetch did a custom component to do something similar to what you mention (if I understood you well): https://youtu.be/LEMGL2NH0r8?t=2760 https://youtu.be/LEMGL2NH0r8?t=2760
- jiofih 6y ago
  So you’re shipping a 150MB frontend to your users?
  - andratwiro 6y ago
    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.
    - deleted 6y ago
      [deleted]

andratwiro 6y ago

You need to have a pro account to use the desktop version and make the export, and as we speak they are refactoring this version to include it in the web version. On the – non Beta – Desktop version, it works as a single folder file (pretty sizeable, +150mb) that you can host anywhere, and renders the prototype within an iframe. The team at Farfetch did a custom component to do something similar to what you mention (if I understood you well): https://youtu.be/LEMGL2NH0r8?t=2760 https://youtu.be/LEMGL2NH0r8?t=2760

jiofih 6y ago
So you’re shipping a 150MB frontend to your users?
- andratwiro 6y ago
  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.
  - deleted 6y ago
    [deleted]