Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Transition to React Native

blog.coinbase.com

Post reply on HN
Print view View original

181–190 of 221 posts

Re: Transition to React Native

#181

Post by throw14082020 »

kitsunesoba wrote: post #167
rhodysurf wrote: post #118

Earlier quoted context omitted.

I very much disagree that Android is easier to learn and iOS. The iOS SDK is incredibly simple to get started with compared to android. Dealing with extensions on iOS is really hard, but creating apps involves so much less boilerplate than in android. XCode isn’t great, but I am not a IntelliJ Jetbrains fan at all, their IDEs are way too heavy for my taste.

I concur. Another big benefit of iOS vs. Android is that the iOS SDK is both generally more capable (greatly reduced need for third party dependencies) and opinionated . The latter is hugely important because it means there’s a well supported “happy path” for almost everything, simplifying development. It’s a stark contrast to Android Framework where there’s 6 ways to do everything, 3 of which are deprecated, 2 that…

> the new shiny thing that’s too immature for production use

Both Android (e.g. Jetpack Compose, new privacy centric storage APIs that we are now forced to use) and iOS (SwiftUI) have this. I guess we'd need to list them down and compare.

> iOS SDK is both generally more capable

Yes, Apple provide more higher level functionality, at the expense of flexibility. Android also provides higher level features, but these are provided in external libraries which you can package in your app. When it comes to auxiliary features though (e.g. machine learning), I think Apple does the high level APIs much better. Android's features are quite a bit buggy.

Re: Transition to React Native

#182

Post by mekkkkkk »

hardwaresofton wrote: post #13
vmception wrote: post #6

If I wanted to do android development again, I have no idea which skillset to optimize for React Native? Kotlin? An old version of Java that just got lambdas? Are we doing Model-View-Presenter (MVP) no matter which? Or are we still doing Massive-View-Controller (MVC backronym) Are there adequate networking, database ORM, and image loading libraries for all frameworks? Last time I interviewed for any mobile developmen…

None of those! The real answer is Nativescript -- https://nativescript.org It doesn't get the buzz, and the ecosystem is somewhat old (it's surprisingly common to run into a repo that hasn't been touched in a year) but it's the superior platform to React Native and you get none of the capriciousness of the React ecosystem (if anything the Nativescript community might need a jolt). Nativescript is incredibly productiv…

What made you dislike Dart? I find it a highly inoffensive language.

Re: Transition to React Native

#183

Post by mekkkkkk »

pixel_tracing wrote: post #174
jessepollak wrote: post #155

Hi all - I support all Retail engineering at Coinbase and was one of the folks who helped shepherd this change through from inception to rollout. I'm happy to answer any questions that folks have - just thread here, and I'll either answer or pull in our team to give more detail.

So what is your native mobile engineering team doing now?

Which native mobile engineering team?

Re: Transition to React Native

#184

Post by modernerd »

throw14082020 wrote: post #179
kitsunesoba wrote: post #167

Earlier quoted context omitted.

I concur. Another big benefit of iOS vs. Android is that the iOS SDK is both generally more capable (greatly reduced need for third party dependencies) and opinionated . The latter is hugely important because it means there’s a well supported “happy path” for almost everything, simplifying development. It’s a stark contrast to Android Framework where there’s 6 ways to do everything, 3 of which are deprecated, 2 that…

To explain further why I think iOS is harder - Where will you learn it? Apple documentation is bad. remember this? "On Apple's Piss-Poor Documentation", 1180 points to date https://news.ycombinator.com/item?id=25046691 Android documentation is great . Yes there are at least 5 ways to do something e.g. schedule background work, load files, but its very clearly deprecated in their docs/ in the code. You can, read the c…

This is helpful overall but perhaps your Xcode experience is out of date, or at least several of your comments don’t match my experience of Xcode 12.5.

> The actual code editing part is just a text editor, e.g. searching for function calls involves using the search function, as opposed to a keyboard shortcut that uses static code analysis.

Xcode has indexed static analysis, symbol navigation, jump to definition, quick fixes, in-line quick help and a bunch of other features I use every day that lift it out of the ‘just a text editor’ class.

> Most warnings for your code won't show up until you try to build it, therefore the feedback loop is extremely slow.

This hasn’t been my experience - warnings that appear on build generally also appear when saving a file. There’s no need to trigger a build to get feeedback.

> Code refactoring features do not exist on Xcode.

Editor > Refactor reveals 13 refactoring options for me in Xcode 12.5.

I like Xcode, even as someone who switches between it and JetBrains editors (for frontend/backend work) every week. The only thing I really miss is stable vim emulation.

Re: Transition to React Native

#185

Post by jpeter »

alexandr1us wrote: post #154

I want to write small review regarding replies on this link. I am working as an mobile engineer for more than 8 years now. I have worked on native iOS, Android, Xamarin, Unity, Titanium, Flutter and React Native. Long story short I have never been happier since I switched to React Native and Expo made everything so much better. I am not comparing it to native but I can compare it to Flutter. First of all Flutter has…

What was the worst framework? Xamarin?

Re: Transition to React Native

#186

Post by travisjungroth »

jessepollak wrote: post #155

Hi all - I support all Retail engineering at Coinbase and was one of the folks who helped shepherd this change through from inception to rollout. I'm happy to answer any questions that folks have - just thread here, and I'll either answer or pull in our team to give more detail.

Sup Jesse!

Re: Transition to React Native

#187

Post by mikevm »

gfarah wrote: post #48
nmfisher wrote: post #11

Anyone got experience with both RN and Flutter willing to chime in on how they compare? So far I've been fairly satisfied with Flutter, however there are some glaring performance issues (though it sounds like these will be addressed in due course).

