Web Development

AJAX should not mandate HTTP

AJAX applications rely upon the existence of an application server always being available, and many Web developers are assuming that the user will not want to save the Web page or lose network connectivity. Hear why Justin James thinks this is a mistake.

An interesting and unfortunate by-product of AJAX applications is that these applications rely upon the existence of an application server always being available. Many Web users are used to the idea that they can save a Web page to be read at their convenience. Even when there is Flash on the page, the page still works offline. After all, HTML is simply a document storage format, and HTTP is simply a protocol designed to optimally transmit HTML documents. But, in reality, more and more Web developers are assuming that the user will not want to save the Web page or lose network connectivity. I think that this is a mistake.

A lot of frameworks have come out recently that are designed to tackle the offline problem; the frameworks' approach is usually to run a database on the client. The database can cache data from the "home server," and if the user makes changes while offline, that database can write the changes back to the "home server" when it becomes available again. These frameworks don't do anything about all of the back and forth requests to the app server that AJAX applications generate.

Some developers try to tackle this problem by loading a miniature application server on the client via Java (or similar "applet" style technologies). This approach works. However, after a certain point, I wonder how many hoops someone needs to jump through to compensate for an inherent shortcoming of a particular technique before it becomes clear that a technique might not meet their needs.

Even assuming that you can put a miniature application server and database server on the client that can cache and sync with the master servers whenever possible, you still have not solved the problem of "saving a Web page." The user doesn't think they are using an "application"; if it runs in a Web browser, they treat it like a Web page. Users are always clicking the Back button (which messes up AJAX apps) because they expect it to work like the Undo button. And incidentally, it does work like the Undo button in a more traditional step-by-step forms-based application. Ironically, one of the biggest issues that AJAX addresses in traditional Web development is the stateless nature of the HTTP protocol -- and yet it suffers from its own lack of state.

Let's take a "product finder" application as an example. In the application, the user selects various options as "must have" and "nice to have" features. Some of these are Boolean selections, while others might be numeric ranges, and one or two might be "one-of-many" or "many-of-many" options. Now, let's imagine that our user has narrowed her choices down to four products from the original 50. She decided to save the Web page to disk so she can e-mail it to her boss or coworkers for review. Whoops! Her boss and coworkers will likely have a problem if they try to bookmark the page or e-mail the link. In a traditional Web application, if the developer is smart, he or she will use GET rather than POST for these scenarios to ensure that the link accurately represents the application's state, and the page is quite easily saved in its current state.

