Approaching React Native

[priand]

As a React developer, I love this library and the concepts behind it. Great job!

To make it even more appealing, it would be great to have an iOS version of it based on multi-os-engine (https://multi-os-engine.org/), which is Java on iOS. It should not be very hard to do, I might start that if I find time.

Now, Anvil is different from React with a different API. Have you thought about making it closer to React, with a base Component class, a component state, cloning the react native component library... The idea is to facilitate the migration of existing react code (like https://nativebase.io/) and drag the community to the technology.

[zserge]

@priand Hi and thanks for giving Anvil a try!

Anvil has gone a long way moving away from React (and Mithril) concepts because of the Android limitations. Unfortunately, if we rely on a virtual tree diff - we will end up with lots of garbage produced, and the whole rendering process will be much slower (comparing to the incremental DOM approach).

And we only look at the syntax - I believe Anvil has certain benefits. For example, lambdas are not as compact in JS as they are in Kotlin, and it looks like that have bigger cost. Anyway, they are not part of the React API, which forces developers to write ugly ternary operators instead of if/else and totally avoid for-loops, using map instead (which is also missing in Java). On the other hand, JS has very good-looking objects and one can initialize a dynamic object with properties easily, which is impossible in Java or Kotlin. That's why something that looks naturally in JS is unlikely to work in Java and absolute API compatibility is very unlikely (or very hard to achieve):

// React:
h('div', {foo: (isFoo ? 'bar' : 'baz')}, childViews.map(....))
// Anvil/Kotlin
someLayout {
  if (isFoo) {
    foo("bar")
  } else {
    foo("baz")
  }
 for (child in childViews) {
    someView {
      text(child.text)
    }
 }
}

Anvil's approach does not create temporary collections (unlike map) and basically patches view properties on the fly, which gave us something like a 5-7x performance boost in the past: http://zserge.com/blog/anvil-breaking-changes.html

Speaking of the iOS support - I'm all for it, and I believe Swift is a nice little language with plenty of syntax sugar to build Anvil DSL upon. The problems here are on a much deeper level - I have close to zero knowledge of iOS, and it looks like there is no easy way to do reflection (e.g. to collect a list of all views and their properties). Generated DSL seems to be the most critical component of Anvil, and unlike HTML DOM where all elements share the same, small set of properties, in iOS views differ a lot and their properties can be set in a number of different ways.

Multi-os-engine looks interesting, and I will have a look into it. Although, I doubt I would use something like this in production (although we have been using Anvil for years now). Looks like it creates UI with storyboards and then only generate Java bindings. Anvil, on the other hand, suggests to build UI in code (like React does), which seems to be impossible with Multi-OS-Engine.

That being said, for the first question - the answer is probably, 'no'. Anvil is as native as it can get (resulting in tiny APK sizes, unlike React Native and very simple internals, which anyone can explore or debug). For the second question the answer is "I'd love to!", but I need help from some really smart iOS developers (because I believe a native solution would be the best).

[priand]

Thanks for your reply.
I understand the technical advantages/design of Anvil and how it fits well with Java/Kotlin. My point is more on 'how to make it look like React Native', even if the internal implementation is very different. It will have a greater chance of adoption if React developers feel at home by just looking at the code. Moreover, ReactNative starts to have a pretty impressive eco system of add-ons, so making it easy to port them to Anvil will help.
MOE is Java on iOS, through an AOT compiler and the Android Art library, and Java bindings to the whole Cocoa library. In short, you code in Java or Kotlin the same way you would code in Swift. You don't have to use storyboards, you can definitively code to the low level API.
With MOE and some cross platform components, we could share most of the application code between the two platforms. All Java.
BTW, https://discuss.multi-os-engine.org/t/anvil-a-react-native-like-library/1014