DEV Community: Ilia

How Not to Lose Yourself in the Age of AI

Ilia — Sat, 01 Aug 2026 19:43:17 +0000

The promise that we'll soon stop writing code by hand is far from new. COBOL was made to look like English so that programs would be readable by more than just programmers. SQL's predecessor was called SEQUEL, literally Structured English Query Language. Then no-code platforms arrived. The amount of manual work really did go down, but programmers didn't disappear. If anything, there were more of them than before.

Now it's the turn of large language models (LLM). For brevity I'll just call them models from here on. And this time we've met the final boss: for the first time, a tool genuinely works in natural human language from end to end. It became possible to write entire programs knowing nothing about programming languages.

That sounds a little frightening. But we quickly reached a reassuring conclusion that only the routine work disappears, and demand grows for the people doing architecture and review. Surely there still need to be people who define the tasks and then check the generated code.

But what are we going to lean on when we check that code? In sheer volume of knowledge, a model already outstrips any individual developer: it can reproduce most known algorithms and patterns, it knows a huge number of libraries, it knows the syntax. No human holds that much in their head. Competing with models on the amount of memorized information is pointless.

And yet they still haven't become a full replacement for a programmer. So our value isn't only in knowledge, there's something else.

What makes us different

The model doesn't have your context.

At least not in the form you have it. Technically, model context windows are already big enough to fit an entire library. In practice the model only sees what made it into the working session. And even when a lot of information fits, that's no guarantee the relevant connection gets noticed: models draw unevenly on different parts of a long context and can miss even explicitly stated instructions.

Rules files and project descriptions help, but you can't pack the whole context into them. You can't fit ten years of experience into a single set of instructions. If understanding could be transferred as one document, we'd have been turning juniors into seniors with a README a long time ago.

So a model can hold nearly all of humanity's knowledge and still be unable to replace experienced specialists.

The model doesn't carry responsibility.

You're the one who gets pulled in on a weekend, who explains to the team lead or the business why production is broken, who fixes the aftermath. And the thing is, responsibility forces you to see where a decision led, and that's where experience comes from.

Someone who once wiped a production database didn't just learn a new fact. They had to live through the consequences, and that kind of experience tends to stick. It's what keeps you from making the same mistake twice. A model, meanwhile, gave its answer and moved on to the next task. As long as the mistake is in the current context it can account for it, but that experience never becomes a durable habit.

So our advantage really isn't the amount of knowledge. It comes out of accumulated experience and our own decisions, out of feedback from reality, out of the ability to notice when something's off, and out of having to answer for our choices. And here, it seems to me, a problem starts to take shape, because all of that is formed and sustained through practice.

How we pick up skills

Understanding used to arrive on its own, just in the course of the work. A task lands from an unfamiliar area, you read the documentation and Stack Overflow, try different approaches, make mistakes, debug. In the end an understanding of the implementation takes shape in your head. You remember the path to the solution, you find your way around the code faster, you can explain the choices you made and answer questions about them.

Working out how a finished solution works and arriving at it yourself are not the same thing. When you look at a completed implementation, it's easy to get the feeling that it's all clear. Then you try to reproduce the same solution on your own and discover that the understanding was an illusion.

A skill forms where you do the work yourself, mistakes included.

These days models increasingly walk that path for us: they break down the task, pick an approach, write the code and the tests, fix the errors. If you only join at the end, it's easy to remain a spectator. The code looks comprehensible, but no understanding of the solution of your own ever appears.

That said, there's no point clinging to everything either. Some skills genuinely can be let go. Why spend effort on things models already do faster? The goal isn't to refuse progress, it's to avoid losing your own understanding along with the routine work.

What's left is deciding which skills to keep and which can safely be released.

What to release and what to keep

I ended up with a single criterion: does this skill help with the things we're still better at than the model?

Release.

Anything you can look up and verify quickly: exact syntax, API details, boilerplate, a ready-made implementation of an algorithm. If the answer takes a minute to find and correctness is easy to check, there's no obligation to keep it in your head.

But it's important not to confuse implementation with understanding here. You can ask a model for the code of an algorithm. Understanding its complexity, its limitations, and whether it fits your particular problem is still worth doing yourself.

Keep and develop.

Everything that accumulates over time: knowledge of the project, the reasons the workarounds are there, the ability to debug, a sense of the boundaries and constraints in your own specific context. Working with incomplete requirements. Working with a team. The cost (in every sense) of one decision over another.

Put simply, what's worth keeping is what you can't get from a single prompt. Which means keeping for yourself the work in which that understanding appears.

What this looks like in practice

Almost any task has at least four stages:

Framing — what we're doing and why.
Contract — what data goes in and out, where the boundaries are, which states are valid.
Acceptance criteria — how we'll know the task is solved.
Implementation — code and configuration.

