Publishing an iOS App with ClojureScript and React Native | Hacker News Reader

Publishing an iOS App with ClojureScript and React Native

increasinglyfunctional.com

76 pointsspinningarrow30 comments

> Pros > Functional Reactive Programming

Is this still a pro? Reactive programming is very popular in Native Android development and I assume as well on iOS with RxSwift and similar libraries.

I worked on a React Native app for a while and am sure to never return to it. Constant breaking changes, bad/lacking native implementations, and hacky ways of implementing natively supported features like Dialogs/Bottomsheets on Android make it a no-go.

In my experience React Native is wonderful for iOS and nowhere near as good for Android.

I find the constant breaking changes troublesome as well. I've never seen that with another framework and am hoping that things converge towards stability.

RxJava and RxSwift are Reactive Programming, not Functional Reactive Programming. FRP includes behaviors and hence truly continuous values and intercepts. RP has to use subjects, side effects, hot and cold observables and other nonsense. They’re quite different even though most online commenters tend to be unaware that there is a difference.

RxJava's Github says "RxJava is a Java VM implementation of Reactive Extensions". The Reactive Extensions website claims it is "Functional: Avoid intricate stateful programs, using clean input/output functions over observable streams." You're saying that it's not?

I really enjoy Clojurescript + React Native as well. Re-Frame + Hiccup is way better than redux + JSX. I'm pretty sure I can write equivalent apps with 50% less code compared to the Redux/UI boilerplate in most React apps.

Yup, ClojureScript with re-frame is literally about half the code of the equivalent React and Js https://medium.com/walmartlabs/performance-monitoring-with-r...

To add one data point; I rewrote one of our applications that was Redux+React+Typescript with exact feature parity in Re_Frame+Reagent+Clojurescript. It was 4.7x less code. We continued development on the cljs app and abandoned the typescript app. Months later the app is ~17,000 LOC. I shutter to think how the equivalent typescript would have turned out.

Redux is verbose but there are far less verbose options for React+Typescript.

I find clojure/script to be too dense for my taste in most examples. I actually really prefer a few more LoC, so that's a poor metric for effectiveness. Your IDE can deliver far more savings in time while encouraging more LoC often.

Your taste has nothing to do with effectiveness. There's plenty of evidence that loc are one of the most reliable predictors of # of bugs in a codebase.

I can make a one line program, I wonder how many bugs that would eliminate?

You don't have to write dense code in ClojureScript. Most functions I write are general purpose and end up being 5 ~ 10 lines of code.

These general purpose functions can then be composed to do declarative data transformations. This results in code that's largely declarative where what's being done is decoupled from how it's done.

It's not just about having less code, but about eliminating noise and incidental code. My experience is that ClojureScript does a very good job in this regard compared to most alternatives such as TypeScript.

It's denser because there are so many lines of assignment statements in other languages. Though the temp vars provide some form of documentation, I still prefer to focus on compositions of pure functions and tests.

Currently using a similar stack with Expo and it has been great.

There is no substitute for a real REPL and immediate code changes.

have you been able to keep up with expo sdk releases?

I have a cljsrn app still on expo 23 and it's turned into kind of a trainwreck to update. considering dropping expo for vanilla re-natal

detaching from expo and pulling out all the expo bits is pretty tough. you dont know what is needed and what isnt, and you have to find replacements for all your expo handy apis, OTA updates, ios/android standalone builds, and push notifications

Well luckily I started with a version that was not that hard to update as of yet.

I expect it to get harder though but this being a side project I'm not that worried.

Related: has anyone published an Android app with ClojureScript and React Native? How much did the fact, that React Native for Android is incompatible with 3rd-party 64-bit libraries[1] affect the development?

[1] https://github.com/facebook/react-native/issues/2814

I hope React Native matures into a powerful and ubiquitous tool. I love React, but my experiences with React Native have been incredibly frustrating. If a client wants a multi-platform app, I can get a smoother more consistent experience from Cordova/React than React Native.

Is there an easy way to do this iOS development on an Linux platform? I have a Macbook Retina from 2012 that's a pain to use because the battery will die unless plugged in, and they don't offer replacement batteries for my model.

My next option is to put MacOS on a VM in Arch Linux, but ideally I'd like an easier solution before I go down that route...

Have you tried Expo? It allows you to develop directly on your iPhone, with the development server happily running on Windows or Linux.

The easiest way to try it is at https://snack.expo.io/ , which is an in-browser dev environment for React Native. All you need is the Expo app on your iPhone or Android.

Disclaimer: Expo supports my work on React Navigation, the JS navigation framework for React Native. But I would recommend them regardless!

Not an answer to your question, but it seems like ifixit.com sells batteries for your model.

React Native is fine for small, standalone apps. Don't ever try to integrate it into an existing native app. Better to stick to 100% native or rewrite it completely.

I integrated it in a top-100 app in the app store in less than a day and it works perfectly for us.

If you don't know the iOS or Android build chains I would imagine that its confusing and troublesome, but unless you are doing some fairly extensive native compatibility stuff you will reap great efficiency benefits from adding it to an existing app.

> integrated it in a top-100 app

Same. Been leading the native side of an app with 30-40 native devs and ~20 JS devs. Initial integration is easy, but it opens up a lot of problems as time goes on.

Last time I tried ClojureScript, I found the interop with web APIs and vanilla js libraries to be horribly lacking, and development was abysmally slow as a result.

I loved Clojure when I used it, but ClojureScript was a nightmare.

The only saving grace was shadow-cljs, which made it bearable to work with. I eventually dropped it in favor of Elm mostly for the static typing, but also for the tooling, which is leaps and bounds better.

My team has the opposite experience. We've been using ClojureScript on the front-end for over 3 years now, and it's been fantastic. We use Leiningen with Figwheel, and it's by far the most productive workflow that I've seen in any mainstream language. You make changes and you see the results instantly. You also have an editor integrated REPL, so you can explore and try things live. You get things like code pruning and minification out of the box thanks to leveraging Google Closure compiler, and access to the Closure standard library which is quite comprehensive in itself. Meanwhile, tools like re-frame-10x https://github.com/Day8/re-frame-10x provide a great way to inspect the state of the app during development.

I'm not really sure what you mean regarding the interop either. It works quite seamlessly in my experience, and it's much easier to do than it is in Elm where you have to use ports, and keep all your interop at the edges.

If your main problem was interop with vanilla JS libs how can Elm possibly be an improvement over Clojurescript?

because ports actually work as documented, even if their functionality is limited.

kewl, downvoted because people disagree with me. yay, we've become reddit apparently.

Reply on news.ycombinator.com