Reverse Engineering LIGHT: a learning pattern

But what if we can steal the basic thrust of reverse engineering and revise it for our very practical purposes, in particular for learning and internalizing new frameworks and libraries?

I propose that we can devise a friendlier reverse engineering process to balance out rote ingestion of documentation and make us wiser, more nimble wielders of the seemingly magical methods that come with Vue, React, Angular, Express, D3, Mocha, etc. (I list only JavaScript tools because that’s my jam, but the process I describe could be applied in other languages).

Long story short, the idea is to translate the built-in methods of a framework into bare vanilla JS, even if only in your imagination.

Whereas traditional reverse engineering might emphasize an accurate reconstruction of what’s going on under the surface of a language or software, we’re not so much in the business of figuring out e.g. what developers at Facebook actually did when they built React (though if you’re curious, you can scour the implementation).

You may be thinking, “I already do this. This is how I always deal with a new tool.”

If that’s the case, well done! You probably learn new libraries and frameworks more deeply than the rest of us, but I urge you to introspect, just in case. I think many of us are used to the abstraction step involved in what I’m describing. We’re used to explaining and re-explaining a method to ourselves, devising metaphors for a framework’s architecture, recognizing parallels between methods in one library’s API and those in another…

This mimicry is important, but on its own, it can lead to brittle learning, familiarity without understanding, and fluency with only one or two (perhaps arbitrarily selected) design patterns.

I’m suggesting one extra cognitive maneuver to help us deepen our learning before we get stuck with a pattern, a little exercise to enrich the abstraction. By first analyzing functionality into vanilla logic, and only then investigating how that logic fits into the big picture, we’re less likely to miss an important piece of the puzzle, and we’re more likely to be resourceful when making decisions about our code in unfamiliar contexts.

A couple of tips before you try it

start simple and iterate

Begin by pseudocoding for the most basic use case of a method and only then worry about edge cases or fancy interactions with other methods

failure should teach you something

If you can’t even begin to translate some feature into vanilla code, that should reveal to you (a) something in the library or framework you could stand to brush up on and/or (b) what makes the library or framework special (no truly useful tool should be easily replicated)

And now a challenge:

To start off, try analyzing the logic of useState() — a React Hook — into vanilla JS. The actual implementation of this method is only 9 lines long, but of course, it calls on the useReducer() Hook, which is a bit gnarlier. Comment your solutions…and then challenge yourself to something harder.

Specializing in questions about JavaScript and its appendages

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store