Code Sharing Research

(Crosspost from medium.com/@kpgalligan)

I never finish blog posts because I treat every one like it’s some grand research paper that should also touch you on an emotional level. I have again been told to just ship the little thought every day. Here’s today.

I’ve been pairing down the things I think will be important in the future for app development, which includes web. It’ll be kind of a 2+1 situation (2 mobile + 1 web), although I guess if reasonable, should do “native” desktop.

Most of the stuff gaining eyeballs is coming from the web world. The web world has been predicting native’s demise since native became a thing. So was I, till Facebook threw in the towel. I now think not having a mono-platform can be a good thing, and we should focus on being able to reasonably share code between them, and not get locked into English just because all the tourists are Americans.

Yes, that’s a shitty jab at Javascript.

Rather than getting into the identity politics of platform, I’ll just say I think there’s room for options. There’s no “best” way to do it.

I *do* think the trend of coming *from* web to mobile is not always great. I think the tech should push the other way. Mobile to web. “Offline first” works perfectly fine if you’re never offline. The other way around, not so much.

We’re separating the areas where one might share code into 3 tiers. UI, “biz logic”, and architecture. The last 2 often get lumped together, or solutions I see tend to be at extremes. Just biz logic, or EVERYTHING. This is interesting to me. For mobile specifically, architecture is a hard problem, and under the UI, iOS and Android are basically the same. Sharing architecture and biz logic gets you a lot of mileage for free.

Anyway, will expand on all that (in a different post). What I’m looking at now.

J2objc

If you know me, then you know this. I’ve been doing this for a while. It’s Doppl. Just go read that. The sample needs an update, which I’ll hopefully get to today, but its *really* nice out. Anyway. There are a lot of meaningful benefits to be found there, but I also see this as more of a bridge solution while other situations improve. Not that it should go away eventually, if it’s useful, but there are things coming that are a little more purpose-built for sharing.

Swift

Swift is a good language. You *can* compile it to Android, although somebody needs to write an interop layer. I can see how this would work. It may exist, but if I go google this now I won’t finish the blog post. If it does exist, its certainly not popular.

Swift has a large community and set of libraries. Swift is also becoming a great back end language. However, until web assembly becomes a serious thing, I don’t see much client web coming (swift for JS?). Essentially on the UI, its just Apple hardware. That makes obvious sense, but the community should be cooking up other stuff. I’ll be speaking at a Swift conference about that.

Kotlin

I first heard about Kotlin back in 2011, and we started using it in 2014. It’s great. However, nobody else was using it much, and I got very into Doppl, so I wound up in the reverse commute situation where everybody else got into Kotlin right when I was getting out of it.

I had avoided the concept of Kotlin as a shared language mostly because I was a fanperson deep down, and assumed I’d over-love too many of its plusses and ignore too many of its cons. However, if you’re a Java-ish shop, and that’s most of the world (kind of), this could be an amazing solution.

Java server code and Android code are a done deal. Not much to say there.

The JS code is, I’m told, really solid.

Kotlin native is going to take some time to finish, but Jetbrains is very serious about it, and the demos so far are pretty compelling. I hope they allow you to build a library that you can call from Swift/Objc rather than a full executable. That would be dog cookies.

Kotlin shared libraries on iOS would be the cookies. I’m the dog.

Rust

Sometimes you finally look at a thing that people are talking about and realize you don’t listen to people enough. I don’t know how easy actual coding would be on Rust, but I intend to find out. Just reading the basics of threading and safety is really exciting. I don’t 100% understand it, but I do understand the problems in other language contexts well enough to get the hint that they’re onto something.

I ran through a demo that compiles down to iOS and Android. I wouldn’t call it simple to do, and the interop code was certainly verbose, but both of those things can be solved with tooling and training. The lack of a runtime bloat was amazing. The library was super, super small on iOS. That was the big surprise. Also, since it makes libraries, you can share code relatively seamlessly (minus boilerplate, as mentioned).

Intellij has a decent plugin. Just make sure you’re on the newest Intellij (spent a while figuring out my mac doc was pointing at a very old version, but I digress).

I doubt the architecture side would be easy to share now. iOS/Android have very robust libraries dealing with mobile architecture. I assume if your language isn’t doing a lot of mobile, it probably doesn’t have a lot of mobile architecture libraries. However, that’s what coders do. Build things.

Obviously the web with Rust is problematic right now, but apparently, Rust is also one of the few languages that can output web assembly right now. I saw a post on that. I still don’t really believe it, but that’s what I read. Will need to verify. In any case, if not right now, very soon. It’ll be a while before there are threads and other things is wasm, but they’re apparently on the roadmap. It’s possible that wasm will just kind of fizzle out, but if it doesn’t, a whole lot of things might be changing in the (relatively) near future.

Anyway, Rust seems cool.

Changes

It’s hard to gauge how likely folks are to adopt a new language and/or platform. In the iOS and Android worlds, the community seems very receptive to Swift and Kotlin, respectively, but especially in the case of the latter, there is a disconnect between the “community”, which is for me the folks that actually bother to go to conferences, who are very much a self-selecting group that is excited about new things, and the bulk of the developer ecosystem. I don’t think there’s going to be a quick, wholesale move to Kotlin from Java, even though you can pretty much say Kotlin is better (drama!).

Similarly, we’re having lots of conversations with larger companies looking to consolidate their platform efforts. Although there may be better options, it’s a real struggle to push their existing teams to anything other than a web-like solution.

So, maybe Rust winds up being awesome, but a lot of orgs will wind up with React Native because the career engineers don’t really want to change everything, and maybe that’s not a problem. Depends on the situation.

One of the benefits of the Doppl stack, and soon Kotlin as well, is the possibility of having an existing Java server team also start working on the client architecture, to better design APIs. There are *a lot* of large orgs with large teams of career Java people. We’re experimenting with a split whereby those engineers kind of own the architecture from the cloud through the client, and other folks are focused on delivering UI on top of that to the various platforms. See how that goes.

UI

Right now this is a “don’t even go there” topic for me. Trying to have a unified UI on multiple platforms has never really gone well. There’s enough to work on below the UI, so I haven’t been thinking about this too much.

However, I *do* think what Facebook is doing in this area probably makes sense. Not the detailed libraries, but just the general “flexbox everywhere!” approach. Even if you’re largely replicating your UI code, having the same mental model for it will make things easier, rather than having several totally different ways of laying out your screen.

No real insights here. See how it goes.

In Summary

Nothing. Just need to wrap up the post and ship so I don’t overthink it. Its really nice out and we’re taking Binky for a lunch.

Binky is a dog, named after a horse