React native sucks! Why is building a react native project for iOS on an ARM-based Mac so hard? The same setup works on an Intel-based Mac without issues.
Also: Why is there no script to install and configure homebrew, node, watchman, yarn, rbenv & ruby, cocoapods, … from scratch?

Why the fuck do you need Ruby for react-native?

I don't know about iOS, react native on android was also. a pain but I write it up to the interaction of java and js

I think Android is the best possible example why languages that are substantially higher level than C are terrible for defining OS APIs.

@lorentz There's a tool called "CocoaPods" which is a dependency management system for Objective-C and Swift. CocoaPods is written in and inspired by Ruby. You need it because react native still needs a whole bunch of native bindings for various things, and that's how it gets them. It's the same for Android, except it's handled by Gradle.

@lorentz expand on the Android being the best possible example. Not trying to contest your stance on this, cuz I hate Android development. But I wanna know more about your input on it.

@AleCx04 When you develop an app for Linux, MacOS, Windows or any of the normal targets, you get to choose from several completely self-governed toolchains that can evolve fast because they only share the operating system ABI and API, and what's intrinsic to modern computers.

When you develop an app for Android or the web, although the choice of language is still there, you also have to interact with a lot of abstractions that are different from your own and not intrinsic to the way computers work. No matter what language you develop an Android app in, there will always be Java code even if it's hidden from you, and some things will always only be possible in Java. For example, in order to expose distinct entry points for other applications via intents you always need to subclass Activity.

It is possible to generate this Java code according to abstractions in the source language, but the toolchain is still there with its platform peculiarities, performance costs and expected use cases. If the API is defined extremely close to the hardware in something like C, the performance costs are much lower and the toolchain gets to define the abstractions according to its own internal logic.

@AleCx04 I think Javascript on the web is just as bad by the way, but building perfect sandboxes to run totally untrusted code is hard and it wasn't originally expected to be so popular so I don't really blame it. Android was always meant to be an OS and app development was always expected to require tooling.

@lorentz was the choice of language always there for Android though? While support for inner workings of the system in C++ is present on the Android API, I was under the impression that Java (and now Kotlin) were specifically the target languages for the platform. Sure, we can touch the bare metal of the operating system with C++, and wrap them up by making them accessible to Java, but the target has always been Java specifically (again, Kotlin now) which would mean why using other tools such as NativeScript or React Native would be a pain in one way or another, they are designed to somehow consume the underlying api, but not necessarily replace it.

@AleCx04 That is the decision I'm criticizing. I'm saying exactly that because they were making an OS - an extremely general piece of software that can't possibly keep up with the latest and greatest high level languages - they should've defined the API more specifically with lower level concepts that can be consumed from any language.

I also agree with you on this. I used it on iOS but it doesn't work.

@lorentz aaaaaaaaah okok I get you know. That seems fair/reasonable to me.

@lorentz Ruby is required by CocoaPods

Just build a static HTML based site and add lightweight JavaScript enhancements on top of it. No need for heavy slow-loading frameworks and no risk of one little JS exception resulting in a blank page.

Your users will thank you.