LWN.net Logo

my guess - it's RPC again

my guess - it's RPC again

Posted Dec 13, 2012 1:06 UTC (Thu) by tialaramex (subscriber, #21167)
In reply to: Platform specific "apps" vs. HTML-based "apps"? by dowdle
Parent article: A simulated FirefoxOS experience

Mobile devices, even including tablets, spend more time in the environment that shows up the flaws in "treat remote things as local" models of computation from RPC right up to the modern time. Internet access is patchy, it's available one moment and gone the next, bandwidth varies enormously, two apparently simultaneous things experience apparently different network conditions for whatever freak reason.

So it turns out that you want to do a lot of work in the client. Instead of being just some dumb rendering and a lot of calls to a remote server where all the smarts live, you have two copies of everything, one in the client making things appear to work for the user instantly and another in the server keeping up with the client state whenever there's a window of Internet access. They could be exactly the same, but for a variety of reasons they are more likely to be quite different, maybe not even written in the same programming language.

If you do this perfectly you get a really nice app, something every Nexus / iPad / whatever owner is happy to be using and you contribute to the (false) notion that everywhere has Internet access all the time these days.

Obviously you can't ever quite get it perfect, but as you deviate from the ideal further and further you interfere with the illusion. A spinning "wait" icon appears and the user curses. Somewhat more frustratingly, something they just did magically undoes itself before their eyes as the client state catches up with a server that has lost an update, or reports that an action which seemed possible was actually rejected. Worst of all, the app just freezes, unable to either complete the intended action or return the user to their state of bliss it waits forever for the Internet.

Now, obviously in theory you can implement the "smart client" with enough Javascript and nasty DOM mangling code. But in practice that's a lot more work than using real languages and real toolkits, and it probably always will be. Those "web applications" intended only for the desktop can continue to just do all the heavy lifting in the server and rely on Internet access to pump HTML views to a client, but on a phone or tablet it doesn't and may never work.


(Log in to post comments)

my guess - it's RPC again

Posted Jan 8, 2013 13:49 UTC (Tue) by DavidBild (guest, #88575) [Link]

> Mobile devices, even including tablets, spend more time in the
> environment that shows up the flaws in "treat remote things as
> local" models of computation from RPC right up to the modern time.

This, this, this.

Native apps provide a better experience than web apps when the network connection is poor or non-existent. An in-browser app with local caching of data and code could in theory work as well, but the ecosystem just isn't there yet.

If mobile network connections were as omnipresent and reliable as desktop connections, users wouldn't have reason to flock to the native apps.

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds