Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×

How Would You Usurp the Web Browser? 149

Posted by Cliff from the survival-of-the-fittest dept.
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?"
This discussion has been archived. No new comments can be posted.

How Would You Usurp the Web Browser? More

How Would You Usurp the Web Browser?

Comments Filter:

  • Why? (Score:3, Insightful)

    by elbenito69 ( 868244 ) on Tuesday November 21, 2006 @01:22AM (#16925590)
    I think a better question would be: Why Would you Usurp the Web Browser?
    • It's a Monday night. I'm bored to death in my Unix Administration class learning about web servers. Why not?
    • Why would you usurp the web browser? Simple, to take it out of Microsoft's hands.

    • Re: (Score:3, Interesting)

      by plopez ( 54068 )
      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.
      • Yes and no. Some features of http, like being stateless, encourage writing web apps which are easily scalable. REST has some points IMHO.

        Many shortcomings of http for web apps are being addressed, xul, xmlhttprequest... the main problem being that MSomebody is still trying to fragment standards for its own product line.

        Who will get to 3.0? Java, now FOSS? C#/Mono, momentarily free? new functionality being incrementally added and standardized, AJAX way? or maybe cross platform libraries, and the increasing e

        • Re: (Score:3, Insightful)

          by DaveV1.0 ( 203135 )
          Many shortcomings of http for web apps are being addressed, xul, xmlhttprequest

          In other words, more, bigger, uglier kludges are being done on HTTP to get it to do something it was not and is not designed to do.

    • Not usurp, but augment. (Score:5, Insightful)

      by Pfhorrest ( 545131 ) on Tuesday November 21, 2006 @02:33AM (#16926220) Homepage Journal
      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.
      • I meant to mention this in there and forgot it somehow...

        You might ask, why exactly is it wrong to build programs in the web's document-centric framework?

        To make the answer clear, I need only ask back, would you build an interactive game, or heck, even a word processor, *inside* of a Word doc, if the macro language allowed you the ability to do that? If the answer is "no" (as I suspect it is, and it ought to be), then you should understand why doing the same thing in an HTML document, which is in the same c

      • 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 adva

        • You've just described Java WebStart

          I, for one, would prefer something not tied up with Java (which is a subpar language in many ways) and especially with the Java Virtual Machine, which is worse.

          The real advantage of webbased apps are that the providers have total control of the software. I'm not sure this is to the advantage of the users, but hey. If we want something like this, I'd suggest taking a look at SVG and work on a similar standard, meant for applications.

      • 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 entir
  • 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 standar
    • After seeing a project one of my friends worked on last year, I got pretty excited by the potential offered by a mix of SVG and AJAX. If we ever see a solid toolkit and good support for SVG in the major browsers, this might be a short-term answer to the poster's question.

      Then again, the idea of any "platform" built on top of JavaScript scares the hell out of me...
      • Well, there's KDE's Konqueror, which can support SVG and Javascript, and is in fact a generic container application itself. It would be a good start, although it would need a security and probably architecture abstraction layer in order to meet security requirements. I'd bet someone could put something together with Konqueror and a persistent Java engine that would fit the bill.
    • ``I've been looking at UJML lately and like the small footprint and the concepts behind it.''

      Holy heavens, no! You don't program in XML; it's bad enough for data! Now, I see the actions aren't described in XML, but look at this:

      <state-variables>
      <state-var name="sKeyEvents" type="boolean"/>
      <state-var name="sMessagePrompt" type="boolean"/>
      <state-var name="s

  • Taking out the "AJAX", HTTPRequest, Javascript, Flash, Java and advertisements would be a nice start.

    • I have no problem with advertisements, but I do have a problem with advertisers who try to force me see or click their ad. Advertising is a tool, but it's misused. What the advertisers need to understand is that there is nothing bad in allowing viewers to ignore their ads. An advertisement should be useful content itself. How? It's simple: Don't advertise irrelevant stuff.
  • For starters I would change your terms of reference. Not everyone agrees on the definition of Web 2.0. I personally know of business owners who profess to currently be running Web 2.0 sites and they are crap and worthless. Therefore what exactly do you mean. Are we talking loose ideological concepts - "lets all share"? Are you talking a technical specification for programming like java? You indicate something like that in you aplication browser bit. I would like persoanlly to see some discussion on W
    • I'm not generally a spelling nazi (well I am, but I keep it to myself), but I'm curious how you managed to make the exact same, rather odd (looking, not odd to make) mispelling of personally, twice. I suppose copy and paste would explain it, but none of the preceding and succeeding words are the same, so that makes that hypothesis rather poorly supported. Just a coincidence?
      • Actually, a little rudimentary thought would explain it quite easily. Typing habits, not coincidence at all. Or perhaps keys swappedo on the keyboard for a hunt and pecker. Or an incorrect word in a spell checker. It is curious and I am being polite about it because usually spelling nazi's make me reach for my Maschinengewehr 15.
    • ``For starters I would change your terms of reference. Not everyone agrees on the definition of Web 2.0. I personally know of business owners who profess to currently be running Web 2.0 sites and they are crap and worthless. Therefore what exactly do you mean.''

      You, sir, understand Web 2.0.

  • 'True' Web 2.0 (Score:5, Insightful)

    by Z0mb1eman ( 629653 ) on Tuesday November 21, 2006 @01:26AM (#16925626) Homepage
    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. :)

    • Re:'True' Web 2.0 (Score:5, Informative)

      by suv4x4 ( 956391 ) on Tuesday November 21, 2006 @05:16AM (#16927666)
      In other words... what might succeed at doing exactly what Java and Flash promised to do, but have failed?

      You're signing out Flash too quickly. I'd say give it a chance. I mean Flash 9 and Flex 2 are out just couple of months ago and Adobe also donated their supposedly (for Flash haters) "crappy" Flash 9 JS engine to Firefox, which will replace SpiderMonkey in the near future.

      Flash currently has the best ECMA4 implementation out there, and fastest. And it's available right now, today, on all browsers, on Windows, Mac and Linux.

      • Re: (Score:3, Insightful)

        by Bent Mind ( 853241 )
        I mean Flash 9 and Flex 2 are out just couple of months ago... And it's available right now, today, on all browsers, on Windows, Mac and Linux.

        Yes, it will be nice when Flash 9 is finally released (rumor says sometime early next year). I get so tired of flash sites telling me that I need to upgrade to the current version. I'm running the current version (7.0.68)!

        Sorry, it's very annoying! Personally, I don't understand why flash is used as a video format. What is wrong with the other hundred or so for
    • ``In other words... what might succeed at doing exactly what Java and Flash promised to do, but have failed?''

      In my eyes, that would be: setting open standards that can be freely implemented in handy plugins for all platforms.

      Flash is actually pretty successful, but, unfortunately, many Flash applets or whatever they're called only work with the latest versions from Adobe/Macromedia, which are not available to everyone.

      Java applets failed because Java is unwieldy, both as a programming language and as a run

    • Re: (Score:2)

      by kaffiene ( 38781 )
      Applets in Java were ahead of their time. They ran poorly on the CPUs and VMs of a decade ago. They're pretty good now (check out ThinkFree).

      A current issue with Applets is the delay to start, but a Java application launched from within an already running VM launches pretty much instantaneously - which points towards the solution, no?

  • java (Score:2, Insightful)

    by Sicnarf ( 529730 )
    applets, modified for fullscreen w/ an easier alternative to swing.
    • That's close to my thought. A simple Java browser that uses RMI to run other classes that make up applications.

      I can't see what you mean by an easier alternative to Swing. Do you mean from the programming end? I've found Swing easier to program with than some GUIs I looked at and tried to code in.

      Hal

  • Some thoughts (Score:4, Insightful)

    by plopez ( 54068 ) on Tuesday November 21, 2006 @01:29AM (#16925652) Journal
    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.
    • for an example, see the iTunes <strike>Music</strike> Store.
    • 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.

      It would be Java?

    • Re: (Score:2)

      by GWBasic ( 900357 )

      You're describing ClickOnce [microsoft.com]

      ClickOnce is an immature technology from Microsoft that sandboxes a .Net application that's stored in a web server. If the .Net WinForms API, (or another cross-platform GUI API) is generally accepted on the Mac and Linux, ClickOnce will provide what you describe.

      Basically, what happens with ClickOnce is that you compile a standard .Net application using a few extra switches, and drop it on a web server. When the user clicks on a link. the newest DLLs are automagically downloa

  • Distributed IIOP services via IDL, RMI, or SOAP/XML.

    The browser is reduced to a layout engine for active widgets or applets, or some variant on XUL or XForms.

    "Web" is a misconception derived from the assumption that IP traffic must be HTTP/HTTPS based. There are another 32000+ ports aside from 80 and 88...

  • Prognostication Central (Score:3, Insightful)

    by zappepcs ( 820751 ) on Tuesday November 21, 2006 @01:30AM (#16925656) Journal
    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.
  • Do it violently and make sure you get the job done.
    • Yes, that's right. It's not the technically superior approaches that succeed, but the ones that are there and the ones that are hyped. It's more important that you get something working and that you get people to use it than it is to get it right the first time. Worse is better.

      • Re: (Score:2)

        by crossmr ( 957846 )
        Of course its not. How many times have you seen the superior product fail because of the marketing power of the inferior one? 50%? 75%? 99%?

        I never said it was right, just how I'd go about it.

  • JVM (Score:3, Insightful)

    by nickos ( 91443 ) on Tuesday November 21, 2006 @01:34AM (#16925676)
    How about the JVM, seriously?

  • Microsoft? (Score:2, Informative)

    by Dan East ( 318230 )
    that doesn't stop Google, Microsoft and others from trying their best to use them to build office suites and the like.

    How can you include Microsoft in that sentence? They have done more to harm and impede the WWW than all other entities combined. You make them sound like they are doing something ground-breaking and cutting-edge. If MS could be granted one wish, they would ask for the death of "Web 2.0" and the return to static html, thus protecting their well-entrenched product line and business model.

    Da
    • If that is so, then why can I use MICROSOFT Visual Basic and imbed a copy of MICROSOFT Internet Explorer in any app I'd like in 6 mouse clicks? The web browser is embedded as a core element of their flagship product, which has helped make the Internet available to the public at large. If that's "harmed", then I wish we'd see more software writers "harm" the web.

      • Re: (Score:2)

        by jZnat ( 793348 ) *
        Because MSIE doesn't follow any standards but its own, and it took almost 10 years for them to fucking fix at least some of its thousands of problems. I'd say they fucked up the web, and it's going to take a while to fix it.

    • Re: (Score:2)

      by smchris ( 464899 )
      and the return to static html

      "Static" I don't agree with.

      Otherwise, yes. Microsoft is ONE COMPANY. Unfortunately, their #1, foundational philosophical policy as the monopoly company is and always has been in all things to make _sure_ they break standards with the rest of the world. Having just put highlighter to the last page of "Professional JavaScript for Web Developers" last week the basic truths are fresh in my mind that:

      1) Everyone knows the obvious that JavaScript currently has to be written twice
  • Wasn't the web browser supposed to die in like, 1998? Substitute "push media" for "Web 2.0" and its the same old song. While we're at it, lets usurp the WIMP interface metaphor and bring back VRML. Anybody have one of those pets.com mascots lying around? We can have a theme party.


    The web browser isn't going anywhere anytime soon. Nor should it.

  • Ideas (Score:4, Interesting)

    by illuminatedwax ( 537131 ) <stdrange@alumni. ... u ['go.' in gap]> on Tuesday November 21, 2006 @01:49AM (#16925814) Journal
    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: (Score:2)

      by Dom2 ( 838 )

      sack Javascript and replace it with something better, like an iteration of Python

      You mean like JavaScript 2?

      -Dom

    • Re: (Score:2)

      by 4of12 ( 97621 )
      I agree. While AJAX is teh hot new thang, Javascript still sucks. Python would be great if:
      1. It could live in a sandbox on the machine.
      2. It had a powerful cross-platform widget set.
      3. It was based on scalable vector graphics.

      I think using Python as Jython running on the JVM would satisfy part of this.

      Perhaps a PyQT or Swing widget set would fit the bill, but maximum niceness is always hard to achieve cross-platform.

      The SVG initiative has the right idea, but it's married to javascript and dom and, last I h

  • XRC (Score:2, Insightful)

    by NNland ( 110498 )
    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 wha

  • "Usurp"? (Score:2, Insightful)

    by TodMinuit ( 1026042 )
    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 an

  • iTunes does this already (Score:4, Insightful)

    by SuperKendall ( 25149 ) on Tuesday November 21, 2006 @01:54AM (#16925854)
    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.

  • Simple is fast is good (Score:4, Insightful)

    by jd ( 1658 ) <imipak@ y a hoo.com> on Tuesday November 21, 2006 @01:54AM (#16925856) Homepage Journal
    HTML took off, not because it could do everything, but because the little it could do, it did well and did fast. XHTML is not taking off, because it tries to do everything badly. Most modern web developers stack together a number of technologies, each tuned to a relatively narrow range of tasks. This RISC-style of development is the way forward, with highly modular, highly pluggable, highly specialized technologies replacing the uber-generic.


    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!!!!

    • "XHTML is not taking off, because it tries to do everything badly."

      I'm not sure what you think XHTML is, but I'm pretty sure it's not what you think.

      XHTML is nothing more than HTML with the syntax normalized enough to make documents XML-conformant. If you like HTML, there's nothing about XHTML not to like -- unless you have an irrational aversion to lowercase, self-closing tags, or required quote-enclosed values for attributes.
  • I actually spent a bit of time the past few months working on a research project dealing with similar questions. I haven't finished a paper yet, but there's slides [rose-hulman.edu] from a presentation I gave. (hopefully a comment this far down won't crash my computer...)

    Basically what I was working towards was somethings similar to ajax but with a more appropriate and protocol and without the browser. The two main things I dislike about Web 2.0 applications is that 1. They have to run in a browser, and 2. they take up a
  • piss poor answers so far, basically more of the same.

    If all you want to do is app hosting, be it a store or an ERP package then a secure version of something like X or VNC is perfect. Many clients and servers available, standards available, bandwidth is probably there for the most part. Before you dis this solution make damn sure you understand what X can do e.g run seamlessly with normal apps etc.

    Go a step further brings in things like 2nd life etc. The apps are going to be non traditional and maybe eve

  • "feature-rich interactive networked apps" - NOT (Score:4, Insightful)

    by Animats ( 122034 ) on Tuesday November 21, 2006 @02:23AM (#16926148) Homepage

    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 [whatwg.org].

    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.

    • Excellent post.

      I don't see much hope for the short-to-medium term, though, with the content mafia pushing executable content hard and Microsoft poisoning efforts for declarative content with proprietary solutions (VML, XAML) or foot-dragging (ECMAScript, CSS). I don't think this is going to change until other platforms (probably phones) eclipse Windows as the dominant web client platform.

      Is anything happening with WebForms, btw? That "This document is in the very final stages and will very shortly become a
    • Once again, a security-minded professional ignores the fact that the market ignores security.
  • The "correct" answer depends on what exactly it is you want to do.

    The tricky thing about answering this question is that it is easy to end up with an answer that already exists.

    "I want to run arbitrary apps on the client as if they are on a server": Do it. Terminal services, VNC, whatever.

    "I want to be able to write a chat client that runs in the browser": All you really need here is real socket support instead of hacked up AJAX running on HTTP, which is an excellent protocol for many things, but not a cont

    • Re: (Score:2)

      by Jerf ( 17166 )

      By market share, all have failed; all that has survived is the web browser and its basic standards.

      Clarification (it's late for me): By "market share" I mean including HTML+Javascript "applications" and pages; Flash isn't a "failure" in the conventional sense, but for every truly Flash-based site (not just animations or fancy menus but truly flash based; the only one I can think of off the top of my head is J. K. Rowling's site [jkrowling.com]) there are probably a hundred basically HTML+Javascript sites, like Slashdot or

  • OS (Score:2)

    by LauraW ( 662560 )

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

    I think an application browser was called an "Operating System" last time I checked.

  • Was Office too fast or something? (Score:3, Insightful)

    by Squid ( 3420 ) on Tuesday November 21, 2006 @02:49AM (#16926372) Homepage
    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.

  • NTW (Score:4, Interesting)

    by Bluesman ( 104513 ) on Tuesday November 21, 2006 @02:56AM (#16926450) Homepage

    http://ntw.sourceforge.net/ [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.

    • Re: (Score:2)

      by Nurgled ( 63197 )

      I was considering writing something in a similar vein myself some time ago, but didn't have the time to do it all from scratch myself. However, I will take a look at your project and see how much the design has in common with mine. If I "get" your approach, I may well contribute. :)

  • ...why not have dynamically created executable machine code delivered to the user? This should get rid of all of the annoyances of Flash and the limitations of JavaScript. You could write the code in any language. The code would be sent to the browser and would be executed in the same context as the user. You could, (but would not be required to), sign the code to make sure that it wasn't modified before you received it. Considering Macs are x86 now, you wouldn't have to worry about translating the code or

  • Web is document-driven (Score:4, Insightful)

    by wikinerd ( 809585 ) on Tuesday November 21, 2006 @03:14AM (#16926626) Journal

    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


  • Haven't we had enough already of the next great thing? The only point I see that we're all in agreement over is that Web >1.0 provides a lousy pipe for bubble blowing. From where I sit, that what we have now is crappy-enough-to-be-hype-resistant is more of an advantage than a liability. Whatever straw poll was taken where we all agreed, I was not in attendance.

  • It's here already (Score:3, Insightful)

    by scdeimos ( 632778 ) on Tuesday November 21, 2006 @03:56AM (#16927004)

    XULRunner [mozilla.org]

    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.

  • Usurping The Web Browser Is A Bad Idea (Score:3, Insightful)

    by roca ( 43122 ) on Tuesday November 21, 2006 @04:46AM (#16927438) Homepage
    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.

  • make the shell cool (Score:2, Interesting)

    by nthwaver ( 1019400 )
    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 t

  • I Wouldn't (Score:3, Interesting)

    by RAMMS+EIN ( 578166 ) on Tuesday November 21, 2006 @05:06AM (#16927592) Homepage Journal
    ``"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).

    • Re: (Score:2)

      by ardor ( 673957 )
      In short:
      We need to stop mixing web *applications* with web *documents*.

      Things like Horde or Plesk are perfectly OK as webapps, but not with web document technology (HTML/CSS/Javascript).
  • What type of platform would you like to see delivering the 'true' Web 2.0 in the not too distant future?

    Something that uses a combination of BitTorrent, Gopher, AFS, TOR, GFS and Tor. :-)

    Seriously, everything could be decentralized - both datastore and computations could be done in p2p. Today's powerful home computers and widespread broadband has created an infrastructure that's ripe for real distributed networking - by and for everyone.

  • A distributed programming language is the solution (Score:3, Insightful)

    by master_p ( 608214 ) on Tuesday November 21, 2006 @07:03AM (#16928334)

    First of all, let's all have a look at REBOL [rebol.com].

    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. [sun.com]

    For example, if I wanted to make a simple login form, the code would be something along this:

    let username = ''
    let password = ''

    let loginForm = page [
    title = 'login'
    layout = grid 2x3
    label [text = 'username:']
    textbox [model = username]
    label [text = 'password:']
    passwordbox [model = password]
    button [text = 'submit' click = {close [form = loginForm value = true])}]
    button [text = 'exit' click = {close [form = loginForm value = false])}]
    ]

    let ok = do(loginForm)

    if ok then
    login(username, password)
    else
    doPage('loginFailed')
    end if

    function login(username, password)
    let loginOk = server.login(username, password)
    if loginOk then
    doPage('mainScreen')
    else
    doPage('loginFailed')
    end if
    end function

    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:

    1. the whole thing is programmable and there is nothing hardcoded.
    2. the problem of distributed communication is solved right at the most fundamental level.
    3. security can be applied to the whole of the language, since distributed communication is the foundation of the system.

  • Stop this Progress! Stop it, I say! (Score:3, Insightful)

    by dpbsmith ( 263124 ) on Tuesday November 21, 2006 @07:24AM (#16928458) Homepage
    (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.

  • we need to replace the Document Browser with an Application Browser

    Then it won't be big. Very, very few people need that, and few people want that.

    Then there's the problem that the most popular web browsers can't even safely show documents, and now you want it to run foreign code? You're basically trying to re-invent a program called Internet Explorer. If you're going to follow up on that nonsense, at least wait for virtualization hardware to get more ubiquitous first, because given the industry's tr

  • My take is that any move away from web browsers will take decades to occur. The interface exists and is widely established. The hardware, software, and knowledge requirements needed to support a web browser are relatively mild, meaning that the relatively poor or technically incompetent will continue to use what works. There is an established user base of on the order of a billion users. Finally, if you want to build "feature-rich interactive networked applications", web browsers are more than adequate as
  • Which will be replaced in turn by mainframes.

    I'm not kidding. Web 4.0 will be X12.
  • isn't Active X and all the threats it pose the same kind of thing that an 'application' browser threatens?

    think about it- right now, just looking at web pages with IE can cause all kinds of evil computer problems.

    imagine running random net apps in your 'application' browser..
  • why cant you make a application server/interface that goes along with web? do you hate http that much that you think it must die?

    Sounds like a good student project. make a application server/client system.
  • What type of platform would you like to see delivering the 'true' Web 2.0 in the not too distant future?

    Well, I think a good replacement would have a rich set of controls packaged with a robust windowing system so that the user could easily dynamically interact with the system. But, in some cases, latency is a problem, so it might be a good thing to offload some of the caching and processing locally and just send messages back to the server when necessary to garner information. Yeah, the more I think abo

  • Everyone here knows that HTML, Javascript and HTTPRequest are not the tools for building feature-rich interactive networked applications

    All HTML governs is the formatting of output. You have your client/browser as the UI, which sends and receives I/O back and forth, and what's on the server can be as "feature-rich" as you like. Add low-latency I/O queuing and limited event pre-emption (a la what they typically have in your average online FPS) with a Flash application masking it in the browser...and you're c
  • Let's quit trying to make a perfectly good web-browser into a cheap X-Server. Web browsers are GREAT at doing what they
    were meant to do: browse the web. However, they suck at being a freaking X-Server, which is what everybody seems to
    be trying to make the browser over into.

    I mean, thank about it: what's the job of an X-Server? It's to receive data from a remote application running some logic "somewhere"
    and provide the display capabilities: drawing widgets on the screen, receiving keyboard input and mouse-

  • This isn't so much a technical question as a business and political question. So far, the way this sort of thing is being done in web browsers is that some company provides a closed-source app, stores your data for you, and pays their bills by putting ads on your screen. If that's what people want, that's cool for them, but if I can't dance to it, it's not my revolution. One big advantage of redoing the whole thing without tying yourself to a web browser as the platform is that it would let you design the w

  • It's already there!

    If not Java - something exactly like Java :o) You need a VM so that you have a well known target that allows content to run cross platforms. You need security and you need a full-featured API over the top of that.

    The web should be inverted - all browsers should be Java VMs so they can run content directly and quickly and HTML content should be handled as a special case. Doing apps in HTML and Javascript is *really* dumb.

Slashdot Top Deals

I tell them to turn to the study of mathematics, for it is only there that they might escape the lusts of the flesh. -- Thomas Mann, "The Magic Mountain"

Close