12 ms·

I sympathize with cross-platform development woes (we have this problem too) but I can't say I've ever been impressed with a cross-platform app developed using

I sympathize with cross-platform development woes (we have this problem too) but I can't say I've ever been impressed with a cross-platform app developed using React Native (or anything else cross-platform). A React Native app isn't horrible or bad (nothing like Java Swing) but it also isn't delightful to use. Technically you have animations and things like the cross-platform navigator. In reality, you have a lot of performance issues and strange incompatibilities due to attempting to execute animation keyframes on the JS thread (or replace the system-provided navigation bar in the case of Navigator). It isn't terribly easy on battery life either. I'd rather write my sync and offline storage system in JS and share that across platforms while leaving the entire view layer as native code. That stuff is far harder to get right for non-trivial apps, it just isn't sexy and most web devs ignore it completely because hey - the web browser is always online! I'm biased though. Our customers download 5-10 GB projects with millions of objects in them because when you're building a hospital the MRI room is a literal faraday cage. No such thing as internet access in there and telling the user they can't pull up plans or engineering specs because they're offline is a non-starter.

Benjamin_Dobell 11y ago
Agreed. If people want to use reactive programming for their view layer on iOS or OS X then ReactiveCocoa is probably a nicer fit.
- dhruvtv 11y ago
  React != reactive programming.
  - vinnymac 11y ago
    To add to this, for anyone who is interested in using javascript to do reactive programming lookup rxjs or baconjs.
  - Benjamin_Dobell 11y ago
    I didn't say it did...? EDIT: I mentioned "reactive programming" because React is typically used in conjunction with reactive programming. Mentioning something related to something else is pretty standard communication. To elaborate on why I made my initial comment... Reactive programming is a paradigm, it has advantages (and disadvantages). Paradigms are higher level than implementations (libraries), or even a programming languages. When people start a new project they come up with requirements; continuous integration, easily testable etc. These requirements are mostly satisfied by a paradigm, not a implementation, nor even a programming language. If you've decided you like React, you probably like it for various reasons, most of which are probably because you're following the reactive programming paradigm - and perhaps because you like JavaScript. Nonetheless, when you start a new project (e.g. you've decided you want a native Mac app) it's your job as a competent software developer to determine the best fit for the project. This means you should really do your best to make a well rounded assessment of the situation - that means being educated about the subject matter. My comment merely agreed with the parent comment's description of the disadvantages of a (near) pure JS solution, and proposed ReactiveCocoa as an alternative that provides many of the advantages and familiarities of React, minus the disadvantages the parent post pointed out. Of course, you can't use JS to write your app - that may well be deemed by your team as a sufficient enough disadvantage to avoid ReactiveCocoa as a solution.
    - neoeldex 11y ago
      React has very little to do with reactive programming. It definitely has similarities, but in React you do not map the dataflow in the same way you would in reactive programming. Only the flow of data through components could be considered reactive. The real dataflow in reactive programming which could be considered the 'state', is not managed by React at all. You could use Redux for that, but having a datastore with reducers which modify state, and actions which trigger reducers is not something I would consider reactive.
  - xenadu02 11y ago
    Funny enough we are moving to a flux-style model for our view layer and using RAC signals for async stuff. The syncing and database logic is in a separate library that the main app treats as its official "API". That makes most of the interactions akin to Async Action Creators.
cageface 11y ago
I'm a big fan of React for frontend web work but I'm also not sold on React Native. It's a step up from web frameworks like Ionic but it's still a lowest-common-denominator experience that can easily be beaten by a real native app. And given that the competition for a spot on the user's home screen is tougher now than ever I don't think you can afford to be lowest common denominator unless the service behind your app is so essential that users will put up with a less than stellar app. So I think RN is a reasonable option for some kind of business that needs a decent, usable app on both iOS and Android. But if your business is mobile-first then I would still recommend you take the time to do a real native implementation.
- weixiyen 11y ago
  It's really odd to read your comment and the parent comment, at least regarding the iOS side of things. I've gotten my RN app to run at the same performance level (as far as the user is concerned) as my native app and there are definitely some non-trivial animations and gesture responders for the RN version. It did take some tuning and I had to add a couple artificial delays to wait for animations to finish, but nothing crazy. No opinion on Android yet, but RN for iOS is definitely not negatively impacting the user experience in my case. It's not in the store yet, but to give you an idea of the UI complexity level - see Slack and Google Chrome's UI and gestures.
  - briandear 11y ago
    "As far as the user is concerned.." What exactly does that mean? How do you benchmark that? Or are you just guessing?
    - weixiyen 11y ago
      It means that the transitions between RN and Native for most cases are visually indistinguishable to the end user. Of course there are potential differences "under the hood" simply b/c the animations are implemented differently. It's possible that the OPs ran into certain issues with specific cases or weren't able to figure out a workaround even though solutions exist, but the result of their comments unintentionally create FUD. I'll give an example. One of the most popular libraries for messenger apps to use in RN is GiftedMessenger, but it's actually doing the keyboard wrong, so people may get the misconception that ReactNative doesn't support smooth keyboard animations, which is not true. There are a lot of examples like this, not meaning to pick on anything specific. I will say that the library ecosystem around RN doesn't feel mature yet, kind of like Node.js in the early days, but React-Native itself is not the issue.
