5 ms·

I tested out React Native on Android the other day and it was a real disaster. It doesn't compile for all the CPU ABIs (instruction sets) we have, so if you hav

by lnanek2 10y ago

I tested out React Native on Android the other day and it was a real disaster. It doesn't compile for all the CPU ABIs (instruction sets) we have, so if you have native libraries for x86 or arm 64 in your app it immediately breaks it completely. You have to remove all your own libraries for unsupported architectures, then modify your build not to include them, then depend on those platform's compatibility features to run React Native's libraries built for older ABIs like arm v7. Once you get it running despite their poor support for Android CPUs in their native libraries, half the examples and half the dependencies on the web out there crash immediately because they decided you have to import React and Component from "react" instead of "react-native" now. And there's no stack trace at all when it crashes for that error since it crashes before the normal source map functionality that provides them. My company has hundreds of files being used by React Native on iOS, but they are unusable due to this, even hours of search and replace cannot fix it because it is still crashing out, probably due to one of a dozen dependencies. Similarly if you try to use react redux 4 you are screwed, only 3 is supported. Woe be to anyone who upgrades that dependency. As a Java programmer who is used to compile time errors when something is wrong, React Native where it crashes constantly at runtime due to poor platform decisions like forcing developers to use a different package from earlier versions is a tough pill to swallow.