I am not saying that AJAX applications cannot function like this; however, until users get used to the idea that the traditional model no longer applies, developers will want to find smart and creative ways of addressing this issue. One way of doing this would be to periodically "tag" the state with a hash code and redirect the browser to a URL that calls that hash code (for example, http://www.site.com/application/j7qw132j). This way, if the user hits the Back button, she goes back, say, two minutes in time (or 10 operations) rather than back to the beginning. Also, the user can e-mail (or bookmark) that link. Developers often build in E-mail This Page, Bookmark This Page, or even Save This Page buttons on their site, but it takes effort to build in the buttons, and users often miss those buttons or assume that they do the same thing as the similarly labeled browser functions.

I think that developers who work hard can find some creative, workable, and usable solutions for this issue, and their users will appreciate it.

J.Ja

Disclosure of Justin's industry affiliations: Justin James has a working arrangement with Microsoft to write an article for MSDN Magazine.

Additional resources about AJAX on TechRepublic

About

Justin James is the Lead Architect for Conigent.

52 comments
kj_easy
kj_easy

Yes, as a user I really agree with the point made for allowing links to be forwarded to others and saving the page the user looks at in that moment. One good thing of windows, being the most common operating system is that things work the same way - ALWAYS (or almost, if a programmer does not screw up). No need to find out again and again and again how to copy some text from here to there, etc. The same is true for web browsers and web pages. As a user, I do NOT want to find out, how this great artwork I am looking at functions technically. I want to get results fast, and that means, by using the procedures I ALWAYS use, like saving a page or a link, and sending the link to another person (or the whole page). If this does not work, it drives me nuts, because it causes me needless suffering.

miguel.tronix
miguel.tronix

Yeah its real bugger how I can't make toast any more because with the toaster I got given you have to place the bread flat/horizontally in the tray. I've ALWAYS just dropped it in vertically and waited for it to pop up. Hate it when that happen eh?

Tony Hopkinson
Tony Hopkinson

frying pan. It just came in a box marked toaster and you weren't experienced enough in the kitchen to realise........

Tony Hopkinson
Tony Hopkinson

That's pretty much the argument. One school of thought sdays you'll learn that back isn't back and another says you shouldn't have to learn anysuch thing. JJ is in the latter camp as am I and a few others. We do seem to be a minority though, so keep shouting, there's a vague chance some more people might start listening.

alaniane
alaniane

whippersnapper I would have been in the first camp, but now that I've aged I see the wisdom of the second camp. When I switched cars a few years ago, they switched the horn from the center of the steering wheel to the side. The guy in front of me put his car in reverse and started backing up without looking and for the life of me I could not find the horn until after he hit me. To me the car was broken since its design got in the way. What younger ones forget is that when most users have come to expect a certain functionality and your app doesn't provide the expected funtionality, they're going to figure that your app is broken which means you just potentially lost your users. They're going to move to app that gives them the expected functionality.

Tony Hopkinson
Tony Hopkinson

I mean if someone suggested using the print button for Save as if there was no need to print that would be stoopid. So why isn't re-using back? I don't get it.

Elvis.Is.Alive
Elvis.Is.Alive

I'm not sure I agree with this argument, see: http://www.gmail.com It works as expected, and is near 100% ajax, allowing saving, back button, etc.

Justin James
Justin James

I agree, there are some applications that have overcome the difficulties. I can't speak to GMail directly, since I have never (and will probably never) used it. But I know that they are few and far between. If you look at the number of years that GMail has been around, combined with the thousands of man-hours that Google has put into it (directly and indirectly, through working on projects that developed useful tech), I think it fair to say that GMail is *not* representative of the typical project. Indeed, if a project needs to be as mature and have as many resources dedicated to it as GMail has had to reach that level of maturity, I think it is safe to say that the projects with tht level of fit & finish will be measured in the "thousands" on a global basis, and the number than any given individual encounters will be measures in the tens. Sad, isn't it? I know that Outlook Web Access is quite slick as well (it was an AJAX pioneer, after all, and was slick even in 2000), but I know that it would take me a year to write even a small portion of an application half as good (in terms of UI). J.Ja

michael.crocker
michael.crocker

Hi, I agree with Justin. People have gotten use to using web browsers and have specific expectations. If we use Web 2.0 Apps, Flash, or any or the other shiny new tools we should not expect the user to automatically understand that things are not the same old static page. This becomes even more problematic when the designer tries to make it "look" like a standard web page. Users will want to print, bookmark, hit the back button, and do all the other bad habits they have learned. Using techniques like "email this page" (which is just a tool to make it easier for Spammers) is just an attempt to ignore usability. If you create the Web 2.0 App that has a very different look, you design safety features into it to prevent bad things from happening, and you explicitly warn people about the bad things, then you have done all you can. Expecting everyone that uses your App (even if they do not know they are) to understand your design and change their behavior has rarely worked. If you get them early then you have a shot at the new folks. Mike

mattohare
mattohare

The article seems to out stating that as developers we need to handle the times when the http connection breaks, and the user can not save their work. I'm VERY keen to see this area explored more in future posts. Then again, maybe we went as far as we could with current technologies and workaround frameworks. *chuckle* Then came the issues of user comfort. I find this a very important issue that can take a lot of pages from the marketing realm. The marketing realm says you need to understand your market, or your product will not succeed. It's the same about applications. In fact, almost all applications are products. One nature of the web is the ability to share and collaborate. Google seems to have seen this from the off. Not only do the applications save regularly, they show changes to two users at the same time so naturally, I almost didn't see the marvel of it. Some other people posting here say that users should not expect the same functionality as the web page paradigm, and Justin rightly says that excludes some users that have old habits. (And even the youngest of us have habits that don't die easily, I'm sure.) But let's not forget the expectations that users have of their tools. If you build an AJAX application, learn from your [perspective] users what they will want to share. Travellers need to share itineraries with partners and colleagues, sometimes in different parts of the planet. Researchers need to manipulate data to explore ideas, sometimes in different places and time zones. Traditional web use allows for this. We should be open to these possibilities in our applications.

Justin James
Justin James

Matt - Yeah, it almost was two articles, that is why it has that weird transition right in the middle of it. It may have been better to split it into two articles, one discussing the offline issues, and one discussing the breaking of the user's expectations. But making weird oddball mistakes like this is how I learn and grow as a writer, too! Heck, look back at my early stuff, say, 2 years ago. I am almost embarassed by some of it, it is like this teenager angsty stuff (I *did* listen to a lot of KMFDM and Ministry during those days...) directed at the IT industry. :) Today, I try to be a lot more positive, although I am not there yet. J.Ja

LyleTaylor
LyleTaylor

In general, I agree with your philosophy that Web 2.0 apps using AJAX and similar to make a web app look and feel more like a traditional app is somewhat of a hack on top of HTTP and is a manifestation of people trying to make something that wasn't intended for the desired purpose work for what they want (square peg, round hole; the web browser's my hammer; etc.). That said, I think your comments here are a bit off. I agree that there are issues with web apps in browsers, because a browser was really designed for sequential _page_ access rather than dynamic HTML update, so there's a disconnect between the original design and function of the browser and how the app needs to be used in the browser, and that can cause problems with people used to the "old" way of doing things. However, a Web 2.0 app cannot really be considered a web page in the traditional sense, and so I don't think you can have the same expectations of a web app that you have of a static web page or web site. A web app is not the same as a traditional "web page" or "web site", and so even if users are used to being able to download and browse a web site offline, I don't think it's reasonable to expect or even try to support that ability in a web app. Similarly, despite the fact that you can bookmark a web page, I don't think that users should necessarily be able to bookmark a specific state in a web app. Rather, it makes more sense to allow the user to save their state somehow (like a shopping cart that stores your state for future reference on the server) and recall that state when they come back later. In short, despite my misgivings about the idea of trying to make a web app look and feel like a traditional app using AJAX and the like, I don't think we can try to apply our old expectations to the new technology despite the fact that it still happens in a regular web browser. That's unfortunate, and it can cause confusion, but it's a new beast and has new rules that people will eventually have to learn.

Tony Hopkinson
Tony Hopkinson

To the guy who's just clicked on the big blue e, what's teh difference between a web app and a web page. If they are both going to be accessed by the 'same' browser, then any difference should be completely transparent to the user. If this isn't / can't be the case then you should be clicking on a big blue w. Using abrowser to host a web app sets an expectation of function, the actuality is irrelevant.

seanferd
seanferd

