Hacker News Reader

Comment by satvikpendem | Hacker News Reader

I tried using this a few months ago, as well as React Native for mobile and React Native Web for web, and I felt like they were all just hacks glued together to get cross-platform support, and RN isn't even native, it still includes a Javascript bridge. Build dependencies and packages were a nightmare, things continuously broke. I tried Flutter afterwards and it just felt like a breath of fresh air. Everything "just worked", on all the platforms I tested it on: web, iOS, Android, Windows, Mac, and Linux. Updates on one are hot reloaded to another. In contrast, Expo sometimes just broke. This was all wrapped up in one package instead of needing to use separate build chains for each platform.

I wonder if React Native can do all of this officially, but I suppose that's not their prerogative, given that RN is mostly used by Facebook for apps and these other platform efforts are by third parties, like Microsoft here.

View on HN

I've had the exact opposite experience, but I mostly use Java over Flutter for Android. Expo can be fairly limiting and breaks a lot, but core React Native is wonderful and does everything I need with a couple exceptions (FCM and more fine grained microphone support). I also have a dedicated Android native module for my app, and a lot of React Native libraries can probably be consolidated down to one module and directly using the Java libraries on Android.

What dependencies are you using that continuously broke? Did you track your package lock file on Git?

EDIT: Ive also tried React Native Web and it pretty much worked OOTB. Alerts were the only thing I found that weren't implemented, but they didn't show any runtime errors or instability

What do you think is the main reason for the difference between your experience and the parent's?

I had the same experience.

Expo is wonderful for prototyping and quick iteration. The ability to use Snacks online and see them working on the phone is great.

But beyond that everything in RN feels hacky and unfinished. While working with it I had some silly issues with Metro, and found some subtle bugs in Text and Button components.

About the "Native" part. I think that a lot of people have the expectation that doing RN apps will be the same as building a iOS or Android native app. But RN+Expo is not that different from frameworks like Ionic. Is really hard to do an app that follows the Apple HIG or Material Guidelines, you end with something in the middle that doesn't look or feels truly native (at least not without tons of extra work to imitate things that you get for free in the native UI kit) .

RN without Expo is not so nice, lots of rough edges and sooner or later you'll need to write interop code in Objective-C or Android Java to take advantage of the native platform.

I had the opposite experience actually. Expo made it difficult to accomplish anything with their ever changing sdk and (what felt like) never ending version deprecations and I found sooner or later for any serious project one would inevitably need to eject.

As of RN 0.60 it has been completely smooth sailing developing a react native app sans expo IMO

And I’d like to second this experience. Expo was more pain than it was worth for us, and raw RN was great once you understood it’s toolchain.

Expo has one small issue... if you are in an organization that isn't capable of keeping it up to date and it becomes deprecated, your app will stop working.

If this happens over a weekend, expect your phone to blow up every three hours until it gets republished and fixed.

Unless you are referring to another issue, using `expo build:android` will create an apk file so you don't have to rely on staying up to date with the Expo app.

Yeah, but if you are using their native extensions and they deprecate your version, their repo will become unavailable and your app will fail to start.

That’s a massive claim to say RN doesn’t feel native without alot of extra work? Please elaborate because it feels pretty native out of the box using the standard components.

It’s nothing like ionic. When is the last time you used RN? RN apps are hard to tell from native.

Take the most basic example: a Button.

The RN's core Button it’s a Text composed with a Touchable (https://github.com/facebook/react-native/blob/master/Librari...). It behaves in the same way but there are subtle differences in text rendering: the font size and letter spacing is not exactly the same, so when you create a native looking iOS view it doesn’t look the same unless to fine tune the font settings (and of course that will break when iOS decides to change it). This is just one small example, another one in iOS is “routing”. With the RN Router you don’t get the native components but a simulation of it. But Apple HIG doesn’t document many details of the animations and behavior of headings and nav bar (they assume that you use the native component). So if you want to have a native look and feel your options are: try an alternative router built for iOS, try to build your own adapter (hard unless you have tons of native dev experience), or try to imitate the native platform. All the options have pros and cons, and require more extra work over a small UI detail that you get for free using native tools. At least Flutter took the effort to make it look native by default.

In the end is similar to the desktop: if you want cross platform code is easier to not follow the platform rules. The differentiator of RN is that you have the option to embed the native widgets, which is not always easy. (The last time I used RN was mid-2019, I didn’t see substantial changes since then)

> RN isn't even native, it still includes a Javascript bridge

"Native" doesn't describe the programming language, but the GUI layer. Native == non-web-browser.

The GUI layer in a static sense. You can't have native realtime interactions with the GUI, for instance dragging and interactive animations.

You can choose one of two things:

1) Run a single precomputed action or animation in native-land when receiving an event from JS. No interaction is possible.

2) Run a requestAnimationFrame loop in JS which is passing the bridge (6 API calls on Android - 3 layers per direction) 60-120 times per second in async mode. Enjoy the jank.