haberman 10y ago
You had a lot of bad things happen with React Native. But do these bad experiences apply to Exponent also?
- jameside 10y ago
  Exponent mitigates a lot of the problems the OP described partly because it's a coherent, maintained platform that is one of our core competencies and partly because the design of Exponent guides you away from those issues. The Exponent team spends a lot of time working with React Native and several members including myself are also core contributors to React Native so we see many of these issues up close. With Exponent you generally write your entire app in JavaScript. We've found that you can build quite a large set of comprehensive apps with pure JS and the APIs that Exponent provides (https://docs.getexponent.com/versions/latest/sdk/index.html https://docs.getexponent.com/versions/latest/sdk/index.html). We believe that set of apps will quickly grow as Exponent's API grows. Exponent is open-source, though, so if you needed to you could fork it and write your own native code in which case you might need to think about CPU ABIs. But most people developing on Exponent don't need to think about native code or ABIs at all. We also stay on top of React Native's changelog and make sure our APIs keep working when React Native changes. Some of your other third-party dependencies might fall out-of-date but the Exponent API stays current. Also with Exponent there aren't any Xcode or Android Studio workspaces to keep up-to-date. Static type systems for JS like Flow are getting better over time and if enough people use it (or contribute type definitions to https://github.com/flowtype/flow-typed https://github.com/flowtype/flow-typed) more of these runtime errors will become compile-time ones. Parts of the JS ecosystem do move quickly, though, largely because of the proliferation of npm.
deleted 10y ago
[deleted]
mukeshsoni 10y ago
Why is the top comment on every story a negative one? Is nothing good anymore?
- deleted 10y ago
  [deleted]
- thesmallestcat 10y ago
  Maybe it's because of: > half the dependencies on the web out there crash immediately because they decided you have to import React and Component from "react" instead of "react-native" now. That resonates for anybody who has done serious work with npm packages over the past few years. It seems like horrific breakage is the norm. Package authors break backwards compatibility for the stupidest "improvements."
  - dikaiosune 10y ago
    So please correct me if I'm wrong, but aren't these papercuts the exact motivating reason for something like Exponent?
  - dismantlethesun 10y ago
    Isn't there a way to control module name resolution when compiling a react-native app? On the browser side we have JSPM and Webpack, which let you alias module names so you don't have to rewrite third party code. It's pretty useful too if you have a drop-in replacement for another library. Heck with JSPM, you can even scope module resolution per module... so you can say module A should resolve to B but only within the context of an import from module C, everything else gets the normal resolution.
- _pmf_ 10y ago
  People probably don't like constantly reading about how some large SV player pushed its half-assed ideas through to the public despite the pain it causes. If the wheel you reinvented is square, you might run into someone who doesn't quite buy into your pitch of this being the future of technology.
- 10y ago
ak1394 10y ago
I'm using react-redux 4.4.5 in React Native app, no problems at all.
jesseruder 10y ago
Some of these issues don't apply to Exponent: > if you have native libraries for x86 or arm 64 in your app it immediately breaks it completely We handle all the native code for you, so you'll never hit this. > half the examples and half the dependencies on the web out there crash immediately because they decided you have to import React and Component from "react" instead of "react-native" now We support multiple React Native versions in our client app, so if you target an old version of React Native it'll keep running on that version even when we upgrade. The redux 3 vs. 4 part is still an issue, but you should only hit it when you're specifically upgrading your app.
- izacus 10y ago
  > We handle all the native code for you, so you'll never hit this. How do you handle that exactly?
  - chii 10y ago
    I'd assume it means you have to use their api rather than directly import native apis.
banachtarski 10y ago
> The other day Calling shenanigans given that redux 4 is completely supported and has been supported for a while. Was this many months ago?
- bagels 10y ago
  I had an identical experience last month with broken examples and packages, trying to get started with react native. Additionally, it seems many features are ios only.
jameside 10y ago
Yeah. That's a good articulation of some of the problems but that's tough to learn them the hard way. I wrote a comment below talking a bit about how a lot of these problems start to go away with Exponent but I wanted to offer some thoughts if you or your teammates have embarked on the raw React Native route. One thing I've learned from working with React Native is that you want to stay fairly up to date with the frequent releases. The Exponent team puts a lot of work into upgrading our own dependencies and maintaining the Exponent API that other developers depend on. Authors of components and other npm packages will update their code to work with the latest version of React Native. It takes energy to stay up to date since you need to read the release notes and breaking changes and sometimes it's helpful to scan the commit history on the release branch. But this way you can use react-redux v4 and other actively developed dependencies. On the other hand, though, sometimes component authors don't maintain their projects or support one platform but not the other. When dependencies fall out of date there isn't an easy answer. In the past I've fixed the issues myself and sent pull requests. Showing financial support is also another approach; my teammate Brent wrote a post about this: https://blog.getexponent.com/putting-your-money-where-your-package-json-is-e34a35099a1b https://blog.getexponent.com/putting-your-money-where-your-p.... The maintenance of open-source libraries isn't unique to React Native but it's perhaps exacerbated by its cross-platform nature and frequent release cycle. For the issue about CPU ABIs, I believe React Native supports armeabi-v7a and x86 but not arm64-v8a or x64. It would be great to have native arm64 support but so far no one has needed it enough to implement it instead of using ndk.abiFilters. For what it's worth, this works for Exponent and several other companies with apps that use React Native like Facebook.
on_and_off 10y ago
What made you want to try React-native ? I honestly struggle to find the problem addressed by RN, at least if you already know java.

by lnanek2 10y ago

haberman 10y ago

You had a lot of bad things happen with React Native. But do these bad experiences apply to Exponent also?

jameside 10y ago
Exponent mitigates a lot of the problems the OP described partly because it's a coherent, maintained platform that is one of our core competencies and partly because the design of Exponent guides you away from those issues. The Exponent team spends a lot of time working with React Native and several members including myself are also core contributors to React Native so we see many of these issues up close. With Exponent you generally write your entire app in JavaScript. We've found that you can build quite a large set of comprehensive apps with pure JS and the APIs that Exponent provides (https://docs.getexponent.com/versions/latest/sdk/index.html https://docs.getexponent.com/versions/latest/sdk/index.html). We believe that set of apps will quickly grow as Exponent's API grows. Exponent is open-source, though, so if you needed to you could fork it and write your own native code in which case you might need to think about CPU ABIs. But most people developing on Exponent don't need to think about native code or ABIs at all. We also stay on top of React Native's changelog and make sure our APIs keep working when React Native changes. Some of your other third-party dependencies might fall out-of-date but the Exponent API stays current. Also with Exponent there aren't any Xcode or Android Studio workspaces to keep up-to-date. Static type systems for JS like Flow are getting better over time and if enough people use it (or contribute type definitions to https://github.com/flowtype/flow-typed https://github.com/flowtype/flow-typed) more of these runtime errors will become compile-time ones. Parts of the JS ecosystem do move quickly, though, largely because of the proliferation of npm.

deleted 10y ago

[deleted]

mukeshsoni 10y ago

Why is the top comment on every story a negative one? Is nothing good anymore?

deleted 10y ago
[deleted]
thesmallestcat 10y ago
Maybe it's because of: > half the dependencies on the web out there crash immediately because they decided you have to import React and Component from "react" instead of "react-native" now. That resonates for anybody who has done serious work with npm packages over the past few years. It seems like horrific breakage is the norm. Package authors break backwards compatibility for the stupidest "improvements."
- dikaiosune 10y ago
  So please correct me if I'm wrong, but aren't these papercuts the exact motivating reason for something like Exponent?
- dismantlethesun 10y ago
  Isn't there a way to control module name resolution when compiling a react-native app? On the browser side we have JSPM and Webpack, which let you alias module names so you don't have to rewrite third party code. It's pretty useful too if you have a drop-in replacement for another library. Heck with JSPM, you can even scope module resolution per module... so you can say module A should resolve to B but only within the context of an import from module C, everything else gets the normal resolution.
_pmf_ 10y ago
People probably don't like constantly reading about how some large SV player pushed its half-assed ideas through to the public despite the pain it causes. If the wheel you reinvented is square, you might run into someone who doesn't quite buy into your pitch of this being the future of technology.
10y ago

ak1394 10y ago

I'm using react-redux 4.4.5 in React Native app, no problems at all.

jesseruder 10y ago

Some of these issues don't apply to Exponent: > if you have native libraries for x86 or arm 64 in your app it immediately breaks it completely We handle all the native code for you, so you'll never hit this. > half the examples and half the dependencies on the web out there crash immediately because they decided you have to import React and Component from "react" instead of "react-native" now We support multiple React Native versions in our client app, so if you target an old version of React Native it'll keep running on that version even when we upgrade. The redux 3 vs. 4 part is still an issue, but you should only hit it when you're specifically upgrading your app.

izacus 10y ago
> We handle all the native code for you, so you'll never hit this. How do you handle that exactly?
- chii 10y ago
  I'd assume it means you have to use their api rather than directly import native apis.

banachtarski 10y ago

> The other day Calling shenanigans given that redux 4 is completely supported and has been supported for a while. Was this many months ago?

bagels 10y ago
I had an identical experience last month with broken examples and packages, trying to get started with react native. Additionally, it seems many features are ios only.

jameside 10y ago

Yeah. That's a good articulation of some of the problems but that's tough to learn them the hard way. I wrote a comment below talking a bit about how a lot of these problems start to go away with Exponent but I wanted to offer some thoughts if you or your teammates have embarked on the raw React Native route. One thing I've learned from working with React Native is that you want to stay fairly up to date with the frequent releases. The Exponent team puts a lot of work into upgrading our own dependencies and maintaining the Exponent API that other developers depend on. Authors of components and other npm packages will update their code to work with the latest version of React Native. It takes energy to stay up to date since you need to read the release notes and breaking changes and sometimes it's helpful to scan the commit history on the release branch. But this way you can use react-redux v4 and other actively developed dependencies. On the other hand, though, sometimes component authors don't maintain their projects or support one platform but not the other. When dependencies fall out of date there isn't an easy answer. In the past I've fixed the issues myself and sent pull requests. Showing financial support is also another approach; my teammate Brent wrote a post about this: https://blog.getexponent.com/putting-your-money-where-your-package-json-is-e34a35099a1b https://blog.getexponent.com/putting-your-money-where-your-p.... The maintenance of open-source libraries isn't unique to React Native but it's perhaps exacerbated by its cross-platform nature and frequent release cycle. For the issue about CPU ABIs, I believe React Native supports armeabi-v7a and x86 but not arm64-v8a or x64. It would be great to have native arm64 support but so far no one has needed it enough to implement it instead of using ndk.abiFilters. For what it's worth, this works for Exponent and several other companies with apps that use React Native like Facebook.

on_and_off 10y ago

What made you want to try React-native ? I honestly struggle to find the problem addressed by RN, at least if you already know java.