Domain: ashleyit.com
Stories and comments across the archive that link to ashleyit.com.
Comments · 10
-
Re:How is this new?
Me too. The framework I used was JSRS. IIRC, it worked by creating hidden iframes on the fly for server-side communication and had dispatchers for PHP, ASP, perl and others. I don't recall if it was asynchronous or not, but pretty much anything can be made asynchronous in javascript by using the setInterval or setTimeout functions. The only thing I could tell was different was the fact that AJAX used the XMLHttpRequest object.
So, naturally I was dumbfounded when people started talking about how amazing and cool AJAX was. I thought, "Hasn't this been around for years?"
-
well, it's complicated...
AJAX apps will replace numerous desktop apps, but not because they're better. Vendors distribute products as Web apps because of a distaste for installing things by IT departments. Not requiring an install on every desktop can mean the difference between getting a sale and not. AJAX allows this to be less of a compromise in user experience, which in turn translates to competitive advantage.
Even in the Web space, AJAX isn't actually better than anything: Flash is arguably a more appropriate rich application platform and can do everything AJAX can. Java is an even better application platform. But I think people got burned by client-side Java when it first appeared and are wary of it now. In addition, turning your Web app into a Flash or Java app requires significant retraining and recoding, while adding some AJAX does not. Thus AJAX is an easier path to a better product in many cases.
AJAX is also not a silver bullet for application functionality on the Web. For example, an AJAX-based word processor can't directly open and close documents on the user's hard drive. While the solution doesn't have to be local file access, the current state of affairs isn't enough I don't think. Also, Web apps are stuck inside a Web browser, which means limited acces to OS-wide features and unfortunate ties to a UI designed for pages, not apps. These aren't limitations to AJAX only, but to anything confined to a browser window.
For the promise of AJAX to be realized on a large scale, some things need to happen. Web app frameworks need to incorporate it more. This has already started to happen with Rails, JPSpan, and others, but the integration needs to be tighter and the standard enterprise development environments need to incorporate it. In addition, AJAX permits much more application-like functionality but the Web only natively supports some very basic user interface elements. A standard set of elements, available to everyone with a consistent look and feel, will both make building AJAX apps easier and make for a more consistent, predictable user experience Web-wide.
Last, it's worth noting that you can do AJAX in earlier browsers than those that support XMLHTTPRequest. It used to be called Remote Scripting, and there's an excellent article on the Apple developer site describing the technique (http://developer.apple.com/internet/webcontent/if rame.html) as well as a library called JSRS that works in v4.0 browsers (http://www.ashleyit.com/rs/jsrs/test.htm). -
Re:browser versions
Look into JSRS it has been around for 5 years and provides full support for everything for IE or NS 4+
-
Re:Correct me if i'm wrong but...
Oops, this is the correct link and I meant DOM<->Server comm...
-
Re:Correct me if i'm wrong but...
Hm, Ajax as these guys mean it, is centered around XmlHttpRequest which IE (6, I think) introduced first (meaning it was a non-standard API). Mozilla actually copied MS, which then made XmlHttpRequest "cool" and we now have this Ajax buzzword business. Never mind that there have been libraries that have been enabling asynchronous DOMServer communication for much longer than Google Maps or GMail...
-
Here's the link to Brent's site
-
Re:Implementation details
This is old hate. JSRS for instance has been around for about 5 years. Checkout http://www.ashleyit.com/rs
-
Re:Repeating my comment on OSNews...
AFAIK, the issue is the DOM/JS integration for individual browsers --essentially you need a standard way to talk back to the server from within the DOM of a page instance, which doesn't exist. Now, there is an excellent JS library that does exactly that, abstracting away the browser-specific hacks (works on IE, Gecko, KHTML and Opera at least). For a demo, go to my site in my
.sig: that's how the automatic ratings work, w/o re-loading the page. -
Re:HTML on Steroids
Let me just point out there are other ways to make more interactive web apps: JSRS is a free JavaScript Remote Scripting library that lets client-side JS communicate with the server: think listboxes or menus that get populated based on button clicks or check-boxes in the web page, without re-loading the page. It works here and now, and on IE, Gecko, KHTML and Opera (not a plug, just a happy developer).
You can see JSRS in action on my newsbot, where it lets you rate articles dynamically without re-loading the web page or submitting forms (in my example the server-side solution is Python Webware, but JSRS is simple enough to get to work with anything, and in fact there are already libraries for PHP, Perl, ASP, etc). -
Use Javascript Remote Scripting (no reloading!)
You should check out Brent Ashley's work with Javascript Remote Scripting (ie: "getting information from the server without refreshing the page")
a client-side javascript library which uses Dynamic HTML elements to make hidden remote procedure calls to the server. It only works asynchronously, but is known to work on Win9x, WinNT/2000, WinXP, Unix/Linux/BSD, and Mac with IE4+, NS4.x, NS6.x, Mozilla, Opera7 and Galeon.
There use to be a real-time chat on his website. And it's all updated without refreshing the page and uses the regular HTML gui. Very neat stuff.