That would be one way to do it. Even if the W loads the same web browser as the 'e', perhaps the toolbar, frame, etc., could have a different color applied, or perhaps this color could change automatically whenever a web app was loaded through a previously opened browser. If transparency is hard to do with folks who don't know the difference between a page and an app, perhaps a "take the tour" button, or otherwise explicit instructions, could be included in the display of the app, with the ability to "turn off" this information for the more experienced user. I personally have no idea whether that would be easier to code than an app that functions transparently, however.

seanferd
seanferd

but out there, it's a mad, mad, mad, mad world. ;)

Tony Hopkinson
Tony Hopkinson

Move the back and next buttons, make it look different, in fact don't call them back and next. As bad as it is for the user a lot of inexperienced developers fall into the trap of designing an application from the UI, now if you are thinking of your web app as a web page, it is going to be a tip, if you are really lucky it just won't work early on.

Justin James
Justin James

To a huge number of Web users, they aren't using a "page" or an "app", they are using Internet Explorer or Firefix (or whatever browser they use), and they treat it as a document within the browser application. Ironically enough, that maps perfectly onto the technical details as well. :) Now, though, the browser is being used more and more like a runtime environment, like Smalltalk. J.Ja

aardvark92
aardvark92

At my previous employer, they wrote an online auction for a client, with a twist. During the last 20 minutes the auction switched into an real-time "lightning round," which used AJAX to let everybody see as soon as a bid was placed. During the lightning round, all the rules changed, and with them the expected functionality changed. In that scenario there's no need to save the content, work offline, or see a previous state. The same is true, I think, for any web app that has a time limit -- online games, e.g. Sometimes there's no reason an app should have to save its state.

Tony Hopkinson
Tony Hopkinson

are essentially attempting to do stateful over HTTP. In fact by the definition of web app, your boss' example wasn't. It was an application on the web that use technology 'designed' to do web apps. AJAX is simply an attempt to cope with lack of state, if you don't have to then why use it?

Justin James
Justin James

Lyle - What you are talking about makes sense. The problem is, the user (particularly people who started using the Web before Web apps that were not sequential [shopping carts, forums] were widespread) does *not* often discern the difference. They don't know that they are using an AJAX app, so they try the "Back" button. For the next 5 - 10 years, most likely (remember, longterm DOS users were still trying to use the "Escape" button to back out of dialogs up until a few years ago), we will need to keep in mind that a huge portion of users were trained to use the "Back" button in a certain way, bookmarks, etc., and it will take time for their expectations to change, and for them to re-learn how to use the Web. You are right, that on a technical level it is not fair to have those expectations, but you're fighting user's expectations that have been build up over a *decade*. It takes a while to re-train and re-shape their expectations. J.Ja

dashifen
dashifen

I wonder if there isn't a bit of a digital divide here. I've had a major, AJAX-heavy online application running now for close to three years and performed usability testing on that application with the target audience: college students. Not a one has reached for the back button when presented with the application's interface. I've probably seen a couple hundred users move through the system with no (reported or observed) problems caused by conflicts between the browser's UI and the application's. Further, I've there have been no reports of connectivity problems and other such issues, although that could be due to constant saving of information on the server-side that no more than one form's worth of data could ever be lost due to network and/or client issues. While successful, I have no idea if these results would be generalizable to other (i.e., older) audiences. I suspect that people who aren't living a Web 2.0 lifestyle would run into problems described within this article but as time passes we'll see a better understand of the power of the web. And, as wireless penetration becomes even more ubiquitous, I tend to think that connectivity issues will also be come more and more rare.

blackfalconsoftware
blackfalconsoftware

The Internet was never designed for the way it is being used today. The original TCP\IP protocol was created for simple-messaging. Yet, we in the IT world have done a wonderful job of adding an incredible feature-set to this original creation while still relying on it. The issue is, the web is becoming way too complex for what it was designed to do and most web development projects add more than their share of "fluff" for the simple idea of usability. Now the author here promotes we should add more for the occasional down-time one may experience with a web-page. User flexibility was proven long ago to be an expensive myth propagated by managers and vendors who have nothing else to do but insist that the user has all the features they could ever possibly want. For that systems have increased substantially in maintenance overhead and cost to the companies that put them in. Though the distributed world of technology has created miraculous capabilities for processing data we have lost site of the fact that as professional developers one of our responsibilities is to understand the limitations of the technologies we promote. Adding capability simply for "ease of use" by the user has to be tempered for ease of maintenance and cost constraint by the IT organization as well.

blackfalconsoftware
blackfalconsoftware

