Kristin Reddington

A coder's diary

The Beginnings of Demystifying Javascript

These past couple of weeks, I’ve attended a few awesome meet-ups related to both vanilla javascript and AJAX. With Ruby as my first programming language, I often doubted my Javascript skills and avoided its convoluted kinks. That was until I learned what was actually going on “under the hood”, so to speak, and can begin to demystify this incredibly powerful yet initially quirky language.

I’ll be honest here- I’m guilty at using many methods at a very high level and barely knowing how they work, but that they do what I need them to do when I need them to do it. Yes, a very honest statement and very, very bad programming practice. Take for instance the fetch API used in Javascript. I knew that it was “fetching” data that I needed from my endpoint or external API but had no idea what was going on within those milliseconds it took to grab that handy data.

At the most basic level, fetch is essentially making an HTTP request that relies on a promise, which is much like a callback. A promise is a placeholder object for the eventual result value of our fetch method or reason for error will manifest. Now, what happens next is dependent on the execution context of your program. Normally, there are two different functions you can call, then() or catch() depending on the state of fetch. If it’s fulfilled, then() is chained to handle any asynch actions that need to happen with the data object fetched from the API. That then returns another promise, which is handled by synch or asynch actions once again.

One thing to note about fetch() is that we use these promises because of Javascript’s single threaded nature. We need a “placeholder” browser object to hold onto the data we need while our code executes so that way we can use this data to make another request if need be, instead of directly handling the result of the initial request.

Asynchrony in Javascript is tough because of the language’s innnate single threaded execution, but once the mystery of fancy browser APIs like fetch() can be demystified, we’re able to do cool things like make multiple data requests in a row and have our request send us the callback instead of including it in our original function parameters. Pretty cool if you ask me!

React / Redux

I’ve always been completely fascinated with how things work. I love things invisible to the naked human eye: human biology, the physical laws, neuroscience, etc. have always lured me from their intristic principles and in-depth research. For this reason, I was intruiged by React due to the instant rendering of the UI without a visible server rendering. It makes sense that constant calls to the database can be taxing on an application and the sophistication of React combined with Redux challenged many things I have learned about good coding practices up until this point. But, I was already sold by how it worked - like invisible browser magic.


When I read Jesse James Garrett’s “Ajax: A New Approach to Web Applications”, it blew me away how much Ajax was resonsible for a revolution in technology, and how I barley remember a world without it. From Google to Uber, almost every technical interface I engage with on a daily basis relies on the power behind this paradigm of multiple technologies working together.

Riding the Rails

I smile when I think back to creating my Sinatra project, B.R. (Before Rails) time - oh, how times were simple yet unscalable compared to the world of Ruby on Rails. I entered Rails in naivety, thinking I would just switch some syntax and conventions around and transition to the Rails track with greater ease than going from my old 2000 Honda Civic to my 2017 Volkswagan Passat with an upgraded engine and Bluetooth for my convenience. However, unlike cars, frameworks require a bit more competence other than the muscle memory needed to drive any automatic car you get behind the wheel of. Lucky for drivers, we don’t need to know much about the automotive mechanics in order to be an efficient driver. As programmers, learning the technicality behind Rails magic is not only encouraged, but necessary while using this complex yet brilliant paradigm successfully.