arasmussen 11y ago
The point of React Native isn't to create a delightful product experience. The point is to create the equivalent experience of a native app with a delightful development and organizational experience. - Instead of having separate teams develop your iOS, Android, and now OS X apps, one product team can make all three and share the majority of the code. - Instead of a slow frustrating compile cycle you get live reloading.
- switch007 11y ago
  So you're supposed to explain to your boss that the poor user experience is due to you picking something that was easier to develop with?
  - bmelton 11y ago
    Exactly. Except, the time to do it is before you decide on a tool, when the company is comparing time to value vs. quality. Whether or not the experience is great isn't a deal-breaker, it's a factor in the decision making process. For plenty of companies out there, having a less-than-perfect application that they can deploy to many platforms in a month or two with a single or couple of developers is a choice that might get made, when the alternatives are either much longer timetables or many more dollars.
  - hrktb 11y ago
    TBH this kind of solution is more often pushed by bosses than devs. Any management person will throw in a "you've done X on this platform, why don't you try to reuse most of your stuff on this other platform ?", just in case it's actually doable.
    - bobwaycott 11y ago
      I feel bad for you if you've met such bosses. As one, and as someone who has worked under several, I've never once experienced a boss knowing or saying such things. I've only ever seen it come from developers. Edit: Just to clarify, there may be instances where a mgmt type has asked if X on platform Y can be reused on platform Z easily. I've never seen it go beyond the ask.
zkhalique 11y ago
I agree that sync and offline storage is hard to get right. We developed a whole general-purpose platform to do exactly this, in a way that also supports multiple users, decentralized publishing, offline storage, synchronizing messages, optimistic updates etc. And unlike Firebase, Parse et al it is based on posting messages to streams that people join, rather than diffing objects. This way you can have a history of changes, and just focus on implementing the front end handlers for the changes.
- mbrock 11y ago
  Are these messages kind of like Redux actions, i.e., arbitrary domain events with semantics defined by pure JavaScript functions?
  - zkhalique 11y ago
    You could describe them that way. Here is how we describe them: http://qbix.com/platform/guide/messages http://qbix.com/platform/guide/messages
alexkavon 11y ago
> I sympathize with cross-platform development woes (we have this problem too) but I can't say I've ever been impressed with a cross-platform app developed using React Native (or anything else cross-platform). Do you feel the same way about Xamarin? I'm just curious as I've been considering moving to it. My company has been developing on Ionic the past year or so and it's become quite cumbersome as a platform. Basic apps look alright in Ionic, but is plagued by web view problems, making a non believer in the platform. Xamarin seems to compile better and avoid the web view. I guess I'm just looking for opinions.
- skrebbel 11y ago
  You realize that React Native also avoids the web view, right? Its more like Xamarin-for-JS with a ui kit built in.
- blub 11y ago
  Any 3rd party solution will have some issues. Whenever you see mostly positive testimonials, you should be both suspicious and scared, because it means you will be the one to find those issues in production, and you won't find any help on the internet. That was a long time the case for Xamarin, but if you look at their customer forums, reddit, stackoverflow etc you will find the negatives too nowadays. I am not interested in .NET, so I would not personally use Xamarin anyway, but I know that with Qt for instance you have to be careful with mobile UIs - it's best used for custom stuff and not native-looking apps.
  - m_fayer 11y ago
    I use Xamarin regularly, and it's true the primary downside is frequent bugs and regressions along the entire toolchain, and in the Xamarin wrappers of native APIs. That said, it's improved by leaps and bounds in since last Summer. It's gone from "I'm about to dump this platform any day now" to "minor nuisance", and most of the time you can just get on with your work.
    - dcveloper 11y ago
      I second the regression issue. Particularly if you use Xamarin.Forms. The Forms navigation stack is full of memory leaks as well.
