Live data from Hacker News

Exponent – Build native apps in JS that work across both iOS and Android

getexponent.com

71–80 of 119 posts

Re: Exponent – Build native apps in JS that work across both iOS and Android

#71
post #70

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…

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

Re: Exponent – Build native apps in JS that work across both iOS and Android

#72
post #70

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…

[deleted]

Re: Exponent – Build native apps in JS that work across both iOS and Android

#73
post #70

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…

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

Re: Exponent – Build native apps in JS that work across both iOS and Android

#74
post #70

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…

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.

Re: Exponent – Build native apps in JS that work across both iOS and Android

#75
post #70

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…

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

Re: Exponent – Build native apps in JS that work across both iOS and Android

#76

Exponent is super cool. Super simple to start building an app. I wish I could use it for every RN project I work on. The team is very responsive too. Totally recommend.

Can you elaborate on why you cannot use it for every RN project you work on?

Re: Exponent – Build native apps in JS that work across both iOS and Android

#77
post #70

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…

> The other day

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

Re: Exponent – Build native apps in JS that work across both iOS and Android

#78
post #70

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…

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.

Re: Exponent – Build native apps in JS that work across both iOS and Android

#79

Earlier quoted context omitted.

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?

Re: Exponent – Build native apps in JS that work across both iOS and Android

#80

Earlier quoted context omitted.

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

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.

Post reply on HN