Forem: Ceci Olivera

As We May Code: Why Software Is a Human Problem Dressed in Logic

Ceci Olivera — Thu, 16 Apr 2026 21:29:21 +0000

On interfaces, accessibility, wicked problems, and the illusion that machines can write code for us.

The first time I used NotebookLM, I fed it an essay I'd been meaning to read for months: Vannevar Bush's "As We May Think," published in The Atlantic in 1945. I knew it was the essay that predicted the internet. What I didn't know was that it was about something much more fundamental.

Bush's central concern was that humanity generates knowledge faster than any individual can absorb it — that the collective output of science, culture, and experience had outgrown the tools we had for navigating it. He proposed a machine called the Memex to help: not a machine that thinks for us, but one that helps us think. A tool for making associative trails through the ever-expanding record of human knowledge, mirroring the way thought actually moves — by meaning, by context, not by alphabetical index.

The synchronicity wasn't lost on me. I was using an AI tool to navigate a piece of that very record, to absorb an essay I hadn't found the time to read. And the tool worked. It helped me absorb the essay faster, make connections, follow the thread. It was doing, in a small way, what Bush imagined eighty years ago: amplifying my thought, not replacing it.

But here's what stayed with me. Bush wasn't just predicting a technology. He was drawing a line. On one side: technology that extends what humans can do. On the other: technology that substitutes for what humans do. He was firmly, explicitly, on the side of amplification.

That line matters now more than ever. Because there is a quiet assumption that most people hold about software: that it is, fundamentally, a problem of logic. You define what you want, you write the rules, the machine executes them. Input, process, output. Deterministic. Clean.

This assumption is wrong. And it is the root of a much larger misunderstanding — one that shapes how we think about AI-generated code, about the role of developers, and about what it actually means to build something that people use.

I. The deterministic illusion

Software runs on deterministic machines. Given the same input, a CPU will produce the same output, every single time. This is a fact about execution, and it is what makes computers useful.

But somewhere along the way, we confused the nature of running software with the nature of creating it. Because the machine is deterministic, we assumed that building software must also be a deterministic process: define the requirements, translate them into code, compile, ship. A pipeline. A factory.

Fred Brooks dismantled this illusion in 1986. In "No Silver Bullet," he distinguished between two kinds of complexity. Accidental complexity is what we create ourselves — the friction of our tools, the limitations of our languages, the overhead of our processes. This is the complexity that better tools can eliminate. Essential complexity is something else entirely. It comes from the problem itself: from what the software needs to do, for whom, in what context, under what constraints. No tool can remove it, because it is not an artifact of the process — it is the substance of it.

Brooks's claim was radical and, forty years later, still widely misunderstood: the hard part of software is not writing code. The hard part is deciding what to build. And that decision is irreducibly human.

In 1992, Jack Reeves took this further with an essay that should be required reading for anyone who writes code. In "What Is Software Design?", he argued that source code is not the construction of software — it is the design. Compiling is construction: it's cheap, it's automatic, you press a button. But the act of writing code? That is a design activity. It is creative, contextual, full of trade-offs and judgment calls. It is, in the deepest sense, a human endeavor.

If code is design, then the developer is not a technician executing a blueprint. The developer is a designer making decisions that directly shape how people experience a product. Every line of code carries assumptions about who will use it, how, and why.

II. Interfaces are wicked problems

In 1973, Horst Rittel and Melvin Webber published a paper that gave vocabulary to something designers and planners had always felt but could never quite name. They called it "wicked problems" — not wicked in the moral sense, but in the sense of being deeply resistant to the kind of linear, analytical problem-solving that works so well in engineering and mathematics.

Wicked problems have no definitive formulation. They have no stopping rule — no signal that tells you the problem is solved. Their solutions are not true or false, only better or worse. Every attempt at a solution changes the problem itself. And they are essentially unique: what works in one context may fail in another.

User interfaces are wicked problems. Not metaphorically — structurally. Consider:

