I’m a .NET Developer, and I Want to Be Free from Frameworks.

So Why Use a Framework at All?

I’m a .NET developer, and I have a dream. A dream to be free from frameworks.
I don’t want to depend on massive ecosystems where rendering a simple button requires installing 100 megabytes of dependencies and reading through dozens of pages of documentation. I want a simple implementation.

I don’t want a component that brings along a hundred others — just to show a button with an icon.
I don’t want to waste time resolving version conflicts and dependency hell when I could be working on logic and UI meaning.

And if I just need to refresh a component on the page — like in an SPA — that shouldn’t require restructuring the entire application. There’s no reason to subscribe to global state, register routes, or adhere to complex patterns. It’s just a reload, nothing more.

What works well on the server shouldn’t be forced into the client. We shouldn’t wrap everything in JavaScript just to compensate for it later with server-side JavaScript. It introduces unnecessary complexity and raises the entry barrier for developers.

In this vision, I have a partner — AI.
It doesn’t get tired. It doesn’t argue. And it truly understands HTML, CSS, and JavaScript. This is its native territory. It knows structure, style, behavior. It doesn’t need frameworks. It needs clear instructions — and it knows how to produce them.

It can generate interfaces, styles, animations. Confidently, reliably, fast. Its knowledge of this domain is deep and powerful.
And then I asked myself: if both AI and I understand these technologies well — why do we need a framework at all?
Why learn to wrap a simple idea in 10 layers of abstraction, when we can just write exactly what we mean?

What I Want Instead

We’ve accepted complexity as the cost of expressiveness — and for a time, that trade-off made sense. Before AI, we needed frameworks to structure our ideas, compensate for limitations, and unify practices across projects.

But today, we stand at a turning point.

That’s how Instancium TagKit Core was born.
It’s not a framework. It’s a rendering protocol.
It doesn’t require global state. It doesn’t ask for magical subscriptions. It doesn’t build a universe around your component.
It simply brings HTML to life.
You control the markup. It activates it.
Need SSR? Great. Need interactivity? Add JS where it’s needed — and only there. No excess. Each component remains isolated, clean, and understandable.

Instancium TagKit Core is built on simple principles:

• Markup comes first. A component is HTML, CSS, and logic — not a framework structure.
• Components don’t take over the app. They do only what they’re meant to.
• Rendering is transparent and controlled.
• AI can create, edit, and test such components — no magic, no ceremony, and no stumbling over framework version mismatches.

It’s an architecture where both humans and AI can work together.
Not as an experiment — but for productivity. To spend less time fighting the system, and more time creating value.
Instancium doesn’t compete with frameworks. It simply shows that there’s another way.

Right now, this idea is expressed as an open beta. But behind it is a philosophy and an engineering mindset. And it has every chance to become a new approach to building component-based user interfaces.

Follow the progress, join the discussion, and check out the repository:
https://github.com/Instancium/Instancium.TagKit