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

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

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).

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.:)

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

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.

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)

+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.

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.

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!

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.

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.

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

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.