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

The not so hidden cost of sharing code between iOS and Android

blogs.dropbox.com

Post reply on HN
Print view View original

291–300 of 335 posts

Re: The not so hidden cost of sharing code between iOS and Android

#291

Post by root_axis »

whalabi wrote: post #287
root_axis wrote: post #269

Earlier quoted context omitted.

The nice thing about React Native compared to Flutter is that RN uses native UI widgets whereas Flutter implements its own rendering system. Flutter engineers basically reinvent a large portion of the work already done by Apple and Google in their UI kits and ultimately you have to rely on them to keep doing that work whenever changes are introduced to iOS and Android UI kits. Since RN uses native widgets they get th…

Wasn't one of the main points with flutter having really good fps?

In my experience it generally does, but on older devices, especially older androids, when the FPS does drop, the entire UI appears to be affected, whereas native widgets seem to perform better, or at least, don't seem to drag down the performance of the entire app UI if one widget is misbehaving.

Re: The not so hidden cost of sharing code between iOS and Android

#292

Post by ufmace »

paulryanrogers wrote: post #268
dougk16 wrote: post #79

Earlier quoted context omitted.

Basically the same process as when you first started. Implement the changes on Platform A, get it stable, port it over to Platform B, get it stable, port back any refinements to platform A. Platform changes themselves should ideally be quarantined behind said abstractions/injections, so your actual ported code is very simple and "timeless": no fancy language features, no preprocessor magic, no annotations, no excessi…

Approaches like this could increase the second-class-platform effect. Where, for example, Android gets updates long after IOS. (Unless both releases are synchronized.) In theory the shared code approach means platforms could be tested in parallel.

The whole point of the post here is that the theory doesn't apply very well to modern mobile development, and trying to share code effectively slowed them way down.

Re: The not so hidden cost of sharing code between iOS and Android

#293

Post by pjmlp »

shmerl wrote: post #277
pjmlp wrote: post #193

Earlier quoted context omitted.

Go learn about the industry business practices to start with, an advice you keep ignoring. Some people never get tired to fight windmills.

You repeating the same thing won't change the fact that lock-in is a foul practice that simply taxes developers for the benefit of those who want to hamper competition. Only shills support such approaches. You perfectly well know it yourself.

Somehow it makes you feel good to call me and others that enjoy the productivity of better tooling shills.

Do you think it matters at all to us with actual experience passing by the soap box?

Re: The not so hidden cost of sharing code between iOS and Android

#294

Post by bobthepanda »

abacadaba wrote: post #63
bobthepanda wrote: post #48

Earlier quoted context omitted.

AirBnB has a series of in depth blog posts about their decision to abandon RN. In particular this quote seemed extremely worrying to me: > While debugging, React Native attaches to a Chrome Developer Tools instance. This is great because it is a powerful debugger. However, once the debugger is attached, all JavaScript runs within Chrome’s V8 engine. This is fine 99.9% of the time. However, in one instance, we got bit…

Having been bitten by this exact issue one or two times, meh. Par for the course in the life of a Javascript dev, really. RN would definitely still be my go to tool for the majority of green-field mobile apps. If I'd already invested in learning flutter/Dart I'd probably feel the same about that, but certainly feel no urgent need to go out and learn it. As in, I don't think there's a significant difference in what I'…

That's great from a dev perspective. Not so much from a product perspective, particularly if you operate at AirBNB scale and your issue could be costing lots of money for every second of failed debugging.

Re: The not so hidden cost of sharing code between iOS and Android

#295

Post by verttii »

s_y_n_t_a_x wrote: post #278
verttii wrote: post #213

Earlier quoted context omitted.

There's a lot of valid points from native advocates though. Like differences in touch features, various sensor APIs, Firebase etc. These may not be serious considerations in simple apps but they make major difference to both the end user as well as the codebase/developer in larger scale / more serious apps. That said, myself I still write Flutter too, having jumped ship from React Native.

I use React Native so there is no difference in touch features etc. It's native components bridged by JS.

But on React Native there are major platform differences that you also have to bridge. Moreover, as the platform essentially uses each platform's native components through that JSON serialized bridge you'll have UI inconsistencies between platforms when sharing code.

Re: The not so hidden cost of sharing code between iOS and Android

#296

Post by ufmace »

jugg1es wrote: post #120

I often struggle trying to explain to more junior developers that there are times when it's OK to write code more than once. There is a mindset that you should only ever write code once. It exists for (very) good reason. But if you follow it dogmatically, you may end up with an unmaintainable tangle of dependencies that can only be resolved with a rewrite. Sometimes, it's OK to write the same thing twice if the alter…

I like the rule I read somewhere called Rule of 3. Goes something like, don't bother to write a shared version of some piece of code until you've already written it in at least 3 different places. This simultaneously ensures that

1. There is actually a need to use this code in multiple places

2. You know where the places that need this code actually are, and what they need, so what you write will actually be practical for all of them to use

3. Or maybe you can tell that, despite the seeming similarity, the different places are too far apart or too different for sharing code to actually make sense

Re: The not so hidden cost of sharing code between iOS and Android

#297

Post by shmerl »

pjmlp wrote: post #293
shmerl wrote: post #277

Earlier quoted context omitted.

You repeating the same thing won't change the fact that lock-in is a foul practice that simply taxes developers for the benefit of those who want to hamper competition. Only shills support such approaches. You perfectly well know it yourself.

Somehow it makes you feel good to call me and others that enjoy the productivity of better tooling shills. Do you think it matters at all to us with actual experience passing by the soap box?

Enjoying lock-in - that's a new one. Instead, I enjoy breaking it (for example by using dxvk).

Re: The not so hidden cost of sharing code between iOS and Android

#298

Post by s_y_n_t_a_x »

verttii wrote: post #295
s_y_n_t_a_x wrote: post #278

Earlier quoted context omitted.

I use React Native so there is no difference in touch features etc. It's native components bridged by JS.

But on React Native there are major platform differences that you also have to bridge. Moreover, as the platform essentially uses each platform's native components through that JSON serialized bridge you'll have UI inconsistencies between platforms when sharing code.

I built upon ReactXP with helps with that. A project from Microsoft that powers Skype for Web.

But yes, there can be differences, but that doesn't mean give up and write the application code 6x.

Re: The not so hidden cost of sharing code between iOS and Android

#299

Post by ec109685 »

saagarjha wrote: post #72
bobthepanda wrote: post #48

Earlier quoted context omitted.

AirBnB has a series of in depth blog posts about their decision to abandon RN. In particular this quote seemed extremely worrying to me: > While debugging, React Native attaches to a Chrome Developer Tools instance. This is great because it is a powerful debugger. However, once the debugger is attached, all JavaScript runs within Chrome’s V8 engine. This is fine 99.9% of the time. However, in one instance, we got bit…

> Android JSC Wait, React Native uses JavaScriptCore on Android?

Yes. However Facebook now has their own JavaScript engine.

Re: The not so hidden cost of sharing code between iOS and Android

#300

Post by jjtheblunt »

bfrog wrote: post #108
rabidrat wrote: post #57

Earlier quoted context omitted.

Yeah, I have 15 years of C++ experience, but not since 2012. So with C++11 and C++17 (and soon C++20) my skills have not aged well, even though I can still write C++03 just fine. It's no wonder 'senior' devs prefer to use plain C, where even C11 is not that different from C99.

C is just easier to keep most of the rules in your head for. I prefer C any day, especially in an embedded system.

i agree
Post reply on HN