DEV Community: Mánu Fosela

The Shifting Role of the Software Engineer

Mánu Fosela — Tue, 11 Aug 2026 09:43:26 +0000

This is the first of three articles about how I see AI adoption in software development within companies and how I'm pushing it forward at TRIBBU, my company.

First, I want to talk about the change itself: what's happening to our work and why I think we're facing a change in the level of abstraction. In the second one I'll talk about how we can govern software development carried out by agents. And in the third, probably the most complicated one, about how to lead people through this transition.

Because technology will probably be the easy part.

We're living through a “turbulent” yet exciting period with the arrival of what we somewhat incorrectly call artificial intelligence into our lives.

Although I think software development is where its adoption has gone deepest, little by little it's making its way into every discipline and more and more people are using it to make their day-to-day work easier and better.

It's true that some people use it to do their work for them. Often badly, especially when that work requires judgment.

And it's also true that if an AI can do your work because that work doesn't require judgment, then your job will, sooner or later, be replaced by AI.

But that's not what I want to talk about.

I want to focus on how to lead the transition towards software development with AI inside companies.

And here I see two different problems.

One is how to “evangelize”, more than convince, how to get them to convince themselves, to “convert”, and get developers to see the enormous benefits it can bring, leaving behind bad past experiences caused by using it without judgment or knowledge.

The other one, much more complicated in my opinion, is how to do it well.

Because right now there's a lot of ignorance, very little accumulated experience and, above all, a huge disparity of opinion about how far we're willing to stop doing what until now we considered our job: writing code.

I'm going to address both problems, but I want to start with the how.

Because I think that if we can answer the how properly, solving the first problem will be much easier.

It will be easier for a programmer to accept delegating an increasing part of their work to an AI if they can trust the system through which they do it.

Because let's not fool ourselves: feeling that something artificial is beginning to do what you've spent years doing, what you're good at and, even worse, what you probably love doing, is hard. Very hard.

But denying the evidence, what's happening, won't make it stop happening. Let's not be like little children who cover their faces and think nobody can see them.

And let's be aware that an AI-native generation is taking shape, and we are responsible for training and educating it.

This generation won't be made up of developers who first learned to program and then incorporated AI into their work. That's us.

They will learn to develop with it from day one.

And those who don't adapt will be overtaken, much sooner than we think.

When Was the Last Time You Looked at Assembly?

Let me start with a question, and I hope the metaphor and the distance between the two things are clear.

When was the last time you looked at the assembly generated by your compiler to check that it was managing registers, memory or loop efficiency properly?

Probably never.

And yet there was an entire generation of programmers who did. Who had to.

Because early compilers generated worse code than a good assembly programmer could write. Trusting them blindly was simply reckless.

Those programmers were right at that moment.

The ones who were wrong were those who turned that temporary distrust into a permanent identity.

Those who ten years later were still arguing that a good programmer had to write assembly while the rest of the world had moved up one level of abstraction.

I think we're already inside that same kind of moment with generative AI.

I'm not saying it's exactly the same.

In fact, there are huge differences, as I said at the beginning.

But conceptually, I see that we're facing another leap in abstraction.

Until now we've been incorporating tools that helped us program. Editors. IDEs. Autocomplete. Frameworks. Stack Overflow. Copilot...

All of them, in one way or another, allowed us to write code more easily or more quickly, with fewer errors or by failing earlier.

But we were still writing the code.

With agents, something different is starting to happen. More and more, we're moving away from saying “I want to write this code” and starting to say “I want this to happen”.

This changes absolutely everything.

Because the leap we're trying to make isn't simply from one tool to another, no. We're moving, with all the obvious differences, from assembly to the compiler, except this time the leap is several orders of magnitude bigger. An exponential leap.

A compiler receives high-level code and generates low-level code. And yes, I know, following deterministic rules and within a bounded space. True. That's why I call it an exponential leap, because we're moving into an enormously more open space.

But we're getting an AI to receive an idea, a need, a specification, some constraints or a conversation and produce software.

And as I've already said, there's vastly more space between one thing and the other, and therefore vastly more things that can go wrong.

And this is precisely one of the big differences compared with a compiler. A compiler is deterministic and verifiable. An agent isn't. It can make mistakes in subtle, plausible and difficult-to-detect ways.

And the skeptic who says that the verification problem hasn't been solved is right. It hasn't.

That's why I'm not saying that we can stop verifying what AI does. I'm saying that verifying it by reading every single line it generates can't be the solution either.

We Get Carried Away With AI

At first the experience is spectacular. You ask it for a function. It does it.

You ask it for an endpoint. Same thing.

You explain a small feature and it changes four files, creates the tests and apparently everything works.

And you think: “Holy shit.”

Then you take another step. You give it something bigger. It starts touching things. Changes others. Interprets something differently from what you expected. Suddenly something doesn't add up. You tell it to fix it. It fixes that and breaks something else. You explain the new problem. It tries again. And shortly afterwards you have a mountain of useless, incomprehensible, unfixable and unmaintainable code.

And you don't even really know when exactly it started fucking everything up.

That's when a phrase we've heard quite a lot appears:

“That's where you can tell whether you really know the fundamentals. If you know how things work, you can review what the AI has done and fix it.” Well, yes. Up to a point.

Because let's be honest. There comes a point where not even Uncle Bob would understand a fucking thing about what it has done.

And, besides, there's a much more important problem.

If an AI can produce code much faster than I can read it, trying to control that AI by reading everything it generates simply doesn't scale.

Some people talk about knowledge debt. But I don't think that's quite it. I think we're mixing two different things.

It's like accepting the compiler but insisting on reviewing all the assembly it generates afterwards. It makes no sense. Especially with today's processors, whose assembly code very few humans are capable of understanding.

Or, at least, it can't be the final solution.

The fact that reviewing the code no longer scales doesn't mean the verification problem has been solved. It means exactly the opposite: we need another way to solve it.

Even more so as agents keep getting better and we give them more and more autonomy.

We need rules. A harness. Guardrails. External mechanisms that the agent doesn't control and that allow us to let it work without constantly looking over its shoulder.

Not to tell it exactly how it has to do things. We don't need that anymore. We need to set the limits, prevent certain actions and check that what it delivers meets what we expect.

But I'll talk about that in the second part.

Having the Tool Doesn't Mean Getting Value From It

And here another confusion appears that I see quite often.

Having access to a tool is one thing and knowing how to get value from it is something very different.

Today practically anyone can open ChatGPT, Claude, Copilot or any other agent and ask it to build something.

That doesn't mean anyone can build a good product.

In the same way that having an IDE doesn't make you a developer, having an AI capable of writing code doesn't automatically make you capable of creating software that delivers value.

If writing code had really been the only barrier to creating good products, by now we should be seeing a massive explosion of disruptive applications.

And I honestly don't see it.

What I do see is a lot of vibe coders paying for advertising to try to sell, again and again, variations of the same worn-out product.