underwater 11y ago
What React Native apps have you tried?
- wuliwong 11y ago
  Facebook's Groups app.
eloisant 11y ago
The thing is that when you encounter a good application based on a cross-platform toolkit, you don't know it's a cross-platform toolkit. You only know when you notice something is wrong.
- LeoNatan25 11y ago
  You know. You always know. Do you not know Atom is web based? You always feel it, no matter how good it is. It's never as good as native. It's just a deep down, "something is not right" or "something is not 100% the same" feel that you always have, be it on mobile or desktop.
  - jrochkind1 11y ago
    Eh, Slack works pretty well, and I don't know if I would have known. It may depend on the app function/domain, a chat app is maybe one you expect to look like 'the web' in the first place. Instagram too maybe, maybe apps with network connectivity/communication as their core will deal better with being implemented on web-tech based platforms.
    - veidr 11y ago
      There are two non-native apps I use frequently on OS X, which are both rather jarring and tawdry in their deviations from the platform norms. Slack is the second-worst offender. It feels less native than many websites do. The other is Rubymine, which on Mac now includes its own embedded Java runtime. It's significantly worse, but they are neighbors on the spectrum. Slack suffers less because it's mostly just chat, which can be done even in a Terminal window (e.g., IRC) without suffering that badly. But when you try to do anything in Slack other than just chat, the non-native kludge factor quickly becomes obvious and irritating.
  - squeaky-clean 11y ago
    Have you used Visual Studio Code? It's also web based, and 100x smoother than Atom. Some applications are just slow.
  - 11y ago
TeeWEE 11y ago
I totaly agree with you. What web-devs often forget is that native (mobile apps) have a very different runtime environments, things come and go (onCreate, onDestroy). Memory gets destroyed and reused. You need to think about background processes, multithreading. App startup is of upmost important. (starting a web page takes a lot of time, people every noticed that ios-chrome only has one page in memory at a single point ?). Its just a different mindset. The webbrowser is an abstraction on top of UI toolkits, with a very dynamic rendering engine, and simplified execution environment. Once you have a a hammer (javascript), it doesnt mean you should apply it everywhere.
- Wintamute 11y ago
  tl;dr React Native doesn't use browser. It's not clear from your comment whether you're familiar with React Native architecture or not. A React Native app works by using JS/React as the "brains" of the app (http services, state, smart components) and runs this in a separate thread to a 100% native portion of the app that uses uses platform specific native ui controls. Animation performance is pretty good because of this multithreaded approach. So in this way your JS app brain can be portable across platforms, while the nitty gritty view layer may shift to accommodate the capabilities of the native components you work with on each platform.
Kiro 11y ago
> I'd rather write my sync and offline storage system in JS and share that across platforms while leaving the entire view layer as native code. Of course, who wouldn't? The problem is resources. The alternative to not horrible/bad (React Native) for many devs is either horrible/bad (Ionic etc) or nothing.
hartmel 11y ago
Am I the only one who see the same story repeated again ? We have now Facebook, a major actor on the web, who is developping a cross-platform toolkit for application development, using OS native widgets. XUL, I miss you :) And now others try support different OS. Mozilla created everything and they just failed to "market" it. It s at the same time a pain and a joice to see real JS applications, shadow dom, custom components, CSS based styling being the core of a toolkit while we saw XUL/XBL/CSS/native calls from Mozilla be killed a few months ago. It had its flaws, but it s a serious (but really difficult) way to go : Qt did it, Gnome did it, Microsoft did it, even Adobe tried to do. Mozilla and people involved in previous ideas and implementations deserve a special mention for their work. We really need such technologies, and that Mozilla killed theirs was a really sad choice for me. Creating software with "simple" markup, "simple" styling rules, "simple" event/user interaction handling should be a concrete goal of decades of languages/compilers/interpreters researches. It has a price : performance, sometimes native look&feel not perfectly accurate, supported platform must have similarities. We may hopefully reach a level where a <button> tag will cost 1% of overhead against a native call and this will be a great day. I hope these new implementations will succeed, and that the actual overcomplexity in the web developpement will not land in though.
- pjmlp 11y ago
  > We may hopefully reach a level where a <button> tag will cost 1% of overhead against a native call and this will be a great day. Also known as XAML and QML.
  - pax_americana 11y ago
    I find it amusing that those two mirror XML and JSON respectively.
    - pjmlp 11y ago
      We could have had XAML for the web if XHTML had been successful. It is a pleasure not having to deal with HTML + CSS + JavScript tricks to bend the DOM to fake UI widgets.
