Front-end, regrounded: Why Wraplet might be what you’re missing | Wraplet

Skip to main content<br>The Landscape​

Difficulty in recognizing what depends on what is the main reason why the code<br>is unreadable. It applies to both: a micro and macro scale. It's this relationship<br>that makes the fabric of a mental model.

Frameworks solve this problem by forcing a specific structure on the code.<br>This is what developers like because code becomes predictable. When the dependency<br>model is easier to read, the logic is easier to follow. However, in my<br>opinion, popular frameworks are doing way too much in this department.<br>Everything is clean on the surface level but ugly underneath. And if things<br>don't quite work as expected because of the hidden framework's logic that you<br>didn't fully grasp, you are in for a rough ride of debugging a framework instead<br>of your own code.

This introduces a whole class of framework-specific knowledge<br>that is needed to be proficient. This additional knowledge makes switching<br>between frameworks exhausting. Imagine you inherited a codebase written in an unknown framework.<br>You have new, clean code, but you cannot interpret it unless you will put<br>a lot of effort to understand this framework's internals.

This is what makes JavaScript's landscape so gruelling, unless you stick to<br>a single framework and don't bother to learn others, even if they might be<br>better for your use case. And what's the alternative? Bending your favorite framework to fit your<br>needs against its strengths? Defaulting to jQuery or vanilla JS as the quick-and-dirty<br>solution for everything else? Almost everyone at some point thought: "I would rather write this in vanilla JS",<br>but it has its own problems: it's imperative, the code structure is completely up to<br>the developer, and as each developer has different preferences, the resulting code<br>will always be unreadable to someone. Inconsistent dependency structure is what makes<br>vanilla JS hard to maintain. It's the same thing that made jQuery hated.

What if we had a framework focused exclusively on giving you the readable and testable<br>structure, with minimal internals and magic? It would make your "quick and dirty" solutions<br>no longer dirty but actually maintainable without much of the framework-specific knowledge required.

Wraplet enters the chat.

Wraplet​

Wraplet is a small TypeScript framework that wraps real DOM nodes with real<br>classes, gives them a predictable lifecycle, and lets you wire them together<br>with typed, declarative dependencies.

That is essentially all it does, and<br>most of the time, that is all you actually need – unless you are building<br>a full SPA, and even then, you can get surprisingly far with Wraplet alone.

What follows is a short tour of why that turn might be worth taking.

The growing fatigue with framework magic​

Wraplet came to life as an answer to the growing fatigue with the popular<br>frameworks. React, Vue, Angular, Svelte – each of them is a great tool in its<br>own right, and each of them asks you to accept a certain amount of magic in<br>exchange for productivity.

There is a:

virtual DOM that diffs and patches on your behalf,

reactivity system that quietly tracks reads in invisible scopes,

compiler that rewrites your code into something that no longer<br>matches what you wrote,

and an ever-growing collection of file-based routers, server components,<br>hydration boundaries, and "use client" directives, all revolving around<br>a constantly moving definition of what a "component" even is.

When everything works, it feels elegant. When something breaks, you are<br>often debugging the framework instead of your code, and the gap between<br>"what I wrote" and "what runs in the browser" keeps widening. A growing<br>number of developers - especially those maintaining long-lived applications,<br>server-rendered apps, or libraries - are starting to push back. They want<br>code they can read top to bottom, without a mental model of a compiler<br>sitting between them and the browser.

Wraplet is built for exactly that audience. There is no virtual DOM, no<br>compile-time transformation of your components, no hidden reactivity graph.<br>A wraplet is a class. The class has a lifecycle with a constructor,<br>an onInitialize hook, an onDestroy hook, and a node it owns. That is the whole mental model.

Here is the smallest example - a clicker wrapping an existing<br>piece of HTML:

The HTML is the HTML you would have written anyway. The class attaches to it,<br>listens for clicks, and updates the DOM. There is no template language, no<br>re-render cycle, no reconciliation. If you can read JavaScript and the DOM API,<br>you can read – and debug – this code.

Easier to understand – for humans and LLMs​

A subtle but important consequence of avoiding magic is that Wraplet code is<br>unusually friendly to readers. And in 2026, "readers" no longer means just<br>your teammates. Modern development is increasingly a collaboration between<br>humans and large language models. Whether you use an LLM to review a pull<br>request,...