
JavaScript becoming the lingua franca for mobile development - cmulligan
http://www.sdtimes.com/JAVASCRIPT_BECOMING_THE_LINGUA_FRANCA_FOR_MOBILE_DEVELOPMENT/By_Christina_Mulligan/About_JAVASCRIPT_and_APPCELERATOR_and_IDC_and_MOBILEDEVELOPMENT_and_LINGUAFRANCA/67508
======
sjtgraham
"JavaScript becoming the lingua franca for mobile development" says a report
commissioned by a company hawking a mobile framework where the API is…
JavaScript.

~~~
jmspring
When you have a hammer...

------
fidotron
Not just being a contrarian, but really?

I could swear it's C++, and I hate C++. One major factor is it runs on all
environments, including via asm.js if you are inclined that way.

It might be true that most apps end up written in other things, but the most
money will be made from C++, C# (via Unity) and ObjC. If your app is too easy
to write it will be cloned and you won't make money from it anyway.

~~~
nawitus
>If your app is too easy to write it will be cloned and you won't make money
from it anyway.

That's a bit oversimplification. First of all, writing in JavaScript doesn't
make the app easier to clone, the programming language has very little effect
on the easiness of cloning. Secondly, even if an application can be re-
implemented quickly, doesn't mean one cannot make money from it. Twitter can
be implemented in a single weekend, but that doesn't mean the Twitter-clone
will be profitable.

~~~
al2o3cr
"First of all, writing in JavaScript doesn't make the app easier to clone"

Yep, shipping the source code for your entire application _IN_ the application
doesn't make it any easier to clone. Somebody better tell that to the Phonegap
users who are dealing with knockoffs:

[http://www.tuaw.com/2012/02/17/ripoff-apps-plague-some-
ios-d...](http://www.tuaw.com/2012/02/17/ripoff-apps-plague-some-ios-
developers/)

~~~
nawitus
I was talking about legal clones.

------
charlesdm
For apps that just display content, sure. Those are essentially nothing more
than glorified web apps.

For apps with specific functionalities, no way. A combination of Java (for
Android) and Objective-C (for iOS) with potentially some C++ under the hood to
easily share logic code between platforms. C and C++ are pretty much the only
languages that run on all those platforms (out of the box). Obviously you can
get any language running on any platform, given enough time.

~~~
daliusd
What about writing cross-platform UIs using HTML/JS for those parts that must
display content (not necessary from web)?

~~~
charlesdm
While I think as a concept it's absolutely great, I'm still not that happy
with their actual results and performance. Things have certainly improved over
the last years, with iOS moving closer towards Android by using flat design.

If you're targeting high end devices (which is easier when targeting iOS than
Android) it's probably pretty good for UI stuff. The problem usually lies with
the lower end Android handsets. That said, most of these pure HTML/JS apps are
pure junk when comparing them to a well developed native app. Depends what the
business objectives of the app are, I guess.

~~~
daliusd
What about looking at long term? Android 4.4 (KitKat) uses Chromium engine for
WebView. On Moto G 200$ device it works like a charm. In 2 years everyone will
have Chromium on their phone.

~~~
charlesdm
Sure, in 2 years. That's still a pretty long time.

It's constantly been improving for like 5-6 years, and it's still not there
yet.

~~~
daliusd
What do you mean not there? I have Moto G with Chromium based WebView NOW.

------
coldcode
JS is a terrible language that nonetheless has wound up being everywhere. But
despite its shortcomings as a language it is extremely flexible in what you
can do (abuse) it with and that is probably its biggest advantage.

~~~
nawitus
Most critics of JavaScript don't know the good parts[1]. Sure, JavaScript has
problems, but convention and static analysis fixes a lot of it. In addition,
you can use something like TypeScript if you don't prefer dynamic typing. And
it must be said that JavaScript does some things better than C++/C#/Java, e.g.
functions. These languages are only now starting to catch up.

