Inheritance is one of OOP’s most powerful tools, but also one of its easiest to misuse. When applied in the wrong places, it can create internal dependency hell.

Yet Wraplet does provide base classes with basic implementations of the Wraplet API that users can extend. They are thin, sure, but I never wanted to force them on people using Wraplet. That's why Wraplet API is encapsulated in a single property, and can be created manually on any class, so anyone who wants to avoid inheritance can do so completely. The Wraplet API can be created by calling a single function: createWrapletApi. You can hook into the wraplet's lifecycle by passing lifecycle callbacks to it.

Hard to make it simpler than that, right?

I'm thrilled to announce the release of the 1.0.0-rc.1 version.

So what does this mean for you? It's a pledge that there will be no further BC breaking API changes. The API you build on today is the API you can rely on.

Why am I confident enough to commit to that? Because Wraplet is (and has been for quite some time already) 100% covered with tests, including branch coverage. It was tempting to push out a 1.0.0 release right away. For long-lived projects a certain caution is required, though, and it's best to exercise it from the start, so we'll move slowly and strictly follow the SemVer rules.

One thing worth clarifying: the stability pledge doesn't mean the base classes you extend are frozen solid. Within minor versions Wraplet may still add new methods and properties to them as its capabilities grow — in particular lifecycle methods whose names start with on. To stay on the safe side, treat the on prefix as reserved and avoid using it for your own methods on classes deriving from Wraplet, so a future addition can't clash with them. We'll be careful about the name clashes.

Introduction​

Wraplet takes what you like about Web Components – class per element, no virtual DOM, server-rendered HTML, and adds typed dependency management, lifecycle decoupled from the DOM, and more. Still, both share a lot of DNA, and the best way to see it is to look at the same widget written in both.

Here is a simple "color toggle" as a Web Component:

The Landscape​

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

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