4 ms·

The single threaded nature is a big problem. I have led teams building large RN apps and it is then #1 problem we experience at scale. The worst bit is that yo

The single threaded nature is a big problem. I have led teams building large RN apps and it is then #1 problem we experience at scale. The worst bit is that you can only pass strings between threads in JS. Which means you have a lot of serialisation and deserialisation overhead, which can become the cause of UI slowdowns itself, which is a whole world of pain.

Klathmon 9y ago
Well you can pass TypedArrays as well (using a zero-copy "transfer" method), but that's of fairly limited use.
JustSomeNobody 9y ago
What does "at scale" mean in this context (mobile application)?
- LeoNatan25 9y ago
  It means an application that is beyond displaying a short list in a two — three screens. Once you start having a real business logic, you hit the relatively low ceiling. And the usual advice of “if you need more, just write a native component” — a. does not scale in performance either and b. what’s the point, just write in native in the first place and save yourself the headache of having to learn or hire native developers at moment of crisis.
  - atoko 9y ago
    Delegate the business logic to a server, I'm not sure what kind of "real business logic" needs to live in a mobile app
    - LeoNatan25 9y ago
      Then you don’t understand mobile development. There is absolutely no need to run business logic that can run on mobile on a server. Mobile devices today are more powerful than the majority of laptops out there.
      - atoko 9y ago
        Such as? Still no examples, I see. Without a real architecture you don't get to complain that a hamhanded solution is less than optimal
        LeoNatan25 9y ago
        For example, a mail app, a chat app. Would not scale at all with RN (or mobile web in web view). Imagine having to preload hundreds or thousand messages or other existing content while the user is viewing or typing. None of that is applicable to "server side business logic". Not if you want a quality app.
        doublerebel 9y ago
        This is false, mail and chat apps work fine with multiple hybrid app frameworks. I've created plenty of hybrid apps that have 100s of items in lists, this is what ListViews are designed for. There's no limitation inherent to hybrid apps that prevents holding 1000s of objects in memory. This also works fine on mobile web if it's designed right. If the mobile client can't handle 100,000 messages (probably more an issue of bandwidth or latency than local memory), then page them from the server. That's where serverside becomes relevant, at huge scale. I'm not sure you understand how architecture of a mail or chat app would work.
        LeoNatan25 9y ago
        In the past, I have built both a large enterprise-grade mail/calendar/contacts app which interfaces with Exchange, as well as a chat app: https://www.checkpoint.com/products/capsule-workspace/#overview https://www.checkpoint.com/products/capsule-workspace/#overv... https://itunes.apple.com/il/app/check-point-capsule-workspace/id522091441?mt=8 https://itunes.apple.com/il/app/check-point-capsule-workspac... RN list views are terrible, as all the data is held in memory. For a chat or a mail apps, that's catastrophic. "Paging on the server" is not a solution; users want all their data on the device. In my previous comment, I actually meant a different scenario than displaying a list. Take any proper mail client or a chat app; the first thing they do once a user logs in is start preloading previous data that can be found in cloud / on the server. Depending on the amount of data available, that is a very serious undertaking in and of itself, doing it efficiently enough in the background while updating the UI where needed upon insertion. This is just not possible in a single-threaded JavaScript. Your mindset of only holding a small subset of data on the mobile is erroneous and is empirically not what users want; it's a web mentality and has no place in any app development but web. We went with this approach, albeit for security reasons. The result was the vast majority of users were unhappy. Users wanted a full blown Outlook in their mobile, and there was no reason not to give it to them.

Klathmon 9y ago

Well you can pass TypedArrays as well (using a zero-copy "transfer" method), but that's of fairly limited use.

JustSomeNobody 9y ago

What does "at scale" mean in this context (mobile application)?

LeoNatan25 9y ago
It means an application that is beyond displaying a short list in a two — three screens. Once you start having a real business logic, you hit the relatively low ceiling. And the usual advice of “if you need more, just write a native component” — a. does not scale in performance either and b. what’s the point, just write in native in the first place and save yourself the headache of having to learn or hire native developers at moment of crisis.
- atoko 9y ago
  Delegate the business logic to a server, I'm not sure what kind of "real business logic" needs to live in a mobile app
  - LeoNatan25 9y ago
    Then you don’t understand mobile development. There is absolutely no need to run business logic that can run on mobile on a server. Mobile devices today are more powerful than the majority of laptops out there.
    - atoko 9y ago
      Such as? Still no examples, I see. Without a real architecture you don't get to complain that a hamhanded solution is less than optimal
      - LeoNatan25 9y ago
        For example, a mail app, a chat app. Would not scale at all with RN (or mobile web in web view). Imagine having to preload hundreds or thousand messages or other existing content while the user is viewing or typing. None of that is applicable to "server side business logic". Not if you want a quality app.
        doublerebel 9y ago
        This is false, mail and chat apps work fine with multiple hybrid app frameworks. I've created plenty of hybrid apps that have 100s of items in lists, this is what ListViews are designed for. There's no limitation inherent to hybrid apps that prevents holding 1000s of objects in memory. This also works fine on mobile web if it's designed right. If the mobile client can't handle 100,000 messages (probably more an issue of bandwidth or latency than local memory), then page them from the server. That's where serverside becomes relevant, at huge scale. I'm not sure you understand how architecture of a mail or chat app would work.
        LeoNatan25 9y ago
        In the past, I have built both a large enterprise-grade mail/calendar/contacts app which interfaces with Exchange, as well as a chat app: https://www.checkpoint.com/products/capsule-workspace/#overview https://www.checkpoint.com/products/capsule-workspace/#overv... https://itunes.apple.com/il/app/check-point-capsule-workspace/id522091441?mt=8 https://itunes.apple.com/il/app/check-point-capsule-workspac... RN list views are terrible, as all the data is held in memory. For a chat or a mail apps, that's catastrophic. "Paging on the server" is not a solution; users want all their data on the device. In my previous comment, I actually meant a different scenario than displaying a list. Take any proper mail client or a chat app; the first thing they do once a user logs in is start preloading previous data that can be found in cloud / on the server. Depending on the amount of data available, that is a very serious undertaking in and of itself, doing it efficiently enough in the background while updating the UI where needed upon insertion. This is just not possible in a single-threaded JavaScript. Your mindset of only holding a small subset of data on the mobile is erroneous and is empirically not what users want; it's a web mentality and has no place in any app development but web. We went with this approach, albeit for security reasons. The result was the vast majority of users were unhappy. Users wanted a full blown Outlook in their mobile, and there was no reason not to give it to them.