Hacker News Reader

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.

> We handle all the native code for you, so you'll never hit this.

How do you handle that exactly?

I'd assume it means you have to use their api rather than directly import native apis.

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

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."

So please correct me if I'm wrong, but aren't these papercuts the exact motivating reason for something like Exponent?

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.

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.

No idea but I'm really tired of all the negativity on here. Not even the noblest of projects escape, the negativity still finds a way. Every time I open the comments I think "ok, let's see what the HN crowd complains about this time" and I'm seldom surprised.

It sounds like a fair critique to me.

As an Android dev, RN is a real head scratcher for me.

I embraced kotlin but I really struggle to find RN's purpose.

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-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.

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

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). 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) 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.

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

> The other day

Calling shenanigans given that redux 4 is completely supported and has been supported for a while. Was this many months 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.

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.