There is no single correct interface for any given task. The "right" design depends on the user, their device, their abilities, their context, their mental model, their culture, their patience, their internet connection.
Interfaces are never finished. Every new feature, every new user, every new device introduces new interactions, new edge cases, new failures.
You cannot test your way to a perfect interface. You can only test your way to a less wrong one, because the space of human variability is infinite.
Every design decision carries consequences that ripple outward. A color choice excludes people with low vision. A navigation pattern confuses people using screen readers. A gesture-based interaction locks out people with motor disabilities. A modal dialog that "works" for sighted users traps keyboard users in an invisible cage — or, conversely, lets their focus escape into a background that is supposed to be inert.

Richard Buchanan connected wicked problems to design thinking in 1992, arguing that what many people dismiss as "impossible" may actually be a failure of imagination — one that better design thinking can overcome. Don Norman, through decades of work from The Design of Everyday Things to Living with Complexity, showed that the complexity of our tools must match the complexity of our lives. Simplifying an interface beyond a certain point doesn't make it better — it makes it dishonest about the problem it's trying to solve.

The temptation, always, is to treat interfaces as tame problems. Define the requirements. Implement the spec. Check the boxes. Ship. But the users were never part of the spec, not really — not in all their unpredictable, embodied, diverse humanity.

III. HTML: the most human language in code

Here is something people rarely say about HTML: it is beautiful.

Not in the way that an elegant algorithm is beautiful, or a well-factored function. HTML is beautiful because it is a language of meaning. It is a declarative API — arguably the most successful one ever created — whose purpose is not to instruct a machine but to communicate intent.

When you write <nav>, you are not telling the browser to render a box. You are saying: this is navigation. When you write <button>, you are not just creating a clickable element — you are declaring that this element is interactive, that it can receive focus, that it responds to keyboard events, that it announces itself to assistive technology as something a person can press. A <button> carries decades of human expectations in six characters.

HTML is not a programming language in the classical sense. It has no conditionals, no loops, no variables. And yet it may be the most consequential language on the web, because it is the layer where machine logic meets human meaning. It is the interface between the accessibility tree and the person. Between the browser and the body.

And it is also, without question, the most widely written and most widely written poorly language on the web. Because it is forgiving. Because a <div> with an onclick looks the same as a <button> — to sighted users, on a good day, with a mouse. The damage is invisible until someone tries to navigate with a keyboard, or a screen reader, or a switch device. And by then, the developer has moved on.

This is the paradox: the language that carries the most human meaning is treated as though it carries the least. Because it "works." Because it renders. Because the tests pass.

IV. What the machines see

In 2024, Michael Fairchild at Microsoft built a tool to answer a simple question: when you ask an LLM to generate HTML for common UI components, how accessible is the result?

The answer, documented in the A11y LLM Eval project, is sobering. Without explicit accessibility instructions, most models score near zero. The average across all tested models is around 10%. Even the best-performing model only passes 41% of tests. And these are not obscure edge cases — they are fundamental patterns like forms, navigation, dialogs, and data tables.

An important caveat: these percentages do not mean "41% accessible according to WCAG." The tool evaluates code against axe-core (an automated accessibility scanner) plus a set of custom assertions per component. But automated tools can only catch a fraction of real accessibility barriers — perhaps 30-40% of WCAG criteria. Everything that requires human judgment — whether the reading order makes sense, whether an alt text is actually meaningful, whether a focus management pattern is appropriate for the context, whether the right ARIA design pattern was chosen — is beyond what any scanner can measure. So when we say "90% pass rate with good instructions," we mean 90% of the automatable tests pass. The full picture still requires a human who understands what accessible means.

Fairchild is explicit about this: these tests do not fully evaluate WCAG or guarantee accessible results. Manual testing remains essential.

With that caveat in mind, the results are still revealing. Why do models perform so poorly by default? Because approximately 95% of websites have accessibility issues. The training data is the web, and the web is broken. LLMs don't learn what HTML should be — they learn what HTML is, statistically. And statistically, it's <div> soup.

But Fairchild's research reveals something even more interesting. When you add explicit accessibility instructions — custom instruction files that tell the model to use semantic HTML, follow WCAG, ensure keyboard support — the automatable pass rates jump dramatically. A minimal instruction ("All output MUST be accessible") alone produced an 18 percentage point improvement. Detailed, expert-level guidance pushed some models from near-zero to over 90%.

