Portable Native Client - It begins

The long slow death of JavaScript as a reasonable platform for "apps" begins.

Portable Native Client: The "pinnacle" of speed, security, and portability

I've been deeply critical of HTML5 and JavaScript as a platform for general purpose applications for several years now. HTML5 is a step in the right direction as far as layout goes, but JavaScript was never intended as a target for compilers and is intrinsically inefficient.

I always felt that the push toward JavaScript-based web applications by Google was premature in that HTML5 was incapable of efficiently running applications. Even if you had a sufficiently fast machine to get reasonable performance out of a "web" application, you would do so at the expense of battery life. Assuming identical algorithms, a web application would consume far more cycles than its native equivalent for the same unit of work. This, at a time when more and more devices are battery powered and portable. The push was folly.

Up until today, Native Client had three problems:

  1. CPU architecture specific.
  2. Lack of rich APIs / native widget / platform bindings.
  3. Chrome only, not an open standard.
The first has now been addressed, once two & three are resolved, then the "web" will finally be a platform that can potentially replace modern OSs. The originally presented vision of Chrome OS was always doomed to fail. The "web" as existed at the time was not a platform where applications could be barely anything more than form-like curiosities. Anything heavy, such as IDEs, photo editors, games, would suffer embarrassing levels of performance and/or battery life.

It is my hope that, through Native Client - or similar technology, the "web" does become a cross-platform source of native applications. Such a development would be of monumental significance as finally it will be possible to deliver on the age-old promise of Java - write once, run anywhere - but without the bloat of early Java or the current web. Curated collections of applications will always have a place but the walled gardens will fall and applications, developed without comprise (unlike todays web "apps") will have a potential audience of everyone.


Android 5.0

Features I'm expecting / hoping for in Android KLP (5.0?) :

  • A bundle of usability tweaks.
  • OS-wide features to selectively hide soft-buttons on an app-by-app basis (possibly requested by the app, possibly overridden by the user).
  • Android desktop-mode, with ability to load apps into resizeable windows or ability to snap-apps Windows-8 style. The desktop mode would improve navigation with keyboard and mouse, automatically disable the soft keyboard and allow for Android to be used with larger monitors.
  • Ability to toggle DPI on app by app basis (as per Paranoid Android).
  • More social media integration within the OS via open apis with Google+ baked in.
  • Better Bluetooth keyboard integration with full-keyboards supported, and ability to optionally automatically disable soft-buttons when they are available via keyboard.
  • Optional split-software-keyboard, useful for larger phones.
  • Thumb-mode within the Smartphone UI , where users can put into a mode where the screen is scaled down to an area accessible by a thumb, aligned to bottom right or bottom left. Useful for commuters on train that must operate ever-larger-screened phones with one hand whilst holding a rail with the other hand. Thumb mode could be activated explicitly (possibly via the power button menu), or if the hardware supports it, have hardware detect the thumb grip (phone held with right hand if right handed, held with left hand if left handed). In that grip, and if auto-thumb mode selected, then automatically scale the screen down to the maximum range of the thumb (if no hover detection hardware present), or if the touch-screen supports hover detection, only scale down if the thumb is hovering or touching the screen. That way, the phone could have a large screen, but be entirely usable with one hand without ever having to manually set between thumb mode or non thumb mode. Sensors would be required on left and right sides of the phone to detect two or more fingers on one side, used in conjunction with the user specifying (once) if they are left or right handed, you have a phone that uses the full screen to display information, but when the user moves their thumb over the screen, the screen scales down so that ALL UI elements are in range. If holding in the two handed grip (right handed person holds the phone in their left hand, and vice versa), then thumb mode will not be activated as the index finger of the opposite hand will be assumed to be use (which has full range of the screen).
  • File-explorer integrated into the OS, possibly simplified from the actual-OS.
  • Simplified app backup (to desktop/cloud) built into OS.
  • Add ability for applications and/or users to load the app in battery saver mode. For example, lots of apps clock the CPU/GPU to max when running in the game-loop, but the max clock might consume 50% more power than at 80% max clock, and the app has no use for the extra clocks. Limiting the clock speed of CPU/GPU could lead to much longer gaming times for lots of apps that are not best optimised.
  • A Desktop-Linux Compatible Kernel so that Android devices can run Ubuntu etc.
  • The Android Application Stack being refactored into its own project so that it can be supported by any browsers (such as Chrome, or Chrome OS). Apps that don't use phone specific features will be able to executed natively via the web. This will include native apps utilizing C++, as such, they will run like lightning next to JavaScript/HTML5 apps and be able to access more hardware features directly (or Google might go Native Client all the way).
  • Many more voice search features especially being able to use multiple languages without having to explicitly switch the language.
  • More gesture-based navigation features, possibly the addition of an conical menu based UI, and possibly deprecating the soft button bar or making it optional.
  • A brand-new innovate launcher that doesn't use icon grids.
  • Addition of bandwidth management APIs. At the moment, Wifi is all you can eat, 3G tends to be consume less bandwidth where possible, but no option to consume less bandwidth on Wifi. Users need the option to minimise data use independent even if on Wifi (as lots of portable hotspots charge per MB). This is increasingly important if Android is to become a Notebook OS.
  • A game-pad only navigation mode built into the OS.
  • Support for H265.
  • Portable Native Client support for the NDK, all apps automatically support all current CPU architectures (ARM, ARMv7a, MIPS, x86) and all future architectures at 99% of native speed. I imagine Intel is especially keen on this being implemented.