Rolling Your Own AJAX (Part 1)

As AJAX has grown as a programming paradigm for the web, there has been an emergence of platforms to support development. I was lucky enough to work for a company that got into the web 2.0-game fairly early and was tasked with designing and creating a client-side framework along with some new form controls (the code I’m going through here was written about a year ago). Today, I’ll talk a little about some of the benefits and challenges of using AJAX in web user-interface design.

This was one of those rare projects where we were given adequate time to do a good job, so I spent a lot of time thinking about what some of the challenges were going to be, both for this and future implementations. AJAX creates an illusion of immediacy to the user by bypassing many of the redundant processes of a typical postback. Think about the lifecycle (we’ll do a simplified version) of an HTTP page request on the web.

1. The user makes a request by clicking a link or submitting a form


2. The browser makes a request to the destination web server


3. The browser receives the response as a text stream


4. The response is de-serialized into a document object


5. The page artifacts (images, video files, JavaScript and CSS files, etc) are identified, and latent HTTP calls are made for objects that are not available in the browser cache.


6. The browser paints the HTML page based on the document object and page artifacts

In an AJAX model, steps 4 - 6, are bypassed and the data from the request is simply inserted into the existing DOM. Three fairly expensive and unnecessary processes (because they were handled with a prior request) have been replaced with a lightweight operation. So how does an intrepid developer take advantage of this technological wizardry? Basically, the same object that is used by the browser to make server request is exposed and can be accessed through JavaScript.

It looks like this could get a bit long, so I think I’ll make it a trilogy. In the next part, I’ll dig into the hows and whys of the framework I put together for the aforementioned project, and see where it goes from there.

The Skills that Don't Pay the Bills

The other day I was asked a question by a friend/co-worker about what skills are important to have for a developer today. Reflecting on the question, I think he wanted to know what skills make somebody a more attractive candidate on the job market. Of course rather than answer the question, I went off on a tangent regarding a recent pet peeve of mine.

More and more, I'm finding that .Net developers are losing touch with how things work. Microsoft has abstracted many programming functions to such a high-level, many people in the industry have forgotten (or no longer bother to learn) what's going on under the hood. I suppose this is a natural and necessary evolution; the growth of the talent pool doesn't come close to the expansion of software development and implementation needs. By dumbing the work down with every release, Microsoft expands the pool of workers while fostering a need for the latest software and training.

The result is an increasing gap between programmers/engineers and coders. So my answer to the original question was--try to be the former rather than the latter. In many ways the distinction is subjective, but if I wanted to gauge somebody's programming abilities, here are some of the things I might ask.

• Write a function that sorts an array. Describe it in big-O notation.


• Write the pseudocode for a simple XOR encryption algorithm


• You have a table in a database with 1,000,000 rows and need to extract a single-specific record. What is the maximum number of records that will need to be evaluated to return the required row if the column you're looking at has a clustered index vs non-indexed with unique values.


• Write your own string-builder


• Design a custom cache mechanism

From what I've seen of the job market of late, it's unlikely these things are going to help one command a higher salary, but I think this depth of understanding is becoming a lost art in business software development.

So This is a Blog...

So I've been reading a lot of these blogs lately and figure it's time to throw my hat in the ring. My name is Jeff, and I'm a web software engineer currently living in San Diego, having recently moved from the Boston area. I've been a web developer for the past 8 years or so and have mostly worked in Microsoft technologies on the server side.

Some of the topics I plan to tackle are architecture and design, coding practices, hiring and interviewing, and emerging technologies. I'll also try to reflect on projects and jobs I've had in the past, and compare and contrast working on opposite coasts. With any luck, I'll stick with it for a while. Who knows, maybe somebody will even read it from time to time.