Because code was never the product. The user doesn't want or need our code.

They don't want our hexagonal architecture, our patterns, our framework or to know whether we use microservices or monoliths.

They want to solve a problem.

Code was, and still is, the means to achieve that. Or one of them.

The difference is that this means has just become dramatically cheaper and more democratized.

AI is making it extraordinarily cheap to plant software (a brilliant analogy from the great eduferro).

But planting isn't the same as having a good garden.

Someone still has to decide what to plant, when to plant it and what for. Then it has to be watered, pruned, fertilized, whatever no longer serves a purpose has to be removed, and it has to be adapted when conditions change.

Because software isn't something you build and finish. It's a living thing that evolves, and neglecting it is a great way to end up with a garden bed full of shit.

Someone has to understand the problem. Know what's worth doing and what isn't. Choose between alternatives. Prioritize. Make decisions with incomplete information. Validate. Change their mind and iterate.

And, above all, have judgment to know whether what we've created actually delivers any value.

The barrier to creating software is falling.

The barrier to creating value, not necessarily.

Our Work Is Shifting

That's why I don't think the conclusion is that AI is going to replace software development.

I think our work is shifting, because that work, as it exists today, will be replaced.

One level up.

If before we spent a large part of our effort telling a machine how it had to do something through a programming language, increasingly we'll spend more effort defining what should happen, why, under what conditions and how we can know whether the result is correct.

That requires judgment.

Probably much more than we needed to implement many of the tasks we do today.

And this, for me, is where the truly important change lies.

We're not stopping developing software.

We're starting to stop being necessarily the ones who write every single line of it.

And the Window Won't Stay Open Forever

Every change in abstraction level opens a window of opportunity.

It happened with version control, for example. With CI. With cloud. With infrastructure as code.

For a while, those who adopted it well had a huge advantage over those who said: “We're fine like this.”

Then it stopped being an advantage. It simply became the normal way of working.

I think we're in one of those windows now.

Except this time everything is happening much faster.

Not adapting doesn't mean standing still. It means falling behind.

Because while you keep working the same way, the bar for what we consider normal productivity keeps moving, but this time at a speed that makes it increasingly difficult to jump onto the train once it's already moving.

Today, knowing how to work well with agents is a competitive advantage. Tomorrow it will simply be part of the job.

But as I said before, first we have to solve an important problem, because if we're not going to review every single line produced by an AI...

how the hell do we know whether what it has done is actually right?

That's what the second part will be about.

Karajan v3.0.0: a local-first multi-agent orchestrator that conducts AI CLIs like an orchestra

Mánu Fosela — Wed, 03 Jun 2026 22:46:30 +0000

karajan-code@3.0.0 is on npm. nvm install 22.22.1 && npm i -g karajan-code@3 and you're done.

Why I built Karajan

I love coding with AI. What I don't love is babysitting it.

If you've spent any time with Claude Code, Codex, or Gemini, you know the loop:

You describe what you want.
You watch the model work.
You catch it skipping tests, hallucinating an API, or touching the wrong layer, even with a solid CLAUDE.md/AGENTS.md and SKILLs in place.
You stop it, correct it, relaunch it.
Repeat.

Fine for a one-off change. Doesn't scale to a real project with a known plan, real tests, and a real quality gate. You end up being the human stuck in the middle of an async loop you can't pause, retry, or measure.

I wanted something different. A tool where I describe what I want once and, from there, a set of AI agents (a coder, a reviewer, a tester, a SonarQube gate, a security auditor) run the loop themselves and ping me when it's done. Reproducibly. Locally. Using the subscriptions I already pay for.

That tool is Karajan.

The name is a nod to Herbert von Karajan, the conductor who never played a single instrument but imposed a unified vision on dozens of musicians until they sounded like one. Karajan didn't replace the musicians: he coordinated them under a single guiding intent. Karajan Code does the same with your AI agents: none of them is in charge, all of them converge under a single baton that arbitrates and unifies.

What Karajan actually is

Karajan is a local-first multi-agent orchestrator written in vanilla JavaScript on Node 22.

You describe a task (in a markdown file, a user story, or directly on the command line) and Karajan runs a role-based pipeline over it:

task
  → triage      (classifies complexity, decides route)
  → researcher  (reads existing code)
  → architect   (designs the change)
  → planner     (breaks it into steps)
  → coder       (writes code and tests)
  → SonarQube   (static analysis as a gate)
  → tester      (runs the real test suite)
  → reviewer    (independent agent reviews the diff)
  → security    (security pass)
  → commiter    (commit, push, opens PR)

Each role is a CLI agent. The coder can be Claude, the reviewer can be Codex, the tester can be Aider. Karajan doesn't call /v1/messages: it spawns claude -p, codex, gemini, aider, opencode as child processes and reads their stdout/stderr. That single architectural decision unlocks two things:

Zero API cost. Your existing Pro / Plus / Max subscriptions do the work. No new bills.
Multi-provider routing. A powerful coder + a strict reviewer + a cheap triage agent = the right model for each role, with automatic fallback when one hits its quota.

The whole system is TDD-first by default. The coder writes tests alongside the code, the tester runs them for real, the reviewer sees the diff. If something fails, the reviewer feeds back to the coder and the loop iterates, bounded by maxIterations and maxIterationMinutes so it can't spiral.

A few more pieces worth knowing:

MCP server. Karajan ships as an MCP server, so you can drive the full pipeline from inside Claude Code, Cursor, Codex, or any MCP host. kj_run, kj_plan, kj_code, kj_review, kj_audit, kj_rag_query: full pipeline access without leaving the conversation.
Solomon, the AI judge. An independent role the Brain orchestrator consults when there's a real dilemma (security vs. deadline, two reviewers disagreeing). Not on every loop; only when the Brain can't decide deterministically.
Story Board. A small local web dashboard at http://localhost:4000 showing every user story, every session, every plan, every RAG metric. The single source of truth for the team.
Local RAG. Each project gets its own embedded code index (~/.karajan/rag.db). The pipeline retrieves real code before planning, so the architect sees what already exists. Six embedding providers (Ollama, OpenAI, Voyage, Cohere, Mistral, local ONNX). Tree-sitter-based chunkers for JS, TS, Python, Rust, Go, and Java.
kj audit. A deterministic-first audit command: dead code, unused dependencies, complexity growth, security findings (OSV, Semgrep, SonarQube), accessibility hints, Web Performance budgets, and an AI Harness Scorecard run via Docker that gives an objective 0-100 score for "how AI-friendly is this repo right now." Keeps a per-project history and draws sparkline trends.

What v3.0.0 brings

v3.0.0 is a runtime alignment, not a feature drop.

Node 20 hit EOL on 2026-04-30. The Active LTS line is Node 22. Three of Karajan's dependencies independently bumped to majors requiring Node 22+: lint-staged 17, commander 15, and better-sqlite3 12.10. Rather than publishing four staggered minors patching each constraint separately, v3.0.0 bundles the runtime bump with the dep majors that depend on it.

