For some reason I never came across this before, but it seems there is something of a movement (complete with manifesto) promoting client-side-only web apps.
According to the Unhosted site:
By “unhosted web apps” we mean browser-based apps with no server-side backend. Unlike server-side or client-server apps, unhosted web apps leave users in control of their valuable user data and privacy, by default.
I’m a big fan of writing client-side apps using the web standards stack (JS, CSS, HTML) for many of the reasons stated on the site, including not least the fact I don’t need to provide an actual hosting platform – users can run the app locally, or access it from an app store (e.g. Edukapp) or a shared collaboration environment (e.g. Apache Rave).
Publishing a web application in this way means you can also make it available as open source software, allowing it to be forked and modified by users, and also potentially bringing in contributions and improvements from a wider community.
So, even when the intention is to create a web app that will work in a particular hosting runtime such as Apache Wookie, I always start with creating a working web app that will run in the browser without any server-side services. So, you can use the following apps directly in the browser or host them in Wookie:
(You can also run them locally in the browser – download the .wgt version, change the file extension to .zip and extract the contents)
I can then add tests for injected features provided by the runtime, and make use of them where available. For example, multi-user collaboration via the Wave API in Wookie, or inter-widget communication in Rave. Also even for things like storage, I can test whether widget.preferences is available, or default to localstorage. (Maybe in future I might want to give remotestorage a go, which provides more storage options for the user.)
I tend to opt wherever for possible for highly generic back-end services such as storage and communication, rather than creating a tightly-coupled set of services for each application. For some, this seems like an odd restriction, as you have so much freedom to do nice things on the server side (e.g. using NodeJS). However, it does make the apps much more portable and reusable, and avoids a lot of configuration hassles.
Even where it is necessary (at east for now) to use a server-based back-end, such as for collaboration or multi-user games, I created WaveNode as a generic backend in NodeJS so you don’t need to run a dedicated server-side component for each app, and the apps themselves will work anywhere there is a Wave Gadget API implementation (e.g. Apache Wookie, Apache Wave etc).
So I guess I’ve been in the Unhosted movement for a while now without realising it!
Scott's Workblog 
How would you say this approach relates to learning object web applications, where some things are similar (like being able to run in browser regardless of server-side technologies) but some things are different (communication with the host site is part of the benefit to the user, keeping scores and tracking progress, perhaps through a SCORM wrapper)?
I suppose such an app could both exchange data with the hosted environment, but also with a personal learning environment component like a portfolio (badge transfer and so on).
I think there is quite a bit in common between the original SCORM model and what we’re now doing with “Native Web Apps” – taking web components, zipping it up with a manifest, and then using JS APIs to talk to services.
Something that Bill Olivier came up with ages ago was the idea to have a personal SCORM player, so scores and so on are cached locally, and then the learner has the option of basically replaying the API calls to an LMS at a later date.
I’d not heard of the Unhosted movement either – interesting. Actually the first web app I ever wrote was almost completely client side, but that might have been more by accident or personal coding bias. Still I soon saw you get benefits like less power + bandwidth heavy round trips, plus resilience in conditions of low connectivity. Since those days when you need to do for each browser, the wide spread standards conformance means great portability, and the new power of browsers means great functionality. Another plus is it’s easy to just to try out an app / widget as you point out – no additional serverside config.
Interesting! The ‘Unhosted’ movement reminds me of SOFEA and TSA (Thin Server Architecture)
>> SOFEA paper worth a read: http://sofea.googlegroups.com/web/Life%20above%20the%20Service%20Tier%20v1_1.pdf
>> http://www.thinserverarchitecture.com
This was all about moving applications to the client and directly binding those services you need. ‘Unhosted’ seems to go even further regarding the “data freedom”. I’m a bit sceptic about the feasibility though. Putting data on the client sounds nice at first hand (privacy and all), but increasingly unrealistic in such a distributed, ubiquitous computing world (I want my data on my phone, tablet and pc!)
Yes, putting all my data locally sounds great, but also risky. I think this is the reasoning behind providing user control over storage as a utility, and putting the emphasis on synchronization – e.g. PouchDB.
Indeed. Putting users in control of their data seems to become more trendy with new names for it appearing every other week: Check Un-Web 2.0 http://unweb2.blorkmark.com/
@Stefan thanks for the link – Dave Winer is an “unhosted” pioneer; the Radio platform was definitely ahead of its time. But I think the commenter on that post is correct – the problem is “free”.
I make some research about Apache Rave. Thanks