Skip to main content

Overweight Ajax

I came across an interesting article this morning on Ajaxian:  Ajax, Browsers, Running Out of Time.  The crux of the article is that the author's PC consistently gets bogged down if he leaves Ajax-heavy applications - such as Google Mail, Zimbra & Yahoo Mail - up for most of the day.   I can understand his pain, as i have noticed similar behavior with the new Yahoo Mail.  Sure, it's much "cooler" and easier to use than the "classic" version, but it comes with a cost.

This is why I am still very cautious and conservative when using Ajax components in APEX applications.  It's still too easy to create code that just doesn't play nice with browsers.  It's also 100% impossible to discern what else a browser is running when your Ajax component is fired up, which makes it all the more difficult to ensure that your code doesn't step on someone else's.

For better or worse, perception is reality.  If large-scale Ajax applications that the masses use degrade overall confidence in the technology, it will be even harder in the future to convince clients that even the smallest Ajax component in an APEX application is scalable, secure, and a good investment.

Comments

Anonymous said…
AJAX's days are numbered. Sooner or later, something like Adobe's Flex or Microsoft's Silverlight are going to become the norm for creating web-based applications.

Although HTML was never intended to be used for data entry, the browser makers and organizations like W3C have sat idle for far too long by not introducing native HTML widgets that would have filled the large gap that AJAX components now fill.
November 15, 2007 at 2:20 PM
Carl Backstrom said…
>>
AJAX's days are numbered. Sooner or later, something like Adobe's Flex or Microsoft's Silverlight are going to become the norm for creating web-based applications.
>>

bah what do you work for adobe or microsoft?

the problem is you have people throwing ajax at things that have no need for it.

I use ajax everyday and carefully decided where and when to put it, when and where it makes sense and it kicks a...

proprietary formats silverlight and flex /air and truthfully xul are bad.

Why buy into in micorsoft and adobes personal little war when you can just follow web standards. Javascript and html work everywhere even your brand spanking new iphone.
November 16, 2007 at 5:40 AM
Carl Backstrom said…
Not you Scott ;) my comment was for the first "Anonymous" commenter.
November 16, 2007 at 5:42 AM
Scott said…
I'm going to have to agree more with Carl here; there will be some people who go with Adobe and MSFT, but I think that keeping with a standard, portable format is more advantageous.

Ajax is relatively young, and like most young technologies, people do stupid things with it. How many spinning, flaming Java applet logos were there in the 90s?

I also think that people will be hesitant to adopt another MSFT web "standard", for fear of some obscure dependency on IE. Remember what MSFT did to Java?

HTML is simply too common to be quickly or completely replaced, at least in the next several years.

- Scott -
November 16, 2007 at 7:12 AM
mathewbutler said…
I don't have a problem with AJAX per se.

However, I'm still using the old version fo yahoo mail, and given the choice will continue to do so.

Mathew Butler
November 22, 2007 at 11:59 AM
Post a Comment

Popular posts from this blog

Custom Export to CSV

It's been a while since I've updated my blog. I've been quite busy lately, and just have not had the time that I used to. We're expecting our 1st child in just a few short weeks now, so most of my free time has been spent learning Lamaze breathing, making the weekly run to Babies R Us, and relocating my office from the larger room upstairs to the smaller one downstairs - which I do happen to like MUCH more than I had anticipated. I have everything I need within a short walk - a bathroom, beer fridge, and 52" HD TV. I only need to go upstairs to eat and sleep now, but alas, this will all change soon... Recently, I was asked if you could change the way Export to CSV in ApEx works. The short answer is, of course, no. But it's not too difficult to "roll your own" CSV export procedure. Why would you want to do this? Well, the customer's requirement was to manipulate some data when the Export link was clicked, and then export it to CSV in a forma
76 comments
Read more

Refreshing PL/SQL Regions in APEX

If you've been using APEX long enough, you've probably used a PL/SQL Region to render some sort of HTML that the APEX built-in components simply can't handle. Perhaps a complex chart or region that has a lot of custom content and/or layout. While best practices may be to use an APEX component, or if not, build a plugin, we all know that sometimes reality doesn't give us that kind of time or flexibility. While the PL/SQL Region is quite powerful, it still lacks a key feature: the ability to be refreshed by a Dynamic Action. This is true even in APEX 5. Fortunately, there's a simple workaround that only requires a small change to your code: change your procedure to a function and call it from a Classic Report region. In changing your procedure to a function, you'll likely only need to make one type of change: converting and htp.prn calls to instead populate and return a variable at the end of the function. Most, if not all of the rest of the code can rem
5 comments
Read more

Logging APEX Report Downloads

A customer recently asked how APEX could track who clicked “download” from an Interactive Grid.  After some quick searching of the logs, I realized that APEX simply does not record this type of activity, aside from a simple page view type of “AJAX” entry.  This was not specific enough, and of course, led to the next question - can we prevent users from downloading data from a grid entirely? I knew that any Javascript-based solution would fall short of their security requirements, since it is trivial to reconstruct the URL pattern required to initiate a download, even if the Javascript had removed the option from the menu.  Thus, I had to consider a PL/SQL-based approach - one that could not be bypassed by a malicious end user. To solve this problem, I turned to APEX’s Initialization PL/SQL Code parameter.  Any PL/SQL code entered in this region will be executed before any other APEX-related process.  Thus, it is literally the first place that a developer can interact with an APEX p
1 comment
Read more