> In English: the philosophy of JavaScript (to the extent that it has any philosophy) is that you should not be able to observe what is going on in system memory, full stop.
Mobile web apps are slow because they're secure, precisely for the reason that they cannot examine or manipulate underlying system memory.
Manipulating memory is fundamentally a bad desktop practice incompatible with the way that JavaScript—i.e., untrusted software—is distributed.
Most browser vulnerabilities come from manipulating the browser's underlying C++ objects, causing leaks & buffer overflows. E.g., the WebRTC bug in Chrome which provides a full sandbox jailbreak, or the TIFF/PDF exploit in MobileSafari from iOS 3 (jailbreak.me).
> Mobile web apps are slow because they're secure, precisely for the reason that they cannot examine or manipulate underlying system memory.
By that logic, they'd better start writing OpenSSH in JavaScript, unless they want to compromise every server in the world. Oh no!
Secure doesn't imply slow. Not even sandboxed implies slow. Mobile web apps are slow because their runtime has more layers of functionality and is more complex -- therefore, it requires more processing than a native application.
> Manipulating memory is fundamentally a bad desktop practice incompatible with the way that JavaScript—i.e., untrusted software—is distributed.
This simply isn't true. Native Android applications also can't manipulate memory; how are web applications more secure than those? And if they aren't, why are they slower?
>Mobile web apps are slow because they're secure, precisely for the reason that they cannot examine or manipulate underlying system memory.
I believe the idea he was getting at was "you need to be able to tell how much memory is available to your (web) application, how much of that memory you've already used, and you need to be able to accurately predict how much memory will be allocated in the course of performing an action, in order to achieve acceptable performance on mobile," not "you need to be able to directly bang the address space." You can certainly have those features in a safe language.
Absolutely.. you could also set the higher-level system to never report as more than x% available, even if it really is, to prevent app clashing.. say forground apps available max is 35-40%, and background apps at 3%, etc.
Mobile web apps are slow because they're secure, precisely for the reason that they cannot examine or manipulate underlying system memory.
Manipulating memory is fundamentally a bad desktop practice incompatible with the way that JavaScript—i.e., untrusted software—is distributed.
Most browser vulnerabilities come from manipulating the browser's underlying C++ objects, causing leaks & buffer overflows. E.g., the WebRTC bug in Chrome which provides a full sandbox jailbreak, or the TIFF/PDF exploit in MobileSafari from iOS 3 (jailbreak.me).