Using HTML5 enables the operating system to be very lean and it requires less memory consumption.
This claim is deeply suspect.
This claim is deeply suspect.
Android is barely usable on these devices. Firefox OS run really well.
But of course I'm biaised, I spent a bit too much time on this project ;)
And worst of all (or best?) is that it seems we are moving towards this thing where Mono and Qt are also on phones, meaning you have two parallel stacks - one interpreter and one big ass shared library or another interpreter - running at once.
Yes, while you can build a kernel+libc+binary code application that is pretty lean, that means that your kernel plus graphics stack need to handle both that type of application, as well as a web browser and related content.
In some cases, having to handle just one of those opens up optimization opportunities, either in the kernel, libc, or the graphics stack. If you can run only native binaries using a single graphics method, that might be overall leanest, but every phone needs a browser these days. So the only other option to have a single thing to optimize for is to make the only stack the web stack.
Then, whatever is optimal for the browser in terms of handling GPU textures, as one example, you can just do, because nothing else needs to run as well.
kernel + libc + luajit == *ahem*Correct, but likewise there's no good reason for (linux + android hal + web) to require /less/ ram than (linux + android hal + dalvik and java toolkit).
Even if we accept the claim that most of the time on Android you have both dalvik and webkit loaded at once, whereas on B2G you only have gecko running, claiming that this necessarily means that B2G uses less memory is akin to claiming that
x + y > z
for arbitrary values of x, y, and z, which is obviously silly.
But I don't need to tell you that this claim that B2G uses less memory by design was a major frustration to me back when I owned B2G memory usage. :) If FFOS is small, it's because you and I and others worked really hard to make it so.
Is anyone really surprised that Java is not so good for interactive applications? It's never been in first place for that type of app.
If anything, Applets is still to an extent responsible for a lot of the negative opinions of Java's performance and suitability for interactive applications.
Also, doing things in separate threads means that scheduling of tasks also causes pauses in execution.
Umm, JavaScript and DOM/HTML have the exact same problem except it's magnified by the fact that the language is much more complex to JIT compile (statically typed bytecode vs dynamic/weak typed source code) and the GC has to deal with managed/native interop in the DOM. And not to mention the cost of inefficient DOM interfaces and silly data structures/native types in JS.
>Also, doing things in separate threads means that scheduling of tasks also causes pauses in execution.
Yea, on the order of milliseconds at worst. Unless we're talking about real time software like games which need to execute a simulation iteration 30-60 times per second (and JS is much worse for this than Java for the reasons mentioned) delays in a reasonably well implemented UI app shouldn't matter and JIT startup time can be avoided by AOT (which is much simpler for static typed languages)
First run time is important, and interpreters are faster in this case. Also, JavaScript can execute as it is downloaded. I can load a whole UI, and complete my task before the JVM has loaded the code.
Also, at least Firefox does AOT on JavaScript now. This is how I load and start executing 1.2MB of JavaScript in 50ms in the app I'm currently producing.
ART AOT is on-install and that can even be changed to something like Mono AOT which is offline (you're essentially distributing precompiled native code along with IL) giving you the best of both worlds.
>Also, at least Firefox does AOT on JavaScript now
AFAIK this is only ASM.JS code, AOT compiling dynamically typed code would be questionable - maybe to avoid initial parsing costs but then you hit all of the problems of AOT (longer load time, need whole code) without the main benefit (performance gain).
If you had a $30k work station with 8 times the ram of a high end PC at the time they weren't too bad.
It's just that Java (and to lesser extend Object C) is such a resource hog. The future are apps written in C/C++, Go, Rust, Julia, Swift or JS (FirefoxOS).
As someone pointed out above, JavaScript is more memory efficient (first order function, etc.).
In Java, all objects need to have at least one additional field so that they can be used for synchronization. Most JS engines, on the other hand, support tagging (floats/doubles/ints are stored unboxed).
In Java, everything needs to be statically typed, and every object needs a class. If you want to make a first-class function, you need a classfile, a class, and an actual full-blown object for that function. In JavaScript (and other languages supporting first-class functions), closures can be optimized and represented by a single "closure" class, which has an existential type (the tuple of types of closed-over variables) and which is guaranteed to be correct (sound) by construction.
Modern JIT engines work very very well for the majority of "nice" (strict) dynamically-typed code. Where you lose is (1) numerics (where Java sucks as well, no vectorization - JavaScript is probably better here, with WebGL) and (2) non-polymorphic function calls (which are quite rare in Java as well). For polymorphic functions, polymorphic inline caches perform very well, probably not much worse than virtual/interface calls.
this isn't wholly true as of java 8. dynamic invocation is used to implement the new lambda facility.
one source with many links: http://www.takipiblog.com/compiling-lambda-expressions-scala...
[1] https://blog.mozilla.org/luke/2014/01/14/asm-js-aot-compilat...
Therefore total required resources is the OS+WM+browser+background apps (phone etc). In Firefox OS, the OS+WM+browser heavily share resources, allowing significant resource saving.
Moreover, correct me if I am wrong, but data structures such as xml/sgml/xhtml tend to require a lot of memory (or a lot of cpu throughput to convert to simpler data structures).