How Would You Usurp the Web Browser?

cyclomedia wonders: "I've been thinking about this for a while now, and a recent article posturing about Web 3.0 brought forward some other suggestions which basically boiled down to 'what should be next.' Everyone here knows that HTML, Javascript and HTTPRequest are not the tools for building feature-rich interactive networked applications, but that doesn't stop Google, Microsoft and others from trying their best to use them to build office suites and the like. As one project puts it: 'we need to replace the Document Browser with an Application Browser.' So, let's get the ball rolling with my question: What type of platform would you like to see delivering the 'true' Web 2.0 in the not too distant future?"

Comments

Ideas

[illuminatedwax]

The biggest benefit of the current style is a widget set that can display documents using a simple markup language. It also benefits from a programmer interface based on documents, or data, not subroutines.What's wrong? It results in a very static design - you have to basically refresh the entire document to change one aspect of it with dynamic (where "dynamic" means "from somewheres else") content. There are plenty of hacks around this. Among the problems:

• The current method for allowing a document to react to a user is terrible. Javascript sucks.
  
• HTTP being a stateless protocol is both a benefit and drawback. It's a benefit because it makes things simpler. It's a drawback because, well, it's useful to have state. Currently we have what can be described at best as "workarounds" - sessions, cookies, etc.
  
• The current method for updating a part of a document without reloading the entire thing boils down to a single Javascript function.
  

So I think the solutions here would be: sack Javascript and replace it with something better, like an iteration of Python, and make the focus more on manipulating the DOM than verifying forms; move the user authentication parts from the documents themselves (PHP, etc.) and into the web page server; and make the network support better. It would be nice to have a web browser that supported, say, socket based connections. The negative side to that, of course, is now you have to support all those connections. But it could be useful for other purposes as well.

Basically, the next step will be to treat the browser simply as a large framework for GUIs.

NTW

[Bluesman]

http://ntw.sourceforge.net/

If you'll allow me to plug a pet project of mine, I think an asynchronous networked GUI widget toolkit is the wave of the future. The client (browser) is responsible for drawing widgets and sending events to the server, which handles callbacks. It's AJAX done right.

The biggest problem I have is explaining to people why this is so different from X, or display postscript, etc.

Imagine writing a GUI app that runs over the network without you having to do any network coding. Sort of like X, but without the tremendous speed penalty of having to maintain graphics on the server side.

Or imagine writing an app interactively over a network by typing a few simple Lisp commands. (not that this protocol is limited to Lisp only)

Imagine serving ten thousand GUI clients from a cheap machine, or saving the entire state of each client's session so they can log off and on again without losing any work. NTW does all of this.

Unfortunately, I got everything almost done, and have not had much time to see the project to fruition. It's frustrating too when most people don't quite "get" it.