AJAX
Posted on November 2nd, 2005 in Uncategorized |
I wrote something very similar to AJAX over 5 years ago for a chat system I designed that worked purely on DHTML and Javascript. My idea used DHTML to insert a script tag into the body somewhere with a url pointed to dynamically generated external javascript page which encoded the data going back in the that page’s query params. The cool part is that I could write in the server code to generate the javascript that would modify anything on the users’ browser I wanted to change in the return post. Still works to this day in almost all web browsers (if you can ignore the nasty click sound in IE on every timer post every few seconds).
I have heard a lot of theories to why these technologies took so long to develop or why it wasn’t adopted earlier. Its sort of odd since these technologies have been around for a while and I’ve seen lots of similar models in the past 7 years since DHTML started to come alive. I know a lot of developers that have looked at the technology and noticed it wasn’t the best choice for a lot of the traditional reasons why trusting the client to do things right is a lesson in pain.
The major reason why interest is picking up is Google. Google has the man power and the time to invest in working out the kinks and making it work pretty well. I’m not saying AJAX doesn’t rock but don’t get yourselves caught up in all of its good sides without taking in all the down sides. AJAX breaks the common nature of the web that we expect. You might have trouble with search engines, back buttons in your web browsers, bookmaking pages, browsers getting slower and slower after loading many queries into memory into one page session without clearing (very rare but I’ve seen it), and various DHTML incompatibles from all the browsers. Also AJAX can increase your bandwidth dramatically and make it hard on dial up users (yes, a few are still around). You also have to plan for handling disconnections and server side errors and timeouts when you can’t dynamically update the page while the user is disconnected for a moment. (See more: Wikipedia: AJAX Pros, Cons, and Criticism)
However, if done correctly, you can take advantage of AJAX without hurting yourself. Take consideration of all the possibilities so in case the user can’t support something, you have a fallback. It’s good to design for it in the beginning. One of the best models to do that is (gulp) ASP.NET.
This may be a shocker to some that know how much I love .NET/Mono. Personally, I’m not truly fond of ASP.NET, being a big headed traditionalist for the old fashion amount of control I’m used to getting in languages like ASP, PHP, and Perl. I absolutely don’t think that ASP.NET is bad (although 1.x’s use of non webstandard compliant “features” out of the box is a little annoying). I like having full control of everything from top to bottom which is why I use PHP a lot. I guess that’s mostly because I have the extra time to develop every single aspect the way I want in most of my projects (yes I know I can do the same ideas in ASP.NET but I just like PHP). ASP.NET does offer some very practical design patterns minus a few nasty edges. I have to admit when a site gets as large as I’ve seen in some cases, ASP.NET give you some nice usage options. So, I’m going to swallow my pride here.
If you are going to design a site that you want to model to use AJAX at some point, the best technologies I have found to do the job are technologies that support some type of customizable custom control system and support some type of event driven (or event like) system like ASP.NET does. While I don’t really like postback controlling my forms, a technique similar could be modeled to handle live updates over AJAX, as well as handle legacy users with a method like traditional postback. A few implementations for AJAX do this for you and even some custom controls do this in their own way already.
However, ASP.NET’s built in model could be modeled towards it, its going to be really hard avoiding some types of issues just from the nature of AJAX. I don’t think that you can do it perfectly without doing everything out manually which may turn into a very massive project you didn’t expect.
Tags: Mono and .NET
Add New Comment
Viewing 1 Comment
Thanks. Your comment is awaiting approval by a moderator.
Do you already have an account? Log in and claim this comment.
Do you already have an account? Log in and claim this comment.
Add New Comment
Trackbacks
(Trackback URL)
8/4/2008 at 7:45 am
compare home insurance rates... roost refrigerators reemphasized....