I’ve been working on a side project for the last 5 months, and I finally got to a point where I feel okay sharing it.
It’s called No.JS. It’s an HTML-first reactive framework. The idea is simple: what if you could build reactive web apps using just HTML attributes, without writing JavaScript?
<hr>
<h3>How it started</h3>
I was at my last job, deep in an Angular codebase. Not a bad one, honestly. Well-architected, good team. But one day I needed to add a dropdown that filtered a table. Simple stuff, the kind of thing that should take ten minutes tops.
I created a component, a module to declare it in, a service to fetch the data, an interface for the response type, an observable pipe to debounce the input, and a template that referenced all of it. Six files, maybe forty lines spread across them, just to say “when this changes, re-fetch that and show it here.”
I remember looking into my vscode, clicking between <code>filter-dropdown.component.ts</code>, <code>filter-dropdown.module.ts</code>, <code>filter.service.ts</code>, <code>filter.model.ts</code>, and thinking: the actual logic I care about fits in a sentence. Everything else is just the framework and established conventions (HATE THEM!) asking me to prove I mean it or I know all that ˆ%&amp;ˆ*(*.
That thought stuck with me. So I looked around. Found an awesome project with an even greater name: HTMX.
HTMX was the first thing I tried. Genuinely great project, and it nails the server-driven model. If your backend is the brain, HTMX just wires the HTML to it beautifully. But I didn’t have a backend. I had a static page and a public API. HTMX assumes a server that returns HTML fragments, and for my use case that meant I’d still need to stand up a server just to proxy and template the responses.
Then I tried Alpine.js. Closer to what I wanted. Reactive, lightweight, stays in the HTML. I liked it a lot. But after a few days I kept bumping into walls: no declarative HTTP, no SPA routing, no built-in loops-over-fetched-data pattern. I was writing little <code>x-init</code> scripts to fetch, parse, and assign data, then wiring up <code>x-for</code> separately. It worked, but it felt like I was assembling the plumbing myself every time, and the thing I wanted (just point this element at an endpoint and render what comes back) was always just out of reach.
What I was missing was the middle ground. Something that lives entirely in HTML like Alpine, talks to APIs like HTMX, but treats the whole lifecycle (fetch, bind, loop, route) as one continuous surface. Not a server story. Not a scripting story. An HTML story.
So I started building one.
<hr>
<h3>What it looks like</h3>
A reactive search box in No.JS:
<pre><code>&lt;div state=&quot;{ query: &#x27;&#x27; }&quot; get=&quot;/api/search?q={{ query }}&quot; as=&quot;results&quot;&gt;
 &lt;input model=&quot;query&quot; /&gt;
 &lt;li each=&quot;r in results&quot; bind=&quot;r.name&quot;&gt;&lt;/li&gt;
&lt;/div&gt;
</code></pre>
Four lines. It’s reactive, auto-fetches when <code>query</code> changes, and renders the results. No imports, no hooks, no build step. (I Got this from my html docs just to show you guys how it works)
<hr>
<h3>The thinking behind it</h3>
Browsers already understand HTML. They already handle events, update the DOM, manage layout. Somewhere along the way we started treating the browser as something to work around instead of something to work with.
HTMX proved that a lot of people feel the same pull back toward HTML. Alpine proved you can have reactivity without a build step. No.JS tries to carry that further: what if HTML attributes could cover the entire surface (data fetching, state, routing, validation, i18n) so you never have to drop down to a script block at all?
Attributes become the API: <code>bind</code> for data, <code>each</code> for loops, <code>get</code> for fetching, <code>state</code> for reactivity. Your templates are valid HTML that any browser can read.
It’s not anti-JavaScript. There’s still JS under the hood. But the developer-facing layer is HTML, and for a lot of use cases that turns out to be enough.
<hr>
<h3>What’s in it</h3>
It’s more complete than you’d expect:
<ul>
<li>Declarative HTTP (<code>get</code>, <code>post</code>, <code>put</code>, <code>delete</code>)</li>
<li>Reactive binding (<code>bind</code>, <code>model</code>)</li>
<li>Conditionals and loops (<code>if</code>, <code>show</code>, <code>each</code>, <code>switch</code>)</li>
<li>State management (local <code>state</code>, global <code>store</code>, <code>computed</code>, <code>watch</code>)</li>
<li>SPA routing with guards, params, nested routes</li>
<li>Form validation</li>
<li>Animations and transitions</li>
<li>i18n with pluralization</li>
<li>30+ built-in filters</li>
<li>Custom directives</li>
</ul>
~11 KB gzipped, zero dependencies.
<hr>
<h3>Where it’s at</h3>
I rewrote the core three times. I went back and forth on the directive API more than I’d like to admit. I wrote tests, wrote docs, and built the documentation site with No.JS itself.
It’s not going to replace React for large team projects with complex tooling needs. That’s not the goal. But for landing pages, dashboards, internal tools, prototypes, or anything where you just need something reactive without the ceremony, it works well.
<h3>One thing I’ll be honest about</h3>
When your template language lives in HTML attributes and evaluates expressions at runtime, you’re essentially handing the browser a tiny interpreter. That keeps me up at night a little. I’ve put guardrails in place (sandboxed evaluation, no <code>Function</code> constructor on user-facing inputs, scope isolation between components), but I haven’t battle-tested it the way a framework with five years and a hundred contributors has. XSS surfaces, expression injection, what happens when someone pipes unsanitized API data straight into a <code>bind</code> – I’m still mapping all of that out.
If you’ve worked on CSP policies, template sanitization, or runtime sandboxing and something here makes you wince, I genuinely want to hear it. Security is the one area where “it works on my machine” isn’t good enough, and I’d rather have someone poke holes in it now than find out the hard way later.
The project is open source (MIT): <a href="http://github.com/ErickXavier/no-js" target="_blank" rel="noopener nofollow">github.com/ErickXavier/no-js</a>
If you want to try it:
<pre><code>&lt;script src=&quot;https://unpkg.com/@erickxavier/no-js@latest/dist/iife/no.js&quot;&gt;&lt;/script&gt;
</code></pre>
That’s the whole setup.
BTW, I didnt want my name in the npm package url but just <code>no-js</code> was too similar to other 2 dead projects: <code>nojs</code> and <code>no.js</code>. And I just followed the NPMJS suggestion, I used my name (github username).
I covered the thing with tests, but I’m expecting the community to find bugs and create their own PRs. Please, do! I need all the help with this one!
<hr>
Mostly I’m curious what people think. I’ve been heads-down on this for a while and would love some outside perspective. Feedback, questions, criticism, suggestions, all welcome.

No.JS is a new open-source HTML-first reactive framework (~11 KB gzipped, zero dependencies) that lets developers build reactive web apps using only HTML attributes — no JavaScript required on the developer side. Inspired by frustrations with Angular's boilerplate and gaps in HTMX and Alpine.js, it covers declarative HTTP requests, reactive binding, loops, conditionals, state management, SPA routing, form validation, animations, i18n, and custom directives. A reactive search box requires just four lines of HTML. The author acknowledges open security concerns around runtime expression evaluation and sandboxing, and is seeking community feedback, bug reports, and contributions.

No.JS: an HTML-first reactive framework (no JS required on your end)