I have used RAD tools for windows and web development for many years (primarily Infragistics). I invariably find myself in some situation where I have a very difficult time figuring out what is going on because these controls have layer upon layer of indirection and abstraction.

This goes for all sorts of RAD tools, including AJAX update panels, AJAX grids, etc. More than once I have found myself asking "Is this worth the trouble?"

For all the trouble and time I take debugging what often are bugs or quirks in these controls, would it be better to just code my own AJAX? Code my own extra functionality instead of using these RAD tools?

The other problem with them is it keeps us unfamiliar with the technology they are using, for instance I have never done my own AJAX because I have always had update panels etc. But I imagine this would be useful to know.

What is your take on this?

Note: Please don't just say "Well you should try XYZ RAD tools instead of Infragistics...they are better". This isn't a debate on the RAD tool itself. This question is about RAD tools in general, not the merits of the one I mentioned in my question.

  • 1
    Just to clarify, you are talking RAD tools for web development, correct? You have 'windows development' as a tag, but Windows RAD tools are much more mature than any of the tools for web development I've seen. They're very different beasts. Jul 13 '11 at 18:53
  • I'm talking RAD for windows and web. Windows RAD tools may be more mature, but they have so many layers of abstraction it makes it difficult to work with them sometimes.
    – richard
    Jul 13 '11 at 19:33
  • 1
    Can you provide examples of what you are objecting to, then? I dont see how the amount of abstraction is necessarily connected to an IDE. Thats more about framework than anything else. Jul 13 '11 at 20:02
  • 1
    A downvote? Really? And a silent one at that?
    – richard
    Jul 13 '11 at 20:13
  • 1
    those look like 3rd party component vendors. A RAD tool is an IDE, such as Delphi, Powerbuilder, Visual Basic, etc. Jul 14 '11 at 4:47

Okie, so here is the thing that is very very important in situations like these. While the use of RAD tools is not bad, the lack of knowledge on the basics of how they work is certainly bad and this will definitely be an area for one to work upon.

Citing an example from your own use case, while you use the tool/plugin for AJAX requests, what stops you from trying out simple snippets of experimenting the same or similar use case by your own hand-written AJAX java-scripts. It is this constant experimentation and reading materials on how stuff works that will help you understand and appreciate the work you do.

Happy reading, coding, experimenting, and learning!!!

  • I agree with you there. RAD tools make it unnessesary in most cases to learn the underlying tech, and so we tend to not learn it (since there are a million other things that we are forced to learn to keep up).
    – richard
    Jul 13 '11 at 18:32
  • So here is the thing with any RAD tool - it is not meant to save you from learning the underlying technology; on the other hand, it does save you big time in automating the grunt work which you otherwise have to do on your own every single time. It is for this reason that I have said you should try learning the underlying technology and do a sample use case so that you appreciate how much of grunt work the RAD tool does and saves your time.
    – karthiks
    Jul 14 '11 at 5:22

In my experience it depends on the control, but for the most part I've found them to be useful. Particularly rich text editors and some of the calendar controls. The only time it really makes sense is when the cost of the control is less than what it would cost you or the developer to build it themselves. In general, the controls are very well tested and have quarterly updates, which is pretty cost effective for the most part, but the kicker is making sure you pick the control because it can do what you want and not because the controls just look pretty or something (which OTS RAD controls do look way prettier than most of us devs could imagine to make them).

  • Pretty looks can affect the bottom line too... Jul 13 '11 at 18:28

RAD tools can be a pain every once in awhile, and I have definitely seen one or two buggy updates that break a build for a couple days. At the same time, these tools often allow you to do things that you would be very unlikely to replicate on your own in any reasonable amount of time. You have your own project to work on, so there is really no need to go off building your own rich textboxes or filtered datagrids, when companies like Infragistics or Telerik pour loads of resources doing just that. The time you spend fiddling with RAD tools may seem like a lot, but it is probably no time at all compared to what it would take you to build the same quality component yourself. And if you are thinking that looks do not matter as long as the controls you build work the same...your customers may disagree.


