DEV Community: Alexandra

The Curiosity Gap: Why We've Stopped Asking Questions

Alexandra — Tue, 22 Sep 2026 08:26:58 +0000

In a comment some weeks ago (link) i wrote about how it doesn't matter if you are using AI or not, or if you call yourself a vibe coder or a SWE. Over my years of working with code, I have seen passionate people who are excited and want the product to succeed, and people who have no interest in improving anything and promote enshittification. In my unpopular opinion, it all comes down to how much you care about the outcome and the quality of your work, and how curious you are to learn the whys.

In this post I want to dig into that second part: curiosity, or rather, the lack of it. Last year I felt so stuck, I didn't feel that I was learning anything or producing the results I want to. Even though I was shipping code (a lot of it), everything was feeling pointless. Everyone around me was so obsessed of automating everything, that learning and progressing as an engineer was an afterthought. Even though they were pushing us to use AI in a ridiculous degree, and our performance was almost certainly evaluated by token usage, they didn't offer any material, courses on how these systems really work, what are the optimal ways of using them and why we should care. Their thought process sounded more like "use-this-produce-money" and the magical answer to everything was "ask claude".

Buuuut...What it took me a long time to realise was that the only person that is responsible for my learning and the quality of my work, is me. I had slowly and steadily gave up trying, because everyone was telling me that I will be replaced. But nobody will come and save me, or implant knowledge in my head. It's on me whether I offload all my thought process to AI and don't care anymore, quote very confidently what claude answers me back or whether I doubt on the quality of my work and push for the best. Somehow this is how I started writing here again. My mantra is that if you can't explain it simple, you don't know it, so writing helped me identify my gaps and what really really interests me.

I see lately both in my friends, my professional circle and even on linkedin, that many people have mentally given up (generally, not only in SWE). The state of the world isn’t the best. We’re constantly hearing about AI replacing jobs, industries changing overnight, economic uncertainty, climate anxiety, wars, and about 147 other reasons to wonder what the hell we’re doing here and what is the point of anything.

When you’re constantly being told that whatever you’re learning might be automated tomorrow, I can understand why people stop investing to their skills or even to themselves. Why bother getting good at something if it might not matter in a few years (or months/weeks?). Why even bother look at the code when AI generates it, AI reviews it and AI documents it? Why even invest on learning how to code? And somewhere along these lines we lost everything that made this job interesting.

My question to you dear reader: Does it really matter if AI can do the skill/task/programming? The promise of these fancy tools was to automate the boring tasks and us the humans we will continue doing the interesting or difficult parts. Is that what we are really doing? Somewhere in this trip we started offloading the interesting or the difficult and kept the worst part of this job for us - managing a tool. I like solving problems, find where this little bug comes from, create a new feature. It's like little puzzles to me, that you play the detective and you need to find the culprit. I really enjoy solving these by myself. So who cares if they can be automated? The world won't stop about the half hour more I will take to do something without Claude whispering "Yes, you are right, i underestimated the scope".   Not everything should be done in the name of automation and efficiency, sometimes we do stuff for the sake of enjoyment and curiosity.

So maybe it's a good time to re-invest to ourselves and start be curious again. Care about what we are doing, even if we don’t know whether that thing will still exist in a year. The time that we invest to ourselves and our skills are never wasted. You can learn a new programming language, try a non-tech hobby, learn how the electronics world works, try a new library, revisit old projects, or build something completely unrelated to our job. Maybe we get the inspiration or motivation we need from somewhere we weren’t expecting.  

I don’t think the answer to uncertainty is to stop being curious because AI can do it anyway. Sometimes we learn because we want to expand our mind or simply because it's just fun.

So, thank you, for coming to my Ted talk and the optimistic message of the day for you is: Stay curious! ✌️

--
This post was written by human(me!) and might have grammar errors.

AI psychosis might be a result of subscription fatigue

Alexandra — Wed, 09 Sep 2026 13:06:37 +0000

Continuing my thoughts after my previous article, and having too much free time lately, I have been spending more time than I should browsing LinkedIn, the place where the jobs descriptions die, but the AI influencers thrive.

The subscription problem

After reading too many AI posts, followed by too many anti-AI posts, I’ve started to forming some kind of belief that the AI psychosis we’ve seeing over the last year is- at least some extend of it- a direct consequence of something that started long before AI was there: the endless subscription models that almost every major or minor company has imposed on us.

For years, we’ve gradually moved from buying software to renting it (who remembers the good old days that when you bought a laptop, it was also included the actual CDs to install Word?). Instead of paying once for a product, we now pay a monthly subscription to keep accessing it. Yes, we are paying for infrastructure (since everything seems to be on the cloud), ongoing development, support, content or a service that has recurring costs.

But sometimes it feels like our money goes to something that it is more like a collection of features wrapped in a nice-ish interface.

Two Types of AI Enthusiasm

Upon browsing Linkedin you can see too major groups:

The first group has realised that they can build a spinoff of an application they need/want/like for a fraction of the cost. They don't necessarily need to build something sophisticated, with the best architecture or commercially viable. They just need something that solves their particular problem and AI helps them to achieve their goal.

The second group has a different thought model. They have realized that they can build a spinoff of an application they need/want/like, and then they assume that because they were able to build it more or less cheap and easy, there must also be an opportunity to monetize it.

In my humble opinion this second group is where some of the current enthusiasm around AI starts becoming disconnected from reality. Being able to build something in a low price does not mean that someone is willing to pay you for it or you solve any particular novel problem.

AI Didn't Democratise Software

So, did AI unlock our potential to democratize code or reduce (finally) the prices? Absolutely not.

What AI has done is reduce the cost and effort required to produce certain types of software. We have to consider the difference between the cost of creating that said software and the value that this software provides.

If the software is just an interface around something easy to reproduce, then yes, AI can make it much less valuable. But there are plenty of businesses where the software itself isn't the main reason people buying it. That could be the trust in brand or the security promise etc.

Software Isn't Always the Product

There are some services that you can’t really hurt and it doesn’t even matter if they use AI or not. Their value comes from something the average person can’t reproduce: their content.

Streaming services are a good example. Netflix can charge (or change whenever they want) a monthly subscription not because the application is difficult to recreate (the contrary), but because its value is the content available inside the app.

Yes, you could build your own basic streaming application version very easy. But that doesn’t give you access to the catalogue of movies or shows.

