Comment by hunterb123 | Hacker News Reader

Comment by hunterb123 | Hacker News Reader

Parent Full thread

> But if you need to really leverage the specific platforms, it’s hard to do that.

Not my experience. I have a production app for web, ios, and android, with desktop platforms coming.

You can swap out anything per platform and write any extension for any native functionality you don't have, but the std and community extensions are plentiful.

RN sucks for "web pages", great for apps. In fact sometimes I embed web pages inside my RN apps. (surveys, etc.)

I haven't heard a single good argument of why it doesn't work. If you were going to write a native app you can write a native extension and share the common parts in JS.

RN is not Cordova, it's not a black box, it's very flexible and extensible.

-- @Jcampuzano2 because of post limit --

Earlier yes there's some fickleness with the toolchain, I don't really have issues now, it's fine unless you're on bleeding edge versions or old versions. Performance issues usually relate to the JS bridge, JSI will alleviate that, most devs won't experience an issue. I don't know why others struggle with RN, it works well for me. Flutter is a no go because it emulates native, it's not true native. You can feel the difference on iOS and the web part sucks so hard.

Weird because this is the exact opposite of everything I hear from most developers I know.

I personally also worked with React Native for a while, and sure, you can write native extensions for everything, but the biggest complaint is how fickle it is when it comes to upgrading, package management, mind boggling errors related to the metro bundler, etc.

I.E. It's great when it works and you have something simple, but things broke so often compared to native development when you had to do anything complex. And the performance characteristics weren't very great on top of this.

I haven't done React Native in a bit more than a year but from people I talk to not much has changed, and most people I talk to who were all in on React Native mention to use Flutter instead nowadays if you really want cross platform UI.

react native can definitely ship production ready applications that large teams work on. bundler problems arent even react native related.. theyre webpack/babel etc. Package management? how is that related to RN?

Because you never have to deal with that stuff in mobile apps unless you use react native? So sure maybe it’s not directly react native’s fault but it is an issue.

This thread initially started by me comparing Svelte to React.

React uses webpack usually, RN uses metro usually, you can use esbuild, swc, etc for either though.

Svelte is a web tech, and thus uses web bundlers like webpack, thus has the same "faults", though I'm not sure what specifically is being critiqued.

When comparing RN to other cross platform solutions like Flutter you're wanting to compare it's package manager / bundler to Metro and the native dependency systems such as Cocoapods.

Just wanted to clear that up.

you will always have to manage dependencies somehow. Maybe you prefer the model used by flutter or something, thats preference. Its not a matter of whether of one is unsustainable or not. react native is fine for professional or hobby projects. even if you have problems with babel/webpack/etc bundle server (which btw can be worked around using inline bundling...)

My experience with the tool chain was abysmal. It's been almost 3 years away now for me, so I don't know the current state of things. I hope it has improved.

But every update was a large effort in bringing the app back into compliance with the new changes. The debugging platform used a different interpreter than in app resulting in things that worked in the debugger but not in production. Odd bugs at boundary layers nobody could (easily) decipher. The inability to even catch or do anything with some crashes.

It was the worst experience I ever had with a development tool chain in my entire career.

> The debugging platform used a different interpreter than in app

What discrepancies did you notice? It depends on the target platform which JS engine is used. Sometimes the debugging platform shares the same engine.

> Odd bugs at boundary layers nobody could (easily) decipher.

I'm not sure I understand, could you provide an example?

> The inability to even catch or do anything with some crashes.

Strange, you're able to catch and debug both JS and native crashes currently. I'm not aware of a past limitation but I could be wrong.

Disclaimer, these memories are about 3 years old...

> What discrepancies did you notice? It depends on the target platform which JS engine is used. Sometimes the debugging platform shares the same engine.

Exactly what I said, there would be some code that would run differently in the two environments. I know more now than I did then, but I believe the example was specifically on iOS the app was using JavaScriptCore and the desktop dev tools was using v8.

> I'm not sure I understand, could you provide an example?

> Strange, you're able to catch and debug both JS and native crashes currently. I'm not aware of a past limitation but I could be wrong.

Best as I recall, there was a semi-frequent bug that happened down in our logging system. When it blew up we got a native stack trace instead of JS. My best guess is some kind of handshaking problem between the two layers. Neither used code we wrote and maintained.

Because the whole thing happened inside our error reporting engine, it wouldn't end up in our logs other than a high level apparent failure. It was a mess, and we had limited native experience on the team when it happened. We hired a dev with more native experience, but we still didn't ever figure it out while I was there.

The tool chain always felt like it was a hacked together early beta. To complicate our experience our internal APIs were a mess and unreliable and our React Native codebase wasn't dramatically better. Between our internal problems and all the idiosyncrasies and unintuitive issues in the tool chain it was really miserable.

It wasn't unusual for everyone on the team to spend more than a day simply trying to get the app running again after an update, that is after a dev had completed a 1 to 2 week migration required after the update.

Reply on news.ycombinator.com