Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

How Would You Usurp the Web Browser?

Cliff posted more than 7 years ago | from the survival-of-the-fittest dept.

149

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?"

cancel ×

149 comments

Sorry! There are no comments related to the filter you selected.

Why? (3, Insightful)

elbenito69 (868244) | more than 7 years ago | (#16925590)

I think a better question would be: Why Would you Usurp the Web Browser?

Re:Why? (1)

creimer (824291) | more than 7 years ago | (#16925640)

It's a Monday night. I'm bored to death in my Unix Administration class learning about web servers. Why not?

Why? Simple! (1)

camperdave (969942) | more than 7 years ago | (#16925722)

Why would you usurp the web browser? Simple, to take it out of Microsoft's hands.

Re:Why? (2, Interesting)

plopez (54068) | more than 7 years ago | (#16925968)

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.

Re:Why? (1)

marcello_dl (667940) | more than 7 years ago | (#16928356)

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 ease of installation of packages on different architectures will make many people consider reverting to client server apps.

But the browser isn't going away until internet porn is available, sorry.

Re:Why? (2, Insightful)

DaveV1.0 (203135) | more than 7 years ago | (#16930030)

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. (4, Insightful)

Pfhorrest (545131) | more than 7 years ago | (#16926220)

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.

Also... (1)

Pfhorrest (545131) | more than 7 years ago | (#16926314)

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 category of files as a Word doc (rich text with other embedded media), is wrong.

Re:Not usurp, but augment. (1)

CowboyBob500 (580695) | more than 7 years ago | (#16927394)

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.
You've just described Java WebStart [javaworld.com]

Some of the ease-of-use and ease-of-programming features associated with Java Web Start include:
  • Portability: Java Web Start is available on Windows, Solaris, and Linux, and is expected to be ported to other platforms.
  • Caching: Applications launched with Java Web Start are cached locally. Thus, an already-downloaded application is launched on par with a traditionally installed application.
  • Maintainability: If the remote application is updated, Java Web Start updates the locally cached version at the application's next invocation.
  • Easy launching: Java Web Start allows applications to be launched independently of a Web browser. The application can also be launched through desktop shortcuts, making launching the Web-deployed application similar to launching a native application.
  • Ability to work offline: An application can be used in situations where launching through the browser is inconvenient or impossible.
Bob

Re:Not usurp, but augment. (1)

EsbenMoseHansen (731150) | more than 7 years ago | (#16927772)

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.

Re:Not usurp, but augment. (1)

CowboyBob500 (580695) | more than 7 years ago | (#16928312)

I'm not a fan of Java WebStart (and I'm a professional Java developer). I was merely pointing out that what the grand-parent was suggesting has already been done.

Bob

Re:Not usurp, but augment. (0)

Anonymous Coward | more than 7 years ago | (#16928044)

Portability: Java Web Start is available on Windows, Solaris, and Linux, and is expected to be ported to other platforms.

No OS X support? Forget it, then. What's "portable" about a product that only supports Windows plus the non-existent Solaris and barely-existent Linux desktop markets? It might as well be Windows-only for all the use that is, and if you're only targeting Windows you might as well just use .NET and get better support and better GUI performance.

Re:Not usurp, but augment. (1)

CowboyBob500 (580695) | more than 7 years ago | (#16928298)

No OS X support?

It does support OSX (I use a Mac myself). That article is a bit out of date (2001) but was the best article I could find in the 20 seconds I searched...

Bob

Re:Not usurp, but augment. (1)

Vlad_the_Inhaler (32958) | more than 7 years ago | (#16927642)

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 had never thought of it this way before, but Gates' logic must have been a bit similar when it came to using Internet Explorer for everything under Windows (leaving aside the 'smash Netscape' issue). The 'Explorer' software should allow you to go everywhere, look at anything and execute anything. So far, so good and all very user-friendly. Only one really tiny problem - security. The Explorer concept did not take account of sites hiding inimical software and forcing it to be executed, it did not even take account of CDs causing damage via AutoRun. Active X and maybe JavaScript (not from Microsoft) place too much trust in the outside world. Even adding a firewall-like trust-level (Local=Trusted, DMZ, outside=untrusted) was not enough.

Any browser replacement has to know when to stop, what not to execute. I don't think it is going to happen because far too many people and sites will not be prepared to give up the comfort a browser offers for an increase in security.

Not an easy question (2, Interesting)

BadAnalogyGuy (945258) | more than 7 years ago | (#16925612)

This is a really good question.

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

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

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

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

Re:Not an easy question (1)

Z0mb1eman (629653) | more than 7 years ago | (#16925668)

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

Re:Not an easy question (1)

Mr. Hankey (95668) | more than 7 years ago | (#16927158)

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.

Re:Not an easy question (1)

RAMMS+EIN (578166) | more than 7 years ago | (#16927764)

``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="sCurrMessageLine" type="boolean"/>
            <state-var name="sOldMessageLines" type="boolean"
                size="&MESSAGE_COUNT;"/>
            <state-var name="sButton" type="boolean" size="5"/>
            <state-var name="sButtonFlasher" type="int" size="5"/>
            <state-var name="sHelpText" type="boolean"/>
            <state-var name="sLoadSounds" type="boolean"/>
        </state-variables>
        <variables>
            <var name="mButtonBackColor" type="int"/>
            <var name="mButtonForeColor" type="int"/>
            <var name="mTextHeight" type="int"/>
            <var name="mScreenWidth" type="int"/>
            <var name="mScreenHeight" type="int"/>
            <var name="mArrowUpPos" type="int" size="2"/>
            <var name="mArrowDownPos" type="int" size="2"/>
            <var name="mArrowLeftPos" type="int" size="2"/>
            <var name="mArrowRightPos" type="int" size="2"/>
            <var name="mFirePos" type="int" size="2"/>
            <var name="mCurrMessageLine" type="string"/>
            <var name="mOldMessageLines" type="string"
                size="&MESSAGE_COUNT;"/>
            <var name="mMessageLineStartOffset" type="int"/>
            <var name="mSoundLoaded" type="boolean"/>
            <var name="mSoundFallback" type="boolean"/>
            <var name="mSoundURL" type="string"/>
        </variables>
        <functions>
            <!--
                Flashes the requested button by swapping the colors
                and turning on a state variable with a delay.
            -->
            <function name="flashButton" type="void">
                <parameters>
                    <var name="button" type="int"/>
                </parameters>
                <script>
// Set flash colors.
                    mButtonBackColor = &_COLOR_YELLOW; ;
                    mButtonForeColor = &_COLOR_BLUE; ;
 
// Show button in flashing mode.
                    _clear_state(sButton[button]);
                    sButton[button] = true;
 
// Restore colors.
                    mButtonBackColor = &_COLOR_BLUE; ;
                    mButtonForeColor = &_COLOR_YELLOW; ;
 
// Start flash countdown.
                    if (mSoundLoaded)
                    {
                        sButtonFlasher[button] = &FLASH_SOUND; ;
                    }
                    else
                    {
                        sButtonFlasher[button] = &FLASH_DELAY; ;
                    }
                </script>
            </function>
The /. filter and I agree that it's lame and overly repetitive.

Re:Not an easy question (1)

BadAnalogyGuy (945258) | more than 7 years ago | (#16927832)

I agree. The XML syntax is a bit chatty. If you look at the actual executable code in that sample, it's not very much compared to the amount of XML overhead. However once you get past the wordiness (using a good editor), the simplicity of the language and the ease of creating quick mockups makes it very useful for quick prototyping.

It would have been nice if they used a less verbose language for implementation, though.

Get rid of it (1, Troll)

jlarocco (851450) | more than 7 years ago | (#16925614)

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

Please enter your credit card number (1)

tepples (727027) | more than 7 years ago | (#16925764)

Taking out the [etc] and advertisements would be a nice start.

People who create works need to eat, and people who ensure the quality of works also need to eat. Would you rather be presented with one sentence and a form asking for your credit card number to read the rest of the article? Without advertisements, this is what the web would become. Just look at articles published in scholarly journals; if you're not a student or faculty, the PDFs cost big bucks.

Re:Please enter your credit card number (1)

jlarocco (851450) | more than 7 years ago | (#16925910)

Would you rather be presented with one sentence and a form asking for your credit card number to read the rest of the article?

Actually, I like it the way it is right now. I'm sure the advertisements are there, but I never see them. And it's free.

But when it comes down to it, I'd rather pay a few bucks than have advertising shoved in my face.

Re:Please enter your credit card number (1)

werewolf1031 (869837) | more than 7 years ago | (#16927698)

But when it comes down to it, I'd rather pay a few bucks than have advertising shoved in my face.
Speak for yourself. For those of us on a budget, it's better to deal with a few ads and have free content, than to have to pay to read articles or use web-based applications. Maybe YOU can afford to pay to have ads removed from X number of web-based apps or articles, but some of us can't, and it'd be nice to at least have the option to either pay for no ads or have free content with ads. Right now, on my modest income, I'll gladly deal with a few ads (to a point) to get content for free. I personally dislike ads as much as the next guy, but the harsh realities of economics are a more prevalent factor for some of us than dealing with a few annoying advertisements.

Re:Get rid of it (1)

wikinerd (809585) | more than 7 years ago | (#16926830)

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.

wrong question (1)

tezbobobo (879983) | more than 7 years ago | (#16925622)

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 WebOS's. (I persoanlly think this question is to broad.)

Re:wrong question (1)

The_Wilschon (782534) | more than 7 years ago | (#16925988)

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?

Re:wrong question (1)

tezbobobo (879983) | more than 7 years ago | (#16927126)

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.

Re:wrong question (1)

RAMMS+EIN (578166) | more than 7 years ago | (#16927170)

``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 (4, Insightful)

Z0mb1eman (629653) | more than 7 years ago | (#16925626)

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 (0)

Anonymous Coward | more than 7 years ago | (#16926230)

> 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. :)

I would like to see a network-enabled, p2p + client/server model, database-driven, object-oriented, multimedia application framework.

*ahem*

Now, having gotten the buzzwords out of the way, I do think someone (everyone, actually) missed the opportunity to put together an easy-to-use tool that combines the best features of:

  • QuickTime Pro
  • Flash
  • HyperCard
  • OpenDoc
  • FileMaker
  • XML/DHTML/JavaScript
  • DreamWeaver
  • WebDAV
  • Java
  • Visual Basic
  • Konquerer

And no, I am NOT kidding! :)

Re:'True' Web 2.0 (4, Informative)

suv4x4 (956391) | more than 7 years ago | (#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:'True' Web 2.0 (1)

Gnulix (534608) | more than 7 years ago | (#16929426)

Adobe also donated their supposedly (for Flash haters) "crappy" Flash 9 JS engine to Firefox, which will replace SpiderMonkey in the near future.

I thought it was scheduled to go in no sooner than 2008. That's hardly the "near future"!

Re:'True' Web 2.0 (1)

RAMMS+EIN (578166) | more than 7 years ago | (#16927888)

``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 runtime. Perhaps it wouldn't have been so bad if it hadn't been introduced in an era where most people still had dial-up connections, but you're just not going to wait and hour and pay connection fees just to be able to view one nifty applet that requires a different version of the runtime.

java (2, Insightful)

Sicnarf (529730) | more than 7 years ago | (#16925632)

applets, modified for fullscreen w/ an easier alternative to swing.

Re:java (1)

TheWanderingHermit (513872) | more than 7 years ago | (#16925928)

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 (3, Insightful)

plopez (54068) | more than 7 years ago | (#16925652)

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.

Some thoughts-XMPP (0)

Anonymous Coward | more than 7 years ago | (#16925858)

"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."

Jabber.

Re:Some thoughts (1)

Hes Nikke (237581) | more than 7 years ago | (#16926114)

for an example, see the iTunes <strike>Music</strike> Store.

Re:Some thoughts (1)

dk.r*nger (460754) | more than 7 years ago | (#16929674)

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?

What web? (1)

msobkow (48369) | more than 7 years ago | (#16925654)

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

Firewalls (1)

tepples (727027) | more than 7 years ago | (#16925804)

"Web" is a misconception derived from the assumption that IP traffic must be HTTP/HTTPS based.

This misconception is not only (or possibly even primarily) on the part of "web service" providers. It is a misconception on the part of enterprise IT personnel, who use port whitelisting at the firewall to slow down information security breaches.

Prognostication Central (2, Insightful)

zappepcs (820751) | more than 7 years ago | (#16925656)

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.

Don't overthink it... (1)

crossmr (957846) | more than 7 years ago | (#16925662)

Do it violently and make sure you get the job done.

Re:Don't overthink it... (1)

RAMMS+EIN (578166) | more than 7 years ago | (#16927900)

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:Don't overthink it... (1)

crossmr (957846) | more than 7 years ago | (#16929822)

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.

blinking lights (1)

corychristison (951993) | more than 7 years ago | (#16925664)

'nough said. ;-)

JVM (2, Insightful)

nickos (91443) | more than 7 years ago | (#16925676)

How about the JVM, seriously?

Seriously? - How about CXAP? (1)

jethr0211 (996156) | more than 7 years ago | (#16925990)

The new trend: Closed-standard Xml Acquisition of Patents That seems to be catching on pretty well lately.

Microsoft? (1, Informative)

Dan East (318230) | more than 7 years ago | (#16925704)

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.

Dan East

Re:Microsoft? (1)

NineNine (235196) | more than 7 years ago | (#16925816)

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:Microsoft? (1)

jZnat (793348) | more than 7 years ago | (#16927330)

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:Microsoft? (1)

Osty (16825) | more than 7 years ago | (#16926024)

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 it wasn't for Microsoft, this whole "AJAX" thing never would've been possible in the first place. See, late in 1998 Microsoft released an ActiveX control called "XMLHTTP" that they used with their Outlook Web Access software that ships with Exchange to make a very compelling user interface. It was leaps and bounds ahead of all webmail software for a number of years. Later, around 2003, Opera and Firefox jumped on the bandwagon, taking the interface defined by XMLHTTP and implementing it in their browsers without the need for ActiveX. They called it XMLHttpRequest, and it's the basis for the first "A" and the "X" in "AJAX". It took Google to really publicize the availability of such coolness with Google Maps and Gmail, but that was more a failing of Microsoft's marketing department than any technical problems. Sure, developers have used hidden frames and iframes to fake asynchronous calls for years, but the essence of AJAX/Web 2.0 is the ability to easily make an asynchronous call without any hacks.

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.

Web 2.0 applications are not going to kill the Microsoft cash cows of Windows and Office any time soon. If anything, Microsoft is leveraging the web to make their offerings even more compelling, with rich RSS support in IE7 and Vista, the Windows and Office Live family of products, etc. They may not be the most innovative of services (though they have beaten Google to the punch several times -- Live.com gadgets and Live Favorites, for example), but it's a core area of growth at Microsoft with massive investment and potential.

If anything, how could you possibly exclude Microsoft from a list of companies making an impact with web-centric software.

(Yes, I know this sounds like a shill, so let me get my geek creds back. I've run Linux since 1997, my entire home network is managed by a Debian box, I have a Nintendo Wii as well as an Xbox 360, I've never had a virus, and I once set up a quad-boot system for a friend that switched between two different distros of Linux, NT 4.0, and Windows 98. There, that should do it ... :)

Re:Microsoft? (0)

Anonymous Coward | more than 7 years ago | (#16930418)

If it wasn't for Microsoft, this whole "AJAX" thing never would've been possible in the first place.See, late in 1998 Microsoft released an ActiveX control called "XMLHTTP"

Bullshit! People were already able to exchange data between the sever and client via a hidden frame. Stop being such a Microsoft fanboi. Next you'll want Gates for president or some other shizzle.

Re:Microsoft? (1)

smchris (464899) | more than 7 years ago | (#16929418)

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: once for IE and once for Mozilla.

2) Why? Because the ECMA can hold as many committee gatherings as it likes and while Mozilla, Opera and Konqueror may (very, very) imperfectly try to develop along the lines of the Document Object Model and ECMAScript, Microsoft will time and time again demonstrate their willingness to go off in whatever direction they choose.

So, either Microsoft somehow can be persuaded, uncharactistically, that playing with others is good or Mozilla, Opera, and Konqueror can give up. But if you DON'T believe that "My way or the highway" is the best way to do things and you DO believe that cooperation between browser creators on _standards_ IS a good thing, then Microsoft IS and HAS BEEN the 800 lb attitude problem at the source of the chaos. How we make progress on a _standard_ IS a problem when Microsoft fights it every step of the way.

wow, and only 8 years later.... (1)

DwarfGoanna (447841) | more than 7 years ago | (#16925718)

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 (3, Interesting)

illuminatedwax (537131) | more than 7 years ago | (#16925814)

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:Ideas (1)

Osty (16825) | more than 7 years ago | (#16926142)

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

There's nothing wrong with Javascript as a language. In fact, it's actually more powerful than Python, considering that Javascript really is a functional language (it's based around closures as first-class objects, where classes, functions, even variables are really nothing more than closures as far as Javascript is concerned). The problem is with the implementation of the engine inside of web browsers. The lack of proper threading is a real killer, for example. Changing the language will not solve that problem (see VBScript for an example).

make the focus more on manipulating the DOM than verifying forms

I don't know about you, but the Javascript I've been doing lately [live.com] is 99% DOM manipulation, 1% form verification.

move the user authentication parts from the documents themselves (PHP, etc.) and into the web page server

Isn't that already the case? Seems to me that client-side authentication would be rife with problems, and thus all authentication methods I know of are either 100% server-side (IIS' basic auth or Apache's .htaccess, for example) or use little or no javascript client-side just for sanity-checking before sending off the credentials for server-side validation via Perl, PHP, Ruby, ASP, ASP.NET, etc.

make the network support better

I whole-heartedly agree! XMLHttpRequest is good for what it is, but it has too many problems and limitations. Granted, some of those are security-related (Same Origin Policy), but others (threading) could be solved with a better framework.

Re:Ideas (1)

illuminatedwax (537131) | more than 7 years ago | (#16926546)

There's nothing wrong with Javascript as a language. In fact, it's actually more powerful than Python, considering that Javascript really is a functional language

Actually, Python is just as much of a functional language as Javascript - it does the same thing. The problem I have with Javascript is its slim pickings in data processing. Python has dicts, arrays, and tuples, and built-in methods to make your classes behave like these objects. Really, this is six/half dozen stuff, but the REAL negative to Javascript is the complete lack of good documentation out there.

You're right, however, in that the real evil is how browsers implement Javascript.

I don't know about you, but the Javascript I've been doing lately is 99% DOM manipulation, 1% form verification.

Javascript has evolved into this kind of creature - there's tons of ugly crud left over from the old days when it was about form validation. I think if you really wanted to see things improve, you'd start over. In addition, all of the documentation on Javascript is about 99% form verification and Stupid Browser Tricks and 1% DOM manipulation.


Isn't that already the case? Seems to me that client-side authentication would be rife with problems, and thus all authentication methods I know of are either 100% server-side (IIS' basic auth or Apache's .htaccess, for example) or use little or no javascript client-side just for sanity-checking before sending off the credentials for server-side validation via Perl, PHP, Ruby, ASP, ASP.NET, etc.

The server-side validation all comes from externals like PHP. What we need is something like HTTP authentication. The authentication procedure is a good start, but it needs to be implemented in the browsers a lot better for it to really work. For example, a form input indicating that this is a user/password box rather than some popup getting in the user's way. Also letting users destroy authentication information.

I think, then, that the solution would be to rewrite parts of the browser, destroy Javascript and start over again.

This of course has been said for YEARS, I'm certain.

Re:Ideas (1)

uradu (10768) | more than 7 years ago | (#16930354)

> Python has dicts, arrays, and tuples

And JS has--the same. Don't get me wrong, I do like Python, but I've really started to like and appreciate the power of JS since using it more intensively.

XRC (2, Insightful)

NNland (110498) | more than 7 years ago | (#16925834)

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.

"Usurp"? (2, Insightful)

TodMinuit (1026042) | more than 7 years ago | (#16925840)

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.

iTunes does this already (3, Insightful)

SuperKendall (25149) | more than 7 years ago | (#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 (3, Insightful)

jd (1658) | more than 7 years ago | (#16925856)

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

Bigger Tubes (0)

Anonymous Coward | more than 7 years ago | (#16925884)

Bigger Tubes.

Research project (1)

andy753421 (850820) | more than 7 years ago | (#16925902)

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 lot of resources (browser resources and separate connections for each new content request). There's a few things of interest that already exist for some application of the future, for starters there's CORBA which is a distributed object based system. That can be useful for traditional applications but I would rather have a client-server type architectures where all the processing happens on the server side and only the display is on the client side. This makes it better for low power things like smart phones other mobal devices, as well as helps keep all the data on the server so it can be accessed from anywhere. The 9P protocol from Plan9 is also an interesting thing when dealing with distributed programing. It's not a complete suite by itself but it could have some uses in replacing HTTP and/or HTML.

Anyway to answer the question, here's some things I think a 'Web 3.0' should be (from my slides):
  • Text based like RSS and Atom feeds
  • Interactivity like X11/RDP/VNC and Ajax
  • Ability to run standalone programs like X11 (e.g without a browser)
  • Private vs. Shared sessions like VNC

Good question.... (1)

Usquebaugh (230216) | more than 7 years ago | (#16925938)

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 even interesting. But be careful of vendor lock in.

Alan Kay has a nice project going with croquet, maybe in a few years that'll start to gain traction. would solve the centralised server problem of 2nd life and get back to the net as an end to end system.

The thing to grasp is that the net is just a net, bandwidth and latency are the limits not the protocols.

Personally, I hope that people start to use X or some such client rather like they used to use telnet. Would make things a lot easier all round.

ssh kinslayermud.org (-1, Offtopic)

dcapel (913969) | more than 7 years ago | (#16926032)

Last login: Sat Nov 18 06:40:30 2006 from dsl-is-an-ip-address.slashdot.lame-filter
narg@km ud:~$ ls
10.weave       Merge.tar.bz2         index.php                    livemud.zip
11.weave       PHProxy.class.php     javascript.js                mbox
12.weave       README.txt            kbak                         merge
13.weave       TODO.txt              kinslayer                    src
14.weave       a.out                 kinslayer-8.28.tar.bz2       style.css
15.weave       circle                kmerge-8.25.tar.gz           temp_bak.tar
CVS            copy.tar.bz2          kmud.2006-08-06.bak.tar.bz2  test.cpp
ChangeLog.txt  current-25th.tar.bz2  kmud7-11.tar.bz2             url_form.inc
FAQ.txt        current6-30.tar.bz2   ksrc-7-15.tar.bz2            weave_chart.xls
From Galnor    dg_mobcmd.cpp         ksrc7-25.tar.bz2             weaves
LICENSE.txt    dg_objcmd.cpp         ksrc8-1.tar.bz2              weaves.tar
Mail           dg_wldcmd.cpp         livemud.tar.bz2
narg@kmud:~$                                           

XRC (1)

NNland (110498) | more than 7 years ago | (#16926050)

Due to a crashed browser and little patience from me, this post is far shorter than it was, but I'll sum it up with: XRC. Specifically the XML-based GUI markup that can handle widget layout in wxWidgets (wxPython, wxRuby, wxPerl, etc.).

There already exists applications that distribute updated/dynamic layouts, behavior (in Python), and state, all from a database, all using XML-RPC. I haven't messed around with XML-RPC in other languages, but if you haven't used XML-RPC in Python, you are missing something. It's a bit slower than some other TCP/IP-enabled RPC mechanisms, but in Python it's a breeze to set up. See http://aspn.activestate.com/ASPN/Cookbook/Python/R ecipe/81549 [activestate.com] for an example recipe that offers both client and servers, with comments including a threaded and forking server.

Is it the future? Maybe. I like using it today. Makes my time more productive.

Flash and/or XUL, plus SOAP (0)

darnok (650458) | more than 7 years ago | (#16926082)

I think the OP is saying that the browser/HTML combination is too big and clunky to cope with "Web 3.0", and I'd agree with that.

If you look at what Laszlo is doing with Flash, there's conceivably a large-scale future for Flash beyond dinky ads. I know Flash does useful stuff, but it's *still* used far and away for really annoying advertising, and it's really capable of a whole lot more. Unfortunately, the focus with Flash has always been on (um) flashiness and glitz over all else, and the Flash Enterprise products really haven't done much to change the perception that that's all it's good for. Laszlo really has some interesting stuff going on; the question is whether it'll reach critical mass, or something better (in capabilities, or marketing terms) comes along. A big plus of Flash as a platform is that it runs just about everywhere that a browser can run now, but it's potentially much more capable as a UI.

Mozilla's XUL adds a whole lot of useful stuff to the browser's UI capabilities. Although it doesn't seem to have caught on to any real extent, I'd like to think that today's HTML-driven sites could eventually morph into XUL (or something equally capable) in the future. If not, and HTML stays largely as it is in terms of capabilities, I can't see it being the presentation protocol of choice - it simply isn't powerful enough.

Finally, SOAP (or something equivalent) is needed to tie good looking user interfaces with backend systems. Good old stateless HTTP is well past its use-by date - although it's done a lot, there's only so much you can do with it. A fullblown RPC mechanism is going to be required to deliver Web 3.0.

Now, what the hell is Web 3.0 anyway?

"feature-rich interactive networked apps" - NOT (3, Insightful)

Animats (122034) | more than 7 years ago | (#16926148)

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.

Re:"feature-rich interactive networked apps" - NOT (1)

Hortensia Patel (101296) | more than 7 years ago | (#16929578)

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 call for implementations." message has been up for well over a year now.

Re:"feature-rich interactive networked apps" - NOT (1)

mattwarden (699984) | more than 7 years ago | (#16930348)

Once again, a security-minded professional ignores the fact that the market ignores security.

HTML is fine (0)

Anonymous Coward | more than 7 years ago | (#16926182)

We just need a better way of handling user actions and changing the page accordingly.

Represent the entire HTML page inside Python objects and let some master code modify it and have those changes reflected to the client automagically. Similarly, let that same python code parse an event loop that user events like button pushes can be added to (ok so technically yes, this wouldn't be the same old HTML, but it would still be close).

Depends. (1)

Jerf (17166) | more than 7 years ago | (#16926198)

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 continuous, small-scale back-and-forth. (Chat's a great example; the headers may well cost you a factor of 100x on the byte count.) But why not run a proper chat app? A browser by design can't integrate with the system tray or KNotify or whatever, and loading a second server with a connection to the actual IM server is silly.

"I want to write little applications that anybody can pick up and use, but I really need feature X": If you add in everybody's feature X, then before you know it, "nobody" wants to use the no-longer-simple web browser any more.

I think what it boils down to is that the very reason "mere mortals" like interacting with web "applications" is in fact a direct result of the simplicity that results from the limited palette web designers have. I've been developing on the web since 1996 and I could reel off a long list of things I'd like to see if I don't think about it, but if I think about it I start to see that for each feature I want, it would almost inevitably complicate the web and drive away the charm it has for so many "mere mortals". (I am explicitly talking about "your grandmother" here, not a Slashdot user.)

By way of evidence I offer up the long list of things that have tried to "improve" the web: Flash. Java. ActiveX. Any number of other solutions based on those. By market share, all have failed; all that has survived is the web browser and its basic standards.

Personally, if I had to choose, I'd say, maybe a few more widgets standard, certainly some tuning and tweaking, a raw socket might not hurt, but I'd rather see improvement come from the other direction: Make better desktop apps that focus on simplicity and connectivity, that don't bloat the user's desktop or act like they own it, and have better connections with the internet.

If you really nailed me down, give me some kind of standardized XBL that works across browsers. I've done what I can with that [jerf.org] and other libraries have some entries on that front too, but there are certain last little bits that really need some browser help to make them slick. For the love of Knuth, don't embed this in XML [jerf.org] , XBL and my experience prove it to be an extremely poor fit to the job of specifying widgets. (The sad thing is that it is poor in ways you can't see until you step out of the confines of the actual XBL Mozilla implements.) This really helps clean up the spaghetti code that Javascript development tends to turn into.

(In fact each browser has a poor, hacky, over-specialized implementation of the idea, but they are totally incompatible with each other and both extremely poorly known.)

Re:Depends. (1)

Jerf (17166) | more than 7 years ago | (#16926342)

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 Google Email. By that measure even mighty Flash is just a blip.

40 Years Ago Today, PLATO Taught the World to Play (1)

theodp (442580) | more than 7 years ago | (#16926226)

For the future, look to the past [classicgaming.com] !

Only one answer... (0)

Anonymous Coward | more than 7 years ago | (#16926242)

Porn. And lots of it.

OS (1)

LauraW (662560) | more than 7 years ago | (#16926350)

"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? (2, Insightful)

Squid (3420) | more than 7 years ago | (#16926372)

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 (3, Interesting)

Bluesman (104513) | more than 7 years ago | (#16926450)


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.

Instead of Javascript... (1)

Jack Schitt (649756) | more than 7 years ago | (#16926510)

...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 alienating the users. Of course Linux users and other such double-plus-unconformists would be forced to reverse engineer it.

I think this is a great idea!!! I'll call up Microsoft! They could call it Web.Net ActiveX# 2.0!!!

{{{SMACK!!!}}} No! Bad brain! Bad...

(This is written as satire. Please don't hurt me.)

Web is document-driven (3, Insightful)

wikinerd (809585) | more than 7 years ago | (#16926626)

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/Flash to the customer, but it's not easy to not use them if the customer wants them, as they may go to another designer if your creation doesn't suit their desires (not their true needs, though: few sites really need client-side interactivity beyond what CSS can offer - but we all know that few customers know or understand what they truly need in the first place!).

enough already (1)

epine (68316) | more than 7 years ago | (#16926712)


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 (2, Insightful)

scdeimos (632778) | more than 7 years ago | (#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.

I say a brick (1)

jpardey (569633) | more than 7 years ago | (#16927376)

I like bricks.

Usurping The Web Browser Is A Bad Idea (2, Insightful)

roca (43122) | more than 7 years ago | (#16927438)

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 (2, Interesting)

nthwaver (1019400) | more than 7 years ago | (#16927464)

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

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

I Wouldn't (2, Interesting)

RAMMS+EIN (578166) | more than 7 years ago | (#16927592)

``"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).

wtf?? (1)

voudras (105736) | more than 7 years ago | (#16927686)

Why the fuck would you?
It took how long to get almost everybody (yea, im being generous) on board for some fucking standards - yea, thats what we need - sign me up for another round of 52 card pickup!
The only thing we need is a clear check list for which any do-dah can apply to media - which - and it may be utopian - would clarify the difference between content and cosmetics. certainly there are situations where they should not be seperated (example, Andy Warhol's "200 Campbell's Soup Cans"), but the objective, the function, the value that this here internets provides is the transfer of information.
The only drive for "Web VII.0: A Smothering" is to put fancier lipstick on an already obvious pig.
There is a very good reason why books have not changed much - g'head and add a Figure 1a reference to a full color pie chart on page 144 - you are still only illustrating existing information (which transfers just fine in text files)

Distributed (1)

richie2000 (159732) | more than 7 years ago | (#16927724)

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.

Don't reinvent! (0)

Anonymous Coward | more than 7 years ago | (#16928180)

Learn programming(!) and wrap EVERYTHING into (e.g.) PHP functions.

If you don't get that you're not qualified enough to think about such matters.

A distributed programming language is the solution (2, Insightful)

master_p (608214) | more than 7 years ago | (#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! (2, Insightful)

dpbsmith (263124) | more than 7 years ago | (#16928458)

(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.

It's a niche (1)

Sloppy (14984) | more than 7 years ago | (#16928596)

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 track record, I don't even want that shit running on the same [virtual] machine as my home directory's filesystem.

Long shall the web browser reign! (1)

khallow (566160) | more than 7 years ago | (#16928630)

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 an interface. Just toss the appropriate plugin on top and you're good to go. My take is that web browsers and the protocols and tools like HTML, javascript, Flash, java, etc will remain the primary internet interface of choice for a long time to come.

Client side applications (1)

oyenstikker (536040) | more than 7 years ago | (#16929732)

Which will be replaced in turn by mainframes.

I'm not kidding. Web 4.0 will be X12.

document browser vs. application browser (1)

way2trivial (601132) | more than 7 years ago | (#16930716)

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..
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>