Migration is a single command:

nvm install 22.22.1 && nvm use 22.22.1
npm install -g karajan-code@3
kj doctor    # checks runtime + HW + tooling

If you were already on Node 22+ and your ~/.karajan/ works, nothing changes. No public API changes: kj run, kj plan, MCP tools, role templates, RAG, Story Board, audit, telemetry, all intact. Existing sessions, plans, RAG index, and audit history are forward-compatible; nothing to migrate by hand.

Why a major with no API changes?

Semver. Bumping the minimum Node version is a breaking change for downstream consumers: an install that worked on Node 20 now hard-fails. That alone qualifies, and the three dep majors on board each qualify on their own semver. Cutting a single v3.0.0 surfaces the runtime change once instead of four times.

The release also brings documentation polish: a new footprint and hardware requirements section in the README so you know what you're getting into before installing. kj itself is 5.2 MB on npm and ~/.karajan/ runs around 40 MB. Ollama (optional, 6.55 GB), SonarQube (optional, 1.47 GB), and the qmd cache (optional, ~2.2 GB) are the heavy optional layers. Three profiles: Minimal ~250 MB, Recommended ~8.5 GB, Full ~11 GB.

v1 to v3: how Karajan grew

Karajan didn't start as a multi-agent orchestrator. It started as a shell script.

v0.x: One script. task → claude → diff → codex review → done. Hardcoded to two agents. No retry, no cost tracking, no SonarQube, no test integration. It worked, roughly, on a Tuesday afternoon.
v1.0 to v1.1: Quality gates and roles. SonarQube became a mandatory step between coder and reviewer. The TDD policy meant any code change required a test change. Then the monolithic script became a role-based pipeline: BaseRole, BaseAgent, 12 configurable roles, review profiles, Solomon escalation, budget tracking.
v1.2 to v1.3: MCP server and extensibility. The MCP server made Karajan callable from inside any MCP-speaking AI agent. The plugin system let users wrap their own CLIs as Karajan agents without forking. Planning Game integration connected the pipeline to project management. Git automation closed the loop with auto-commit, auto-PR, auto-rebase.
v1.4 to v1.7: Resilience. Rate-limit detection across all supported CLIs. Automatic fallback when the primary coder hits its quota. Smart model selection mapping triage complexity to model tier (trivial → Haiku, complex → Opus). Interactive checkpoints replacing the brittle hard timeout. In-process MCP execution so subprocess SIGKILLs stopped killing agents mid-work.
v1.40 to v1.46: Sovereignty, OpenSkills, parallel stories. The pipeline learned to defend its own decisions against host AI overrides (pipeline sovereignty guard). OpenSkills brought domain knowledge to coders, reviewers, and architects. Parallel user stories ran independent stories concurrently in git worktrees. First SEA binaries appeared: kj running without Node installed.
v1.50 to v1.58: Telemetry, domain knowledge, i18n, WebPerf. Telemetry (opt-out, no code or personal data) to finally measure what was happening. Domain knowledge files (DOMAIN.md) injecting business context into every role. i18n letting the pipeline speak EN or ES end to end. Web Performance as a first-class quality gate (Core Web Vitals via Chrome DevTools MCP, inspired by Joan Leon's WebPerf Snippets).
v2.0: Karajan Brain. A central AI orchestrator deciding routing, enriching feedback, suggesting direct actions, and compressing outputs between roles. Solomon moved from "every loop" to "real dilemmas only." Tester and security became blocking gates. The proxy subsystem (which never worked well under SSE/WebSockets) was dropped in favor of RTK for token savings.
v2.x: The "I use this daily" phase. Too many releases to list, but the highlights: stack-aware audit (v2.9.0), Docker/shell installer (v2.10.0), Story Board hardening (v2.13.0), plan adherence scoring + golden tasks (v2.12.0), shared team Story Board (v2.31.0), editable config UI (v2.30.0), multi-language RAG with AST chunkers for Python/Rust/Go/Java (v2.34.0), retrieval quality harness (kj rag eval, v2.34.0), and the AI Harness Scorecard golden metric integrated into kj audit (v2.32.0-v2.33.0).
v3.0.0: Runtime alignment. No new features. Node 22 baseline, three dep majors, one migration command, zero public API change. The story of "boring releases that buy you a year of headroom."

That arc, compressed: a shell script → a role-based pipeline → an orchestrator with a brain → a local-first, MCP-driven, RAG-powered, multilingual, multi-provider, test-first team tool. The same idea throughout: many different AI agents, one baton that makes them converge.

Getting started

Install:

nvm install 22.22.1 && nvm use 22.22.1
npm install -g karajan-code@3

Smoke test:

kj --version           # 3.0.0
kj doctor              # checks Node, agents, Docker, SonarQube, RAG...

Initialize a project:

cd your-repo
kj init                # autodetects stack, suggests agents, scaffolds .karajan/

Run a task:

kj run "Add a /healthz endpoint with a unit test that returns 200" \
  --coder claude --reviewer codex

Or from inside Claude Code / Cursor / any MCP host, just call kj_run.

Open the Story Board:

kj board start         # http://localhost:4000

That's the loop. Describe what you want. Let the orchestra play.

Where to find it

npm: karajan-code
Docs: https://karajancode.com/docs
Repo: github.com/manufosela/karajan-code
License: AGPL-3.0
Author: @manufosela, built in the open.

If you try it and something surprises you (good or bad), I want to know. Open an issue, reach out on GitHub, or reply here.

I’ve tried RTK and it saves a lot of tokens, but I think Squeezr is on another level.

Mánu Fosela — Sun, 05 Apr 2026 16:37:21 +0000

Sergio Ramos Vicente

Apr 5

I was burning through AI tokens without realizing it. Here's how I fixed it.

#ai #tooling #opensource #claude

3 min read

Over-Architecting in Web Design

Mánu Fosela — Thu, 10 Oct 2024 05:01:23 +0000

I recently read a post by @justinfagnani on X that says:

"Lit is not a framework. The browser is the framework."

This got me thinking about how we've been building for the web in recent years.

For quite some time now, if you know HTML, CSS, and JavaScript, you really don’t need a framework to build web applications. At most, you might use some libraries to simplify certain tasks, but even these are gradually being incorporated into the platform itself, like routing or state management.

Our focus, however, has shifted towards learning frameworks, and now meta-frameworks, which do make it easier to build web environments. They optimize pages, automatically generate necessary files like sitemaps.xml, optimize images, remove unused CSS, bundle, minify, and optimize JavaScript. They’re effective, yes. But they don't adhere to the standard.

Meta-frameworks like Astro let you use standards, but they don’t exactly make it easy. Instead, they streamline using other frameworks or their own components in a more user-friendly, non-standard format to "simplify" component creation. They also employ techniques to facilitate SEO, loading, and indexing—depending on how you’ve implemented them.

To me, this approach has two major issues:

Cognitive overload: Developers must learn to manage not only the framework itself but now also the meta-framework and its set of tools, which often adds unnecessary complexity to project architecture.
Detachment from the standard: Focusing on frameworks means we’re not investing time in understanding the latest developments in the web itself, which are substantial. CSS, for example, is making a huge leap forward with features like container queries. Meanwhile, JavaScript and HTML are also evolving, with HTML potentially introducing a new <select> element that will allow HTML and CSS within <option>, opening new and more flexible ways to create rich selectors.

In many frameworks, though, these innovations are implemented through their own components, so to developers, it can seem like these new features are framework inventions instead of standard advancements.

I remember a few years ago, when these meta-frameworks were just emerging, a developer excitedly told me, “They’ve invented SSR (Server-Side Rendering); now we can generate HTML on the server, creating static pages.” I looked at him in surprise. He insisted, thinking I was just as impressed with this “novelty” saying, “Isn’t it incredible? What a fantastic idea.” The irony was that SSR has been around since the early days of the web.

Today’s web developers, those studying web development and entering the field, often lack historical context. They don’t know how web development originally worked. They don’t understand the reasons we moved from server-side rendering to client-side rendering and started using frameworks. Somewhere along the line, when “Ajax” gained popularity, we lost our way—probably driven by the desire for standards to cover everything we needed, while big companies fought to impose their own criteria, tags, and languages in the browser (I still remember Microsoft’s infamous VisualBasicScript).

Frameworks aren’t the problem. Not at all. They added power and value to web development. They allowed us to create applications for everyone, spurring the rise of hundreds of thousands of web developers and bootcamps.

Frameworks and meta-frameworks aren’t the issue; they even helped democratize web development, enabling millions to create applications and fueling the bootcamp boom. But as the web platform matures and standards become more robust, framework creators have business incentives to retain and promote their tools. They’re not going to say, “Stop using my framework; you can do everything with standards now.” Plus, migrating applications built with these frameworks to the standard is nearly impossible, especially since, in my experience, most lack E2E or functional tests to ensure that migration maintains the original behavior.

So, why aren’t we investing in tools that help us leverage today’s standards?

There isn’t a meta-framework that “forces” you to use the standard, making it easier in the process.

We need solutions that help us organize our projects efficiently and assist with build and optimization tasks if we want to do SSR, CSR, SSG, ISR, Hydration, create MPAs or SPAs. But we should be fully aware of our needs and the pros and cons of each choice. These tools should optimize images, JavaScript, CSS, and generate only the necessary files. They should allow the use of libraries that stick to the standard and adequately cover the platform’s remaining gaps. They should optimize and support SEO, loading, and indexing, facilitate testing, and harness the platform’s power.

It’s time to reduce over-engineering and excessive architectural design in our web projects. Let’s keep learning, not just how to use a framework, but also how to appreciate and apply the incredible advancements in web standards.

No excuses.

Desarrollo Web y Web Components

Mánu Fosela — Tue, 29 Dec 2020 01:04:19 +0000

Disclaimer

Lo que vierto en este post es mi opinión. Mi punto de vista. Mi percepción. Desde mi experiencia y mis sesgos. Y sobre todo desde mi ignorancia en muchos campos.

Sobre mi y mis inicios como desarrollador

Llevo programando para la web desde 1997.
A parte de HTML, CSS y Javascript, he pasado por varios lenguajes: CGIs en C, ASP, JSP, PHP, Java, Perl y Ruby si no recuerdo mal. Algunos durante unos meses otros durante años.
He trabajado con bases de datos MSSQL, MySQL, Oracle, IBMDb2 y MongoDB.
Y he trabajado con servidores IIS, Apache, Tomcat y Nginx.
Desde siempre Windows (era un mal necesario) y Linux (era un suplicio a principios de siglo)

He visto cómo hemos pasado de que un desarrollador/equipo web fuera responsable de todo a la especialización más exquisita.
Aprendí a hacer testing, TDD, metodología XP y pair programing en 2007. Hacia 2008 con el boom de Javascript y Jquery, empecé a especializarme más en Javascript, aunque no fue hasta 2010 cuando pasé a ser “oficialmente” FrontEnd Developer, a pesar de que mis dotes de diseño dejan mucho que desear.
Y dejé de tocar la parte back y configuración de servidores. Dejé de subir a producción por FTP y empecé a usar control de versiones con CVS y Subversion.

Luego empezaron a aparecer librerías como Backbone y arrancó el boom de los frameworks del front, las llamadas AJAX y el desarrollo de APIs que alimentaban esos frontales “mágicos”

Por cierto, AJAX empecé a usarlo hacia 2007 cuando existía ¡¡desde 2002!! Y yo usando iframes ocultos, leyendo información y cargándola en la página principal, una “guarrada”... pero es que antes era otra epoca ;)

