
The state of Clojure on Android - Kuytu
http://blog.ndk.io/2015/04/23/state-of-coa.html
======
robinricard
This is a nice, complete and well-documented review of why Clojure is not made
for Android.

I disagree with the conclusion though: yeah, the classic JVM-clojure seems
doomed on Android. Why ? It's not made for that, it's made for servers, it's
not even used for desktop GUI programming that much. Even if we beat the
startup time, it's not likely that we'll get nice UI-bindings for Android
before a long time (I like the Java-interop but writing serious Android apps
with the interop alone seems awful to me) and yes, there are some libraries
abstracting this a little bit such as neko [1] but it's still too close to the
Java-development paradigms (it's not as clojure-ish as I wish, but that's my
opinon!).

So, the conclusion: no we don't need a swift for Android, and clojure is not
swift anyway.

iOS already has clojure support, it's not really stable but it has decent
startup times and a nice API. It's not the JVM-clojure, it's clojurescript.
The UI is managed by React Native and om. It works and you get a nice REPL
running too. [2] No it's not finished and has lots of bugs and it's not even
publishable on the AppStore for now but it's just a matter of weeks here
before addressing those problems (you can follow the work of David Nolen &
Mark Fikes on this particularly, they often communicate on what they're doing
but there are other awesome people working on this too!)

So for Android ? ReactNative is coming too [3]. When it's there, the community
will try the same thing as what they did on iOS, and it's likely to succeed
too. The community behind cljs is growing and it's becoming the main clojure
implementation for ui-related stuff. You can thank React and om for that but I
think that core.async has a lot to do with it too.

Anyway, I don't want to stop believing in Clojure for mobile development.

[1]: [https://github.com/clojure-android/neko](https://github.com/clojure-
android/neko) [2]: [https://github.com/omcljs/ambly/wiki/Driving-React-Native-
wi...](https://github.com/omcljs/ambly/wiki/Driving-React-Native-with-Om) [3]:
[https://facebook.github.io/react/blog/#when-is-react-
native-...](https://facebook.github.io/react/blog/#when-is-react-native-
android-coming)

~~~
zak_mc_kracken
> So, the conclusion: no we don't need a swift for Android,

I think we do, and to me, that language is Kotlin:

Analysis: [http://goo.gl/wNjXoU](http://goo.gl/wNjXoU)

The language: [http://kotlinlang.org](http://kotlinlang.org)

~~~
on_and_off
Kotlin also looks like the most serious contender to me. Sure, something like
Rust might be more interesting for various reasons, but the engineering effort
needed to port the Android framework to another language would be huge (and
the official word from the Android framework team is that it is not worth the
effort). Not to mention that third party developers would have to relearn the
framework from scratch and that we either have a windows mobile 6 / WP7 rift
or the framework team has another nightmarish problem to solve. Kotlin looks
like it could both guarantee retro-compatibility with Dalvik and brings a
better language to the platform.

------
th0br0
From a user perspective, I find the statement that "Lean Clojure" works based
off these charts a bit daring. Why?

a) Without having access to the numbers, (Skummet) startup is ~5 times as slow
as the Java version. That is a noticeable difference. Plus, even Java apps
sometimes tend to take a second or more to start up if they're reasonably
complex.

b) The "Lean Clojure works" statement is derived from comparing _only_ the
startup times. The fact that the task time is around two times Java's for
Skummet is a big thing. Ignoring startup time, and without further data/tests,
one could argue that Clojure Android apps run twice as slow as Java ones...
that's a big no-go given the high amount of sparkly UI features of most modern
apps. Or at least a no-go for having a Clojure-only stack?

(Skummet's probably in its early stages and I'd expect improvements but ...
from those graph I'd argue 'Lean Clojure' does not work (yet?))

~~~
hoodunit
To clarify my statement: the idea of lean Clojure for making Clojure viable
for Android development basically works. More static compilation of vars
dramatically reduced startup times; I think further "lean Clojure" changes
like dependency shaking would bring equally dramatic improvements. I'm
handwaving a bit here at the challenges involved in making further changes,
but the direction seems quite promising, at least for reducing startup times.

General performance is more difficult to speak for. If it is within a factor
of two of Java that seems pretty similar to Clojure vs Java on the desktop and
is a tradeoff many are willing to make. It's also true that Clojure relies
heavily on Java libraries and Android app performance is highly dependent on
underlying library and native performance. So basically for run time
performance I don't think the performance of Clojure itself is the most
significant factor.

------
cp9
At clojure/west Zachary Kim had a talk about the state of mobile app dev in
clojure [0].

[0]:
[https://www.youtube.com/watch?v=AgjRo54ImUMa](https://www.youtube.com/watch?v=AgjRo54ImUMa)

------
daniel_solano
So, I've been involved on Clojure/Android for a long time. I really like what
Alexander has done with Skummet, and I think there is still room for
improvement. However, I have to wonder to what extent is it good enough?

I use a lot of applications which have terrible load times. Some of these may
be native, others are probably using some sort of cross-platform development
framework. While I would prefer better performance, I am coming to the
conclusion that startup time really isn't an absolute deal-breaker for a lot
of people.