jaxondu 11y ago
React Native (RN) is not for all apps, it has its uses if what your app does is mainly text delivery, example news app. One of the more complicated app that uses React Native is Discord for iOS (http://stackoverflow.com/questions/35309471/is-discord-mobile-app-really-built-with-react-native http://stackoverflow.com/questions/35309471/is-discord-mobil...), a Slack like chat app. That was then but I'm not sure the latest version is still RN heavy. You can actually build a native iOS app, and then add RN as part of your app. The tweet by Discord that said they are using RN is deleted. Some reservations to choose RN: RN is possible due to the JavaScriptCore framework build by Apple. It is the bridge between JavaScript code and Cocoa API. Apple designed this so that you can use JavaScript as scripting language for Cocoa. The popular Sketch for OS X is using the precise JavaScriptCore to power its plug-in scripting feature. I guess Apple never have thought JavaScriptCore could be used the way RN does. Choosing RN means your app is relying on Apple's decision on JavaScriptCore API. Someone please enlighten me if RN is still possible or not if Apple remove JavaScriptCore. JavaScriptCore opens up the Cocoa API, but does not give you a JavaScript ready API. So RN has to implement the bridge internally. So when iOS 10 is released, you will have some lag waiting for new features or changes to be supported by RN. I guess this is common problem to all cross-platform framework. In order to implement RN for Android, Facebook implements its own JavaScripCore for Android. I have no Android experience, but what I read is RN app for Android is not performing as natively as its iOS counterpart. If your business rely on all Apple's platform, then choosing RN does not help as there is no RN for watchOS and tvOS. React Native will make app manager and web-dev team happy, but not those who treasure the last mile UX experiences. But is could also be useful for those startups creating their first MVP. Get app release fast and then change to native codes when you got the traction. Is this good or bad startup advice? It will be a different ballgame if Facebook announce they are moving to use 100% React Native for Facebook for iOS app.
- jhgg 11y ago
  I work at discord. The app is still react native. We use component kit for chat messages view though. But this was because early react native when we built it couldn't do what we wanted to. May switch to full RN soon.
jbhatab 11y ago
Are you being serious? Have you seen facebook groups or discord? Both are amazing apps. Facebook groups is better than most native apps I see. Just because the tool isn't the right tool for your job means nothing about how good it is. graph databases aren't the best at searching large singular tables, but that doesn't make them useless.
- RussianCow 11y ago
  I could be wrong, but I don't think Discord uses React Native; I think it just uses Cordova or one of the web hybrid platforms. And it definitely shows: performance is less than stellar, and it definitely doesn't feel like a native app to me (on Android, at least). Edit: It looks like the iOS version is built using React Native, but the Android one is not. I can't comment on the iOS version as I've never used it.
  - seanclayton 11y ago
    The Android app is fully native because Android phones tend to have not have the single thread performance that js needs.
    - RussianCow 11y ago
      Do you have a source for this? Everything I'm finding suggests that the Android app is not native, and last time I used it (a couple months ago), it definitely didn't feel native, and performance was sub-par.
hire_charts 11y ago
I have a question. How would you know when you're using an iOS or Android app developed with React Native? Is it possible that you're only unimpressed when you actually notice something is off? Because, in my experience, React Native is the first framework that actually feels native, and often results in apps that behave identically to their native counterparts. One of the big reasons for this is that it actually is using native components in most places. Facebook's philosophy isn't that you should write platform-agnostic components and use them everywhere. They actually encourage using platform features wherever possible, but at the same time the way you write the components doesn't change across platforms -- "learn once, write anywhere."
KingMob 11y ago
I can imagine there not being great internet while you're building a hospital, but you know MRI rooms aren't that large, right? If you need to leave the Faraday cage, you just walk 10 feet. Your customers are probably downloading GBs of data in advance because their reception/speeds outside the MRI room aren't sufficient.
- xenadu02 11y ago
  I was making a glib comment to sum up the entirety of the issue. I actually typed up the full pedantic explanation, then deleted it. I told myself it was superfluous prose. Guess I was wrong! Yes, the problem is that connectivity is often absent, poor, or slow combined with the fact that the app is useless without the entire dataset available. And you're collaborating with a team, so you have 10s-1000s of disconnected clients.
hollerith 11y ago
>when you're building a hospital the MRI room is a literal faraday cage. No such thing as internet access in there No such thing as Wifi, sure, but why can't the hospital run ethernet into the room?
- xenadu02 11y ago
  Because the building is under construction and there's no conduit... Or working power for that matter.

Benjamin_Dobell 11y ago

Agreed. If people want to use reactive programming for their view layer on iOS or OS X then ReactiveCocoa is probably a nicer fit.

dhruvtv 11y ago
React != reactive programming.
- vinnymac 11y ago
  To add to this, for anyone who is interested in using javascript to do reactive programming lookup rxjs or baconjs.
- Benjamin_Dobell 11y ago
  I didn't say it did...? EDIT: I mentioned "reactive programming" because React is typically used in conjunction with reactive programming. Mentioning something related to something else is pretty standard communication. To elaborate on why I made my initial comment... Reactive programming is a paradigm, it has advantages (and disadvantages). Paradigms are higher level than implementations (libraries), or even a programming languages. When people start a new project they come up with requirements; continuous integration, easily testable etc. These requirements are mostly satisfied by a paradigm, not a implementation, nor even a programming language. If you've decided you like React, you probably like it for various reasons, most of which are probably because you're following the reactive programming paradigm - and perhaps because you like JavaScript. Nonetheless, when you start a new project (e.g. you've decided you want a native Mac app) it's your job as a competent software developer to determine the best fit for the project. This means you should really do your best to make a well rounded assessment of the situation - that means being educated about the subject matter. My comment merely agreed with the parent comment's description of the disadvantages of a (near) pure JS solution, and proposed ReactiveCocoa as an alternative that provides many of the advantages and familiarities of React, minus the disadvantages the parent post pointed out. Of course, you can't use JS to write your app - that may well be deemed by your team as a sufficient enough disadvantage to avoid ReactiveCocoa as a solution.
  - neoeldex 11y ago
    React has very little to do with reactive programming. It definitely has similarities, but in React you do not map the dataflow in the same way you would in reactive programming. Only the flow of data through components could be considered reactive. The real dataflow in reactive programming which could be considered the 'state', is not managed by React at all. You could use Redux for that, but having a datastore with reducers which modify state, and actions which trigger reducers is not something I would consider reactive.
