There are three ways in which the web currently works.

1. A web server sends a static html file to the browser.
2. A server side application outputs a html stream to the browser.
3. A web server sends static html, css and javascript to the browser, which is run locally to generate html.

Server side app - an application that processes data on the server and only outputs html and css to the browser. the user interacts using forms and links. Data is saved only on the server.

Local app - html, css and javascript are sent to the browser. The js processes data locally and syncs with the server when needed. Data is saved locally and on the server.

What are the differences between server side applications and local apps?

Server side apps

• Server side apps require a network connection.
• Everything is stored on the server
• They act like hypertext documents

Local apps

• Need to interact with server to create more value
• The app needs to run locally, and is open to local inspection

If someone is writing a blog post and they are without network connection they will lose the post if they are using a servers side app. The submit form will fail and they will lose their post. A local app could notice that no network is present and save the post locally. Later when a connection is restored would the app in the background send the post data to the server to be, possibly, published to the world.

So I'm seeing the two differences here as where data is being processed, and time interaction.

For data that the user owns we can process it locally. A new blog post. There is a security risk however in letting users process data that they shouldn't have rights to. Such as another players score.

The second thing to keep in mind is that of time. For content that doesn't not require real-time interaction with other users we can save it locally then upload (sync) it with the server. This could be a new blog post, word processing, image uploads.

However there are some questions that need to be looked at when we talk about real-time interactive content.

A user is in an airport and reading a thread, halfway through they need to get on a plane. While on the plane they finish reading the thread from browser cache, then they write and post a reply. What happens? Do we sync the post into the thread later. Do we put the post in chronological order based on when the post was authored, or when it was submitted to the server. If other users have added posts after the airport user then you could insert the post on an old page, pushing older posts down. Most users wouldn't even see this as it would be on older pages. Technical means could be put in place to let users know that a post was synced in, but I think that it negativity effects the time line of the thread. It's editing the thread. (would spammers edit old threads inserting posts pages back)

Another scenario is that at sync time the post is added to the bottom of the thread. An issue with this is what if the post asks a question that was answered by other posters and precede the newly synced in post. To me this is a better way to do this. Even though it does present problems it seems the best way.

Or we do away with local storage for some or all activities that require real-time interaction. Maybe users can start a new thread, but not reply to existing threads. Maybe they can write, edit and manage their blog, but not reply to comments.

That's an interesting one. Comments on a blog are only real-time if it's really popular.

Why not both?

I think the real solution will be to use a hybrid of both server side and local apps. We want to give people options to process data locally, but must account for cheating and privacy.

We could still give over to the local app a good deal of responsibility, but only allow it to work if there is a network connection.

Or things like let a user reply to a thread, and if there is no network save the contents of the post for later.