En 2015 me enganché a los web-components, con Polymer en su versión 0.8 y a la espera de que los ansiados estándares vieran su primera versión que no llegó hasta 3 años después.
Y aunque siempre he probado, y hecho alguna aplicación que otra, en todos los frameworks típicos, nunca me han entusiasmado en exceso.
Sí. Mola. Facilitan. Ahorran tiempo (una vez les coges el punto). Unifican los grandes desarrollos. La curva de aprendizaje puede venir hecha al incorporarte a un equipo. Y sobre todo hacen mucha “magia” que se puede traducir en desarrollo mas rápido y menos dolores de cabeza, pero ¿necesitaba usarlos?

Empiezo la polémica

Creo que en los proyectos grandes donde he trabajado, o he visto trabajar desde que ejerzo como manager, está plenamente justificado el uso de un framework, pero ¿Y en un blog? ¿Y en una web de contenidos? ¿Y en algunos juegos? En internet veo muchas webs que son contenidos y creo que no necesitan un framework para desarrollarlas.

¿Que se pueden usar frameworks? Correcto. ¿Que no penaliza? Bueno, depende. A nivel de lo que es una página web, solo hace falta hacer “botón derecho” (lo siento no uso Mac), “ver código fuente de la página” y ver en dicho código fuente “atrocidades” que ni DreamWeaver en sus mejores momentos…
Porque o bien no hay contenido, ya que se genera dinámicamente, y por tanto es contenido invisible a los crawlers de los buscadores, o bien lo que se escupe aparece “ofuscado”, cuando una web de contenido, justo lo que se tiene que leer perfectamente es el contenido, con sus tags HTML, usando la semántica de las etiquetas HTML (cuantos años luché al principio por una web Semántica)
O eso creí entender allá por 1997 cuando leí mi primer libro de HTML.