Framing has to stay our responsibility, because this is where context matters most. We know the business we work for, the history of the product, the verbal agreements and the constraints that never made it into the documentation. Some of that can be passed to a model, but it won't find it out on its own.

Describing the contract is the next important stage. This is where gaps in the framing usually surface and where clarifying the requirements begins. Either we go and clarify the details, or we make a deliberate decision based on experience.

Beyond that, the contract gives a high-level picture of how the feature is put together: what data it needs, what goes in, what comes out, what changes in between. This is where a connection forms not just with the task but with the implementation to come.

Acceptance criteria (tests or acceptance conditions) are better defined before the model writes any code. They're what separates a correct solution from a plausible one.

If the model writes the implementation first and then generates tests from it, it can misread a requirement once and repeat the same mistake in the checks. The tests will be green: they're simply consistent with the code. So the criteria have to come from the framing, not from code that already exists.

In principle a model can be brought into the framing, the contract, and the criteria too. It'll offer options, find edge cases, and argue with the contract you've chosen. But as a second pair of eyes, not as the sole author.

Once framing, contract, and criteria are settled, implementation looks like the most natural candidate for near-total delegation. Everything's decided; all that's left is writing the code. But do that every time and you deprive yourself of practice you need.

Two questions help work out which work to hand over.

Will this task give me new understanding?

If the solution is already clear, the result is easy to check, and all that's left is assembling it from known parts, the work can go to the model almost entirely. But if the approach still has to be found, or the area is new to you, a lot will only become clear while working on it. And the more you delegate in a task like that, the less understanding you come away with.

What are the risks?

The higher the cost of a mistake and the harder the rollback, the less autonomy the model should get. You need to have a picture of what you'd do if something breaks. Here your involvement isn't about learning any more — it's about staying in control of the consequences.

In conclusion

LLMs don’t strip us of our skills, but for the first time we’re at a point where the end result of work can be separated from getting the experience and skills. Previously, getting a task done meant actually understanding it, but now you can get working code without ever going through that process. And the problem is that we ourselves give in to the temptation of staying in the role of the ones who just assign tasks and check results, even though the ability to do that well also came from practice. So I think we need to start asking ourselves what to delegate and what not to, so we don’t lose ourselves.

Web performance case study

Ilia — Fri, 31 Jul 2026 21:44:06 +0000

In this article I want to share my experience running a full optimization pass over a real project, with examples. In this case it's an SPA built with Vue 3, using Vuetify for part of the UI and Firebase for auth.

Some context: I work as a frontend developer at a company that mostly builds MVPs, but also develops and maintains long-lived products. MVPs in particular tend to accumulate problems, because refactoring and optimization get the bare minimum of time, and the same problems repeat across projects, since we often start from the same template.

Measuring performance

It all starts with metrics: to make something better, you first need to know what "before" looked like. I used three tools: PageSpeed, Lighthouse, and rollup-plugin-visualizer (our project runs on Vite).

You'd think PageSpeed and Lighthouse were the same thing, because they use the same engine, but in practice they report noticeably different Performance scores. In my case PageSpeed was consistently 20 points worse than Lighthouse. So which one do you believe?

That's the first problem: any Performance metric is always a simulation, never reality. Your website can work perfectly on real users' devices while the Lighthouse engine tells you the opposite. And the other way around.

But if your website is in production with enough traffic, PageSpeed can help: it has a section showing actual performance based on real user data.

Here's an example of that field data, while PageSpeed's own score for the same page sat somewhere around 45–55, rating every individual metric noticeably worse:

So I think it's worth looking at both PageSpeed and Lighthouse in DevTools. You get far more information that way, and a better sense that both of them only roughly estimate performance by simulating particular hardware and network conditions — affected by things like where the server physically sits.

The next tool is rollup-plugin-visualizer, which shows you visually what your bundle is made of, whether there's anything in there you don't want, and how much each piece weighs. I used it only because Lighthouse doesn't show the bundle tree for Vite (unlike Vue CLI with webpack).

So, here's where we start:

Optimizing fonts and icons

The biggest impact on load speed comes from whatever blocks rendering — scripts, styles, or fonts loaded in <head> that block the render until they've downloaded and executed.

In our case, among other things, fonts and the mdi (Material Design Icons) library had a noticeable effect.

Fonts were setup like this:

Let's see what's wrong with it:

Every possible weight from 100 to 900 is loaded, even though the site only uses 400, 500, 600, and 700.
There's no display=swap, so there's no way to show a fallback font while the main one loads (without it, users see no content at all until the font arrives).
The font loads from an external resource, Google Fonts, so it would be good to add preconnect to those origins and do the DNS/TCP/TLS handshakes ahead of time.