- xenadu02 11y ago
  Funny enough we are moving to a flux-style model for our view layer and using RAC signals for async stuff. The syncing and database logic is in a separate library that the main app treats as its official "API". That makes most of the interactions akin to Async Action Creators.

cageface 11y ago

I'm a big fan of React for frontend web work but I'm also not sold on React Native. It's a step up from web frameworks like Ionic but it's still a lowest-common-denominator experience that can easily be beaten by a real native app. And given that the competition for a spot on the user's home screen is tougher now than ever I don't think you can afford to be lowest common denominator unless the service behind your app is so essential that users will put up with a less than stellar app. So I think RN is a reasonable option for some kind of business that needs a decent, usable app on both iOS and Android. But if your business is mobile-first then I would still recommend you take the time to do a real native implementation.

weixiyen 11y ago
It's really odd to read your comment and the parent comment, at least regarding the iOS side of things. I've gotten my RN app to run at the same performance level (as far as the user is concerned) as my native app and there are definitely some non-trivial animations and gesture responders for the RN version. It did take some tuning and I had to add a couple artificial delays to wait for animations to finish, but nothing crazy. No opinion on Android yet, but RN for iOS is definitely not negatively impacting the user experience in my case. It's not in the store yet, but to give you an idea of the UI complexity level - see Slack and Google Chrome's UI and gestures.
- briandear 11y ago
  "As far as the user is concerned.." What exactly does that mean? How do you benchmark that? Or are you just guessing?
  - weixiyen 11y ago
    It means that the transitions between RN and Native for most cases are visually indistinguishable to the end user. Of course there are potential differences "under the hood" simply b/c the animations are implemented differently. It's possible that the OPs ran into certain issues with specific cases or weren't able to figure out a workaround even though solutions exist, but the result of their comments unintentionally create FUD. I'll give an example. One of the most popular libraries for messenger apps to use in RN is GiftedMessenger, but it's actually doing the keyboard wrong, so people may get the misconception that ReactNative doesn't support smooth keyboard animations, which is not true. There are a lot of examples like this, not meaning to pick on anything specific. I will say that the library ecosystem around RN doesn't feel mature yet, kind of like Node.js in the early days, but React-Native itself is not the issue.