Y lo de que no es necesario usar un framework para generar contenido como un blog parece que se están dando cuenta la comunidad.
Por eso ¿Qué está pasando últimamente? Que alguien “descubre” el SSR (Server Side Rendering)
Y empiezan a aparecer frameworks sobre los frameworks para hacer lo que se hacía desde siempre, generar el contenido de la página desde en el servidor y que el navegador haga la petición y le envíe dicho contenido, eso sí, ahora usando toooooda la lógica del framework sobre otro framework. Volvemos a los inicios, pero complicándolo.
¿Por qué? Quizás porque lo no sabemos hacer de otra manera. Es lo que nos han enseñado.

Nos enseñan a usar algunas herramientas, pero no nos enseñan a pensar cuándo se deben usar dichas herramientas.
Como se suele decir: “Te enseñan a usar un martillo y todo son clavos”
¿Te enseñan el framework AcojoJS? Todo son aplicaciones con AcojoJS. Sin pararnos a pensar si es la solución idónea para nuestro problema. Funciona, ¿no?

Quizás porque no nos enseñan más.
Quizás porque no nos ponemos a pensar.
Quizás porque va todo tan deprisa que nos falta tiempo para aprender.

Porque aprendemos a usar un martillo, es decir a programar, y ¡ale! a clavar todo lo que pille, aunque sea un tornillo o un cristal.

Y es cierto. Aprendes lo suficiente para usar ese martillo con suficiente destreza. Pero nada más.
Aunque seamos conscientes de que la caja de herramientas es gigante y la cantidad de herramientas casi infinita, nos quedamos con nuestro martillo.

Pero sobre todo, creo que no se fomenta el buscar soluciones adecuadas a los problemas, si no a usar nuestra solución a cualquier problema.
Es decir, adaptamos problemas a nuestras soluciones, complicando más el problema.

Esto me pasó en uno de mis equipos, cuando nos plantearon un proyecto en el que teníamos vía libre para utilizar lo que quisiéramos. Greenfield Project lo llaman.
Pregunté:

¿Qué usamos? Todos al unísono:
Vue! Vue! Vue!

Mi pregunta era para implicar al equipo en el análisis del problema y buscar la solución adecuada, que facilitara el trabajo y la entrega a tiempo.
Pero mi sorpresa fue mayúscula cuando con un mínimo de información sobre el proyecto, todos pedían a Barrabás, en este caso Vuerrabás :P
Menos mal que en este caso no hice como Poncio Pilato, aunque si me lleve un Soponcio Parrato :P

Este es solo un claro ejemplo de a lo que nos conduce el mundo del desarrollo actual, del que me siento parte y responsable.

WebComponents

Y ya metidos en faena, quiero también reivindicar a los denostados, en algunos círculos, web-components estándar, incluidos en muchos frameworks, pero sin pertenecer a ninguno.

Y sobre todo quiero plantear mi disconformidad con el uso que se hace de ellos con el “Atomic Design”, es decir, crear componentes atómicos, que pueden usarse solos o como parte de un componente de orden superior, conocidos como “moléculas”. Y que estos últimos a la vez puedan conformar “organismos” de componentes…

No se. Me chirría. Siempre he visto los web-components como etiquetas HTML, como un <UL> o un <TABLE> o <DIV> solo que “haga más cosas”. Igual que crearon el tag <VIDEO>, que es realmente el concepto de un web-component aplicado: permite insertar vídeo en la web de manera sencilla, con su controlador del vídeo, la pantalla de vídeo, admitiendo diferentes formatos y fuentes…

Y veo bien web-components que aporten “cosas” que no hay. Un lector de QR. Un campo de formulario para votar con estrellas. Un reloj digital. Un calendario. Un menú. Hay mil ejemplos de necesidades.

¿Pero es un componente un ente formado por un <h1>, un <h2> y un <IMG> donde además ninguno de los 3 elementos tiene que aparecer siempre, pudiendo incluso llegar a ser solamente uno de ellos…?

El argumento suele ser “es que se repite”, “es que así es flexible”, “es que si no ¿cómo lo hacemos?”

Pues puede ser un componente web, cierto. Pero también puede no serlo. Si usas un framework quizás no te quede más remedio. O si no te han enseñado a cómo hacerlo sin que lo sea.

Bajo mi punto de vista, si usas web-components y estás generando páginas estáticas, aunque se alimente el contenido de una base de datos, al fin y al cabo, ese ente de <h1><h2><img> es simplemente una plantilla HTML.

Y puedo tener plantillas con combinaciones de esos 3 elementos, si realmente se llaman a todas las combinaciones de los mismos, porque si no, emplear tiempo en tenerlo “por si acaso” es tontería. Ese es otro de los grandes problemas del mundo del desarrollo que da para otro post.

Volviendo al problema planteado. Creo que siempre y cuando sean una simple presentación de tags HTML agrupados, sin ninguna funcionalidad, es una simple plantilla.
Si tuviera funcionalidad, entonces sí podría tener sentido que fuera un web-component. O si tuviera un diseño especial, que pueda chocar con el diseño global y necesite encapsular dicho diseño, también podría ser un web-component.

Es decir, creo que un web-component, la razón de crearlo es cuando:

Se puede reutilizar.
Tiene una presentación que no existe ya en un tag HTML
Tiene una funcionalidad que le da entidad y sentido.
Tiene una parte de su presentación/diseño abstraído del entorno donde se use.

Si no cumple alguno de esos puntos, debo analizar si realmente necesito diseñar un web-component o tengo alguna alternativa.

Y siguiendo esta premisa, por lo tanto para mi no tiene sentido un web-component no visual, que solo aporte funcionalidad, como a veces he visto los llamados “data managers”.

Para mi eso es un tag HTML que ya existe. Se llama <script>. Creo una “librería” con la funcionalidad que necesito. El API que he convenido. Y todo el que lo necesite lo usa. No veo la necesidad de hacerlo mediante un web-component.

Comunicación entre web-components.

Otra "unpopular opinion". Siempre se dice, yo de hecho lo he preguntado en alguna entrevista, ¿Cómo se comunican los componentes? Y quien se lo sabe, repite el mantra: “De padres a hijos mediante propiedades, de hijos a padres mediante eventos”

Bueno, desde el “Atomic Design” quizás ese mantra sí tiene sentido.
Pero si concibes los web-components cómo “tags” autónomos, que pueden convivir y estar anidados dentro de otros, pero independientes, la comunicación debería ser siempre mediante eventos. O mediante prospección.

O sea, aunque puede haber dependencias entre web-components, como la hay en un <table> con un <tr> y este con un <td> o un <ul> con un <li>. Pero realmente puedes usarlos por separado, aunque su funcionamiento no sea el esperado o no sea correcto.

Soy más partidario de un “Phenotypic Design” para los web-components. Es decir, diseñar los web-components basándonos en el conjunto de características visibles como resultado de la interacción entre su tipo y el medio.

Los tags HTML están clasificados por su tipo: Fundación, Formato, Formulario, Marco, Imagen, Audio, Enlace, Lista, Tabla, Estilo, Meta información y Programa.
¿Por qué no seguir esta clasificación y ampliarla para los web-components si es necesario?