In my opinion, RAD tools are good for quick development and for a dev team that is lacking a dedicated web developer who knows what they are doing.

Everything that you do with RAD tools can be done in house with jQuery and your own ajax controls. I find that if you are doing stuff that is right out of the box RAD tools can save a lot of time.

But, as soon as you start doing more advanced stuff, you end up fighting with those tools. You need to invest a lot of time into learning the APIs for these tools to make them do what you want.

Some downsides I've found are:

  • The markup that they produce isn't always the best.
  • If you encounter a bug, you are limited to waiting to a new release for the fix.
  • You are limited to what they support. Infragistics, for instance, only supports IE.
  • You lose a level of control over the look and feel. If they haven't provided the CSS or the way to change it, too bad for you.
  • They can be quite expensive depending on the size of your dev team.

Right now, I'm actually working on removing Infragisctics controls from our web app. It has taken me nearly two years to convince my company to do this. We now have a dedicated team of web developers in the company, and there is no longer a reason to spend the money on Infragisctics because everyone on the team would prefer doing it by hand or using a jQuery plugin. We are going to be saving upwards around 20k/year in licensing alone. That's a pretty penny.

If you are going to invest in a RAD suite, make sure it does what you want. Make a page using their demo objects. Find out the ease of use. Look at the markup produced. Make sure you can configure it the way you want. Hit their demo site in all of your supported browsers and make sure everything works. Read reviews, and most important of all look at their support forums; do the devs actually answer questions, or is it just a load of questions with little or no resolutions?

  • Great points all throughout your answer.
    – richard
    Jul 13 '11 at 19:35
  • @Richard DesLonde - Thanks. I've had the opportunity to work with 3 different RAD libraries, and I've come to the point that in the time it takes me to figure out how to do something advanced with any of them, I could develop it myself without them.
    – Tyanna
    Jul 13 '11 at 19:38
  • I am about to get there myself. I am really tired of the layers and layers of abstraction. The IG tools have so many redundant properties etc. it is ridiculous.
    – richard
    Jul 13 '11 at 19:43
  • @Richard DesLonde - I feel your pain. Infragistics is by far the worst library I've used. Naming conventions aren't the same between controls. Controls are slow and can crash the browser if you give them too much data. Client side methods sometimes change from version to version. The number of hours I've spent trying to make their blasted grid work in FF is insane. And the support is little more than a joke. Just terrible.
    – Tyanna
    Jul 13 '11 at 19:58
  • So what is your company doing instead now? Are you just using the web controls that ship with VS and augmenting them where necessary?
    – richard
    Jul 13 '11 at 20:13

I will go on record as saying that abstraction, in itself, is rarely the problem.

Most of the problems arise when the abstraction provided is incomplete, inconsistent, or just poorly suited to the task you're trying to solve. In the case of many RAD tools, you also get problems that have nothing to do with abstraction per se, and are primarily a matter of poor design and/or execution -- buggy tools, poorly managed development cycles, etc.

Web development adds in the (nearly) unique element of designing for an execution environment that's so loosely defined that almost no amount of testing can really give more than a general inkling of what the user will really see/experience on their machine. That doesn't excuse poor quality Web-oriented RAD tools. It does mean that in this case, extreme care in picking your vendor/tool(s) is even more important than usual.


RAD tools vs not RAD tools is a very simple problem.

it falls down to three criteria

  • How tight is your deadline?
  • Do you have the experience to go down the abstraction level chain and do it yourself.
  • How leaky is the abstraction your RAD tool gives you.

If you have the time and experience then the only RAD tools you should use are the ones you wrote yourself. All the other RAD tools will be too leaky.

If you don't have the time nor the experience and you have real deadlines then use whatever you can to get the project meeting the requirements by the deadlines. If you can meet the requirements with the RAD tool do it. You only need to meet the requirements minimally.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.