My team's anecdotal experience: In February of last year we moved from RN to Flutter. We are super happy with the switch. Our app in Flutter is used by around 1.3M users in 3 different countries. Our Flutter app is more stable (less crashlytics bugs), faster (performance wise) and keeps our mobile team happy (better developer experience). We also use Flutter Web for one app used by around 25k users, even though it is…

What about the currently janky iOS animations with no fix in sight? https://github.com/flutter/flutter/issues/60267

I'd warn anyone targeting multiplatform mobile from using Flutter until this is resolved.

Re: Transition to React Native

#188

Post by treelovinhippie »

FlashBlaze wrote: post #50
treelovinhippie wrote: post #37

Having just finished an 8 month Expo RN contract I'm excited to never touch it again. For personal projects keen to see how far I can go with Svelte PWA + Capacitor. Google + Microsoft should really double-down on PWA apps. I think at one point Microsoft was crawling the web and automatically listing any PWA in their app store. If that became the norm then maybe Apple will make their PWA install UX less deliberately…

Are there any disadvantages of using PWA + Capacitor instead of RN? Did you use Ionic for it?

PWA + Capacitor would basically be a web wrapper with access to native APIs: https://capacitorjs.com/docs/v3/plugins

I'm chasing the holy grail of "build once, run anywhere". I want to basically use Svelte and Tailwind and spit out web, iOS and Android apps.

But I also want to use normal HTML components. RN, Flutter and NativeScript all have their own unique components which is another thing you need to learn.

Will see how far the PWA approach can go when I find the time.

Re: Transition to React Native

#189

Post by treelovinhippie »

macando wrote: post #58
treelovinhippie wrote: post #37

Having just finished an 8 month Expo RN contract I'm excited to never touch it again. For personal projects keen to see how far I can go with Svelte PWA + Capacitor. Google + Microsoft should really double-down on PWA apps. I think at one point Microsoft was crawling the web and automatically listing any PWA in their app store. If that became the norm then maybe Apple will make their PWA install UX less deliberately…

What were the issues with Expo and why haven't you ejected to vanilla RN?

They ejected toward the end but that just makes development more difficult, particularly the deployment process.

Expo is nice but the whole DX is just painful. The iOS Simulator will crash often. You need to do a hard 'expo start' relaunch often. What looks great in iOS will often be broken on Android. Trying to get pixel perfect UI and the desired UX is painful. Expo is full of bugs and limitations. RN is old and unmaintained.

Re: Transition to React Native

#190

Post by hardwaresofton »

mekkkkkk wrote: post #182
hardwaresofton wrote: post #13

Earlier quoted context omitted.

None of those! The real answer is Nativescript -- https://nativescript.org It doesn't get the buzz, and the ecosystem is somewhat old (it's surprisingly common to run into a repo that hasn't been touched in a year) but it's the superior platform to React Native and you get none of the capriciousness of the React ecosystem (if anything the Nativescript community might need a jolt). Nativescript is incredibly productiv…

What made you dislike Dart? I find it a highly inoffensive language.

In no particular order:

- The type system was essentially like java but perhaps even worse -- in a world with Rust, Haskell, Julia, Kotlin, Scala, and even Golang this seemed egregious.

- No algebraic data types (sum/union),

- class-based inheritance

- nullable values

- using exceptions instead of errors-as-values approach.

I know they worked hard on the language (rewrites are hard, there are some good talks on there about it, link @ end), but it's like they ignored all the progress in PL over the last like decade+. Anyway, continuing on:

- JSON serialization/deserialization[1] was like the worst parts of Go and the worst parts of Java (again this has to

- SQLite driver[0] couldn't be used off device. I found this out while trying to write tests that ran off-device. Now there's sqlite3[1] so maybe it's no longer an issue

- Dart2 was a played down rewrite of Dart1, with JS interop removed. Typescript is a better language than Dart.

- BloC is overcomplicated and was rolled out poorly at the time (this has more to do with Flutter than Dart). The state management patterns felt like unbaked react (flux pattern) v1.

All this said, Dart will probably be around for a very long time. Fuschia makes a LOT of sense for Google to continue pursuing, which uses Flutter. Dart could be worse, and I think it's good enough for a bunch of usecases. If it were me, I wouldn't even choose it over Nativescript.

The Boring Flutter Development Show[3] was/is fantastic, I watched it religiously when I was learning and trying out Flutter -- having a big backer like google means there are always going to be dedicated resources and smart people behind Flutter which honestly probably matters more in the long run than Dart being a shit language. As Golang has shown us, you can just iterate to having a good language.

Feels like Dart2 has it's base to build from now, and I don't like the places it's started, but it will probably continue to succeed. At the very least you won't see bad PR about it, because most people who are willing to tweet about it are invested in it's success or want jobs at Google someday, and there is dedicated money for "dev rel".

Seeing Sony embrace flutter for embedded things is pretty big as well[4]. Sony has a surprisingly strong track record of making technologically competent products:

- PS Vita (generally regarded as ahead of it's time)

- Sony SmartWatch 1 & 2 (I owned both, they were ahead of their time, and were very good quality, easily hackable)

- Sony XPeria phones & tablets (embraced open source and easy bootloader unlock, I own a tablet that I'm extremely happy with)

[EDIT] - Separate some points about the language, also add a link to the strange loop talk on the rewrite[5]

[0]: https://pub.dev/packages/sqflite

[1]: https://pub.dev/packages/json_serializable

[2]: https://pub.dev/packages/sqlite3

[3]: https://www.youtube.com/watch?v=qXAUNLWdTcw&list=PLjxrf2q8ro...

[4]: https://github.com/sony/flutter-embedded-linux

[5]: https://www.youtube.com/watch?v=WjdrUphF5l4

Post reply on HN