React Native 0.60 | Hacker News Reader

React Native 0.60

facebook.github.io

72 pointsreimertz61 comments

I just really can't see RN gaining much traction outside of experimental/small apps. You very much still need experienced mobile devs to debug the multitude of Java/kotlin/XCode/Android issues that come up because of how fragile the entire workflow is. Running a business on that is non-starter.

I run. A voip app for call centers. You can't imagine the pain.

I have to agree with you. Moreover, you also go through plenty of pain to make the app work well on both platforms, with surprisingly much platform specific code.

While I am not necessarily an advocate of React Native, I don't think your point is fair. React Native never promises that its users can "write once and run anywhere".

Fair enough, but my point stands. Flutter is much more pleasant in cross-platform development even though this isn't even its primary goal.

I understand this is not a trivial problem, just comparing my experiences with RN with Flutter.

Luckily the most RN devs come from the web and have a much higher pain tolerance.

Chuckled at this. But honestly I find debugging the “native” side of RN apps much more painful than any type of web development I’ve had experience with. Then again perhaps I’ve never worked with a 100% pure native app so would love to hear some more perspectives on this.

IDK what you mean but there so many things much easier and straightforward with web-based tech, eg sane layout systems like flexbox are way superior than anything native frameworks have to offer.

if you only need another listicle app with a push notification or two, React Native is there

but so are a bunch of other things that are easier to use

Yep, I just upgraded my RN app and their official upgrade strategy is to go line by line and update your project with the changes they made between versions.

https://react-native-community.github.io/upgrade-helper/?fro...

The Discord devs use RN and their app is anything but experimental or small. And there are by far not the only one (Skype, Instagram, Wix, UberEats, Tesla, Baidu, Salesforce).

Native devs don’t like RN because the mobile dev supply gets bigger which hurts their market value. That’s the real reason of your post, spreading FUD.

RN has its limitations but for 80% of apps it’s absolutely fine.

I am quite sure uber eats is not using RN anymore (evidence here: https://www.appbrain.com/app/uber-eats:-local-food-delivery/...). There are many examples of companies abandoning RN, e.g. udacity, airbnb...

But the vast majority stays with RN.

I don't know and don't really care. Most apps I use work as PWAs anyway, I also prefer the browser. But i can only speak for myself, time will tell...

Exactly. It's the same with Rails.

I love rails.

For every app still using it there are 10 abandoning it.

https://medium.com/airbnb-engineering/sunsetting-react-nativ...

Please stop with the market value/FUD attacks, they are nonsense and childish. You clearly have an axe to grind.

I don't like RN because I have had to sunset multiple large projects in RN. Javascript is a mess for mobile development. The interaction between the native layer is a mess. Hell, it's still not even a 1.0 release yet - smart CTOs would be insane to suggest it as a tool. Just look at the upgrade guides they post - a mess.

Judging by the number of React Native jobs on Indeed that ship has already sailed.

I tried Nativescript, React Native and Ionic. I've had previous experience with both React and Angular. I found Ionic to have the most enjoyable and cogent end-to-end experience amongst the three.

Interopt with Nativescript and other libs was hard, React Native didn't support Typescript as a first-class citizen (which as a prereq of mine) and the developer tooling wasn't as mature as the Ionic/Cordova/Angular cli(s) were.

A lot of noise around Flutter but haven't given it a try yet, but I'm weary because of defining views-as-code rather then a flavor of JSX/Angular Templates.

Have you tried Expo?

>because of defining views-as-code rather then a flavor of JSX/Angular Templates

JSX is just syntactic sugar, it's not a templating language. You could write yourself a JSX syntax extension for Dart, it'd be the same thing really.

Edit: More succinctly, JSX desugars to method calls

For a stupid guy like me who needs the compiler, flutter is the most sane experience I have ever had in the UI ecosystem (except Qt and JavaFX). The view as code is really really better (for me).

Same here. I don't see how adding some kind of XML layer on top of Dart would help with anything.

Tell us nore about your dev experience with Flutter. Can you also create the web version of your app with Flutter?

Desktop and web versions are in the making. So we will be able to make all of them from a single codebase.

I am really dependent on static types so take my take on this with a grain of salt :)

Flutter is more mature right from the Dev tools to the overall ecosystem. The types are first class and make it a joy to use. Not to mention the libraries are better quality and stuff works even when you upgrade. I could never work on any RN project for more than 1-2 weeks without something or the other breaking and me cursing out aloud for the really shitty (again subjective) state of things. I am used to having codebases just keep on working almost forever.

Is the layout system as powerful as eg css' flexbox, React's component composing etc.?

> I found Ionic to have the most enjoyable and cogent end-to-end experience amongst the three.

Agreed, though I'd love to use Ionic with Scala.js in place of TypeScript (which is great, but doesn't give me the same if-it-compiles-it-works confidence as Scala does, not to mention batteries-included standard library).

Hopefully technology will emerge that allows one to write once/run everywhere in preferred-language on all major platforms. Compromises seem to abound with currently available options.

Scala.js sounds really interesting. There's no reason you shouldn't be able to use it with Ionic as of Ionic 4, since we generally now support whatever framework you want to use (not just Angular anymore)

I'm not sure why TS wouldn't give you confidence. The compile process is simply stripping out the typing to JS.

I think they mean TS lets too much buggy code typecheck, as compared to Scala.

I don't think that's true. TypeScript's type system is very advanced, and has most of the features you need for type-safe development if you use strict mode (which is the default for projects created with `tsc --init`). It has ADTs, null safety, exhaustiveness checking and the LSP tooling is better than any other language I've tried. The biggest feature that's missing from Scala is HKTs, and even those can be faked in TS.