In our case the requests go to https://fonts.googleapis.com and https://fonts.gstatic.com. For the external origin the font itself is downloaded from (for Google Fonts that's https://fonts.gstatic.com), you need the crossorigin attribute — otherwise preconnect will only do the DNS part.

Incidentally, Google Fonts now offers all of this by default, but our project was apparently created long before that.

You can use preload to request the font at the very start of the critical rendering path, without waiting for the CSSOM to be built (by default the browser only downloads a font after it has built the CSSOM). Since the font isn't loaded after HTML and CSS parsing in that case, you may not even need the fallback font at all — which eliminates the layout shift you get when the two fonts don't match in size.

But be careful with preload: you're delaying the loading and parsing of other resources, and you're downloading the font unconditionally, even if it turns out not to be used on the page. So you need to measure its effect on load and render speed and weigh up whether it's worth it.

That gives us this:

The next optimization opportunity is a variable font. In short, variable fonts are "programmable" fonts you can tune flexibly along different axes without downloading each variant separately up front, the way you have to with regular fonts — which drives up both the number of requests and the amount of data transferred.

Google Fonts already has a variable version of Roboto called Roboto Flex, so let's use that:

For comparison, here's how many requests we had with regular Roboto:

And here's how many with Roboto Flex, now that we no longer need to download each weight separately:

Now for the icon library. It's connected like this:

What's the problem here? It downloads a single file containing every icon in the library, even though the vast majority of them are never used in the project.

The fix is fairly simple: instead of the CDN we pull in @mdi/js, which lets you import only the icons you actually use, so only those end up in the final bundle.

Here's what that looks like with Vuetify:

First results

So far we've only optimized how fonts and icons are loaded — but those were contributing a lot to Total Blocking Time. Let's measure Performance again and compare with where we started:

Before

After

We gained 10 points and noticeably reduced Total Blocking Time. But these are only the first steps, so let's keep going.

Eliminating layout shift

As I mentioned in the fonts section, layout shift is, in simple terms, content jumping around when data loads late or changes size and pushes the surrounding content out of the way. It sounds like something that has nothing to do with load speed, but since Lighthouse v10 this metric contributes a full 25% to the overall Performance score (Total Blocking Time is first, at 30%), so you can't ignore it.

Right now the metric is in the red at around 0.5, and the page load timeline looks like this:

You can see that in the first seconds of loading the user sees the site's footer, and only then does everything snap into place. That happens because between the header, the text banner, and the footer there's content that loads and renders dynamically. Until it arrives, the footer takes its place.

The simplest fix — though not always the best one, since the footer then gets hidden below the fold even when the main content doesn't fill the whole height — is to give the main content, which is almost always dynamic, a minimum height of, say, 100vh, so it occupies all the available screen height:

The second, more involved option is skeleton loaders: while data loads you show placeholders that mirror the structure and size of the real content, which also avoids the shift. For now we're going with the first option.

Let's check what effect this had on layout shift:

We brought it to 0, and the overall score is now 56, it's roughly a 10-point gain from one small change. And indeed, in the timeline at the bottom you can see the footer is no longer visible during the first seconds and everything sits where it should.

Firebase

The short version of the problem:

Almost 2 MB of JavaScript, taking up 70% of the bundle. The reason is simple: we're on Firebase 8, which doesn't support importing only the modules you need, unlike the current version 9.

We upgrade Firebase to 9, rewrite our code to match the API changes, look at the bundle again, and… we've gone from 1.78 MB to 310 KB. Still a lot, but 6× better.

But that's not all. Looking again at what gets loaded, we spot an iframe.js from Firebase weighing 279 KB. A bit of digging shows it's only needed for certain auth flows — for example signInWithPopup for Google or Facebook sign-in. We don't use that method, so all that code is dead weight sitting there just in case. Worth removing.

We started with this code, using getAuth(), which pulls in a lot of unused code:

We rewrite it to use initializeAuth() with only the imports we need, and leave a comment for whoever comes next warning them to be careful with the methods that needed that iframe.js:

We check the bundle one more time and there's nothing extraneous left:

Interim results

Last time we were at a Performance score of 56; after the Firebase work we're at 75:

Async components and routes

Looking at the final bundle, you can see that even though we're on the home page it contains other pages we don't need right now — NotFoundPage and TermsPage:

Vue Router supports dynamic imports out of the box, so pages we don't need get split into separate chunks and are requested only when required, instead of ending up in the main bundle. And yes, every other page was already wired up that way — these two were apparently just forgotten or overlooked.

We fix router.js, replacing the static imports with dynamic ones:

By the way, back when the project was on Vue CLI, a side effect of dynamic imports was that each chunk generated a prefetch — and with enough of them that hurt load speed, because the browser had to make a lot of extra requests for things it didn't need right then:

To prevent that, I configured webpack to skip prefetching:

If you want to keep prefetch for specific routes, you can enable it per route with a webpackPrefetch: true comment on the dynamic import: import(/* webpackPrefetch: true */ './somePage.vue')