Usando el concepto de “parientes” he visto siempre que ineludiblemente terminamos acoplando componentes padres, madres, hijos, sobrinas, abuelas y tíos todos entre sí, como buena familia. Pero ese no es el fin de los web-components, ya que solemos perder re-utilización fuera de la “familia”, creando verdaderas “mafias”.

Un web-component, por estar anidado dentro de otro no tiene porque crear una relación padre-hijo. Para mi tienen que crear una relación simbiótica. Y las hay de muchos tipos. Pueden ser un alga-hongo, creando un web-component de más valor. Árbol-ardilla, donde uno usa al otro para darle “cobijo”.
Creo que aporta una visión más amplia, menos limitante, donde es más fácil de mantener la individualidad, y por tanto la re-utilización de web-components en diferentes entornos, aplicaciones o webs.

Indexabilidad de los web-components

Otro tema que me ha preocupado siempre es que la encapsulación que hace el shadow DOM en los web-components que hace que su contenido no sea indexable y por tanto desaparece al darle a “ver código fuente de la página”, siendo invisible para los crawlers.

Pero esto creo que también es por un mal uso que le estamos dando a los web-components.

Si tengo por ejemplo un web-component de un menú de navegación, que al final puede ser un tag <nav> al que le hemos dado una funcionalidad especial en base a unos requisitos, incluso diferente en diferentes resoluciones pantalla, y al que le hemos dado un diseño concreto.
¿Por qué no utilizar el light-dom, es decir, el dom dentro del web-component, leer este en el ciclo de creación del mismo, y pintarlo conforme a los requisitos que necesitamos?
Estaríamos dando el contenido al crawler y encapsulando maquetación, diseño y funcionalidad. ¡Voila!

Porque otra aberración que veo bastante por ahí es pasar información a un web-component mediante un json ¡¡¡que insertamos como atributo!!!
¿Por qué no generar esa información en el light-dom con HTML semántico, indexable y accesible y luego “darle forma” en el web-component?

Es cierto que puede penalizar algo el tiempo de renderizado, pero no más si lo que tienes que leer es un json o una lista de elementos como atributo para pintarlos.
Y ademaś existen técnicas para poner un “loader” o añadir una animación de fade-in después del primer renderizado.

Por otro lado, si metemos el contenido del web-component en el light-dom, en el remoto caso de que no funcionara javascript, incluso podríamos asegurarnos de que la página tuviera contenido ya que el light-dom se renderiza, aunque probablemente se verá como “HTML feo” al no cargar el CSS de los componentes y no tener CSS para esos elementos HTML del light-dom.

Ejemplo de componente nav-list
En el repo de git se puede ver la evolución según versiones.

Mis conclusiones

No nos enseñan a buscar soluciones a los problemas, sino a usar las soluciones que conocemos ante cualquier problema.
Crear un web-component cuando:
- Se puede reutilizar.
- Tenga una presentación que no existe ya en un tag HTML
- Tenga una funcionalidad que le da entidad y sentido.
- Tenga necesidad de abstraer presentación/diseño del entorno donde se use.
Relación entre componentes simbiótica frente a la “familiar”
Comunicación entre componentes mediante eventos.
“Phenotypic Design” frente a “Atomic Design”
Utilizar el light-dom cuando sea posible, para insertar contenido al web-component y hacerlo indexable

Y si has leído hasta aquí ¡gracias! :)
Nos vemos por la comunidad.

Javascript Proxy: algunos usos prácticos

Mánu Fosela — Sun, 20 Sep 2020 01:10:05 +0000

Este post está basado en una mezcla de la traducción de los post del blog de Arbaz Siddiqui, y el blog de Eslam Hefnawy, javascrip.info
y del post en español de TodoJS y por su puesto de la documentación oficial en MDN

Introducción a Proxy

En términos de programación, proxy es cualquier entidad que actúa en nombre de alguna otra entidad. Un servidor proxy se encuentra entre un cliente y un servidor y actúa como cliente para el servidor y viceversa. El trabajo de cualquier proxy es interceptar las solicitudes / llamadas entrantes y reenviarlas en sentido ascendente. Esta intercepción permite que el proxy agregue lógica y cambie el comportamiento de las solicitudes entrantes y salientes.

El proxy Javascript es algo muy similar, se encuentra entre su objeto real y el código que intenta acceder a este objeto.
Nos permite hacer metaprogramación dinámica (metaprogramación: programas que escriben o manipulan otros programas).

Va a permitirnos interceptar las operaciones con objetos y sus propiedades de tal forma que podemos redefinir el comportamiento para cada una de estas acciones

De acuerdo con los documentos web de MDN:

El objeto Proxy se usa para definir comportamientos personalizados para operaciones fundamentales (por ejemplo, búsqueda de propiedades, asignación, enumeración, invocación de funciones, etc.).

Terminologías

Hay tres términos que necesitamos saber antes de poder implementar un proxy:

Objetivo (target)

Target es el objeto real que nuestro proxy interceptará. Este puede ser cualquier objeto de JavaScript.

Manejador (handler)

El manejador es un objeto donde viven todas las trampas.
Cada elemento de este objeto tiene como valor una función que implementa una trampa.

Trampas (trap)

Las trampas son métodos que interceptarán la llamada al destino cuando se llama a una propiedad o método. Hay muchas trampas definidas que se pueden implementar.
Los métodos que se pueden usar como trampas son:

Object methods:

getPrototypeOf()
setPrototypeOf()
isExtensible()
preventExtensions()
getOwnPropertyDescriptor()
ownKeys()

Property getters/setters:

has()
get()
set()
deleteProperty()

Function methods:

apply()
construct()

Ejemplo básico:

//movie is a target
const movie = {
    name: "Pulp Fiction",
    director: "Quentin Tarantino"
};

//this is a handler
const handler = {
    //get is a trap
    get: (target, prop) => {
        if (prop === 'director') {
            return 'God'
        }
        return target[prop]
    },

    set: function (target, prop, value) {
        if (prop === 'actor') {
            target[prop] = 'John Travolta'
        } else {
            target[prop] = value
        }
    }
};

const movieProxy = new Proxy(movie, handler);

console.log(movieProxy.director); //God

movieProxy.actor = "Tim Roth";
movieProxy.actress = "Uma Thurman";

console.log(movieProxy.actor); //John Travolta
console.log(movieProxy.actress); //Uma Thurman

El resultado de la ejecución del código anterior será:

God
John Travolta
Uma Thurman

En este ejemplo, nuestro objeto target era movie, implementamos un manejador con dos trampas: un get y un set.
Agregamos la lógica de que si estamos accediendo a la clave director, deberíamos devolver la cadena en God en lugar del valor real.
Del mismo modo, agregamos una trampa en el método set que interceptará todas las escrituras en el objeto de destino y cambiará el valor a John Travolta si la clave es actor.