It doesn't have soundness.

This is by design, and rather well explained in the typescript documentation: the type system is based on structural subtyping, which seems like a good tradeoff to me (but of course, as any design choice, not everyone should agree, and it's fine).

Structural subtyping doesn't imply lack of soundness, OCaml object types have structural subtyping too and OCaml is sound.

I'd be hard pressed to say ADTs are first class citizens in Typescript. If anything, seems more like a hack over some interface primitives to me.

I miss having a solid advanced type system like in Haskell when using something like Typescript or Dart. Typescript feels mostly like Microsoft's attempt on converting Javascript to align more with C# to me.

(Ionic co-founder here) glad you're enjoying Ionic, we're working on a ton of stuff to improve it even more right now. Have you tried Capacitor yet, our Cordova alternative?

Sounds interesting. We’re looking into Cordova right now. Do you have a page which explains the benefits of this vs. Cordova?

Yep lots more info here: https://capacitor.ionicframework.com/docs/cordova

Also see some past blog posts with more: https://ionicframework.com/blog/announcing-capacitor-1-0/

I'm still using Ionic v3 with Cordova - assuming I try and migrate to Ionic v4, will I have to use a whole new set of plugins with Capacitor?

Not necessarily. Cordova plugin compatibility was designed in from the start. Unfortunately, some plugins relied on more obscure aspect s of Cordova and don’t work. We keep an updated list of incompatible plugins here: https://capacitor.ionicframework.com/docs/cordova/known-inco...

Yeah, looks like quite a few of the plugins i rely on are on that list :(

Which ones? We can see if there’s anything we can do about it

fcm/Firebase/qrscanner

Capacitor 2.0 should fix the XSS issue that Cordova has always had, and split the code between privileged code (backendish) and UI code.

Capacitor 1.1 turned off Electron security protections to make things work as they always have. As a new project, I was hoping for more.

In Capacitor 2 you have the opportunity to have the business logic run in a separate thread than the UI, and add the privileged code there. And such logic would not need to hold up the UI allowing for a smoother app.

One XSS in an iPhone app and maybe they own that app. One XSS in an Electron app and they wipe out your whole PC and life. There is a reason why Electron changed the defaults.

> React Native didn't support Typescript as a first-class citizen

As someone that uses TypeScript to death and works on react native as my job pretty happily, please explain this?

Also JSX is absolutely not a templating language, it's an extremely thin layer over JS.

Should have made the distinction clearer but I was just saying JSX _and_ Angular specific templates. The fact of JSX being an abstraction over the React API that equates to what the DOM _should_ look like is must easier to grep then defining them as literal code, imo.

When I used React Native with Typescript (this was about a year ago) the initial setup to get all of the types playing well together either wasn't clear from the documentation or I ended up debugging/writing custom definitions to get things to work. It just felt sidelined or treated as a second class citizen, but I feel like this has been a common theme throughout the life of React generally.

> equates to what the DOM _should_ look like is must easier to grep then defining them as literal code, imo

It's a common view but really quite a funny form of path dependence / mental fixedness. The fact that html elements have been defined with angle brackets is essentially historical accident. It's just a simple hierarchical structure that can be in any notation and any given programming language can happily support this already without new syntax. Yet because of the history, we feel more comfortable with some angle brackets and so we have all this redundant syntactic complexity in jsx/tsx which we would never design without the history.

I'd encourage you to be open minded for going to all code because although there will be an acclimatisation period as you break the historical connection, those familiar angle brackets are totally superfluous.

I've worked with frameworks like GWT and Vaadin enough to know I prefer the DOM way of doing things over visualizing the view through code. Hell, I've used the React programmatic API before I used JSX...never going back.

I much prefer React Native's (React) paradigm over Flutter's, but as a platform Flutter is just a lot more robust in my experience. Everything just works on it while RN has all kinds of weird quirks and issues, particularly when using libraries that have native code.

I chose to give up on RN at 0.59 and focus my efforts on getting really fluent at Flutter instead.

> as mature as [...] Cordova

Stopped reading there.

https://www.npmtrends.com/ionic-vs-quasar-framework-vs-react... at the moment react-native remains way ahead of ionic and quasar alternatives.

in real ionic is mainly about Angular while Quasar is mainly about Vue, so React Native must be mainly about React, which happens to be the largest framework comparing to Angular and Vue these days.

Assuming you are someone who thinks “number of downloads” is a proxy metric for “quality” or “developer experience” or “production ready”, maybe.

This isn't some Oracle or SAP product your boss bought and forced you to use it...

Downloads != actually using in “production”

Not discrediting RN, just calling out that the number of downloads is a terrible proxy metric for quality.

So looks like upgrading existing apps to RN 0.60 is going to be pain! Same old RN story. So many backwards incompatible changes.

Still a few bugs to iron out (esp. with React Native Maps) - but good work to the team on this one. The autolinking is a game changer. Also looking forward to giving Hermes a spin!

Past discussions:

- https://news.ycombinator.com/item?id=20344705 - https://news.ycombinator.com/item?id=20360060

Second one has no comments, not much of a discussion.

Well seen! I should have said "past posts" instead

Though what's the point of linking past posts if they have no discussion? It's not like anyone would want to post in a dead submission.

To demonstrate that the same story has been ashtray posted another 2 times within a span of roughly a week. It has little value to repost it a 3rd time again.

Edit: interestingly, the most recent re-post did gain some traction this time!

Reply on news.ycombinator.com