Beta
×

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

Thank you!

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

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

An Ajax Reality Worth Worrying About

CowboyNeal posted more than 8 years ago | from the ajax-world-order dept.

79

An anonymous reader writes "This article discusses the hype that currently surrounds Ajax and it's shortcomings. Reliable Ajax frameworks are still under construction, and you should worry about navigation history, bookmarkability, feedback, persistence, concurrency, and security. This article will help you avoid the major problems inherent in Ajax development."

cancel ×

79 comments

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

Sessions (4, Insightful)

shawngarringer (906569) | more than 8 years ago | (#15313286)

One thing I wish more webmasters would use on sites with AJAX and other technologies is sessions. When I hit "Back" in my browser, I want it to actually go back... not crap out and dump me completely out.
I know... I know, I should be using whatever function is built into their website. But, I'm sorry, clicking Back or hitting backspace is just such a habit, its really a deal breaker for me...
I have no idea how much time I've wasted refilling in forms on my bank's website because it cant figure out what I'm doing when I press back!

Re:Sessions (1)

AuMatar (183847) | more than 8 years ago | (#15313321)

If you do online banking you really ought to check out Bank of America. I have an account there, and not only does back work, but it renders perfectly in Firefox (and for that matter, an old copy of Mozilla 1.0 I was forced to use). The interface for writing bills and scheduling payments is pretty nice too. My only complaint is that if you delete a contact with a payment scheduled to him, it deletes the payment as well as the default (that bit me when I wrote a final check to a utility when I moved then deleted the utility. They didn't get paid).

Re:Sessions (0, Offtopic)

shawngarringer (906569) | more than 8 years ago | (#15313374)

Thats an interesting idea. Today I belog to a credit union, they used to have many perks (not being charged for out-of-network ATMs, free checking, high interest rate on savings accounts, easy loans) but now they seem to be just another bank out to make a buck. I've owned and paid off 4 car loans to them (each car used but around $4000) and I applied for a home loan. My median credit score is around 690. We'll they won't touch me. Not only that, they actually told me they don't like people with questionable credit history as members...

I think I'll check out BoA next week... thanks.

Re:Sessions (1)

AuMatar (183847) | more than 8 years ago | (#15313397)

FOr the loan try Washington Mutual. My score is just a bit better, and I got a loan about 3 months ago.

Re:Sessions (1)

whimmel (189969) | more than 8 years ago | (#15317372)

690 is questionable? No wonder my (former) credit union was such a PITA. In my experience, BofA is a little picky too. Failing them, try Wachovia.

Re:Sessions (3, Interesting)

Dionysus (12737) | more than 8 years ago | (#15313451)

The BankofAmerica website even works with Konqueror.

Re:Sessions (0)

Anonymous Coward | more than 8 years ago | (#15316910)

> The BankofAmerica website even works with Konqueror.

Well, that's exactly how it should be. From my experience, Konqueror is a browser which strictly adheres to current standards and since switching about a year ago, I have yet to run into a website that does not work.
Occasionally you have to switch your browser identification via the 'Tools'-menu to fool those sites that check for hardcoded browser identification strings, but the site will still work.
Even GMail, which at first proclaims that it isn't compatible, is working fine.

Re:Sessions (1)

jonbryce (703250) | more than 8 years ago | (#15319804)

All the bank sites I use work in Konqueror. On of them (Natwest) requires user agent spoofing, either to a recent version of Safari, or Mozilla Firefox.

Re:Sessions (1)

Bloomy (714535) | more than 8 years ago | (#15313713)

Just make sure you block doubleclick.net in some way. The Bank of America site loads web bugs from doubleclick.net, even after you've logged in [spywareinfo.com] . I see them (adblocked) on the Accounts Overview page. It seems they were just doing this in the eastern US two years ago [google.com] , maybe they're doing it elsewhere now.

Re:Sessions (1)

FuzzyDaddy (584528) | more than 8 years ago | (#15313720)

I've also used the BofA site with Firefox for some time, and have had a good experience with it. One thing I have been wishing for (but having gotten around to trying to implement) is a way to download all my check images every month. I need them for tax stuff and insurance claims, but they only let you get at them for six months. After which they charge you several bucks for a copy, which I find annoying because I know it costs them nearly nothing to produce it!

Re:Sessions (1)

whimmel (189969) | more than 8 years ago | (#15317320)

Once they go offline they are probably stored in some sort of near-line storage (or worse, microfiche) that requires a human to retrieve and print. Then those have to be matched up with a cover letter and folded and stuffed into envelopes and presorted for the post office. Not quite "nearly nothing" to produce. They are probably losing money on check copies if not barely breaking even.

Blame HTTP Post (2, Informative)

Anonymous Coward | more than 8 years ago | (#15313358)

You can blame the HTTP Post mechanism for this. Do you want your confidential details appearing in a URL? No? Then you can't use GET, you have to use POST. And what does the POST spec [w3.org] say? Responses to this method are not cacheable. Not that this would work anyway; consider this, when you click back, is the old data still current? If you've just transferred money out of your account, then definitely not. The only way to ensure that customers don't see incorrect figures (which would draw too many complaints and possibly lawsuits) is to make the posts expire.

I'm sorry, but something better than HTTP/POST/HTML and a web browser is required to solve this problem. Perhaps some sort of interactive web site client which is designed from the ground up to support applications and not just static pages like was the original intent with web browsers.

Re:Blame HTTP Post (3, Informative)

heinousjay (683506) | more than 8 years ago | (#15313510)

You don't need anything other than HTTP to support applications that don't require a constant connection. The redirect-after-post [google.com] technique does what you're looking for. It allows the browser view to always reflect model state, which is (or should be) the end goal.

Re:Blame HTTP Post (0)

Anonymous Coward | more than 8 years ago | (#15313533)

raw http header() location should do the trick for you in php.. other server side languages have simliar mechanizms for this..

Re:Blame HTTP Post (1)

ultranova (717540) | more than 8 years ago | (#15316000)

You don't need anything other than HTTP to support applications that don't require a constant connection. The redirect-after-post technique does what you're looking for. It allows the browser view to always reflect model state, which is (or should be) the end goal.

The interesting thing is that I, a total amateur, figured this out on my own when making my image gallery application, so how can any paid-for professional justify not realizing it ?

Simply have each POST operation redirect to the same page as the final step of processing the request. The browser will use the default (GET) method, which is cachable, so you don't get any nasty surprises from either reload or back button (but you should still not trust this behavior, since it's completely possible that a malicious hacker will resend the same POST request, it's just for the convenience of regular user).

Re:Sessions (1)

fossa (212602) | more than 8 years ago | (#15313385)

I know... I know, I should be using whatever [back] function is built into their website.

Don't excuse poor usability. Your browser already has a back button which as you say is often used reflexively. That's a good thing. Webpages that break your learned navigation skills are bad as they cause needless frustration and require uncecessary relearning. Sure, it's not a huge deal in the grand scheme of things, but add up a million tiny frustrations and before you know it you're tearing your hair out and getting less done.

Re:Sessions (1)

Fireflymantis (670938) | more than 8 years ago | (#15315727)

I would highly reccommend any one that even begins to contemplate using ajax in their web app to check out the Dojo Toolkit [dojotoolkit.org] and it's IO::Bind functionality. It transparently handles back/forward functionality and deals with bookmarkability quite well as long as you use it correctly. For small AJAX tricks like google suggest-esq autocomplete, this is a moot point, but if you are writing a serious web app that relies on asyncronous communication with the server, you need to deal with these issues.

AJAX will be dead before it launches. (-1)

Anonymous Coward | more than 8 years ago | (#15313389)

Vista will before too long support Avalon which was dropped in longhorn, so the real battle in rich web-based UIs will be Mozilla XUL vs Microsoft's-whatever-they-rebrand-Avalon-as.


Javascript+HTML has always been an ugly cludge; and every time IE is released you can be sure Google's AJAX will break just enough to get a few people to switch to MSN/Live.com


Ajax of the 2000s is Java of the 1990s.

New technologies (1)

RageLink (918351) | more than 8 years ago | (#15313421)

The problems that come with new frameworks, new technologies and mostly new trends usually lies amon the purpose for implementation. Using ajax just for the sake of using it is not the issue. Of course emerging technologies have their maturation process. Criticizing a technology usually helps in the development if the criticism has specific issues that must be resolved.

-My 2 cents.

Maybe it's just me... (1)

drinkypoo (153816) | more than 8 years ago | (#15313446)

...but I can't take anything from IBM on web design seriously when their article renders in a tiny little font. If that wasn't enough, they actually go to the trouble to create and apparently use acronyms for "Tipping Point" and "Paradigm Shift". Great, now we get acronyms for buzzwords in a technical article? They're specifying font sizes in pixels, too. Shame on them.

Re:Maybe it's just me... (1)

the eric conspiracy (20178) | more than 8 years ago | (#15313664)

Font size is the easiest thing there is for the end user to adjust to their preference if the page is designed correctly. My eyes are not at all good, but a couple of taps on ctrl+ made this page quite easy to view.

What REALLY ticks me off about working with some designers is when they want to place text on a page in the form of images so they can force the user to look at the design exactly the way they want it shown.

Re:Maybe it's just me... (1)

drinkypoo (153816) | more than 8 years ago | (#15313834)

Well, it makes some degree of sense since there is no means for sending font data to browsers. You can use sIFR but I'm not sure how it handles resizing, I haven't tried. I suppose you could also use a SVG graphic whose size is specified in ems, but that will only work in firefox 1.5+, or for people who have an SVG plugin. This does seem like it makes the most sense, though. Flash sucks.

Re:Maybe it's just me... (1)

the eric conspiracy (20178) | more than 8 years ago | (#15313969)

Text as images has so many problems that there is no excuse for it. Anyone with any kind of disability has problems with it, the images are far slower to download, and making the text dynamic is nearly impossible.

The main culprit as far as I have seen is people working as web designers who started as print designers. They are used to having their design rendered exactly as they envisioned it, but that is not how html works so they try to force it to the detriment of all concrned.

quit blowing smoke (1)

subtropolis (748348) | more than 8 years ago | (#15323443)

Text as images has so many problems that there is no excuse for it.

If done badly, yes.

Anyone with any kind of disability has problems with it, ...

Are you aware of text image replacement [google.com] ? Those of us who use it understand well how to create sites accessible to people with disabilities [webstandards.org] . Your remark suggests otherwise.

...the images are far slower to download, ...

Thanks for the news flash. We'll take it into consideration.

...and making the text dynamic is nearly impossible.

No, it is not [alistapart.com] .

Re:quit blowing smoke (1)

the eric conspiracy (20178) | more than 8 years ago | (#15326744)

The articles that your search results point to generally contain warnings that text replacement techniques cause accessability problems. And as far as dynamic image creation, I dare you to try that on a server that is under any kind of significant load.

Give it up. Text as images is a WTF. [thedailywtf.com]

Re:quit blowing smoke (1)

cas2000 (148703) | more than 8 years ago | (#15327088)

>>Text as images has so many problems that there is no excuse for it.
>If done badly, yes.

it is *always* done badly. it is a bloody stupid practice, and there is no excuse for it.

text-as-images makes the incredibly stupid assumption that the viewer's display is the exact same size and resolution as the author's display - if the viewer has a large, high-resolution display (e.g. 21" at 1920x1440) then any textual images created at, say, 1024x768 (or, worse, 800x600) will be unreadable.

this is annoying enough even when it's only used for buttons (where you can eventually learn what the buttons do by trial-and-error and remembering them - e.g. tiny little button image-text is common on forum software. often with no alt= text), but it makes the page entirely useless when used for any content text.

Re:Maybe it's just me... (1)

eddeye (85134) | more than 8 years ago | (#15314336)

Font size is the easiest thing there is for the end user to adjust to their preference if the page is designed correctly. My eyes are not at all good, but a couple of taps on ctrl+ made this page quite easy to view.

Tapping ctrl+ gets old real quick, especially if you do a lot of page-hopping on a bad site. Fortunately Firefox/Mozilla users can enforce a minimum font size through either the font preferences panel (fails on a lot of sites) or a personalized userContent.css. If you wanna go the extra mile like me, you'll setup a web proxy to blast all reduced font sizes before they even reach your browser.

If you ask me font face and size properties should never have been added to the html/css specs. Developers have no business touching my fonts unless they know everything about my monitor (type, size, resolution, viewing distance) and my eyesight. Hint: that would be never.

Re:Maybe it's just me... (1)

NickFitz (5849) | more than 8 years ago | (#15316224)

Font size is the easiest thing there is for the end user to adjust to their preference if the page is designed correctly.

I think the point being made by the post to which you are replying was that because the font size is specified in pixels, the text can't be resized by anybody using Internet Explorer for Windows, up to and including version 6. As you say, the page needs to be designed correctly, and specifying font sizes in pixels is wrong for as long as the dominant browser has this misfeature.

IE7 goes some way to curing this but of course MS, rather than just fixing the original problem, had to go for a totally over-engineered zooming mechanism which is now showing assorted issues in Beta testing. Maybe one of these days they'll learn that sometimes you don't need to make it better, you just need to make it work.

Thinking it through from first principles (1)

2901 (676028) | more than 8 years ago | (#15319860)

The issue is the credibility of a page on the topic of website design. It is easy enough to say that a web page is a bit like an ink on paper page and to translate print layout ideas to the web by analogy. So there is no need to read other persons vague analogies.

The reason for reading somebody else's views on website design is the hope that they might have attempted to do the hard stuff, responding to the web as something new and thinking the principles of layout through from first principles. An obvious first principle is that font sizes should be set at the browsers end of the link not the server. How else are you to cater for the varied needs of many different readers?

A writer on website design who fails this basic test cannot expect readers to go to the trouble of using ctrl+ to read his pathetic drivel.

Re:Thinking it through from first principles (1)

subtropolis (748348) | more than 8 years ago | (#15323457)

A writer on website design who fails this basic test cannot expect readers to go to the trouble of using ctrl+ to read his pathetic drivel.

The author's title at IBM is "Performance Engineering Team Lead". His bio mentions that he has worked on user interfaces in the past, but there is nothing to suggest that he is responsible for the www-128.ibm.com design.

Re:Maybe it's just me... (1)

johansalk (818687) | more than 8 years ago | (#15316234)

Indeed, TP and PS are very, very annoying.

Abbreviations are for saving paper (1)

2901 (676028) | more than 8 years ago | (#15319766)

Take a look at the medical journal The Lancet. Its paper version is mailed all over the world and the publishers economise on mail costs by using small type on thin, high quality paper. Obviously one uses abbreviations to avoid wasting paper and incurring avoidable transport costs.

What are abbreviations doing on web pages? Literate adults tend to recognise whole words or even whole phrases. Decoding the abbreviations slows us down. Sometimes we don't recognise the abbreviation, which brings us to a halt. Other times abbreviations clash. I frequently get slowed down by CVS. How did a mention of the Concurrent Version System get into my non-geek mailing list. Oh! It is the American pharmacy chain. There are not enough Three Letter Acronyms to go round.

Abbreviations are a total loss on webpages.

Just finished an AJAX shopping cart (0)

Anonymous Coward | more than 8 years ago | (#15313621)

Just finished implementing an ajax drag and drop shopping cart.

Check it out here: http://www.merchdirect.net [merchdirect.net]

Re:Just finished an AJAX shopping cart (0)

spongman (182339) | more than 8 years ago | (#15313793)

very nice.

Re:Just finished an AJAX shopping cart (1)

generic-man (33649) | more than 8 years ago | (#15313915)

Very spiffy! Have you seen Panic Goods [panic.com] ? Based on my experience there, I was expecting to drag things into and out of the cart just to get the Mac OS X-like puff-of-smoke animation. :)

Not many positive comments.. (0)

Anonymous Coward | more than 8 years ago | (#15313637)

Perhaps because real Ajax developers are getting stuff done and not wasting time on slashdot...

Ajax is not the problem (4, Insightful)

Umbral Blot (737704) | more than 8 years ago | (#15313933)

The real problem with Ajax isn't java script or browser fickleness, or Microsofts hatred of standards, it is that we are trying to solve one a problem, distributed applications over the internet, within the wrong framework, a document viewer with scripting capabilities. What we really need is an internet application browser, that is desgined to be able to host such applications, render consistantly over multiple platforms, be stable and secure, ect. Then users wouldn't be confused concerning the behavior of the back button for example, because no one expects applications to have a back. It might make sense to have the broweser be able to launch the application viewer when needed, but more than that is just begging for problems.

Re:Ajax is not the problem (0, Offtopic)

Seraphnote (655201) | more than 8 years ago | (#15314202)

Don't we already have that?

You know... that thing called "Flash Player"...

Re:Ajax is not the problem (0)

Anonymous Coward | more than 8 years ago | (#15314236)

I think the reason for the web's sucess over traditional "application" style usability is it's clean and simple approach to navigation: forward and back.

Re:Ajax is not the problem (1)

generic-man (33649) | more than 8 years ago | (#15314322)

Ten years ago, Java was so trendy that Netscape chose to name their scripting language JavaScript despite the fact that it had virtually nothing in common with Sun's language.

I find it deeply ironic that after Java failed to transform the face of computing into a network-centric model, so many dollars are being funneled into JavaScript development for applications intended to supplement or replace native ones.

Re:Ajax is not the problem (1)

MikeFM (12491) | more than 8 years ago | (#15314337)

I think applications should have back buttons. Being able to undo everything is a brilliant concept.

Re:Ajax is not the problem (1)

gdchinacat (186298) | more than 8 years ago | (#15326186)

I think you are confusing back and unod. If you POST data to a website, hitting the back botton does not undo that post. In fact, browsers even warn you when you go back to a POSTed page, saying that you might redo (rather than undo) the operation, which may cause problems.

Re:Ajax is not the problem (1)

MikeFM (12491) | more than 8 years ago | (#15328226)

True, but hitting back SHOULD undo anything that is possible. It'd be nice if it'd send some sort of special signal on back so that site's could undo. A built-in transaction model would be good too so that transactions could be started, rolled back, or committed in such a way that the whole task would group back and forward actions in a way that makes sense.

Is the web to the point where it needs to improve the back and forward model without completely tossing it? What about refresh and stop? It all seems it could be improved a lot while still keeping things easy.

Re:Ajax is not the problem (1)

gdchinacat (186298) | more than 8 years ago | (#15330010)

I not sure I agree with the statement that back SHOULD undo if possible. My concern is that this would essentially overload the back button to have two functions (navigation and application state). As a user, I would hate having to wonder if the site I'm browsing supports undo-on-back. However, as a user, I'd hate to have a new button to worry about.

As for improving the back/forward, refresh, and stop issues, I don't think they are broken enough to justify changing them. I don't think they could be made simpler (at least I haven't heard of any proposals for this). The current implementations are well known, and work well enough for the majority of users. The only thing I'd really like to see is a standard way for pages to disable the forward/back when appropriate, or to indicate that certain pages should not be added to the stack (such as pages that don't do anything but redirect you to the real page).

Re:Ajax is not the problem (1)

MikeFM (12491) | more than 8 years ago | (#15330743)

I think apps should have to make it clear if back is functioning as an undo. Maybe if they had to overload the back button the back button could change colors and offer an option to prompt for permission to undo? "Doing this will undo your last change. Are you sure you want to continue? [Yes], [No], [Go Back]" I think in applications that back as undo and forward as redo makes sense but you have to make clear to the user when they are in an application and when they are in a document. Back as undo is a common concept in many apps, such as wizards, already so if implemented well I don't think it'd be near as confussing to users as the current way things happen. An application transaction that can't be undone, such as sending an email, should be listed but make it clear that it's permanent. I'm seeing a handy little dropdown under the back button, if you click on the widget for it, that shows previous pages as it does now but in the case of an application shows a collapsable sub-list that shows the different actions you've taken with each of them with their own collapsable sub-list of steps. They could be greyed out for actions that can't be undone.

I think an easy back-forward model is one of the things that made the web as popular as it is and it can make applications easier to use too if handled correctly. It's an important enough issue to be worth some study and work to make it right.

Re:Ajax is not the problem (1)

Eli Gottlieb (917758) | more than 8 years ago | (#15314380)

Oh, you mean like NeWS [wikipedia.org] , which was actually designed for efficient and elegant distributed applications?

Nebekh it was never open-sourced.

Re:Ajax is not the problem (2, Insightful)

billcopc (196330) | more than 8 years ago | (#15314384)

Yes and no. It's true that asking a web browser to become an application client is a deadly blunder, but the underlying problem is that few sites today serve static content anymore. It's all about logins and forums and customization. Essentially we're going back to the 80's and 90's with BBS'es, where each sysop would painstakingly tweak and customize their server to offer a unique experience. Myself, I ran Maximus and I had pretty much rewritten every function using the MEX scripting language built into the BBS software, though I am known for being a masochistic code poet.

With Ajax, the corporate sites want to use it to extend their online service portfolio. The vanity sites want to use it for the coolness factor. I'm actually surprised it took this long for Ajax to catch on. I was doing funky tricks with Javascript years ago, specifically in 1998 for a spiffy navbar on my personal site, then a newer style in 2003 for thumbnail galleries a-la Flickr streams, browsing pictures quickly without reloading the static HTML template.

It's a fair bit of extra work getting all the browsers to play nice, but it's easier than inventing a standard for thin-client apps that will please everyone.

Re:Ajax is not the problem (2, Insightful)

uradu (10768) | more than 8 years ago | (#15314436)

You're absolutely right, but unfortunately the browser is the most widely distributed application delivery platform today. XUL might be nice and all, but it is supported on very few desktops. It's actually quite amazing how closely a modern web app can be scripted and styled to behave like a traditional application. As these web applications become more and more sophisticated they are increasingly outgrowing the traditional forms-based web paradigm, and features like the Back button can indeed become quite meaningless or even counter-intuitive. Sort of the like Back button in Windows Explorer, that you somehow instinctivly hit every once in a while but inevitably doesn't do what you want.

Should use Konqueror (1)

mangu (126918) | more than 8 years ago | (#15316239)

Sort of the like Back button in Windows Explorer, that you somehow instinctivly hit every once in a while but inevitably doesn't do what you want.


Funny, but I hit the back button in Konqueror all the time and it does exactly what I want, both when browsing the web or my local files.

Re:Ajax is not the problem (1)

fatrabbit (975194) | more than 8 years ago | (#15341620)

I think you are correct with your comment about the back button. People claim that AJAX will break the back button, but as already stated, the back button doesn't always work with the normal style of dynamic website we're all now familiar with.

We have that. It's called Java applets. (0, Offtopic)

Animats (122034) | more than 8 years ago | (#15315484)

That's exactly what Java applets do. If you want to run an application in the browser, that's the appropriate mechanism.

Re:We have that. It's called Java applets. (1)

Ash-Fox (726320) | more than 8 years ago | (#15316706)

> That's exactly what Java applets do. If you want to run an application in the browser, that's the appropriate mechanism.

Unless you're on a Mac (Apple's Java framework is terrible).

Re:We have that. It's called Java applets. (1)

2901 (676028) | more than 8 years ago | (#15320022)

Trouble with FreeBSD too. I installed Firefox painlessly using the package system, but it came without Java because of some licensing issue that I didn't understand. My response has been to ignore websites that depend on Java. It is not as though I have read all the non-Java websites on the web and now have spare time to piss about with Sun's license SNAFU :-)

Re:Ajax is not the problem (1)

ZombieRoboNinja (905329) | more than 8 years ago | (#15317221)

The whole advantage of AJAX is that it's available from pretty much any computer with internet access, due to the ubiquity of browser software. If I have to download a special "application browser" to run these apps, I might as well just download a real, compiled executable and get better speed out of it.

Re:Ajax is not the problem (1)

nwbvt (768631) | more than 8 years ago | (#15326816)

I think what the gp was saying wasn't that such a technology doesn't exist, but that there is not yet a standard "application browser" that is ubiquitous enough that it can be relied on.

Re:Ajax is not the problem (1)

blue.strider (737082) | more than 8 years ago | (#15318103)

--"no one expects applications to have a back"--

I suppose no one expects applications to have undo/redo either...

XULRunner (0)

Anonymous Coward | more than 8 years ago | (#15318261)

XULRunner is the answer.

Re:Ajax is not the problem (1)

SixDimensionalArray (604334) | more than 8 years ago | (#15319912)

Have you ever seen Rebol? Check out http://www.rebol.com/ [rebol.com] . I messed with it a bit in the past, and it kind of comes close to what you are talking about, although it has a very different programming syntax!

SixD

Re:Ajax is not the problem (1)

suv4x4 (956391) | more than 8 years ago | (#15330867)

What we really need is an internet application browser, that is desgined to be able to host such applications, render consistantly over multiple platforms, be stable and secure, ect.

Well you've just described the rewritten (with applications in mind) and improved Flash 9, coming in 3 months...

Even better, Adobe will release a free compiler and component framework for Flash 9, so the barrier of entry is $0.

...Unless you use a tool that already fixes these (1)

MikeyTheK (873329) | more than 8 years ago | (#15314494)

Morfik http://www.morfik.com/ [morfik.com] has already worked on these issues and deal with them so you don't have to lift a finger when you build your application. Atlas is (reportedly) going to (eventually) make all of these issues go away as well. Since Atlas isn't handling these issues yet I can't comment on how elegant it is, but Morfik is unbelievable. States are just handled. Bookmarks, back, forward, and reload buttons are no longer an issue. What's even cooler about Atlas and Morfik is that they are RAD IDE's with built-in everything that you need. Obviously Atlas is an all Microsoft tool, but Morfik integrates the more /.-friendly Apache and Firebird servers, which also means that in theory you shouldn't be burdened with a higher deployment cost. How they're going to handle patches to those products as new versions come out hasn't been determined, AFAIK.

Both make the transition to AJAX development even easier since the code-portion of your application is built in a high-level language you are already familiar with, whether or not you do web-development for a living already.

It's so cool to live in interesting times!

Re:...Unless you use a tool that already fixes the (0)

Anonymous Coward | more than 8 years ago | (#15315227)

Wow... The morfik home page doesn't render AT ALL in Safari... Great compatibility there!

Re:...Unless you use a tool that already fixes the (1)

MikeyTheK (873329) | more than 8 years ago | (#15316440)

I believe there is a compatibility issue in Safari. Of course it's also only in an EARLY beta. I don't remember about Opera.

Re:...Unless you use a tool that already fixes the (0)

Anonymous Coward | more than 8 years ago | (#15315682)

So... how's the astroturfing business?

Re:...Unless you use a tool that already fixes the (0)

Anonymous Coward | more than 8 years ago | (#15316017)

Can this be true - you can program in a high-level language like C# for the browser?!!! I have downloaded it and will let you know.

Re:...Unless you use a tool that already fixes the (2, Insightful)

NickFitz (5849) | more than 8 years ago | (#15316249)

Can this be true - you can program in a high-level language like C# for the browser?

Well, you can (with ASP.NET), but it's an awfully long-winded method for generating bloated HTML pages which don't work without JavaScript. Try Front Page, or save a Word doc as HTML; either is a much quicker way of generating shoddy code ;-)

Re:...Unless you use a tool that already fixes the (0)

Anonymous Coward | more than 8 years ago | (#15321719)

Okay half-day at it. The C# is a syntax implementation. Which is good enough for me. Also allows me to put projects together including a mix of other high-level languages - Java, Basic and Pascal. Now I wonder how Sun will look at this....having projects in Java for browser and server and no JVM.

Re:...Unless you use a tool that already fixes the (1)

darkheavy (78519) | more than 8 years ago | (#15316378)

It's so cool to live in interesting times!

Tell that to Rincewind.

Ajax on Web Analytics (1)

zhangyong (791280) | more than 8 years ago | (#15314653)

I have been always worried about Ajax' impacts on current web analytics software (e.g. AwStats, WebTrends, Google Analytics?, etc., almost all of them are page or logfile based). How will they be able to track Ajax applications if there is no new page loads, tags?

Re:Ajax on Web Analytics (1)

ELProphet (909179) | more than 8 years ago | (#15315613)

AJAX still uses page requests, albeit in a rather exotic way. If you have a peak in calls to `functions.js`, you know you have a bunch of people starting sessons; if you have a peak of hits to `dynamicRefresh.php`, you know you have a bunch of people using your application. It's not hard, it just takes a slight "PS" (paradigm shift, TFA).

Re:Ajax on Web Analytics (1)

MikeFM (12491) | more than 8 years ago | (#15315938)

Why not just get a new bit of analytic software? In years of using different packages I've yet to see one I liked anyway. I use my own and it analyzes a lot more than any of the off-the-shelf options I've seen. I want to know everything about the people at my sites.

Re:Ajax on Web Analytics (0)

Anonymous Coward | more than 8 years ago | (#15316445)

Fuck analytics. I use AdBlock with all of those services anyway.

ajaxblock (0)

Anonymous Coward | more than 8 years ago | (#15314676)

What I would really like to see is something like flashblock for ajax. It's that kind of popular, closed-source web design that makes so many pages load slowly and suffer from crippling design and compatibility issues. When people who aren't skilled in using the standard or the principles of web design, you end up with a crappy page with all the shiny new features like java and popups and frames. Well, those are not so common now thankfully, but they were at one point until people got tired of them. Now the major issues are things like websites only in flash and those that only really function with IE. All I can say is I'm waiting for an open standard that improves on these issues through commmunity scrutiny. It's unlikely to ever happen, but I'll keep crossing my fingers.

And as per normal, they forgot about security (1)

ajv (4061) | more than 8 years ago | (#15314768)

Ajax is wonderful, but it's not necessarily secure out of the box. I wrote about this back in February:

Ajax security presentation for OWASP
http://www.greebo.net/?page_id=329 [greebo.net]

Just because Ajax is being used should you abandon years of security knowledge.

Hop-on Lemmings! (1)

lon3st4r (973469) | more than 8 years ago | (#15315563)

"When we were young, we were told that 'Everybody else is doing it' was a really stupid reason to do something. Now it's the standard reason for picking a particular software package." -- Barry Gehm

I feel the same about AJAX! :) It may have improved the user interface and the browsing experience a lot, but AJAX pages eat up so much memory! Maybe its an issue with the browser implementation, but it does drag the system's responsiveness down. One should really think about it before one decides to go for AJAX.

I was working on developing a web interface for an embedded device. You just had to configure a few parameters; but people wanted AJAX!

goodbye accessibility (2, Insightful)

Eil (82413) | more than 8 years ago | (#15316829)

Allow me to play devil's advocate for a moment here...

Let's not also forget accessibility and backward compatibility. Neither of which you have if your site heavily relies on Ajax. Ajax is fun and all, but if you build a site or application that relies on Ajax (as so many do these days), you're completely leaving behind those with disability that prevents them from using a graphical browser and those who can't or won't use the latest versions of IE, Firefox, or Safari. (Let's at least be honest for a moment and admit that those are the only three browsers that Ajax authors ever attempt to target and even throwing Safari in there is a bit of a stretch.)

For awhile there, we were making good progress toward better adherence to web standards. Now it seems like "oooh shiny!" is rapidly taking over web design again.

Of course it's possible to build a site or application that is backwards compatible and accessible and thus uses Ajax only as a enhancement. But if the site works just fine without Ajax, why would you waste time implementing a few extra Ajax features just for show?

AJAX not always "just for show" (1)

BeanBunny (936648) | more than 8 years ago | (#15319248)

Of course it's possible to build a site or application that is backwards compatible and accessible and thus uses Ajax only as a enhancement. But if the site works just fine without Ajax, why would you waste time implementing a few extra Ajax features just for show?

Most of your comments are right on the money - if you are building a site that relies on AJAX, you are building incompatibility into the site (for now).

However, I must take exception with your last statement. Just because a site "works fine" without AJAX doesn't mean that it is a waste of time to add it. I developed a live search page recently that has users raving about how useful it is. This page was a static enter-your-criteria-and-hit-search page until recentl, which was fine, but it now allows you to return results while you are selecting criteria, which has an immense usability benefit when trying to sift through thousands of search results. Thus, it looks cool AND works great - not "just for show." Of course, the page still works "just fine" if the necessary AJAX components (Javascript, et al) are not present.

Overall, however, you are right. AJAX is simply another technology that should be used as it is appropriate as a solution to a problem rather than for its own sake.

Re:goodbye accessibility (1)

fatrabbit (975194) | more than 8 years ago | (#15341881)

There are people out there that are aware of the current pitfalls and limitations of AJAX, and use it in an appropriate way. My site worked fine without AJAX, albeit with the overhead of unnecessary page reloads and having to send and receive superfluous data with each request/response. Now I've used AJAX techniques in certain places to enhance the functionality and it works fine, not least of all the transactions to and from the server are now smaller and quicker and there is no need for a complete page refresh.

Stop the presses! (1, Funny)

Anonymous Coward | more than 8 years ago | (#15317626)

Reliable Ajax frameworks are still under construction, and you should worry about navigation history, bookmarkability, feedback, persistence, concurrency, and security.

Stop the presses! Someone has discovered that AJAX applications should follow the same usability guidelines that have been researched, reported, and [often to a lesser extent] used in all other applications.

Art of the State (1)

Doc Ruby (173196) | more than 8 years ago | (#15321393)

Those very relevant AJAX problems boil down to two: state management and security (including state integrity/privacy). So state management is the #1 priority for making AJAX apps work. Client-side cookies are about to finally gain the recognition they deserve for their necessity in handling those factors.
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

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

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

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

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