I find all of the postings very interesting to my thread. I never expected to cause such a stir. However, I think some people have misinterpreted what I was trying to say. First, TCP\IP and the Internet were designed by DARPA as an adjunct communications system to the original ARPANET which was basically designed as a communications mechanism between disparate systems of which there were few points at the time. Its sole purpose at the initiation of these projects was to link up message points across the US that could maintain consistent communications and what many originally thought (including myself) implement a high resistance to nuclear catastrophe at a point in the network. "The top level goal for the DARPA Internet Architecture was to develop an effective technique for multiplexed utilization of existing interconnected networks." (see http://www.cs.princeton.edu/~jrex/teaching/spring2005/reading/clark88.pdf) Whatever the individual, who attended a lecture of one of the inventors' of this protocol heard about complex documents may have been the vision, but at the time it was limited to simple messaging. Nonetheless, there were plans (or hopes) to implement DOD procurement documents which tended to be rather complex but at this time they were still mostly text-based. Similraly, at the time DARPA still had little or no idea how to incorporate hyper-text algorithms on such a scale though the mathematics were designed in the 1940s. TCP\IP is also a highly insecure medium. And two of the original scientists who attended a lecture given by the CIO at TIAA-CREF in the early 1990s who annopunced plans to put major systems on the Internet did not get a positive reaction from them due to security weaknesses... So the story goes. So any idea that this protocol on the Internet was designed for complexity is sadly misinformed. It was designed for simplicity and for use with the technologies available. Further, the Internet at the time was a "closed loop" system with no plans to commercialize it so the creators already had built in security which the protocol did not require to have in addition. As far as being a "minimalist" is concerned, that is quite true. To be honest, I don't really care about the user getting a "feel good" sense about the systems they are working with. People who come into the corporate environments aren't being expected to have fun, they are expected to get the job done and simplistic but elegant interfaces can be designed to do just that without all of the bells and whistles that are being added into current systems. Much of that is for resume building, personal likes, and as I said before, "fluff". You can argue against this all you want but after close to 35 years in the field, half of it spent developing distributed systems while also maintaining the messes that other people created, you tend to get an aversion to complexity for the sake of the user's need to have "flexibility". Developers who promote such complexity have often never had to deal with its consequences or review the negative cost analysis attributed to it. Of course, there is the argument for "performance" requirements. That too is complete nonsense. Massively, available systems that run on such configurations as the Internet, if properly designed, are not done so with performance in mind but "concurrency". And with higher levels of concurrency you cannot obtain similar levels of performance. That is just simple logic. You can do a number of things to make responses acceptable but they have more to do with with hardware configurations than code development. For example, well designed concurrent systems can be easily scaled-out with the addition of more hradware to process the increasing number of requests. In fact that is about the only thing you can do. Much of what has been developed recently for interfaces is "eye candy" and adds very little to the task of completing a process at the user end. As a result, strategic system development has taken second place to tactical decision making processes which are often made outside of any strategic thinking. The results are well known...

Justin James
Justin James

"The Internet was never designed for the way it is being used today." Change the word "Internet" to "Web", and I agree wholeheartedly. All it takes is a few minutes with the HTML and HTTP specs to realize that they were designed specifically for remote document reading... which is exactly what TBL had in mind! Scientists needed an easy way to share documents. "The issue is, the web is becoming way too complex for what it was designed to do and most web development projects add more than their share of "fluff" for the simple idea of usability." This is where I disagree. Most of these things were NOT done with "usability" in mind! They were done with "feature set" (or maybe, "usefulness") in mind, but hardly "usability". Web apps are insanely unusable from the standpoint of usability theory, and they are also very bad (particularly AJAX apps) when it comes to accessibility. "User flexibility was proven long ago to be an expensive myth propagated by managers and vendors who have nothing else to do but insist that the user has all the features they could ever possibly want. For that systems have increased substantially in maintenance overhead and cost to the companies that put them in." I agree as well. What has happened is that developers are trying to shoehorn the full feature set of a desktop app into a framework designed to be a remote file system access protocol (HTTP) with a lightweight document format (HTML). But if you are going to go for the desktop-like experience, you need to go whole hog and get a truly desktop-like experience. At the same time, you can't break the existing paradigms that users are used to (like back buttons). And this is the difference between "usability" and "usefullness". It is very difficult to built an app (Web, desktop, or whatever) that has a huge feature set *and* is useful. Look at Word. Huge feature set, lousy usability (although Word 2007 improved it a lot). J.Ja

Elvis.Is.Alive
Elvis.Is.Alive

I understand your primary concern now. I agree that HTTP isn't the *best* protocol out there, in fact, for as many years as I've worked with http applications, I understand the frustration of trying to get everything to work right. But, unfortunately, we are kind of stuck with http and AJAX for the moment (or possibly next few years) until something else better comes along. Come to think of it, I remember the early days of writing Java "Applets" for webpages, and I seem to remember being able to open statefull connections through Applets... Correct me if I'm wrong tho. Maybe Flash and Silverlight frameworks would be a good area to target evangelizing about stateful connections. If we could get either or both of those frameworks to support opening connections with state, we developers would be able to latch on and leverage that power. Justin, if you keep fighting, this concern will eventually get addressed. Thanks for being a good sport and thanks for some very good disucssions.

Justin James
Justin James

Yeah, this is something I write about a few weeks ago, this idea that the presentation layers of our apps are getting very standardized around HTML and RIA technologies, and that over the next few years, most developers won't be targeting "Windows Forms" or "X Windows" or "GNOME" or whatever for their display, they will target XAML/WPF/Silverlight, Flash, HTML, etc. The system that the user is sitting at is becoming less important and more separated from the server. Even in the client/server days, a lot of times there was not an app server with real logic stored there, it was just a database and the client software knew which procedures and queries to call. It's a shifting world, that's for sure! J.Ja

Tony Hopkinson
Tony Hopkinson

Well not while the boys with a serious vested interest in the way it works now can plaster over the flaws in the current infrastructure instead on a risking a large amount of money on something new. I like web apps, it's a tech I've used to simplify things, to give a better ROI, to make things actually work better. All the arguments for going to a wholly 'web app' environment are argued from the benefit of providers, not consumers. Even the ones that come out with that bollocks about needing less hardware and not having to buy MS office. If I decide AJAX is a suitable technology for implementing a solution I'll use it quite happily. I'm not in the habit of going round saying "What can I use AJAX for this week" though. That mentality is the one that gives us access enterprise solutions and people who struggle with their excel database, I want no part of it.

Justin James
Justin James

Sorry, but the Viagra comparison just could not go ignored! :) I do agree wholeheartedly that for an application developer, working with AJAX is easier than trying to squeeze networking into a desktop app. With one provision: *if* you are using a pre-built AJAX library. The simple fact is, AJAX is so bloody difficult to do well, cross platform, error free, and smoothly, that until libraries like script.aculo.us came around, the only AJAX apps out there were ones that took thousands of man hours to get nailed down, like Outlook Web Access, GMail, etc. Meanwhile, HTTP is only easier than, say, telnet, because every language came out with an HTTP component and tools based around it really quickly. If, for example, .Net, J2EE, PHP, and Perl shipped with a hook that let you open a port on startup, and treat that port like STDIN/STDOUT (or tie System.Console to it) and it took 3 lines of code to use this correctly, providing developers with a seamless way of enabling stateful, connection-ed communication, and this happened around 1996 or so, I bet you wouldn't see every app under the sun using HTTP. The biggest side benefit of HTTP (and beleive me, there are few) is simply the support. Every language ships with components that make it stupid simple to use. Every network has port 80 wide open. What has happened is that everyone is using port 80, not because HTTP is in use, or when they do use HTTP, not because it is a good protocol, but because they know they can get through the firewall. That's it. Sad, that the security guys created a situation in which programmers were forced to use the wrong protocol for many tasks (IM'ing with HTTP? C'mon!). AJAX is no more (and no less) of a kludge than using HTTP for everything. It's just that AJAX libraries came out before good "connection-ed, stateful protocol over HTTP" toolkits became readily available for free. :) J.Ja