Las posibilidades son infinitas

Casos de uso del mundo real

Aunque no es tan conocido como otras características de ES2015, Proxy tiene muchos usos.
Veremos escenarios del mundo real donde podemos usar proxies.

Validaciones

Como podemos interceptar las escrituras en un objeto, podemos hacer una validación del valor que estamos tratando de establecer en el objeto.

Por ejemplo:

const handler = {
    set: function (target, prop, value) {
        const houses = ['Stark', 'Lannister'];
        if (prop === 'house' && !(houses.includes(value))) {
            throw new Error(`House ${value} does not belong to allowed ${houses}`)
        }
        target[prop] = value
    }
};

const gotCharacter = new Proxy({}, handler);

gotCharacter.name = "Jamie";
gotCharacter.house = "Lannister";

console.log(gotCharacter);

gotCharacter.name = "Oberyn";
gotCharacter.house = "Martell";

La ejecución del código anterior dará como resultado lo siguiente:

{ name: 'Jamie', house: 'Lannister' }
Error: House Martell does not belong to allowed Stark,Lannister

En este ejemplo, restringimos que el valor permitido para la propiedad house solo pueda ser una de las casas permitidas. Incluso podemos usar este enfoque para crear objetos de solo lectura, todo lo que necesitamos hacer es lanzarlo dentro de la trampa set.

Efectos secundarios

Podemos usar proxies para crear efectos secundarios en una propiedad de lectura / escritura. La idea es activar alguna función si se accede o se escribe una propiedad en particular.

Por ejemplo:

const sendEmail = () => {
    console.log("sending email after task completion")
};

const handler = {
    set: function (target, prop, value) {
        if (prop === 'status' && value === 'complete') {
            sendEmail()
        }
        target[prop] = value
    }
};

const tasks = new Proxy({}, handler);
// ...otras tareas que al final llevan a poner un estado...
tasks.status = "complete";

La ejecución del código anterior dará como resultado el siguiente resultado:

sending email after task completion

Aquí estamos interceptando la escritura de la propiedad 'status' y si status está completa, estamos ejecutando una función de efectos secundarios.

Almacenamiento en caché

Como podemos interceptar el acceso a las propiedades del objeto, podemos construir en cachés de memoria para devolver solo valores de un objeto si no ha caducado.

Por ejemplo :

const cacheTarget = (target, ttl = 60) => {
    const CREATED_AT = Date.now();
    const isExpired = () => (Date.now() - CREATED_AT) > (ttl * 1000);
    const handler = {
        get: (target, prop) => isExpired() ? undefined : target[prop]
    };
    return new Proxy(target, handler)
};

const cache = cacheTarget({age: 25}, 5);

console.log(cache.age);

setTimeout(() => {
    console.log(cache.age)
}, 4 * 1000);
setTimeout(() => {
    console.log(cache.age)
}, 6 * 1000);

La ejecución del código anterior dará como resultado el siguiente resultado:

25
25 // a los 4 segundos
undefined // a los 6 segundos

Aquí hemos creado una función que devuelve un Proxy. El manejador de ese Proxy primero comprueba si el objeto ha caducado o no. Podemos ampliar esta funcionalidad para tener TTL basados en cada clave.
Otra aproximación puede ser usar ese TTL para pedir a una API (fetch) los datos una vez caducado.

Observar cambios en objetos

Como podemos interceptar el acceso a las propiedades del objeto, podemos crear nuevos elementos en DOM y renderizarlos cuando detectamos que una propiedad cambia o si se añade una nueva.

// NOTA IMPORTANTE!! 
// En el DOM tenemos un div con id=“salida”
//
function render(prop) {
  const salida = document.getElementById("salida");
  if (!document.getElementById(prop)) {
    const div = document.createElement("div");
    div.id = prop;
    salida.appendChild(div);
  }
  document.getElementById(prop).innerText = observables[prop];
}

handlerObservables = {
  set: function (observable, prop, value) {
    Reflect.set(observable, prop, value);
    render(prop);
    return true;
  },
  deleteProperty(observable, prop) {
    const elem = document.getElementById(prop);
    elem.parentNode.removeChild(elem);
    Reflect.deleteProperty(observable, prop);
    return true;
  }
};

const object = {};

const observables = new Proxy(object, handlerObservables);

observables["prueba"] = "valor";
// observables['otro'] = 'otro valor';
// delete observables['prueba'];

Si añadimos al objeto observables nuevos elementos, estos se irán añadiendo en el DOM dentro de la capa con id salida.
Si eliminamos del objeto elementos, estos se irán eliminando también del DOM.

Data binding

El enlace de datos suele ser difícil de lograr debido a su complejidad. El uso de proxies para lograr un enlace de datos bidireccional se puede ver en algunas “librerías” MVC en JavaScript, donde un objeto se modifica cuando el DOM sufre un cambio.

En pocas palabras, el binding de datos es una técnica que une varias fuentes de datos para sincronizarlas.

Supongamos que hay un con el id de username.

<input type = "text" id = "username" />

Digamos que se desea mantener el valor de esta entrada sincronizado con una propiedad de un objeto.

const inputState = {  id : 'nombre de usuario' , valor : '' }

Es bastante fácil modificar el valor de inputState cuando el valor del input cambia escuchando el evento ‘change’ del input y luego actualizando el valor de inputState. Sin embargo, lo contrario, actualizar el input cuando el valor de inputState se modifica, es más complicado a priori.

Un Proxy puede ayudar a lograrlo.

const input = document.querySelector('#username');
const handler = {
    set: function(target, key, value) {
        if (target.id && key === 'username') {
            Reflect.set(target, value);
            document.querySelector(`#${target.id}`)
            .value = value;
            return true;
        }
        return false;
    }
}

const proxy = new Proxy(inputState, handler)
proxy.value = 'John Doe'
console.log(proxy.value, input.value) 
// 'John Doe' will be printed for both

De esta manera, cuando haya cambio en inputState, el input reflejará el cambio que se ha realizado.
Combinado con escuchar el evento ‘change’, esto producirá doble data binding simple de input e inputState.

Si bien este es un caso de uso válido, generalmente no se recomienda por performance.

Convertir un array de objetos en agrupable

Este quizás sea el ejemplo más complejo, donde se anidan dos Proxy para poder agrupar por el campo que indiquemos.

Partimos del siguiente json con datos sobre características de procesadores:

