A New Kind of Abstraction

Hello, everyone. I'm Mike Huggington. We've already had a full day of a lot of technical topics. Let's take a break from that and talk about ideas and abstractions.

As someone who came from a non-engineering background, I was taught that an abstraction is this thing that builds on top of another thing. The simplest example is we have this low level library, or low level API, and we just have all these kind of rough implementations of how to get things done. This could be assembly. This could be C for you. This could be a raw DOM API.

Well, people come together and they realize that that is not going to be very productive. They're going to be stuck having to maintain the nuances of a low level API. So they go ahead and they create an abstraction. They build on top of it. They provide either some kind of utility or some kind of library that can sit on top of API and give you a better time developing. People come along later, and they realize that that's a pretty good starting point. Let's go ahead and make something more. Let's make this a little bit more easier. Let's remove this method because it's not really used that often. There's a lot of footguns in there. Let's give you something that's going to be simpler, easier to understand and let you get to build whatever you want.

We sit with this level of abstractions, where we either look at them as being very, very low-level or very high-level, and the spectrum of very high-level to low-level, and this hierarchical spectrum is how we typically look at it. Now, with this hierarchical approach, we also have to consider that whatever is at the high-level might also include more code, whether that's runtime or just in general as a library. It might include limited feature set but still handle edge cases. So the smaller the abstraction, the closer that it is to the lower level, maybe, maybe not. In addition, the abstraction also could provide escape hatches to the low-level. Perfect example, not in JavaScript, but in Python, you can import C modules. You can write some C, import it into your program and have access when you need that escape hatch. Lua offers the same thing. There could be JavaScript libraries that instead of returning their own custom object, they return a valid JavaScript object, whether that's a date or something more. So these are the ways I was taught to think of abstractions and as time has gone on, I've realized that there's another way.

We could think of them as a spectrum. It's not just about how far removed from that low-level API are we operating on, but where is this code going to live? What's its execution target? Is it going to be the browser, server? Are we going to be doing Cloud Functions? Perfect example, Node, Deno and the browser. Is this code going to operate in both the browser and Node? Maybe. Is it going to operate in Node and Deno? Probably not. How that code operates and how that code is approached is just another level of abstraction.

If we use a library that operates really well in the browser, chances are it could run in Deno but we don't know. So how far removed is it from that target? One that I'm really familiar with is the idea of cross-platform. We have one side the web and we have the one side native. Now, depending on where you are, where your team sits, you could be picking abstractions that are one degree removed from pure native or you could be picking abstractions that are one degree removed from just pure web. It doesn't matter if they're – don't look at them as if they're better or worse. Look at them as just being opposite ends of the spectrum.

This is stuff that we think about daily at Ionic where we think we have our abstractions sitting right at the middle. We give you access to the web, but we also give you access to native. Is that a middle ground? Is that better? Is that worse? The answer is kind of up to you, but it's just a different way of looking at what that code is. It's not necessarily better or worse. It's just going to give you the options. Understanding that code and abstractions are less about the performance impact, the actual level removed from low level. It's really about your code, performance size, and where is it going to live. We could have code that works in all of our devices right now, but in a few years, is it going to be able to work there? Are there going to be more platforms where this code can't run because it's using the wrong abstraction? As a team, evaluate what abstractions you are using, what their portability is, and also, how far removed are they from the low level? Those not discounting the hierarchy. I'm just saying, evaluate more on the spectrum.