← Back to team overview

ubuntu-phone team mailing list archive

Re: Why js not c++?

 

On Thu, Oct 8, 2015 at 12:41 PM, Thomas Voß <thomas.voss@xxxxxxxxxxxxx>
wrote:

> On Thu, Oct 8, 2015 at 1:36 PM, Michi Henning
> <michi.henning@xxxxxxxxxxxxx> wrote:
> >> you can indeed build apps in C++ if you want, but C++ is more complex to
> >> understand and write (if you ever did a dynamic web page in your life
> >> you likely know the basics of js). C++ needs a (cross) compile
> >> environment set up while js means you can just dump a txt (well, .qml)
> >> file in place and it just works. Doing C++ is just a lot more work and
> >> while you can use C++ I think people find it easier to simply use js (I
> >> surely do, i can write a ready made QML app including rolling the click
> >> and uploading it to the store with a plain text editor within 20min, I
> >> (personally) cant do that in C++)) ...
> >
> > Writing a dynamic web page in C++ is a bit like writing a neural network
> in COBOL. Don't.
> >
> > Would I write a device driver in JS? Probably not.
> >
> > Would I try to tighten a Phillips head screw with a nail file? Probably
> not either.
> >
> > I think you get the drift… :-)
> >
>
> +1 :)
>
> Please note that qml and c++ components are happily mixed together
> with QML/Qt. If there is a serious performance issue with using pure
> QML,
> falling back to C++ is always possible.
>
>
Remember everyone, that Android apps launch pretty quickly, and they are
Java based
(and were only natively compiled with the release of Lollipop's ART).

This is achieved through the use of a "Zygote" process and some clever
copy-on-write
page management (I *think* using special kernel patches). There is always a
pre-warmed instance of the JVM ready, and it is forked each time a new app
/ service
wants to launch. The page copy-on-write behaviour allows a new JVM instance
to be
spawned with almost no effort to the phone (you only copy the memory if you
alter the
Java runtime libs in some way, which is uncommon) and comes with large
memory savings.

The summary of what I'm saying is the old adage "there are no slow
programming languages,
only slow programs". I think a lot of our app launch speed troubles could
be alleviated by
employing the same techniques that Google does. The answer to performance
issues
is rarely to "switch programming language", assuming you're using a
language that at
least has a JIT compiler.

-Pete

Follow ups

References