JavaScript becoming the lingua franca for mobile development
sdtimes.com
sdtimes.com
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.
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.
Especially considering that Twitter isn't either :-).
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...
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.
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.
It's constantly been improving for like 5-6 years, and it's still not there yet.
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.
You should choose the right tool for the job - that's it. That's neither stupid, lazy or complacent.
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.
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.
If your programming stack consists of 3-4 different languages, the mental maintenance required by the developers can become considerable. That number of languages is an inflection point. After that point is reached, you'll see resources directed to rewriting things in order to reduce the overhead, or the executives will end up creating new departments with different language requirements and roles.
It's not that people are lazy, complacent or stupid, it's that on average they can't retain multiple representations of the same thing in their head. If you search around, I think you'll find the average number of human languages known by any given person is between 2.5 and 2.8. Programming languages are no different than human languages.
As for languages - it's whatever you can compile.
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.
99% of TOP20 apps in each category are NDK apps, you like or not.
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?
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.
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...
It is even better that Moto G (200$ device without contract) has KitKat already.
I love it!
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."
Snooze.