The year was 2000 and I worked for a small web-based solution team and we wrote applications in Java. Many people that know me may not realize that I have a development background. I began teaching myself web development before we called it that back in the mid-90s. There were not many things going on then, like happens now. Web pages were written in HTML there was some JavaScript sprinkled in and we were using web browsers like Internet Explorer and Netscape Navigator. You could do some backend things with CGI which was commonly done with Perl, C, or maybe some BASH.
If you needed to have new information on the web page, you either needed to have it already loaded somewhere in a JavaScript object, or you needed to get a new version of the web page from the server. Seems like a waste and it was not a great user experience. This could be mitigated a bit by using frames in our pages, but it was still a full web page getting loaded and really… they were frames.
Around 2000, Microsoft had developed some concepts for OWA that would ultimately become AJAX. However, these things were not widely available and worked only Internet Explorer. I came across a car insurance web site where selecting a value in one drop-down menu would update the available options in another; this seems simple today, but we have AJAX. How did this work? I had no idea, and the site was cryptic. I never reverse engineered, but I came up with my own method that we implemented in our code long before AJAX become commonplace.
Fetch and XMLHttpRequest
If you do web development today, you are rather likely to be familiar with these methods. Single-Page Applications (SPAs) rely on this implicitly. If you have less than 10 years of experience with this, then you likely take it for granted. The whole idea of trusting this model was concerning from a security perspective. How can we ensure that we are accessing a trusted platform?
Onchange, Onload, and Frames
I started by suggesting that frames are just not worthy. To make this all work, I cheated. I used frames. I admit that up front. However, I used them in an unconventional way. If you are still with me, you are surely familiar with the event handlers in JavaScript and specifically Onchange and Onload. If I want the act of changing a value in drop-down A to have an impact on drop-down B, I need to place an Onchange event handler on drop-down A. How does this help?
Within the Document Object Model (DOM), it is possible to traverse up a page to parent pages when using frames and then back down to sibling pages.
This method relied on having a zero pixel width frame. The user never saw the frame and never directly interacted with it; it was invisible. To the user, it did not exist. When the user made a select in drop-down A, the Onchange event would make a request to load a new page in the invisible frame. This request would take the value of the selection and send it off to the page request within the query string.
To make this more concrete, let us say that drop-down A is the country field and drop-down B is the state/province field. Loading all of the state/province data for the entire world would be a lot of data to pass into each page request and most of it would be irrelevant based on the country selection. So, we select “United States” from the country drop-down and in the state/province field we would expect the 50 states, Washington DC, and perhaps territories to be included. To make this happen, the Onchange event on the country field triggers. It says to load a new page in the invisible frame and passes ?co=US in the query string to instruct the application on the server side to give us the desired information in return.
Now, on the server, that page request occurs and the code queries the database backend for all of the relevant information for the US. That page is some minimal HTML and quite a bit of JavaScript. Within the page is an Onload event on the body that tells it to execute a JavaScript function after the page finishes loading. That JavaScript function has an object with all of the expected data and it traverses the DOM to the state/province drop-down and populates it.
Results
I was pretty impressed with myself when I made this happen. It looked cool because you could see it working; when you made the selection, the controlled form field was disabled, but then it would be enabled and it would flicker as it was being populated. It worked in all of the browsers at the time (for some reason, we were still doing our integration testing back to Netscape Navigator 2.0).
At the time, I was working on the team that was adding new features and bug fixes to the production product. But the news quickly traveled to the lead developer who was building the framework that would be used for the next version of the product; a complete rewrite. He called it a “hack”. Now, I have ton of respect for him; working at that company and seeing what he built gave me a huge head start. We were doing DevOps there in 2000 before it was called DevOps. We had dynamically built test and dev environments spun up on demand. We were checking our DML into repos. Reflecting back, it was awesome. Was it a hack? Probably. It was still impressive and it would have been nice to have heard that.
Back to AJAX
AJAX would not be formalized for years to come. AJAX simplifies all that was required to make this work. We have moved from complex JavaScript on both sides to a simple call on one side and a response of progressively simplified data. It began as XML, but now we commonly use JSON and we may move on to YAML or something else.
Why Does This Matter
Creating value requires experimentation. Mike Pfeiffer has been talking about his time at Amazon and listening to Jeff Bezos say, “it wouldn’t be an experiment if we knew it was going to work.” There has to be room for failure; it has to be safe. We have to create situations where we can have a failure that is low impact. We do this by making small iterative changes and implementing testing practices that catch more of these things before they reach production. However, they will not all be caught. Creating value is about doing something that was not being done before. Be open to changing what is.
Dustin Dortch 