Slashdot Mirror
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?"
I think a better question would be: Why Would you Usurp the Web Browser?
In other words... what might succeed at doing exactly what Java and Flash promised to do, but have failed?
:)
I'm interested to find out that answer myself.
ClutterMe.com - easiest site creation on the Net. Just click and type.
It would have to stateful and sandboxed. Run on any platform with a GUI. It probably wouldn't be the results of a standards committe as the committe would make a mess of it.
Clients would need to be able to bootstrap webapps automatically. The engine itself could be either embedded in the client or a thumb drive. The engine would just be a container to run the logic and render the content from the net.
putting the 'B' in LGBTQ+
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.
Did you ever notice that *nix doesn't even cover Linux?
iTunes is already a specialized browser for music and video. It feeds the online music store to you using web technologies, but no browser can access the store directly.
I think if anything the future will look like these application shells wrapped around things that are almost, but not quite, web sites.
AJAX can only take you so far, at some point you need a deeper integration into the OS to make an application really compelling and useful within the context of the OS it runs within.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
AJAX, Java servlets, etc, are all dead-end technologies. They are the PHIGS and GKS of the web - nice in theory but not much more. Programming languages are simply too heavy for this kind of work. This is something that is simply not getting through to designers. You don't WANT a Turing-complete scripting language for a web browser, but you may very well want a large assembly of partial scripting languages that - when combined - are Turing-complete.
Overhead is the first problem. You don't want more than you absolutely need, for most cases, even if that means that in the corner cases of trying to do a lot, you end up using more resources than you would otherwise. Computing devices are getting bigger, overall, but are also getting smaller. Phones now support the web, and phones don't have the memory to run the sort of stuff people are using. PDAs could have the memory - if you don't want to use them for anything else, which rather eliminates their usefulness as a PDA.
Distributability is the second problem. Computers are now multi-threaded, multi-core, n-way SMP, clustered into Linus-knows-how-large a Beowulf cluster. But web pages are linear. You can't parallelize them, in the general case, and can't parallelize them well even in the better cases. Thus, browsers simply can't take advantage of the bulk of the CPU power available to them. You might as well hook up a paper tape reader to a SATA interface, whilst you're at it! If you can't benefit from the computing power, then all you're doing is burning energy and getting nothing back in the process.
CODECs need to be slashed. And dotted. Inefficient algorithms may work over broadband, but you can use a 40' truck to pick up the weekly groceries, too. Just because you CAN do something doesn't mean you should. Inefficient algorithms will create more traffic at a faster pace than Internet providers can provide more bandwidth. The service you get is not much better than you'd have had using quality code and a 56K modem. Efficient use of the resources available will allow for better quality content, not merely noisier content.
For goodness' sake, enable multicast and IPv6!!!!
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
No, no, you do NOT want yet another scheme for letting "content owners" run stuff on your machine. We have enough of those now: Java applets, Active-X controls, Macromedia Director programs, Microsoft's latest downloading DRM controls, etc.
Executable content has many downsides. First, all you can do is run it. It's really tough to do anything else with the content. Even resizing it for a device the content owner didn't intend can be tough. Try to reformat a PostScript file (PostScript is an executable language) for a small screen. Originally, repurposing HTML content was easy. With the mess we have today, it's tough to even archive it usefully.
Then there's the hostile code problem. This has essentially killed Active-X (which is hopeless), it's hurt Java applets (which were supposed to be secure, but weren't quite), and we're still having trouble keeping JavaScript in its cage. There are even Flash exploits.
Then there's the "Now everybody can do things their own way" problem. Every piece of content has its very own user interface, and usually not a very good one.
More fundamentally, executable content puts the content, not the user, in control. With declarative content, the user has control. With executable content, the content owner is in control, and can restrict the user as much as they want to. Which, as we know by now, will be as restrictive as they can get away with. You WILL watch the ad for twenty seconds before you get to the real page.
What we need is more descriptive power in HTML, so you don't need so much executable content. There are about ten things people do all the time with Javascript, and those should be supported with declarative code in HTML. We need more stuff like WebForms.
If you want the Web of the Future, try Second Life. Now that's a real "feature rich interactive networked application". It's a great toy, but a terrible way to deal with large quantities of information.
I think a better question would be: Why Would you Usurp the Web Browser?
I thought the summary alone made it pretty clear why you'd want something beyond a web browser. The web is (or at least, was designed as) a network of hypertexts. This would now properly be expanded to a network of hypermedia, but the point remains the same: it's function is to present documents, and link from one document to another. Text, images, sounds, movies, all that fits well enough into this model; even database output is basically nothing more than all of the above organized in a different way than a standard file system would do it, and databases can implement all variety of useful things like the web forum that we're chatting on without really breaking that model.
But when you start getting fancy complicated interactive applications crammed into that model, it gets ugly and breaks. Games, document editors, all that sort of stuff belongs in an *application* framework, not a document framework. And mind you, I find a lot of these networked applications very useful, but still, they don't belong in the Web; they belong in something else, an Application Browser to go along with your Document Browser. Though honestly, I'd just do away with the whole "browser" concept entirely and treat internet documents and applications the same as you would a doc or app on the other side of your LAN, which is not much different than you treat local docs and apps, besides permissions differences).
I guess this is my answer to the question in the summary, too. I'd take all applications out of the browser entirely and integrate the browser functions into something like, to use OSX examples, Finder and Preview; maybe merge the two together into one program, for browsing (local and remote) filesystems and viewing (local and remote) documents. Include a plugin architecture to allow extensibility of format support (and heck, if you allow editing of documents therein too, you're moving awfully close to a document-centric computing model, at last!).
Then standardize on a cross-platform API (Java is a possible candidate), and then when you click a link to a remote application (from your browser/finder/explorer thing), that app is quickly downloaded and cached on your end and run like any other local program, with the exception of different privileges and such. These programs might just call back to their home server for their data, in the case of something like a simple game, or they could allow you to read and write data from your local disks. The advantage of using a remote app in the latter case would of course be not having to worry about upgrading or anything - the only version that's available to use is the latest version. The disadvantage of course being if that app is unavailable, well, maybe you're stuck without the ability to open your data, even if it is stored locally. But open file formats could help there.
So, I guess that's my solution. Fat chance of it ever happening though.
-Forrest Cameranesi, Geek of all Trades
"I am Sam. Sam I am. I do not like trolls, flames, or spam."
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.
If moderation could change anything, it would be illegal.
The Web is document-centric, I like it, and I want it to remain as such.
Very few applications really need rich interactivity, and those that do can utilise Java applets (and remember now Java is really free software under the GPL). I see nothing wrong in loading a document, filling up a form or activating a hyperlink, and getting back the results from the server in another HTTP request.
I would welcome more rich form controls in XHTML pages, though. We do need better forms, better XHTML/CSS, and faster low-latency networks. But we should never forget that Web is a big pile of interconnected documents, so we should be careful about trying to emulate applications with tools built for document creation (it's like wanting to code your next OS in an Excel worksheet with tons of VBA... you can try it, but the results will disappoint you).
Web is for documents, servers are for creating those documents dynamically (PHP, Perl), and C is for building real applications. I do not like running code on my client machine. As a Web user, I want your code to run on your own machine as a PHP or Perl script, and I only want to get the results of your code (the HTML page). I see no reason why I should trust every random 10-year old Web designer on the planet to execute untested JavaScript code on my CPU. If you really badly need strong interactivity for a Web project, use Java applets or downloadable Java applications, and be very careful not to overuse AJAX or JavaScript if you think you really need them on a webpage. For example, there is absolutely no reason (apart from corporate stupidity) to hyperlink Web pages with JavaScript. If you want to analyse your traffic patterns, go feed your Apache log to a Perl script and don't fuck up your visitors with JavaScript hyperlinks. Other stupid things I have seen include displaying your email as a Java applet or Flash movie (you should use text or an image). People should focus more on leveraging the power of CSS instead (why use Flash to create rollovers when you can use CSS?).
I sincerely believe that many times the use of Flash, Java, AJAX, JavaScript, and sometimes even superfluous CSS, is nothing more than the emanation of a desire to own things, control your visitors, and be the master, and this is mostly prevalent in companies (where it is known that employees left their brains at the gate, managers only care about their bonuses, and the owner either has no ability to fix their organisation or enjoys life at a Pacific island, often without knowing that what they created is an organisational monstrosity of apathy and mindlessness). Just compare how free software projects and corporate software utilise AJAX and JavaScript and you will see the difference: Companies seek to minimise the utilisation of their support helpdesks, and only open-source projects care about creating something useful.
Now, the Web is just a service of the Internet, and it's not the only one as we have lots of other services (email, newsgroups, sometime we had gopher too). I really see nothing negative in creating another Internet service, with its own protocols, for distributed applications. We need to define a protocol, perhaps a stateful protocol (remember HTTP is stateless), write a server, and distribute a client to all concerned. Then we sit down writing application software for this protocol, and we watch our new service grow.
I think Web developers should stop masturbating with AJAX and JavaScript and work together to create a new protocol specifically built for applications.
Of course, there are also some practical and commercial considerations you need to make if you code Websites for a living. It is, unfortunately, difficult to avoid JavaScript in the modern world, especially if you work at a company or if you are a freelance Web developer. Many times the client specifically asks for strong interactivity and control, or even specifies technologies like Flash or AJAX. If you are self-employed, you can describe some disadvantages of AJAX/JavaScript/Fl