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

Not an easy question

[BadAnalogyGuy]

This is a really good question.

There are a handful of application platforms that fit the bill. The first being AJAX, but that's what we're trying to move away from. Another is Flash, and that's pretty well entrenched.

Some others are Java and Javabeans which allow for some level of cross-network execution. MIDP is the way things look like they're headed for this branch.

I've been looking at UJML lately and like the small footprint and the concepts behind it.

The basic problem is that you need to have a standard platform. The browser was it until now. As we move past the browser, we will need to have more network-aware languages and platforms that can interact with each other. I'm anxious to see how it turns out.

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.

Re:Why?

[plopez]

Because it is a hack which leads to ugly, insecure and inefficient work arounds?

HTTP was only intended to serve up text docs, some images and picts for information exchange for researchers. It has been pressed into service far beyond that, requiring huge hacks to get it to work.

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.

make the shell cool

[nthwaver]

SSH would be the internet's killer app, except it's not *COOL*. Make the shell cool, and everything else will follow. The browser of the future is just PuTTY with widgets instead of characters, and [insert fancy immersive web experience] instead of bash.

Except, in order to lure people from the existing web, you either need a static site begging people to download, install and convert to your new app (as if Google Earth is that much more useful than Google Maps) or to be so backwards-compatible with http that browsers can implement it themselves. Not to mention downgradeable, so for every new fancy site you'd better have ajax/flash or even static html equivalents. Thus, you haven't usurped the web browser - you have made it grow. Bwahaha.

I Wouldn't

[RAMMS EIN]

``"we need to replace the Document Browser with an Application Browser."''

No, we don't. We need to realize that Web browsers are tools, and that these tools are good at some tasks, but not at all tasks. That's fine, it's the way it should be; if you try to make a tool that is good at everything, you will end up with a tool that is good at nothing.

Web browsers are for rendering hypertext. We've added in support for images and style sheets, and that works fine (when properly implemented, of course). Using these facilities, we can access a wealth of information, access various services, order products, and various other things. Some web browsers also make decent download tools, although most are easily surpassed by tools made specifically for that purpose.

Plug-ins and the object element (when properly implemented) allow any content whatsoever to be embedded in (X)HTML documents. This way, we can embed other web pages, but also multimedia (something browsers are otherwise completely unsuitable for), and, really, anything else you can think of. That includes full-blown applications.

Considering the above, it is clear that all the infrastructure is already there. The desire to build more and more interactive applications that people access through web browsers is also evident. However, people are using the wrong tool for the job: they're using languages that were designed for documents to build applications. With a lot of effort, the results are acceptable to some. However, they are obviously not as good as they could be, had the right tools been used.

The obvious question at this point is why people aren't using the right tools. The answer is standards. While there are certainly tools that are much better suited to application development than HTML+JavaScript, none of these are as uniformly supported. You can build great applications using C++ and Win32, or Ruby and Cocoa, or Python and GNOME, or any other combination of language and platform-specific libraries. However, the result will only work on one platform, and most of these can't be readily viewed in a browser, AFAIK.

There are some technologies that attempt to address the issue of standards for browser-embedded applications. Java applets are one. Flash could be considered another. XUL is one. Perhaps the desklets that are popping up all around us will come to be supported by web browsers in a standardized way. Perhaps .NET will provide a solution, here. Time will tell.

Another question is whether a standardized interface is even necessary, or if it will be enough. Many GUI programmers agree that GUIs are inherently platform-specific, because different platforms have different guidelines for how GUIs should look and behave. I feel a lot of ground can be gained by abstraction: rather than describing what the interface should look like, where elements should be placed, etc., the description should specify the information to be presented to the user and requested from the user, and, as much as possible, let the implementation handle the look and feel. The question is how far this approach can be taken; it works pretty well for common elements like file open dialogs, but interfaces will almost invariably include custom elements, as well. Perhaps a standard language with a way to include platform-specific code will eventually prevail.

All in all, my vision is that, before we can get truly smooth and interactive applications in the web browser, we need to develop a technology that delivers those, and that technology is not HTML+JavaScript. There's a lot of work yet to be done: identifying the requirements, developing the plug-ins, competition among plug-ins, standardization, and wide-scale deployment. However, given the demand, I think we might finally start to see things materialize (I've been saying pretty much the same thing since 1996 or thereabouts).