JavaScript becoming the lingua franca for mobile development(sdtimes.com)
sdtimes.com
JavaScript becoming the lingua franca for mobile development
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
21 comments
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.
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.
I have to agree - if anything there is a greater move away from JavaScript towards native platforms, although I think that C# via Unity and Xamarin.iOS/Xamarin.Android is gaining significant popularity. C++ does technically work on both iOS and Android, but I think its use outside of games is fairly small - Google has bold text on the NDK download page saying it won't be useful for many applications and Xcode's support isn't anywhere near as good as its support for Objective-C.
Very true about Xamarin - that has exploded in the last six months or so.
>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.
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.
"...but that doesn't mean the Twitter-clone will be profitable."
Especially considering that Twitter isn't either :-).
Especially considering that Twitter isn't either :-).
"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...
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...
I was talking about legal clones.
I think how easy your app is to clone depends more on your feature set and business model, than any choice in language. It's actually an advantage to use languages that make it easy to write your applications, since really, speed-to-market is the most important factor in selling software.
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.
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.
What about writing cross-platform UIs using HTML/JS for those parts that must display content (not necessary from web)?
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.
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.
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.
In 2 years there'll be a ton of Android users still not on KitKat.
Majority of users (almost 75%) today are on 4+ versions (http://developer.android.com/about/dashboards/index.html) which was released 2 years ago. Are you developing next facebook?
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.
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
1. http://www.youtube.com/watch?v=hQVTIJBZook
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.
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...
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.
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.
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?
Managers and executives often care about languages. It actually is pretty difficult to find developers who can easily pick up new languages. Most of the places I've worked at, the average number of languages known by individual developers was about 3. By the time I was 20 I had learned 13 (and 3 human languages). That's an exception.
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.
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.
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.
You should choose the right tool for the job - that's it. That's neither stupid, lazy or complacent.
>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.
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.
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.
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.
Well, it would be nice to get more reuse out of mobile code. Having to write a mobile app twice is a bit of a hassle.
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.
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.
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.
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.
99% of TOP20 apps in each category are NDK apps, you like or not.
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?
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?
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.
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.
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...
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...
Android NDK is primarily about native code, not language (except, possibly, for somehow language-related ABI like "C" calling convention or x86).
As for languages - it's whatever you can compile.
As for languages - it's whatever you can compile.
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.
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).
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
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.
It is even better that Moto G (200$ device without contract) has KitKat already.
Javascript will be the only language we talk about in this board in less than 2 years. Mark my words HN.
I love it!
I love it!
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.
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
HN without language wars? That would be extremely uncharacteristic.
[deleted]
In what world is Javascript "lightweight"?
Probably in Bizarro World [1]
[1] http://en.wikipedia.org/wiki/Bizarro_World
[1] http://en.wikipedia.org/wiki/Bizarro_World
actually javascript kind of sucks for mobile dev - unless of course you are a company pushing javascript for mobile dev.
One wonders if describing JS as a pidgin for mobile dev would be more accurate:
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."
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."
Somewhat off-topic, this is really a misuse of the term "lingua franca". If anything, the lingua franca of development is currently JSON/XML.
Are there any good examples of mobile apps made with JS?
Oh boy, another language war.
Snooze.
Snooze.
Had anyone used Duetto to make mobile apps?