Another problem with dynamic routes: if a component had logic tied to route information (say, checking $route.name to work out that we're on the login page and hide the footer), it could misbehave, because at the moment the condition was evaluated the route itself might not have loaded yet.

So in places like that we had to write conditions so that the component, or part of it, only rendered once the route had loaded and therefore had a name property, with the dependent logic running after that:

Now for async components. The idea is roughly the same as with routes: we can load them only when we need them. We only started doing this after moving to Vue 3, where it's quite simple and convenient.

For example, we have a global component for error notifications that sits unused most of the time and is only needed when an error actually occurs (the same goes for plenty of modals). A good candidate for an async component.

Let's rewrite its import using defineAsyncComponent:

By the way, the overall Performance score didn't move after all these changes, so there's nothing to show. But that's only because we removed a couple of lightweight routes and one small component — the bigger and more complex the project, the more you stand to gain from these Vue and Vue Router features.

Optimizing requests

On top of everything else, we can reduce both the number and the size of requests.

For example, on the pages listing athletes or coaches on the platform we were requesting 50 people per paginated page — even though in practice a user on a phone initially sees only 3–5 cards, and on desktop 10–15, depending on screen size. The obvious fix: cut the number of athletes and coaches requested to 15 per page:

Next: the site has a lot of images (competition photos and their thumbnails, user avatars), so for images that aren't visible on screen at load time, or that sit behind pagination, I add loading="lazy". We have a shared image component, so that's what I change:

I decided not to use a dedicated lazy-loading library, because support for the attribute is already close to 93%.

We could also add an SVG sprite to cut down the number of image requests, since besides the mdi icons we have a lot of custom ones. That task is still in progress, though.

Then we go through the project looking for chains of awaited requests where each one waits for the previous to finish, even though in some cases they don't depend on each other and could run in parallel with Promise.all():

Equally important: look at what the backend actually returns, and talk to the backend developers. Tell them when responses contain unused fields that bloat the payload, or suggest splitting large endpoints into several smaller ones where the situation allows.

Vue 3

Another improvement to the Performance score came from migrating the project from Vue 2 to Vue 3, so if you're still deciding whether to make that move, this can be one more argument in favor.

I found the numbers on the speed difference between Vue versions here. In practice, for us the difference in Performance was 10–15 points in Vue 3's favor. I'm sure everyone's results will differ, but that was our experience.

Redesign

Something outside my control contributed too: a redesign of the home page (keeping in mind that the Performance score on other pages obviously didn't change as a result). Instead of one large banner at the top, the page got several smaller, lighter images, which can also be loaded with loading="lazy". That was worth roughly another 10 points:

PWA

Finally, we converted our SPA into a Progressive Web App, which lets us cache almost any resource the site uses — CSS, JS, fonts, images. From then on they're served from cache without being re-downloaded until a new release goes out. And while this doesn't affect load speed on a first visit, it significantly speeds up loading and navigation on subsequent ones.

But caching is a hidden devil. It's important to be sure that when the site's code is updated, users always get the latest version and don't get stuck on a stale cache.

Wrapping up

Let's sum up and draw some conclusions from the optimization work:

We doubled Performance (from 30–40 to 70–80 points).
The most noticeable results came from loading fonts properly (including using a variable font), from the icon library, and from the modular Firebase 9.
Given how much fonts matter, discuss the topic with your designer up front so they can use variable fonts where possible.
Layout shift is an important factor in the Performance score. Bringing it to 0 gives a meaningful boost, and also improves the actual experience of using the site.
Vue 3 gave a decent gain, which is one more argument for migrating from Vue 2.
Async components, async routes, lazy loading, SVG sprites, request optimization — these give fairly limited results, but the payoff grows with the size and complexity of the project.
Sometimes changing the design is enough: making it lighter. But it's important to account for this from the start, sometimes by talking your designer out of things like very large images.
Going PWA can bring a significant Performance improvement through caching.

Understanding `this` in JavaScript

Ilia — Thu, 30 Jul 2026 17:31:34 +0000

There are three things you can watch forever: fire burning, water flowing, and frontend developers writing yet another article about this.

Still, that pile of articles exists for a reason. The topic really is confusing for a lot of people. There are plenty of good articles that get it right, but mostly from a purely practical angle, without digging into how it actually works underneath. Articles that go deep on the theory are literally a handful.

In this article I'll try to open the topic up from the theoretical side, starting from the ECMAScript specification, and then derive the practical rules for determining this from that theory.

The Reference Record type

One of the foundational concepts for determining the value of this is the Reference Record.

A Reference Record is one of the ECMAScript specification types (not to be confused with JavaScript's own types, or the spec pedants will come for you) used internally by the language. It has the following fields: Base, ReferencedName, Strict, and ThisValue. Let's go through them in order.

Base — a value equal to one of the JavaScript data types, or an Environment Record (another specification type).

ReferencedName — a String, Symbol, or Private Name.

Strict — a Boolean.

ThisValue — one of the JavaScript data types.

In plain terms: Base can be, for example, an object or an Environment Record (essentially a special object that holds all the local variables); ReferencedName is the name of an object property or an identifier; Strict indicates strict mode; and ThisValue is related to the super keyword.

From here on I'll leave out the Strict and ThisValue fields unless we need them for something specific.

So how do we tell what counts as this type? It's fairly simple. The interpreter treats something as a Reference in two cases:

When we use a property accessor, meaning dot or bracket notation: obj.name, obj['name'], or obj.method(). Incidentally, the usual phrasing about this is that it equals whatever sits to the left of the dot, which conveniently forgets the bracket variant.

And when we're dealing with an identifier — variables, properties, or functions.

In every other case — with operators (x + y, x ? y : z, !x) and literals ("abc", [1, 2, 3], and so on) — we get other types.

For example, say we have a person object:

const person = {
  name: 'Dasha',
  catName: 'Thomas',
}

person.catName

Walking through this code, the interpreter sees that a property accessor is being used to reach the catName property, so what we have is a Reference Record expression that looks like this:

{
  Base: person,
  ReferencedName: catName,
}

Or take a variable:

const cat = 'Thomas'

That's an identifier, so it's a Reference too, and it looks like this:

{
  Base: global object,
  ReferencedName: cat,
}

A note on the global object: it's the object that, depending on the environment and on strict mode, can have different values: in a browser it's window, or undefined in strict mode. Rather than list every possible value each time, I'll just use the word "global" from here on.

So we can say that the value of Base is the context that ReferencedName lives in.

`this` and the Reference type

Now that we've worked out what a Reference Record is, we can move on to how it helps us determine the value of the this keyword.

The point is that the main case where the value of this depends on context is when we're dealing with a Reference, and the value we use is the Base field.

To see how that works in practice, let's look at a few examples.

const person = {
  name: 'Dasha',
  catName: 'Thomas',
  getCatName() {
    return this.catName;
  }
}

person.getCatName()

The object's method is called through a dot, which means we have a Reference where Base equals person and therefore this equals person.

const getCatName = person.getCatName

getCatName()

And what happens here? Calling the identifier getCatName is also a Reference, but Base will be global, and therefore this equals global.

All of this follows from the spec's algorithm for calling a function. In the first example we passed the check at the first step, whose first sub-step (IsPropertyReference means we're calling a property of an object) leads to taking this from Base.

In the second example we land in the second sub-step, since the value isn't a property reference, and Base is set to the Environment Record, which in this case is the global object.

Now let's look at a more complex, classic example:

;(person.getCatName)();
(false || person.getCatName)();
false || person.getCatName();

In the first case the expression uses the grouping operator (), which on its own doesn't affect the returned value, so the Reference type is preserved and the function returns 'Thomas'.

In the second case grouping is used as well, but with the || operator added, which forces the expression to be evaluated and the Reference type to be lost, so this becomes global. On top of that, in strict mode, trying to execute the line this.catName gives an error, because this will be undefined and we're effectively reaching into undefined.catName.

In the third case an operator is used, but without the parentheses, so the result is a call to person.getCatName() in dot notation with the Reference type intact, and the function returns 'Thomas'.

This tells us that calling the same function in different ways can produce different values of this.

Callbacks deserve a separate mention: there, the value of this depends on the specific function the callback is passed to. That's especially true for external APIs like addEventListener() or setTimeout(), which are part of the HTML specification, where the value of this is something you simply have to memorize rather than derive from the rules.

For example, this inside a click handler callback on document returns document itself — the element the listener is attached to:

document.addEventListener('click', function() {
  console.log(this)
})

Whereas inside forEach, this is already global:

[1, 2, 3].forEach(function() {
  console.log(this)
})

Arrow functions

Arrow functions are a case of their own when determining this, because according to the specification they simply don't have one, they take it from the parent lexical environment:

It follows that for arrow functions, the value of this is fixed not when the function is called but when it's created. And that can lead to some unexpected results.

Let's go through a few examples.

const person = {
  catName: 'Thomas',
  getCatName: () => {
    return this.catName
  }
}

person.getCatName()

The parent lexical environment for the arrow function getCatName here is the outer global Environment Record. Since an object literal (creating an object directly with {}) doesn't create a lexical environment of its own, the arrow function takes this from wherever the person object was created. So calling person.getCatName() returns undefined, or throws in strict mode.

What if we wrap the arrow function call in a regular function?

const person = {
  catName: 'Thomas',
  getCatName: () => {
    return this.catName
  },
  wrapperFoo() {
    return this.getCatName()
  }
}

person.wrapperFoo()

Nothing changes. this for getCatName() has already been set statically, and it doesn't matter how or where we call it.

But if the arrow function is defined inside a regular function to begin with, then this comes from that regular function, and calling person.wrapperFoo2() returns 'Thomas':

const person = {
  catName: 'Thomas',
  getCatName: () => {
    return this.catName
  },
  wrapperFoo() {
    return this.getCatName();
  },
  wrapperFoo2() {
    return () => {
      return this.catName;
    }
  }
}

person.wrapperFoo2()();

And here's an example that highlights the fact that this is fixed when the function is created rather than when it's called:

const person = {
  catName: 'Thomas',
  wrapperFoo() {
    return () => {
      return this.catName;
    }
  }
}

const foo = person.wrapperFoo()

foo(); // ‘Thomas’

Remember how, when we were talking about the Reference type, we said this kind of assignment and calling a function without dot notation loses this? For an arrow function that's not a problem, because the value of this was already fixed at creation time and doesn't depend on how the function is called.

That's exactly what makes arrow functions useful as callbacks, which, as mentioned above, can end up with all sorts of values for this.

It also affects bind(), call(), and apply(), which don't override this for arrow functions. That's spelled out in the spec for these methods too:

bind()

call() and apply()

Methods bind, call, apply

These methods let you set this explicitly when calling a function, passing it as the first argument. But bind() occupies a special place among them, because it produces a bound function. Its defining feature is a fixed this value held in the BoundThis field.

Let's look at an example:

const cat = {
  name: 'Thomas',
  getOwnerName() {
    return this.ownerName
  }
}

const owner = {
  ownerName: ‘Dasha’,
}

const boundGetOwnerName = cat.getOwnerName.bind(owner)

boundGetOwnerName()

By binding owner as the first argument to bind(), we set it as the value of this, and it stays tied to that function regardless of how the function is called. Even if it's later called with call() or apply(), they can no longer override the this that bind() locked in:

const anotherOwner = {
  ownerName: 'Ilia',
}

boundGetOwnerName.apply(anotherOwner)
boundGetOwnerName.call(anotherOwner)

This follows from the spec too, which says that when these methods are applied to a bound function, the this argument is ignored:

call() and apply()

So in our example the cat always stays attached to the original owner we tied it to. And even if we try to override this with bind() a second time, we won't manage it.

There is one exception to this rule, though: the this value passed to bind() is ignored if the function is invoked with the new operator. Per the spec, that's because the constructor path, [[Construct]], simply has no step where BoundThis is applied, unlike the ordinary [[Call]] path:

The `new` operator

With new, everything looks straightforward at first glance: this takes the value of the newly created object that the constructor returns:

function Cat() {
  this.name = 'Thomas'
}

const newCat = new Cat()
newCat.name // ‘Thomas’

Or an empty object, if the function is just called with new:

function Cat() {
  console.log(this)
}

new Cat() // {}

Another example, with a class:

class Cat {
  constructor(name) {
    this.name = name
  }
  getCatName() {
    return this.name
  }
}

const cat = new Cat(‘Thomas’)
cat.getCatName(); // Thomas

const cat2 = new Cat(‘Lesya’)
cat2.getCatName(); // Lesya

But there's a subtlety hidden in the phrase "the object that is returned". If the function being called explicitly returns an object, that object becomes the result of new, and the object created by the constructor is lost:

function Cat() {
  this.name = 'Thomas'
  return {
    name: 'Lesya',
    getName() {
      return this.name
    }
  }
}

const newCat = new Cat()
newCat.getName() // ‘Lesya’, not ‘Thomas’

Here's why. When new Cat() is called, the engine runs the internal [[Construct]] method:

ConstructorKind is checked, and if this is a base constructor (that is, no extends), OrdinaryCreateFromConstructor is called. A new empty object is created and given Cat.prototype as its prototype. That object is stored in thisArgument.
OrdinaryCallBindThis takes the created object and binds it as this inside the function body. From that point on, every reference to this in the constructor body points at this new object.
OrdinaryCallEvaluateBody executes the function's code. This is where this.name = 'Thomas' fires, the property is written to the object from step 1.
If the function explicitly returned an object (result.[[Value]] is an Object), that object becomes the result of new. The object from step 1 is lost.
If the function returned a primitive, or returned nothing, thisArgument is returned, the object from step 1.

It's step 4 that explains the last example. An object is returned there, so step 4 fires and the this.name = 'Thomas' from the constructor body is lost.

Finally, the super keyword. Two things are worth pointing out here.

First: in a derived constructor you can't touch this before super() has been called, doing so throws an error.

Second: even when we call a method through super, say super.getName(), this inside it won't refer to the object super points at:

class Parent {
    constructor() {
        this.name = 'Parent'
    }
    getName() {
        console.log('Name:', this.name)
    }
}

class Child extends Parent {
    constructor() {
        super();
        this.name = 'Child'
    }
    testSuperMethod() {
        super.getName()
    }
}

const child = new Child()
child.testSuperMethod()  // "Name: Child", not “Name: Parent”

So even when methods are called through super, the this context stays bound to the current object.

And this brings us back to the Reference type, incidentally, because evaluating super.getName() ultimately gives us a Reference with the ThisValue field set and Base holding the current object where super was called:

There's one more case worth covering separately. We've already seen that an arrow function in an object literal loses this:

const cat = {
  name: 'Thomas',
  getName: () => this.name
}

cat.getName() // undefined

You might expect classes to behave the same way. But they don't:

class Cat {
  name = 'Thomas'
  getName = () => this.name
}

const cat = new Cat()
const fn = cat.getName
fn() // 'Thomas' — this is not lost

Why? As we know, an object literal {} doesn't create a lexical environment of its own, so the arrow function takes this from outside. But properties declared directly in the class body — class fields — are initialized inside the constructor, where this is already bound to the new instance. It's effectively equivalent to this:

class Cat {
  constructor() {
    this.name = 'Thomas'
    this.getName = () => this.name
  }
}

The arrow function captures this from the constructor and keeps it forever, like any other arrow function.

Conclusion

Let's boil the whole article down to a short algorithm:

Arrow function? → this is taken from the outer lexical environment at creation time. Ignores bind/call/apply, and can't be called with new.
Called with new? → this is the new object (unless the function explicitly returns a different object). Overrides bind.
Called through bind? → this is BoundThis. Not overridable via call/apply.
Called through call/apply? → this is the first argument.
Called through a dot or brackets? → this is the object to the left of the dot. Exception: super.method(), where this stays the current object rather than the prototype.
Everything else → this is global (or undefined in strict mode).

That's it. We've covered all the main cases and some of the edge cases for determining this, working from the operations described in the ECMAScript specification, which should help build a more fundamental understanding of the topic, and with it, help solve concrete problems in practice.

Optimizing Images for Users on Slow Connections with the Network Information API

Ilia — Thu, 30 Jul 2026 17:04:07 +0000

Most of us are used to treating fast, stable internet as a given. But there are still scenarios where it isn't: on the road between towns or inside buildings that block the signal for one reason or another.

In this article I'll look at one optimization technique that uses the Network Information API. It's an API with a large set of information about the connection, though browser support isn't great yet. That's not a reason to skip it for users whose browsers do support it — roughly 76% of users globally. The code examples are in Vue.

The image component and imagekit

I'll start with some background. Our project has an AppImage component responsible for all images, and we host them with imagekit.io. Leaving out the details that don't matter here, a simplified AppImage looks like this:

<script lang="ts" setup>
import { computed } from 'vue'
import { useMedia } from '@/composables/media.ts'

interface IProps {
  imgId?: string
  src?: string
  height: number | string
  width: number | string
  ...
}

const props = withDefaults(defineProps<IProps>(), {
  imgId: '',
  src: '',
  ...
})

const { getImageById } = useMedia()

const srcAttrs = computed(() => {
  if (props.src) {
    return {
      src: props.src,
    }
  }

  return {
    src: getImageById(props.imgId, +props.width, +props.height, props.type),
    srcset: `${getImageById(props.imgId, +props.width * 2, +props.height * 2, props.type)} 2x`,
  }
})
</script>

<template>
  <img
    v-bind="srcAttrs"
    :height="height"
    :width="width"
  >
</template>

It contains a getImageById function that hits imagekit with the image id and the w and h parameters to request that image at particular dimensions:

const getImageById = (
    id: string,
    width: number,
    height: number,
    ...
  ): string => {
    ...
    return `${BASE_URL}/${id}${width ? `?tr=w-${width}` : ''}${width && height ? `,h-${height}` : ''}`
  }

The service also has a q parameter, which takes values from 1 to 100 and controls the quality of the returned image. Here, for example, are two images at q=90 and q=20, weighing 31 KB and 3 KB respectively:

That's the parameter I'll be changing based on the user's connection speed. If you don't use a service like this, it'll be more work, but you can still prepare images at different quality levels separately and swap them in.

Using effectiveType to detect connection speed

We need a service that tracks connection information and changes image quality in response. Let's call it handleNetwork and declare the variables we need:

import { ref } from 'vue'

const imagesQuality = ref(90)
const isSlowConnection = ref(false) // we will use it later

export function handleNetwork() {
  return { imagesQuality }
}

The default value for imagesQuality is set to maximum quality. We'll only degrade on an explicit signal.

The Network Information API gives us the effectiveType property, available via navigator.connection.effectiveType. It can take several values — slow-2g, 2g, 3g, 4g — each corresponding to a particular connection speed, even when the user is on wifi or a wired connection. Here's a table with a short explanation:

These are the values we'll key off when changing imagesQuality.

To initialize and track changes to effectiveType, we need to add a listener for the change event on navigator.connection, plus an updateNetworkState function to handle the updates.

Important: always check that the browser supports the API, with a simple 'connection' in navigator check:

function updateNetworkState() {
  ...
}

if ('connection' in navigator) {
  updateNetworkState()
  navigator.connection.addEventListener('change', updateNetworkState)
}

Now let's write updateNetworkState. It's just the switch that sets imagesQuality — the support check is already done above, at the only place this function is called from:

function updateNetworkState() {
    switch (navigator.connection.effectiveType) {
      case 'slow-2g':
      case '2g':
        imagesQuality.value = 1
        break
      case '3g':
        imagesQuality.value = 20
        break
      case '4g':
        imagesQuality.value = 90
        break
      default:
        imagesQuality.value = 90
        break
    }
}

Changing image quality

Back to AppImage: we import our service and do two things.

1) Pass the quality variable as a new parameter to getImageById

2) If imagesQuality is below 20, drop the srcset attribute holding the 2x image — on a slow connection there's no point downloading higher-resolution images

