What is the risk here?

Are you worried that in a year it will be missing a feature you want?

It's client side javascript, aside from DOM based XSS (which if reported, you can probably fix yourself), there isn't much to worry about from the security perspective. The web doesn't normally deprecate things so it's probably going to work in a year too.

This is a tiny project which already requires that you know JavaScript, so you can't even claim that you can't maintain it because you don't know the implementation language. It doesn't depend on some build step (which often is the thing that breaks after a year).

Totally fair — longevity is a real concern, and I’ve had the same hesitation with new tools myself.

The nice thing about Dagger.js is that it’s intentionally very small and HTML-first. If the project disappeared tomorrow, your markup is still just plain HTML + attributes, and your components are still standard Web Components. There’s very little “lock-in” compared to bigger frameworks with proprietary syntax or build pipelines.

That said, I do intend to keep it alive — it’s under active development on GitHub, MIT licensed, and easy for others to fork or extend. If a year from now it still looks useful, I’d be glad for you (and others) to take another look.:)

And a very cool CI toolkit https://github.com/dagger/dagger (Apache 2)

Link to the DI mentioned by the parent comment https://github.com/google/dagger (also Apache 2)

Right — there’s also the dagger DI framework in the Java ecosystem. To avoid confusion: this project is dagger.js, a small runtime-only JavaScript library for HTML/Web Components. Totally unrelated to the Java DI framework other than sharing the name

Dagger is also a well known framework/runtime for task pipelines (dagger.io)

Was about to say that it's also a lightweight orm for .net, but apparently that's called dapper and I could swear it was dagger.

Isn't that what Svelte was aiming to do? It's moved on a ways since then, but you can still see the fundamentals in its demos: https://svelte.dev/playground/hello-world

Thanks for your comment.That's right — the compiled/optimized end of the spectrum is powerful, and I think Prepack showed just how far you can push that. However, dagger.js is intentionally the opposite: it trades the simplest usage for zero build, instant setup. My focus is “drop in a <script> and go,” not competing with compiler-driven stacks. In practice I see them as complementary — one for squeezing every byte/cycle, the other for minimizing friction and complexity.

> I’d actually love to see something that goes in the opposite direction, highly optimized and compiled, where the result is as small, fast, and efficient as possible

Right, but that is what basically every JS framework is going for these days. Its refreshing to see somebody trying to go back to old school non-compiled js/html where every front-end is open-source(ish)

I’m in a similar boat like you. I would love for a React-like library that compiles down to direct JavaScript DOM transforms. Of course Svelte exists but I don’t want to mark what is reactive or not and I can’t go back to html templates after using typed JSX. Also I don’t really like the “island” like template syntax of Vue, Svelte, etc

> I’d actually love to see something that goes in the opposite direction, highly optimized and compiled

+1, I genuinely miss php-like template development.

Can't believe there is no modern take on such a simple and powerful approach.

I feel like powerful php-like templating with typed props, proper module resolution, etc.

Website looks dead. I get Godaddy domain parking.

FYI: daggerjs.org is resolving to a GoDaddy domain parked page right now.

Will check out the repo linked at the end of your message.

Thanks! Totally agree — in most real-world apps the “runtime overhead” ends up dwarfed by everything else in the stack, so the build-free ergonomics can be a bigger win.

And nice, Mancha looks cool — I’ll give it a read and star. It looks similar with dagger in some features, for instance, mancha uses :data to create scope while dagger uses +load directive. Always great to see other takes on the runtime/compile spectrum; I think having multiple approaches out there is healthy for the ecosystem!

Thanks for reporting this issue, it's fixed now. Welcome back to scoop up dagger.js :)

Haha, true — the front page doesn’t always need another JS framework

dagger.js is tiny and pretty niche compared to the “big ones,” but I figured it was worth sharing since it’s trying to go backward a bit: no build, plain HTML, Web Components. More of a “view-source-able” experiment than a contender for the next React/Vue.

The last decade gave us enough JavaScript for a lifetime.

Using the full vue.js doesn't have a build step either.

I started out developing UIs using petite-vue, unfortunately ended up rewriting it to use full Vue.js after running into too many of its limitations and issues, which given that it's abandon-ware wont ever be resolved. As such I'd strongly recommend against starting projects with PetiteVue and just use the ESM build of Vue.js which also doesn't require a build step, has the full feature-set, is actively used and maintained, etc.

Either way developing Web Apps (using Vue) without a build step using JS Modules is now my preference which I've written about in my Simple, Modern JavaScript post [1]