arasmussen 11y ago

The point of React Native isn't to create a delightful product experience. The point is to create the equivalent experience of a native app with a delightful development and organizational experience. - Instead of having separate teams develop your iOS, Android, and now OS X apps, one product team can make all three and share the majority of the code. - Instead of a slow frustrating compile cycle you get live reloading.

switch007 11y ago
So you're supposed to explain to your boss that the poor user experience is due to you picking something that was easier to develop with?
- bmelton 11y ago
  Exactly. Except, the time to do it is before you decide on a tool, when the company is comparing time to value vs. quality. Whether or not the experience is great isn't a deal-breaker, it's a factor in the decision making process. For plenty of companies out there, having a less-than-perfect application that they can deploy to many platforms in a month or two with a single or couple of developers is a choice that might get made, when the alternatives are either much longer timetables or many more dollars.
- hrktb 11y ago
  TBH this kind of solution is more often pushed by bosses than devs. Any management person will throw in a "you've done X on this platform, why don't you try to reuse most of your stuff on this other platform ?", just in case it's actually doable.
  - bobwaycott 11y ago
    I feel bad for you if you've met such bosses. As one, and as someone who has worked under several, I've never once experienced a boss knowing or saying such things. I've only ever seen it come from developers. Edit: Just to clarify, there may be instances where a mgmt type has asked if X on platform Y can be reused on platform Z easily. I've never seen it go beyond the ask.

zkhalique 11y ago

I agree that sync and offline storage is hard to get right. We developed a whole general-purpose platform to do exactly this, in a way that also supports multiple users, decentralized publishing, offline storage, synchronizing messages, optimistic updates etc. And unlike Firebase, Parse et al it is based on posting messages to streams that people join, rather than diffing objects. This way you can have a history of changes, and just focus on implementing the front end handlers for the changes.

mbrock 11y ago
Are these messages kind of like Redux actions, i.e., arbitrary domain events with semantics defined by pure JavaScript functions?
- zkhalique 11y ago
  You could describe them that way. Here is how we describe them: http://qbix.com/platform/guide/messages http://qbix.com/platform/guide/messages

alexkavon 11y ago

> I sympathize with cross-platform development woes (we have this problem too) but I can't say I've ever been impressed with a cross-platform app developed using React Native (or anything else cross-platform). Do you feel the same way about Xamarin? I'm just curious as I've been considering moving to it. My company has been developing on Ionic the past year or so and it's become quite cumbersome as a platform. Basic apps look alright in Ionic, but is plagued by web view problems, making a non believer in the platform. Xamarin seems to compile better and avoid the web view. I guess I'm just looking for opinions.

skrebbel 11y ago
You realize that React Native also avoids the web view, right? Its more like Xamarin-for-JS with a ui kit built in.
blub 11y ago
Any 3rd party solution will have some issues. Whenever you see mostly positive testimonials, you should be both suspicious and scared, because it means you will be the one to find those issues in production, and you won't find any help on the internet. That was a long time the case for Xamarin, but if you look at their customer forums, reddit, stackoverflow etc you will find the negatives too nowadays. I am not interested in .NET, so I would not personally use Xamarin anyway, but I know that with Qt for instance you have to be careful with mobile UIs - it's best used for custom stuff and not native-looking apps.
- m_fayer 11y ago
  I use Xamarin regularly, and it's true the primary downside is frequent bugs and regressions along the entire toolchain, and in the Xamarin wrappers of native APIs. That said, it's improved by leaps and bounds in since last Summer. It's gone from "I'm about to dump this platform any day now" to "minor nuisance", and most of the time you can just get on with your work.
  - dcveloper 11y ago
    I second the regression issue. Particularly if you use Xamarin.Forms. The Forms navigation stack is full of memory leaks as well.

underwater 11y ago

What React Native apps have you tried?

wuliwong 11y ago
Facebook's Groups app.

eloisant 11y ago

The thing is that when you encounter a good application based on a cross-platform toolkit, you don't know it's a cross-platform toolkit. You only know when you notice something is wrong.

