Slashdot Mirror
How Would You Usurp the Web Browser?
cyclomedia wonders: "I've been thinking about this for a while now, and a recent article posturing about Web 3.0 brought forward some other suggestions which basically boiled down to 'what should be next.' Everyone here knows that HTML, Javascript and HTTPRequest are not the tools for building feature-rich interactive networked applications, but that doesn't stop Google, Microsoft and others from trying their best to use them to build office suites and the like. As one project puts it: 'we need to replace the Document Browser with an Application Browser.' So, let's get the ball rolling with my question: What type of platform would you like to see delivering the 'true' Web 2.0 in the not too distant future?"
I think a better question would be: Why Would you Usurp the Web Browser?
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.
Taking out the "AJAX", HTTPRequest, Javascript, Flash, Java and advertisements would be a nice start.
Maybe not
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.)
In other words... what might succeed at doing exactly what Java and Flash promised to do, but have failed?
:)
I'm interested to find out that answer myself.
ClutterMe.com - easiest site creation on the Net. Just click and type.
applets, modified for fullscreen w/ an easier alternative to swing.
It would have to stateful and sandboxed. Run on any platform with a GUI. It probably wouldn't be the results of a standards committe as the committe would make a mess of it.
Clients would need to be able to bootstrap webapps automatically. The engine itself could be either embedded in the client or a thumb drive. The engine would just be a container to run the logic and render the content from the net.
putting the 'B' in LGBTQ+
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...
I do not fail; I succeed at finding out what does not work.
I can't tell you exactly what will replace current Internet UI technology, but I can say this, HTML, W3C, XML, CSS XHTML and on and on are simply the evolution to what will replace all that has gone before. Web 2.0 is simply an effort (no comment on value of the effort) to consolidate the things that make the Internet's UI more useful and exciting. Web 3.0 (and I hate the buzzwords because it always makes it seem like some person or group has more info or style than others when the buzzwords are used) and what lays beyond it are simply the morphing of what works, has worked, or seems like it will work into a common Internet UI experience.
There is no silver or magic bullet that will usurp web browsers, and its just silly to think that there will be, or could be. As an example, if the fully automatic hover car (think Jetsons) was to be invented tomorrow, it would not usurp the venerable internal combustion powered manually operated common day vehicle for a whole slew of reasons, not the least of which is cost, or cost of upgrading.
To ask such a question smacks of ploy or troll... though I find it not unreasonable to think there are those that ponder such questions as a matter of vocation.
Support NYCountryLawyer RIAA vs People
Do it violently and make sure you get the job done.
'nough said. ;-)
How about the JVM, seriously?
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
Better known as 318230.
The web browser isn't going anywhere anytime soon. Nor should it.
"You know why you do not see me styling wit my homies? Because I have no homies!!" -Mojo Jojo
Why would you usurp the web browser? Simple, to take it out of Microsoft's hands.
When our name is on the back of your car, we're behind you all the way!
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.
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.
So I think the solutions here would be: sack Javascript and replace it with something better, like an iteration of Python, and make the focus more on manipulating the DOM than verifying forms; move the user authentication parts from the documents themselves (PHP, etc.) and into the web page server; and make the network support better. It would be nice to have a web browser that supported, say, socket based connections. The negative side to that, of course, is now you have to support all those connections. But it could be useful for other purposes as well.
Basically, the next step will be to treat the browser simply as a large framework for GUIs.
Did you ever notice that *nix doesn't even cover Linux?
There are three parts to developing a GUI application; widget layout, widget behavior, and state persistence (view, controller, model if you want to think of it like that). Right now, people are dealing with HTML (or XHTML or XML), Javascript, and XML for those things.
What's better? Some people have come to like the flavor of XRC from the wx world, wxPython coming with a fairly decent GUI designer called XRCed that produces XRC as output. That handles widget layout. From there, you can use basically whatever language you want to handle behavior, and one can stick with XML or a database as persistent state.
There are already applications being used and developed right now using Python and wxPython that distribute XRC GUI components, Python behavior, with data all from a live database, transferred over XML-RPC. I haven't spent much time digging into the AJAX stuff, but from what I have seen, even pure wxPython is far nicer to read and write. With XRC handling layout and Python handling behavior, it would be difficult to find a significantly better "dynamic application platform".
Toss in the fact that you can actually embed XRC into HTML when using the wx browser, and one can write rich applications right into web pages, or even full on applications by themselves.
I don't think you can really overtake the web browser. It has too many functions. You can, however, make something that is better at one particular thing. And that's really where other attempts, such as Flash and Java, have failed: They tried to be too broad, and keep getting broader. If you try to do everything, you end up doing nothing well.
Choose one aspect of the browser, make something better that is simple and narrow, and see where it goes. The kind of applications written for the browser are small and data-driven. Perhaps streaming Tk between client and server would work.
I wonder if I use bold in my signature, people will notice my posts.
iTunes is already a specialized browser for music and video. It feeds the online music store to you using web technologies, but no browser can access the store directly.
I think if anything the future will look like these application shells wrapped around things that are almost, but not quite, web sites.
AJAX can only take you so far, at some point you need a deeper integration into the OS to make an application really compelling and useful within the context of the OS it runs within.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
AJAX, Java servlets, etc, are all dead-end technologies. They are the PHIGS and GKS of the web - nice in theory but not much more. Programming languages are simply too heavy for this kind of work. This is something that is simply not getting through to designers. You don't WANT a Turing-complete scripting language for a web browser, but you may very well want a large assembly of partial scripting languages that - when combined - are Turing-complete.
Overhead is the first problem. You don't want more than you absolutely need, for most cases, even if that means that in the corner cases of trying to do a lot, you end up using more resources than you would otherwise. Computing devices are getting bigger, overall, but are also getting smaller. Phones now support the web, and phones don't have the memory to run the sort of stuff people are using. PDAs could have the memory - if you don't want to use them for anything else, which rather eliminates their usefulness as a PDA.
Distributability is the second problem. Computers are now multi-threaded, multi-core, n-way SMP, clustered into Linus-knows-how-large a Beowulf cluster. But web pages are linear. You can't parallelize them, in the general case, and can't parallelize them well even in the better cases. Thus, browsers simply can't take advantage of the bulk of the CPU power available to them. You might as well hook up a paper tape reader to a SATA interface, whilst you're at it! If you can't benefit from the computing power, then all you're doing is burning energy and getting nothing back in the process.
CODECs need to be slashed. And dotted. Inefficient algorithms may work over broadband, but you can use a 40' truck to pick up the weekly groceries, too. Just because you CAN do something doesn't mean you should. Inefficient algorithms will create more traffic at a faster pace than Internet providers can provide more bandwidth. The service you get is not much better than you'd have had using quality code and a 56K modem. Efficient use of the resources available will allow for better quality content, not merely noisier content.
For goodness' sake, enable multicast and IPv6!!!!
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
"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.
Bigger Tubes.
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):
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.
The new trend: Closed-standard Xml Acquisition of Patents That seems to be catching on pretty well lately.
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.).
R ecipe/81549 for an example recipe that offers both client and servers, with comments including a threaded and forking server.
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/
Is it the future? Maybe. I like using it today. Makes my time more productive.
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?
No, no, you do NOT want yet another scheme for letting "content owners" run stuff on your machine. We have enough of those now: Java applets, Active-X controls, Macromedia Director programs, Microsoft's latest downloading DRM controls, etc.
Executable content has many downsides. First, all you can do is run it. It's really tough to do anything else with the content. Even resizing it for a device the content owner didn't intend can be tough. Try to reformat a PostScript file (PostScript is an executable language) for a small screen. Originally, repurposing HTML content was easy. With the mess we have today, it's tough to even archive it usefully.
Then there's the hostile code problem. This has essentially killed Active-X (which is hopeless), it's hurt Java applets (which were supposed to be secure, but weren't quite), and we're still having trouble keeping JavaScript in its cage. There are even Flash exploits.
Then there's the "Now everybody can do things their own way" problem. Every piece of content has its very own user interface, and usually not a very good one.
More fundamentally, executable content puts the content, not the user, in control. With declarative content, the user has control. With executable content, the content owner is in control, and can restrict the user as much as they want to. Which, as we know by now, will be as restrictive as they can get away with. You WILL watch the ad for twenty seconds before you get to the real page.
What we need is more descriptive power in HTML, so you don't need so much executable content. There are about ten things people do all the time with Javascript, and those should be supported with declarative code in HTML. We need more stuff like WebForms.
If you want the Web of the Future, try Second Life. Now that's a real "feature rich interactive networked application". It's a great toy, but a terrible way to deal with large quantities of information.
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).
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 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, 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.)
I think a better question would be: Why Would you Usurp the Web Browser?
I thought the summary alone made it pretty clear why you'd want something beyond a web browser. The web is (or at least, was designed as) a network of hypertexts. This would now properly be expanded to a network of hypermedia, but the point remains the same: it's function is to present documents, and link from one document to another. Text, images, sounds, movies, all that fits well enough into this model; even database output is basically nothing more than all of the above organized in a different way than a standard file system would do it, and databases can implement all variety of useful things like the web forum that we're chatting on without really breaking that model.
But when you start getting fancy complicated interactive applications crammed into that model, it gets ugly and breaks. Games, document editors, all that sort of stuff belongs in an *application* framework, not a document framework. And mind you, I find a lot of these networked applications very useful, but still, they don't belong in the Web; they belong in something else, an Application Browser to go along with your Document Browser. Though honestly, I'd just do away with the whole "browser" concept entirely and treat internet documents and applications the same as you would a doc or app on the other side of your LAN, which is not much different than you treat local docs and apps, besides permissions differences).
I guess this is my answer to the question in the summary, too. I'd take all applications out of the browser entirely and integrate the browser functions into something like, to use OSX examples, Finder and Preview; maybe merge the two together into one program, for browsing (local and remote) filesystems and viewing (local and remote) documents. Include a plugin architecture to allow extensibility of format support (and heck, if you allow editing of documents therein too, you're moving awfully close to a document-centric computing model, at last!).
Then standardize on a cross-platform API (Java is a possible candidate), and then when you click a link to a remote application (from your browser/finder/explorer thing), that app is quickly downloaded and cached on your end and run like any other local program, with the exception of different privileges and such. These programs might just call back to their home server for their data, in the case of something like a simple game, or they could allow you to read and write data from your local disks. The advantage of using a remote app in the latter case would of course be not having to worry about upgrading or anything - the only version that's available to use is the latest version. The disadvantage of course being if that app is unavailable, well, maybe you're stuck without the ability to open your data, even if it is stored locally. But open file formats could help there.
So, I guess that's my solution. Fat chance of it ever happening though.
-Forrest Cameranesi, Geek of all Trades
"I am Sam. Sam I am. I do not like trolls, flames, or spam."
For the future, look to the past!
Porn. And lots of it.
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.
-Forrest Cameranesi, Geek of all Trades
"I am Sam. Sam I am. I do not like trolls, flames, or spam."
"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.
I gotta gripe about this.
Don't get me wrong. I like functionality, I like a well-done AJAX site.
But stop me when you see the problem. What's being talked about is rewriting popular desktop apps to run inside a Web browser, in an environment where you have limited native GUI functionality, no toolkits to speak of, no access to the local filesystem (you know, where your stuff is), no window management, no native menus, network access is limited for security reasons but required because the local filesystem is off limits, all the GUI widgets invented in the last 35 years have to be written from scratch in languages and technologies that don't even work the same from browser to browser. What, was Office too fast on your machine? Being able to load and save your own files on your own hard drive was too convenient?
This was tried a decade ago, people were talking about the browser as an OS and all your apps would run in Java, same problems, you lost everything your native OS provided for you, added a few layers of Slow 'n Buggy, and didn't gain much except, oh, hell, I'm not sure what anyone would have gained except sticking it to Microsoft, and anyone who cared wasn't using Office in the first place. It seems to be the same thing now: surely there are better ways to stick it to Microsoft than writing productivity apps that are so constrained by the browser environment that Office looks good by comparison?
Get the right tool for the right job, folks. If you need groupware, write groupware, don't just assume the need for collaborative writing means that word processing fits nicely inside a Web page. If the point is to thumb nose at Microsoft, write better apps for your OSes of choice.
The legitimate purpose of AJAX is to bring interactivity to those things on a Web site that need it, not to move desktop apps into a smaller box.
To the original question: What's Next is probably already happening in the arena of standalone Javascript engines and Dashboard-like mini apps, that are reasonably lightweight, unobtrusive, and play nicely with the native GUI you're running. Sort of like each Web site you like and use everyday will have an applet or widget that "breaks off" and stays floating, on your desktop or on a Dashboard layer or whatever, to keep some kind of line of interactivity open with the Web site long after you've left it. Like RSS but more tailored to what that site naturally does: tickers, headlines, webcams, music, gamelets, whatever, and in the style of the site itself as visual cue.
~ radiographite: art by john shepard
http://ntw.sourceforge.net/
If you'll allow me to plug a pet project of mine, I think an asynchronous networked GUI widget toolkit is the wave of the future. The client (browser) is responsible for drawing widgets and sending events to the server, which handles callbacks. It's AJAX done right.
The biggest problem I have is explaining to people why this is so different from X, or display postscript, etc.
Imagine writing a GUI app that runs over the network without you having to do any network coding. Sort of like X, but without the tremendous speed penalty of having to maintain graphics on the server side.
Or imagine writing an app interactively over a network by typing a few simple Lisp commands. (not that this protocol is limited to Lisp only)
Imagine serving ten thousand GUI clients from a cheap machine, or saving the entire state of each client's session so they can log off and on again without losing any work. NTW does all of this.
Unfortunately, I got everything almost done, and have not had much time to see the project to fruition. It's frustrating too when most people don't quite "get" it.
If moderation could change anything, it would be illegal.
...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.)
This message brought to you by Jack Schitt's Previously Shat Shit
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.
XULRunner
It supports rich applications like Firefox and Thunderbird using XUL and XPCOM. Cross-platform (and unlike Microsoft's implementation of the term "cross-platform", it doesn't just mean several versions of Windows). It supports themes and plugins.
Why get rid of Web version x.x? The web is a hypermedia document service, get the applications out of it.
I like bricks.
I have freaks! I did something right...
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.
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.
``"we need to replace the Document Browser with an Application Browser."''
.NET will provide a solution, here. Time will tell.
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
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).
Please correct me if I got my facts wrong.
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)
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.
Money for nothing, pix for free
http://www.rebol.com/
A step in the right direction?
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.
First of all, let's all have a look at REBOL.
Secondly, what we need is a distributed and declarative programming language running in the 'web' browser. A web page should become a declarative description of a user interface, much like F3.
For example, if I wanted to make a simple login form, the code would be something along this:
In the above example, the UI is built in a declarative manner as a tree of objects, much like HTML. But there are no hardcoded tags: the final output is created by running the code in the page.
Furthermore, the calls to the server are part of the language specification: the language automatically knows how to call server functions, without any need to declare them somewhere.
Finally, the platform shall have lazy downloading, with classes downloaded when they are first instantiated.
Pages which do not have any logic and simply present information could then easily be built by using the declarative user-interface library.
Style mechanisms like CSS and resources would be data retrieved from external servers and applied to the UI.
If the page needs to do more things, for example to display a video, run a calculation, present a menu or a tree, run 3d graphics, etc it would be very easy: since the whole interface would be programmable, there would be no limitation.
The advantages over the current situation are:
(That's a quotation from the luddite character Theotocopulos in the H. G. Wells movie, Things to Come).
Not that it matter, but 99.734% of everyone using the Web is perfectly happy with the functionality that's available now.
What they want is for someone to make the current technology work. That is, make it work more reliably for the average user with an average three-year-old computer on an average-speed connection.
The only complaints I hear are problems with bugginess due in large part to a) failure to adhere to standards at server or client, and b) version skew between the set of browser-related stuff loaded on the particular user's machine and the site that's being visited.
I don't hear them in that form, however... what I hear is "for some reason I always crash on this site" or
Why is this page taking forever to load?" or "I can't seem to get this site to work properly."
Nobody but overly ambitious web-designers and corporate egotists want all the fancy flash crap that takes minutes to load... or the fancy Java applet crap, now thankfully rare, that takes minutes to load and then doesn't work because you have the wrong version of the JVM.
People just want to get in, read their news, do their shopping, not have the browser hang or crash or take a minute to load a page, not get their identity stolen, and not get interrupted by advertising popping up over, under, around, or through.
Everything being discussed here is just engineering ego ("I can do way better than Tim Berners-Lee") or corporate ego ("Isn't there some way you can make our website have a real shiny metallic reflection") or vendor lock-in ("This site does not support your browser. Please use Internet Explorer version 7. Click on the link to get it free. Of course it won't run on the version of Windows you're using... or the version of Mac OS you're using... but that's your problem. Go buy a new computer.")
None of it has to do with the real needs of actual web users.
"How to Do Nothing," kids activities, back in print!
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.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
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.
Which will be replaced in turn by mainframes.
I'm not kidding. Web 4.0 will be X12.
The masses are the crack whores of religion.
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..
every day http://en.wikipedia.org/wiki/Special:Random
The browser will not go away. It may expand to include more functionality, but it won't go away. People like "one stop shopping". It's called INTERNET Explorer for a reason.
s ources/dpw?
Hyper Text - http://slashdot.org/
Gopher - gopher://seanm.ca/
WAIS - wais://stardust.jpl.nasa.gov:210//home/wais/wais-
File transfer - ftp://ftp.wustl.edu/
Telnet - telnet://locis.loc.gov/
Multimedia Streams - mms:media1csuseduusrvideodemosamplewmv
etc.
The browser handles all of these activities in a single platform (either natively or through "handlers" - plug-ins if you will). Make a new protocol for applications if you want, the browser will likely be expanded to support the protocol (first via plug-ins, later natively). As a Web surfer, I don't want to have to know which program to run in order to accomplish my task (read docs, play games, use apps, etc.). I want to run one program (my browser) and have all of that "MAGIC" take place behind the scenes.
Layne
(P.S. Sorry if some of the links don't work, I'm at work and some of them are blocked. They were all copied from pages that purported them to be working example links.)
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.
Do not look at laser with remaining good eye.
There is already a solution for providing a "rich application experience" over a network. It is called the X Windows Protocol, and it allows a user to run an application on a remote machine and see the display on their local machine. Now that most people have high bandwidth connections to the internet, I think it is a better solution than the proliferation of JavaScript hacks and other workarounds that are used in an attempt to turn web browsers into application interfaces.
To use this technology, you do not need a new computer, you just need to download and install cygwin (www.cygwin.com) and make sure you select the X Windows components during the installation. Of course, the applications will have to run on a *nix box, because Micro$oft does not like people being able to run multiple copies of their software without paying. But there are still a lot of useful applications that run on *nix machines.
...it's called "X Windows".
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 about it, that's what we nee... Oh!? 1970 called? They want their VM-driven desktop systems back? But it talks XML now - slowness and non-readability - all in the same package. Oh, alright... But you better not screw it up again this time...
That is all.
"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."
Isn't that just it? The box..
The browser should not be a 'smaller box', it should be the -main- graphics engine of a computer. We should adopt a -declarative- graphics interface layer that acts as a binding context for independent components.
Many would say it is stupid to put a layer of text (although it could be compressed) between an 'application' and it's graphis, however, I would argue that this is a good separation. It forces us into a style of programming that separates programming interests. Declarative (xml style) markup for people who wish to compose content, and whatever procedural or functional language for rendering content.
The browser is just a container to hold this 'binding context' (read: traditional process), while potentially downloading the graphical component code to render tags that are not understood yet (mobile widgets). Namespaces and registries are powerful tools in our favor.
Declarative languages are powerful simply because they hide complexity. That is why HTML was a success: it was simple. Anyone can compose an HTML document becuase they only worry about what they care about, the rest is just taken care of. And if, at some time they want more control, access to the right properties should be available.
Markup tags are perfectly embedable too, so it is easy and natural to compose and contain content in any way imaginable. Take for example floating 'widgets' on your desktop.
There is another one.. The browser is not the desktop, but they both are responsible for graphics. To many users there is no conceptual separation. Why should there be? We don't need two. Since the 'browser' metaphore is more powerful, it should be adopted by the 'operating systems' as their means to display graphics. There is no reason it can't be as 'powerful' as a 'desktop' metaphore. Come on people, we are making this up as we go, are we not??
AJR
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 correct that technically speaking, it wouldn't be a real-time interactive application...but it'd be that close that your average end-user isn't going to know the difference.
REBOL is cool but it's not free software. So that's the end of the story for general use (as opposed to the vertical markets they seem to be going after). Lots of technologies wither away in vertical markets, unfortunately.
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-clicks and sending them back to the application, etc. And they happen to be really good at it. Web Browsers are NOT good at doing this. Two big problems: they don't allow convenient access to the full array of UI widgets that are needed for a client, and they communicate using a stateless protocol which hinders the interactivity between the remote app and the UI.
Solution? Use browsers for browsing and X for serving up UI's to remote applications. Use the right tool for the job, instead of trying to shoe-horn something into a role it's not meant for. I mean, can't you just picture the browser developer guys huddled around a square peg, hammering it into a round hole with a big-ass hammer, while one of them yells "hit it harder, hit it harder?"
// TODO: Insert Cool Sig
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 whole thing so that it gracefully enables a free-as-in-speech approach, rather than encouraging everybody to backslide into proprietary software at exactly the moment in history when the OSS community has finished creating a fairly complete stack of traditional apps.
A wish list:
Find free books.
It's already there!
: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.
If not Java - something exactly like Java
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.
The ability to represent 3D in some real time manner would be the next step. With Dual-Core 64 bit technology at our door step, the Internet Band Width is now the current choke point.
I think SVG and CSS3 (possibly even version 4) along with more AJAX/JavaScript/OpenLazlo/Flash/Flex are what Web 3.0 would be about.
Although unless the most popular browser (IE) supports SVG and CSS3 by default I dont see it happening.
I've seen some impressive things with SVG and JavaScript.
by that, i mean, you must have a way to do it (even if slower) using ajax, flash or java. just so people with browsers can still use. otherwise, it's as doomed as the 1.084.975.092.485.902.834[1] things already tried before.
[1] number take into account just last weeks.
However, it is not accurate. PHP, ASP, Zope, Cold Fusion, embedded Perl, CGI scripts in any language (including Java), Apache's amazing "SSI" scripts that are practically a language these days - these easily cover more than 50% of all server-side dynamic content. There is still a lot of static content as well, and "fat client" code (where an applet, embedded Tcl, embedded Shockwave/Flash or whatever does the dynamic stuff on the client end) is definitely hanging in there, as people realize that thin clients make no sense when each user has more computing power to spare than the largest server farms can dedicate to a given thread server-side.
For that matter, with the complexity of stored procedures (which even MySQL has added) and relational database "blades" (modules for handling specialized data types, mostly used in Informix databases), you don't really need sophisticated code on the web server - you just have something to translate URLs into SQL queries which pull up the necessary HTML code fragments.
But all of these techniques (with the exception of static content) have one thing in common - they are SLOOOOOW. If you don't want anything fancy, Gopher and WAIS would outstrip virtually any web-based information system out there. Even if you do want something fancy, why pay such gigantic overheads for so little gain? Why is the world settling for something that is technically superior but is implemented in such an inferior way that all gains are instantly neutralized?
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
and into 3D with a FOSS system that's a little like Second Life. And call it "cyberspace", of course.
no sig, no plan, no clue
I only posted a link to REBOL for reference...in my opinion, it is not production-ready yet, but it has good ideas, many of them solving the problems the question to /. asks.