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.
applets, modified for fullscreen w/ an easier alternative to swing.
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+
I can't tell you exactly what will replace current Internet UI technology, but I can say this, HTML, W3C, XML, CSS XHTML and on and on are simply the evolution to what will replace all that has gone before. Web 2.0 is simply an effort (no comment on value of the effort) to consolidate the things that make the Internet's UI more useful and exciting. Web 3.0 (and I hate the buzzwords because it always makes it seem like some person or group has more info or style than others when the buzzwords are used) and what lays beyond it are simply the morphing of what works, has worked, or seems like it will work into a common Internet UI experience.
There is no silver or magic bullet that will usurp web browsers, and its just silly to think that there will be, or could be. As an example, if the fully automatic hover car (think Jetsons) was to be invented tomorrow, it would not usurp the venerable internal combustion powered manually operated common day vehicle for a whole slew of reasons, not the least of which is cost, or cost of upgrading.
To ask such a question smacks of ploy or troll... though I find it not unreasonable to think there are those that ponder such questions as a matter of vocation.
Support NYCountryLawyer RIAA vs People
How about the JVM, seriously?
There are three parts to developing a GUI application; widget layout, widget behavior, and state persistence (view, controller, model if you want to think of it like that). Right now, people are dealing with HTML (or XHTML or XML), Javascript, and XML for those things.
What's better? Some people have come to like the flavor of XRC from the wx world, wxPython coming with a fairly decent GUI designer called XRCed that produces XRC as output. That handles widget layout. From there, you can use basically whatever language you want to handle behavior, and one can stick with XML or a database as persistent state.
There are already applications being used and developed right now using Python and wxPython that distribute XRC GUI components, Python behavior, with data all from a live database, transferred over XML-RPC. I haven't spent much time digging into the AJAX stuff, but from what I have seen, even pure wxPython is far nicer to read and write. With XRC handling layout and Python handling behavior, it would be difficult to find a significantly better "dynamic application platform".
Toss in the fact that you can actually embed XRC into HTML when using the wx browser, and one can write rich applications right into web pages, or even full on applications by themselves.
I don't think you can really overtake the web browser. It has too many functions. You can, however, make something that is better at one particular thing. And that's really where other attempts, such as Flash and Java, have failed: They tried to be too broad, and keep getting broader. If you try to do everything, you end up doing nothing well.
Choose one aspect of the browser, make something better that is simple and narrow, and see where it goes. The kind of applications written for the browser are small and data-driven. Perhaps streaming Tk between client and server would work.
I wonder if I use bold in my signature, people will notice my posts.
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."
I gotta gripe about this.
Don't get me wrong. I like functionality, I like a well-done AJAX site.
But stop me when you see the problem. What's being talked about is rewriting popular desktop apps to run inside a Web browser, in an environment where you have limited native GUI functionality, no toolkits to speak of, no access to the local filesystem (you know, where your stuff is), no window management, no native menus, network access is limited for security reasons but required because the local filesystem is off limits, all the GUI widgets invented in the last 35 years have to be written from scratch in languages and technologies that don't even work the same from browser to browser. What, was Office too fast on your machine? Being able to load and save your own files on your own hard drive was too convenient?
This was tried a decade ago, people were talking about the browser as an OS and all your apps would run in Java, same problems, you lost everything your native OS provided for you, added a few layers of Slow 'n Buggy, and didn't gain much except, oh, hell, I'm not sure what anyone would have gained except sticking it to Microsoft, and anyone who cared wasn't using Office in the first place. It seems to be the same thing now: surely there are better ways to stick it to Microsoft than writing productivity apps that are so constrained by the browser environment that Office looks good by comparison?
Get the right tool for the right job, folks. If you need groupware, write groupware, don't just assume the need for collaborative writing means that word processing fits nicely inside a Web page. If the point is to thumb nose at Microsoft, write better apps for your OSes of choice.
The legitimate purpose of AJAX is to bring interactivity to those things on a Web site that need it, not to move desktop apps into a smaller box.
To the original question: What's Next is probably already happening in the arena of standalone Javascript engines and Dashboard-like mini apps, that are reasonably lightweight, unobtrusive, and play nicely with the native GUI you're running. Sort of like each Web site you like and use everyday will have an applet or widget that "breaks off" and stays floating, on your desktop or on a Dashboard layer or whatever, to keep some kind of line of interactivity open with the Web site long after you've left it. Like RSS but more tailored to what that site naturally does: tickers, headlines, webcams, music, gamelets, whatever, and in the style of the site itself as visual cue.
~ radiographite: art by john shepard
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
XULRunner
It supports rich applications like Firefox and Thunderbird using XUL and XPCOM. Cross-platform (and unlike Microsoft's implementation of the term "cross-platform", it doesn't just mean several versions of Windows). It supports themes and plugins.
Why get rid of Web version x.x? The web is a hypermedia document service, get the applications out of it.
For a few reasons.
Reason #1: The hyperlinked nature of the Web drives all content into the browser. You don't want link navigation to open content in another application. It's just a bad user experience.
Reason #2: A critical feature of Web applications, frequently overlooked, is that they do not require the user to make a trust decision. You just go to the site and use the app without having to click "OK" or "Install". This only works because the app is *visually* sandboxed with browser UI to label the app and separate it from stuff you trust.
Reason #3: The three major contenders for a Web-like application platform are Flash, WPF, and the HTML/JS/DOM Web. Only one of these is standards-based, not controlled by a single company. Only one of these has top-notch open-source implementations. You can dream about creating an open source, standards-based Web alternative --- the W3C does --- but it's not going to win.
Full disclosure: I'm a Firefox developer.
First of all, let's all have a look at REBOL.
Secondly, what we need is a distributed and declarative programming language running in the 'web' browser. A web page should become a declarative description of a user interface, much like F3.
For example, if I wanted to make a simple login form, the code would be something along this:
In the above example, the UI is built in a declarative manner as a tree of objects, much like HTML. But there are no hardcoded tags: the final output is created by running the code in the page.
Furthermore, the calls to the server are part of the language specification: the language automatically knows how to call server functions, without any need to declare them somewhere.
Finally, the platform shall have lazy downloading, with classes downloaded when they are first instantiated.
Pages which do not have any logic and simply present information could then easily be built by using the declarative user-interface library.
Style mechanisms like CSS and resources would be data retrieved from external servers and applied to the UI.
If the page needs to do more things, for example to display a video, run a calculation, present a menu or a tree, run 3d graphics, etc it would be very easy: since the whole interface would be programmable, there would be no limitation.
The advantages over the current situation are:
(That's a quotation from the luddite character Theotocopulos in the H. G. Wells movie, Things to Come).
Not that it matter, but 99.734% of everyone using the Web is perfectly happy with the functionality that's available now.
What they want is for someone to make the current technology work. That is, make it work more reliably for the average user with an average three-year-old computer on an average-speed connection.
The only complaints I hear are problems with bugginess due in large part to a) failure to adhere to standards at server or client, and b) version skew between the set of browser-related stuff loaded on the particular user's machine and the site that's being visited.
I don't hear them in that form, however... what I hear is "for some reason I always crash on this site" or
Why is this page taking forever to load?" or "I can't seem to get this site to work properly."
Nobody but overly ambitious web-designers and corporate egotists want all the fancy flash crap that takes minutes to load... or the fancy Java applet crap, now thankfully rare, that takes minutes to load and then doesn't work because you have the wrong version of the JVM.
People just want to get in, read their news, do their shopping, not have the browser hang or crash or take a minute to load a page, not get their identity stolen, and not get interrupted by advertising popping up over, under, around, or through.
Everything being discussed here is just engineering ego ("I can do way better than Tim Berners-Lee") or corporate ego ("Isn't there some way you can make our website have a real shiny metallic reflection") or vendor lock-in ("This site does not support your browser. Please use Internet Explorer version 7. Click on the link to get it free. Of course it won't run on the version of Windows you're using... or the version of Mac OS you're using... but that's your problem. Go buy a new computer.")
None of it has to do with the real needs of actual web users.
"How to Do Nothing," kids activities, back in print!