Think about what this means. The models can generate code that passes automated checks. The knowledge is somewhere in the weights. But without a human explicitly asking for it — without someone who understands accessibility framing the problem — the model defaults to the statistical average. The inaccessible average. And even at its best, it still cannot evaluate the things that matter most: the human things, the contextual things, the wicked things.

This is not a bug. This is the fundamental nature of what LLMs do: they index. They find the most probable pattern given the input. Vannevar Bush warned us about this in 1945 — that the artificiality of indexing systems would always be a poor substitute for the associative, contextual, meaning-driven way humans actually think. LLMs are the most sophisticated indexing system ever built. They are extraordinary at finding what is common. They are structurally incapable of understanding what is right.

V. The old tension, resurfaced

There is a deeper reason why AI struggles with interfaces and accessibility, beyond training data. Interfaces are fundamentally human problems. They are wicked problems where context, intent, and user behavior all shape what the right solution looks like.

A modal is not a modal because of its markup. It is a modal because of what it means to the user in that moment: stop, pay attention, deal with this before you continue. A role="status" is not a technical annotation — it is a social contract: this information changed, and you should know, but I won't interrupt you. These are not pattern-matching problems. They are problems of human communication, encoded in HTML.

AI approaches this as a statistical exercise: given this prompt, what code is most likely? But accessibility — and interface design more broadly — requires understanding why a pattern exists, not just what it looks like. It requires knowing that a person using a screen reader will navigate by headings, not linearly. That a person with low vision needs more than a change in opacity to perceive a state change. That a person with a motor disability needs every interactive element to be reachable by keyboard. That these are not edge cases — they are the full spectrum of how humans meet technology.

Kat Holmes calls this the "mismatch" — the idea that disability is not in the person but in the gap between the person and the design. Sara Hendren goes further: nearly everything we build is assistive technology, designed to bridge the gap between body and world. The question is whether we acknowledge this or pretend the gap doesn't exist.

What AI brings to the table is not a new problem. It is an old tension, resurfaced with new urgency: the temptation to reduce a human problem to pure logic. Herbert Simon dreamed of this in The Sciences of the Artificial — a world where design could be formalized, optimized, computed. Fred Brooks answered him: the complexity of software is essential, not accidental. You cannot abstract it away without abstracting away its meaning.

The illusion is seductive. If software were truly deterministic — if interfaces were tame problems with optimal solutions — then of course machines could write them better than we can. They are faster, cheaper, tireless. But interfaces are not tame. They are wicked. They involve bodies, contexts, cultures, disabilities, emotions, expectations. They involve people. And people resist reduction to statistics.

VI. As we may code

I started this essay describing a small moment: using an AI tool to read a text about the limits of human processing. The tool helped. It genuinely did. It compressed time, surfaced connections, let me absorb an 80-year-old essay in a fraction of the time it would have taken otherwise. Bush would have recognized it as a Memex — a machine that extends human thought.

But the understanding that came from that essay — the realization that its argument about amplification versus substitution was directly relevant to my own work in accessibility and code — that was not something the tool provided. That was association. That was meaning. That was the intricate web of trails carried by the cells of a brain that has spent years thinking about HTML, about screen readers, about the gap between what we build and who we build it for.

Eighty years after Bush, we have tools that can generate code at extraordinary speed. They can produce a login form in seconds, a dashboard in minutes, an entire landing page before you finish your coffee. But speed is not understanding. And production is not design.

The question Bush asked is still open: does our technology amplify human thought, or does it replace it? With LLMs applied to code, we are in danger of choosing the second option — not by conscious decision, but by the quiet assumption that software is a deterministic problem that machines can solve. It isn't. It never has been.

The developers, designers, and accessibility specialists who understand this are not being replaced by AI. They are becoming more essential. Because someone needs to write the custom instructions that turn a 0% automated pass rate into a 90% one — and then do the manual work that covers everything automation can't. Someone needs to know that a <dialog> is not just a <div> with a backdrop. Someone needs to understand that the user on the other side of the screen might not see, might not hear, might not use a mouse, might not think the way the designer assumed — and that this is not an edge case but the human condition.