LeoNatan25 11y ago
You know. You always know. Do you not know Atom is web based? You always feel it, no matter how good it is. It's never as good as native. It's just a deep down, "something is not right" or "something is not 100% the same" feel that you always have, be it on mobile or desktop.
- jrochkind1 11y ago
  Eh, Slack works pretty well, and I don't know if I would have known. It may depend on the app function/domain, a chat app is maybe one you expect to look like 'the web' in the first place. Instagram too maybe, maybe apps with network connectivity/communication as their core will deal better with being implemented on web-tech based platforms.
  - veidr 11y ago
    There are two non-native apps I use frequently on OS X, which are both rather jarring and tawdry in their deviations from the platform norms. Slack is the second-worst offender. It feels less native than many websites do. The other is Rubymine, which on Mac now includes its own embedded Java runtime. It's significantly worse, but they are neighbors on the spectrum. Slack suffers less because it's mostly just chat, which can be done even in a Terminal window (e.g., IRC) without suffering that badly. But when you try to do anything in Slack other than just chat, the non-native kludge factor quickly becomes obvious and irritating.
- squeaky-clean 11y ago
  Have you used Visual Studio Code? It's also web based, and 100x smoother than Atom. Some applications are just slow.
- 11y ago

TeeWEE 11y ago

I totaly agree with you. What web-devs often forget is that native (mobile apps) have a very different runtime environments, things come and go (onCreate, onDestroy). Memory gets destroyed and reused. You need to think about background processes, multithreading. App startup is of upmost important. (starting a web page takes a lot of time, people every noticed that ios-chrome only has one page in memory at a single point ?). Its just a different mindset. The webbrowser is an abstraction on top of UI toolkits, with a very dynamic rendering engine, and simplified execution environment. Once you have a a hammer (javascript), it doesnt mean you should apply it everywhere.

Wintamute 11y ago
tl;dr React Native doesn't use browser. It's not clear from your comment whether you're familiar with React Native architecture or not. A React Native app works by using JS/React as the "brains" of the app (http services, state, smart components) and runs this in a separate thread to a 100% native portion of the app that uses uses platform specific native ui controls. Animation performance is pretty good because of this multithreaded approach. So in this way your JS app brain can be portable across platforms, while the nitty gritty view layer may shift to accommodate the capabilities of the native components you work with on each platform.

Kiro 11y ago

> I'd rather write my sync and offline storage system in JS and share that across platforms while leaving the entire view layer as native code. Of course, who wouldn't? The problem is resources. The alternative to not horrible/bad (React Native) for many devs is either horrible/bad (Ionic etc) or nothing.

hartmel 11y ago

Am I the only one who see the same story repeated again ? We have now Facebook, a major actor on the web, who is developping a cross-platform toolkit for application development, using OS native widgets. XUL, I miss you :) And now others try support different OS. Mozilla created everything and they just failed to "market" it. It s at the same time a pain and a joice to see real JS applications, shadow dom, custom components, CSS based styling being the core of a toolkit while we saw XUL/XBL/CSS/native calls from Mozilla be killed a few months ago. It had its flaws, but it s a serious (but really difficult) way to go : Qt did it, Gnome did it, Microsoft did it, even Adobe tried to do. Mozilla and people involved in previous ideas and implementations deserve a special mention for their work. We really need such technologies, and that Mozilla killed theirs was a really sad choice for me. Creating software with "simple" markup, "simple" styling rules, "simple" event/user interaction handling should be a concrete goal of decades of languages/compilers/interpreters researches. It has a price : performance, sometimes native look&feel not perfectly accurate, supported platform must have similarities. We may hopefully reach a level where a <button> tag will cost 1% of overhead against a native call and this will be a great day. I hope these new implementations will succeed, and that the actual overcomplexity in the web developpement will not land in though.

pjmlp 11y ago
> We may hopefully reach a level where a <button> tag will cost 1% of overhead against a native call and this will be a great day. Also known as XAML and QML.
- pax_americana 11y ago
  I find it amusing that those two mirror XML and JSON respectively.
  - pjmlp 11y ago
    We could have had XAML for the web if XHTML had been successful. It is a pleasure not having to deal with HTML + CSS + JavScript tricks to bend the DOM to fake UI widgets.

jaxondu 11y ago

