Call me old-fashioned, but I thought the Android/iOS code sharing nut was cracked: Business logic in C or C++ and UI in Objective-C (iOS) and Java (Android + NDK). As a bonus, you could bolt a desktop UI on top of the C++ as well.
It's certainly possible, but comes with a large number of its own issues: - C++ is a way more complicated language with the manual memory management. C is way too low level for things like this. - Complicated builds if you need to use a bunch of C++ libraries as dependencies. - Much slower iteration. - Complicated debugging. - The need to either write (slow) or generate (constraining) the Java/ObjC bindings. Then the…
React Native at Instagram
231–238 of 238 posts
Re: React Native at Instagram
#232Earlier quoted context omitted.
It's certainly possible, but comes with a large number of its own issues: - C++ is a way more complicated language with the manual memory management. C is way too low level for things like this. - Complicated builds if you need to use a bunch of C++ libraries as dependencies. - Much slower iteration. - Complicated debugging. - The need to either write (slow) or generate (constraining) the Java/ObjC bindings. Then the…
With modern C++ language features, the "complicated language with the manual memory management" a lot less obvious or necessary. Debugging is only complicated on Android, where NDK is pain in the ass for some reason, even after so many years of Google developing the toolchain.
Not completely though, you still have to think a lot more about ownership and object lifetimes (https://www.youtube.com/watch?v=JfmTagWcqoE), which is a lot better than manual new/delete, but still not as simple as just having a GC.
Plus you have to deal with lifetimes of objects proxied to Java code, where something in the Java code becomes the object's owner. Though you can use a bindings generator like djinni (https://github.com/dropbox/djinni) to handle this for you (with some tradeoffs).
>Debugging is only complicated on Android
It's gotten slightly better recently, but it still sucks.
With Swift it's not trivial either, it's not that easy to set breakpoints into C++ code, stack traces on crashes are often not helpful (so any unhandled C++ exception that you didn't catch and convert into a Swift error is hard to track down, etc.)
Re: React Native at Instagram
#233As an iOS developer, I had to decide between investing more time in Swift or React-Native. I chose React-Native simply because I thought it will allow me to broaden my mobile development experience and maybe one day stretch to even the Android platform. Furthermore, it improved my javascript skills in general and allowed me to create React web apps as well. I think it is the right choice thus far. Anyone else have si…
Yep. This describes me. I'm an iOS developer who has been contracting for the last 6 months doing nothing but React Native. I do hope to return to Swift once the language stabilizes a bit more. It was annoying not being able to easily use any third party swift libraries when Xcode 8/iOS 10 came out (Apple made some Swift language changes and all third party libraries had to update). All that being said, I'm pretty ha…
Re: React Native at Instagram
#234Earlier quoted context omitted.
Especially as chips get faster, teams can afford opting towards a better developer experience to move faster and retain happier engineers. It isn't only developer experience, also developer velocity. That was the whole motivation behind React Native in the first place.
From my experience, any native developers that work with React Native have a mental toll from having to adapt to what seems like unnatural technologies from the native side. Add on top of that the terrible web ecosystem, terrible JS base library (and, perhaps, the language itself), the lack of IDE (not code editors), the debugging experience, the packager performance, and it's just not a good experience for people wh…
Take it from a former UIKit author: https://twitter.com/andy_matuschak/status/560511204867575808
Re: React Native at Instagram
#235This is a bad sign to me, talks about how to optimise start up performance and optimise list views when the processors in our pockets are the fastest they've ever been. Do we really have to switch to developer centric development where devs have an easier life using JS at the expense of performance? Think the millions of users would prefer their devices to have better battery life, load faster and have less cruft jus…
> devs have an easier life using JS I think that is willfully missing the point. Creative work, especially UI-centric product development, requires significant iteration. Layouts change frequently, entire view hierarchies can be re-worked, sizes are tweaked obsessively. This isn't just about decreasing the burden of engineering (as if Obj-C/Swift/Java/etc. were so hard to master). This is about decreasing the time fr…
Re: React Native at Instagram
#236Re: React Native at Instagram
#237Earlier quoted context omitted.
So you say that React Native is not just to make life easier for developers, but then go on a rant ... that proves how React Native makes life easier for developers? Otherwise, it is a very big compromise, in regards to UX and performance. UX is not native - it reimplements basic concepts from each OS on its own in JS, which is neither good for UX (it doesn't look or feel right), and performance suffers due to bridge…
"So you say that React Native is not just to make life easier for developers, but then go on a rant ... that proves how React Native makes life easier for developers?" I'm very sorry if my comment came across as a rant, that was not my intent. I actually never made the claim that React Native makes developers lives easier in that comment. My main point was that raw performance is not the only thing that matters to us…