Slashdot Mirror
Building Richly Interactive Web Apps with Ajax
FalsePositives writes "Ajax: A New Approach to Web Applications (from Adaptive Path and via Jeffery Veen) introduces their experiences with what they are calling 'Ajax' as in 'Asynchronous JavaScript + XML' aka the XmlHttpRequest Object. It is used by Google (Google Maps, Google Suggest, Gmail), in Amazon's A9, and a few others (like the map of Switzerland spotted by Simon Willison). ... Is this 'The rise of the Weblication'?"
No more cutesy terms, please.
Is Ajax compatible with the Odysseus web security tool or will it just cause Ajax to die a horrible death?
I Am My Own Worst Enemy
This site also has a lot of news. Ajax seems to me to be a realy good technology, if google uses it it has to be at least of some use. XML itself it realy good if you use it the right way.
Bits of News Giving you the latest bits.
old technology, noob developers
remote scripting has been around since 1998 with Dan Steinmans DynAPI, then Brent Ashley published his remote scripting and a plethora of remote scripting projects popped up on sourceforge
the only thing new here are the developers/kids calling it Ajax when its nothing new or original at all, not to mention MS has had remote data binding on elemnts since IE4 !
sheesh
Even more stuff to learn. As if high school wasnt mind numbing enough.
Soap box, Ballot box, Jury box, Ammo box. Use in that order.
Defining Ajax
Ajax isn't a technology. It's really several technologies, each flourishing in its own right, coming together in powerful new ways.
It's like the marketing folks went plumb crazy generating this ad that was posted onto the slashdot front page.
Tell me: how is this news?
yet an other buzzword?
Webplication? Please.
it's a shame we don't have a standard web-app framework yet, because i've seen some pretty cool stuff done with XUL. i keep thinking "man, it would be awesome to have an XUL based webmail client. or an XUL based search engine" .. etc etc. hopefully what-wg will change things, but it's a shame to see all these competing web app libraries now because it really makes universality impossible
- tristan
an "oldskool" web developer grumbling about newskool kids who don't know what it was like back in the Real Days. Why, all we had were radio buttons! And they could only tune in AM! And we liked it that way!
Sometimes seventeen/Syllables aren't enough to/Express a complete
Isn't that a cleaning powder?
Ajax is not meant to be used on windows.
Maybe I'm missing the point somewhere, but if you really want something on the web to feel like an app, why not make it a Java app that runs in the browser? With all the different browsers and how they each handle Javascript differently, I much rather write something in Java and know it will almost always work on different platforms. Anytime I have to do something in Javascript, it almost always feels like a hack. I can't imagine writing something like the stuff Google does in Javascript. Is there really an advantage to doing stuff this way over the Java way?
SIGFAULT
Wonkavision? No, not television....Wonkavision.
Weblication? No, not web applications... Weblications.
Yeah? Well I think you're overrated too.
Isn't the OSS model built upon the Darwin model?
Anyway, welcome to the Netscape vs IE wars redux.
Webisode, Weblog/Blog.. feel free to suggest more
Don't get me wrong I love the gmail interface, and for rich GUI applications where interaction is the rule rather than the exception this seems like it could well become popular.
But the devices which are going to be accessing the web in the future are not all going to be PC based devices, and the overhead of client side layer does not seem worthwhile.
If you want to be read anywhere in the world on any device, needing a javascript "engine" running in an iframe simply to say "hello world!" seems like a mistake.
i'm trying to give up sigs.
your customer/visitor is just as likely to be using a 3gHz super duper PC straight out of the box as a 400mHz "Email checker" grade computer. Your server is the only thing you really have controll over, it is nice to see people switching to the model of "Catering to the lowest common denominator"
Read More... | 6 bytes in body
Six more bytes? I HAD to click through...
One man's -1 Flamebait is another man's +5 Funny.
Apple developers have posted a useful IE/Mozilla/Safari demo for parsing iTunes RSS feeds with explanation . I used their demo code to very easily add a much more seamless 'add to cart' function to a site I'm working on.
How far from a fully web-based productivity/home software suite with nothing but a good browser and a videocard on the other side?
Think about it, sell a tiny commoditized PC-like box with nothing but a browser and media player, all in firmware. Then sell a monthly subscription service that provides a Javascript-based rich text editor, webmail client, calendaring, and even a basic photo editor. All the user files never leave the server, accumulating there like in Gmail. And yes, all of this is possible already - that's just what the article mentions.
With enough capital to fund the hardware (which could and should be sold at a loss), such vendor could make a killing off the monthly fees. And if you think that people won't trust a server-based file store, then consider how much sensitive information people already store in their Hotmail/Gmail.
http://zero-to-enterprise.blogspot.com/
I RTFA (I know, I should burn my /. membership card), but I got the feeling that the entire article could be summarised in a paragraph or two. There was a lot of handwaving, and not enough nuts-and-bolts stuff. I was looking for simple examples, etc. but other than links to Google's myriad offerings, there wasn't much else.
The Fine Article talks about several elements working together to pull off this new stuff. One of the technologies is "dynamic display and interaction using the Document Object Model".
So if DOM is essential to the "display and interaction" (that is, the user interface), what does that do to non-Windows users? When they browse, do they just get nothing? Or do they get a crippled user interface?
That is sooooo last month...try to keep up will ya? :)
-matthew
"THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
Can Mozilla integrate these apps better? From what I understand there's a lot of JavaScript going on to talk to the server, parse the results, etc. Could some of that be moved into custom reusable libraries in Mozilla / Firefox which the Javascript (Ajax engine) utilizes? I've noticed that Google Maps can take a heck of a lot of processor overhead. I imagine a lot of that is Javascript parsing which could easily be moved into compiled libraries.
It would be very interesting to have these applications work better (faster, more smoothly) on Mozilla based platforms, and degrade into a portable Javascript-only implementation on other browsers such as IE.
When I login, my user name doesn't show up on the first page. I get weird trailing characters like "-×oe" after the story, and I can't see my user info page. Is Slashdot broken (again)??
I am scientifically inaccurate.
one can only hope...
It said, "Nothing to see here. Move along."
I don't understand why developers still look at HTML fix ups to make web applications rich. Especially when a tool like Macromedia's Flash allows a developer to build a rich web application with a clean interface that truly mimics a desktop application's. It offers a small foot print, interactivitey, mantains state, and can work with eneterprise backend logic (Web Services, J2EE, ASP.Net, and Coldfusion). Better solution hand down.
If your interested I wrote a short white paper on why its the future of web applications at http://www.jasonmperry.com/.
The cynic in me says that this guy took a good look at Google's innovation and gave it a name:
In this quote, read "doing our own work" as "invoking view source".
But really, the greatest source of household dirt, smut, filth, and sewage is, yes, the INTERNET. Therefore, coming RSN (like most apps are):
Ajax Web Development! We keep the internet clean!
Brought to you by:
The Vast Right-Wing Conspiracy
Household Products and Services Division
Thanks anyway. You kids have fun. My browser will ignore your site(s) until I'm literally forced to use them.
Then, they won't work right unless I use the browser you developed it on... yea, Google maps, that's great, it works with all the Javascript-supporting browsers out there, right ? ( btw, that was sarcasm right there )
Besides that, what really gets me is- hey, you're going to wait for some server process at some point anyway, right? What's your glorified Javascript doing besides displaying a "Waiting for server..." dialog anyway? Yea, real useful...
Is there a different portable filesystem type they should be using?
--
the strongest word is still the word "free"
Isn't he describing something like the Echo Framework?
Hey look, a web framework that uses javascript to dynamically update itself! It's only been around at that website since 2002.
I developed a web server with Comet abrasive cleanser. It makes you vomit and makes your mouth turn green, it's awesome.
It's a show about nothing!
Does anyone know if their licence is GPL compatible?
Are we going to start seeing /. editorial spots up on ebay or what? geez
Not only do Google mail, Google maps and several of the other examples feature pretty impressive interactive user interfaces, they also work just fine on FireFox. And on Linux. And the servers aren't tied to any particular OS either.
The ability to deploy full featured apps hosted on AnyServer(tm) and usable on AnyBrowser(tm) can't make Microsoft very happy.
~~~~~~~
"You are not remembered for doing what is expected of you." - Atul Chitnis
You don't need to tell the user to "install the javascript run time environment."
User: "Install? What does that mean?"
There should be a project that unifies these things together and allows programmers to code with a single language/tool and handle the browser differences, etc. Perhaps there already is? This would be very powerful, perhaps it can be approached as a XUL to Javascript 'compiler' of sorts
-ashot
This article describes an architectural concept NOT an actual technology. AJAX, is similar to Client-Server in that it implies a mode of development for a given network topology and NOT an actual toolset. The richer interaction of remote scripting techniques will provide a significant challenge to XFORMS as it will be unable to compete with the functionality. XFORMS is what web driven apps should have been in '97, the new class of techniques using Javascript,CSS,xmlhttprequest and other DHTML tools are the way forward.
What will they search now? I can't see many sites, especially shopping sites, powering their interfaces this way. Suddenly they'd lose all their search engine hits and PageRank becomes that much less useful. Sure it's good for the likes of email sites and interactive maps, where the data wouldn't be indexed much anyway.
Call me ignorant, but isn't the ability of HTTP version 2 supposed to act as the intermediary between calls to the server without re-posting an entire page? I thought this was where browsers were headed, like ASP.NET's "SmartNavigation" @Page directive? Please educate me.
--I smoked my sig.
we're coders, not artists. (Flex or no Flex)
And Flash is expensive to buy, IDE wise.
HTML, Javascript and XML can all be developed on whatever text editor you like.
Adaptive Path Services: "We evaluate your site and offer detailed recommendations."
wait wait, this is rich, let me get this straight: a web design company wrote a article saying what you're using now is the "old" sucky way and their new stuff is the way to go??
hold on! this is revolutionary! ;)
Not that AJAX isn't great, i'm sure it is, but this is like reading a article on how great a new car is that was written by the manufacture. Perhaps a more unbiased article needs to be submitted before I believe it.
oh and mod me +5 flamebait cuz i have so much karma i'm sniffing clouds.
my karma will be here long after I'm gone
Now you can write your web apps to remove tough dirt and grease and it'll leave your websites sparkling clean! It's grease cutting algorithms even come in a lemon fresh scent!
Web developper needed, must have 5 years experience with AJAX
I love HR departments...
Mostly random stuff.
What has been taken for granted in every client/server application (that the client and server can, well, you know *communicate*) can now be done in a HTML application. ...and there was much rejoicing.
It's a hack based upon unstandard JavaScript extensions, and even when it works, it still sucks for building applications.
However, even though unstandard it is supported by most browsers, and it sucks very much less the alternatives.
If you are forced to develop web "applications" this is probably a very good way (in English: "If you are being forced to eat dung, a good way to do it is to cut of your nose first).
I choose to remain celibate, like my father and his father before him.
Fuck the jews. Heil Hitler!
Eliminate the undesirables!
This is not going away, and only going to get more prevalent online. The real problem right now is the lack of mature, high level APIs and components to develop these types of interfaces. Basically, it requires a lot of nuts and bolts programming to build. Coming soon (watch for it), desktop application like development tools that allow you to build rich, dynamic interfaces, using these technologies.
I don't know about you, but I'd love to have some sample source available to understand better what they're doing and how it all fits together.
So, the real question is this: I'm about 10% into coding a major open source project that I've been spec'ing out for a long time. I'm at a point where I could switch to AJAX to handle things (and don't think it's not *super* tempting), but it's a bit daunting of a task.
Should I do that? Or should I stick to using CSS/HTML + PHP and regular server-side coding, and then move to AJAX in version 2.0?
I love GMAIL, and the benefits of saving bandwidth and increasing the speed seem really enticing. As far as I can tell, the only disadvantages are learning a new coding skillset (my javascript is rudimentary), and limiting the browsers that can use my site down to IE and Mozilla, which is really not that big of a problem.
Thoughts?
I design web pages all day long for internal use on a Tier I Supplier. I have just recently started adding this to my web pages (as of Sept 2004) and surprisingly people appreciate the pages. Most of the feedback on these pages are just as said, "It feels more like an application." There is no constant refreshing, and people greatly enjoy that. The only problem is the learning curve of this new way of doing pages. I have other developers around me that would not even try to use the stuff, but agree that it is cool. While others just cannot grasp the concept of it. I personally love it! Not only is it faster in response time, it is actually easier to program, then the pages that constantly refresh. Go Figure!
Overall, I find this interesting despite some questions (interoperability, etc.). It looks convenient, it looks planned, and I've done hidden-frames work rather effectively.
The article just doesn't SAY much. I want more links, more code, more examples. Yes, it looks pretty, but don't just show me the product, let me under the hood, let me test drive it.
That being said, I'd also like to know if this framework can integrate into others. If you could merge this into Mono, into STRUTS, etc. . . . then we've got something REALLY interesting.
"The Sage treasures Unity and measures all things by it" - Lao Tzu
Not Flash. No matter how great Flash is, it's a plug-in, and therefore a worse user experience. The real question is: now that we are seeing what can be done with the browser in native languages, why would anyone bother with Flash?
Beta was "better" than VHS too, but sometimes market share and de facto standards matter more.
Doesn't this technology already exist?
Is this new technology lower bandwidth, lower latency, more responsive?
Here is an article by John Udell that I found fascinating when it was published a few months ago. It discusses the quasi-rich-client architecture that Google cobbled together to bring us GMail. The really incredible part is that interfaces built on this architecture, consumed in the browser, outperform commercial desktop apps:
I appreciate AP's efforts to assign some greater precision and clarity to this architecture. Up until now, realistically, I figured I had to be tethered to .net/XAML, Mozilla/XUL, or something like Macromedia Flex.
javascript is not renown for speed
PHP is not renown for speed
HTTP was designed as a stateless protocol
Any other 'round holes' anybody can think of, I'm sure the parent has some square pegs going spare.
The technology has been around for ages. Now if only more people would start using it. I was designing dynamic Javascript applications on the web years ago. Using JS and an Iframe. Its really cool works really good and no one but google and a few others are using it. Such a shame really
If you see spelling or grammatical errors don't blame me. I tried to preview but IE here at work borked the CSS
400MHz is far more than enough. I routinely use gmail on firefox on a 166 MHz box with 32 megs RAM running NT4. Takes ff forever to start up, but after that it's reasonably smooth.
that is why it is *new*. It was developed way back but not deployable to a wide audience. Hence you see Googles browser requirements. So it is new as in, new as a technology that can be put into production with actual browser support.
Thats funny, I've been considering moving toward SVG 2.0 ... which provides lots of nice GUI features, PLUS javascript, and native sockets support. (Well in the standard anyway)
meh
Some slashdotters have already identified this technique of using a combination of using javascript, xml, and dhtml has been around for some time (the article even says its mature). It has been refferred to in the past as javascript remoting or dhtml depending on what your talking about. I work for a company with a web database app that uses a similar technique. Our product, Sysbotz Enterprise has been in development about a year now which show you the age here.
I think the big deal here is not some much the technique or the new label they are giving it (ajax). Rather a educational effort to inform developers to thing past the traditional load page, post form, process, return results back to web browser concept of web apps. The web app needs to broaden its abilities and needs to be more interactive which greatly limits its uses.
I don't understand why anybody would use flash for anything? I think I'll target the doom3 VM for client webpages from this moment forth, sure it's not a webpage and not everybody has the viewer installed but that never stopped the "flashers".
My future clients will doubtlessly be overjoyed with their new visually stunning websites, because let's face it, people don't visit websites looking for fast simple textual information so much as to appreciate my artwork.
Why do tech writers feel the narcissistic need to display photos of themselves next to their writings? That is probably the largest photo I've ever seen on one of these articles...and it's an awful photo at that. They obviously cut the baldness of his head off for a reason, and half the photo is of his black on black outfit.
Their whole site reeks of late 90's marketspeak. Slightly interesting article, though.
There is no gravity...the earth just sucks.
http://www.webappsec.org
http://www.cgisecurity.com/
What is SQL Injection?
What is Blind SQL Injection?
What is Cross Site Scripting?
... Where can I learn more? How can I get started with this?
Thanks!
Insert obligatory uninformed "Flash == evil", "Flash can't do and java/svg/xul/html can/will be able to do soon" typical slashdot post, followed by "long rant on how of an annoying animation tool Flash it is because the crappy sites decided it'd be cool to force you to watch one/the IDE isn't open-source/it doesn't suport CPM/other random reason".
So will it clean my counter tops as well as render spectacular web pages?
Seriously, this is all starting to seem like a huge Frankensteinian monster. Technologies keep getting bolted on trying to get to a better user experience on the web. People want applications, but they like the non-deployment aspects of the web. We really need something new. This is getting too much like VB, trying to turn a sow's ear into a silk purse.
I'm tired of spending hours trying to get something done in a web environment that would take me 15 minutes in a traditional client. There should be a better way. There should be something like X-Windows like technology in browsers over HTTP or some such.
It's sad to see that the browser hasn't evoled all that much in the past 10 years.
--
oxurt mocru ducro mia trimar
Isn't that the shipped that crashed and burned in
Flash Gordon?
Cool?
Developing applications using a particular technology because it's cool? Un-f*****g-believable. If you can get something on the web to interact almost as well as a client application it should be considered a miracle of design. The only advantage I see on web apps is that you don't have to install anything on the client PC, and even that's a stretch if you consider the apps that require flash, MSXML or all the different media players.
It's like calling lemmings cool because they invented base jumping.
PS: Yes, I have developed web apps with popout menus and using MSXML to generate SOAP requests for interactive content. It still sucks.
There is nothing so silly as other peoples traditions, and nothing so sacred as our own.
Am I missing something, or is this company coming in late to the party and trying to coin the term "Ajax" as if they started the party themselves? Sounds like marketing BS to me. Just take a look at some of their wording. It's as if Google used Adaptive Path to create their client-rich interfaces:
Google is making a huge investment in developing the Ajax approach. All of the major products Google has introduced over the last year -- Orkut, Gmail, the latest beta version of Google Groups, Google Suggest, and Google Maps -- are Ajax applications. (For more on the technical nuts and bolts of these Ajax implementations, check out these excellent analyses of Gmail, Google Suggest, and Google Maps.) Others are following suit: many of the features that people love in Flickr depend on Ajax, and Amazon's A9.com search engine applies similar techniques.
eTrade SUCKS
Perhaps you have never seen one with .NET development experience"
"At least 5 years
Yes, I know some of these clueless requirements are determined by the HR. Can't they just make a bit sense though?
I'm happy to see stuff like this happening. Being able to do rich web applications without the use of non-web technologies is a good thing. It's open, it's cross-platform, and it allows us to continue using whatever browser and whatever operating system we want.
If this trend continues, it will help to stave off the possibility of a world full of XAML web sites after Longhorn comes out. That's Microsoft's big, final attempt to proprietize the Web, and it'd be bad news for the rest of us.
Seeing apps like Ajax, Google Maps, and A9 is encouraging. Now we need to have someone come out with a development kit that makes it drag-and-drop easy to create sites like these.
Tired of FB/Google censorship? Visit UNCENSORED!
..and it really is beautiful. XML backend, Javascript frontend... deliciously platform independent, fast, and dynamic as you wanna be. Once you overcome some of the cross browser weirdness, it's a breath of fresh air.
(...but if someone says the word "Weblication" to my face I'll have to smack them.)
vk.
vk.
Please, point us to all the apps you've written using this "old technology". Point us to ANY app that uses this technology that is more than a couple years old. Point us to any book that uses this technology. Point us to a library/framework that makes this technology easy to use. The truth is that this "old technology" has a lot of promise. The fact that almost no one has used it in a real app goes to show how immature this "old technology" really is.
It wasn't new when Berners-Lee started working on the web!
somebody should tell this guy who wrote about this in 2002, or some of my old coworkers, who have been doing similar application development using frames instead of xmlhttprequest since about 1998.
It seems like ever since google released gmail, everyone has suddenly been preaching about the next wave of web applications. give me a break.... i don't mean to slam google- the interface on gmail is definitely amazing, and they should be proud of themselves. but revolutionary, it is not.
If I don't put anything here, will anyone recognize me anymore?
Did anybody besides me note that GMail, Google Maps and some other Google stuff does not work well, if at all, using Mozilla?
Methinks that Javascript is the problem. The MSIE and Mozilla versions don't work the same. Plain and simple. The DOM views are just too different, plus all the other crap.
Since I don't use MSIE anymore, at the urging of the US Department of Homeland Security, there's a lot of crappily implemented sites that I just can't see at all.
Phooie!
There you will be guided with baby steps on how to implement a city, state lookup based on zip.
http://www.magicsoftware.com/bin/en.jsp?enPage=Inn erPage&enDisplay=view&enDispWhat=object&enDispWho= tech%5El1%5EseDeveloper&enZone=tech&enVersion=0&en retain=branch&/
;-)
I don't think the web-part (browser-client) is completely there yet... but hey... it kinda works
http://www.ashleyit.com/rs/
More people can see Flash than can see Google's new uber-cool map system.
:P
If the map system were developed with a Flash front end, it would be:
1. More interactive
2. More responsive
3. With a smaller footprint
4. With a broader audience
5. With full browser support
I gather you're a fan of SVG animation, think VRML is still a cool technology, and think Javascript can deal with the "Rich" part of Rich Application Development.
var isRich = javascript == rich ? true:false;
if (isRich)
{
trace("Hell froze over");
}
I like cheese.
Isn't that a mode?
Some good examples of Ajax-type site features using Flash and Javascript:
s how/
a rt?gameId=250 222004
Flickr's slideshow Flash-app -- this one features hot chicks, so don't miss it! Mouseover top and bottom of the slideshow to get the navigation and thumbnails. Slick.
http://flickr.com/photos/zuan/sets/66471/
Orlando Magic's new site - in-frame Flash video and slideshow (Timberwolves did something like this about a year ago too)
http://www.nba.com/magic/
ESPN's Flash-based game shot-charts
http://sports.espn.go.com/nba/shotch
For an even better example of Ajax, try an ESPN Game Update page for a live game (there should be some starting in a few hours).
Another decent example, more along the lines of an app that runs in the browser as you described, is the NBA's live scores done with Flash with a dynamic boxscore, play-by-play and efficiency ratings.
'Thats they exact same thing a banana wrench monkey.'
See my journal. Idiot. How you got an insightful mod is beyond me. You haven't got a fucking clue what you're talking about.
Drill baby drill - on Mars
Plenty of ignorant and inaccurate Flash bashing going on here. Standard Rebuttal.
Drill baby drill - on Mars
Wait a sec... If they trademark "Ajax", does that mean we have to pay fees to use asynchronous processing of XML data using Javascript???
buffering...
HTML Applications (.hta files) are quite good and use basic html and dhtml.
/ hta/over view/htaoverview.asp
See:
http://msdn.microsoft.com/workshop/author
Capiche?
I would be almost completely convinced that Ajax is the solution to the Reload Problem, if it weren't that there is one imperfection: in order for it to work, Javascript has to be enabled in the client browser. Yah, ok, almost everyone has it enabled, but it's not 100%.
Even a small percentage of clients without Javascript is a major usability issue if you're talking about an enterprise web application. I avoid Javascript altogether, not because I don't like it, but because it's not a gaurantee.
And we also have War Rocket Ajax from the movie Flash Gordon....
General Kala, Flash Gordon approaching
- What do you mean Flash Gordon approaching?
- Open fire - all weapons
- Dispatch war rocket Ajax to bring back his body
Cue intellectual song lyrics by Queen:
Flash - Aha - Saviour of the universe
Flash - Aha - He'll save every one of us
Flash - Aha - He's a miracle
Flash - Aha - King of the impossible
He's for every one of us
Stand for every one of us
He'll save with a mighty hand
Ev'ry man ev'ry woman ev'ry child
With a mighty Flash
Flash - Aha
Flash - Ah - He'll save every one of us
Flash! He saved everyone of us!
(And a Ska band by the same name)
Didn't expect that?
;-)
I agree that the main disadvantage is the lack of a free compiler (or even IDE); and the lack of compiler for my preferred OS. I might buy such software (if it existed); though only if the software featured something ~intersting~ beyond the free alternatives.
The Flash language seems to have grown up; the API is implemented in an object-oriented fashion not unlike the JDK; you can write new logic/GUI elements and combine everything into jar-equivalent packages (swf); there is probably nothing you can't do with flash (anymore).
Though Java is certainly more advanced (as a language), a lot more research(!) is done on/with it and there are myriads of java libraries.
So flash might not always be a good choice, but it may be any alternative for a java applet;
actually someone already made what the article describes (using flash):
http://sfmenu.sourceforge.net/
Not overwhelming, but I nice proof of concept.
XUL (combined with some other stuff from the mozilla dev pages; XUL alone isn't any good; basically I am talking about Mozilla/Firefox) is certainly an intersting alternative.
But (last time I checked) the state of docs wasn't that good, several features (including some API decisions) were either broken or being rewritten.
Anything but locally installed extensions are sandboxed (which is certainly a good idea), but the official way of getting certain rights (signed code) wasn't working.
If I were to design a web-app (for a limited user group == I can tell them to install Firefox), I'd go with XUL. But I wouldn't go beyond a (simple) database interface; writing any kind of non-trivial program (think Open-Office) using XUL (or flash for that matter) is simply not a good idea.
SVG is just a graphics format?! I wasn't aware of it including any kind of scripting; am I missing something?
Informed enough
I used the web service "behavior" from Microsoft to acomplish asynchronous behind interaction with a web server. It functions the same way as this AJAX thing. But do you really want to go thru another layer for every single call to the web server? Or just when you first open a page? On another note, MSFT's ASP.NET 2.0 will have a "Client Callback" mechanism that will allow you to do the same sort of thing - make calls from javascript to your web server using XMLHTTP.
I've been working on an app that has a complex (multi-page (from the user's perspective, hiding/showing DIVs is okay), interdependent, hierarchical data) form that I'd like to get and post as XML. The issue I'm facing now is how to build the DOM for the UI and bind it into some kind of JS "controller" that takes events from the view and updates the model or does other controller logic.
XForms does this really well: it's declarative in your view how it (the UI) binds to the XML in your model. I haven't seen a good way to do this using JS.
The other thing I see a lot of in this Ajax kind of model are race conditions: what happens when your XSL finishes loading before the XML needed for the model? All that asynchronicity is nice for interactive stuff, but it's a major PITA for dealing with things that have complex interdependencies. I know very well there are workarounds, but I'm wondering how people tackle these issues.
The thing I see with google, amazon, et al is that all of their applications have rich data that is primarily view only. What I'm looking for are robust solutions that have considerably more complex data that the user can interact with.
That map of Switzerland is pretty cool. All I need now is a reason to want to look at a map of Switzerland..
There's been a lot of talk recently about this kind of thing, but there is also an almost unforgivable dearth of resources on the subject of XmlHttpRequest and its brethren. Can anyone who's used it point out some links with APIs, tutorials, examples, etc that would help in the learning and use of XmlHttpRequest? Thanks.
Lack of eloquence does not denote lack of intelligence, though they often coincide.
--Mike--
I've used XmlHttpRequest and depending on your target audience, you can run into problems. First, it doesn't work in IE versions earlier than 5. Second, even for versions after 5, a few installations had to have MSXML 3 re-installed before it would work.
Like most rebuttals on the Flash question it avoids the most important point. Flash is a plug-in. Using it for interactive Web development is like creating a brochure Web site in Word and then converting it to a series of PDFs that the user downloads--instead of coding it in HTML. It's possible and maybe not even a bad user experience if the bandwidth is good. But it's not the best way of doing things.
The Flash plug-in gained market share because it allowed people to do things on their Web site that they could not with browser-native code. Now that they CAN do many of those things natively in the browser, I don't see why anyone would choose Flash to do them--despite its continued development.
It's not that Flash is useless--it's just that when the same functionality is possible using either Flash or native code, I fail to see the sense in using Flash. I feel the same way about Java applets and PDF files. If it can be accomplished in the browser, why go outside the browser? To me it's not much different from continuing to develop new software for Mac OS 9. Sure, a modern Mac will load the Classic environment and run the 9 app just fine. But why not just write for OSX from the beginning?
To the end-user of the Web, Flash vs. native doesn't matter--all that matters is what they can do on the site. For that reason Flash is in trouble as an interactive Web technology, because all sites are still accessed through Web browsers (not Flash clients). As more sites move toward native development (a la Google), the user is less and less likely to be prompted to download or update their Flash plug-in. Flash is left as a non-default technology choice that must be pushed on the user--as opposed to the unique enabling technology it once was. Technologies in such a position usually don't last long in the mass marketplace.
Another "Rich Internet App" in the same vein is QWAD Chat: http://www.qwadchat.com
It uses XMLHttpRequest to poll a server for chat messages, without requiring page refreshing.
In addition it has various DOM manipulation behind it to have tabs to switch between different chat rooms.
As I've been reading this lengthy discussion, I've started wondering...old school developers that say this has been around forever...but where is their GMail? For a bunch of "noob" programmers, it seems a lot of them are seeing what can be done and taking advantage of it to do something new and inventive. I also realize that some people are whining about it not being compatible with browsers that don't handle all the javascript tweaks and such, but I'm also wondering, why are you crying? No one told you to use a less than compatible "elite" browser. I've seen the Gmail code and the Google Suggest code. It looks to me like people are finally coming around to taking advantage of what has always been right in front of us.
Ubuntu, the way linux should be.
Try Ubuntu FREE! --
I used XMLHttpRequest to build a Remote screenshot generator which you can use to see your site on Safari, MacIE or Mozilla.
It's the best thing to use when you don't want the user to hop through pages of forms/error-reporting/status etc.
With this you get an interactive interface without having to use Flash or similar crap.
We'll see a lot of this in the future for sure, it's just so convenient to built sites with it - and as a user it's really nice to have (near)instant feedback without having to reload.
Server-initiated GUI changes is the real philosopher's stone of "weblications," and overwhelmingly the most important qualitative difference between web and desktop applications. It's the reason why a simple but realtime, multiplayer game is very hard to construct over the HTTP protocol, and without using Java sockets or some alternative communications technology. Everything else is simply smart caching (well, pretty much), as long as the server can't tell the client something. That, or the whole application is actually in the "Ajax engine," which means it's not a network app, but a just-in-time downloaded app.
Even though such a weblication could be stuponfucious, we really should think of the children.
AJAX is just a hype name these guys made up for a set of technologies.
If it uses Flash, it's not true AJAX; the point of AJAX is that it runs on a bare (recent) browser, using only JavaScript, DHTML and XMLRPC, without relying on any bloated proprietary frameworks or plugins.
Btw, as far as nifty AJAX apps go, look at BitFontMaker; it's an old-sk00l bitmap font editor in Javascript/DHTML, which, at the touch of a button, sends its data back to the server, which sends it back in a TrueType font file.
It uses JavaScript and requires client-side support. It also sends XML to the client. In my opinion, the Web should be based on server-side scripting, not client-side. I analysed my thought on my blog.
http://www.adaptivepath.com/images/team/headshot_g arrett.jpg
Imagine him saying - "After all, when was the last time you heard someone rave about the interaction design of a product that wasn't on the Web? (Okay, besides the iPod.) All the cool, innovative new projects are online."
Spooky, innit?
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
I'm excited about this, but also worried that it will be the death of better RIA (rich internet application) architectures. Things like Macromedia Flex, Luxor, Laszlo, etc. all promise to do away with HTML as a UI layout tool. However, this just legitimizes HTML and all of the pain and suffering it causes developers when you start to go beyond simple markup.
I (and my business partner) used this technique 5 years ago to develop the budgeting system used by all Idaho state agencies. It uses IE5 with a few ActiveX controls (grid, custom combo boxes) bound to an XML data source. The result is a rich application-like experience within the browser.
The back end is IIS + SQL Server. The server runs in Boise. Hundreds of users from dozens of agencies around the state manage their complex budgeting process with this app.
XMLHTTP was a key technology in Microsoft's plan to use IE as the business app environment. Databinding to native HTML controls was pretty cool - 5 years ago.
If you want links, try this, this, or this. It's even taught in vocational programming courses.
Well, at least that's what makes GMail, et. al. different/innovative.
It appears they started with a UI design and worked backwards to figure out a way to implement it. If it couldn't be done in IE6/Firefox it got canned, otherwise they pulled out whatever tricks they could to get it working.
Google knows how to gracefully degrade. But the browser wars/innovation have been over for 5 years. They decided to focus on usability and leave the non-compliant browsers at the station.
The marketplace apparently approves.
When we were coding for a new major browser rev every 9 months, graceful degradation was a more useful concept. Today there are basically 3 categories of browsers: lynx, modern, and old-and-busted. They probably never considered lynx and decided to ditch old-and-busted.
If you can measure an appreciable productivity increase for a good UI, how much of that is worth sacrificing for lynx? Graceful degradation may have outlived its usefulness. Somebody's going to have to figure out how to make these apps accessible in another way.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
You don't even need to use ActiveX objects in IE. You can use document.createElement("xml") and use Internet Explorer's built-in XML islands extention to load content, which seems to work even if ActiveX is disabled (at least for me) in IE6-SP2. Pimping my own stuff: I wrote a few journal entries on this topic a while ago. Check out the original article and its update.
It is impossible to enjoy idling thoroughly unless one has plenty of work to do.
- Jerome Klapka Jerome
Or did he just write a book about toilets using "Ajax" as a pun (i.e. "a jake").
that although this may be old school to most of the /. community, I wasn't aware of this approach, and I've been working on a project that needs exactly this kind of interface. So at least this pretentious bastard was helpful to somebody.
Hi, try http://nevow.com and take a look at livepage and canvas. This isn't magic, people.
It's rare that you're presented with a knob whose only two positions are Make History and Flee Your Glorious Destiny.
I don't think Ajax is an actual 'product'. It's just a term for the technique of accessing the model from a javascript/DOM based viewer over an xml based request.
So JPSpan would be classified as an implementation of the Ajax approach.
Yup. I tell you one thing, this is a huge goddamn threat to flash. All the interactivity, no plugins, no breaking of web standard functions (if programmed right). w00t!
vk.
vk.
This stuff has been around for years. Asynchronous XML transfer - flash has been doing that since version 5 (~2000) and MSXML has been doing that since uhh IE 4. It's just now that more browsers support this that some clever bod decided to write a wrapper API to support multiple browsers, and some marketing bod comes along and coins a term and thinks he invented the whole thing. Nothing new here, move along now.
In this world nothing is certain but death, taxes and flawed car analogies.
I don't think you understood my post. I am a Flash developer. Please read my post again with your sarcasm detectors on. Peace, Zeh
Weblicate your applications with Weblets in no time!
I've been working on a such a "rich" app using the Javascript DOM on the front to call SOAP and XML services on the back. I wrote about my experiences.
Been a while since I worked with that
It is not httprequest is important. It is that render the layout in client with xslt.
...
The httprequest together with javascripts can provide the dynamic interface which is not exploited for most of you.
But what make ajax standout is to render the layout in browser (as well as in server). For example, when a user request a big document, the server just sent it to the browser: no paging is done in server, the paging is done in browser. Skip those ugly next, prev,
More important, it works in text only and slim browsers: the xslt just got lost. The pure xml document is present.
I wonder what Macromedia thinks about all this Ajax hype?
You folks might appreciate my "Zuggest" tool It uses the "Ajax" concepts you're talking about and works similarly to Google Suggest but searches against the Amazon Product database as you're typing.
Check it out: http://www.francisshanahan.com/zuggest.aspx