React Native (RN) is not for all apps, it has its uses if what your app does is mainly text delivery, example news app. One of the more complicated app that uses React Native is Discord for iOS (http://stackoverflow.com/questions/35309471/is-discord-mobile-app-really-built-with-react-native http://stackoverflow.com/questions/35309471/is-discord-mobil...), a Slack like chat app. That was then but I'm not sure the latest version is still RN heavy. You can actually build a native iOS app, and then add RN as part of your app. The tweet by Discord that said they are using RN is deleted. Some reservations to choose RN: RN is possible due to the JavaScriptCore framework build by Apple. It is the bridge between JavaScript code and Cocoa API. Apple designed this so that you can use JavaScript as scripting language for Cocoa. The popular Sketch for OS X is using the precise JavaScriptCore to power its plug-in scripting feature. I guess Apple never have thought JavaScriptCore could be used the way RN does. Choosing RN means your app is relying on Apple's decision on JavaScriptCore API. Someone please enlighten me if RN is still possible or not if Apple remove JavaScriptCore. JavaScriptCore opens up the Cocoa API, but does not give you a JavaScript ready API. So RN has to implement the bridge internally. So when iOS 10 is released, you will have some lag waiting for new features or changes to be supported by RN. I guess this is common problem to all cross-platform framework. In order to implement RN for Android, Facebook implements its own JavaScripCore for Android. I have no Android experience, but what I read is RN app for Android is not performing as natively as its iOS counterpart. If your business rely on all Apple's platform, then choosing RN does not help as there is no RN for watchOS and tvOS. React Native will make app manager and web-dev team happy, but not those who treasure the last mile UX experiences. But is could also be useful for those startups creating their first MVP. Get app release fast and then change to native codes when you got the traction. Is this good or bad startup advice? It will be a different ballgame if Facebook announce they are moving to use 100% React Native for Facebook for iOS app.

jhgg 11y ago
I work at discord. The app is still react native. We use component kit for chat messages view though. But this was because early react native when we built it couldn't do what we wanted to. May switch to full RN soon.

jbhatab 11y ago

Are you being serious? Have you seen facebook groups or discord? Both are amazing apps. Facebook groups is better than most native apps I see. Just because the tool isn't the right tool for your job means nothing about how good it is. graph databases aren't the best at searching large singular tables, but that doesn't make them useless.

RussianCow 11y ago
I could be wrong, but I don't think Discord uses React Native; I think it just uses Cordova or one of the web hybrid platforms. And it definitely shows: performance is less than stellar, and it definitely doesn't feel like a native app to me (on Android, at least). Edit: It looks like the iOS version is built using React Native, but the Android one is not. I can't comment on the iOS version as I've never used it.
- seanclayton 11y ago
  The Android app is fully native because Android phones tend to have not have the single thread performance that js needs.
  - RussianCow 11y ago
    Do you have a source for this? Everything I'm finding suggests that the Android app is not native, and last time I used it (a couple months ago), it definitely didn't feel native, and performance was sub-par.

hire_charts 11y ago

I have a question. How would you know when you're using an iOS or Android app developed with React Native? Is it possible that you're only unimpressed when you actually notice something is off? Because, in my experience, React Native is the first framework that actually feels native, and often results in apps that behave identically to their native counterparts. One of the big reasons for this is that it actually is using native components in most places. Facebook's philosophy isn't that you should write platform-agnostic components and use them everywhere. They actually encourage using platform features wherever possible, but at the same time the way you write the components doesn't change across platforms -- "learn once, write anywhere."

KingMob 11y ago

I can imagine there not being great internet while you're building a hospital, but you know MRI rooms aren't that large, right? If you need to leave the Faraday cage, you just walk 10 feet. Your customers are probably downloading GBs of data in advance because their reception/speeds outside the MRI room aren't sufficient.

xenadu02 11y ago
I was making a glib comment to sum up the entirety of the issue. I actually typed up the full pedantic explanation, then deleted it. I told myself it was superfluous prose. Guess I was wrong! Yes, the problem is that connectivity is often absent, poor, or slow combined with the fact that the app is useless without the entire dataset available. And you're collaborating with a team, so you have 10s-1000s of disconnected clients.

hollerith 11y ago

>when you're building a hospital the MRI room is a literal faraday cage. No such thing as internet access in there No such thing as Wifi, sure, but why can't the hospital run ethernet into the room?

xenadu02 11y ago
Because the building is under construction and there's no conduit... Or working power for that matter.