21–30 of 149 posts
Absolutely not. We went all in on it. We even developed our own open source framework based on it called Gluestick. It's original purpose was to make it automatically isomporphic by running the same code in the browser as on the servers, using node. We also built a component/style library that allows us to make responsive designs into web and mobile apps quickly and easily. Gluestick also allows easy creation of nati…
Absolutely not. We went all in on it. We even developed our own open source framework based on it called Gluestick. It's original purpose was to make it automatically isomporphic by running the same code in the browser as on the servers, using node. We also built a component/style library that allows us to make responsive designs into web and mobile apps quickly and easily. Gluestick also allows easy creation of nati…
what's the company name?
Absolutely not. We went all in on it. We even developed our own open source framework based on it called Gluestick. It's original purpose was to make it automatically isomporphic by running the same code in the browser as on the servers, using node. We also built a component/style library that allows us to make responsive designs into web and mobile apps quickly and easily. Gluestick also allows easy creation of nati…
what's the company name?
Absolutely not. We went all in on it. We even developed our own open source framework based on it called Gluestick. It's original purpose was to make it automatically isomporphic by running the same code in the browser as on the servers, using node. We also built a component/style library that allows us to make responsive designs into web and mobile apps quickly and easily. Gluestick also allows easy creation of nati…
what's the company name?
OP, I would like to learn more about your story as well. How did you arrive at your decision that RN is not a good fit?
I really don't want to rail on RN. My experience is 2 years old at this point, and even then it was the internal decision we made based on our use-cases and needs. Yours are likely different and maybe RN would be a silver bullet for you. We tried it for a few months in earnest. There were a lot of bugs or incomplete APIs for our use-cases. Off the top of my head, if I remember correctly - intricacies and bugs around…
That's a... big mobile team. RN's been a good move for our smaller 2-3 person teams (2-3 devs, plus part-time designer, QA, various other roles full or part time—call it 6 personnel) though not without trade-offs. Big wins:
1) JS devs can contribute quickly and comfortably.
2) Can still easily write native code if needed (win over other native-but-not-native frameworks)
3) If you decouple business logic (Redux, even) and, say, REST client code, that stuff's largely portable to an awful lot of platforms. RN's supported platforms (including kind-of supported, like FireTV and Apple TV), plus desktop (well, "desktop"—Electron) and (depending on what you're doing) web.
4) It actually does look pretty OK on both iOS and Android with few special considerations (conditionally rendered sections, different views) for each. This surprised the hell out of me.
5) Papers over a lot of stupid, badly-designed, and/or broken crap on Android, and does a decent job of it.
These add up to a ton of time saved, which manages to overcome:
1) Immature, kinda poorly managed ecosystem. If you stray from RN+Redux and one or two other core libs, Here Be Dragons. Like, good luck ever upgrading RN if you load up on dependencies like a typical JS project, if those dependencies touch RN itself at all. Part of this is just JS "culture", part of it's the relative youth of the project, and part of it's FB's choices.
2) It's Javascript. We've fixed this by using Typescript, which is great. Makes Redux actually manageable—way less bouncing around between files, bouncing out to documentation, more just writing code. Fewer red screens due to typos or related dumb mistakes.
I can see, though, how it'd be challenging to divvy up work efficiently on even a fairly large mobile app for 30 people (are they all devs?!) unless you've got a lot more going on than just layout/CRUD/client-server, in which case I'd think RN wouldn't change things much, as far as division of labor goes.
Earlier quoted context omitted.
I really don't want to rail on RN. My experience is 2 years old at this point, and even then it was the internal decision we made based on our use-cases and needs. Yours are likely different and maybe RN would be a silver bullet for you. We tried it for a few months in earnest. There were a lot of bugs or incomplete APIs for our use-cases. Off the top of my head, if I remember correctly - intricacies and bugs around…
Was RN available for Android when you were testing it?
Overall, I would call it a great success; we have four apps (2 iOS and 2 Android) built from the same codebase, soon to be 5, and React Native has allowed us to be incredibly nimble in developing the framework and features for them.
Some things I do regret:
1. We didn't go all in on React Native, keeping large portions of code in native in case of performance or security needs.
This means that any given feature requires iOS, Android and React Native development. All of us are now fluent enough in each to do the work, but the context switching and debugging of actions moving across the bridge are a velocity killer.
2. We didn't realize that RN's cross-platform integrations testing story was so poor; we thought that we'd "just use Appium, it's perfect." Nope - design decisions made by the React Native team actually make Appium unusable for our Android apps.
This has forced a lot of churn in our testing strategy and we still have a lot of manual testing at this point. This is, IMO, the #1 thing that should be focused on either by Facebook or the React Native community.
Our iOS app: https://itunes.apple.com/us/app/root-car-insurance/id1021256...
Our Android app: https://play.google.com/store/apps/details?id=com.joinroot.r...