With modern software development, an application is rarely created completely from scratch. There is a plethora of libraries, plugins, and components that can be leveraged to ease the workload. This has become such a part of our way of thinking, we often don’t notice it anymore. I know that I have found myself grumbling about challenges associated with configuring an application server- without taking the slightest consideration of how difficult and involved it would be to create an application server from the ground up. Although this is an extreme example, it illustrates the point.
With all of these components available for us to use, it changes the way that we engineer software. We have to take into account the advantage of using code that someone else wrote, while also not forgetting the learning curve of the API that comes along with each one.
This changes the idea of modeling our software in clay, or rather from an unformed lump of clay at least. It is almost like we are putting together pieces of the system that fit together nicely, like just like a child (uh…a child…right) might play with a bucket of legos. But we are still need to configure and shape these pieces to work seamlessly together. It is more like we are developing with preformed pieces of clay that can be used to construct a larger system. This concept could be thought of as using “Claygos” to model and develop our system.

For example, lets say that we are going to create ourselves a bright, shinny, and profitable AJAX driven web based application. When designing the system, we already have many, many components to consider using- and consequently learning the APIs for.
So lets start with the what the users will be interacting with. We should think about our user interface design. We could develop all of our nifty AJAXy interactions with the user in JavaScript by ourselves, but why do that, when we can find an easy, out-of-the-box solution that can offload allot of that work for us. There is an ever growing community of user interface AJAX frameworks to choose from. There is the Dojo toolkit, and old time favorite. Then there is the Yahoo UI library- backed by a large corporation that can afford to develop quality products. There is also JQuery, a solid AJAX framework, with many advanced user interface features. But then, there was that time that a friend showed me a site that used Mootools, which had some great visual effects. Oh, and there is the Prototype framework, a favorite in the Ruby on Rails community…and I hear that if your going to use Prototype, then you can add allot of really cool visual effects in your UI if you take advantage of the Script.aculo.us library as an add on. And oh yeah, there is also ExtJs, a library that extends the Yahoo UI library, Jquery, and Prototype. Hmmmmm. This is alot to take in. All of a sudden we have allot of research to do in order to find the right “easy, out of the box” solution to our user interface issues.
BTW- click the comic to view it in at a larger, more readable size.

OK, so lets take a break for a minute from our user interface design and take a look at some of the fundamentals of how we are going to process our data on the server-side. Ah, good ol’ fashioned server side programming. For sake of argument, lets say that we have already decided to develop our application with Java. Lets get started! Well, we should look at any components that will make it easier to process our data, and transfer that data back to the client AJAX style. We don’t want to go reinventing any wheels here do we?
Oh look, there are some choices here too. Should we use DWR, which allows us seamless communications between the server and the client, which hides allot of the AJAX magic? Also, the Google Web Toolkit looks interesting- it takes Java code and compiles it into compatible JavaScript code for use on the client side, which would assuredly alleviate some of the headaches associated with traditional AJAX development. I also remember running accost a project called ThinWire, which seems to be able to produce some impressive results. Yup, that’s right…more reading and possible API learnin’.
So with all of these rich choices out there, and a gang of fanboys (and girls) following each one of them around singing their praises, which ones do we choose to make our application the best that it can possibly be? Also, how can we create mock ups that represent how these external components will make our application look and feel.
These is the question that we will attack in the next section of this series.