React Native is becoming the Wordpress of mobile apps.
Not sure that's the best analogy.
React Native at Instagram
221–230 of 238 posts
Re: React Native at Instagram
#222Earlier quoted context omitted.
> This is one of those Android design decisions that Google probably wishes they could get to do over again. Doubtful. This decision is what allowed Android to perform reasonably even in the early days circa 2008. Without such a restriction, it's possible that Android couldn't have competed with iOS on performance and die as a consequence. It's easy to make fun of technical decisions made ten years ago, try to put th…
> this 65k limit is barely a minor annoyance that only a very tiny percentage of Android apps ever hit This is not true, you can easily hit this limit because of a dependency that you _need_ that pulls e.g. Gauva, of when you use 2 or 3 libraries from Play Services, which are huge > (and there are easy workarounds) Easy maybe, but the issue is still more than _a minor annoyance_ imo
I've hit the limit when pulling in all Play services. The key is to only pull in what you will be using. Many tutorials(including one from a third party analytics API) are a bit lazy and just have you import Play in its entirety.
Re: React Native at Instagram
#223@martinbigio here in case anyone has questions
Probably OT but a bug that's been driving me crazy for a while now. When I open Instagram it reloads the feed every time as if the app had been purged from memory. This means if I accidentally close the app and reopen it my scroll position is lost and thanks to the sort algorithm the feed order has changed and I can't get back to where I was.
i'm on iOS but today's IG update just got rid of this problem. been suffering this problem for the past week or so.
Re: React Native at Instagram
#224This 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…
I think almost always, if there was a choice between making thing easier for the developer and squeezing more performance with more difficult practices, majority chose better developer experience.
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.
Re: React Native at Instagram
#225Earlier quoted context omitted.
> > devs have an easier life using JS > I think that is willfully missing the point. How is GP missing the point, when you go on to illustrate the point? Or, is your counter-point to GP that "design is special, so cut us some slack"?
The GP implies that the only reason a company would go with React Native is to make life easier for it's dev's at the expense of performance. That's clearly not true and I believe the GP knows it. If performance was the only thing that mattered to consumers then performance and optimization would be the only thing Instagram's developers would focus on. Facebook is a public company, it publishes Instagram's engagement…
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 shenanigans, JS VM and shadow view hierarchy (aka shadow DOM).
Re: React Native at Instagram
#226Earlier quoted context omitted.
So why not have a virtual DOM-based data-driven layout engine that _isn't_ an HTML/JS stack. Something in a language that is more optimisable and works everywhere, like Lua with C extensions, or OCaml, or Java. JavaScript is hard to get predictable performance from and HTML is extremely complex, we can do better if we're writing native apps (hell, we should have had a better online solution years ago too, but we don'…
> why not have a virtual DOM-based data-driven layout engine that _isn't_ an HTML/JS stack I'm not advocating RN, I just understand the motivations behind frameworks like it. I think "to make devs lives easier" is not a fair assessment. Also, to be fair, JS performance is generally adequate. My own experience with performance on mobile devices often fell back to rendering (e.g. managing textures, making animations sm…
What is "adequate"? Any long term task still hangs the business logic thread - the only thread - unless you fallback to native. At what point does constant fallback to native for implementing what is not possible in JS a detriment to development? You may say, multithreading is an edge-case, but is it? I have not been involved in a single project where actual multithreading was not needed.
Also, the way RN is implemented internally, such as async bridge and layout (CSSLayout / "yoga"), it is quite impossible to use native optimized views, such UITableView with reusable views, because this API is designed for synchronous API calls.
Re: React Native at Instagram
#227Earlier quoted context omitted.
OTOH, this kind of tech is a godsend for smaller shops and solo developers, where having two completely separate codbases (or three if you also do a web version) can be impossible.
Or smaller startups who need to support both platforms at launch. We're going through that right now and we definitely can't afford to pay for a java dev and a swift dev and a js engineer (me). We also can't afford the Dev Shop costs of both iOS and Android. and our customer base is split 65-35. React-Native is literally a gift sent from God to save us
Do you mind sharing what your application does, and possibly a link to the app store of it?
Re: React Native at Instagram
#228Earlier quoted context omitted.
I think almost always, if there was a choice between making thing easier for the developer and squeezing more performance with more difficult practices, majority chose better developer experience.
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 who have worked in better developer environments, such as Android Studio, Visual Studio and Xcode. The only people really happy, from my experience, are web developers who are already familiar with this technology and ecosystem.
Re: React Native at Instagram
#229Earlier quoted context omitted.
The GP implies that the only reason a company would go with React Native is to make life easier for it's dev's at the expense of performance. That's clearly not true and I believe the GP knows it. If performance was the only thing that mattered to consumers then performance and optimization would be the only thing Instagram's developers would focus on. Facebook is a public company, it publishes Instagram's engagement…
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 users. App stability and the time that it takes to get new features to market are also things that users care about, sometimes at the expense of performance.
Facebook/Instagram make product and technology decisions based on metrics. Making life easier for their developers is a secondary concern. If a feature is not moving the engagement numbers in the right direction, it gets cut.
The proof of this is Paper, a beautiful fast native app that was originally meant to the replacement for the main Facebook app. It's numbers sucked, so Facebook cut it.
Re: React Native at Instagram
#230Call 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.
That's how we do it as well. Bonus: you can test your business logic without having to run it on a phone. I'm shocked more people don't do this—I guess they don't know C++?
Web developers are a dime a dozen - very low barrier to entry, both from learning standpoint, and quality standpoint (sadly). C++ developers - a lot less. C++ developers cost more. Native developers who are also willing to learn C++ are also expensive. My cynical view is that with RN, startups are just able to hire a few web developers instead of having to hire native developers, so it's a lot cheaper.