[HN Gopher] Transition to React Native
___________________________________________________________________
Transition to React Native
Author : northstar702
Score : 163 points
Date : 2021-05-15 01:41 UTC (21 hours ago)
(HTM) web link (blog.coinbase.com)
(TXT) w3m dump (blog.coinbase.com)
| SilurianWenlock wrote:
| Why does all this stuff have to change so much?
| sigmaprimus wrote:
| Just in time to handle the "Huge Increase" in withdrawls I
| suppose.
| jb775 wrote:
| > _Thinking from this perspective led us to..._
|
| > _the average mobile engineer's velocity remained stagnant_
|
| > _this could dramatically reduce our overall staffing
| requirements...also have to deliver improved quality and
| performance for our customers_
|
| Honestly it sounds like Coinbase is quickly turning into a shitty
| place to work. Sounds like all the ingredients for a race to
| bottom in culture. It's so easy to tell that this was cooked up
| by primarily non-technical management types whose only actual
| "first-principle" is penny pinching.
|
| _Obviously_ you can get work done faster across multiple
| platforms on a per-engineer basis if you use a single technology.
| The cost of that speed is quality to the end user, and being in a
| perpetual state of "1 step behind" the capabilities of native
| app development. There will be regular instances of shoehorning
| in functionality as each underlying platform makes updates to
| their respective operating system. The unforeseen issues are that
| their engineering department will eventually turn into a
| technology echo-chamber...and this close-mindedness in regards to
| technology will likely lead to losing out on top engineering
| talent.
|
| Also, expecting ever-increasing velocity for each employee is
| insane. (not to the penny pinching execs tho) There's a finite
| amount of time and mental energy a human has each week. It's one
| thing to say you want to build software that can accommodate
| massive business growth...but it's another thing entirely to
| represent that by measuring rate of acceleration of velocity per
| engineer. That in and of itself isn't scalable.
| JMTQp8lwXL wrote:
| > being in a perpetual state of "1 step behind" the
| capabilities of native app development.
|
| For a basic CRUD app with simple data visualizations, this
| doesn't seem to be a huge issue compared to apps that might
| need to take advantage of whatever new capabilities arrive on
| mobile phones, though those have largely plateaued in recent
| years.
| reducesuffering wrote:
| And look at what Shopify CEO just said:
|
| "But we all have to re-qualify for our jobs every year. The
| red-queen race of Shopify's historic 40% or better growth is
| that everyone has to show up at least 40% better every year to
| qualify for our current jobs. I expect you to hold yourself and
| your teams to this standard."[0]
|
| [0]https://archive.is/Hql0j#selection-2991.215-2991.490
| Softcadbury wrote:
| I'm never touching mobile development and especially React Native
| again!
|
| I'm a web developer and a few years ago, I had the opportunity to
| develop a mobile app. What a nightmare...
|
| Among the new versions of React Native or Gradle breaking
| everything, all the npm packages suddenly not maintained anymore,
| the virtual phones not always starting or refreshing, the custom
| code you add to do in Java and Objective C because RN cannot do
| everything, and certainly the worst, the deployment on the app
| store.
| k__ wrote:
| I would do it again.
|
| Mobile is generally shit, but RN made it bareable.
|
| But, yes, much bigger overhead with all the native stuff. I'd
| recommend everyone to use web tech whenever possible.
| amelius wrote:
| Also, why support the duopoly if you can develop for the open
| web instead?
| ksec wrote:
| Sort of off topic.
|
| In your opinion, What is the best React Native App, that is also
| extremely popular which could be used to show case the tech?
|
| I think if you look at the best and you are already unimpressed
| that we could wait another few years for others to figure out
| first rather than jumping on to the hype. Sort of like Facebook
| demonstrating HTML5 during the start of the iPhone App Store era.
| dheera wrote:
| Is there a ReactCoin? #moon
| kvirani wrote:
| HN !== Reddit
| SatvikBeri wrote:
| I'm skeptical of most "we switched from X to Y" posts, but the
| thought process here seems pretty solid.
|
| * They had a much harder time hiring mobile developers than web
| developers, and per-person productivity was also lower
|
| * They prototyped an app before committing to a new technology
|
| * Similarly, they tested a change to the existing app before
| switching
|
| * They specifically invested time to cross-train people, and
| tested how long it took web developers to get productive on React
| Native
|
| * They interviewed Airbnb, who had also invested a lot of effort
| into React Native before dropping it
|
| * At each step, they considered whether to rewrite from scratch
| or incrementally switch that part of the codebase
|
| This makes a lot of sense. It shows the kind of careful
| consideration we should apply when seriously considering
| switching to a new technology.
| EvilEy3 wrote:
| > They had a much harder time hiring mobile developers than web
| developers, and per-person productivity was also lower
|
| That's what happens when you pay peanuts.
| frakkingcylons wrote:
| Coinbase does not pay peanuts, look at the compensation:
|
| https://www.levels.fyi/comp.html?track=Software%20Engineer&s.
| ..
|
| It's definitely competitive pay.
| intev wrote:
| Oh? You know everyone's salaries?
| EvilEy3 wrote:
| I don't see shortage complaints from FAANG companies.
| intev wrote:
| Are FAANG companies the median for tech salaries? If
| that's the case most companies are doomed.
|
| It's pretty common knowledge that FAANG pays really well.
| One of the big reasons people work there are for the
| extremely generous salaries. Everyone else is underpaying
| if you're comparing them to FAANG. Also by your
| definition, Apple and Amazon are notoriously cheap too.
| Really you're only comparing to Google, Facebook and
| Microsoft (less so).
| EvilEy3 wrote:
| > Are FAANG companies the median for tech salaries? If
| that's the case most companies are doomed.
|
| FAANG salary is the median for good developer salary,
| yes. After all, why would you work for less if you're
| good enough?
|
| > Everyone else is underpaying if you're comparing them
| to FAANG.
|
| You're getting somewhere.
|
| > Also by your definition, Apple and Amazon are
| notoriously cheap too.
|
| Pretty sure they're paying bigger salary than coinbase
| does. At least their product is more interesting than
| crypto dashboard, maybe that's how they compensate for
| "shitty" pay.
| intev wrote:
| I just compared their salaries on glassdoor. There seems
| to be quite a few data points. Their salary seems to be
| higher than Microsoft but lower than FB. Overall,
| comparable. Where are you getting this Coinbase is paying
| everyone "shitty" pay? I hope you have something...but
| I'm not holding my breadth
| deepsun wrote:
| >They had a much harder time hiring mobile developers than web
| developers...
|
| It's not hard at all to find mobile devs, just offer more
| money. Mobile devs cost more, that's right.
|
| But I think that's because mobile development is significantly
| harder (personal first-hand experience).
| jessepollak wrote:
| This is an excellent summary of our approach - thanks for
| writing it up :)
| jabo wrote:
| Would be great if Coinbase also contributes back to the React
| Native ecosystem, like how Shopify pledged to do. That would be a
| net positive for everyone involved.
| jessepollak wrote:
| We are doing this already and plan to increase the investment
| over time. Stay tuned!
| echelon wrote:
| HTML is the best cross-platform document and application
| specification ever conceived.
|
| It's a product of a very special place and time where companies
| were not able to succeed in growing their own locked-down
| fiefdoms. Microsoft got hammered by the DOJ, AOL gave way to
| better competition. It was a good time.
|
| About the time the DOJ stopped caring and members of Congress
| became invested in tech, a new device category arrived on the
| scene. It took over general purpose computing, becoming perhaps
| the only computer and gateway to the Internet for many.
|
| Two companies form a duopoly, and they look nothing like the web
| of the 90's and 00's. App developers have to write and maintain
| two separate code bases, go through app approval, and have to
| hold hands to get their software released. It's an asinine
| retreat from the freedom we once had.
|
| The web, too, has come under attack. The most popular browser is
| controlled by an ad giant that created an advantageous
| monoculture, removed ad blocking, and embrace-extended into
| things like AMP.
|
| We've taken the wrong path.
|
| The W3C should have written a native app spec, described native
| widget tool kits, and kept the duopoly at bay.
|
| We were all distracted as to what was really going on.
|
| Think about all of the wasted human productivity writing and
| maintaining two versions of the same software. Instead of working
| on actual problems, we have to doubly employ to satisfy the
| powers that be. It's so incredibly dumb that so many work so hard
| just so that two parties can soak up all the benefit. It's a
| fluke of evolution that wouldn't have happened if the regulators
| hadn't fallen asleep at the wheel (or bought into FAANG stock).
| petmon wrote:
| I disagree. An application platform establishes UI conventions.
| It's not "wasted productivity" to build software so that it
| participates in the conventions that users expect. That
| empowers users: they can do more with your app, by bringing
| their knowledge from other apps.
|
| The web erodes UI conventions. Find, bookmarks, back button,
| copy and paste, undo, select all, etc. are worse on the web,
| compared to 5 or 10 years ago. And those are just basic
| functionality, table stakes for any app. Web apps are making us
| all less computer literate: they do less, and so we expect less
| from our software. That's the wrong direction!
| [deleted]
| vmception wrote:
| 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 development role was 2
| years ago and every team (FAANG, Fortune 500, Series B startups)
| wanted something different and acted like that was the normal
| skillset to expect
| throw14082020 wrote:
| Most teams don't hire a "mobile developer", they hire an
| Android developer, and/or iOS developer, and/or React Native
| developer, and/or Flutter Developer. So unfortunately it
| requires some commitment, don't do all of them at once!
|
| - React Native: Easiest to learn, good build tools/ developer
| experience, good amount of jobs already. Unfortunately, React
| Native is naturally intertwined with JS/ react, so you'll face
| issues with the complex world of javascript. I won't say its
| slow, but it certainly doesn't work for all types of apps.
| Also, avoid Expo completely.
|
| - Flutter: Easy to learn, amazing build tools/ devex, very few
| jobs (though predictably growing). If you become a flutter
| developer, you can be confident the company that hired you has
| thought about the tech stack a little more. React Native is the
| defacto for quick and dirty apps (MVP), and Flutter is for more
| of a company thats investing in its technology, I would say.
|
| - Android: Okay to learn, very good build tools/ devex, more
| jobs
|
| - iOS: hardest to learn, okay build tools/ devex, fewer jobs
|
| Difficulty is measured by how long it would take you to
| implement a feature you don't know, or just my rough feeling of
| building apps in all platforms, some of them professionally. Im
| very unusual to know all 4, and I have not met anyone else like
| me in my _jobs_.
|
| I would pick Flutter, because you're not optimising for today,
| and Flutter will be there in 5 years, regardless of how big
| https://killedbygoogle.com/ gets E.g. The tech lead for Flutter
| worked on HTML, CSS, WebSockets.
| SilurianWenlock wrote:
| Is react native is easy to learn?
| geonic wrote:
| Could elaborate on why to avoid expo? I found it super easy
| to use when I dipped my toes into RN development. Also, what
| alternative are you suggesting?
| halfmatthalfcat wrote:
| If you do use Expo, you should eject as soon as possible
| and pick which libraries you explicitly want to include. I
| reduced my app size by like 60% after ejecting because of
| all the stuff I didn't need that was included.
| rhodysurf wrote:
| I'll give two reasons. First, code bloat, expo bundles
| allllll their default libraries along with your app when
| packaged for release. Second, is flexibility. The most
| powerful part of react native is that it displays native
| views and with expo you are only given the native
| functionality they bundle for you, you cannot create your
| own.
|
| The alternative is to just not use expo and add libraries
| as you need them. Then you can do things like add widgets
| and watchOS functionality to your app on iOS using native
| code. Or create your own custom native views and plugins
| that bind to the native sdks, giving you an edge over other
| bland RN apps. I love RN but only when used correctly.
| rhodysurf wrote:
| 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.
| kitsunesoba wrote:
| 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 have odd gaps in functionality, 1 that's
| the new shiny thing that's too immature for production use,
| and none of which are generally "right".
| throw14082020 wrote:
| > 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.
| throw14082020 wrote:
| 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 code because it is open
| source. If you find a bug in Apple's library, what do you
| do?
|
| - There are more developers, more stack overflow
| questions/ answers and more resources on the internet in
| general for Android. So even when Android has edge cases/
| backwards compatibility issues, its more likely than iOS
| that someone has written about it.
|
| - Apple tooling is bad: Xcode is not a good IDE to put it
| lightly. It gets 3 stars on the App Store. 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. Most warnings for your code won't show up until
| you try to build it, therefore the feedback loop is
| extremely slow. Many iOS developers I've known admit they
| do not like Xcode. To upload your iOS app to the app
| store, you upload _gigabytes_ of binaries. Code
| refactoring features do not exist on Xcode. Android
| Studio is one of the best IDE 's I've used, and
| constantly adds support for more features: WorkManager
| inspector, deploy/debug multiple devices at once. Also,
| new features come out for Android Studio all the time,
| and Xcode seems to have not been updated with features
| that benefit me for a long time. Jetbrains IDEs generally
| work straight off the bat, and I'm very happy to see
| AppCode (Xcode competitor by Jetbrains) available, though
| it is thoroughly buggy at the moment, I still use it
| because writing code is nicer in AppCode.
|
| - Basic things in the apple ecosystem are broken/ buggy:
| e.g. New developers in a team will have issues signing
| their application with the company team, the trick/ fix
| is to remove/ add a Xcode/ iOS capability to the project,
| and remove it immediately. Then signing will work.
| Signing the app is literally the first thing that needs
| to be done, why is this not fixed?
|
| - Swift is much nicer than Objective-C to program in, but
| its not as nice as Kotlin. I don't want to get into
| programming language comparison (im sure there are
| connoisseurs here who can), but my opinion of reading
| Swift code is they are less readable and results in
| unusual architecture. Swift apps are also slower and
| bigger than Objective-C apps. Some Apple APIs are also
| designed in a painfully complicated way. It seems like
| they do not get much feedback from developers about their
| APIs, whereas Android is constantly getting feedback and
| improving. Some developers complain that Swift has
| changed, breaking older Swift code. I haven't _heard_
| this from Kotlin developers.
|
| Sorry that felt like a rant. In the end you've can choose
| based on
|
| - Comfort: Android is much more ergonomic for the reasons
| above
|
| - Developer competition: You'll be competing with more
| Android developers worldwide: Android is more than 85% of
| the smartphone market
|
| - Money: iOS costs $100 annually (not much but if you're
| starting out your first app, maybe it is). The upside is
| if you live in a rich country, many people use iPhones,
| and they also tend to spend more money on the app store.
|
| - Market trends: iOS has added ATT/ privacy features.
| They've also got powerful chips but it seems like no one
| has learnt how to use them yet. They are ahead on
| hardware (M1, A14), they've got great market share in
| Western countries, and are poised to take even more with
| recent developments.
| modernerd wrote:
| 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.
| WrtCdEvrydy wrote:
| React Native or Flutter depending on your desired target.
| cercatrova wrote:
| Are you optimizing for jobs/interviewing or for learning? If
| the former, just do native in Kotlin, if the latter, I like
| Flutter personally.
| occz wrote:
| >If I wanted to do android development again, I have no idea
| which skillset to optimize for
|
| I prefer native, but I'm pretty biased, to be fair.
|
| In native-land we're doing more or less all of our development
| in Kotlin these days. It's a really nice language. XML-based
| Views are still where it's at, but Google have been developing
| a new view toolkit called Jetpack Compose which is very likely
| where we are going next. It's based on the reactive view-
| paradigm popularized by React, but I think it's getting a lot
| of benefits from moving second and having been able to learn
| from what React has done. Also, it's not JavaScript, which is a
| big plus.
|
| >Are we doing Model-View-Presenter (MVP) no matter which? Or
| are we still doing Massive-View-Controller (MVC backronym)
|
| We're doing MVVM these days. Or whatever you would like to call
| the following description:
|
| >There's an object called the ViewModel which survives activity
| recreation, from which in your view-layer you subscribe to some
| state. The ViewModel also facilitates access to the Model-part
| of your application with state and network access and whatever
|
| >Are there adequate networking, database ORM, and image loading
| libraries for all frameworks?
|
| I'd say so, yes. The Jetpack-family of libraries by Google are
| all pretty good.
|
| For networking, you can use Retrofit by Square For database ORM
| you can use Room by Google. There's also SqlDelight by Square
| if you like a lighter approach to database interaction. For
| image loading the most recent contender is Coil, but Glide also
| works pretty well.
|
| >Last time I interviewed for any mobile development role was 2
| years ago and every team (FAANG, Fortune 500, Series B
| startups) wanted something different and acted like that was
| the normal skillset to expect
|
| I can't promise you that the entire android development scene
| has aligned on anything entirely yet. This may very well still
| be the case.
| hardwaresofton wrote:
| 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 productive and you can bring
| along frameworks that do their best to move the work to compile
| time (like Svelte).
|
| I think the best options form a spectrum like this:
|
| (PWA)-------(NativeScript/React
| Native)------(Flutter)------(Kotlin/Alternative iOS
| environments)--------(Objective-C/Swifth/Java "fully native")
|
| If you choose essentially anything on the right side of
| flutter, performance will be relatively good out of the gate,
| and anything to the left (including flutter) and you have to be
| a little careful.
|
| I think Flutter is actually the worst of both worlds because
| I'm heavily biased against Dart after using it, _but_ it is
| obviously backed by a behemoth, and the render-every-pixel
| model makes it _insanely_ portable. If you want to write-once-
| run-everywhere (generally a bad idea, but if it works for you
| who cares), then flutter is the best by a longshot.
| mekkkkkk wrote:
| What made you dislike Dart? I find it a highly inoffensive
| language.
| vmception wrote:
| NativeScript is obviously the wrong answer
|
| I want to pass interviews and do android development for
| employers
|
| Thanks for the spectrum, which one would I lead with and
| expect to answer the most questions in and complete project
| time trials on
| hardwaresofton wrote:
| > I want to pass interviews and do android development for
| employers
|
| Definitely learn plain old Android-style Java, with the
| usual tools (android studio, etc) then. Most shops are
| going to be that, and if you want to pick up Kotlin for the
| shops that are a step ahead then do that.
|
| > Thanks for the spectrum, which one would I lead with and
| expect to answer the most questions in and complete project
| time trials on
|
| React Native in this scenario, unless the company already
| has at least one (and if it's one they have to be VERY
| competent) mobile engineers on both major platforms.
|
| Fully native is the best results (there's essentially zero
| limitation) but is the most specialized work. PWA is the
| easiest, but paradoxically needs a tiny bit of
| specialization to get native enough that the business isn't
| embarrassed. Also, with PWA there's lots of hard limits on
| what the app can do (notifications are a particular
| bugbear).
| whoisjuan wrote:
| I believe what you say about NativeScript but there's not
| enough momentum in that solution. Learning NativeScript will
| give you access to a way smaller pool of projects or
| companies you can work for.
|
| I think most developers would prioritize employability +
| traction/community/documention. There's not even a comparison
| there. React Native is the superior solution.
| hardwaresofton wrote:
| Yeah -- I do agree with you, React Native is going to see
| the majority of the love.
|
| I would like to point out that NativeScript _works_ --
| people mostly don 't make buzz about it but it's out there
| powering apps that are delivering value, I've used it
| myself for a client and it was fantastic.
|
| React Native is the superior solution only if you
| prioritize employability/traction/community (I disagree on
| documentation, NativeScript's documentation is excellent),
| but if you need to get an application out but are turned
| off by the React crazy-land and bad performance of React in
| a mobile context, give NativeScript a try, it's the better
| platform in a technical sense -- it has things React Native
| doesn't.
| ryndshn wrote:
| isn't using RN over native ultimately just optimizing for their
| developers and not the product? RN is great for start-ups that
| need to build and launch quickly for multi-platform, but for an
| established giant like Coinbase it seems like a misstep.
| EvilEy3 wrote:
| Just when there are two arguably most important migrations in
| mobile world happening(Compose and SwiftUI), they decided to
| migrate to inferior tech.
| itsjzt wrote:
| Arent they just a copy of React.js? But in native
| intev wrote:
| *According to you. Every 5 or so years there's an "important"
| transition happening. That's tech. There's been many stories
| written about companies that live on the bleeding edge. I don't
| remember any of them ending particularly well.
| EvilEy3 wrote:
| > Every 5 or so years there's an "important" transition
| happening.
|
| Name at least one change in Android SDK that can come close
| to revolution that is Compose. And same for iOS/Mac and
| SwiftUI.
|
| Compose and SwiftUI are doing to mobile what React did to
| web. It arguably single most important change that happened
| since the inception of mobile platforms.
|
| > There's been many stories written about companies that live
| on the bleeding edge. I don't remember any of them ending
| particularly well.
|
| What?
| intev wrote:
| I agree the current one is a major change but it's not
| mature yet. It hasn't stood the test of time. Twitter was
| built on RoR when that was the coolest new thing to build
| things on and Uber's booking engine was on Node.js when
| everything was being run on Node. I'm sure there's more I'm
| missing. .
| EvilEy3 wrote:
| You seem to be missing my point. Compose and SwiftUI are
| React of mobile world.
|
| React certainly stood the test of time.
| intev wrote:
| That's to be seen. I very clearly remember when Angular
| first came out, that was clearly the way to move forward.
| People switched in droves. Then React came along and
| changed everything. React has also remained more popular
| than Angular has, but we didn't know that till years
| later. Some chose to remain in Angular (my old company)
| thinking it will blow over and we can swap to the next
| paradigm instead. Turned out React was flexible enough to
| last a while. Somehow you can perfectly see this is the
| React of mobile and not Angular?
| EvilEy3 wrote:
| Compose is literally React. It has different execution
| model, but the same programming model.
|
| Maybe you should first read about subject before arguing
| for the sake of arguing?
|
| https://speakerdeck.com/lelandrichardson/react-meet-
| compose?...
| intev wrote:
| I don't care that it's literally React. The react model
| doesn't work for every platform. I do know the subject.
| I'm no expert but I've lived long enough to know that one
| paradigm on one platform is not the solution for all
| platforms. Stop making assumptions.
| EvilEy3 wrote:
| Name one where it doesn't work.
| pixel_tracing wrote:
| Unclear on what you mean here React will always be
| inferior to SwiftUI and Compose. All Apple has to do is
| release a new port of Javascript<Whatever> version 2 with
| limitations and boom goodbye React
| swyx wrote:
| Does anyone know if Flutter was in the consideration set? It's
| gaining some momentum as a slightly more stable crossplatform
| ecosystem to React Native. but of course, there is the prospect
| of Google and Dart.
| halfmatthalfcat wrote:
| To be honest, it's only gaining momentum because of the PR
| behind it. I've yet to see or hear of a major hybrid app
| getting shipped in Flutter.
| surajrmal wrote:
| https://flutter.dev/showcase seems to show a lot of major
| applications using flutter.
| k__ wrote:
| I know a few freelancers that specialized in Flutter the last
| year.
|
| But I wasn't convinced either.
| jessepollak wrote:
| We did consider Flutter, but (1) we already had a very strong
| javascript talent base that we wanted to leverage; (2) at the
| time when we made the decision, Flutter was still relatively
| early in its lifecycle.
|
| That said, we've spent a lot of time talking with teams using
| Flutter and we think it's awesome!
| halfmatthalfcat wrote:
| Could you say which teams you were talking to? Curious about
| companies adopting Flutter and why over other solutions.
| cedel2k1 wrote:
| There are no winners when fighting over technologies.
| macando wrote:
| With regards to UI elements and layouts nothing beats React and
| Flexbox CSS on mobile. Also, when it works correctly Expo is a
| pure bliss.
|
| C'mon iOS devs you can't tell you enjoy the byzantine layout
| model of the native iOS apps and working in xCode.
|
| Some parts of React Native are problematic but creating screens
| is simple and intuitive.
| jamil7 wrote:
| SwiftUI is higher level again for layout and I would pick it
| over flexbox CSS on mobile any day.
| macando wrote:
| SwiftUI is a strong competitor I admit.
| treelovinhippie wrote:
| 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
| clunky.
| FlashBlaze wrote:
| Are there any disadvantages of using PWA + Capacitor instead of
| RN? Did you use Ionic for it?
| macando wrote:
| What were the issues with Expo and why haven't you ejected to
| vanilla RN?
| TheMagicHorsey wrote:
| I wonder if they considered Flutter. I joined a startup that's
| using React Native and I have to say, I dislike all the
| complexity around state management, styling in separate CSS
| files, JSX syntax for components, etc.
|
| I much prefer the unified approach of Flutter (everything is in
| Dart and not scattered in 3 different places) and batteries
| included component library.
|
| Not to mention, if you have a small team, Google Cloud Firestone
| plus Flutter is a very productive and elegant way to launch an
| app with a small team ... or even solo.
| rvz wrote:
| The Airbnb / Udacity story is simple. Brown-fielding RN is not
| the way to go.
|
| Here's where green-fielding _would_ have also made sense (and a
| difference) by using a recent example of a new famous product
| that is NOT using cross-platform tech like React Native /
| Flutter, and that's Clubhouse.
|
| Last year, they launched their mobile-only native iOS app and
| everyone was wondering about where the Android app was. It was
| finally released this month and it took them a year in total. By
| that time, the hype was already dead, everyone already moved on
| and didn't care about their app since their competitors copied
| them to death (And took the Android users with them.)
|
| Had they used React Native or Flutter to build their app, they
| would have been able to release both platforms quicker and at the
| same time and become feature complete rather than releasing the
| Android app feature incomplete with iOS and the Android users
| still waiting for a year and leaving for the competitors instead
| as the hype already died.
|
| Now they are stuck with implementing their features on both
| platform _twice_. Discord already cloned them as a feature very
| quickly (using React Native) and now Clubhouse has to catch up
| with them to bring their lost users back. Given how fierce
| competing with social networking / messaging companies are, I do
| not think using native in 2020 / 2021 for a new product was a
| good idea in this case and green-fielding a RN or Flutter app
| would have made sense to iterate quickly.
| _fat_santa wrote:
| Many comments here are comparing this transition to the one
| Airbnb did a few years back. These two transitions could not be
| more different.
|
| Coinbase decided to greenfield their new apps, Airbnb (attempted)
| to brownfield it. I've worked with a number of clients that have
| gone down the same path that Airbnb did, from a business
| perspective it makes perfect sense, keep what you have and slowly
| move over, but the technical reality is this will be a complete
| dumpster fire and you will probably fail.
|
| When you try to convert a native app to React Native everything
| that makes React Native wonderful to work with just seems to
| break. Hot reloading either barely works or not at all, load up
| times increase exponentially, the app just becomes a pain in the
| ass to work with because nothing seems to work like it should.
|
| Whenever companies propose this I always shoot down the idea and
| recommended a rebuild in React Native from the ground up. Doing
| so will take just as much time as browfielding because when you
| try to do a native -> react-native conversion it always seems to
| go south somewhere, either slowness, having to write 3x the code,
| or other problems.
| danielrhodes wrote:
| There's a huge incentive for the company to invest in this.
| Being multi-platform has a huge cost to small and big companies
| alike, as the blog post was alluding to.
|
| The way I see it: in the early days of the web, JavaScript was
| very slow and browsers were operating on weak CPUs. But there
| was a turning point and suddenly JavaScript was now fast enough
| and Web 2.0 was born.
|
| A similar thing is happening with React Native. It is kind of
| slow on older phones, and it felt very kludgy when it was first
| released. But things have gotten better and most important of
| all: phones have gotten substantially faster.
|
| You still have to learn how to make high performance React
| Native apps, compared to React in the browser where it's more
| forgiving. But this is no different than native. So I think
| there is reason to believe it has gotten to a point where this
| could be a long term decision.
| Ozzie_osman wrote:
| The airbnb transition also had (from what I heard) a lot of
| politics around it. Often the things that make or break large
| projects aren't necessarily technical but human. For instance,
| if you hire a ton of native developers and force them to move
| to React Native without getting buy in from them, you're
| probably bound to fail.
|
| There will always be technical challenges with any large
| project. But getting buy in from the right people can make
| those problems surmountable.
| raspasov wrote:
| Right on point. I have done a lot of React Native but never
| tried to mix native + React Native (with the exception of the
| occasional native feature in a mostly RN project).
|
| Mixing an old native project with RN, doing a so called "slow
| transition" sounds like a really bad idea. Data communication
| between the native part and React Native will become an issue,
| you're effectively going to be running a mini distributed
| system within your device. There's probably 100 other problems
| that I can't even start to imagine. Perhaps a super
| experienced, world class expert in both JS and mobile
| development + runtimes can pull it off but I wouldn't be
| comfortable trying to do it (been doing mobile development
| directly since 2016 and have been close to mobile dev since
| ~2011). Re-write is a better option.
| ryndshn wrote:
| if i remember correctly, Airbnb had many issues with RN that
| were not related to their incremental migration, such as the
| issues they had with things like debugging, where it was almost
| impossible to fix certain bugs due to RN using different JS
| engines depending on platform and context (for ex running with
| a debugger causes RN to use V8 whereas running locally on iOS /
| Android it uses JavaScriptCore or Hermes, respectively). RN is
| awesome but imo has some pretty serious pain points.
| raspasov wrote:
| RN used to have a lot of issues years ago (~2015-2016 or so)
| with different layout rendering between iOS and Android.
| Since they re-wrote their layout engine to be the same
| codebase across Android and iOS this has been 99% fixed in my
| experience. You might very occasionally run into a difference
| of some sort but it will most likely be minor. Of course, I
| would say if you've never done a RN project before and you
| plan to release both iOS and Android, please DO test your app
| frequently on both as you code along. If you complete 90% of
| the code on, say, iOS only and then try to run it on Android,
| chances are you'll run into more WTH problems than if you
| were checking along the way.
| ryndshn wrote:
| none of the issues i described are different now. RN on iOS
| still uses JavaScriptCore by default, Android uses Hermes,
| and it still uses V8 if debugging, meaning it's possible
| you'll have some super weird edge case bugs. in Airbnb's
| situation i believe they said it was almost impossible to
| pinpoint the issue due to the differences in these engines.
| it's unlikely, but still an unavoidable thing that could be
| a serious roadblock
| raspasov wrote:
| I've done and ran 2 medium sized apps on both iOS and
| Android and have never ran into such problems. While not
| impossible, that's akin to saying that if you run the JVM
| on MacOS vs Linux, there's a chance of different
| behavior. Possible, but unlikely. It shouldn't be a show-
| stopper for most situation.
| ryndshn wrote:
| ehh, not really. JVMs are all developed under the same
| roof but JS engines are a little more distributed and the
| spec has a little more room for interpretation. i agree
| it's unlikely, but still not ideal
| raspasov wrote:
| Yes, fair enough. Not a perfect analogy.
| nwienert wrote:
| Hermes runs on iOS now and besides missing Intl, I've not
| had any problems with it and flipper let's you debug
| hermes.
| macando wrote:
| What a trope that AirBnB story has become. They mixed their
| gigantic native codebase with React Native code.
|
| Mixing native and React Native = bad.
|
| Doing pure React Native (for everything but ultra high-
| performance and apps that interact tightly with hardware) =
| good.
| _fat_santa wrote:
| I remember there were a ton of articles and hot takes around
| that time that dunked on RN with zero context, essentially
| saying that RN was dead because Airbnb couldn't crack it.
|
| I feel like all those takes completely misunderstood or
| ignored Airbnb's technical constraints and the underlying
| reasons.
|
| Anyone blamed it on the library. Not the dumpster fire
| implementation that ultimately killed the venture
| jamil7 wrote:
| Yeah a lot of it is context. I got the feeling from those
| articles that airbnb has some really strong platform
| specialists and if you already have two teams of people
| like that you can likely get more out of letting them focus
| on their respective platform.
| EvilEy3 wrote:
| > Hot reloading either barely works or not at all, load up
| times increase exponentially,
|
| It works like this even on hello world apps.
|
| The only platform where Hot Reload works reliably on mobile is
| Flutter.
| itsjzt wrote:
| You should check out next.js's live reload
| EvilEy3 wrote:
| On mobile?
| rapsey wrote:
| How does the app perform now?
| EvilEy3 wrote:
| Android performance is garbage. Source: just downloaded app.
| intev wrote:
| I call BS. I just downloaded it and it works fine. Literally
| every single one of your comments has it out for this
| transition. I trust my own experience and their data.
| EvilEy3 wrote:
| Try to create account, input some gibberish, see "something
| went wrong" dialog and close it.
|
| And define "fine" first. If you mean that it works, sure.
| But it works slower than truly native application, like
| Telegram.
| intev wrote:
| By "fine" I mean it does what I expect it to, doesn't
| throw bizarre errors and hasn't crashed (so far). Could
| it be faster? Sure. Does it bother me? Not even the
| slightest. So many apps I use regularly run much slower
| than this.
| EvilEy3 wrote:
| This is the error that most web devs make. Their
| definition of fine is so low, that they can't comprehend
| reasoning why web tech is inferior on mobile.
| intev wrote:
| LOL. So now my standards are not high enough? Everyone
| should program in C. Definitely one of the fastest. So we
| can all serve your highest standards.
| EvilEy3 wrote:
| Nope, on Android you'll have to interface with native
| toolkit anyway. Even if you write everything in C. Just
| follow the platform instead of fighting it.
| htormey wrote:
| Theirs an image in the article that compares business and
| performance metrics before and after:
|
| https://miro.medium.com/max/7200/0*L6GxhXWiTckqwMYL
|
| Ratings and some perf metrics(start time) improved, no
| regressions.
| rapsey wrote:
| Ok but was it good before the rewrite? :)
| mcny wrote:
| I don't know anything about react native and from my (limited)
| experience with titanium, I'm not a fan of js based "native"
| apps.
|
| That being said, I didn't know the iOS app was react native. I
| don't use coinbase much but it feels pretty good.
|
| I'm wondering in hindsight if titanium wasn't so bad and I just
| didn't have a firm enough grasp on js and CSS.
| slow_donkey wrote:
| IMO before react native came on the scene there were no well
| performing hybrid app frameworks except possibly xamarin. So
| it likely wasn't your fault
| pupdogg wrote:
| I've done iOS native development only and was exploring
| transitioning to RN due to single code base/multi-platform
| support. However, one of my constraints for target customer
| market is the final app size. Right now, I have a native iOS app
| talking to our API and using AVKit/MapKit with a final complied
| size of 3MB. Can a RN project yield similar size app?
| ashishb wrote:
| Let's wait for a few years and they will make the Airbnb and
| Udacity style U-turn. Even Facebook doesn't use react native as a
| primary technology for building Messenger, Instagram or Facebook
| app.
|
| Shameless plug: my opinionated beliefs
| https://ashishb.net/all/react-native/
| kumarm wrote:
| 2025: Coinbase successful transition from React Native to Native
| apps.
|
| Seriously haven't we seen how this play-out way too many times
| already?
|
| There is absolutely no incentive for Apple and Google to make
| sure ReactNative controlled by Facebook is the way to develop
| apps for their platforms. Till that is true, its absolutely nuts
| for any company other than facebook to develop their apps in
| ReactNative.
|
| Edit: Example:
| https://softwareengineeringdaily.com/2018/09/24/show-summary...
| codingslave wrote:
| React native is just better, and it has been for years.
| EvilEy3 wrote:
| Better than what?
| ec109685 wrote:
| They addressed Airbnb's experience in the blog post. In
| addition to abandoning React Native, Airbnb created their own
| templating language best suited for their app and rolled it out
| to both platforms so they didn't have to handspin every screen.
| EvilEy3 wrote:
| No, they didn't address anything. They only said that it
| didn't work for Airbnb because it wasn't greenfield. The real
| reason it doesn't work out, is because React Native is a
| dumpster fire. If you really want to go cross platform way,
| then go with Flutter or wait for JetBrains Compose to target
| iOS.
| intev wrote:
| Oh yes. You know best. Their CTO did no due diligence
| before making such an important transition. They didn't
| even bother talking to AirBNB about their experience.
| Nothing has changed since AirBnB made their transition. You
| my friend, know all the ins and out more than the silly,
| tech illiterate Coinbase team.
| EvilEy3 wrote:
| > Their CTO did no due diligence before making such an
| important transition.
|
| He certainly didn't do enough of it, right. They have
| traded long term prospects for short one.
|
| In the long run you'll have more issues with React Native
| than upsides.
|
| They cited issues with hiring native mobile devs, well
| now they've made it even harder for themselves. Since
| they need to find devs who know both native and React
| Native. And those guys cost even more than pure native
| devs.
|
| That's actually a good idea for a career. Learn native,
| React Native and make big buck from companies that are
| stuck with React Native.
| intev wrote:
| > He certainly didn't do enough of it, right. They have
| traded long term prospects for short one.
|
| This is extremely presumptuous to say the least. It
| assumes they didn't do enough _and_ that you know more.
| EvilEy3 wrote:
| Presumptuous is to think that their decision is
| impeccable _and_ that I don 't know shit when you have no
| idea who I am and what I do.
| intev wrote:
| I never once said that their decision is impeccable. in
| fact I mentioned it probably has draw backs. What I did
| say was _you_ don 't have enough information about the
| decision making process and thoroughness. They cared
| enough to talk to the AirBnB devs which highlights how
| thorough they attempted to be.
|
| > I don't know shit when you have no idea who I am and
| what I do.
|
| Your words not mine. Re-read all of my responses without
| your blind hatred for what they did. All I am asking for
| is to give them the benefit of the doubt that they did
| their research and made a good decision. Of course it's
| clear you find that incomprehensible.
| EvilEy3 wrote:
| > Your words not mine. Re-read all of my responses
| without your blind hatred for what they did. All I am
| asking for is to give them the benefit of the doubt that
| they did their research and made a good decision. Of
| course it's clear you find that incomprehensible.
|
| I think you're right. In their case this was the best
| course of action, unfortunately. Not every company has
| capacity to do things right.
|
| React Native does suck big donkey though.
| nmfisher wrote:
| 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).
| gfarah wrote:
| 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 cool
| reusing some things from the mobiles apps, it still needs to
| improve in performance and stability.
| mikevm wrote:
| 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.
| eagsalazar2 wrote:
| We do a lot of RN but recently had a large project that
| required Flutter. We were all curious because you hear good
| things about Flutter but, in the end, no one thought the dev
| experience of Flutter was better than Typescript+RN. One data
| point.
| raspasov wrote:
| The Coinbase iOS app looks nice and the attention to detail looks
| to be at a good level. It's a nice surprise that it's written in
| React Native. Well done to their team!
| ardit33 wrote:
| Two years from now, it will be 'why did we decide to move on from
| React as it was not working out' blog post
|
| It is like the circle of life with native vs semi-native (which
| react is), and just html apps.
|
| Teams build a fast new version, looks great as it is new code,
| without much baggage, and over time it gets bloated and people
| complain that it takes too much to debug/develop on it.
|
| Some people in a internal team write a new demo/prototype in a
| new tech, some director/vp buys in, and the circle of life
| continuous, in the new tech, and a new blog post is made again.
|
| At Spotify, we had few interactions of these, back and forth...
| like clockwork.
|
| Ps. If you are junior engineer reading this, don't pay too much
| attention of these type of blog posts, as they usually are just
| PR for internal teams, so someone gets a promotion. Just work on
| the tech stack that you like working on, and exites you the most.
| Especially for personal projects. Don't do something because
| everyone else is doing, but do it because you do enjoy it.
| dragosmocrii wrote:
| Your comment reminds me of http://boringtechnology.club/ :)
| Bellamy wrote:
| RN is better from the business point of view. I have noticed
| that some devs don't like RN, because they can't write native
| code or they only can write native code to Android/iOS. So they
| can't do everything and are disappointed.
| xyst wrote:
| The airbnb cycle
| raspasov wrote:
| Have you worked with React Native or done other mobile
| development?
| baron816 wrote:
| I think it's possible to go native -> RN -> native without the
| whole being a failure. You may have a product that hasn't
| gained the traction that it should have because you have to
| build everything twice and just don't have the engineering
| resources to support that adequately. You move to RN, build out
| a whole new suite of features, gain momentum (and lots of
| revenue), and are then able to switch back to native now that
| you can afford to hire enough engineers to fully support each
| team.
|
| Might Coinbase be rich enough to support native iOS and Android
| teams? Probably. I'm not trying to litigate Coinbase's
| decision.
| ec109685 wrote:
| How utterly dismissive. They rebuilt their apps, increased the
| number of developers able to contribute to their codebase and
| improved metrics. That should be praised.
|
| Their point about brownfield development was a good one. In my
| experience the intersection between RN and Native (both code
| and people) is the biggest impediment.
| ardit33 wrote:
| AirBnb went exactly through this transition and back...
| Coinbase is just behind by a couple of years. Perhaps
| Coinbase' engineers, are better, or a different breed from
| Airbnb' ones, or perhaps React Native has matured more since
| 2019. Can't give you an answer.
|
| Linkedin had the exact iteration years ago. They had one of
| the first NodeJS Apps, driven mobile apps, and made some
| glossy block posts, praising it. Then quietly went back to
| native. Facebook went back and forth with HTML 5 sound the
| same time, etc.. etc..
|
| It is like seeing the same movie over and over, with just
| some minor plot twists, they tend to play out the same. Since
| the Java's Applets promise 'write once, run everywhere', this
| story instead has been always the 'write once, debug
| everywhere'.
|
| "Sunsetting React Native Due to a variety of technical and
| organizational issues, we will be sunsetting React Native and
| putting all of our efforts into making native amazing."
|
| https://medium.com/airbnb-engineering/sunsetting-react-
| nativ...
| tshaddox wrote:
| What then do you think is the "correct state" that they
| should skip all the experimentation and jump straight to?
|
| Personally, I suspect the reason that big teams are
| experimenting (and finding successes despite some failures
| and trade offs) is because this is a difficult problem that
| isn't solved and requires ongoing creativity and
| experimentation.
| ardit33 wrote:
| I am not dismissing React Native, and saying it is a bad
| technology, (it is pretty good for a certain type of
| apps) and it can work for some.
|
| If you see my end note, "to more junior engineers", don't
| use React Native in your project because X company is
| using it, and it must be trendy.
|
| Use it only if you do enjoy using it. If you are already
| good/skilled at building native apps, then you might not
| need it at all.
| macando wrote:
| AirBnB tried to mix their big native codebase with React
| Native and end up with a Frankenstein.
| SatvikBeri wrote:
| The article specifically mentions that they spent a lot of
| time interviewing AirBnB about their experience and links
| to the same post.
|
| "If you've read Airbnb's excellent Sunsetting React Native
| article, these challenges may sound familiar. We spent many
| hours speaking with engineers from Airbnb and trying to
| learn from their experiences. We're grateful to the team
| for sharing the details of their journey, as the
| information was invaluable in deciding the best path for
| Coinbase. One of our key takeaways was that the brownfield
| approach seemed to be core to many of the challenges they
| faced. While the idea of incrementally migrating is at
| first glance appealing -- leveraging the benefits of React
| native for new features without the upfront cost of a full
| rewrite -- it introduces significant technical and cultural
| migration risk over the long term."
| aardvarkr wrote:
| You're the one being utterly dismissive with your
| condescending tone and failure to acknowledge any points that
| op made. Sounds like they've been around long enough to have
| seen this cycle a few times. Used to be Ruby on Rails was the
| next coming of Christ.
| EvilEy3 wrote:
| You know what is dismissive? Switching to a lowest common
| denominator and offer subpar experience. This is what happens
| when you offer React Natives to users.
|
| They dismissed advancements in native development and they'll
| pay the price the future.
|
| It's literally laughable that they decided to transition to
| half dead tech when Compose and SwiftUI are ramping up.
| intev wrote:
| It's _literally_ laughable that you call react native a
| half dead tech. It 's still *the* most actively developed
| ecosystem for cross platform apps. Don't believe me? See
| https://insights.stackoverflow.com/survey/2020
|
| Moving such a mature company's codebase to bleeding edge
| tech is one of the stupidest decisions you can make. Is
| there some price to be paid to be in the future? I'm sure
| there will be, as there will be with any non native
| platform. Whether is will be a deal breaker is to be seen.
| forgotpwd16 wrote:
| >See https://insights.stackoverflow.com/survey/2020
|
| What is this survey supposed to show?
| intev wrote:
| To show how popular the framework is and that it is not
| "dead". Also to sure that it is not universally hated.
| 57.9% loved is not as good as the 68.8% of Flutter but
| it's not a huge margin.
| EvilEy3 wrote:
| > It's still _the_ most actively developed ecosystem for
| cross platform apps. Don 't believe me? See
| https://insights.stackoverflow.com/survey/2020
|
| Riiiight, and quickly followed by Xamarin and Cordova.
| Lol.
|
| Of course it is not dead in terms of usage. It is more
| "dead" for anything complex.
|
| I'm looking from a perspective of a best experience, best
| performance and best integration. If your only reasoning
| is "we can't afford proper mobile developers" that's
| probably not the best pitch for a technical folk.
|
| Even Facebook, creators of React Native don't use it.
|
| > Moving such a mature company's codebase to bleeding
| edge tech is one of the stupidest decisions you can make.
| Is there some price to be paid to be in the future? I'm
| sure there will be, as there will be with any non native
| platform. Whether is will be a deal breaker is to be
| seen.
|
| Who says about moving now?
| ec109685 wrote:
| > Even Facebook, creators of React Native don't use it.
|
| Yes they do.
| https://www.facebook.com/careers/v2/jobs/710998039655439/
|
| "Work closely with our PM and design teams to define
| feature specifications and build the next generation of
| products leveraging frameworks such as React & React
| Native"
|
| The top contributors are Facebook Engineers:
| https://github.com/facebook/react-
| native/graphs/contributors...
| intev wrote:
| > Riiiight, and quickly followed by Xamarin and Cordova.
| Lol.
|
| I'm confused - is this meant to be a disbelief of the
| survey? "quickly followed by"? Are we seeing the same
| thing? Did you see the %s? It is significantly lower. Of
| course there are Xamarin and Cordova developers still.
| Especially in Asia.
|
| > Who says about moving now?
|
| So wait years and see how everything plays out? So
| basically you have no solution. Clearly the issues were
| pressing enough that they needed a more immediate
| solution. A solution they thought was worth re attempting
| despite its previous failures.
| EvilEy3 wrote:
| > I'm confused - is this meant to be a disbelief of the
| survey? "quickly followed by"? Are we seeing the same
| thing? Did you see the %s? It is significantly lower. Of
| course there are Xamarin and Cordova developers still.
| Especially in Asia.
|
| Oh, I'm sure there are many of them! Just as there are
| many Visual Basic developers, or people who do everything
| in Excel.
|
| > So wait years and see how everything plays out? So
| basically you have no solution. Clearly the issues were
| pressing enough that they needed a more immediate
| solution. A solution they thought was worth re attempting
| despite its previous failures.
|
| No, my solution to the problem would be to rewrite from
| scratch in native, without waiting for Compose/SwiftUI.
|
| But for some reason it is so much easier to justify
| rewrite in X, because if it was written in Y, than of
| course Y is to blame for our shitty practices and lack of
| developer culture. They neglected best practices, piled
| crap upon crap and somehow it is native toolkit that is
| to blame.
| intev wrote:
| Yea so your react native is dead argument is bs. You
| clarified it later saying you meant for complex projects
| but in another comment you claim that they're just a
| crypto dashboard. So which is it? Do they have a complex
| project (not a dashboard) and need something more than
| react native or they're a dashboard app and react native
| is fine? The things you say don't line up.\
|
| > But for some reason it is so much easier to justify
| rewrite in X, because if it was written in Y, than of
| course Y is to blame for our shitty practices and lack of
| developer culture. They neglected best practices, piled
| crap upon crap and somehow it is native toolkit that is
| to blame.
|
| Is it really incomprehensible that there's a _valid_
| reason to rewrite in X? Now you claim they have shitty
| practices and no developer culture? What did coinbase do
| to you? Have you worked there? Did you see their "crap"
| code? If you don't have anything to back it up, I'll add
| it to your bs list.
| EvilEy3 wrote:
| > Yea so your react native is dead argument is bs.
|
| How so?
|
| >You clarified it later saying you meant for complex
| projects but in another comment you claim that they're
| just a crypto dashboard.
|
| Do I really need to chew everything for you? Crypto
| dashboard means that they have boring product, I never
| said it was simple or complex.
|
| > So which is it? Do they have a complex project (not a
| dashboard) and need something more than react native or
| they're a dashboard app and react native is fine? The
| things you say don't line up.\
|
| Native of course! With native applications you won't have
| issues like dangling shadow, or application being
| restarted under your nose when you open privacy policy.
| And I didn't even look at memory consumption and CPU
| utilization yet.
|
| > Is it really incomprehensible that there's a valid
| reason to rewrite in X?
|
| Nope, I can imagine that their use case is valid. But for
| a wrong reasons.
|
| > Now you claim they have shitty practices and no
| developer culture?
|
| Easy! If React Native application is more performant than
| your native application, then something _really, really,
| reaaaaally_ wrong happened. And technology is the last to
| blame in this case.
|
| > What did coinbase do to you? Have you worked there? Did
| you see their "crap" code?
|
| What makes you think that if I criticize their technology
| choice, I have something against them?
|
| > If you don't have anything to back it up, I'll add it
| to your bs list.
|
| Lol.
| macando wrote:
| > as they usually are just PR for internal teams, so someone
| gets a promotion
|
| CEO of Shopify praised React Native in January 2020. I guess he
| was aiming for that postition of Senior CEO there.
| hitekker wrote:
| Not too surprising. Mobile native engineers are quite expensive
| and coinbase has been cutting costs recently
| https://news.ycombinator.com/item?id=27119787
| [deleted]
| alexandr1us wrote:
| 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 major performance problems on iOS. Using
| native views (MapBox, ArcGIS) inside Flutter app has subpar
| performance. Flutter has weird styling compared to anything I
| have ever worked with. Styling in Flutter is very unintuitive
| (ex: Global theme for button width). You can't OTA update Flutter
| code. Weird scroll behaviour. I can go on and on but personally I
| would never use Flutter ever
|
| Most comments under the link:
|
| React Native bad because Flutter good.
|
| React Native bad because native good.
|
| React Native bad because Y is good.
| jpeter wrote:
| What was the worst framework? Xamarin?
| powerapple wrote:
| Thank you for the info. I am starting a project and was
| thinking choosing Flutter or React Native. I have used both
| Flutter and RN for some small toy projects. I really liked
| Flutter with fastlane. Does fastlane still work?
|
| Do people actually use Unity for apps? I am actually building
| an app for kids, Unity can be really interesting for me.
| babesh wrote:
| There are some long term trends that should work in React
| Native's favor.
|
| The pace of mobile changes is slowing and will probably slow
| further. This is the usual case of an initial innovation
| transitioning to incremental improvements. This means that React
| will eventually catch up or come close to catching up with mobile
| developments (if they have enough technical expertise to do so).
|
| Competition has consolidated the market into two platforms. This
| means that only two platforms need to be supported.
|
| Due to competition between iOS and Android, the two platforms are
| undergoing convergent evolution. This will also make it easier to
| support the two platforms since new features will be similar.
| pixel_tracing wrote:
| You couldn't be further from the truth. Mobile is undergoing a
| substantial evolution in development experience. SwiftUI and
| Compose are changing the development world for Mobile. The
| compiler itself is being optimized to show UI with hot
| reloading.
| babesh wrote:
| I think SwiftUI is just as much about platform lock-in by
| bundling Mac, AppleTV, iPad, and iPhone together as an app
| fortress. Furthermore it enforces more standard UI/UX which
| commoditizes apps.
|
| Stepping back, I think we are just seeing a battle of
| commoditizing your complements. For Coinbase and Facebook,
| Apple is the complement. For Apple, Coinbase and Facebook are
| the complement.
| 4eleven7 wrote:
| You have three options.
|
| Optimise for user experience (go native)
|
| Optimise for cost (whatever the cheapest developers, or a cross
| platform solution, like phonegap/pwa/react native)
|
| Optimise for developer experience (use whatever your developers
| know, maybe native, maybe react native)
|
| In my personal opinion, always optimise for user experience.
| Shared code should be in the backend, not in your mobile app.
| Your mobile app (ignoring camera filters & games, as they should
| use an engine; unity etc) should just be a JSON viewer, with a
| small bit of data entry. 80-90% of your efforts should be on UI
| and user experience, but obviously architecture requirements
| scales up with the team size. Anything else is over-engineering,
| generally.
|
| The amount of leads I get in for mobile apps, that eventually
| transpire to the client not knowing the app was built in react
| native, because they heard "native" and assumed Swift/Kotlin, is
| increasing by the day. They can't find enough good developers
| that know react native, and they don't have the funds to rewrite.
| They're stuck. Obviously I, as a native developer, only hear the
| horror stories from these experiences and not the times it works
| out.
|
| But in the last 2-3 years, it has killed 2 startups that I know
| of, and cost 3 a lot of money to rewrite (two of them made that
| decision before they contacted me, one after they spoke to me,
| and they were shocked to find out that they didn't have a Swift
| app). I am now having to rescue more clients from react native,
| than from clients that outsourced to the cheapest agency on
| Fiverr. Wild!
|
| Side note: why has every app got to expand until it adds
| messaging? Let a calculator be a calculator, it doesn't need
| venture capital and network effects to sell.
| sofixa wrote:
| > n my personal opinion, always optimise for user experience
|
| If you have unlimited money, that is. If you don't, a
| suboptimal UX is better than no UX.
|
| > Shared code should be in the backend, not in your mobile app.
| Your mobile app (ignoring camera filters & games, as they
| should use an engine; unity etc) should just be a JSON viewer,
| with a small bit of data entry. Anything else is over-
| engineering, generally.
|
| Ideally, yes, but depending on the app the frontend can still
| be heavy - e.g. with Coinbase, all the graphing and real-time
| stuff, done 3 times over, are probably a not insignificant
| effort.
| throw14082020 wrote:
| There's a lot that goes on in a mobile app, please read
| https://developer.android.com/docs/ and
| https://developer.apple.com/documentation
|
| It certainly is _different_ to backend development, but not
| everything is a "JSON viewer", even if you exclude camera
| filters and games. Only the truly awful apps are "JSON
| viewers". There is a lot of complexity, and I've heard
| arguments from people that 'they don't want to be a front-end
| dev because that is just visual stuff': they're talking about
| pre-javascript days or talking about something they've never
| done to a good level.
|
| Using a backend (adding network cost)/ sharing code should be
| the last on your mind for mobile apps. I've had once, where the
| logic for feature would take less than a day to implement
| (which I subsequently did), but inexperienced non-mobile
| developers decided it would be a good idea (and said exactly
| what you said) to put everything in the backend to share code
| between iOS and Android. The interface cost (network code) cost
| more time in development, and made a much worse user
| experience. Not to mention, I had to use the code written by
| the inexperienced person, which had bugs.
|
| You might not understand mobile, but there's a lot more that
| goes on in a mobile app.
| jfisk87 wrote:
| Long story short, terrible idea unless you're in a position like
| coinbase.
|
| The article is from a high level engineering standpoint about
| productivity and trying to be efficient. The thing the article
| doesn't mention is the best react native developer also is an
| expert in native mobile development. It is crazy hard finding
| these people.
|
| All techno fluff aside, any component mobile developer knows once
| you have a solid foundation it is super easy to build on core
| features. Given how frequently aplkenabd google breaks things
| which makes reactive native upgrades a mega PITA, the only proper
| use at a technical level is to utilize the code at a framework
| level. React native is still on its knees to cocoapods, which as
| of now is virtually nonpreferred for future projects.
|
| Sorry for the rant, I just think A.:) Coinbase made the wrong
| decision in the long run because they limited themselves on a
| technologist that's infamously know to not favor solid user
| experiences
|
| B:) they underestimated the specific qualifications they need to
| get the people that are grounded enough to know native mobile
| development and its capabilities, abs the react native component.
| Even though they are coinbase the article acts like it doesn't
| matter.
| namelosw wrote:
| > the best react native developer also is an expert in native
| mobile development.
|
| It's not that bad. All they need is at least 1 iOS expert and 1
| Android expert in the team.
|
| > infamously know to not favor solid user experiences
|
| I don't think that's necessarily the case. Discord is doing
| fine for me. Most of the apps don't need such high performance
| as video games.
|
| People always rant about React Native and Electron. The reality
| those techs are just scapegoats because most of the companies
| chose them because they want to build something cheap. If they
| use the same budget to build the same set of functionalities
| using native technologies for each platform, the outcome could
| mostly be even worse.
| _fat_santa wrote:
| I highly disagree that an expert RN dev also needs to be an
| expert mobile dev. Articles like these make it seem that react
| native development requires native knowledge but that simply
| isn't the case. With almost all greenfield RN apps, 99.9% of
| the code is RN and only very specific feature are helped out by
| native code.
| Jare wrote:
| You don't need to be an expert in native to write a RN app.
| However, you need to be very capable in native to have a
| responsive, performant, smooth RN app, _and_ to keep it that
| way for years.
|
| Large teams can afford to have a subset of platform devs and
| a large body of RN app devs to make this plan work (note: you
| now have 3 platforms: iOS, Android, and RN itself). Smaller
| teams will struggle. Most often, small teams will end up
| putting their weight on the RN side (develop new features!),
| and slowly slide downhill in performance, responsiveness and
| overall UX like the proverbial boiling frog.
| seanalltogether wrote:
| > Large teams can afford to have a subset of platform devs
| and a large body of RN app devs to make this plan work
|
| This has been my experience as well. I work on an app that
| supports multiple generations of iot products. We were
| forced to start developing for the next gen product in
| react native, and let the legacy stuff just use the exiting
| ios and android codebases. We made it about 9 months before
| throwing out the react native work and porting it all back
| to native. Management doesn't realize that moving to react
| native doesn't mean you now only have to support 1
| platform, it means you're now supporting 3.
| 600frogs wrote:
| Fun fact - your new word "aplkenabd" is a one-hit wonder on
| Google! What was it meant to say?
| pindab0ter wrote:
| "Apple and". Probably written (a bit too) fast on a phone
| without reading it back before hitting 'reply'.
| abacadaba wrote:
| Web developers, no prior mobile experience, we launched a RN
| app just fine with minimal outside assistance. It did take some
| problem solving / trial and error at times dealing with, e.g.
| cocoapods issues though, yes.
| grensley wrote:
| The AndroidX transition breaking basically everything was worse
| than everything Apple did combined in my opinion. That was such
| a massive and messy headache.
| EvilEy3 wrote:
| What an attrocity.
|
| You could've just said that you no longer want to invest in
| mobile talent.
|
| Just opened Coinbase Android app: * Overall slow * Jank in
| transitions * When dialog pops up and you close it, there's a
| dangling shadow in the air * You open privacy policy and
| application is killed in background and you see splash screen
| again with no state restoration, what the f?
|
| Hot garbage, the time you spent on this could be spent on
| rewriting to proper native standards.
| intev wrote:
| What has gotten you so upset about this transition? I don't
| understand. All your comments are so vicious with no backing.
|
| >You could've just said that you no longer want to invest in
| mobile talent.
|
| How does this even track? They had to retrain their engineers.
|
| I call complete BS with your app experience. I have a Redmi and
| the app works flawlessly. They seem to have internal data to
| prove it. They were under no obligation to make the blog post
| if they didn't think it was successful. If anything they are
| going against the grain here so they know there are lots of
| people watching.
| EvilEy3 wrote:
| > All your comments are so vicious with no backing.
|
| I literally listed my experience with the app. And I didn't
| even create account yet.
|
| > How does this even track? They had to retrain their
| engineers.
|
| To leverage Web developers, right.
|
| > I call complete BS with your app experience. I have a Redmi
| and the app works flawlessly.
|
| Which Redmi? I'm testing on Xiaomi Mi A1. It probably works
| better on my Samsung S10. But then majority of people have
| phones closer to my Xiaomi.
|
| > They seem to have internal data to prove it. They were
| under no obligation to make the blog post if they didn't
| think it was successful. If anything they are going against
| the grain here so they know there are lots of people
| watching.
|
| Because the blogpost makes it seem like there are only
| upsides to technology and the only downside is that it's not
| fit for brownfield.
|
| I had very bad experience with RN and give my opinion on
| tech. What's the problem?
| intev wrote:
| > I literally listed my experience with the app. And I
| didn't even create account yet.
|
| That's not all you did. You implied they pay their
| employees very little, that they didn't do their research
| before making the switch and called the whole thing an
| "atrocity" which is heavy to the say the least. That's not
| an app review.
|
| >Which Redmi? I'm testing on Xiaomi Mi A1. It probably
| works better on my Samsung S10. But then majority of people
| have phones closer to my Xiaomi.
|
| I have a Redmi 8 (2019). Most people in the US have
| something similar to a low budget phone from 2017? I find
| that extremely difficult to believe. India, probably. US/UK
| etc? Highly unlikely.
|
| > Because the blogpost makes it seem like there are only
| upsides to technology and the only downside is that it's
| not fit for brownfield.
|
| Yes that is their experience so far. They wrote about it
| and have data to believe it. You don't have either except
| random anecdotal data and visions about the future.
|
| > I had very bad experience with RN and give my opinion on
| tech. What's the problem?
|
| Most of your claims don't have merit other than random
| anecdotal data which you are using to refuse their
| anecdotal data which is actually a lot less anecdotal that
| yours because they have many more developers and users.
| EvilEy3 wrote:
| > You implied they pay their employees very little
|
| No implied. I stated it directly. Pay shit and get shit.
|
| > that they didn't do their research before making the
| switch and called the whole thing an "atrocity" which is
| heavy to the say the least. That's not an app review.
|
| I'm not an app reviewer, I'm a techie. And sorry that I
| didn't sugarcoat it enough for your sensitive ears.
|
| > Most people in the US have something similar to a low
| budget phone from 2017? I find that extremely difficult
| to believe. India, probably. US/UK etc? Highly unlikely.
|
| I'm sure Electron devs use the same reasoning when
| developing their stuff. After all, who has 8GB of RAM
| now?
|
| > Yes that is their experience so far. They wrote about
| it and have data to believe it. You don't have either
| except random anecdotal data and visions about the
| future.
|
| What data, again? "Internal metrics"? They provided
| literally zero data. The only thing they provided is
| improved startup on iOS and no data (sic!) from Android.
|
| >Most of your claims don't have merit other than random
| anecdotal data which you are using to refuse their
| anecdotal data which is actually a lot less anecdotal
| that yours because they have many more developers and
| users.
|
| I never said that my opinion is objective. If you can't
| handle critique, maybe you should quit online forums.
| intev wrote:
| > I'm not an app reviewer, I'm a techie. And sorry that I
| didn't sugarcoat it enough for your sensitive ears.
|
| What are you talking about? Why all this rage? In your
| previous reply you claim to innocently just talk about
| your experience with your app. That was a very clear lie
| and I pointed it out. And now you claim I have sensitive
| ears? Jeez...
|
| > I'm sure Electron devs use the same reasoning when
| developing their stuff. After all, who has 8GB of RAM
| now?
|
| haha way to move the goal posts after you get caught with
| some other bs you said! First you claimed most people had
| something similar to your phone so it should be working
| well on yours. But when I pointed out that this has
| incorrect assumptions suddenly the goal post is the app
| _should_ be able to run really well on a a low budget
| entry device.
|
| > What data, again? "Internal metrics"? They provided
| literally zero data. The only thing they provided is
| improved startup on iOS and no data (sic!) from Android.
|
| That's significantly more than anything you've provided.
| All you have been doing is pointing at random things and
| saying "I know better than them".
|
| > I never said that my opinion is objective. If you can't
| handle critique, maybe you should quit online forums.
|
| I've come this far, doesn't a genius to tell whether or
| not I can handle critique. Question is can you handle
| being called out without kicking and screaming about
| knowing better and moving the goal posts of the topic in
| discussion? TBD
| jessepollak wrote:
| 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.
| halfmatthalfcat wrote:
| What does your CI/CD look like? It took me a long time to fully
| flesh out a RN pipeline that was (mostly) completely automated.
| Are you leveraging Fastlane? Are you buliding both Android and
| iOS on OSX VMs? How do you deal with shipping canary versions
| and is that process also automated? Thanks!
| zitterbewegung wrote:
| Not really a question but more of a statement that Discover
| also transitioned from Native to React Native successfully and
| I believe they also didn't do a brownfield implementation.
| There was a presentation about this at React Chicago but I
| can't seem to find it.
| travisjungroth wrote:
| Sup Jesse!
| pixel_tracing wrote:
| So what is your native mobile engineering team doing now?
| mekkkkkk wrote:
| Which native mobile engineering team?
| cageface wrote:
| I've been doing a RN app lately after not using it for almost two
| years. It's still a very fast way to iterate on both Android &
| iOS but it also still feels extremely brittle. I've tried and
| failed to upgrade to the latest version of RN several times now
| but every time gotten tangled up in dependency hell. I also
| haven't been able to get it to build on my M1 Mac at all.
|
| RN is good for fast prototyping and market value fit testing but
| I'm not sure I'd use it for something like Coinbase.
| dstaley wrote:
| If at all possible, I can't recommend Expo enough. I _hated_
| building RN apps prior to it, and now I hate building apps
| without it.
| thrwhizzle wrote:
| It's too limiting right now. When the Expo team finishes the
| "Expo Application Services" it will be an option for almost
| every project. For now, it's limited to just the Expo APIs
| and for most projects you will ultimately end up ejecting.
| FlashBlaze wrote:
| Isn't the apk size much larger if you use Expo? Or is that
| not the case anymore?
| dstaley wrote:
| With the EAS Build system, it's no longer a concern.
| Available to paying customers at the moment.
| macando wrote:
| When Expo works like it should it's like the best dev
| experience ever. Supporting all React Native 3rd party
| components without ejecting and ditching the Expo app will be
| a huge step forward.
| _fat_santa wrote:
| Expo is great for prototyping and small apps with limited
| scope. However anything bigger and expo just doesn't work.
| At some point you will need to mess with the native side of
| thing, most of the time to initialize things like Firebase
| or adding a lib with a bridge. When you have to make native
| changes, no matter how small, Expo will get majorly in the
| way
| dstaley wrote:
| Honestly I think you'd be surprised just how far the
| managed workflow can get you these days. That being said,
| Expo is aware of the limitations and is actively working
| on addressing those.[1]
|
| [1] https://docs.expo.io/introduction/why-not-expo/
| whazor wrote:
| I think also a requirement is to have experts in React, iOS,
| and Android. Plus maybe even someone who focuses fully on React
| Native internals. Those dedicated people ensure all components
| compile and other developers can be productive. With the
| headcount of Coinbase it seems to be worth it.
| aorth wrote:
| Great writeup! I don't use Coinbase or any cryptocurrencies, but
| I'm tempted to sign up just to see this React Native application
| in action. Are there any other great React Native applications
| you have used on Android? From what I've seen it's mostly
| Facebook, Instagram, shopping apps, etc... which I don't use.
___________________________________________________________________
(page generated 2021-05-15 23:02 UTC)