[1] https://servicestack.net/posts/javascript

Yeah, that’s a fair comparison — Dagger.js lives in a similar space to petite-vue / Alpine: no build step, HTML-first, sprinkle behaviors where you need them.

The main differences are:

pure declarative mode → there is zero API and third-party code & tool dependency.

Web Components first → you can wrap functionality as native Custom Elements and Dagger will happily coexist.

Directive model → simple +click, +load, etc., instead of reactivity syntax or x- attributes.

Distributed modules → small script modules you can drop in from a CDN when you need them.

So it’s playing the same role (buildless, quick internal tools / embeds), but with a slightly different philosophy: keep everything view-source-able and make WC interop a first-class story.

Three reasons spring to mind:

1- the DOM APIs are very verbose, excepting perhaps replacing chunks by setting innerHTML, but

2- manual DOM manipulations aren't composable without also using web components

3- naive manual DOM manipulation can potentially be slow by way of triggering needless layouts/repaints or inefficient use of the APIs

Web components didn't exist when the major frameworks came about, and the ones before them handled composition rather poorly if at all (such as backbone). Angular, ember, react and company all sought to provide a cohesive story for code reuse and composition. Many had their own performance stories, though it was always a secondary concern to everything else.

I've done a bit of everything, including pure vanilla JS, just jQuery, vanilla + web components, all the way up to next, ember, angularjs and angular, and more. If you're building a web site, vanilla JS is fine. If you're building a web "app", you'll pretty quickly appreciate what a framework can bring to the table. If you don't, you'll also quickly find yourself building your own mini framework and runtime to manage things.

That’s totally valid — if you’re comfortable living close to the DOM, zero-runtime + zero-build is the purest path.

dagger.js is meant for folks who want to stay mostly in plain HTML/JS but still smooth out a few of those DOM “sharp edges” — e.g. inline state with +load, simple event handlers with +click, template interpolation. The idea is to reduce boilerplate without hiding what’s really happening underneath.

So it’s less about abstracting away the DOM entirely, and more about lowering the friction for small tools/demos where you don’t want to write a ton of document.createElement calls.

In dagger.js interpolation is scoped to attributes and text nodes — anywhere you put ${…} inside the HTML markup, the expression is evaluated against the current directive scope. In your sample code, winner is looked up from the nearest +load directive context. Interpolation isn’t “everywhere” JS-style, it’s only applied to the DOM text/attribute content that Dagger processes. Actually it's standard string template in JS. You may also use the text directive instead to avoid using inline expression: <div class="text" text="`${ winner ? 'Wins' : 'Draw' }!`"> </div>

Glad to hear that! Buildless is the whole idea — drop in a <script>, wire up a few +click / +load attributes, and you’re up and running. The goal is to keep things simple and view-source-able without needing a bundler or toolchain.

haha, it's sharp but not dangerous :}

As a frontend framework, Svelte apps absolutely run in the browser.However, Svelte relies on a compile step: your authoring code is compiled ahead of time into efficient JS that runs on the client. dagger.js is contrasting itself as purely runtime, build-free — you drop in a script, no compilation needed.

So it’s less about runtime location (Svelte is client-side too) and more about how you get there.

Svelte → compile first, then run in browser

dagger.js → no compile, just run in browser

Thanks for the thoughtful feedback — you raise valid concerns.

The reason dagger.js allows JS expressions in attributes is mostly about lowering the barrier to entry. By keeping everything in plain HTML, you can copy-paste a snippet, view-source it, and immediately see both the structure and the behavior in one place. For small widgets, docs, or internal tools, that convenience often outweighs the drawbacks.

You’re right that it’s technically not “valid HTML,” and that data-attributes would be more standards-compliant. I chose the lighter +click="count++" style because it makes the examples concise and easy to reason about — essentially HTML as a living playground. The trade-off is that it bends the rules a bit.

That said, I agree separation of concerns is important. dagger.js is not trying to replace large frameworks or enforce this pattern everywhere. It’s intended as a minimal option where simplicity and quick iteration matter more than strict layering. If it proves useful but the attribute style becomes a blocker, I’m very open to exploring a data-* form or even alternate syntax.

Also, thank you for sharing your own framework — it looks great. Actually I’m considering adding a pre-compiled, separation-of-concerns version of dagger.js in the future to support a wider range of development needs.

And thanks as well for the docs suggestion about emojis. Feedback like this really helps shape the project in a healthier direction.