HTML is a declarative API of meaning. The most successful one ever built. It was designed to be read by machines and understood by people. It is, in its quiet way, a bridge between logic and humanity. And the decision of which element to use — <button> or <div>, <nav> or <div>, <dialog> or <div> — is never a technical decision. It is a decision about who gets to participate.

References

Bush, V. (1945). "As We May Think." The Atlantic Monthly, July 1945.
Rittel, H.W. & Webber, M.M. (1973). "Dilemmas in a General Theory of Planning." Policy Sciences, 4(2), 155–169.
Brooks, F. (1986). "No Silver Bullet: Essence and Accident in Software Engineering." Proceedings of the IFIP Tenth World Computing Conference.
Reeves, J.W. (1992). "What Is Software Design?" The C++ Journal.
Buchanan, R. (1992). "Wicked Problems in Design Thinking." Design Issues, 8(2), 5–21.
Norman, D. (2013). The Design of Everyday Things. Revised and expanded edition. Basic Books.
Norman, D. (2010). Living with Complexity. MIT Press.
Simon, H. (1996). The Sciences of the Artificial. 3rd edition. MIT Press.
Holmes, K. (2018). Mismatch: How Inclusion Shapes Design. MIT Press.
Hendren, S. (2020). What Can a Body Do? How We Meet the Built World. Riverhead Books.
Fairchild, M. (2026). "Embedding Accessibility into AI-based Software Development." Tool: github.com/microsoft/a11y-llm-eval.

