Comment by t1amat | Hacker News Reader

Comment by t1amat | Hacker News Reader

Parent Full thread

I have been leading two React Native projects for most of 2017 with experience using the platform since early 2016. I would definitely recommend it today.

The two pain points have been 3rd party native modules and platform upgrades but both situations have improved greatly in the last year. Both the platform and the major 3rd party native modules have stabilized a lot, and platform upgrades are pretty easy via the react-native-git-upgrade tool.

I've used React Native with a number of languages: JavaScript, JavaScript + Flow, TypeScript and ClojureScript. All of the above, and soon, if not already, ReasonML, are viable language choices. My personal preference is TypeScript and ClojureScript.

The projects I have worked on professionally tend to be highly company branded with a common UI, and I am able to share ~100% of the JavaScript code-base between them (ignoring platform entry points).

An anecdote: recently one of the applications (React Native + TypeScript) was audited by a respected independent security consulting firm to rave reviews by the security team. On the spectrum of risk (Info, Low, Medium, High, Critical) the worst reported issue was a Medium that was due to the platform default ProGuard setting that disabled binary obfuscation for development; enabling required a 1 line config change.

This is a really solid answer. The point about ProGuard can especially bite you if you are adding React Native to an existing application.

Also, upgrading native dependencies in React Native is a really big pain point. The quality of Native modules also varies enormously.

An example react-native-camera:

https://github.com/lwansbrough/react-native-camera

Works well on iOS but has all sorts of performance problems on Android devices. Even newer ones.

One question I have is why did you prefer Typescript over flow? I have just started using the latter and I would be curious to hear your thoughts on the matter.

I'd also love to hear why ReasonML is good.

> I'd also love to hear why ReasonML is good.

Not the OP but I've spent the last couple weeks diving into ReasonML [1]. I'll give you the synopsis:

1. Type system is great. Way better than Flow/TypeScript in terms of both ergonomics (my opinion) and soundness

2. Comes out of the box ready to build React apps. Project init is very easy (there's reason-scripts for create-react-app and already boilerplate/generators for React Native apps as well).

2. Writing your own bindings for JavaScript code requires some elbow grease and semi-advanced knowledge of both OCaml and BuckleScript; harder than adding flow annotations or typescript definitions IMO. But once written, it's as easy as an `npm install` for everyone else.

3. Still lots of open questions and unfinished stories - especially around async programming. The built-in promise bindings kind of suck right now. I wrote bindings for Most.js [2] that I hope alleviates some of the pain for now until they get their head on straight.

I've spoken a lot with Cheng Lou and other people working on ReasonML in the discord channel, and they're just great - very helpful and friendly to a beginner like me. The community is small but very good. Feel free to hop in and ask questions and try it out!

[1] https://reasonml.github.io/

[2] https://github.com/Lokeh/bs-most

Great answer, thank you so much for writing it. Given all of the con's, would you advise building an app from scratch with ReasonML?

My main hesitation with stuff like this & Clojure is that the learning curve for React Native + the JS ecosystem is already pretty steep. Do I want to add another layer into the mix? For me personally, it would have to come with a big return on investment to justify the cost. I feel it would have to offer more than just an incremental improvement over flow/typescript.

An example: I'm considering synching some time into learning RxJS & ReactiveSwift. My reasoning is that Reactive programming helps eliminate certain types of bugs and makes it much easier to chain events together in a complex app.

I think if you (or your team) are not already comfortable with React and the JS ecosystem, ReasonML probably isn't for you right now. It's still a very leaky abstraction, with multiple layers. Often errors can occur that in order to decipher require knowledge of both Reason/OCaml, BuckleScript (the compiler), React and JavaScript. Adding React Native is another layer.

The ReasonML team are pretty amazing, though, and I do believe that they will rectify these problems quickly. A lot of effort is being put into documentation, error messages, tooling and design. The vision that they have for the project and the way they want people to be able to develop software is one that I admire and support. I'm putting in my own spare time to help them out, in the small ways I can.

Right now, though, I would honestly recommend ClojureScript before Reason. I do believe the maturity of that ecosystem really has hit the point where the gains (REPL, data-driven development, reagent + reframe + figwheel >>> react + redux + webpack, and CHANNELS!) outweigh the costs (unfamiliar language, unfamiliar ecosystem, additional layer of abstraction). I've built some internal tools using Electron + CLJS and it was great. Haven't messed around with using it and React Native yet but I know that the renatal [1] project has come a long way over a short period of time.

Your note about reactive programming is similar to the ReasonML vs CLJS vs JS conversation; reactive programming is great for certain things! But it comes at a cost; the abstraction makes certain problems harder and introduces it's own set of bugs (lifecycle bugs/crashes and memory leaks being the biggest one I've encountered with RxJS & RxJava), and can make your app code harder to reason about. Is it better than using callbacks or promises and imperative programming? Probably! Is it always? Nope! Are there other alternatives? Yes (CHANNELS!)

TL;DR: Not worth it right now; give it 6 months :D

[1] https://github.com/drapanjanas/re-natal

Great answer! Lots of food for thought. I'd love to hear more about any problems you have encountered with RxJS & RxJava.

> One question I have is why did you prefer Typescript over flow?

I don't want to start a holy war on this, as it's generally accepted that Flow's type system and inference is superior. I believe TypeScript is a generally better solution despite this, for other reasons. This is just the list I can come up with offhand:

Upsides for TypeScript:

* bigger community

* more definitions (This cannot be overstated; the gap is wide)

* great IDE tooling and support via language service

* great compiler

Downsides for Flow:

* less definitions

* smaller community

* .flowconfig is difficult to get right, and often requires hacks to pass type checking

* dodgy IDE support

* type discovery is more difficult

Thanks for this. I'm still relatively new to the Javascript world (mainly native developer) and I've only just started using flow.

Could you tell me a bit more about the following points:

* more definitions (This cannot be overstated; the gap is wide)

and

* great compiler

I'd love to hear more about this and or read some good articles comparing flow to typescript.

typescript wants to be in your project from day one

flow can be added to an existing project

i feel that almost everyone underestimates how important this is

This seems to be a common misconception. TypeScript can be added gradually as well with strict settings disabled, and supports JavaScript with a config setting. With Babel now supporting TypeScript[1], none of these arguments prevail.

[1]: https://www.npmjs.com/package/babel-preset-typescript

Reply on news.ycombinator.com