Are RAD tools worth the trouble?

Question

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.

Answer 1

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!!!

Answer 2

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).

Answer 3

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.

Answer 4

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?

Answer 5

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.

Answer 6

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.