Sure, you could start buying DVDs, digitise everything, build a ridiculous amount of storage and spend the rest of my life maintaining it. But at that point, I might as well just pay for the netflix subscription.

Amazon works in a similar way. There is nothing revolutionary about the concept of an online storefront. A developer can build a basic version of an Amazon-like interface relatively quickly (with or without AI).

But Amazon isn’t valuable because it has product cards, a shopping cart and a checkout page. The real value is everything behind them: the sellers, warehouses, logistics, delivery network, payment systems, customer service and, perhaps most importantly, the convenience of having almost anything delivered to your door.

The Software We Never Built

The truth is that AI hasn't made software worthless but rather made a particular category of software easier to reproduce.

The last years, we have accepted subscription software as the default. If we needed a particular functionality, we would search for a SaaS product, create an account and add another recurring payment to a long list of subscriptions we already have. But now we can just consider: "Can I just build and maintain the thing I actually need?"

What Actually Changes?

Realistically, I don't think everyone is going to become a software entrepreneur, and I certainly don't think every AI-generated SaaS product is going to become a successful business. Actually, i believe the opposite, most of them will fail, because when everyone can build another spin-off, building anotherx2 spin-off isn't much of a competitive advantage.

In fact, we are already seeing an enormous amount of software being created that nobody actually needs or cares about. What I do think is changing is the relationship between users and software companies, now the users can make the decision between building or buying that software more or less in the same price (or even cheaper).

These tools won't make us billionaires or help us to make the next billion-dollar application. I think the future lies more in making the tiny, boring, incredibly specific tool that only you need economically reasonable.

The companies that should be worried aren't necessarily the ones selling complex technology or very good content. But the ones whose entire value proposition is a thin layer of software sitting between the user and something the user can now reproduce themselves.

So What is your take? Do you think AI will change the way we buy/rent software?

Will we start building the small tools we need ourselves or will convenience and reliability still be enough to make subscriptions withstand?

Which types of software do you think are most vulnerable to this shift?

This article reflects my own thoughts, and is written by me, but i use AI to help me with the grammar!

This article isn't about AI being good or bad, but more than how the economy changes around it. You can agree or disagree but be nice in the comments.

What do you build when you can build anything?

Alexandra — Wed, 02 Sep 2026 16:38:09 +0000

My hot take is: Telling people that they have to build endlessly is very, very, very bad advice. If you have been remotely on LinkedIn over the last six months, you will have seen two different camps. The AI haters, the ones who don’t want to lay their eyes on your AI-generated code, article or post, and the AI defenders, the ones who say all day long that if we dont build with AI we will be left behind. But which camp is right? Both and neither, all together.

The Cost of Building Everything

I said building everything is a waste. A waste of resources (...poor water), a waste of money, a waste of time and a waste of bytes in a data centre, all for a dead product that maybe only one person will ever discover. The best skill we probably need to develop nowdays is knowing what not to build. In a world of endless possibilities, how do you choose what is a good idea? It is almost an impossible task.

It all started with a random idea I had for an app. I like photography, and i often go for photo walks in my cities. My idea involved creating an app that helps you create/attend/do a photo walk. Sometimes I am already out with my camera and want to find the next place to take photos, but I don't know exactly where to go. Or maybe I want to find a well-known photospot and try to recreate a particular photo. What sounds like a simple feature quickly becomes a set of different user needs. I started sketching the idea, using AI to explore the flows and turn the word vomit in my head into something tangible. But I had to stop and ask myself: is this actually worth building? When I go for my little photowalks, I actually like to getting lost, and find unexpected things. Is this even a good idea?

One would argue "why not" or even not think to question the idea at all. I could open my IDE, ask an agent to build the first version and have something running in a few hours. I could spend a weekend on it. I could launch it. I could even convince myself that I am doing something productive. But none of that answers the question. It only answers whether I can build it.

Welcome to Agency Hell

Engineers love to create their own personal versions of hell. First we had the tutorial hell, then we upgraded to the side-hustle culture hell. And now, apparently, we are in the 7th ring of founder and agency hell.

For a long time, there was a constraint between having an idea and building it. You needed to know how to code, find a designer, learn a new framework, figure out deployment, pay for infrastructure, convince someone to use it and somehow find the time to do all of that while having a job. So, most ideas died somewhere along the way, and that was probably a good thing.