1\.
[http://www.youtube.com/watch?v=hQVTIJBZook](http://www.youtube.com/watch?v=hQVTIJBZook)

~~~
reirob
Thanks for posting the link to the video. Just watched it, total of 1 hour -
was really worth it for me. Increased a bit my love for JavaScript.

------
bengotow
Hah - what a joke. Stopped reading when I got to the second line:
“[Javascript's] ability to render rich results from lightweight, simple-to-
learn languages has made it a natural fit for mobile’s speed of development,”
according to Appcelerator." I take it the developers polled for this article
are the ones on Appcelerator's mailing list...

------
puppetmaster3
From engineering POV JavaScript is more effective, for example w/ cross
platform PhoneGap.

Say you have a $2M eng budget for start up round A for 2 years, so $1M per
year. 1/2 goes to services/back end dev and ops. So $500K for front end. 3
platfroms, Web/mobile web, Android, IOS, so 3 developers ~ 150k. I recommend
you get 3 HTML/js devs.

If you get 1 per platform: vacation/sick time, turn over, management
difficulty, lack of oversight, pain. Just let the compilers do the work.

------
laichzeit0
Why do people even care about languages? I've written code in dozens of
imperative, object oriented and functional languages and really can't see what
the fuss is about. It takes a few days to get comfortable with a new syntax
and then you're back to looking up library documentation and gluing pieces
together. Learning a new syntax is a fraction of the time spent writing an
application. Are people just lazy, complacent or stupid?

~~~
daliusd
People want to write the same app once: not one version for iOS, another for
Android and third for something else. JavaScript seems moving towards that.
Qt/QML is another choice that is available now but Qt has its own problems.

You should choose the right tool for the job - that's it. That's neither
stupid, lazy or complacent.

~~~
reddit_clone
>Qt has its own problems

Could you elaborate on that?

I was excited a few days back that iOS/Android is now supported by Qt/C++. I
found that it still doesn't support the QtQuick Controls on mobiles. That
dampened my enthusiasm a bit.

~~~
daliusd
LGPL is one. It is quite permissive license but it has its own little
problems.

HTML is another one. HTML gets better support on iOS and Android and there
will be no reason to use something else in the future. It is much better when
your app is small than it takes extra 12Mb (Qt libs).

There might be other little reasons why it might not fit for you because of
technological reasons. Weight Qt against your requirements well.

I really like Qt/QML but it is not good for everything.

------
dschiptsov
Nonsense. For Android it is _NDK_ (which is why it is _possible_ to build nice
apps, like FB client) which is C[++], for iOS it is ObjC. Other platforms
cannot be considered seriously in 2014.

~~~
Skinney
The Android NDK is usually used for applications that don't use the Android
API's (which are all Java). Most applications on Android is written in a JVM-
based language. The sort of applications that would typically use the NDK are
games, emulators, VMs (like Xamarin.Android) and the like.

ObjC is also slow. Anytime you write something performance sensitive in ObjC,
you usually drop down to pure C or pure C++. Luckily, since valid C is valid
ObjC, this is rather easy.

Javascript and HTML is actually a great fit for mobile, but there are two
complications. 1) You will have to mimick the UI of the native platform. 2)
Mobile platforms have sub-par JS engines. iOS don't allow JITs outside Safari
(even when you use a webview in your ObjC app) which in turn makes JS-based
apps in iOS slow. Android has in general had a pretty sucky webview, but that
is getting fixed in 4.4 with chromium being the default engine.

JS is getting better everyday on the mobile though, I would be surprised if
not alot of people were using JS for apps in the coming years.

~~~
dschiptsov
This is exactly what those marketing guys have said. In so-called objective
reality 99% of apps people are using, such as FB, Adobe reader, Skype,
WhatsApp, you name it, are NDK apps.

99% of TOP20 apps _in each category_ are NDK apps, you like or not.

~~~
Skinney
All those apps uses the native GUI of the platform, which means they have to
use the SDK. Why FB would even consider using the NDK is beyond me, as the FB
app is simply a frontend over a web-api, and since you already have a HTTP
library in the SDK, the NDK holds little value.