Have you tried react-native-reanimated?

you can, using react-native-reanimated, also, the upcoming fabric work will enable this as well.

React Native isn't afraid to expose platform specific details when abstracting away cross platform APIs in uniform APIs. In my experience, it was fairly easy to use a native UI library inside a React Native app. (It takes more work to embed a React Native view inside a native view that's embedded in a react native view, but it's possible.)

I've seen both uses of the term "native"; it's an overloaded term. Some use it to mean "native UI", and others use it to mean "natively compiled". I meant it in the latter case. I actually prefer wholly custom UI, as most apps do these days that are cross-platform, because it allows for very interesting user experiences. Of course, some people disagree, wanting everything to be native-looking and feeling to their platform, such as Linux apps all using GTK or macOS all using Cocoa.

I've done a few client projects in the past using React Native. I get the appeal of having a "single" codebase for iOS and Android, but I absolutely detested using it.

I'm quite sure and aware of people that love it, but just from my personal development background, it just never really seemed appealing to me. Definitely not a fan of how state is handled. I've rolled my own system, Redux, and a host of other solutions as well. It just all seemed unnecessarily complex.

As you said, to me it just felt like hacks on top of hacks. I'll take vanilla iOS and Android development any day of the week, and twice on Sunday.

With that said, and from what I've seen of Dart/Flutter, I really hope it takes off.

Not sure why NativeScript and Ionic are not more popular on HN, I've seen more success with both of these than React-Native.

I guess the first is not backed by a big company and the second still has the Cordova stigma.

can you go into more detail about "how state is handled"? I wouldn't have considered that to be one of the offerings of React Native (or Flutter).

Well, for a toy app, it's pretty simple, but once you begin to build real-world apps, with 30 or 40+ components, and their children, I just found passing state and props around a bit messy and hacky. Of course, then you introduce Redux, and all is well. But now you have to deal with transducers and actions, and so on. I just didn't find the tradeoff worth it, and prefer native development.

I'm sure every React developer has at some point found themselves banging their head on the wall trying to figure out why some child component isn't updating.

And yes, it's a personal preference, but I'm also not a fan of Javascript. If another client wants a single codebase app, I'm really gonna give Flutter a nice long look. I've read the docs, and it looks quite appealing.

Flutter has a few different state management techniques, and even a Redux implementation. Provider is the most commonly used one.

For Redux with React, you could check out Redux Toolkit (https://redux-toolkit.js.org/). It solves a lot of the boilerplate issues with Redux. createSlice is especially valuable.

Check out React context to avoid this property passing, which is annoying, I agree.

Did you know that Redux is now basically built into React?

https://medium.com/simply/state-management-with-react-hooks-...

https://blog.logrocket.com/use-hooks-and-context-not-react-a...

In contrast,

https://www.simplethread.com/cant-replace-redux-with-hooks/ https://daveceddia.com/context-api-vs-redux/ https://medium.com/javascript-scene/do-react-hooks-replace-r...

TL;DR Context can replace some but not all of Redux. Redux can figure out which components to rerender based on what's being computed. Context doesn't, so it's basically the same as refreshing your entire component tree every time something changes. You could build it yourself, but at that point, you're just reinventing Redux.

I also like the Redux Toolkit (https://redux-toolkit.js.org/) which is an opinionated way to write Redux that cuts down the boilerplate a lot. createSlice is easily one of the best features, you can encapsulate Redux logic for each different type of content, like authentication, users, posts, etc.

Glad to hear that RTK is working well for you!

I'm currently working on updating the Redux core docs to teach RTK as the default way to use Redux. Hoping to have the new "Quick Start" tutorial page up in the near future.

I'm kinda surprised that everything "just works" for Flutter, even on Windows and Linux, which the official documentation seems to say are still in alpha stages and might be subject to breaking changes in the future.

I also couldn't find ways to easily implement things I want, e.g. native Mac MenuBar bindings/Mac App Store payment library etc.

Eventually I ended up using Quasar https://quasar.dev/, which allows you to use one Vue.js codebase but deploy to Cordova on mobile and Electron on desktop. Vue is definitely not the prettiest solution out there, but I had to be practical and actually get the app out.

Maybe I'm just one year too early for React Native/Flutter ecosystem to be developed enough for my app. The landscape is certainly changing rapidly, which is good.

Yes, Flutter is useful for when you have GUI heavy apps, not necessarily ones with platform integration like menu bars and cameras, although that is progressing pretty well I'd say, people are writing plugins for platform capabilities.

Regarding Windows and Linux, I too was surprised at how well everything worked. You can't build to production yet for these two platforms (officially at least, see flutter-rs for unofficial implementations), but the debug builds still work as well as the Android and iOS emulators. I used them on a lower powered machine to run my Flutter apps and it was great that they worked well.

Instead of "Flutter", use "Flash" and you got the same thing!

Except hot reload

Reply on news.ycombinator.com