AI removed a lot of those problems. You can have an idea in the morning and have a prototype by the evening. You can generate an app, the accompanying landing page, write the backend, create the db schema, produce the copy (with the compalsory em dashes) and deploy the thing without needing much more than some free time and a few API tokens (it could many $$, but that's an other discussion).

To some people that sounds like a freedom. But freedom without direction can become its own kind of trap.

When everything is possible, every idea starts to feel like an obligation. You see someone building an AI wrapper, so you build one. Someone launches a micro-SaaS, so you launch one. Someone makes €10,000 from a weekend project, so you start wondering why you haven’t done the same. This is what I mean by agency hell. Not the inability to build, but the constant feeling that you should be building.

What Do You Actually Care About?

When you can build anything, what do you build, though? That question is very personal for each of us. We can rephrase it: what do you care about? That is a much more difficult question to answer. But (in my humble opinion) that will break or make your relationship with AI.

I don't know anyone that grew up with aspirations on making the best accounting software, these kind of software comes from a need of understanding a complex domain. AI can help you build this kind of software, but it cannot give you a reason to care about the problem.

Most people care about their families, their hobbies, their friends and the things that make their lives meaningful. Those are the places where interesting problems hide. You might build something because your mother struggles with a particular task, because your dance studio has an annoying process, because your photographer friend struggles with their workflow, or because something in your own life keeps bothering you.

Not every hobby needs an app. Quite the opposite. The point is that caring about something gives you a reason to notice problems that other people don't see.

Possibility Isn’t Purpose

In a world of possibilities, we probably have to become more selective about what we build. AI has changed the economics of software creation, yes, but there are still only so many hours in a day, only so many people who will use your product and only so many problems worth solving.

Most people think AI unlocks some secret chest of money. The truth is that it doesn’t. It makes execution cheaper. It makes experimentation faster. It gives more people the ability to turn an idea into something real.

But it cannot tell you which idea deserves your time.

Because if you don't care about what you are building, congratulations, you just unlocked a whole new world of endless misery.

I would really love to hear about your thoughts about this topic. Yesterday I saw at least 2 posts of identical ideas being implemented by different people. Do we squeeze ideas to fit in the market in non-existing problems (create our own new kind of hell), or we solve problems people (or ourselves) have? I know that not all software are build for usefulness, sometimes being fun is enough, but i seem to struggle to recognize if my ideas are actually good and worthy to bring into life. So what is your take?

This post was written by human (me!) and passed through an AI grammar revision.

From Figma to the browser: building a shared mental model

Alexandra — Sun, 30 Aug 2026 10:58:03 +0000

Throughout my career as an engineer, I have been given a countless amount of specs, design documents and Figma files to bring ideas to life. I have attended handoffs, kickoffs, design critiques, you name it. Something I noticed out through the years is more often than not, it feels like designers and developers are talking about the same thing while actually having fundamentally different mental models. And here is where the friction between these two disciplines comes into play.

The canvas vs. the browser

A designer has a canvas, and moves around stuff in this space. They can put an element wherever they want, move it around, resize it. This is quick, easy, fun and provides them with the creativity that a designer needs.

But, the browser doesn’t work like that. A browser organizes the elements in stacks. These elements have relationships, they take up space, and their position can change depending on the items around them.

A design to an engineer is a snapshot in a particular size screen, and our job usually is to find the correct rules that produce this result and interpolate this to different sizes.

The interesting part is that the gap between these two mental models isn't actually as big as it might seem. Design tools have started to give designers many of the same or similar concepts that developers use to build layouts. Figma has an "Auto Layout" option, for example, which is very close to the way we think about CSS Flexbox. This helps the designers and developers to find a common vocabulary and collaborate more.

Auto Layout → Flexbox

If you have worked with CSS for a while, you probably know about Flexbox. It has already been available to developers for the last decade.

The basic idea is simple: you have a container with a number of children, and you want to describe how those children should be laid out and how they should use their available space. Instead of telling the browser where each element should go, you describe the relationship between them.

Imagine having multiple buttons inside a container. The moment you instruct that this container is a flex container, I can say that these buttons should sit next to each other, have a gap between them and be aligned to the center. If the container gets wider, the layout can adapt. If one button becomes larger because its label changes, the others can respond accordingly.

Figma has something very similar: Auto Layout! If you have used Auto Layout in the past, you already understand many of the concepts behind Flexbox. You have a container and you decide whether its children are arranged horizontally or vertically. You define spacing and alignment. You decide how the container should behave when its contents change, and how the children should use the available space.

And just like Figma allows you to nest Auto Layout frames, CSS allows you to nest flex containers.

Each of those containers can have its own layout rules. One can arrange its children vertically, another horizontally, and another might allow one child to take up all the remaining space.

The closer the mental model in Figma is to the mental model in the browser, the less translation is required between the two.

When one dimension isn't enough → CSS Grid

CSS Flexbox solves many problems for frontend development, but it still is 1-dimensional layout. What that means is that it handles the items in a single main axis (something like a single row or column).

In many problems we solve one dimension is not enough. So we have a CSS Grid, which is a container in 2 dimensions. Think about a dashboard, a photo gallery, or a page with multiple sections that need to line up across both rows and columns. Now we're not only just asking “how should these things sit next to each other?”, but also “how should these things relate to the structure of the entire layout?”

The easiest way to picture this, it is a grid of cells, something like a table, but unlike a table, these cells aren't tied to the content in a particular row or column. We can define the structure of the layout and decide how elements should span across it.

A designer might look at a Figma canvas and see a beautiful asymmetric layout: one large image spanning two columns, a group of cards underneath, and a section that stretches across the entire page. A developer doesn't need to reproduce that with a collection of arbitrary pixel positions, but they can describe the underlying structure.

This gives designers something useful to think about when creating layouts. That doesn’t mean that grid is the answer to all the problems, we can mix and match those tools to achieve the result.

The important thing is for the designer and developer to work closely with each other. One can help each other, by strong communication and understanding of each others language. It’s not about just handing off designs anymore, but more about thinking these systems and the interaction needed to achieve useful results.

Designing for change → responsive layouts

A design might look as a static snapshot to a developer. It works in a very defined size. A Figma file might give us a desktop design and a mobile design, but the browser has to deal with everything in between.

A breakpoint is essentially the point where the current layout stops making sense. In CSS we use media or container queries that help us to determine the perfect layout for each screen size and all the steps in between.

Flexbox and Grid already give us layouts that can respond to changes in available space. A container can grow and shrink, items can wrap, and columns can adapt without us defining what should happen at every screen width.

Instead of designing only “desktop” and “mobile”, think about the hierarchy of the interface and how that hierarchy should respond when space becomes constrained. Typography is a good example. A heading doesn't necessarily need one font size on desktop and another completely different font size on mobile. CSS gives us tools like clamp() that allow a value to scale within a defined range.

The goal isn't to create a collection of screenshots that the developer has to somehow connect together. It's to define enough rules and constraints that the interface can behave sensibly in the space between those screenshots.

The container matters → container queries

The responsive design can be elevated even more with container queries.

We're probably more familiar with media queries in development, we use it for ages to create responsive designs. A media query looks at the viewport and asks how much space does the browser window have? Based on that, we can change the layout.

But CSS gives us cool tools these days, and we can be more explicit on our responsive designs. Container queries ask a different question: How much space does this component actually have?

Imagine we have a card component. On a large screen, the card might have enough space to show an image next to its content. But the same card could be placed inside a narrow sidebar, where that layout no longer makes sense.

With a media query, the component would respond to the size of the screen. With a container query, it can respond to the space that is available to the component itself.

Beyond the handoff

The goal isn't for the designers to become developers, or vice versa. A designer doesn't need to know how to write grid-template-columns, and a developer doesn't need to know how to create a perfect Figma component.

The goal is to understand enough of each other's world to share a mental model of what's being built. A good handoff isn't just a Figma link with a list of measurements, colors, and font sizes. Yes, all of these are useful, but they merely describe the result.

What matters more is understanding the intention behind the design. The bridge between design and development isn't the handoff, but a shared mental model.

What two months of interviewing taught me about the 2026 tech job market

Alexandra — Fri, 28 Aug 2026 11:40:20 +0000

July wasn’t a particularly pleasant month for me.
I was affected by the restructuring of the company I was working for, which meant going back into a job market I would politely describe as insane.

Over the past two months, I’ve interviewed mostly for frontend, SWE and full-stack engineering roles, and I’ve noticed quite a few things that feel very different from the last time I was interviewing, around two years ago.

I should preface this by saying that I’m not the best interviewee. My job is to be an engineer, not a professional interviewee or leetcode solver. I’m an introvert, and the job market increasingly requires a lot of soft skills: having a "brand", marketing yourself, selling your experience, being charismatic, thinking on-the-fly ideas and presenting yourself as the perfect candidate.

None of that necessarily reflects how good you are at your actual job, and when the interview itself is stressful, that gap becomes even bigger.

1. The expectation is to be the perfect fit

In older interviews I had, there seemed to be more room for learning or better said "potential". You didn’t have to possess all the skills but to be eager to learn. Now, I’m seeing much more of: “You don't have exactly the experience we're looking for? Rejected.”

If you don't match a large part of the job description already, there doesn't seem to be much appetite to invest in someone who could grow into the role.

Maybe this is simply the market correcting itself after years of aggressive hiring, but I do wonder whether we’re losing some of the willingness to hire for potential.

2. Interviewing well seems to matter more than engineering well

To me this is one of the biggest frustrations on the job market right now. Interviews are artificial environments. You are asked to produce your best answer, code, idea, product, under pressure, with very little time to think.

And yet we seem comfortable treating performance in that environment as a proxy for engineering ability.

In one interview, I received feedback that I had frozen because interviewing is stressful for me, and that saying “I don't know” when nothing immediately came to mind wasn't a good signal.

But isn't being able to say “I don't know” actually an important engineering skill?

I would much rather work with someone who says:
“I don't know yet. Let me investigate.”
than someone who confidently makes something up because they think that's what the interview expects.

3. Companies want you to be everything and salaries don't necessarily reflect it

The scope of some of the roles I've seen has become… ambitious. Frontend. Backend. Product. Design. Talking to customers. Making technical decisions. Owning the roadmap. Using AI. Moving independently.

Basically: be the engineer, product manager, designer and mini-CEO of your area. Don't get me wrong that's not necessarily a bad thing, I actually like having ownership.B

ut when a company expects one person to cover what used to be several different roles, I think it's fair to ask whether compensation and expectations have kept up with that change. Instead i see the salaries and budgets have..decreased?

Especially in expensive cities like Amsterdam.
You can live somewhere cheaper, that's true, but then you often trade money for commuting time, which is another cost.

4. Some job advertisements don't feel real

Many of the job descriptions are not real (or better said don’t feel real). Or if they are real, I’ve seen them sitting open for months.

I've seen job descriptions asking for extremely specific combinations of experience. And I've seen companies seemingly looking for a unicorn while complaining that they can't find people.

Maybe they really can’t find talent? Or there is so much talent in the market that they don’t know what to do? Or do they ask for the impossible? Or are some of these roles not really intended to be filled in the first place?

Because right now, we somehow have a situation where companies say they can't hire, while qualified people say they can't get hired.

5. Job applications have become unnecessarily enormous

We've all joked about uploading your CV and then being asked to manually enter every single thing that's already in your CV. Tbh, that's not even a big problem anymore.

Most roles have open-ended questions. With the dreaded “What excites you about this role?” being on the top of the list, which "paying my rent and bills" is not necessirily an answer to.

And then, my personal favourite (approaching the word pet-peeve):
Record a 2-4 minute video answering X question.

Have you ever spoken to an engineer before? Some of us are already fighting for our lives in a live coding interview. Now you want a casting audition too? I didn’t know i was getting hired to be an actor.

6. Job descriptions are generally bad

An other trend i see is an abundance of startups got their first founding engineers, followed by job descriptions that are obviously AI-generated. Five paragraphs of corporate language that nobody understands following 37 technologies in must-haves. You should of course move fast, own end-to-end, thrive in ambiguity, be 20x engineer and 45x productive.

My brain has already left the building.

And then companies complain about receiving hundreds of generic, AI-generated applications. But if you put little thought into the job description, why should candidates put significantly more thought into their application?

You get as much effort as you put into it.

These are simply observations from my own experience over the last two months, and I'm genuinely curious whether other engineers are seeing the same thing.

Maybe it's the AI transition/psychosis. Maybe it's a correction after the hiring frenzy of the 2020 mass hiring. Or maybe I'm just particularly unlucky with interviews. 😅

What have you noticed in the 2026 tech job market that feels different from a few years ago?

HTML is getting cool again: Meet the Invoker Commands API

Alexandra — Sat, 22 Aug 2026 10:55:26 +0000

For years, frontend development has had a slightly embarrassing relationship with HTML. We all read about semantic HTML, we talk about using the right landmarks, the right attributes, accessible forms, and meaningful elements. And then we go back to writing React.

While the whole industry is obsessed with AI, browsers are shipping features that make the platform even more capable. Features that let us remove JS, reduce state, and express UI behaviour in HTML. But since AI is trained in the past, these are ignored or not recommended enough through old patterns.

State boilerplate to open a dialog

Historically, in order to open a dialog or a popover, we need a chunk of custom boilerplate code.

<button id="open-dialog">Open dialog</button>
<dialog id="my-dialog">
  <p>Dialog content</p>
  <button id="close-dialog">Close</button>
</dialog>

<script>
  const dialog = document.getElementById("my-dialog");
  document.getElementById("open-dialog").addEventListener("click", () => {
    dialog.showModal();
  });
  document.getElementById("close-dialog").addEventListener("click", () => {
    dialog.close();
  });
</script>

We need a button to open our dialog, the dialog itself, and then we write JS to explain the interaction to the browser: "When the user clicks the button, open the dialog".

If you're using React or Vue, this can get even more elaborate: You need some custom state, potentially pass it to your component, wire up an event handler, and then make sure everything stays in sync.

Whether vanilla or framework, the code above is completely reasonable on its own, every frontend developer has written something similar a hundred times. But after writing it for the thousandth time, it made me wonder: do we really need application state to represent that a dialog is open? The answer is: it depends. Sometimes state is needed. But sometimes we're just rebuilding behaviour that HTML and the browser can already provide for us out of the box in 2026.

Enters the chat: the Invoker Commands API

The Invoker Commands API provides us a way to declaratively assign behaviours to buttons, which then allows us to control these interactive elements. Instead of adding an event listener we can describe the relationship directly in HTML.

The attributes that help us are commandFor and command:

commandFor: turns our button into a "command invoker". It takes the ID of the element to control as its value.
command: Specifies the action to be performed on that element.

<button commandfor="mycoolpopover" command="toggle-popover">
  Toggle the popover
</button>
<section id="mycoolpopover" popover>
  <button commandfor="mycoolpopover" command="hide-popover">Close</button>
  Awesome Popover content
</section>

How to do it in React?

All of these are transferable to your framework of choice:

export function DeleteButton() {
  return (
    <>
      <button command="show-modal" commandFor="delete-dialog">
        Delete account
      </button>
      <dialog id="delete-dialog">
        <h2>Delete account?</h2>
        <p>This cannot be undone.</p>
        <button command="close" commandFor="delete-dialog">
          Cancel
        </button>
      </dialog>
    </>
  );
}

The important detail here is that React's JSX property is commandFor, while the resulting HTML attribute is commandfor

Is that a really big deal?

At a first glance this looks like saving, maybe 10 lines of code. That's nice. But the most interesting is the shift of the responsibilities from us, back to the browsers.

The browser isn't becoming less capable because we're writing less JavaScript, but rather the opposite. We finally need less JS.

Browser support

Now, before everyone starts deleting their dialogs, there is a small catch: The Invoker Commands API is new. MDN currently lists it as Baseline 2025, with cross-browser availability in the latest browser versions since December 2025. Older browsers may not support it.

References

How Many Introductions Away Are You From Pedro Pascal? A Practical Introduction to Graph Search

Alexandra — Tue, 11 Aug 2026 14:05:24 +0000

I was watching The Mandalorian the other day when it struck me that I don't know Pedro Pascal, which is, by itself, very tragic.

But maybe I know someone, who knows someone, who knows someone, ..., who knows Pedro Pascal. Somewhere out there, there is a finite chain of introductions that connects me to him. So the important computer science question we try to solve today is: How many introductions would it take to reach him?

We accidentally have invented a graph problem!

Turn your social life into a graph

Imagine that each person on this earth is a node and any relationship or acquaintance between two people is an edge:

Alexandra ── Maria ── Sofia ── Pedro
    │
    └── John ── Elena ── Carlos

This is an unweighted and undirected graph.

Unweighted means that every connection counts the same. We don't care whether Maria is Sofia's best friend or someone she met once at a cafe.
Undirected means the relationship is both ways: if Alexandra knows Maria, Maria knows Alexandra.

If we strip the fluff of the original question, it kinda changes from "How do I meet Pedro Pascal?" to "Given an unweighted graph, what is the shortest path between node A and node B?", which if you are familiar with trees or graphs it sounds like a BFS (Breadth-First Search).

In code, the simplest way to represent this kind of data is an adjacency list

const graph = {
  Alexandra: ["Maria", "John"],
  Maria: ["Alexandra", "Sofia"],
  Sofia: ["Maria", "Pedro"],
  Pedro: ["Sofia"],
  John: ["Alexandra", "Elena"],
  Elena: ["John", "Carlos"],
  Carlos: ["Elena"],
};

Make our delusions an algorithm

Unfortunately, screaming “DOES ANYONE KNOW PEDRO PASCAL?” into the void isn't an algorithm. It has no order, no memory, and no stopping condition. If you just wander from person to person picking whoever seems interesting, you can easily do this:

Alexandra → Maria → Sofia → Maria → Sofia → Maria → ...

Because the graph is undirected, Maria connects back to Sofia and Sofia connects back to Maria. Without remembering who we met already, nothing stops us from revisiting the same people forever.

So we basically need two things:

A rule for what order to explore people in.
A way to remember who we already visited.

That's where a queue and a visited set come in.

Breadth-first search explained

The key observation for finding the shortest path is this: check everyone one connection away before checking anyone two connections away. This is breadth-first search, and it organizes the graph into levels:

Level 0        Alexandra
                  │
           ┌──────┴──────┐
Level 1   Maria          John
            │              │
Level 2   Sofia          Elena
            │
Level 3   PEDRO 🎉

BFS will check all my direct friends (level 1), if Pedro isn't there (🥲) will check the direct friends of my direct friends (level 2) and so on. The moment Pedro is found, you know that this is the shortest possible path, because every shorter one has already been checked.

Put everything together


function introductionsAway(graph, start, target) {
  if (start === target) return { degrees: 0, path: [start] };

  const visited = new Set([start]);
  const queue = [[start, [start]]]; 

  while (queue.length > 0) {
    const [person, path] = queue.shift();

    for (const friend of graph[person] || []) {
      if (visited.has(friend)) continue;
      if (friend === target) {
        return { degrees: path.length, path: [...path, friend] };
      }

      visited.add(friend);
      queue.push([friend, [...path, friend]]);
    }
  }

  return { degrees: -1, path: [] };
}

The twist: real relationships aren't equal

So far in our problem knowing someone is binary. But you and I both know that's a lie. There's a biiiig difference between:

Maria once stood next to Pedro at an event, and
Pedro? Yeah, we're having dinner every Thursday.

Technically, both are relationships but practically, one of them is significantly more useful to my mission.

Alexandra --2-- Maria --5-- Sofia --4-- Tessa --1-- Pedro

So let's assign every relationship an introduction cost. A close relationship has a low cost because asking for an introduction is easy. A weak acquaintance has a high cost because... well, good luck with that.

The BFS algorithm doesn't know how to handle weights. For weighted graphs, we need to move our attention to Dijkstra's algorithm.

Dijkstra's algorithm, briefly

Dijkstra's algorithm asks a slightly different question:

"What is the cheapest path from A to B?"

Instead of exploring nodes in the order we discover them, we prioritize the node who currently has the lowest accumulated cost from our starting point.

That usually means replacing BFS's regular queue with a priority queue.

Same graph, different nouns

The Pedro Pascal situation is ridiculous, i know, but the underlying problem isn't. Change what the nodes and edges represent, and suddenly the same ideas appear everywhere.

Domain	Nodes	Edges	What "shortest path" answers
Social graph	People	Relationships	"How many introductions to Pedro Pascal?"
Maps / GPS	Intersections	Roads (weighted by time/distance)	"Fastest route from A to B"
Web crawling	Web pages	Hyperlinks	"How many clicks from this page to that one?"
Codebases	Modules/files	Imports/dependencies	"What breaks if I change this file?"
Recommendations	Users or items	Similarity/interaction strength	"What's most relevant to this user?"

Graphs are one of those computer science concepts that you initially hate and mostly dont understand. Nodes. Edges. Traversals. Queues. But they are everywhere.. The internet itself is basically one very big graph.

And if by any chance anyone knows someone who knows someone... You know where to find me.

Frontend system design interviews are weird. Here’s how I now approach functional requirements.

Alexandra — Sat, 08 Aug 2026 16:40:25 +0000

One of the worst types of interviews for me is the system design. It feels overwhelming, even though i studied computer science, i took all the network and operating systems and DBMS courses. I have an idea on how to explain what a distributed system is. Put me in an interview, though, and sometimes my brain just goes blank.

So usually in these interviews you either get a screenshot or you're given a broad prompt like:

Design a notification system.
Design a URL shortener
Design netflix

On one hand, you're thinking that these systems took entire teams years to design. On the other, your brain is already jumping to WebSockets, caching, React state, API endpoints, databases, pagination, and whether you're somehow expected to know how many servers Instagram has.

Let's take a step back. Before deciding how we are going to build something, we need to know what we are building. So let me introduce you to.. functional requirements.

What are functional requirements?

Functional requirements describe what a system should allow its users to do. You have to clarify what the capabilities of the product is and how it should behave without knowing or specifying how these will be implemented.

Design a notification system for a web application

This is very broad, and give this prompt to 10 people and you'll get 10 different sets of requirements. So what a 'notification system' means? Are these notification real-time? Can users interact with them? Do we need to keep a history? Can users mark them as read? Do they disappear?

Before drawing a single architecture box, we need to establish the scope of the problem we are talking about.

A first set of functional requirements could be:

Users can receive notifications.
Users can view their notifications.
Users can mark a notification as read.
Users can mark all notifications as read.
Users can navigate from a notification to a details page.
Users can see how many unread notifications they have.
Users can receive new notifications without manually refreshing the page.

Functional vs non-functional requirements

This distinction becomes particularly important in system design interviews.

Functional requirements describe what the system does.
Non-functional requirements describe how well the system needs to do it or the constraints under which it operates.

For our notification system, these could include:

Functional requirement	Related non-functional concern
Receive new notifications	Updates should appear with low latency
View notification history	Large histories should load efficiently
Mark notifications as read	UI updates should feel immediate
See unread count	Count should remain consistent across the application
Open related content	Navigation should be reliable and accessible

Accessibility, performance, reliability, scalability, browser support, and latency are usually concerns that influence our architecture without defining the product feature itself. Usually all of these are non-functional requirements.

Don't accept the prompt as the specification

One of the most important things to remember in a system design interview is that the interview prompt is usually intentionally incomplete. You don't get a specification, you have to deduct it with your interviewer. The most important thing in these type of interviews is to ask questions.

For example good questions in our example could be:

What kinds of notifications are we supporting?
Do notifications need to arrive in real time?
Do users need access to their notification history?
Can notifications be deleted?
Do we need read/unread state?
Should notifications synchronize across multiple tabs or devices?
How many notifications might a user receive?
Are we designing only the web experience, or mobile too?

If the interviewer tells you that notifications only need to update when the page reloads, your architecture will look very different from a system expected to deliver millions of real-time updates.

Make assumptions explicit

Sometimes the interviewer won't give you every answer, and leave it up to you. So at this point inevitable you will make an assumption. Make an assumption and say it out loud.

For example:

I'll assume we're designing the web notification center, notifications should arrive while the application is open, users can mark them as read, and we're not covering email or push notifications.

That single sentence dramatically reduces the problem scope.

Now instead of designing Every Notification System Known to Humanity, we're designing something concrete. This is one of the reasons functional requirements are so useful: they establish the boundaries of the system.

Requirements drive architecture

Once we understand the requirements, technical decisions start having a reason to exist.

Suppose one requirement says:

Users should receive new notifications while using the application without refreshing the page.

Now we have a technical problem to solve.

How our system can solve this concrete problem? We could consider:

polling
Server-Sent Events
WebSockets

So, we didn't jump immediately to a conclusion to use Websockets? We derived it from a user requirement and the architecture followed.

Users can view older notifications.

Now we need to think about pagination and data fetching.

Users can mark notifications as read.

Now we need to think about mutations, optimistic updates, error handling, and synchronization.

Users can see their unread count throughout the application.

Now we need to think about where that state lives and how different parts of the UI stay consistent.

From requirements to frontend architecture

A useful way to think about the process is:

Functional requirements
        ↓
User flows
        ↓
Data model
        ↓
API contracts
        ↓
Client architecture
        ↓
State management
        ↓
Rendering & performance
        ↓
Accessibility

These aren't perfectly isolated steps. Real systems are messy, requirements change, and decisions influence each other. But we move from a non defined problem to an architectural decision.

Going back to our notification example: the user flow "click the bell, see 5 unread, mark one, count drops to 4" already forces a data model decision about where read/unread state lives, which in turn shapes the API contract and how the client keeps that count in sync. Each arrow in the pipeline above is really a question you're answering, not just a step you're passing through.

Functional requirements also protect your scope

System design prompts can become enormous very quickly.

For example:

Design Instagram.

What does that even mean? The feed? Posting photos? Stories? Profiles?

It's impossible trying to design all of Instagram in a 45-minute interview, despite what all the vibe coders tell you.

Perhaps we can agree with the interviewer that we are designing the home feed and narrow down the problem to:

Users can view posts from accounts they follow.
Users can continuously load older posts.
Users can like a post.
Users can open a post.
Users can see new content when it becomes available.

And booom...now we have something we can actually design.

Start with "what", then design "how"

System design interviews aren't a competition to mention the largest number of technologies before the clock runs out. They're about making engineering decisions under incomplete information.

Functional requirements give those decisions context.

Suddenly, you're not designing Netflix anymore but a specific set of behaviours with specific problems to solve.

And once you know what you're building, reasoning about how to build it becomes a lot less scary.

At least that's what I'm trying to teach my brain before my next system design interview. 😅

The 10 JS Topics Every Frontend Engineer Should Know

Alexandra — Wed, 05 Aug 2026 08:20:52 +0000

Maybe AI is THE "hot" topic, but interviews are as old as ever. As i am studying for that said interviews, I compiled a list of 10 JS topics I think that are very crucial to prove the understanding of. These are topics I have been asked or ask during my 10 years in tech🤗.

1. Execution Context & Hoisting

Level: Very common. I have been asked about hoisting so much during all my years of experience.

Before JS runs your code, it creates an execution context. A new context is created when a program starts or when a new function is executed. During this phase it allocates memory for variables and functions. var variables are hoisted and initialised as undefined, while let and const are hoisted but remain in the Temporal Dead Zone until their declaration.

Example

console.log(a); // undefined
var a = 5;

Resources

2. Closures

Level: Common. Mostly asked to mid FE.

A closure happens when a function remembers variables from the scope where it was created, even after that outer function has finished executing.

Example

function counter() {
  let count = 0;

  return function () {
    count++;
    return count;
  };
}

const increment = counter();

increment(); // 1
increment(); // 2

Classic interview example :

let result = [];
for (var i=0; i<10; i++) {
    result[i] = function() {
      console.log(i,);
    }
}
result[0](); // 10
result[1](); // 10

let result = [];
for (let i=0; i<10; i++) {
    result[i] = function() {
      console.log(i,);
    }
}
result[0](); // 0
result[1](); // 1

Resources

3. The Event Loop

Level: Very common. Asked at every level. Usually as questions "predict the output" like the one below.

JS is single threaded, meaning it runs one line of code at a time. The Event Loop decides when callbacks (macrotasks, think timers) or promises (microtasks) are allowed to run after the current code (executed in the call stack) has finished.

Example

console.log(1);
setTimeout(() => console.log(2), 0);
Promise.resolve().then(() => console.log(3));
console.log(4);

// Output:
// 1
// 4
// 3
// 2

Resources

4. Promises & Async/Await

Level: Very common. Understandably, there is no way to not have async behaviour in an app in 2026.

Promises represent work that will finish later. async and await is syntactic sugar for promises that let you write asynchronous code that looks like synchronous code.

Example

async function getUser() {
  const response = await fetch("/api/user");
  return response.json();
}

Resources

5. `this` Keyword

Level: Common. Mostly junior to mid FE.

this refers to the object that is calling the function. Its value
depends on how the function is invoked.

Example

const user = {
  name: "Alex",
  greet() {
    console.log(this.name);
  }
};

user.greet(); // Alex

Resources

6. Objects & Recursion

Level: Less common as trivia, but shows up in live coding (deep clone, tree traversal, flattening nested objects).

Recursion is when a function calls itself. It's useful for traversing
nested objects or tree-like structures.

Example

function countDown(n) {
  if (n === 0) return;
  console.log(n);
  countDown(n - 1);
}

Resources

7. Arrays & Data Manipulation

Level: Very common. You need to know how to manipulate data.

Frontend applications constantly read and manipulate API data. Methods like map, filter, and reduce make this easier.

Example

const users = [
  { name: "Alice", active: true },
  { name: "Bob", active: false }
];

const activeUsers = users.filter(user => user.active);

Resources

8. Browser Rendering & Performance

Level: Less common. Mostly senior or performance-focused roles.

The browser converts HTML, CSS, and JavaScript into pixels on the
screen. Efficient updates reduce unnecessary layout and painting work.

Example

requestAnimationFrame(() => {
  element.style.transform = "translateX(100px)";
});

Resources

9. Event Propagation

Level: Common. Mid FE and up.

Events travel through the DOM. They first capture down the tree, then
bubble back up. Event delegation uses bubbling to handle many events with one listener.

Example

document.body.addEventListener("click", (event) => {
  console.log(event.target);
});

Resources

10. Memory Management

Level: Less common as a direct question, but senior interviews may have a "why is this leaking?" scenario.

JavaScript automatically frees unused memory, but objects can stay alive if something still references them, such as an event listener or timer.

Example

button.addEventListener("click", handleClick);

// Later when no longer needed
button.removeEventListener("click", handleClick);

Resources

MDN — Memory management
Chrome DevTools — Fix memory problems (hands-on: heap snapshots, detached DOM nodes)
web.dev — Memory leaks in web apps

Repaint vs Reflow: A Simple Explanation

Alexandra — Mon, 03 Aug 2026 13:34:46 +0000

What's happening when a website loads?

When you visit a website, your browser reads the code, it creates the DOM, it reads the CSS, it builds the CSSOM, figures out where everything should go, and then draws it on your screen. This process includes two main concepts: repaint and reflow.

What is a repaint?

A repaint happens when you change the appearance of an element, but NOT the sizes or positions. Think it as changing a text or background color, opacity, borders or box shadows.

element.style.color = "blue";
element.style.backgroundColor = "yellow";

When this happens, the browser just needs to redraw the pixels on screen. In general, this is somewhat fast.

What is a reflow?

A reflow (or "layout") happens when you change the size or position of an element. Think about it as a result of changing width, height, padding or margins, adding or removing elements from the page, showing/hiding elements with display property, or changing the font size.

newElement.style.width = "500px";
newElement.style.padding = "20px";
document.body.appendChild(newElement);

When this happens, the browser has to:

Recalculate where everything should be
Figure out the new size of elements
Update all the affected elements
THEN repaint everything

That's why reflows are a bit expensive.

Why Should We Care?

Both repaints and reflows make the browser do work, which can make your website feel slow, especially when you trigger them often.

Imagine you're building a feature that updates a user's score:

for (let i = 0; i < 100; i++) {
  element.style.width = (100 + i) + "px";  // Reflow!
  element.textContent = i;                  // Reflow!
}

Every loop iteration triggers a reflow because we're changing the width and content. That's 100+ potential reflows! Modern browsers do batch some of these automatically, but you still want to minimize layout recalculations.

element.textContent = 99;
element.style.width = "199px";

Prefer to do all the changes at once. The browser will likely batch these into a single reflow cycle instead of triggering multiple sequential ones.

Tips to Avoid Performance Problems

Batch your changes

   // Good
   element.style.cssText = "width: 100px; height: 100px; color: red;";

   // Not as good
   element.style.width = "100px";
   element.style.height = "100px";
   element.style.color = "red";

Avoid reading layout properties in loops

  // Bad — alternating reads and writes force recalculation
for (let i = 0; i < elements.length; i++) {
  const currentWidth = elements[i].offsetWidth;  // READ — forces layout recalculation
  elements[i].style.width = (currentWidth + 10) + "px";  // WRITE — invalidates layout
}

// Good — batch all reads first, then writes
const widths = Array.from(elements).map(el => el.offsetWidth);
widths.forEach((width, i) => {
  elements[i].style.width = (width + 10) + "px";
});

Use classes instead of inline styles (similar with 1)

   // Good — batches all CSS changes together and is more maintainable
element.classList.add("highlighted");

// Not as good — multiple individual property assignments can trigger separate reflows
element.style.color = "blue";
element.style.backgroundColor = "yellow";
element.style.fontWeight = "bold";

CSS classes batch multiple properties into a single reflow cycle, and keep your styling logic separate from your JavaScript.

Use transforms for animations

   // Good for animations
   element.style.transform = "translateX(100px)";

   // Causes reflow
   element.style.left = "100px";

Transforms are cheaper because they skip the Layout and Paint phases of the rendering pipeline and only trigger Composite (which happens on the GPU). Position changes like left, top, width, and height require the browser to recalculate the entire layout.

Use requestAnimationFrame for Coordinated Updates

When you need to perform multiple DOM reads and writes in animations, use requestAnimationFrame to ensure they're batched together in the browser's rendering cycle:

// Good — batches all changes into one frame
requestAnimationFrame(() => {
  elements.forEach(el => {
    el.style.transform = "translateX(100px)";
  });
});

// Less efficient — each update happens immediately, may cause multiple recalculations
elements.forEach(el => {
  el.style.transform = "translateX(100px)";
});

Modern Browser Considerations

Browsers have become smarter about batching DOM operations. Modern engines like V8 (Chrome) and SpiderMonkey (Firefox) automatically defer and batch layout recalculations to some degree. However, this doesn't mean poor practices are harmless, you can still force synchronous reflows by reading layout properties like offsetWidth, clientHeight, or getBoundingClientRect() immediately after writing styles. Avoiding these patterns ensures your code stays performant across all browsers and circumstances.

The Bottom Line

☑️ Repaint = Change colors/appearance → relatively fast
☑️ Reflow = Change size/position/layout → slower, more expensive
☑️ Both slow down your site if you do too many
☑️ Group changes together when possible
☑️ Use CSS transforms for animations

Next time a website feels slow, there's a good chance it's because the browser is constantly doing reflows and repaints.

[Boost]

Alexandra — Mon, 03 Aug 2026 11:48:39 +0000

Alexandra

Jul 20

Does the web feel slower these days?

4 min read

The Comfort Atlas: What Does Home Taste Like?

Alexandra — Sat, 01 Aug 2026 21:19:16 +0000

This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing

What I Built

The Comfort Atlas is a spinning 3D globe of comfort food from ~100 countries.

Virtually travel the globe and have a taste of the comfort foods from 100~ countries. Moussaka in Greece, Jollof Rice in Nigeria, Pho in Vietnam. There is also a "featured dish of the day" that rotates deterministically so it's the same for everyone visiting that day. And the fun feature: visitors can type in their own comfort dish and generate a downloadable, passport-stamp-style card in one of three color styles.

Demo

https://comfort-atlas.netlify.app/

Journey

I started with a flat SVG world map, clickable countries, keyboard support, a hover tooltip on the map, all built on real elements so accessibility came for free. It worked fine, but it looked very meh.

So i decided to try something i have never done before. Make a globe! I used cobe which promised a 3D globe out of the box. First attempt rendered absolutely nothing but floating dots. 😂 With a lot of the help of my friend claude, we found out that their docs are outdated, and there is a createGlobe() that draws exactly one synchronous frame and expects you to drive a requestAnimationFrame loop calling .update() yourself.

Two things on the globe I'm proud of, because neither had any library support: a hover tooltip that tracks a marker in 3D space, and a fading "trail" of great-circle arcs between the countries you've visited. Both came down to translating the projection math out of a minified bundle into something readable.

What I would do next: dark mode, enrich the content, comfort food battles per country.

What I learned: a lot about accessibility in 3D/canvas, which is so much more difficult than the 2d one, one check for a11y is never enough. Maps are hard, and getting something to track a moving 3D object from regular DOM is even harder.

Licensed under MIT

Fun fact: I don't like Moussaka, even though i am greek, my comfort food is Pizza or Giouvetsi. xD

DEV Community: Alexandra

The Curiosity Gap: Why We've Stopped Asking Questions

AI psychosis might be a result of subscription fatigue

The subscription problem

Two Types of AI Enthusiasm

AI Didn't Democratise Software

Software Isn't Always the Product

The Software We Never Built

What Actually Changes?

What do you build when you can build anything?

The Cost of Building Everything

Welcome to Agency Hell

What Do You Actually Care About?

Possibility Isn’t Purpose

From Figma to the browser: building a shared mental model

The canvas vs. the browser

Auto Layout → Flexbox

When one dimension isn't enough → CSS Grid

Designing for change → responsive layouts

The container matters → container queries

Beyond the handoff

What two months of interviewing taught me about the 2026 tech job market

1. The expectation is to be the perfect fit

2. Interviewing well seems to matter more than engineering well

3. Companies want you to be everything and salaries don't necessarily reflect it

4. Some job advertisements don't feel real

5. Job applications have become unnecessarily enormous

6. Job descriptions are generally bad

HTML is getting cool again: Meet the Invoker Commands API

State boilerplate to open a dialog

Enters the chat: the Invoker Commands API

How to do it in React?

Is that a really big deal?

Browser support

References

How Many Introductions Away Are You From Pedro Pascal? A Practical Introduction to Graph Search

Turn your social life into a graph

Make our delusions an algorithm

Breadth-first search explained

Put everything together

The twist: real relationships aren't equal

Dijkstra's algorithm, briefly

Same graph, different nouns

Frontend system design interviews are weird. Here’s how I now approach functional requirements.

What are functional requirements?

Functional vs non-functional requirements

Don't accept the prompt as the specification

Make assumptions explicit

Requirements drive architecture

From requirements to frontend architecture

Functional requirements also protect your scope

Start with "what", then design "how"

The 10 JS Topics Every Frontend Engineer Should Know

1. Execution Context & Hoisting

2. Closures

3. The Event Loop

4. Promises & Async/Await

5. this Keyword

6. Objects & Recursion

7. Arrays & Data Manipulation

8. Browser Rendering & Performance

9. Event Propagation

10. Memory Management

Repaint vs Reflow: A Simple Explanation

What's happening when a website loads?

What is a repaint?

What is a reflow?

Why Should We Care?

Tips to Avoid Performance Problems

Modern Browser Considerations

The Bottom Line

Further Reading

[Boost]

Does the web feel slower these days?

The Comfort Atlas: What Does Home Taste Like?

What I Built

Demo

Journey

5. `this` Keyword