abtahi-tajwar

Posted on Jun 15

How I Accidentally Came Up With a Reactive JS UI Library

Okay okay — I get it. Please don’t roll your eyes 🙏

Yes, I built yet another JavaScript UI library. I know it seems like every day there’s a new one popping up — Svelte, Solid, Alpine, HTMX… and now, VaneJS.

But hear me out — this wasn’t the plan.

🚧 The Accidental Start

It all began with a basic personal project. I was building my portfolio site using a raw HTML/CSS template. My goal was simple: load content from a JSON file dynamically — no fuss.

Naturally, I thought of using Svelte. It has that clean, HTML-like syntax and is pretty powerful. But it didn’t feel worth the migration headache just for a small site. So I fell back to vanilla JS.

Now here’s the problem: I kept spamming document.querySelector, innerHTML, and manual state updates just to reflect data. Tedious. So I thought:

"Why not just write a simple templating engine?"

I just wanted to dump data into the HTML cleanly. But... it spiraled. 😅

Before I knew it, I had:

Reactive state management
Loops and conditional rendering
Store syncing between pages
Event bindings with inline params
And yes, even an API call example

Then I thought: "Okay, this is officially something."

I picked a name — VaneJS — in like 10 seconds.

👉 Check the documentation

✨ Very Basic Usage

Here’s the hello world of VaneJS. No CLI, no build step, no npm — just plug and play.

<!-- index.html -->
<script type="module" src="vanjejs.module.js"></script>

<h1 data-vn-bind="user.name">Hello</h1>

<script type="module">
  import { $setState } from './vanjejs.module.js';

  $setState("user", { name: "Abtahi" });
</script>

Want to add loops?

<ul data-vn-repeat="user.skills as skill">
  <li data-vn-ritem="{skill}.label"></li>
</ul>

Update with:

$setState("user", {
  name: "Abtahi",
  skills: [{ label: "JS" }, { label: "C++" }]
});

And conditionally render blocks:

<div data-vn-if="{theme} === 'dark'">Dark Mode</div>
<div data-vn-else>Light Mode</div>

🧠 What Makes VaneJS Different?

✅ Zero Build Step: Just add a single static .js file to your project. No bundlers, no compilers.
✅ Backend Friendly: Works out-of-the-box with PHP, Laravel, Django, Express, ASP.NET — whatever you want.
✅ No Paradigm Shift: Feels like HTML, behaves like a reactive system.
✅ Minimal Mental Overhead: You don’t need to “learn a framework.” If you know HTML and JS, you’re good.
✅ Reactive Stores Between Pages: Yes, you can store values and retrieve them across HTML pages.

<!-- about.html -->
<p data-vn-bind="mystore.name"></p>

// main.js
$setStore("mystore", { name: "SharedValue" });

✅ Smart Inline Events: Attach multiple events inline:

<button data-vn-on="click:myFunc({user.name}); mouseover:logHover()">Click me</button>

$event("myFunc", ({ params }) => console.log(params[0]));
$event("logHover", () => console.log("hovered!"));

🚀 What’s Next

I’m actively building more around the zero-config, zero-setup philosophy:

🔨 Templating System: You’ll be able to define reusable templates without any build tools. Like:

export default () => \`
  <h1>Hello</h1>
  <p data-vn-bind="user.bio"></p>
\`

🧠 Language Server (LSP): I’m planning to write an LSP for VaneJS so your editor can offer intellisense, diagnostics, and autocompletion just like in React or Svelte.
🌱 Plugin System (planned): Think mini-addons for things like forms, routers, or animation — optional and simple.

👋 Final Thoughts

I didn’t set out to build a JavaScript UI library. I was just trying to get my site done faster. But sometimes, the shortcuts become the road.

If you’re a fullstack dev, or even a backend-first developer who hates writing repetitive DOM updates — try VaneJS. It might just save you a few headaches.

🔗 Docs: vanejs.netlify.app

📦 Demo / GitHub: https://github.com/abtahi-tajwar/vanejs

Top comments (15)

Alvaro Flaño • Jun 16 • Edited

There is always value on the learning experience of reinventing wheel. So good job!

That being said, do you see any benefits of this over AlpineJS?

abtahi-tajwar • Jun 20

At this point, not significantly, but I have built it so that over time, I have something to make it unique gradually for sure.

Ahmed Grwan • Jun 17

My thoughts exactly

Yohan Moore • Jun 16

If it works for you and makes your development experience easier and your clients don't care what you use then all the best to you. Everyone should try their hands at developing a web framework. So much to gain from the experience.

abtahi-tajwar • Jun 20

Thank you so much for your appreciation

Laxman Rathod • Jun 21

This looks great. I'll give it a try. Thanks for sharing!

Sourabh Raj • Jun 17

Looks neat. I like the plug and play philosophy. Could be a nice static templating engine.

abtahi-tajwar • Jun 20

Really happy that you liked it. Also let me know your thoughts if you have something you want to see in a library like this!

Firmansyah Adiputra • Jun 17

Have you try web components (lit)? I usually use lit when I need to do DOM manipulation/templating.

abtahi-tajwar • Jun 20

I have just searched it up. lit looks amazing. Is it usable without any npm?

Sean May • Jun 16

Way to go.

There's a lot to be learned (and a lot to be shared) when people do this stuff. You may retread over some buried wisdom about why doing certain things is good (or bad), and sometimes, you hit the same brick walls, and sometimes, the conditions and context provide a new path that makes the solution viable.

I’m banging my way through a system that's TS(X), right now, but also 0 build step, HMR, and local-first, while still doing image optimizing and the like...
It is simultaneously more and less ambitious, because all of the tools have been built with massive assumptions baked in.

I’m glad more people are thinking about what alternatives can look like, for simpler (and still effective) dev-experience, with the current state of tooling.