Elvis.Is.Alive
Elvis.Is.Alive

I didn't mean to imply that there is any such "standardized browser interface" (GUI), but there is a standardized "platform". Basically, I mean that even though there are various flavors of browsers (IE, Firefox, Safari, Opera, etc), they all basically provide the same function: protocol based (mostly http) information retrieval and display. This platform includes the DOM, ECMA, HTTP, XMLHttpRequest, etc., etc. from which us developers can build on. Now, I'm not saying that these different "flavors" are completely standardized (I've been programming web-apps for long enough to know what kind of havoc the various nuances between them can cause for us developers), but for the most part there are some pretty good standards out there, and many/most of the browsers are working toward embracing those standards. Sure, another better technology can come along and make the AJAX revolution disappear overnight, and that would be GREAT, but for now I'm going to continue working with what the World has given me.

Tony Hopkinson
Tony Hopkinson

No maybe, it was, it is, it will be. Because http is stateless (and should be) in order to add state, we essentially send documents describing the state of the document, intercept them in the browser and dynamically modify them according to it's and their content. All Ajax is, is a way of partitioning the entire document to try and encapsulate some of the logic allowing optimisation of a both chatty and verbose mechanism. It's a work around, a bodge, a kludge, a short term fix for a serious design error. As for the standardised browser interface, you owe me some screen wipes.

Elvis.Is.Alive
Elvis.Is.Alive

I agree that developers are shoehorning feature sets of a desktop style application into the browser. Why wouldn't we??? That is the closest thing to a "common platform" that we have. If an end-user is already almost GUARANTEED to have an internet browser and ECMA script and XMLHttpRequest method, then this makes this platform ideal for developing an internet capable application and have the highest possible degree of adoption among users. Sure, I could go out and develop a C++ based application, and make it internet aware by importing all kinds of TCP/IP features, and then write both host and client software to achieve the same goal, but then I have all the problems from last century of trying to make the application compatible with all of the possible end-user platforms (Windows, Linux, Mac, etc.), PLUS I have to distribute that application and force users to install it on their system.... hmmmmm... I like AJAX instead. Maybe the Web (specifically speaking the HTTP protocol) was originally designed to do a sort of "document sharing" scenario that you described earlier, and those benefits of the Web were a boon to development of many, many features of the World Wide Web. But I don't see why that precludes us developers from taking advantage of the side-benefits of this protocol to enrich the experience of more people? I mean Viagra was originally developed to help heart patients, but after people started noticing the 'side-effects', those side-benefits turned out to be (arguably) just as beneficial to other parts of the anatomy as the original benefits to the heart... :)

dallascaley
dallascaley

if "User Flexibility" is an expensive "Myth" then why are more and more people using the internet as more and more flexibility is introduced? Are you suggesting that just because this type of interaction was not thought of when the internet was designed that we should just sit back and be happy with what we've been given? Yes its gonna be more difficult, yes maintenance costs are going to go up, thank god for job security.

miguel.tronix
miguel.tronix