Your Accessibility Overlay Is a Scam (And Here's the Proof)

Ceci Olivera — Sun, 25 Jan 2026 18:46:44 +0000

You've probably seen them: that little wheelchair icon floating in the corner of websites, promising "accessibility" with one click. Maybe your company even pays for one. Products like accessiBe, UserWay, EqualWeb, and AudioEye promise to make your website accessible and legally compliant by just adding a single line of JavaScript.

It sounds too good to be true. Because it is.

Let me be clear from the start: I'm not being hyperbolic when I say "scam." In January 2025, the Federal Trade Commission fined accessiBe $1 million for deceptive marketing claims. The FTC determined that accessiBe was falsely claiming their product made websites "WCAG compliant" when it simply couldn't deliver on that promise.

And accessiBe isn't an outlier—it's the industry leader. The others make the same claims.

What accessibility overlays actually are

An accessibility overlay is a JavaScript widget that sits on top of your website. When users click on it, they get a panel with options like:

Change colors/contrast
Increase font size
Enable a "screen reader"
Activate "profiles" for blindness, dyslexia, ADHD, etc.
A magical toggle to "make the site WCAG compliant"

The pitch to businesses is irresistible: instead of spending money on actual accessibility work, just pay us $500-2000/year and we'll handle everything. Avoid lawsuits! Be compliant! One line of code!

Why they can't work (technically)

Here's the thing: web accessibility isn't about surface-level appearance. It's about the underlying structure of your HTML.

WCAG (Web Content Accessibility Guidelines) is the international standard that accessibility laws reference. It has specific technical requirements like:

Semantic HTML structure: headings (<h1>, <h2>), lists, landmarks
Properly labeled form fields: <label> elements correctly associated with inputs
Keyboard navigation: logical tab order, focus management
ARIA attributes: proper roles, states, and properties for dynamic content
Text alternatives: meaningful alt text for images (not auto-generated garbage)

An overlay is JavaScript that runs on top of your existing code. It cannot change your source code.

If your HTML uses <div> where it should use <button>, the overlay can't fix that. If your form fields don't have proper labels, the overlay can't create that association. If your modal doesn't trap focus correctly, the overlay can't restructure your DOM.

It's like putting a cardboard on a staircase and calling it a wheelchair ramp.

The features are either fake, redundant, or irrelevant

Let's break down what these overlays actually offer:

Fake: "Make site WCAG compliant" toggle

EqualWeb literally has an ON/OFF switch labeled "Make the site comply with WCAG."

This is the exact claim the FTC sanctioned. WCAG 2.1 has 78 success criteria. Many require structural changes to your codebase. No JavaScript widget can magically fix all of them with a toggle. This feature is, to put it plainly, a lie.

Fake: "Blindness profile"

Blind users already have screen readers. Professional ones. JAWS, NVDA (free), VoiceOver (built into Apple devices), TalkBack (Android). They've spent years learning these tools and configuring them to their needs.

An overlay that "adapts the site for blindness" can actually interfere with their existing screen reader, change keyboard shortcuts they rely on, and create an inconsistent experience across websites.

Moreover, I've checked that some of these overlay screenreaders ignore aria-hidden, the standard for removing a node from the accessibility tree (AOM), which is the data structure that dependable screen readers use to know what they are allowed to read.

Fake: "AI-powered image descriptions"

Overlays claim to automatically generate alt text for images using AI. The problems:

The descriptions are generic ("a person smiling") instead of contextual ("CEO presenting Q3 results")
Decorative images should have alt="" (empty), but AI adds unnecessary descriptions
WCAG requires alt text to be functionally equivalent, which requires human judgment about purpose

Redundant: Everything else

Most overlay features already exist at the operating system level:

Overlay feature	Already exists in...
Zoom/Magnification	Windows Magnifier, macOS Zoom, browser Ctrl+/-
High contrast	Windows High Contrast, macOS Increase Contrast
Color filters (colorblindness)	Windows, macOS, iOS, Android color filters
Screen reader	NVDA (free), VoiceOver (free), TalkBack (free), Narrator (free)
Large cursor	System accessibility settings on all OS
Voice control	Dragon, Windows Voice Control, macOS Voice Control
Text-to-speech	Built into every modern OS and browser
On-screen keyboard	Built into every OS
Dictionary	Built into every OS (Ctrl+Cmd+D on Mac, right-click on Windows)

People who need these features already have them configured system-wide, working across all apps and websites. They don't need each website to provide its own inferior version. Also, none of them are WCAG requirements and therefore, not a web dev responsibility.

Irrelevant: "Profiles" for ADHD, Dyslexia, Epilepsy, etc.

WCAG doesn't have success criteria for "ADHD profile" or "dyslexia mode." These aren't legal requirements.

What WCAG does require is specific things like not having content that flashes more than 3 times per second (for seizure safety), proper text spacing, ability to pause moving content, etc. An overlay can't stop a video from flashing. An overlay can't fix your auto-playing carousel.

These "profiles" are marketing theater — they sound inclusive but don't address actual legal compliance.

They don't protect you from lawsuits

The whole pitch is "avoid lawsuits." But the data shows the opposite:

25% of accessibility lawsuits in 2024 were against websites with overlays installed.

The legal precedent is clear. In the Murphy v. Eyebobs case, the court explicitly rejected the argument that an overlay provided adequate accessibility. In the LightHouse v. ADP settlement, the agreement explicitly stated that "overlay solutions such as those provided by AudioEye and accessiBe will not be sufficient to achieve accessibility."

Plaintiff attorneys know about overlays. Finding an overlay on a website doesn't make them go away—it shows them you tried to take a shortcut instead of doing the actual work.

Over 1000 accessibility professionals have signed against them

The Overlay Fact Sheet is a public document signed by more than 1000 accessibility professionals worldwide, including:

Contributors to WCAG, ARIA, and HTML standards
Employees at Google, Microsoft, Apple, BBC
Independent accessibility consultants
Disability advocates

The statement is clear: overlays don't work, they often make things worse, and they represent a misallocation of resources that should go toward real accessibility.

accessiBe, UserWay, EqualWeb, and AudioEye are all explicitly named.

The European Disability Forum has warned against them

In May 2023, the European Disability Forum (EDF) and the International Association of Accessibility Professionals (IAAP) issued a joint statement:

"Overlays do not make the website accessible or compliant with European accessibility legislation. They do not constitute an acceptable alternative or a substitute for fixing the website itself."

This is particularly relevant now that the European Accessibility Act (EAA) is in effect as of June 2025.

They also introduce security risks

In November 2022, Imperva's security research team discovered a DOM XSS vulnerability in EqualWeb's widget. The vulnerability affected major clients including Fiverr, Bosch, Playtika, and Avis.

When you add a third-party JavaScript widget to your site, you're trusting that vendor with your users' security. These overlays load external scripts on every page load, expanding your attack surface.

What you should do instead

If you actually care about accessibility (and avoiding lawsuits):

Remove the overlay. It's not helping. It might be hurting.
Get an audit. Hire an accessibility professional to evaluate your site against WCAG 2.1 AA.
Fix the actual issues. Work with your development team to address problems in the source code. This means semantic HTML, proper ARIA, keyboard navigation, color contrast, alt text, etc.
Train your team. Designers, developers, and content creators should understand accessibility basics so new features don't introduce new barriers.
Test with real users. Include people with disabilities in your QA process. They'll find issues automated tools miss.

Yes, this costs more than a few bucks a month. But it actually works. And it won't get you sued.

The bottom line

Accessibility overlays are selling you a lie: that you can buy compliance without doing the work. The FTC has called it deceptive. The disability community has rejected it. The data shows they don't prevent lawsuits.

If your company uses one, share this article with your manager. If you're a developer being asked to implement one, push back with this evidence. If you're evaluating accessibility solutions, run away from anyone promising a one-line JavaScript fix.

Real accessibility requires real work. There are no shortcuts.

Further reading:

Overlay Fact Sheet — The public statement signed by 1000+ professionals
Overlay False Claims — Documented evidence of misleading marketing
FTC v. accessiBe — The $1M fine for deceptive practices
EDF/IAAP Joint Statement — European Disability Forum warning
Adrian Roselli's blog — Extensive documentation of overlay problems
WCAG 2.1 Quick Reference — What actual compliance looks like

¿Qué significa que Javascript está basado en prototipos?

Ceci Olivera — Sat, 12 Sep 2020 09:21:05 +0000

Cuando empecé a estudiar Javascript y POO escuché muchas veces que a pesar de que Javascript es un lenguaje orientado a objetos no está basado en clases sino en prototipos.
En este artículo intentaremos entender qué significa exactamente esto y por qué es importante saber qué hace un prototipo.

En otros lenguajes orientados a objetos cuando declaramos una clase estamos creando un nuevo tipo de dato compuesto, es decir, un tipo de dato formado por tipos primitivos. Pero esto no es lo que ocurre en Javascript, a pesar de que desde ES2015 usemos la palabra reservada class. Los prototipos son instancias de objetos. Mientras que las clases son modelos, los objetos heredan directamente de otros objetos por defecto en JS.

Entonces, primero que nada tenemos que entender qué es la cadena de prototipos.

La cadena de prototipos es una estructura en forma de árbol que conecta funcionalidades entre objetos y en cuya raíz se encuentra Object.prototype. Object.prototype provee de una serie de métodos que aparecen en todos los objetos, como por ejemplo toString( ), hasOwnProperty( ) o keys( ).

Prácticamente todos los objetos en Javascript son instancias de Object si seguimos la cadena de prototipos. Y como probablemente ya sabes, casi todo es un objeto en Javascript. Incluso algunos tipos de datos primitivos (string, number y boolean específicamente) pueden ser objetos por fracciones muy pequeñas de tiempo. Entonces, los arrays son objetos, las funciones son objetos y, por supuesto, los objetos son objetos.

La cadena prototipal nos permite crear instancias de arrays, por ejemplo, que tengan acceso a todos los métodos definidos en Array.prototype como map, forEach, filter y un gran etc. Pero también obtenemos acceso a todos los métodos disponibles en Object.prototype.

Pero, ¿cómo ocurre esto?
Pues resulta que todos los objetos en Javascript tienen una propiedad oculta llamada __proto__ que guarda una referencia al objeto prototype del constructor. Siguiendo con el ejemplo de los arrays, un array tiene acceso a todos los métodos en Object.prototype porque cada array individual es una instancia del objeto Array, y el objeto Array es una instancia del objeto Object. Y esta cadena continúa hasta que llegamos al prototipo de Object.prototype, que será null.

De esta manera, cuando intentamos ejecutar un método en un objeto, Javascript primero buscará en las propiedades del objeto en cuestión. Si no encuentra una propiedad con ese nombre buscará en su propiedad __proto__, que guarda una referencia al objeto prototype de su constructor. Si no la encuentra ahí buscará en la propiedad __proto__ del objeto constructor. Esto continuará hasta que encuentre esa propiedad o método, o no la encuentre y lance un TypeError.

Por si acaso, ya que estamos usando los arrays como ejemplo, cabe recordar que los arrays son azúcar sintáctico en Javascript. Son objetos con un comportamiento especial, pero bajo la alfombra son algo así:

{
    ‘0’: value,
    ‘1’: value,
    ‘2’: value
}

Lo que esto significa es que, por ejemplo, cada vez que declaramos un array estamos creando una instancia del objeto Array que viene con el lenguaje. Si lo miramos en consola veremos que la propiedad __proto__ está vinculada al objeto Array:

Y si seguimos metiéndonos en la madriguera veremos que el objeto __proto__ tiene también una propiedad __proto__ que guarda una referencia a Object.prototype (es una referencia aunque nos salga en consola todo, porque ya sabes, DRY).

Entonces, ¿hay alguna forma de crear un objeto sin prototipo en Javascript?
Pues sí, la hay. Resulta que una de las formas que tenemos de crear objetos es con Object.create( ), a la cual podemos pasarle como argumento el objeto que queremos que sea el prototipo del nuevo objeto que queremos crear. Si le pasamos null estaremos creando un objeto que sea solo eso, una hash table:

const objetoSinPrototipo = Object.create(null);

What does it mean that Javascript is prototype based?

Ceci Olivera — Fri, 11 Sep 2020 19:10:01 +0000

When I first started learning Javascript and OOP I heard over and over that Javascript is an object-oriented language though it is not based on classes but prototypes.
In this article we are going to try to understand what this means and why it is important to know what a prototype is to acknowledge what we are doing.

In other object-oriented languages when you declare a class you are creating a new complex data type, that is to say, a data type composed of primitive data types. But this is not what happens in Javascript even though we use the keyword class since ES2015. Prototypes are object instances. While a class is a blueprint, objects inherit directly from other objects by default in Javascript.

To understand what this means, we need to understand what the prototype chain is.

The prototype chain is a tree-shaped structure that connects objects functionality and at the root of this tree is where Object.prototype lays.
Object.prototype provides a few methods that show up in all objects, such as toString( ), hasOwnProperty( ) or keys( ).

Almost every object in Javascript is an instance of Object if we follow the prototype chain. And as you probably know, almost everything in Javascript is an object, even some primitive data types (string, boolean and number specifically) can be objects for a tiny fraction of time. So, arrays are objects, functions are objects and, of course, objects are objects.

The prototype chain allows us to create instances of, for example, arrays that have access to all the methods that are available for arrays, like map, forEach, reduce, filter, and a big etc. But arrays also have access to all the Object.prototype functionalities.

How does this happen?
Just to be clear because we are using arrays for the example, arrays are syntactic sugar in Javascript. They are objects with a special behavior to make them look and feel like an array, but under the hood, they are something like this:

{
  '0': value,
  '1': value,
  '2': value
}

It turns out that every object has a property called __proto__ which holds a reference to the prototype object of the constructor. So following the array example, an array has access to all the methods in Object.prototype because every array is an instance of the Array object and the Array object is an instance of the Object object. And this chain goes on until we hit the prototype of Object.prototype which will be null.

This way, when we try to execute a method on an object, first JS will lookup in the properties of the object itself. If it doesn’t find a property with that name, it will look in its __proto__ property, which holds a reference to the prototype object of its constructor. If it doesn’t find it there it will look in the __proto__ property of the constructor object. This will go on until it finds it or it doesn’t find it and throws a TypeError.

What this means is that, for example, every time we declare an array we are creating an instance of the Array object that comes with the language. if we look at it in the console we will see that its __proto__ property is linked to the Array object:

And if we keep looking down the rabbit hole we’ll see that the __proto__ object has a __proto__ property itself that holds a reference to Object.prototype (it’s a reference even though you see all the properties in the console because you know, DRY).

So, is there a way to create an object without a prototype in Javascript?

Well, yes there is. One of the ways of creating an object is with Object.create( ), to which we can pass as an argument the prototype we want that object to have, which by default is Object.prototype. If we pass it null as an argument we will get an object that is just that, a hash table.

const objectWithoutPrototype = Object.create(null);

Share if you liked it and let's connect! Follow me on Twitter and LinkedIn 😊