A New Kind of Abstraction

Hi. My name is Mike Hardington. I'm a developer advocate at a company called Ioniq. And I want to talk about abstractions today.

Now, typically, when people talk about abstractions, they normally mean this first kind. Where we have a low level concept, whether it's an API or a language itself. And working with it can be either cumbersome or lead to a lot of potential errors. In the form of user error or code that is very fragile and easy to break.

Now, to make working with this language or this API a lot simpler, what developers have often done is just build something on top of it that allows you to safely work within that run time or within that language. And be a little bit more productive. We're not necessarily creating a whole new language or a whole new library. We're just adding some helper functions. We can kind of think of this like a utilities concept.

Now, while most people find this very helpful, some people decide that this isn't enough. They want more. And so they build another abstraction on top of that. This one including more features, more safety, perhaps new concepts that are abstracting away the lower level concepts, and then so on and so forth. We have this whole entire concept of a hierarchy where there's an abstraction that is n degrees removed from the lower level, whether it's one degree above, one, two degrees, or even five.

Now, with abstractions there also comes some tradeoff. We also have to think about the impact on overall size. The further abstract you are from a given target, chances are you are also going to increase the final code output. You could be including more functions and more code into your project by using the wrong abstraction and bloat your project up pretty quickly. Something also worth considering is whether or not the abstraction also gives you an escape hatch. Now, languages like Python and Lua are built on top of C. They abstract away a lot of the inner workings that C offers but also give you an exit hook so that way if you need to drop down to C, you can do that. You can think of other libraries out there on the web that also offer similar escape hatch. They may build on top of something like Canvas and abstract away a lot of the complexity that Canvas has, but if you need to for performance reasons, you can just kind of hop out of that and get into the native layer of Canvas.

Now these are the traditional kinds of abstractions that I think most people are familiar with. Abstractions also operate on another vector. They can also be thought of as a spectrum, and this is something that once you realize how this relates to the code you work with, you'll see that you've dealt with this more often than you think of.

When we think about spectrum abstractions, you can think about the code that you write and where is that code going to run. The traditional example of is this code going to run in node or in the browser can now be updated to is this code going to run in node, the browser, or runtimes like Dino. All of these have different tradeoffs, and when we think about code that runs in node or code that runs in Dino, they are on opposite ends of the spectrum. They are so different from one another that without having to work real hard to make sure that that code, without having to work real hard and set up complex build systems, code may not be able to run on one or the other. Where if you have code that can run in Dino, chances are you can figure out a way to get it to run in the browser, and if you have code that runs in node, you can figure out a way to get it to run in the browser, as well. These are the kind of spectrums that we deal with.