<script lang="ts" setup>
...
const { imagesQuality } = handleNetwork()
const quality = imagesQuality.value
...

const srcAttrs = computed(() => {
  if (props.src) {
    return { src: props.src }
  }

  ...

  return {
    src: getImageById(..., quality),
    srcset: quality > 20 ? `${getImageById(..., quality)} 2x` : undefined,
  }
})
</script>

One detail matters here: handleNetwork is called at setup level rather than inside the computed, and the value is read out of imagesQuality once.

If you call the service inside the computed, or put imagesQuality.value in there, then when the connection degrades, src recalculates for every image already on screen. A different q means a different URL: the browser fires a batch of fresh requests over the connection that just got worse, to replace images that are already downloaded and already visible. You end up with an optimization that makes things worse at exactly the moment the connection slows down.

The updated getImageById with a quality parameter:

const getImageById = (
    id: string,
    width: number,
    height: number,
    quality: number,
    ...
  ): string => {
    ...
    return `${BASE_URL}/${id}${width ? `?tr=q-${quality},w-${width}` : ''}${width && height ? `,h-${height}` : ''}`
  }

Done. You can check it in the Network tab of your dev tools: switch the profile to 3G and then, say, go to the next page of pagination — the new images come down at reduced quality, while the ones already rendered stay put and aren't requested again.

