Developers often look at abstractions as being "the closer to the metal, the better," meaning that as abstractions become further removed from the lowest possible level, the more you give up in terms of performance and features. But abstractions work as a spectrum also. We'll look at how we can adjust our view of abstractions and what kind of examples we can use to better understand that abstractions have less to do with programming and more to do with where we deploy.
A New Kind of Abstraction
Transcription
Hello everyone, I'm Mike Harkington. 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. So 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. 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. 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 that low-level 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 foot guns 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. So on and so forth. 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 run time or just in general as a library. 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. For 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 kind of gone on, I've realised that there's another way. We could think of them as a spectrum. Now 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? For 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. 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. So 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. So understanding that code and abstractions are less about the performance impact, the actual size, the level of 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? So as a team, evaluate what abstractions you're 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. And with that, thank you.