But what of web server/memory backed SQL stores that do very simple and quick content changes, hopefully through some sort of controller mechanism (which is hidden from us be web browser's implementation). Now is it so bad? I entirely agree we don't need more security risks and half-baked or over cumbersome technologies to throw at HTTP/HTML, but at the same time I plan on designing web apps for some time to come - and where a technology is appropriate and whose leverage allows me to get the solution design more succintly/efficiently described and implemented - then I'm all for it. Better still if its guided by a standard. As always, Horses for Courses. I appreciate the discussions I come accross in this forum because I think you guys are genuinely aiming at solving/highlighting problems we all face. And being geeks, we each have our favourite corner to stand from - I think this web thingy has a very long long way to run, and funnily enough, for me at least, it will be *us* who are going to precipitate/wrestle with this change. Again, thank you all for your input

Tony Hopkinson
Tony Hopkinson

and it's a fundamental. If you want to show the the result of a query on a web page, you can. There is no good reason at all for putting the query in the web page. HTML is screwed up enough without breaking it even more

miguel.tronix
miguel.tronix

UI languages. http://www.w3.org/html/wg/html5/#relationship1 Why would you say they got jealous of SL/Flash ? HTML, and like most ppl here I've been using HTML since the Mosiac browser, HTML HAS NO COMPETITORS. NONE. NOT A SINGLE ONE!!! If it were not for HTML there would be no Flash no Silverlight, if it had been for MSFT there would be no HTML. What is so wrong about us(the community through out the world) wanting to get together and STANDERDISE the way we do some of this stuff? We're lucky we haven't ended up with OOHTML yet. There is nothing wrong with voicing ones opinions and working with others to change the direction, for the better, of something you think is wrong. That is commendable. But mixing that up with calling for strawmen just to retard the process (I mean really, shelling into servers evertime you want to do something, as opposed to cntr+tab...). Besides, what the hell is the difference between an HTML element calling a DB and a stub or User Control doing the same thing? User controls can't be exploited??

Tony Hopkinson
Tony Hopkinson

You just know some poor newbie is going too do select * from Table and iterate through it in javascript, on 48 different pages and then want to change their schema. Don't even start me on how much implementaion detail it exposes to the scripts kiddies. Please tell me they aren't putting the connection in there.

Justin James
Justin James

I would argue that there is no need for a new protocol, there are plenty of existing ones out there which fill the bill just fine. Why can't the Web page open an SSH channel for communications? Or use something like X Window or Terminal Services to do this? Right now, I am a member of the W3C working group on HTML 5. I can tell you this, from what I have seen. Not only is there no plan for a protocol or system like this, but they are effectively trying to bake in some of the worst practices imaginable! HTML 5 in the draft supports Web pages that can directly call SQL databases; that's just one example of some really bad ideas in there. Right now, I am trying to figut against this stuff, tooth and nail, but I feel like someone get jealous of Silverlight, Flash, etc. and decided that HTML needed to compete with those system. Ugh. J.Ja

Elvis.Is.Alive
Elvis.Is.Alive

I would adopt a new protocol that was built from the ground up. But, the problem is that it would take many, many years to build a completely new stack and have any kind of adoption to compete with the current protocol. I'm not saying it isn't a good idea (it is a very good idea), its just that the world of business demands that we produce something now with what we have (much like you mentioned). Now, that being said, are there any plans in W3C for a new protocol? Anywhere else? If not, then someone should start now, because it is going to take a long time and a LOT of capital from some pretty big players (think: Microsoft, Sun, Cisco, Linux (community), etc) to get any kind of traction on something of this magnitude.

alaniane
alaniane

and be happy with what we've been given; however, we also shouldn't be continually trying to hack around the limitations of TCP/IP and HTTP. It's time to take a look at how we can implement better transport protocols. To put it this way, you don't just keep tacking on stories on top of an existing building until the whole thing crumbles into a pile of dust. If you want to build a taller building, you tear the existing one down and re-lay the foundation for the new one. TCP/IP have been insecure from the beginning, so we just tacked on a security layer. HTTP is stateless, so then we try to hack around that limitation by imitating state in are applications. Why not create new base protocols to handle the current web applications?

Tony Hopkinson
Tony Hopkinson

well the smplicity offsets the implementation difficulties in trying to duplicate a stateful environment. But as you stated the user wants rich traditional ClientSide GUI functionality as a web app. Well that's what's touted, personally I have my doubts. The closer you try to get to rich gui, the more complex it gets, the deficiences at teh very least froma design point of vioew become more and motre apparent. AJAX isn't a bodge, but it will never fix the problem it was designed to address, that problem is stateful HTTP, which is an oxymoron.

Hendry_Betts
Hendry_Betts

First off, I take exception to the beginning of this thread. Dr. Vint Cerf (one of the co-founders of the TCP/IP protocol) would most certainly disagree with your position that TCP/IP was created "for simple-messaging." I had the honor of hearing Dr. Cerf speak and if he had invisioned this protocol as a SMS then he I doubt seriously that he would have thrown his whole life into something so trivial. I agree that the internet (as is any client/server system) does nothing more than transmit data from point a (server) to point b (client). But that is where your argument begins to lose traction. The WHOLE purpose of HTTP and HTML was the ability to transmit complex documents over the wire to share with remote locations (see DARPA-NET). The fact that _you_ are a minimalist is apparent in your post. But many more people want the same features and functionality that traditional desktop client/server or standalone applications provide. And, as computers become more powerful and memory cost is reduced to pennies per meg, this becomes possible. AJAX is often misunderstood. It is seen as some mystical UI thing. AJAX is the asynchronous transmission of data using the XML HTTP Reference (XHR) available to browsers since Javascript 1.2. All the fancy UI crap thrown in to "AJAX libraries" is just a rehash of old DHTML tricks that are standardized by the fact that ECMA script is no longer a Microsoft or Netscape product but a mature standard monitored by a larger governing body. Having gone through all of that, as developers (architects and engineers) it is incumbent upon us to provide our users with the tool set that will result in the highest level of adoption while easing the users pains of learning a new application. And if you don't believe that then I am sorry for you and I wish you well. You won't be here long. Just don't "throw the baby out with the bathwater" because AJAX is a very useful technology and can be supplemented with simple Browser tricks like Cookies for trackbacks saving information via a simple, inexpensive web service.

blackfalconsoftware
blackfalconsoftware

Obviously, you have not seen the technical messes created by energetic developers and managers who attempt to incorporate massive flexibility into their systems. And if you have not seen these nightmares than you haven't had the experience of attempting to maintain them either. I didn't say that user-interfaces shouldn't be usable. However, too much development is centered on how many ways a user can perform a single operation. That is "fluff"... and expensive "fluff" at that. Except for the fancy graphics and all the garbage you can stream over the wires, the Internet provides no more than what CICS did on the mainframes in terms of data manipulation. It can't, due to its stateless environment. If you can't develop a simple but elegant interface with a limited set of options than you are simply wasting money while increasing the costs to the company.

Justin James
Justin James

You are quite right about a "digital divide". It is not that younger users are more "Internet savvy" than older users (which is the traditional stereotype). But the older users got used to the Web browser working a particular way (the sequential Web document model), and learned to use their browser in line with that model. Web apps started to take off around 2000; I mark Outlook Web Access in 2000 as being the start of the modern AJAX era (I am sure there are earlier examples, just none that were as widespread at the time). By that regard, a current college student didn't start really using a computer until after that point. Meanwhile, tons of older folks have been using the Web since Netscape 2 or 3. And that's why you see the "Web 2.0 generation" using bookmarks, "Save to file", and the "Back" button less often, and they have been trained to discern between an "app" and "page". It's the same reason why people who learned to work with PCs in the DOS days were still trying to use the "Escape" button as a "help, I'm stuck!" button well into the Windows XP era. :) J.Ja

mattohare
mattohare

I've been giving a bit of thought to this lately. All of the local libraries have ?Silver Surfers? programmes. It made me really wonder how we got to this point. I was born in 1962 and raised during the 70s. It was the decade of the Jetsons. Left, right and centre, I was hearing about how we're going computerised in everything. In third grade, I was told that we would be able to dial our homes, press the # key, and turn on the oven so our roast would be ready. Notice the context I've given you for age here? I think it odd that the generations now that claim to have been around 'before' computers and can't be used to it are the very generations that were selling it to us in the 60s, 70s and 80s. (Those being the Baby Boom and the Silent generation before it.) Now, all of the sudden, they?re opposed to it, except for the significant minority that actually worked in the trades. Now, I understand how people in Northern Ireland might have missed some of the information age transitions of the past few decades. But, people of these generations seem to also have problems across Britain, Ireland, the United States and Canada.

Justin James
Justin James

So true... it's like the attitude was, "you guys are going to be doing it all with computers... good luck figuring it out!" I also recognize, though, the massive generation gap in other areas of technical knowledge. Whenever I see the wretched film "A Christmas Story", I am reminded that somewhere around my father's generation is when it was expected & acceptable to call a repairman to fix the furnace, instead of doing it yourself. Now, many home owners associations forbid fixing a car in your driveway; 50 years ago, it was quite normal for an accountant or a cashier or whomever to fix their own car. So my theory is that the older generations never saw the computer as being "mandatory" (they retired, or got close to it before computers were all pervasive in the business world), so they didn't bother. What is really fascinating is to watch TV shows or movies with scenes on offices in them... and to see how & where they use computers, based upon when it was made. When Law & Order first started to air, the police needed to go to a special department to have something looked up. Now, they do the search directly through their BlackBerries. :) It is hard for me to judge these things, though; my family has always been incredibly technical. My father has been a programmer since before I was born. My uncle is an EE who worked on the Voyager or Mariner space probes, and still burns his own EPROMs for his boat alarms that he designs & sells. My grand uncle produced documentaries for NBC for decades, and watched the revolutions in video editing; he had one of those first "luggables" so he could edit manuscripts on the road. My mother spent a lot of time around the legal industry and performing research, and learned to use word processors, scanners, etc. in the Wang era. So for me, I don't really have any of those typical "older technophobes" around in my life, but I have worked with quite a number of them. I am just grateful that the relatives are nice enough to not pepper me with "my computer is broken..." items when I visit. J.Ja

Justin James
Justin James

Are the Web pages you write useful and usable without an HTTP connection to a Web server? Or do they need that "always on" connection for AJAX or other widgets? How comfortable do you feel with that? J.Ja

Hendry_Betts
Hendry_Betts

AJAX without HTTP is nothing. Asychronous Javascript and XML... what would you have it use RPC? Maybe CORBA? How about sockets? Your point about web apps vs. web pages is well taken. But that is user education and design. Proper and thorough documentation and help files will help alleviate the "old timers'" issues with "My Back Button is Broken." But let me ask you this... in a traditional application, can you save state and transmit the information? Of COURSE You can. But how is that accomplished? RIGHT... Binary data is written to a file format and then transmitted to another computer that has the same application (or something that can read that pre-defined binary format) so that the other user can share that. Can we do something like that with a web application?? OF COURSE WE CAN (I say that with surety because I have). So a customer narrows down their top 10 choices of widgets and wants to share that with their boss... then the application designer should make a "Save" feature available -- or the ability to create a report. It's all data in the end. It's just about how you present it, interact with it, and make it available to other people. NO WEB PAGE is useful without HTTP... the foundation of the web (let's be sensible here). And AJAX would be useless without its underlying HTTP protocol as used by the XHR.

Justin James
Justin James

It's odd enough, because I would have much rather have seen a system similar to X Window (but without it's historical problems) become what Web apps are. Leave the Web to plain documents (or mostly plain documents... what I call a "dynamic Web site" as opposed to a "Web application"), and use a system suitable for application development. I know the history really well (I was there throughout it), but at the end of the day, the HTTP protocol is a lousy protocol for developers' needs all too often. They are squeezing state and frequent data transfers over a "connectionless, stateless protocol". Imagine if telnet needed to build up a session, re-authenticate, get the echo, and tear down the session with every key press; that's nearly precisely what a Web app over HTTP does. On top of that, the "sandboxed" security model that Web browser put around Web pages make it insanely difficult to do things that are trivial to do in a desktop app. If you look at the state-of-the-art of desktop apps, we are roughly where desktop apps were when VB 3 was released. Judging from the timelines, I think it will be about 10 - 15 years before we have the libraries, tools, and techniques to have a Web app where today's desktop apps are. To say that the issues are simply training and documentation... I have to disagree. Web apps are quite often made with the casual user in mind, the precise people who don't go to training or read documentation. I posit that any application, save for a few really advanced applcations with deep dfeature sets and users who need to use those feature sets (word processing for legal secretaries, where the formatting is crucial, Mathematica for scientics, IDEs for developers, Photoshop for graphic artists etc.), applciations should be self explanatory with no documentation needed to do day-to-day work. If an application runs inside another process, and does not follow the wrapper process' paradigms (like the "Back" button, etc.), you've written something that is broken. That being said... *plenty* of Web *pages* are useful without HTTP. Like all of the documentation I have for various things saved to my hard drive. Or documents that I drop off via FTP, or over Windows networking. HTTP is just one way of transmitting data. In fact, it could be (with an OS that lets you put an application in place that mimics a file system) quite possible to write a full blown application using the file:// handler instead of http:// (although I would hate it even more). Nowhere in the HTML spec is HTTP mandated, nor is there anywhere in the HTTP spec that says HTML must be its purpose. :) J.Ja

miguel.tronix
miguel.tronix

but that doesn't it can't be tried again until it is made successful. There were a number of problems with UDDI/WSDL but you certainly couldn't ask any service (google or otherwise) "web service geo spatial data analysis", you had to know what service you wanted. As for guaranteeing program integrity, well thats always the job of an engineer - talking to a web service doesn't absolve you of the responsibilities, you must still do rigorous analysis for suitability/feasibility. The point I raised on the desktop apps side (and it really shouldn't matter how old the app is, and yes there may at times be very good reasons why some things are restricted but it doesn't make it easy to use) is simplyt that they, too, are imperfect. So X-windows or citrix into the desktop as opposed to AJAX doesn't make the app any better. UDDI/WSDL may go through mutations (like CORBA before it) but these ideas once made workable will win, I believe. Because its a much more natural way to use software than downloading/installing something you only want when you actually run it (not sitting lying around in the registry) or remotely connecting into a "mainframe" type of system where everything you do is ipso-facto restricted. BTW, let me be very clear, I don't have anything against SQLEnterprise Manager (actually I still find it easier than Manager Studio or whatever 05 version is)/VS05-08/Protel I'm just making the point that if the funtionality of the browsers back button in AJAX apps is a pain, trust me there are many many many instances of traditional desktop apps that are similarly painful.

Justin James
Justin James

Miguel - Ironically, what you are asking for here have breen tried, and were miserable failures. "Interestingly I think if we had google for web services (search for what you to achieve and get back a list of services and associated APIs so you can choose which on to tap into yourself) it would really start to make Web Apps useful." It is called UDDI; Microsoft just shut down their public UDDI server due to lack of interest, and they had one of the most used ones out there. I don't even think that UDDI is turned on by default in Windows 2008. This was the original hype of Web services circa 2000 or so. My app would read an anonymous XSD from an anonymous service found via UDDI, magically extend itself to use that service... never came to pass, no one cared. Personally, I was not terribly against the idea, but it is hard for it to get traction. How do you guarantee that the backend logic, not just the front-end interface is equivalent and the services can be interchanged? How do you set up a seprate channel of comunications to handle billing? How does the code agree to be billed on its own? How do you comparison shop, when the code is picking the provider automatically? And so on and so on and so on. Regarding your thoughts on desktop apps. What you describe is not a problem cause by the inherent technical benefits and drawbacks of desktop apps. What you describe are some poorly written desktop apps. I guarantee that if a Web app had the level of functionality as, say, SQL Enterprise Manager (also, that app is EIGHT years old...), it would have some quirky or obnoxious behavior in a few spots too. After all, with literally thousands of points of interaction with the user, not all of them will be perfect. Likewise, the fact that VS05 can't open VS08 projects... I can think of DOZENS of reasons why that makes perfect sense to me, namely all of the programming constructs (.Net 3.5, WPF, etc.) that VS08 supports but VS05 doesn't. You should never expect document downgrade capability. J.Ja

miguel.tronix
miguel.tronix

Ok now I have to take exception. I AM NOT a big fan of desktop apps. In fact I largerly despise the things - unless they're doing really neat stuff like paralellizing large chunks of data procession routines and the like they are often as buggy as web apps (SQLServer Enterprise Manager doesn't let you expand the stupid little selector thingy so with large databases you can't actually read what your selecting - for instance) or are simply unfriendly (my PCB layout app won't share projects, VS05 can't open projects created in VS08, etc). Web Apps are the problem, its the intent that I perceive as the problem. And NO I DON'T WANT web apps to be web pages(i.e. static in any sense), if I did I could just have a REST site (not that REST isn't great for AJAX). Interestingly I think if we had google for web services (search for what you to achieve and get back a list of services and associated APIs so you can choose which on to tap into yourself) it would really start to make Web Apps useful. Heres why - instead of downloading code and merging it with your code any time you need functionality that either is outside your own speciality, or you don't have time to invest in rewritting the code, you could simply ask what web services are there that can perform this function for me. Then pawn off the work to that service, bring the result back into your own service, perform your own value adding work on it and push it back out. Then anyone could tap into your own service to get that extra zing you've created, to their own stuff on it and live happily ever after. And no, the services don't have to be free. In fact I suspect vanilla services would be free and finer grained/value added services would be charged for. Now that sort of a cloud could be really useful. IMHO ofcourse. Interesting topic as always though