If you are new to AJAX and want to know all about it, please read this wiki. I couldn't have put it in better words myself.
Now that you have at least some understanding of AJAX, let's look at what we need to be aware of. First of all for those who did not understand the above wiki, here's what it all boils down to. When you write a desktop application, you use at least one additional thread (other than the main thread). The reason you do that is, you don't want the screen to hang due to some complex computation that would eat up all the resources. It is simply bad user experience when the client cannot do anything (cannot even move the window around) because of resource intensive calculations. So what do you do? you create a new thread and do all calculations on that thread without blocking the main thread. AJAX can be thought of as threading (just an analogy, I don't mean actual threading) for the web. You create an iframe and all computations / saving of information / loading of information, you do through that iframe. To the user the screen is not refreshing / hanging up until the next screen loads. That's the basic of AJAX, better user experience. This is turning out to be a big post! so let's get to pain points. We shall leave the coding for another post.
Paint point 1: Debugging - it just is a hell to debug an AJAX application. You obviously cannot put detailed alert messages on the production server, so you have to resort to other techniques like logging of errors in the background (i.e. sending detailed messages back to the server in a background thread and storing that information in a database). Obviously this method could turn out to be very costly if you have too many error messages. Things get even more complicated even in the development environment if you have hidden frames and server side errors happen within those hidden frames.
Pain point 2: Knowing when to stop - this is just plain old experience. Obviously I could have created the feedback / post entry system of this site in AJAX, but what's the point. If my screen is fast enough or if I am not going to save a lot on the server as well as the client, why do it and go through all the pain.
Pain point 3: Training - remember that the world is used to the traditional three tier architecture where you code a bunch of server side files that spit out html code. Even if you master AJAX and write up awesome code, it is going to be very difficult for the fresh kid out of college to understand / adapt to this new world of client side (javascript) hacks.
Pain point 4: Learning curve - (Thanks Lilly) you may be a good web developer but it does not mean you are a good JavaScript developer. With all the drag and drop components that are in the market, you don't have to code a single line of JavaScript (exaggeration) and still have a decent web solution. The first step is to learn JavaScript + DHTML, this should get you ready to learn AJAX.
Pain point 5: Session timeouts - imagine your screen doing most of the stuff using AJAX and the user being idle for X hours causing the server session to time out. When the user comes back and clicks anything, the AJAX code would fail because the server time out. You need to handle all such situations.
Pain point 6: Framework - there are a lot of frameworks that are coming up in the market, but none have reached maturity yet. Which means that if you need something fancy you have to code it i.e. build your own little framework. Remember to build a framework i.e. all your AJAX code in one JavaScript. All other web pages need to talk to this framework to get any AJAX done. If you don't follow this you will have JavaScript code all over the place and it would become a nightmare to maintain it.
The biggest pain point of them all: Not every one can build an AJAX app. I don't mean to insult you in any way, but Yahoo is the best example. They have redesigned their mail application into an AJAX app. The UI looks and feels just like desktop Outlook, but the app is very resource intensive. IE takes a whopping 150 MB and the browser slowly starts to crawl after about 30 minutes of usage. I am sure the Yahoo developers will figure it out and improve it over time, after all it is still in beta, but imagine you getting into a similar situation. Debugging those leaks is going to be darn hard. Which brings another point. Browsers in particular IE have a lot of memory leaks, before you know, as the user navigates around, the browser keeps bleeding memory and eventually comes to a grinding halt.
Obviously security is a key issue and you may be susceptible to a JavaScript injection attack, just like the sql injection attack. You always need to keep security in mind as you code your stuff.
Moral of the story: The aim of this post is not to scare you away. The intention is only to educate you so that you make the right decisions before jumping into the the AJAX bandwagon. My advice, go slow (slower than when you work with any new technology). Do small things at a time and slowly evolve your framework. Eventually you will be a winner by taking one step at a time.
Today when I was typing up my Internet Explorer bug entry, I messed up so many times that I had to retype some of it. I still ended up hand editing the entry from the backend for the hyperlinks and line breaks. At that point I decided I had enough and started googling for a free web based rich textbox. Here's what I found, a real diamond FreeTextBox. It was very very simple to include it in my project and here I am typing away using FreeTextBox with all the possible formatting at my finger tips.
WOW! it works in Firefox too, and no I am not a sales person for FreeTextBox.
When I started working on this website I wanted to create a new logo (title) for it, so I cranked up Sparkle (a.k.a. Microsoft Interactive Designer) and created the above logo. Sure I could have done the same in Photoshop but I chose to learn something new and different.
Anyways the point I wanted to make was when I created the logo and saved it as png file I saw that the background color for the logo appeared totally different in IE than what I had used. Just to be sure I opened the same website in Firefox and it displayed correctly. I thought it may be a problem with png format so I saved it as gif, still the same problem. I finally gave up on it and created two different gif files and hacked up a small JavaScript code that detects the browser and displays the appropriate image. When is Microsoft going to learn to do the right thing I wonder. It's like Girish said in this post "I hate you. But I still cant live without you."
Sparkle is the a new tool just like the Flash tool that targets the upcoming Windows Presentation Foundation. What is WPF, well I think it needs a post in itself but for now you can go here and read all about it.
This is my second attempt at blogging. I had big plans when I had started this website the first time around about a year back. Today I don't want to make any promises to myself that I can't keep. I am going to use this blog to document anything new that I learn over the course of the day so I can refer back when need be.
I completely messed up. I deployed my website using asp.net 2.0 precompiler command line utility without making backup of my work.
When you run the precompiler it deletes all the folders from the destination directory and then deploys the source. Before running this utility I forgot to take a backup of all my blog entries and ended up loosing all the hard work.
Author: Girish Bajaj
Theres a place in my heart, and I know that it is HATE.
For the past week, Ive been struggling with a error in ALL my asp.net applications. I dont remember the error, but the result is that my asp worker process quits preemtively. So i debug this problem for days and find out that an IE security patch is the cause of the problem. Microsoft in their infinite brilliant glory didnt think that a IE patch would cause a server side development box to crash all the time.
Well, Ive gone thru hell and back. There are tons of ppl out there whose apps are failing because Microsoft decided to replace a shared DLL which was being used by ASP.NET and IE and never thought of testing it.
If you go on the net, there are 20 different ways to solve this problem... which includes reinstalling IIS, .NET framework and VS.NET 2003. Suffice to say that it took me 3 days to go thru all the 20 different ways of fixing the error. NONE of them worked. Surprised? Please dont be.
Finally I decided to call up MS support. Guess what - did it HELP? NO. You know, MS support is just a whole load of shit. I called one person and at the end of 5 hrs... YES 5 freaking HOURS... i had 3 micorosft experts on the phone with me trying to debug the problem. Once what was a functional computer (Except for asp.net) turned into a useless BOX which would not load any application and gave me 10 different errors on boot. They screwed up my computer even more than it already was!!
At the end of the 8th hour - one of the guys says. Girish I have some bad news. I knew it was coming. I told him bye and shut the phone.
For the past 2 days, Ive been reinstalling my computer and getting everything back to where it was.
IM NOT HAPPY with MS right now.
But i know it will pass... and eventually I'll become the same old puppy dog running around its giant master.
Microsoft, what have you done to me?! I hate you. But I still cant live without you.
For the last couple of nights I have been coding the admin module for the blogs using the Site Administration feature of ASP.NET, there was very little coding required to build an entire password protected site using Visual Studio 2005. Everything is drag and drop and few clicks here and there. It simply rocks!!!
Here's an article that explains the concept and takes you step by step on building a password protected website.
https://www.sitepoint.com/article/asp-net-2-security
I know, I know this topic has been beaten to death on many forums, but it still fires up an argument between proponents of both camps. I myself have periodic arguments over this issue with a good friend of mine who is a staunch supporter of Java (needless to say I am a .NET supporter).
Recently I came across yet another article that makes a bold comparison between the two technologies and wanted to share it with you.
https://www.objectwatch.com/FinalJ2EEandDotNet.doc
Little food for your argument hungry brain
Enjoy!
The dates on Longhorn has consistently been slipping for the past one / one and a half years. In fact it has slipped so much that Microsoft has stopped giving any definite dates on the release.
Paul Thurrott has however managed to get hold of some internal schedules at Microsoft that suggest that the Beta 1 for Longhorn is scheduled for Feburary 16, 2005 and the final release is scheduled for May 22, 2006.
Source: https://www.windowsitpro.com/windowspaulthurrott/Article...
If these dates are at all credible it looks like we will finally get to lay our hands on Longhorn much earlier than anticipated.
