Ajax is 99% evil
javascript
Introduction
Ajax is the new gray for quite some time now and it seems that nobody wants to be left out. Everywhere ajax is popping up, it is being used for good and, in a lot of cases, bad. Most of these implementation errors are being made on two separate fields, development and design.
In this post I will try to clear a few things up, to prevent some of the most common errors to be repeated.
Mistakes
Ajax has been the new gray for a while now and like every hype, it has made it's way into the mainstream. In part this is a good thing, as many sites and applications are being made to better the users experience, are the not. Unfortunately not all of the ajax implementations are being done right and a lot of them make the same mistakes. In this post I will try to let you see the mistakes and the (both imho) easiest or even wisest solutions.
Being cool
The problem
First we start with the most common design and development mistakes being made, trying to be cool. Many people add ajax to there application or website without thinking, just to get on the ajax wagon. To be fashionable, to be hip, to be cool, to please the unknowing client or project manager that kept asking for ajax, or some other reason that I don't know.
Don't get me wrong,I see a lot of application and websites that use ajax very good, to bring a better user experience to their user, not to show off some skill of the developer. I know, it is a fun thing to do, showing off, that is, but please don't do it...
In my opinion, ajax is old technology, so why bother with it, in order to show of. So you can implement xhr and manipulate parts of your page without a page refresh. So what, we could do that back in 1999, thanks to Microsoft, lets not forget that folks. So being cool by implementing a 8 year old technique invented by the big bully of the web, I don't think so.
Now that we settled this, lets look at the truly cool things about Ajax.
Ajax lets your users save time, if implemented right, that is if designed right. Implementing it right makes sure that it degrades gracefully, works in all modern browsers and doesn't throw javascript errors or memory leaks. All of that is not that exciting and almost easily done. Take on of the, more and more, mature javascript libraries or pieces of code by gurus like PPK and modify them to fit your need. So now we settled the issue, the technique called Ajax is not cool.
The solution
Be humble, make sure that it is all about the user, not about the developer. In order to help you, hire a user interface designer and a requirements analyst to find out what your users really want. In that way you are using the technique to benefit the user, the way it is supposed to do. The technique ajax is not cool, enriching your users experience is. To do this you first have to know who they are and what they want. If you have a small project and do not have the means to hire a special someone to do this, hire someone who has at least a bit of knowledge of user interface design and let him make up persona's to work for.
Frameworks
The problem
In my daily work I work with a lot of talented people who can work wonders with java or .net code. Very smart developers who can make the back-end of an application or website get you coffee and wash your car. There is a certain part of their work where they (or at least 95% of them) try to stay away from. The big and bad Frontend piece of their application, all of this kiddy stuff like html, css and javascript is simply not worth their attention. They are, after all, serious programmers and can not be bothered by this stuff. So to avoid that they use frameworks like ajax4jsf and similar ones on .net or jsp. In this way they can satisfy their clients, who demand Ajax, and still keep their hands clean.
What they do not know, or want to know, is what kind of code those frameworks generate. And that is what a user uses, with all of it's quirks and minor annoyances. Most of these frameworks that I have seen, have never heard of unobtrusive javascript for instance and write lines and lines of javascript into your html. There is also absolutely no separation of structure, presentation and behavior in those frameworks, at least not that I know of. For the most occurrences this will not be a problem, but in the case that it is, solving problems in a framework that you use like a black box and have no knowledge of is not easy.
This is extra strange, as I have seen those same developers, who do not try and learn anything of the front-end, leap through hoops in order to learn a new java framework. So they are willing to learn, but perhaps in a constrained way...
The solution
The solution to this problem can be found in a couple of ways. If you insist on using frameworks, study them thoroughly and get to know them really good, if you don't do that, you place yourself in a really fast car, without a steering wheel. As you have the speed of development by using a framework, but without a thorough understanding you don't know where you are going. Most jsf frameworks that I know are open-source, so you can improve the framework and give that back to the community. In that way you solve the problem not only for yourself, but for colleagues around the globe.
If you really take your job seriously, go out and learn javascript, css and html. There are enough resources on the internet to help you make a running start. You don't have to be an expert at any of these, just learn enough that you can implement xhr with a javascript library like jQuery. If you can do that, you have more control over things when they go wrong and trust me, when you deal with browsers, things have a tendency to go wrong. Plus you have another technique at your disposal, which can't hurt either.
Ajax vs Dom-scripting
The problem
When people turn to frameworks to do their ajax magic, another problem tends to pop up. Since it is so easy to do Ajax like stuff, people tend to over use their ajax thingamagics. Using ajax to disable or enable a formfield for instance, because it surely looks like ajax. What happens here, is that people have to little understanding of the front-end that they assume that everyone that has to do with manipulating the front-end is ajax.
What they not know is that there is more to ajax than just manipulating the dom, ajax is about communicating with the server and then manipulate the dom to reflect a change in that same page, without refreshing that page. The main difference is that people confuse domscripting with ajax.
That confusion comes from not knowing what your framework does, from not knowing what goes on at the front-end of your application.
The solution
For this you have a simple solution, simply learn the trade. Go to sites like alistapart for your basic front-end knowledge, ajaxian for everything ajax or many more like those, hey you may even pick up a thing or two from my site... Basically, take the solution I offered for your framework problem and work with that.
Conclusion
So here we go, I added my two cents to an ancient discussion in the web community, hoping that maybe some back-end developers will pick it up.