const procesadores2020 = [
 {
   "procesador": "Athlon 200GE",
   "nucleos": "2",
   "hilos": "4",
   "frecuencia-min": "3.2GHz",
   "frecuencia-max": "3.2GHz",
   "precio": "66.18 €"
 },
 {
   "procesador": "Core i3-9100F",
   "nucleos": "4",
   "hilos": "4",
   "frecuencia-min": "3.6 Ghz",
   "frecuencia-max": "4.2 Ghz",
   "precio": "67.99 €"
 },
 {
   "procesador": "Ryzen 3 3100",
   "nucleos": "4",
   "hilos": "8",
   "frecuencia-min": "3.6 Ghz",
   "frecuencia-max": "3.9 Ghz",
   "precio": "105.58 €"
 },
 {
   "procesador": "Ryzen 5 2600X",
   "nucleos": "6",
   "hilos": "12",
   "frecuencia-min": "3.6 Ghz",
   "frecuencia-max": "4.2 Ghz",
   "precio": "136.35 €"
 },
 {
   "procesador": "Core i5-10400F",
   "nucleos": "6",
   "hilos": "12",
   "frecuencia-min": "2.9 Ghz",
   "frecuencia-max": "4.3 Ghz",
   "precio": "149.89 €"
 },
 {
   "procesador": "Ryzen 5 3600",
   "nucleos": "6",
   "hilos": "12",
   "frecuencia-min": "3.6 Ghz",
   "frecuencia-max": "4.2 Ghz",
   "precio": "200.80 €"
 },
 {
   "procesador": "Ryzen 7 2700X",
   "nucleos": "8",
   "hilos": "16",
   "frecuencia-min": "3.7 Ghz",
   "frecuencia-max": "4.3 Ghz",
   "precio": "207.59 €"
 },
 {
   "procesador": "Core i7-10700K",
   "nucleos": "8",
   "hilos": "16",
   "frecuencia-min": "3.8 Ghz",
   "frecuencia-max": "5.1 Ghz",
   "precio": "384.90 €"
 },
 {
   "procesador": "Ryzen 7 3700X",
   "nucleos": "8",
   "hilos": "16",
   "frecuencia-min": "3.6 Ghz",
   "frecuencia-max": "4.4 Ghz",
   "precio": "309.95 €"
 },
 {
   "procesador": "Core i9-10850K",
   "nucleos": "10",
   "hilos": "20",
   "frecuencia-min": "3.6 Ghz",
   "frecuencia-max": "5.2 Ghz",
   "precio": "486.00 €"
 },
 {
   "procesador": "Ryzen 9 3900X",
   "nucleos": "12",
   "hilos": "24",
   "frecuencia-min": "3.8 Ghz",
   "frecuencia-max": "4.6 Ghz",
   "precio": "443.90 €"
 },
 {
   "procesador": "Ryzen 9 3950X",
   "nucleos": "16",
   "hilos": "32",
   "frecuencia-min": "3.5 Ghz",
   "frecuencia-max": "4.7 Ghz",
   "precio": "758.87 €"
 },
 {
   "procesador": "Ryzen Threadripper 3970X",
   "nucleos": "32",
   "hilos": "64",
   "frecuencia-min": "3.7 Ghz",
   "frecuencia-max": "4.5 Ghz",
   "precio": "2099.00 €"
 }
];

Si queremos poder agrupar por los campos de los objetos del array este sería el código.

const groupable = (collection) => {
 // Comprueba que la colección sea un array
 if (!(collection instanceof Array)) {
   throw new TypeError("The input collection is not an Array");
 }

 let grouped = {};
 Object.defineProperty(collection, "groupBy", {
   configurable: true,
   enumerable: false,
   writable: false,
   value: {}
 });

 return new Proxy(collection, {
   get(target, property, receiver) {
     if (property === "groupBy") {
       return new Proxy(target[property], {
         get(target, property, receiver) {
           // si la propiedad a agrupar no existe devolver []
           if (!collection[0].hasOwnProperty(property)) {
             console.log('no encontrado')
             return [];
           }
           // caso contrario, agrupar por la propiedad
           const output = {};
           collection.groupBy[property] = {};
           grouped[property] = {};
           collection.reduce(function(acc, cur) {
             if (!Array.isArray(acc[cur[property]])) {
               acc[cur[property]] = [];
             }
             acc[cur[property]].push(cur);
             return acc;
           }, output);
           grouped[property] = {...output};
           return grouped;
         }
       });
     }
     return Reflect.get(target, property, receiver);
   }
 });
};

const datasource = groupable(procesadores2020);
console.log(datasource.groupBy['hilos']);
console.log(datasource.groupBy['frecuencia-max']);

Cuando declaramos el array como “groupable” llamando a la función con el mismo nombre y pasandole el array, lo primero que hace es crear una nueva propiedad llamada “groupBy”, convirtiendo el array y devuelve un Proxy que intercepta el get del array.
Podemos decir que hemos ampliado los métodos del array.

De esta manera si llamamos a cualquier propiedad 0, 1, 2… devolverá el objeto correspondiente a esa posición.
Si llamamos a groupBy nos devuelve otro Proxy que tiene otra trampa en get de manera que a partir del campo que recibe, recorre el array y los agrupa por el campo pasado y devuelve el array agrupado.

Esta manera es la manera de añadir funcionalidad a objetos de javascript sin tener que tocar su 'prototipo'.

Por ejemplo, en String tenemos el método toLowercase() y toUppercase() pero no tenemos el método capitalize(). Si queremos añadir a String el método capitalize podemos hacerlo modificando la cadena protypica del tipo primitivo string:

   String.prototype.capitalize = function() { 
     const str = [...this]; 
     str[0] = str[0].toUpperCase(); 
     return str.join(''); 
   }

   console.log('buenos días'.capitalize()); // Buenos días

De esta manera, todos los String que se creen a partir de esa declaración tendrán un nuevo método 'capitalize' que convierte la primera letra en mayúscula.

Si esto lo hacemos mediante Proxy, al no ser String un objeto sino un tipo primitivo, tenemos que convertir el String en Object, con lo que perdemos los métodos de String:

const addCapitalize = function(value) {
  const arrStr = [...value];
  arrStr.capitalize = function() {
    arrStr[0] = arrStr[0].toUpperCase();
    return arrStr.join(''); 
  }
  return new Proxy(arrStr, {
    get(target, property, receiver) {
      let value = new String(arrStr.join(''));
      if (property === 'capitalize') {
        value = target[property];
      }
      return value;
    }
  });
}

const saludo = addCapitalize('buenos días');
console.log(saludo.capitalize());
console.log(saludo.toUpperCase()); // ERROR: perdemos el resto de métodos de String...

Con lo que está no parece ser la manera de ampliar métodos en tipos primitivos.

Inconvenientes de los Proxies

Si bien los proxies son bastante “mágicos”, hay algunos inconvenientes con ellos por que debemos tener cuidado.

El rendimiento puede tener un impacto drástico cuando se usan muchos proxies y, por lo tanto, debe evitarse al escribir un código donde el rendimiento sea crítico.
Dado un objeto, no hay forma de saber si se trata de un objeto Proxy u objetivo.
Por último, los servidores Proxy no necesariamente conducen a un código muy limpio y fácil de entender.

Conclusión

Los proxies son increíblemente poderosos y se pueden usar y abusar para una amplia gama de cosas.