Comment by whostolemyhat | Hacker News Reader

Comment by whostolemyhat | Hacker News Reader

Yes, we regret it. Our app is just a wrapper around a webview, and handles things like in-app payments and SDK integrations like Facebook login, in a team of ~10.

Our version of React Native is quite far behind which makes using libraries not already in the project difficult: you have to track back through versions to find a compatible version, which then may not be doing what you want since it's an older version.

We're also having trouble upgrading the version of React Native due to versions having breaking changes. I know it's technically still not v1.0, but in reality a lot of companies are using it so having a stable version would be nice. Since it's unstable, many libraries haven't updated to compensate so you run into the same problem as above, tracking down precise versions of dependencies which also still do what you want.

The build process feels pretty rickety and seems to rely on a lot of global state - I spent a while checking how we could update dependencies, but when I rolled back to a stable version I was unable to build even after re-installing node modules etc. I was only able to fix it after opening Xcode, removing all pod libraries and re-adding them; I have no idea why that worked, and there are very few clues on Github or Stack Overflow as to what specific errors mean. Fixing my build step took the best part of a day.

Overall, for a small app like ours, we're just spending far too long on non-development overhead, like fixing build systems or checking dependency versions, and will probably move to native versions at some point in the future. It may be a pain maintaining two separate versions, but we'll have solid integrations with payment gateways and lots of documentation and info on Github/SO for problems.

I like React and the idea of React Native, but at the moment it just feels far too unstable and unpolished to use. I'd like to use it in the future, but probably not until it's had a major version release.

Why are you using RN if your app is just wrapping a web view?

If you have to ask questions like this, you haven’t been working in the industry long enough.

Haven't been in the industry long enough to do what? Ask questions? It appears you have been working in the industry too long to answer them, which is much worse.

> Haven't been in the industry long enough to do what? Ask questions?

To be jaded.

It's merely a jab at the way we tend to overcomplicate solutions to simple problems. I think.

Yes, that’s right

I was wondering the same thing. It seems like the this may be a case of choosing the wrong tool for the wrong job. Some clarification around the context of the problem could eliminate that possibility. Seems like a fair question.

It's a reasonable question. It's not clear how much interactivity is required outside of the webview, but if there's very little or none, then it would be perfectly reasonable and simple to use the native mobile APIs to wrap the webview.

And thus avoid all the problems mentioned above.

Yep, that's our long-term plan, but saying we want to get rid of our working app and re-write it as two new apps from scratch doesn't go down particularly well with the business.

OK. Let's say that's completely true.

Is snarkily telling someone they're not good enough helpful?

Seems like a moment where you could share what you know (as someone, presumably, has been in the industry long enough) and help someone.

(FWIW it sounds like a decent question to me: but then again undoubtedly I have not been in the industry long enough!)

I wasn’t meaning that at all. I meant that if you have to ask why people solve problems with over complicated solutions, you haven’t been doing this very long.

The answer is: it’s in our nature to make simple things difficult.

It shows more maturity if you just accept people do stupid things without trying to pry a rationale out of them IMO.

That is a reasonable opinion to have for sure, I think it just wasn't too obvious what you meant unfortunately!

A different way to ask that would be, if it's just a webview why not strip out RN instead of struggling with breaking change upgrades?

On top of that my question to the OP would be, why do they need to search around for libraries that are older than RN. In a team of 10 you can most likely create your own ones, or fork already made libraries and upgrade them to fit your purpose. One of the greatest things with RN so far for my team has been that we can actually write native components and bridge them. Yes RN is changing quite fast in general and most libraries out there might not fit your exact purpose, but I find it quite easy to integrate what I need in our app. (Team of 3, been on production for 8 months, its pretty alright so far)

The main problem we're having is that newer versions of RN use React 16. React 16 has breaking changes, particularly the changes to PropTypes and createClass, which some of our dependencies have already fixed but others haven't. This means to upgrade RN, we need to either submit fixes for all these libs or use a version of RN which still uses React 15, both of which have their own problems, especially since React 16 is still a release candidate and not a full release.

We're not creating our own libraries for a couple of reasons: firstly, this was supposed to be a quick project to see if an app is viable (but has now lasted long enough that we've run into this issue), and secondly we've already got forks of key libraries, which is taking more time away from implementing actual features since we now need to maintain them and pull in updates from the original repos.

Yes we should have kept dependencies up-to-date, but constant breaking changes are just taking too much time away from development time, so it's not a good fit for our project as it stands.

Imho, I think you got it wrong here.

I don't think you are supposed to make a production RN app out of the bat, by just using 3rd party dependencies.

RN isn't wordpress where someone can employ you and say I want this and that and then you go off install 50 plugins and thats it, your project is completed.

If you are installing a lot of RN 3rd party dependencies for a production environment then you are doing it wrong.

The best thing RN has to offer is being able to write React for parts and write Native code for heavy tasks.

You do need to go down and write your own components natively, sure if someone has done it before and its well maintained and you tested it and works for you then fine use that library, if not then don't install it but make your own.

For js components only components, then again if its very well maintained then use it, but nothing stops you for making the component that works for you.

RN is a bit less work than writing a Native app, but not too far apart. It's not meant to be for webviews and for people that just want to make a complex production app using 3rd party dependencies in very little time. Its meant for dev teams that JS is their main language but do have someone that has an understanding of native code.

Cool I'll just roll my own Facebook and Stripe integrations then

it depends, on my app I don't use Stripe so can't speak for its sdk, but I do use FB. At start I was using react-native-fbsdk but found that it was very limited and when I submitted a PR and went through the NDA procedure with facebook etc, then they delayed putting my PR which was fixing an issue out. I decided it would be easier for myself to bridge facebook's sdk, and so I did which was helpful as I've added quite more features to it which the react-native-fbsdk isn't providing.

That said it always depends on your usage and if it fits your purpose, but I wouldn't rely on 3rd party devs to solve my issues.

In-app payments and integration with Facebook login, Stripe, Apple subscriptions etc. It was in the first sentence ;)

When using RN with a web view you can easily communicate with RN using the postMessage API. From there, you can use RN for all of the native specific functionality. Most of the "native" code is shared between ios and android at that point. If you only need to support iOS then this is less valuable. This is the reason why things like Cordova exist. However, I find the communication between webviews and RN far more enjoyable to using Cordova + plugins.

Sounds like Ionic is a better solution for your app.

Reply on news.ycombinator.com