I don’t think templates should become hidden execution environments.

That was one of the main ideas I kept coming back to while building Pick Components, a small Web Components framework I’ve been working on in TypeScript.

I haven’t been doing TypeScript forever. In fact, part of the reason I started building this was because I wanted to understand the browser, components, templates, decorators, and reactivity from the inside instead of just using another big stack and accepting all of its decisions.

At first, templates feel like the obvious place to add power.

You start with:

<p>Hello, {{name}}</p>

Then you want conditions.

Then loops.

Then expressions.

Then event wiring.

Then helper calls.

Then more complex logic.

And after a while, the template is no longer just describing UI. It starts becoming a second programming environment.

That is where things get uncomfortable for me.

The problem is not templates

I like templates.

They are readable. They make UI structure obvious. They are close to HTML, and that matters.

The problem starts when too much responsibility gets pushed into them.

At some point, the component becomes harder to reason about because logic is split across too many places:

• some in the class
• some in services
• some in event handlers
• some in template expressions
• some hidden behind framework rules

That can work, of course. Many frameworks do it well.

But I wanted a different trade-off.

I wanted templates to stay useful, but limited.

The rule I ended up with

In Pick Components, I try to keep the template focused on rendering.

The stronger TypeScript parts stay in TypeScript:

• state
• actions
• services
• lifecycle
• routing
• domain logic

A very small example looks like this:

import { PickComponent, PickRender, Reactive } from "pick-components";

@PickRender({
  selector: "hello-example",
  template: `<p>Hello, {{name}}!</p>`,
})
export class HelloExample extends PickComponent {
  @Reactive name = "Somebody";
}

The template reads the value.

TypeScript owns the state.

That sounds simple, but that boundary matters a lot.

Why I avoided arbitrary JavaScript in templates

One decision I made early was that templates should not run arbitrary JavaScript.

No eval.

No new Function.

No “just execute this string and hope for the best”.

Pick Components uses a constrained expression model instead. The goal is not to make the template as powerful as TypeScript. The goal is to make it predictable.

That is a trade-off.

It means the template cannot do everything.

But that is also the point.

When logic becomes important, I want it back in TypeScript, where the tooling, types, imports, refactoring, and errors are stronger.

Declarative does not have to mean magical

For example, list rendering can still be declarative.

pick-for exists for that:

<pick-for items="{{users}}" key="id">
  <article>
    <strong>{{$item.name}}</strong>
    <span>{{$item.email}}</span>
  </article>
</pick-for>

But the data, filtering, loading, and behavior stay in TypeScript.

That is the balance I am trying to keep:

@Reactive users: User[] = [];
@Reactive searchQuery = "";

get filteredUsers(): User[] {
  const query = this.searchQuery.trim().toLowerCase();

  if (!query) {
    return this.users;
  }

  return this.users.filter((user) =>
    user.name.toLowerCase().includes(query),
  );
}

The template renders.

The component decides.

The service does the real work.

A real project helped me test the idea

[Image here: Kronometa screenshot]

I also used Pick Components in a small race timing app called Kronometa.

That project made the idea feel more real.

Kronometa is not just a set of pages. It moves through phases:

• choose race mode
• register runners
• start the race
• record finishes
• review results

That pushed me to think about routing as part of the application flow, not just URL matching.

The UI should not let you jump anywhere if the race state does not allow it.

That is where the structure helped: components for UI, services for rules, routing for flow, and templates mostly for rendering the current state.

What I learned

The biggest lesson for me was this:

Good DX is not only about adding more features.

Sometimes it is about deciding where things should not go.

I don’t want templates to become a second TypeScript.

I don’t want components to become a dumping ground for every kind of logic.

I don’t want routing to be disconnected from the actual state of the app.

Pick Components is my attempt to explore those boundaries in a way that still feels close to the browser.

This is not meant to replace everything

I am not saying this is the right approach for every app.

It is definitely not a “React killer”, a “Vue replacement”, or any of that nonsense.

It is a small framework built around a set of trade-offs that make sense to me:

• native Web Components
• constrained templates
• reactive state
• explicit lifecycle
• services outside the UI
• less hidden runtime behavior

Maybe that is useful to other people too.

Maybe it is just a good learning project.

Either way, building it has changed how I think about frontend architecture.

Links

Playground: https://janmbaco.github.io/PickComponents
Repository: https://github.com/janmbaco/PickComponents

I would be happy to hear what people think, especially around templates, TypeScript DX, and how much logic belongs in the view layer.