A New Kind of Abstraction

Rate this content
Bookmark

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.

7 min
22 Oct, 2021

Video Summary and Transcription

Abstractions in software development build on top of other things and provide utility or make development easier. They can be low-level or high-level, and the smaller the abstraction, the closer it is to the lower level. Abstractions can operate in different environments and their level determines how the code operates and is approached. It's important to evaluate the abstractions used, their portability, and their distance from the low level.

1. Introduction to Abstractions

Short description:

Let's take a break from technical topics and talk about ideas and abstractions. An abstraction builds on top of another thing, like a low-level library or API. It provides utility or a library that makes development easier. Abstractions can be low-level or high-level, and the smaller the abstraction, the closer it is to the lower level. They can also provide escape hatches to the low-level, like importing C modules in Python or returning valid JavaScript objects in JavaScript libraries.

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.

2. Understanding Code Abstractions and Their Impact

Short description:

We need to consider where our code will live and its execution target. Abstractions can operate in different environments, such as the browser, server, or Cloud Functions. The level of abstraction determines how the code operates and is approached. It's important to understand that abstractions are not inherently better or worse, but rather offer different options and considerations. As developers, we should evaluate the abstractions we use, their portability, and how far removed they are from the low level.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2021React Advanced Conference 2021
39 min
Don't Solve Problems, Eliminate Them
Top Content
Humans are natural problem solvers and we're good enough at it that we've survived over the centuries and become the dominant species of the planet. Because we're so good at it, we sometimes become problem seekers too–looking for problems we can solve. Those who most successfully accomplish their goals are the problem eliminators. Let's talk about the distinction between solving and eliminating problems with examples from inside and outside the coding world.
Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Top Content
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Top Content
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Concurrent React and Server Components are changing the way we think about routing, rendering, and fetching in web applications. Next.js recently shared part of its vision to help developers adopt these new React features and take advantage of the benefits they unlock.In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.
React Advanced Conference 2021React Advanced Conference 2021
47 min
Design Systems: Walking the Line Between Flexibility and Consistency
Top Content
Design systems aim to bring consistency to a brand's design and make the UI development productive. Component libraries with well-thought API can make this a breeze. But, sometimes an API choice can accidentally overstep and slow the team down! There's a balance there... somewhere. Let's explore some of the problems and possible creative solutions.
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
DevOps.js Conf 2024DevOps.js Conf 2024
163 min
AI on Demand: Serverless AI
Featured WorkshopFree
In this workshop, we discuss the merits of serverless architecture and how it can be applied to the AI space. We'll explore options around building serverless RAG applications for a more lambda-esque approach to AI. Next, we'll get hands on and build a sample CRUD app that allows you to store information and query it using an LLM with Workers AI, Vectorize, D1, and Cloudflare Workers.
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
Top Content
WorkshopFree
- Introduction- Prerequisites for the workshop- Fetching strategies: fundamentals- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)- Test your build and serve it on Vercel- Future: Server components VS Client components- Workshop easter egg (unrelated to the topic, calling out accessibility)- Wrapping up