The only app on the list that could benefit alot from the NDK would be Adobe
reader, but even Adobe uses the native UI to a great extent, so it uses the
SDK as well. The other apps are (I assume, as that would be easiest) simple
clients to a backend server. There wouldn't be much benefit in using the NDK
for these apps, as they mostly are a combination of UI and TCP/HTTP which are
included in the SDK anyway.

Btw, any source that these apps actually use the NDK?

~~~
dschiptsov
OK, I will try to explain. The problem with Java is that it doesn't actually
fits for mobile development (or any sane development at all) being just a
buzzword, a bubble inflated by corporate money.

Consider the very basics of system architecture. There is something called
ABI, which defines how syscalls are used and implemented. Android uses its own
ABI which is a flavor of Linux ABI for ARM architecture (actually it supports
different ARM chips and even x86, but it doesn't matter).

According to these ABIs we perform syscall as it is in a Linux system. So,
when we do Math we actually call procedures from libm.so, when we do crypto we
call libssl.so (from OpenSSL) etc. It also has its own variant of libc.so and
implementation of OpenGL ES, as one could guess, libGL.so.

How does Java fits here? Well, according to original concept, it ought to be
an isolated VM on top of any OS, which supposed to be run everywhere, and
everything must be written (once) in pure Java.

Because of that brilliant idea to simply ignore what an OS provides, they have
re-implemented everything its own, _proper_ way - famous Strings, Calendar,
UTF-32, you name it.

So-called reality, however, imposed some necessary corrections, and the kluge
called JNI was added. It allows to break the purity and, using ugly and very
inefficient mechanisms, dlload and call OS and third-party libraries.

What we have in Android is, basically, a bunch of JNI calls to Android Runtime
(libart.so, if I got it correctly) which is, not surprisingly, have nothing to
do with Java. I am not an expert to tell how the bytecode translator (dx)
works, but it doesn't really matter.

Why do Android has Java at all? The answer is quite simple - because it is
such a huge buzzword, such a great scam. It was the way to gain attention of
ignorant masses^W^Wmillions of coders. "Wait, Java? Sounds familiar!" (The
very same idea to play the Javascript card with WebOS have died, thank god.)

So, the developers of complex (read: real-world) apps such as FB have realized
that this unnecessary Java layer can't be used for anything but hello-words or
http-get-post apps, and that it is much easier to avoid Java at all (what's
the point to have the overhead of all that JNI calls), because, one could see,
it is just an unnecessary, artificial layer which doesn't fit anywhere (except
manager's presentations).

I probably missed some details, but I am not an Android expert.

~~~
Skinney
This again, is wrong. Android was made to run managed code from the beginning,
it's designed around that very fact. Let me try to enlighten you.

In Android, every process spins up its own Dalvik VM. Yes, Dalvik VM, not Java
VM, as Android doesn't run Java. The android development tools does contain a
Java Bytecode to Dalvic Bytecode converter (dex), which is why JVM based
languages run on Android, as long as you don't generate Java bytecode on the
fly (which several dynamic languages do).

Anyway, each process spins up it's own Dalvik VM, which get's to run your
Application. There really isn't any exception to this, which means that even
if you create a program using the NDK, you will still need to do some Java to
set up an activity that in turn runs the native code.

Because calling native code through a foreign function interface (FFI, known
as JNI on the JVM) creates some overhead, Android does as little of this as
possible. This is why most the UI API is implemended directly in Java/Dalvik-
Bytecode, and only the low-level drawing API is in native code (or implemented
directly in the VM, not certain).

If you program an app using only the NDK, you therefore won't have access to
the native UI API, meaning you will have to write glue-code to call the Java
API, or use your own GUI API (like Qt).

> Because of that brilliant idea to simply ignore what an OS provides, they
> have re-implemented everything its own, proper way - famous Strings,
> Calendar, UTF-32, you name it.

Right... So normally, out of the box, you will have access to wchar, socket,
time.h and math.h. You don't really re-implement this in the JVM, you write
bindings to the low-level functions, and then write abstractions (UTF-16,
Strings, DateTime ...) on top of that. The actual bindings are usually
generated using Swing or something like that.

> So, the developers of complex (read: real-world) apps such as FB have
> realized that this unnecessary Java layer can't be used for anything ...

Hopefully, I've been able to explain why cutting out the Dalvik/Java layer
brings more pain than it's worth. Most applications on Android are running on
the Dalvik/Java VM. The exceptions are VMs (Like Xamarin.Android) and OpenGL
applications, like games, which require more fine grained controll of memory
allocations to avoid garbage collections in the middle of a render-loop.

Just in case you are not convinced, here is Google's own warning on the use of
the NDK for app development.

"Before downloading the NDK, you should understand that the NDK will not
benefit most apps. As a developer, you need to balance its benefits against
its drawbacks. Notably, using native code on Android generally does not result
in a noticable performance improvement, but it always increases your app
complexity. In general, you should only use the NDK if it is essential to your
app—never because you simply prefer to program in C/C++."

P.S: Facebook did use HTML/JS for their app for a while, but switched to the
native SDK because the HTML-based app was to slow. The native SDK (Java) seems
to suit them just fine.

P.P.S: Check out this link to see why using the NDK is a pain in the
____.[https://mflerackers.wordpress.com/2013/08/25/using-the-
ndk-a...](https://mflerackers.wordpress.com/2013/08/25/using-the-ndk-and-jni-
to-build-android-applications/)

------
jeswin
SD Times submissions are becoming a little spammy. To maintain HN's discussion
quality, please submit original articles and try to link directly to the
original. While it is totally fine to submit your own (or your company's)
articles, the point of HN is to have great discussions.

------
Tloewald
Bear in mind that Appcelerator is really targeting the Enterprise market, and
Enterprise folk are used to sluggish, ugly, non-native applications (and
_cough_ sluggish, buggy development tools).

------
volaski
I actually gave up on jS + html5 to build apps. Do you know why? The main
selling point was "It's cross platform!", but with iOS7 and Android UI
diverging away from each other, this "cross platform" thing is not really true
anymore. sure you could make an app with shitty UI that's cross platform, but
you really want to do that? Maybe for games, but for rest of the apps, this
"HTML5 is the future" is over in my opinion

------
daliusd
I have really started considering JavaScript with KitKat as WebView uses
Chromium engine in KitKat.

It is even better that Moto G (200$ device without contract) has KitKat
already.

------
ulisesrmzroche
Javascript will be the only language we talk about in this board in less than
2 years. Mark my words HN.

I love it!

~~~
tcgv
I really enjoy programming in javascript too. I use it mostly for user
interface development in web applications. However, I try to avoid using it in
large projects because I personally believe strongly typed languages are
better suited for handling large code bases.

~~~
michaelwww
I'm wrapping my JavaScript in a TypeScript "facade" to get some of the
benefits of type checking and advanced IDE support in a large project. Works
for me

------
ouggnay
In what world is Javascript "lightweight"?

~~~
tcgv
Probably in Bizarro World [1]

[1]
[http://en.wikipedia.org/wiki/Bizarro_World](http://en.wikipedia.org/wiki/Bizarro_World)

------
academicish
actually javascript kind of sucks for mobile dev - unless of course you are a
company pushing javascript for mobile dev.

------
al2o3cr
One wonders if describing JS as a pidgin for mobile dev would be more
accurate:

[http://en.wikipedia.org/wiki/Pidgin](http://en.wikipedia.org/wiki/Pidgin)

"A pidgin is not the native language of any speech community, but is instead
learned as a second language."

------
Tloewald
Somewhat off-topic, this is really a misuse of the term "lingua franca". If
anything, the lingua franca of development is currently JSON/XML.

------
m1117
Are there any good examples of mobile apps made with JS?

------
mooreds
Oh boy, another language war.

Snooze.

------
jbeja
Had anyone used Duetto to make mobile apps?

