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!

The Current State of Ajax

samzenpus posted more than 9 years ago | from the overview dept.

Programming 347

Dion Hinchcliffe writes "Ajax hasn't even been big a year yet and already open source development tools by the dozen are pouring out. Not to mention big names like TIBCO and Microsoft already have previews on the way of full-fledged IDEs for developing Ajax applications. Ajax may be the biggest software development story of 2005. Dion Hinchcliffe has a detailed article about how Ajax has evolved over the last six months and assesses the current state of tools, libraries, and mindshare. He also points out that Ajax will inadvertently end up being a driving force for Service-Oriented Architecture (SOA) for many organizations since it requires high performance back-end XML services."

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

Thin Clients, Fat Pockets (5, Interesting)

mfh (56) | more than 9 years ago | (#13358051)

Ajax will inadvertently end up being a driving force for Service-Oriented Architecture (SOA) for many organizations since it requires high performance back-end XML services.

I think we've been seeing this shift for a while now, since people went from fat client software towards more streamlined C/S replacements, due mostly to convenience and easier features, server updates etc. Plus you can't argue with the repeat revenue stream generated by services that you can offer your customer, as opposed to a single sale.

When did you move your email handling from a fat client to webmail? My first move was from Eudora to Outlook, then Outlook (yuk) to Pegasus (don't ask) and then to Hotmail and now Gmail. I don't think I'll move away from Gmail, but you never know.

Ajax unplugs you because you get the immediate, targeted response from the server that wasn't available before. So refreshing a whole page when I only need to see a small widget change is really what Ajax fixes. I look at Ajax as being only a bugfix to the intarweb and nothing else, really. Seriously, why do I want to refresh a whole template when I want to send only a little widget of text in the middle?

Frames were not the way to handle this kind of presentation/data separation, mostly because they could be indexed and that would confuse visitors coming to the center frame and not the whole display. Eventually many people just stopped using frames because they are clunky, and have strange display problems on varrious systems. Ajax remedies this problem, really. Hypothetically you could set up a site that had a bunch of frames that interacted independantly and achieve a similar result to Ajax, but who would want to have to handle the cross platform and cross browser problems that arrive when you rely on frames?

Ajax is definately going to push for more service oriented contracts and eventually I can see products dwindling or becoming wrapped into services and monthly subscriptions instead of out of the box solutions that are popular today.

I will bet that eventually we'll see some very thin looking clients in the near future, thanks to Ajax.

Re:Thin Clients, Fat Pockets (0)

Anonymous Coward | more than 9 years ago | (#13358102)

Nice comment. But still nicer Slashdot id, or did the new ids max out and wrap around to 0?

Re:Thin Clients, Fat Pockets (0)

Anonymous Coward | more than 9 years ago | (#13358130)

Let me get this straight. You typed up all that in 1 minute from when the article was posted???

The Current State of Ajax
Posted by samzenpus on Friday August 19, @04:42PM

Thin Clients, Fat Pockets (Score:2, Insightful)
by mfh (56) on Friday August 19, @04:43PM (#13358051)

Re:Thin Clients, Fat Pockets (1)

gregstumph (442817) | more than 9 years ago | (#13358216)

Let me get this straight. You typed up all that in 1 minute from when the article was posted???

See: the previous NTP story ;)

Re:Thin Clients, Fat Pockets (1)

bedroll (806612) | more than 9 years ago | (#13358167)

Frames also didn't solve all the problems. IFrames came much closer, but still no cigar. One of the problems is that sometimes you just need a round trip to the server to tell script to do something to the page, you can accomplish that with a hidden IFrame or Frame, but that's not really what they were designed for and it requires the browser to interpret the result and attempt to render a page. That slows everything down just enough to be noticable.

p.s. I used Pegasus as my primary mail client some 8-10 years ago. For that time it was pretty good, is it really that bad now that it gets a "don't ask"?

Re:Thin Clients, Fat Pockets (1)

AKAImBatman (238306) | more than 9 years ago | (#13358290)

One of the problems is that sometimes you just need a round trip to the server to tell script to do something to the page, you can accomplish that with a hidden IFrame or Frame, but that's not really what they were designed for and it requires the browser to interpret the result and attempt to render a page.

If you get an XML response in a hidden IFrame, it's just as good as the XMLHttpRequest. You can assign a listener to the IFrame so that you know when it's done loading. The listener can then walk the XML DOM for the information it needs to modify the HTML document.

Not sure if that's useful at all, but I figured I'd throw it out there. :-)

Re:Thin Clients, Fat Pockets (0)

AKAImBatman (238306) | more than 9 years ago | (#13358254)

I think you'll find that the idea behind AJAX has been 20 years in the making. [blogspot.com] It's about time it caught on! ;-)

Re:Thin Clients, Fat Pockets (3, Insightful)

C.Batt (715986) | more than 9 years ago | (#13358366)

Hypothetically you could set up a site that had a bunch of frames that interacted independantly and achieve a similar result to Ajax, but who would want to have to handle the cross platform and cross browser problems that arrive when you rely on frames?
I can speak as someone who has in fact done just that and would have killed for an XMLHttpRequest object back in 2001.

Today I'm architecting a significant new web project and my first order of business on the UI side was to specify XMLHttpRequest (buzzword catchphrase, yuck.) as the core around which the client would be developed. It's working fantastically. It simplifies just about everything, imho, once the basics are in place.

It is now possible to do highly-reactive monitoring applications in a browser without applets, plug-ins, or frames+script chicanery. Download the core app, then stream in the rest of the bits behind the scenes. Sweet!

The clients love it, we love to develop using it. Win, win situation - a strange place to be on an IT project.

High Performance Back-end Services (5, Funny)

pete-classic (75983) | more than 9 years ago | (#13358055)

SERVICE UNAVAILABLE

Re:High Performance Back-end Services (0)

Anonymous Coward | more than 9 years ago | (#13358146)

ROFL. I thought of exactly the same thing.

Re:High Performance Back-end Services (0)

Anonymous Coward | more than 9 years ago | (#13358214)

Heh, what did you expect, it's asp.net. ;-)

Re:High Performance Back-end Services (1)

drgonzo59 (747139) | more than 9 years ago | (#13358238)

Yeah I love that, that was a good laugh. I can see someone saying, "Hey boss, check out this article about Ajax, we gotta get ourselves some of dat Ajax stuff, its way awesome! Let's click on the link to read more about it - SERVICE UNAVAILABLE - doh!"

Thats nothing (1)

WindBourne (631190) | more than 9 years ago | (#13358261)

The guy who submitted it, is the same guy who wrote the article and has the downed server. shesshhhh

Re:High Performance Back-end Services (3, Informative)

Anonymous Coward | more than 9 years ago | (#13358375)


Dion Hinchcliffe's Blog - Musings and Ruminations on Building Great Systems

Agility, Service-Orientation, Enterprise Architecture, and Software Development
State of Ajax: Progress, Challenges, and Implications for SOAs
A lot of bits have been pushed around the blogosphere on the topic of Ajax over the last few months. This includes my own post back in March, which gave a general overview of what Ajax was and what it does. A lot of exciting stuff has happened since then, and Ajax has rapidy matured into a development of major significance. Coverage has been all over the map and runs the gamut from Rasmus' been-there-done-that 30 second Ajax tutorial to Alex Bosworth's list of Ajax Mistakes to the uber-repository of Ajax knowedge, Ajax Matters.

Many of you already know that Ajax is a web client programming style which eschews traditional HTML web pages, which are only sprinkled lightly with JavaScript and reload pretty much every time they are updated or clicked on. Instead, an Ajax web client receives an Ajax JavaScript library into a hidden frame which provides run-time visuals on the main browser window that look and feel very much like a native application. Ajax web clients, once loaded, communicate with XML services on the back end (via a browser's built-in powerful XMLHttpRequest API), and then use JavaScript to manipulate what the users sees programmatically via DHTML.

All of this allows Ajax to provide a compelling user experience because 1) it doesn't reload the web page, and 2) it runs asynchronously allowing background server-side requests for information to be issued, all while the users clicks, types, and otherwise interacts with the application in the foreground. Google Maps is the pre-eminent example of a modern Ajax application: rich, interactive, easy-to-use, and predictive in that it loads the map tiles that are just offscreen in case you need them. This is all very good for web client client development, but why all the attention across the board?

Figure 1: Ajax: The first compelling new client application model since the modern web browser

Because Ajax is a sincerely compelling synthesis of the ubiquitous features found in the most popular Internet browsers is why. Practitioners of Ajax get high-intensity user interaction (end-user productivity), asynchronicity (efficient backround processing), web browser access to web services (web service access, reuse, and interoperability, as well as SOA integration), platform neutrality (browser and operating system agnosticity), and the Ajax feature set can be delivered as a framework you don't have to create yourself (developer productivity).

Individually, these items are very nice, but taken as a whole, working solution and you have something extremely special. While many folks thought the web browser story had stopped around the year 2000, Ajax takes us to a whole new place. Slashdot recently highlighted a notable new article in Wired that claims that the industry, mostly on the basis of Ajax, "has affirmed the viability of the web as a standalone software development platform."

This is no small thing, and has the potential to repave the modern application development landscape. Why? Because Ajax creates a rich and fertile new space for developing software solutions that can reach almost anyone, anywhere whatever they're browsing with. It doesn't require anything more specific than your local browser, is based on standards, and leverages all the services that most organizations have in place in their back office, especially if they have been building service-oriented architectures.

Of course, there are some problems with Ajax, as there inevitably are with any major new approach. One is testing. You not only still have to test your applications, but even more thoroughly. Given that JavaScript, DHTML, XmlHttpRequest, and DOM support all vary slightly between browsers, you need to test your Ajax applications in all supported browser versions and in multiple screen resolutions to make sure you have all the kinks out. This is a pain and can be expensive, but can be dealt with by establishing good test procedures and automated test processes when possible.

The full test of a new application platform of course, is ready support in the form of available frameworks and development toolkits in both the commercial space and open source communities. And this shows us that interest in Ajax is high indeed. Everyone from TIBCO (General Interface) to Microsoft (Atlas) has Ajax development environments and frameworks rapidly on the way to market in the commercial space, while the open source world has already delivered numerous smaller tools. While Ajax Matters lists over 30 different Ajax tools and utilities that are already available, SourceForge lists significantly fewer active Ajax projects, which tend to be more serious, larger scale efforts. These include such offerings as ThyAPI, the Ajax Framework project and the Simplifying Ajax in Java projects, which appear to be the top three Ajax development kits currently listed on SourceForge. Also particularly notable in open source is SAJAX, which has nice support for Python and Ruby that claims to do "99% of the work for you." In fact, the newer, cooler languages are getting great support for Ajax, see here for a detailed post that affirms Ruby on Rails to be excellent for Ajax development.

As for blogoshere mindshare, Ajax is currently listed as the #6 overall blog search term on Technorati in popularity, right after "xbox 360". This implies that you'll see a lot of Ajax in web sites near you since developers appear to be vacuuming up the patterns, practices, and toolkits for creating Ajax applications. Unfortunately, there are few books out yet about Ajax, though Dave Crane and Eric Pascarello's Ajax in Action will apparently be out soon.

So all this activity points to the relative seriousness in which the software industry takes the Ajax movement, an approach which was only described tacitly earlier this year. What does this mean for SOA architects? A number of things...

SOA Implications

One: Ajax clearly embraces XML as the service payload of choice (though many Ajax users leverage JSON instead of XML, which is not technically Ajax, of which the last letter represents the X in XML). This clearly aligns very well with XML web services and open-standard SOAs.

Two: Lightweight SOAP and REST services are in and WS-* services may be on the rocks. Since Ajax applications can and will frequently call backend XML web services as the user interacts with the front-end, having lightweight, easy-to-consume, high performance/availability SOAP and REST web services will only become more important. Of course, the implication is that since Ajax applications are primarily in a fairly austere JavaScript sandbox, this means heavy-duty WS-*-style SOAP stacks probably won't play well with the lightweight XML/JSON service interactions that Ajax prefers. This doesn't mean WS-* is broken for Ajax, but at this time there are no Ajax frameworks yet that support more than basic SOAP service interaction. This certainly will affect SOA architecture since it's likely that Ajax will increasingly push back-end services to be extremely scalable, high-intensity, and atomic instead of the more pastoral XML document routing and orchestration view that many SOA architectures promulgate. In fact, Ajax is really more REST friendly since the interaction model is highly stateful, more resource-oriented, and can leverage the HTTP scalability and reliability mechanisms that most organizations already have. And that REST services automatically take advantage of.

Three: Beyond basic questions of load and message exchange pattern (document routing vs. atomic/state-like data transmission), there is a question of whether your SOA will be used more for integration between monolithic applications or as an access enabler. The simple answer is both, but the problem is that it's a clasically hard problem to merge two architecture styles together into one solution. Just look at the tension between transaction processing and reporting for a particularly famous example of the problem. Using the same database for both is virtually impossible and the architecture has to get fairly messy to have up-to-date information from the transaction processing side available for reporting. SOAs have to grapple with this issue increasingly and Ajax applications flowering within your organization's walls will force your SOA down a path you may not be ready to go down. So consider this a warning, Ajax adoption in your organization has the potential to drive your SOA for you as web app developers decide they like the services they find. For a good example of some of thinking that will have to go into SOAs as Ajax grows in popularity, see this excellent post by Joseph Scott.

All this being said, Ajax has a long way to go to be ready for prime-time, white collar, Fortune 1000 usage. Until solid commercial development options from major vendors are available and reasonably mature, larger organizations will probably wait. But as Jeff Schneider so succinctly pointed out recently, "casual services, dynamic scripting, and remixing are clearly the theme for 2005", and the rest of the industry isn't waiting. As Ajax proves to be the application model that allows compelling composite applications to be developed quickly, I expect that 2006 will be the year that Ajax emerges as both a key driver of SOA architecture (important: because, without a SOA, there can be no Ajax applications, by definition) and a must-have application development model.

Update: Dare Obesanjo recently enumerated some key points that Ajax application architects have to contend with and a few of them are particularly worthy of note including how to deal with the need for permalinks, the Back button, and others. Please check it out. He also notes that MSN will be talking about their best practice Ajax techniques at Microsoft's PDC developer's conference next month, which it looks like I will attend. Since a prerelease version of Atlas will be available there as well, expect some updates here on this blog on the latest.

SDL Survey Update: I'm simultaneously working on the REST version of the order service as well as the SSDL service description and clients. Expect these shortly!

Technorati: Enterprise Architecture, Computers and Internet, Programming, Web Services, Ajax
posted on Thursday, August 18, 2005 9:13 AM

Nothing (0, Offtopic)

Luigi30 (656867) | more than 9 years ago | (#13358062)

Nothing for you to see here, please move along. I guess Slashdot hasn't heard of Ajax either.

Wow (1, Informative)

nightsweat (604367) | more than 9 years ago | (#13358068)

Slashdotted by the second comment. That's impressive.

Re:Wow (3, Informative)

TopSpin (753) | more than 9 years ago | (#13358107)

Slashdotted by the second comment.

Doubt it. More like they saw the "mysterious future" post themselves and the subscribers hitting their machine before the post appeared before all ./. Some admin with enough wit to handle the situation frobbed the server and saved himself a tough Friday afternoon.

excellent idea for a script! (2, Insightful)

Tumbleweed (3706) | more than 9 years ago | (#13358314)

That's something a script should be handling for every site - it has an account on Slashdot, and can see the mysterious future posts - if there's a link to their site in it, it sends an alert to the sysad.

If Slashdot supported AJAX (5, Funny)

Anonymous Coward | more than 9 years ago | (#13358074)

You could see the dupes as the editors approved them.

What is it? (0)

Daniel_Staal (609844) | more than 9 years ago | (#13358079)

Ok, the site is down, and I'm ignorant. What is Ajax? Free Karma to the best answer.

Re:What is it? (0)

Anonymous Coward | more than 9 years ago | (#13358092)

Not sure if its slashdotted or not. [slashdot.org]

Don't care about karma, so meh.

Re:What is it? (4, Informative)

cloudkj (685320) | more than 9 years ago | (#13358125)

AJAX is Asynchronous JavaScript and XML. Basically a web development technique. You have seen AJAX in action if you've used Gmail or Google Maps. Check out http://en.wikipedia.org/wiki/AJAX [wikipedia.org] for more info.

Re:What is it? (2, Informative)

RingDev (879105) | more than 9 years ago | (#13358128)

Active Java Asychronous Transfer (IIRC) it allows you to run xml queries from the client to the server with out posting the page.

Compare maps.google.com to mapquest.com. With Mapquest, when you zoom/move the map, it posts to the server and refreshes the frame. In google maps, there is no post, the map just moves/zooms like it would on a thick client.

-Rick

Re:What is it? (3, Informative)

AKAImBatman (238306) | more than 9 years ago | (#13358322)

JavaScript. Please don't confuse Java with JavaScript. It just makes everyone's lives harder. (Especially when managers hire the new "Java" expert.) :-/

Re:What is it? (4, Informative)

Metaphorically (841874) | more than 9 years ago | (#13358149)

Ajax is a buzz-word for Asynchronous JavaScript and XML. It generally refers to web based applications that feel more responsive than traditional pages because they don't refresh the whole page every time the user does an action. There's plenty more on Wikipedia [wikipedia.org] .

Once you get down to the brass tacks of writing an app, here's a good way [codedread.com] to deal with implementation problems people run in to.

Re:What is it? (1, Informative)

Anonymous Coward | more than 9 years ago | (#13358164)

Re:What is it? (-1, Troll)

Anonymous Coward | more than 9 years ago | (#13358175)

Have you been in a coma, a cave, or just high on dope for the past year?

And to be honest, I think even if someone told you, you wouldn't have a clue. I mean, apparently you don't know what Google is either. [justfuckinggoogleit.com]

Re:What is it? (2, Insightful)

Mr. Underbridge (666784) | more than 9 years ago | (#13358197)

Have you been in a coma, a cave, or just high on dope for the past year

Not all of us follow the latest fads. My programming library is kind of like my closet. It's neither worth rebuying your clothes or relearning your skillset annually.

Re:What is it? (1)

Daniel_Staal (609844) | more than 9 years ago | (#13358245)

I don't think you understand the point of my question. The article wasn't avalible, and it was talking about the growth of a tech that was less than a year old, by the blurb. I had never heard of it. I keep moderatly up to date, but I don't have time to follow every new trend. Apparently this one is interesting to people.

So, in the interest of the discussion, I asked what it was. It's not likely to be relevent to anything I do; If it was I'd likely have heard of it. But here's a chance to offer insight into the issue, both to me and other readers. A chance to show the benfits and disadvantages.

Since I can't discuss the article, that's the next best thing. And it might be useful, to me or others.

Re:What is it? (1)

Smokin Goat McGruff (19225) | more than 9 years ago | (#13358329)

It was actually introduced in IE 5, so it's much more than a year old. It's only recently gained popularity thanks to the terrible acronym AJAX. Seriously, doesn't anyone else thing of Duckman when they hear that?

-nb

Re:What is it? (1)

mogalpha (782997) | more than 9 years ago | (#13358219)

AJAX is a combination of technologies that allows web app creators to have real-time refreshing of data. This refresh is not only selective (you can choose only to update a portion of the page), but it also won't waste bandwidth when there's nothing to refresh (it just sends a checksum or an id number). I'm currently using it in http://www.mogos.net/ [mogos.net] . On the front page of the site, you can see the latest word's that people have posted (and through AJAX, it refreshes every 8 seconds). It's a sort of real-time/turn-based word game.

Re:What is it? (2, Informative)

ch-chuck (9622) | more than 9 years ago | (#13358279)

To be really up-to-date and 'with-it', here's a podcast [softwareas.com]

More than a year thanks (5, Informative)

buro9 (633210) | more than 9 years ago | (#13358083)

"Ajax hasn't even been around a year yet"

Which is strange, because in 1999 I was making web applications that utilised hidden frames to post information to the server and return JavaScript arrays which I would then use to modify the limited parts of the DOM I had access to at that time. It worked in Netscape 3, Netscape 4, and IE 3 and IE 4.

So the techniques in question have been around for ages, and the use of Xml and the XmlHttp objects appeared several years ago with Outlook Web Access.

The ONLY thing that has been around for approx' a year is the utterly stupid name for it, "AJAX".

I'm glad other people are picking up on it and using it, it's very powerful, but let's not credit Adaptive Path with creating a technology or method that many people have been using for a long time.

If you have to use a name, then RIA (Rich Interactive Applications) is far more suitable and doesn't restrict the developer to asynchronous work only for it to be included in that.

Re:More than a year thanks (2, Informative)

PIPBoy3000 (619296) | more than 9 years ago | (#13358147)

Yep. Very true.

We were having performance issues with our Intranet home page. The page was data-driven and requests took too long to execute. People would get impatient, hit refresh, add more items to the queue, and eventually things would melt into a puddle.

I rewrote as much as possible using static javascript includes and cookies, greatly improving performance. There were still a couple things personalized to the individual. Those I threw into a hidden frame which filled in a couple drop-down boxes and populated a line that said "Hello username." (not my idea).

If the database was down or busy, those things wouldn't be available, but 90% of the time the users wanted to click one of the static links.

No Kidding (2, Interesting)

Tony (765) | more than 9 years ago | (#13358171)

I started in about 2000 with hidden frames, Javascript, and DOM. I got the idea from someone else on the web; I thought it was brilliant at the time. I was able to auto-update forms without clearing the form, etc. All the stuff that AJAX is doing now.

It's nothing new. Other folks just think it is.

Re:More than a year thanks (1)

jdavidb (449077) | more than 9 years ago | (#13358211)

If you have to use a name, then RIA (Rich Interactive Applications) is far more suitable and doesn't restrict the developer to asynchronous work only for it to be included in that.

Thank you for the explanation. I've been wondering what in the world AJAX is, and why I should care. I don't know what AJAX is. But I can tell what a Rich Interactive Application is. Isn't it nice how language can be used as a communication tool rather than a way to hide your meaning so you can feel elitist compared to those who do not know the new terms? To date I don't think there's been a single slashdot submission that explained in the summary what AJAX was, even though this submitter clearly agrees that it's something new. You'd think if it were new and something they want to promote they would be explaining it at every opportunity -- unless of course they want to hide the fact that it's not that big of an advancement.

Re:More than a year thanks (4, Insightful)

buro9 (633210) | more than 9 years ago | (#13358217)

AJAX = Asynchronous Javascript And Xml

It's a terrible name because it says nothing about what it is, only what it is made of. Even then it poorly describes what it is made of, as it can be made of other things too.

So from this CBL (Carbon Based Lifeform) to another, I say, "Goodnight".

Re:More than a year thanks (0)

Anonymous Coward | more than 9 years ago | (#13358337)

Don't you mean CarbOn Based Organic Lifeform?

Re:More than a year thanks (1)

merreborn (853723) | more than 9 years ago | (#13358231)

A startup I worked for, State Software [prnewswire.com] had a full out API developed that did the exact same thing back in 2001 -- used a hidden IFRAME to pass javascript objects to and from a server. It was enterprise ready... But it was proprietary, and while they recieved quite a bit of attention from the biggest names in ECommerce apps, they never did get any real sales/installations.

Popularization is an important job ... (4, Insightful)

lazzaro (29860) | more than 9 years ago | (#13358246)

The person who makes a technology popular receives technical fame for a good reason -- by making more of the world aware of a good technology, in a way that leads to deployment, the world becomes a better place. Sometimes, popularization adds more value than invention to an idea.

Re:More than a year thanks (0)

Anonymous Coward | more than 9 years ago | (#13358250)

Ajax hasn't even been
big a year yet
around != big

Re:More than a year thanks (1)

quamaretto (666270) | more than 9 years ago | (#13358255)

Which is strange, because in 1999 I was making web applications that utilised hidden frames to post information to the server and return JavaScript arrays which I would then use to modify the limited parts of the DOM I had access to at that time. It worked in Netscape 3, Netscape 4, and IE 3 and IE 4.

Yup. Our company has a VERY old web application that makes minor use of this sort of thing, to fill dropdowns in a business application. Except, whoever wrote it used a pop-up window instead. Not quite as eleganet.

The ONLY thing that has been around for approx' a year is the utterly stupid name for it, "AJAX".

A simple solution would be to believe AJAX stands for "AJAX, Javascript And XmlHttpRequest." (This definition replaces 'asynchronous' with a specific mechanism, XmlHttpRequest, and drops XML.)

Even so, it could be interpreted in the same manner as LAMP. The operating system could be one of Linux, any BSD, Solaris, Darwin, or something else entirely. The web server could be Apache or a great many others. Database? MySQL, Postgres, Firebird, SQLite... Language/Platform? Oh, hell. So, the real representation would be /[LBSDW].[MPFS][PRMLS]/. Use your imagination on these. AJAX is the sameway; it is a mishmash of ideas and technologies, but a few lead the pack and represent what is going on.

But, maybe your RIA idea is better. :)

I have been working on a nice AJAX app for awhile now and the most tiring part of it (apart from cross-browser woes) is trying to explain what AJAX is.

RE:More than a year thanks (0)

Anonymous Coward | more than 9 years ago | (#13358260)

Yeah, but the X doesn't stand for 'Hidden Frames'.
The topic here is AJAX, not the fact that an (IMO) ugly hack can also make RIA's.

Although I do agree that it has been around for a lot longer than TFA makes out, and that AJAX is a wanky name - everything in the tech world is given an acronym now-a-days and it seems most of the time the words are fitted to the acronym not the other way round. Adds to the coolness for people who don't use the tech and annoys some people who do use the tech (but don't want a stupid name for it).

Re:More than a year thanks (1)

TigerTale (414169) | more than 9 years ago | (#13358280)

If you have to use a name, then RIA (Rich Interactive Applications) is far more suitable

RMS, is that you?

Re:More than a year thanks (1)

TheGreatDonkey (779189) | more than 9 years ago | (#13358341)

I laughed when I read your post, as I was thinking the same thing.

For years there has been this certain drive to turn the web browser into more of an "application" platform, and most attempts I have seen were a failure in one way or another (poor execution speed, strict browser requirements, buggy interface, random crashing, inconsistent experience with different browsers or even different versions of same browser, etc.). And for the countless billions of web pages out there, and the very limited scope of those that I have seen myself, I have only seen two web-based "applications" that impressed me with a certain wow factor - Outlook Web Access, and Google Maps.

This just seems like something new for the guys who keep pushing the web browser as a viable application platform to grab onto to sell books and libraries until the next acronym comes flying by. Meanwhile, I am still both impressed and amazed at the amount of information available now, compared to 10 years ago, simply by just using my browser as the information tool it was originally intended. In fact, I have no idea how I would have even accomplished my job 10 years ago without it.

Microsoft? (0, Offtopic)

Eightyford (893696) | more than 9 years ago | (#13358089)

Microsoft has an AJAX IDE coming out? Isn't AJAX supposed to do away with alot of Windows development , and replace it with browser based apps? I could see Microsofts AJAX IDE crippling Firefox in many 'accidental' ways.

Re:Microsoft? (0)

Anonymous Coward | more than 9 years ago | (#13358195)

Huh?

Do you even know what an IDE is?

I'm guessing no.

Re:Microsoft? (0)

Anonymous Coward | more than 9 years ago | (#13358218)

perhaps he means the resulting app will be compiled in such a way that it wont work in firefox?
he's scraping the bottom of the barrel of paranoia though imo

Re:Microsoft? (1)

Eightyford (893696) | more than 9 years ago | (#13358267)

Frontpage is basically in IDE right? Sure you can write standards complient code with it, but the automated stuff spews out all kinds of non-standard crap.

Version I will support standards. (0)

Anonymous Coward | more than 9 years ago | (#13358308)

But Version II and onward of Microsoft's AJAX toolkit will proprietize things.

Embrace. Extend. Destroy.

I think they need to use some Ajax... (1)

meditation_dude (907877) | more than 9 years ago | (#13358095)

...to scrub out their server after that Slashdotting. ;-)

Re:I think they need to use some Ajax... (0)

Anonymous Coward | more than 9 years ago | (#13358145)

Hmm, if only the cleaner "Ajax" would be known to every human in the great wide world ...

Is it really that popular?

Smoking crater (0)

Anonymous Coward | more than 9 years ago | (#13358096)

"Ajax requires high-performance service-orie....a@%JA6zzzz1...NO CARRIER

The Current state of ajax? (3, Funny)

Anonymous Coward | more than 9 years ago | (#13358103)

I think you can still find the cleanser at any Wal-Mart, Meijer or Kroger. ;)

Re:The Current state of ajax? (1)

Radres (776901) | more than 9 years ago | (#13358183)

OMG TEH LOLZ!!!

What's next, you can find Java at Starbucks?

Re:The Current state of ajax? (2, Funny)

aminorex (141494) | more than 9 years ago | (#13358305)

...Perl in oysters, Ruby in North Carolina, Afghanistan, and Tanzania, CAML in the Zahara and Gobi, Orca in the north Pacific, C in the alphabet, Ada in Babbage's budoir...

I'm working on a script for a Matt Damon movie, "The Bourne Shell".

Re:The Current state of ajax? (1)

maelstrom (638) | more than 9 years ago | (#13358405)

And the SQL to the Bourne Shell, "Bourne Again".

Since it's Slashdotted... (5, Informative)

tcopeland (32225) | more than 9 years ago | (#13358104)

...here's an article [onlamp.com] by Curt Hibbs on Ajax with Rails. He's got an "Ajax in 60 seconds" history lesson at the top of the article...

AJAX and Centrino (3, Insightful)

cerelib (903469) | more than 9 years ago | (#13358112)

Does anybody think of Intel Centrino when they hear AJAX? They are quite similar in the fact that it is just giving a name to using a combination of technologies. Also, has anybody ever heard a Best Buy computer salesman say "This one has a Centrino processor."?

No. (1)

mnemonic_ (164550) | more than 9 years ago | (#13358227)

I did not think "Centrino" when I heard "AJAX." It's not like giving a single name to multiple technologies is rare, see; object oriented programming, linux, fuel cell, sensor fusion, quiet supersonic platform (QSP), etc. I don't see why you think AJAX and Centrino are so exceptional.

Re:No. (1)

cerelib (903469) | more than 9 years ago | (#13358293)

I think that your counter-examples are different. In AJAX people are already using these technologies to make web applications, but if they decide to leave one out it is no longer AJAX. If a comp manufacturer wants to provide their own wireless card instead of Intel's then it is no longer Centrino, but still the same thing. OO is an idea, not a catchphrase. You can implement OO any way you see fit with many languages(even non-OO langs). Linux is then name of a specific kernel. I can't comment on the rest.

Add LAMP to the list (1)

merreborn (853723) | more than 9 years ago | (#13358285)

Linux, Apache, MySQL and PHP, for the uninitiated

Ruby on Rails settles everything (5, Funny)

duffbeer703 (177751) | more than 9 years ago | (#13358115)

Ruby on Rails and AJAX makes everything else obsolete. A coworker and I just implemented the J2EE spec in 25 minutes. We're working on the win32 api on monday!

Re:Ruby on Rails settles everything (1)

TopSpin (753) | more than 9 years ago | (#13358188)

We're working on the win32 api on monday!

Win32? Big deal. Go implement X11 6.8.2 if you want to impress /.

Go ahead, I'll wait...

Re:Ruby on Rails settles everything (1)

drgonzo59 (747139) | more than 9 years ago | (#13358278)

Oh yeah, I'll see your X11 and raise by one Emacs editor.

You know.. (2, Insightful)

Anonymous Coward | more than 9 years ago | (#13358132)

He also points out that Ajax will inadvertently end up being a driving force for Service-Oriented Architecture (SOA) for many organizations since it requires high performance back-end XML services.

Advertising programming languages with a pre-com-bust-style-buzzword-overload isn't very useful for gaining the attention of developers.

What is it? Its this (3, Informative)

razmaspaz (568034) | more than 9 years ago | (#13358133)

http://en.wikipedia.org/wiki/AJAX [wikipedia.org]

Ajax is using Javascript to fetch only part of a web page and then updating the page with DHTML and JavaScript, reducing round trip time and server load and making the application "feel " more native.

accessability guidelines (4, Insightful)

sammy baby (14909) | more than 9 years ago | (#13358137)

Does anyone here know of a good reference for balancing the "gee-whiz, nifty" aspects of ajax techniques with designing towards accessibility? I like the thought of, say, livesearch, but dislike the idea of breaking support for text-to-speech readers, assistive devices, et cetera.

In fact, the article in the story might have a terrific section about just this issue. But I wouldn't know, because the server fell over worse than I do after a gin-and-tonic bender.

Re:accessability guidelines (1)

Metaphorically (841874) | more than 9 years ago | (#13358215)

Accessibility takes a back seat to flashiness so far. A lot of "gee-whiz" ajax applications are great eye candy and the surprising responsiveness can make you wonder if it's just a web page or something more. I think that most of what we're seeing now doesn't get past that stage.

I follow Ajaxian [ajaxian.com] , and even though it doesn't cover accessibility directly, I find that the developers they link to do get in to these issues sometimes. It's a new field, so you have to dig deeper to find people doing apps that are more than just experiments.

Degrade gracefully. Include keyboard accelerators. Always use alt text. The same rules, but there's got to be a lot of interpretation still.

Re:accessability guidelines (1)

MemeRot (80975) | more than 9 years ago | (#13358333)

There was an article on slashdot a couple days ago about ibm donating a large section of code to firefox to enhance accessibility in ajax apps.

qooxdoo (3, Informative)

The Bungi (221687) | more than 9 years ago | (#13358140)

http://qooxdoo.sourceforge.net/ [sourceforge.net]

Weird name, but very impressive. Though not an "AJAX" framework, with some effort it can be "bound" to an OOB request factory or something similar to have your cake and eat it (rich client-side stuff + backend server). Very cool. And it works with IE and FF, but obviously better with Firefox.

BTW, I love how this "AJAX" thing is just a cute name for a Microsoft technology that was first introduced with IE4. The first "AJAX" app was the Exchange OWA client.

Re:qooxdoo (1)

MemeRot (80975) | more than 9 years ago | (#13358377)

True, but the XML part of this framework isn't really necessary. Why send a lot of xml text back to the browser and then make it load it into memory and walk through it? It's often better to send back a Javascript array - no real overhead for the browser or the internet connection.

BTW, OWA is so much more pleasant to use in Firefox (without all the dynamic crap) than it is in IE. It's sooooo slow in IE when all I want is webmail.

What is this... (0)

creimer (824291) | more than 9 years ago | (#13358150)

Postings of articles about AJAX on /. seems to be getting very popular these days. Is AJAX important or just another fad?

Got in before it went down (5, Interesting)

NoTheory (580275) | more than 9 years ago | (#13358153)

Dion Hinchcliffe's Blog - Musings and Ruminations on Building Great Systems [hinchcliffe.org]

Agility, Service-Orientation, Enterprise Architecture, and Software Development

A lot of bits have been pushed around the blogosphere on the topic of Ajax [wikipedia.org] over the last few months. This includes my own post [hinchcliffe.org] back in March, which gave a general overview of what Ajax was and what it does. A lot of exciting stuff has happened since then, and Ajax has rapidy matured into a development of major significance. Coverage has been all over the map and runs the gamut from Rasmus' been-there-done-that 30 second Ajax tutorial [rajshekhar.net] to Alex Bosworth's list of Ajax Mistakes [sourcelabs.com] to the uber-repository of Ajax knowedge, Ajax Matters. [ajaxmatters.com]

Many of you already know that Ajax is a web client programming style which eschews traditional HTML web pages, which are only sprinkled lightly with JavaScript and reload pretty much every time they are updated or clicked on. Instead, an Ajax web client receives an Ajax JavaScript library into a hidden frame which provides run-time visuals on the main browser window that look and feel very much like a native application. Ajax web clients, once loaded, communicate with XML services on the back end (via a browser's built-in powerful XMLHttpRequest API [wikipedia.org] ), and then use JavaScript to manipulate what the users sees programmatically via DHTML.

All of this allows Ajax to provide a compelling user experience because 1) it doesn't reload the web page, and 2) it runs asynchronously allowing background server-side requests for information to be issued, all while the users clicks, types, and otherwise interacts with the application in the foreground. Google Maps [google.com] is the pre-eminent example of a modern Ajax application: rich, interactive, easy-to-use, and predictive in that it loads the map tiles that are just offscreen in case you need them. This is all very good for web client client development, but why all the attention across the board?

Figure 1: Ajax: The first compelling new client application model since the modern web browser

Because Ajax is a sincerely compelling synthesis of the ubiquitous features found in the most popular Internet browsers is why. Practitioners of Ajax get high-intensity user interaction (end-user productivity), asynchronicity (efficient backround processing), web browser access to web services (web service access, reuse, and interoperability, as well as SOA integration), platform neutrality (browser and operating system agnosticity), and the Ajax feature set can be delivered as a framework you don't have to create yourself (developer productivity).

Individually, these items are very nice, but taken as a whole, working solution and you have something extremely special. While many folks thought the web browser story had stopped around the year 2000, Ajax takes us to a whole new place. Slashdot recently highlighted a notable new article [wired.com] in Wired that claims that the industry, mostly on the basis of Ajax, "has affirmed the viability of the web as a standalone software development platform."

This is no small thing, and has the potential to repave the modern application development landscape. Why? Because Ajax creates a rich and fertile new space for developing software solutions that can reach almost anyone, anywhere whatever they're browsing with. It doesn't require anything more specific than your local browser, is based on standards, and leverages all the services that most organizations have in place in their back office, especially if they have been building service-oriented architectures.

Of course, there are some problems with Ajax, as there inevitably are with any major new approach. One is testing. You not only still have to test your applications, but even more thoroughly. Given that JavaScript, DHTML, XmlHttpRequest, and DOM support all vary slightly between browsers, you need to test your Ajax applications in all supported browser versions and in multiple screen resolutions to make sure you have all the kinks out. This is a pain and can be expensive, but can be dealt with by establishing good test procedures and automated test processes when possible.

The full test of a new application platform of course, is ready support in the form of available frameworks and development toolkits in both the commercial space and open source communities. And this shows us that interest in Ajax is high indeed. Everyone from TIBCO (General Interface [tibco.com] ) to Microsoft (Atlas [asp.net] ) has Ajax development environments and frameworks rapidly on the way to market in the commercial space, while the open source world has already delivered numerous smaller tools. While Ajax Matters lists over 30 different Ajax tools and utilities that are already available [ajaxmatters.com] , SourceForge [sourceforge.org] lists significantly fewer active Ajax projects, which tend to be more serious, larger scale efforts. These include such offerings as ThyAPI [thyamad.com] , the Ajax Framework [sourceforge.net] project and the Simplifying Ajax in Java [sourceforge.net] projects, which appear to be the top three Ajax development kits currently listed on SourceForge. Also particularly notable in open source is SAJAX [modernmethod.com] , which has nice support for Python and Ruby that claims to do "99% of the work for you." In fact, the newer, cooler languages are getting great support for Ajax, see here for a detailed post [jroller.com] that affirms Ruby on Rails [rubyonrails.com] to be excellent for Ajax development.

As for blogoshere mindshare, Ajax is currently listed as the #6 overall blog search term on Technorati [technorati.com] in popularity, right after "xbox 360". This implies that you'll see a lot of Ajax in web sites near you since developers appear to be vacuuming up the patterns, practices, and toolkits for creating Ajax applications. Unfortunately, there are few books out yet about Ajax, though Dave Crane and Eric Pascarello's Ajax in Action [amazon.com] will apparently be out soon.

So all this activity points to the relative seriousness in which the software industry takes the Ajax movement, an approach which was only described tacitly earlier this year. What does this mean for SOA architects? A number of things...

SOA Implications

One: Ajax clearly embraces XML as the service payload of choice (though many Ajax users [asp.net] leverage JSON [wikipedia.org] instead of XML, which is not technically Ajax, of which the last letter represents the X in XML). This clearly aligns very well with XML web services and open-standard SOAs.

Two: Lightweight SOAP [w3.org] and REST [uci.edu] services are in and WS-* services may be on the rocks. Since Ajax applications can and will frequently call backend XML web services as the user interacts with the front-end, having lightweight, easy-to-consume, high performance/availability SOAP and REST web services will only become more important. Of course, the implication is that since Ajax applications are primarily in a fairly austere JavaScript sandbox, this means heavy-duty WS-*-style SOAP stacks probably won't play well with the lightweight XML/JSON service interactions that Ajax prefers. This doesn't mean WS-* is broken for Ajax, but at this time there are no Ajax frameworks yet that support more than basic SOAP service interaction. This certainly will affect SOA architecture since it's likely that Ajax will increasingly push back-end services to be extremely scalable, high-intensity, and atomic instead of the more pastoral XML document routing and orchestration view that many SOA architectures promulgate. In fact, Ajax is really more REST friendly since the interaction model is highly stateful, more resource-oriented, and can leverage the HTTP scalability and reliability mechanisms that most organizations already have. And that REST services automatically take advantage of.

Three: Beyond basic questions of load and message exchange pattern (document routing vs. atomic/state-like data transmission), there is a question of whether your SOA will be used more for integration between monolithic applications or as an access enabler. The simple answer is both, but the problem is that it's a clasically hard problem to merge two architecture styles together into one solution. Just look at the tension between transaction processing and reporting for a particularly famous example of the problem. Using the same database for both is virtually impossible and the architecture has to get fairly messy to have up-to-date information from the transaction processing side available for reporting. SOAs have to grapple with this issue increasingly and Ajax applications flowering within your organization's walls will force your SOA down a path you may not be ready to go down. So consider this a warning, Ajax adoption in your organization has the potential to drive your SOA for you as web app developers decide they like the services they find. For a good example of some of thinking that will have to go into SOAs as Ajax grows in popularity, see this excellent post by Joseph Scott. [randomnetworks.com]

All this being said, Ajax has a long way to go to be ready for prime-time, white collar, Fortune 1000 usage. Until solid commercial development options from major vendors are available and reasonably mature, larger organizations will probably wait. But as Jeff Schneider so succinctly pointed out recently [blogspot.com] , "casual services, dynamic scripting, and remixing are clearly the theme for 2005", and the rest of the industry isn't waiting. As Ajax proves to be the application model that allows compelling composite applications to be developed quickly, I expect that 2006 will be the year that Ajax emerges as both a key driver of SOA architecture (important: because, without a SOA, there can be no Ajax applications, by definition) and a must-have application development model.

Update: Dare Obesanjo recently enumerated some key points [25hoursaday.com] that Ajax application architects have to contend with and a few of them are particularly worthy of note including how to deal with the need for permalinks, the Back button, and others. Please check it out. He also notes that MSN will be talking about their best practice Ajax techniques at Microsoft's PDC developer's conference next month, which it looks like I will attend. Since a prerelease version of Atlas will be available there as well, expect some updates here on this blog on the latest.

SDL Survey Update: I'm simultaneously working on the REST version of the order service as well as the SSDL service description and clients. Expect these shortly!

Technorati: Enterprise Architecture [technorati.com] , Computers and Internet [technorati.com] , Programming [technorati.com] , Web Services [technorati.com] , Ajax [technorati.com]

posted on Thursday, August 18, 2005 9:13 AM

Ajax hasn't even been around a year yet?! (3, Funny)

Flinx_ca (809816) | more than 9 years ago | (#13358155)

Ajax [townofajax.com] has been around for 50 years...

Re:Ajax hasn't even been around a year yet?! (0)

Anonymous Coward | more than 9 years ago | (#13358298)

a few millenia, actually http://www.infoplease.com/ce6/ent/A0802924.html [infoplease.com]

i stopped reading here: (5, Informative)

circletimessquare (444983) | more than 9 years ago | (#13358185)

"Ajax hasn't even been around a year yet"

excuse me?

ajax the functionality has been around for 6 years or more

the buzzword "ajax" and the google maps implementation that skyrocketed the word to buzzword status has only been around for less than a year

i'm usually not one to champion geek snobbery

but when geek snobbery is pitted against cattle herds of phbs spouting buzzwords with little understanding of the buzzword itself, geek snobbery is more appealing

Re:i stopped reading here: (1)

camarojoe (902869) | more than 9 years ago | (#13358201)

Ajax (tm) has been around for about 24 years, and Comet (tm) works better Anyway, the article says "Service Unavailable". :P

Mmm, yeah, ok (2, Interesting)

Anonymous Coward | more than 9 years ago | (#13358204)

Dion Hinchcliffe writes...

'Dion Hinchcliffe has a detailed article about how Ajax has evolved'

It is never a good sign when someone talks about themselves in the 3rd person.

You gotta love those consultants, always after some free ad space in search of the dollar...

Annoyed (2, Informative)

defile (1059) | more than 9 years ago | (#13358220)

You can't (via "AJAX") query any site but the one that served the script without the browser imposing this scary security warning. We run the sites in question, they just have different domain names.

Sigh.

I realize there's worry about cross site scripting attacks, and in the end it's not a big deal, it just means moving the request to a server side proxy. It's just added complexity that wouldn't exist if someone didn't impose something "for our own good".

Re:Annoyed (0)

Anonymous Coward | more than 9 years ago | (#13358315)

That security "feature" exists when you are using IE. You can "AJAX" other domains.
At least I did it from localhost to one of my works web sites.

Simple fix for cross-domain AJAX (1)

bexmex (663081) | more than 9 years ago | (#13358358)

You can't (via "AJAX") query any site but the one that served the script without the browser imposing this scary security warning. We run the sites in question, they just have different domain names.

Use a proxy.

Create a page in your favorite scripting language that forwards the HTTP request for you. Then put that page in your domain, and make AJAX calls to it.

5 lines of ASP, PHP, Perl, or Python... or 20 lines of JSP. Easy!

Old AJAX in New Buzzwords (2, Interesting)

Doc Ruby (173196) | more than 9 years ago | (#13358222)

The "name" AJAX hasn't been around long, but client JavaScript loading XML from servers for dynamic page rendering, inrteractive with client GUI events, has beeen around as long as JavaScript and XML. Before XML, it was data in proprietary or app-specific formats. Along the way it was FRAMES. The technique has always been the wizardry of the most aggressive web developers.

But now the marketers have a buzzword for it. It's good to have them back. They got so spun out as the Bubble popped that we haven't been able to get them to get anyone to buy stuff for years. Now it's time for them get back to work, marketing the tech that the rest of us have been producing for the past 5 years. It's good to have you back on the team - now show us the money.

good xmlhttp site (0)

Anonymous Coward | more than 9 years ago | (#13358243)

check www.litebay.org's search box for a good xmlhttp example.

This is laughable (5, Insightful)

ikekrull (59661) | more than 9 years ago | (#13358265)

We need to write out business apps in Javascript now because this is the only standard browser vendors can agree on?

Javascript, it's non-standard browser-specific extension syntax and the restrictive, incomplete and non-standard HTML DOM is an awful environment to write apps in, and it illustrates clearly just how dysfunctional the modern software industry is today.

AJAX is a shit way to write apps, it's central concept revolves around badly hacking around a problem that shouldn't even exist in a language that was never intended for use in such a way, its like we've got the worst aspects of every major technology available today, grudgingly provided by browser vendors who are want to take their ball and go home since nobody wants to use their proprietary ActiveX or XUL - in an incompatible fashion and we're supposed to see this as a step forward?

It's stupid, AJAX is stupid, and browser based apps are crap.

Re:This is laughable (3, Insightful)

Tumbleweed (3706) | more than 9 years ago | (#13358351)

It's stupid, AJAX is stupid, and browser based apps are crap.

Dear Sir or Madam,

You rock.

Sincerely,

Moi

Re:This is laughable (1)

akuma(x86) (224898) | more than 9 years ago | (#13358367)

Sounds like x86 :)

Crap, crap, crap, loaded with more crap. But 99% of the world uses it due to market forces.

Re:This is laughable (0)

Anonymous Coward | more than 9 years ago | (#13358395)

If you still contend that thick-client applications are the correct way to go for most data entry and information retrieval problems then you will be out of business soon. Server + Thin Client "AJAX" + browser allows for a far faster development cycle than thick-client apps.

Ajax compared to Flash (4, Interesting)

ObligatoryUserName (126027) | more than 9 years ago | (#13358273)

Now I'm not saying that these are mutually exclusive technologies (Macromedia itself has put out some examples of them working together), but as someone who started out writing a lot of Javascript and moved over to Flash in part to escape browser incompatibilites, what is the technical advantage of Ajax as compared to Flash.

As far as I can tell, Flash is more accessible (they've built in hooks for this), and Flash uses less bandwidth. (It comiplies to a binary format.) There's an open source compiler (MotionTwin). Flash also seems to provide a better user experience. (Compare Google Earth to Flash Earth [flashearth.com] .)

I know everyone here doesn't like Flash because it's used for advertising, but people here talk a lot about how wrong it is to attack a technology because of how some people choose to use it.

So, seriously, I've been thinking about looking into Ajax some more, but right now I don't have a good reason to. Convince this Flash programmer that Ajax is a better solution.

Site already slow (3, Funny)

Saiyine (689367) | more than 9 years ago | (#13358281)


Here's a mirror:

Service Unavailable

--
Dreamhost [dreamhost.com] superb hosting.
Kunowalls!!! [kunowalls.host.sk] Random sexy wallpapers.

Still pissed, I think. (2, Funny)

Leontes (653331) | more than 9 years ago | (#13358287)

I tried to get him to talk to me [wikipedia.org] , but he was still muttering some shit about armor and went back into Erebus. So his current state: dead and bothered.

Thin Client, My Ass! (2, Informative)

_bug_ (112702) | more than 9 years ago | (#13358299)

This is nothing more than a repeat of what we saw when Flash started to get popular.

AJAX requires a client that supports javascript in the first place, along with XML and whatever other bits of things (hidden frames.. god knows what else) to get and manipulate all this data.

So truly thin-clients (think Lynx circa 1996, guys) are SOL. Now it's AJAX or bust.

And you're probably thinking "well who the hell uses Lynx or some other, archaic, web browser?"

Well there are those people out there, but that's not all. I'm thinking about the non-human factor, computer applications that come in whatever form to consume the information available on the web. Many (though not all) don't have a javascript engine to execute the various instructions needed to get at the data. So once AJAX becomes ubiquitous (enough), search engines will either need to start using smart crawlers that can execute javascript, or their indexes will start to really be meaningless.

And that's just one of (what I vision) many non-human processes that take web pages and process them (the data marked up by HTML... remember, that's what the web has always been about, data structured with HTML) to produce more useful information for users, sometimes human, sometimes other non-human applications that futher analyze, compress, etc.. the data they find.

When Flash hit the streets, we saw this problem come up rather quickly, although many simply chose (and still choose) to ignore the issue. You still can't (really) bookmark a single page inside a Flash movie... so if there's vital data you need, you have to watch/move through the movie to get to the key page you're after. AJAX will prove to be no different.

So what? Use RSS or web services or some other means to provide information to non-visual applications (everything besides a web browser developed after 1998).

But RSS,SOAP,etc. is simply re-inventing the HTML wheel. They exist simply because HTML isn't being used the way it was always intended to be. You can write an application to parse heading tags and present their contents in a list format. You can write an application to submit a query via a POST operation (form fields) and parse the results back to the user.

Simple shit. Being done since the 1990s with great results.

But not anymore. The web is abused so much we reinvent HTML with XML. Now we only need a 4kb file to present a 20 character string to a consumer process. Bloated. Ugly. Inefficient.

And you think XML will be the answer? HELL NO. XSLT has no business even existing, and yet there it is. XHTML? Give me a break.

The web is a piece.

AJAX is just helping to quicken the flushing of the web down the toilet, and not helping to clean it.

Re:Thin Client, My Ass! (0)

Anonymous Coward | more than 9 years ago | (#13358361)

Wah wah wah. I'm a crank.

Re:Thin Client, My Ass! (1)

cosinezero (833532) | more than 9 years ago | (#13358394)

Thin is relative. 65K is not a small application... to a C64. I've got over 2 gigabytes of flash memory and at least 128MBs of RAM just on the handheld devices -in my backpack-, all of which more than adequate to run an AJAX client.

AJAX has already failed (0)

Anonymous Coward | more than 9 years ago | (#13358300)

Running arbitrary javascript is a security liability, which is why many people have it disabled. Whoops, there goes your latest buzzword.

TBL has one vision for the future of the web and AJAX proponents have another; "The web for drooling moron consumers, forced to use javascript and hence endure DHTML popups". The real future lies somewhere imbetween, without everybody attaching semantic metadata to every digital item and without clueless buzzword-weilding CTO's expecting to run arbitrary code on end users desktops.

DOM 3 (2, Interesting)

mov_eax_eax (906912) | more than 9 years ago | (#13358302)

What i learned with the painful development with javascript, is that standards are good, using the DOM model instead browser specific extensions is a good thing, better compatibility, the API is more stable, for this reason i think that the right thing to do is embrace the Document Object Model (DOM) Level 3 Load and Save Specification standard [w3.org] for asynchronous communication instead XMLHttpRequest.

Changing my tune (3, Interesting)

cbare (313467) | more than 9 years ago | (#13358365)

Rich web applications... what a great idea.

I've been telling clients for years (since about 2000) to give up on any grandiose ideas of a highly interactive web site. Javascript and DHTML were just hype and didn't work worth a shit in the real world.

Ironicly, my main example was Google... a dead simple interface that lived within the limited means of HTML and was still extremely usefull. Nowadays, Google is leading the way into more interactive web applications. So, I guess it's time to change my advice.

Still, AJAX is basically a dirty javascript hack to achieve rich interactivity in today's browsers.

I hope the evolution of interactivity in the browser doesn't stop here. It seems like there's got to be a less hacky way. One good thing is that the use of XML should allow client side technologies to evolve independently without having to rewrite server-side code.

Anyway, it's about time!

AJAX vs VNC (0)

Anonymous Coward | more than 9 years ago | (#13358373)

Five years ago I thought that something like VNC would become the preferred way to deliver server-based applications (email, for example) to thin clients. Instead we have AJAX. Why? I think that until recently network latency was too slow to use VNC from one side of the planet to the other. As a result we got HTML-based solutions which require less frequent round trips, but are less flexible.

Home broadband speeds are now fast enough that VNC-like "webmail" could be a good option, but maybe it's too late: we have already gone a long way down the HTML route, from which AJAX is the evolutionary development.

From the server perspective, AJAX is also easier to make lightweight: it's currently quite a challenge to support thousands of simultaneous VNC sessions without using vast amounts of RAM. Maybe some smart programming could solve that.

I'll just mention my favourite AJAX application, Anyterm: http://anyterm.org/ [anyterm.org] . It uses an Apache module to implement a browser-based shell. Great for remote admin through firewalls.

Just developed 2 large AJAX-enabled apps (5, Informative)

mflorell (546944) | more than 9 years ago | (#13358384)

I just finished about 4 months of work writing two AJAX apps using PHP with javascript and while the end result is what we were hoping for and the app runs beautifully, it took me a tremendous amount of time to code it as compared to a standard fat-GUI-app that runs on the client machine.

I basically did a port of the functionality I had in two Perl/TK apps, but I wanted portability and easy updates of code and I had just done a stress test of AJAX in Firefox and IE and they both seemed to handle the load OK so I started developing.

I did not use any tools aside from a text editor and the browsers to test in. The tools like SAJAX just created bloated code that crashed the browsers once things got too complex for them so I decided just to hand-code it from there on. I built in some session security and user authentication both of which ended up working rather well.

These apps are querying other pages to get updates on phone system extensions statuses(from Asterisk) and other bits of information and updating DHTML elements constantly, so they do generate a lot of HTTP requests and use at least three times of the bandwidth that the fat-client perl/Tk app used to, but the database and web server seem to take the traffic OK and we thought that both of the browsers did too until we did some time tests.

We were able to leave the AJAX app running in the same Firefox session for over 2 weeks before we had to reboot the machine for other reasons which was wonderful and much longer than we thought. But, Internet Explorer never lasted a day. It seems that in the ActiveX element that handles XML requests(IE itself doesn't do it internally like Firefox does) there is a memory leak and within 2 hours our app was chewing up over 120MB of RAM and was getting slower. We tried several fixes and the only way to get the memory back was to kill the iexplore.exe process(This was on IE5.0 through 6.1). And that is the reason we recommend only Firefox for intensive AJAX apps.

In case anyone has read this far, the apps are GPLd and available on sourceforge. They are apps that extend the functionality of Asterisk PBX phone system extensions. You need to have Asterisk and the astGUIclient suite installed in order to test them:
astGUIclient project page [sf.net]

MATT---

Problem is... (1)

TarryTops (888130) | more than 9 years ago | (#13358402)

There will be so many cool things that eventually the most cool thing will be to make/design/invent an uncool technology. That said, I like AJAX(remember I'm with the herd!)
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?