How BaseNative compares

• 150

  Lines of reactivity core

• 0

  Core runtime dependencies

• 0

  Build steps required

• 6

  Core API primitives

Bundle size

BaseNative ships raw ES modules. No bundler, no tree-shaking needed — what you import is what runs. The runtime is one package you can read end to end.

Templates are data

BaseNative expressions are interpreted by a hand-written parser — a tokenizer, a recursive-descent grammar, a scope object. There is no eval and no Function constructor anywhere in the shipped runtime or server; the count is taken from source on every build, and it is 0. A BaseNative page runs under script-src 'self' with no 'unsafe-eval' — and unlike the compiled frameworks, that does not depend on a build having happened first.

Because a template is never compiled into code, a template is data. It can live in a CMS, come out of a database, or be written by a model, and rendering it cannot turn it into an injection: the parser interprets a deliberate subset — property access, calls into the provided scope, operators, ternaries — and blocklists prototype access. React, Angular and Svelte are safe the opposite way: their templates become code at build time, which is exactly why a template has to go through the build before it can run at all.

The narrow, measured version of that claim: an LLM wrote the same two apps twice, in BaseNative 2.1.0 and in React 19.3.1 — a server-rendered catalog and an interactive counter-and-list page, sharing one dataset, with identical behavior tests on both sides and every fix logged. With no build pipeline in the way, the BaseNative side needed no tooling fixes at all. Both implementations passed every test. What differed was the path, and the code-size hypothesis failed in public:

API surface

Fewer primitives means less to learn and less to break. BaseNative's entire reactivity model fits on a whiteboard.

Counter: the same app, four ways

A reactive counter shows each framework's mental model. BaseNative uses plain HTML with signal expressions — no compilation, no special file format.

<div :data="{ count: 0 }">
  <p>Count: {{ count }}</p>
  <button @click="count++">+1</button>
</div>
<script type="module">
  import { hydrate } from '/basenative.js?v=72245475d1';
  hydrate(document.body, { count: 0 });
</script>

import { useState } from 'react';

export default function Counter() {
  const [count, setCount] = useState(0);
  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setCount(c => c + 1)}>
        +1
      </button>
    </div>
  );
}

import { Component, signal } from '@angular/core';

@Component({
  selector: 'app-counter',
  template: `
    <p>Count: {{ count() }}</p>
    <button (click)="count.set(count() + 1)">
      +1
    </button>
  `,
})
export class CounterComponent {
  count = signal(0);
}

<script>
  let count = $state(0);
</script>

<p>Count: {count}</p>
<button onclick={() => count++}>+1</button>

SSR and hydration

BaseNative includes server rendering and 4 built-in lazy hydration strategies out of the box. Most frameworks require extra packages or custom implementations for selective hydration. Server and client interpret the same expressions through the same shared parser, so the markup the server renders is the markup the client hydrates — there is no second template dialect to drift.

Developer experience

The place BaseNative is furthest behind. None of this is close, and pretending otherwise would waste your afternoon.

Honest tradeoffs

BaseNative isn't trying to replace React or Angular for every use case. Here's where it genuinely excels and where you should think twice.

When to choose BaseNative

Try it

The reactivity core is 150 lines. Read it, understand it, then decide.