Optimizing background-image

The next opportunity is turning off background images set through CSS. Background images are usually purely decorative and carry no valuable information, so on a slow connection they can be sacrificed and skipped in favor of a solid color.

For that we'll use the isSlowConnection flag we declared at the very beginning. We extend the switch so it changes this variable alongside image quality:

switch (navigator.connection.effectiveType) {
  case 'slow-2g':
  case '2g':
    imagesQuality.value = 1
    isSlowConnection.value = true
    break
  case '3g':
    imagesQuality.value = 20
    isSlowConnection.value = true
    break
  case '4g':
    imagesQuality.value = 90
    break
  default:
    imagesQuality.value = 90
    isSlowConnection.value = false
}

And below that we add a class toggle on body — you can name the class whatever you like, but it's better to use a distinctive prefix to avoid style conflicts — which lets us target the right styles with a CSS selector:

function updateNetworkState() {
  switch (navigator.connection.effectiveType) {
    case 'slow-2g':
    case '2g':
      imagesQuality.value = 1
      isSlowConnection.value = true
      break
    case '3g':
      imagesQuality.value = 20
      isSlowConnection.value = true
      break
    case '4g':
      imagesQuality.value = 90
      break
    default:
      imagesQuality.value = 90
      isSlowConnection.value = false
  }

  document.body.classList.toggle('cs-slow-connection', isSlowConnection.value)
}

For instance, we have a background image on the competition page. Let's write styles so that when the cs-slow-connection class is present, the background image is replaced with a solid fill in a similar color:

.event-header {
  &::before {
    background-image: url("/img/event-default-img.webp");
    background-position: center;
    background-size: cover;
  }
}

body.cs-slow-connection {
  .event-header {
    &::before {
      background-color: #e4e4e4;
      background-image: none;
    }
  }
}

It looks like this:

slow 3g

In the second case there's no image request at all, which takes at least some of the load off an already struggling connection.

Other possibilities

I've shown just two examples of using the Network Information API to optimize images, but the possibilities go much further. You can load placeholders instead of video, skip images entirely on 2g, try not to load non-essential fonts, even swap out or drop whole components — and so on.

But I hope these examples at least sparked some interest in this API, and drew attention to the problems that come with a bad connection.