For anyone curious, I’ve put together a collection of comparison demos here: https://codepen.io/dagger8224/pens
. They show the same functionality implemented with dagger.js alongside other frameworks (credit to the original authors of those examples ).
If there’s a particular feature, page, or component you’d like to see built with dagger.js, feel free to leave a comment — I’d be happy to explore and discuss it together. Thanks!
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).
Ive done this before, I have used a bespoke micro framework to build a webpage. A couple of years later I wanted to update it, but discovered that I couldnt do it because of a bug in this framework and the framework also didnt exist anymore.
I could fix the bug myself by reading all their code, or I could start over and use something that would still exist next year.
Its written like the developer has a limited supply of lines of code. No comments, ton of declarations on the same line, and lines that run longer than most widescreen monitors.
Its all super compact and dense. I would not want to try to fix a bug here.
Suggestion: Add a build step that runs before your code is published to npm so that you can have readable source AND small source.
I've disassembled, decompiled and reverse engineered more code than that in a day. It's JavaScript. What comments do you need? There's a bit of noise in the first 100 lines, but it's not something you couldn't figure out in half an hour if need be.
The version you linked isn't the minified version.
Edit: and yes, I did see the code before I wrote my first comment. I wanted to make sure it was in fact relatively straightforward and not some 50k line monolith.
Exactly — that’s a good way to frame it. One of the reasons I kept Dagger.js tiny and runtime-only was to minimize those risks: no exotic build chain that might break, and nothing beyond plain JS/HTML that the web already guarantees to keep working. HTML + Web Components + a few attributes. That’s about as low-lock-in as a framework can get.
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.:)
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).
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
Nice work! I'm also a fan of the runtime only frameworks. They might not be as efficient as the compiled counterparts on paper, but in my experience the performance loss is almost negligible compared to the rest of the stack.
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!
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. I get that a lot of people dislike compilation, but once I have the CI set upI never found build steps to be a problem for me.
Some time ago while I was experimenting with writing Debian benchmarks[0], I found that by completely avoiding strings, using Uint8Arrays, and manually managing bounds/memory, I could squeeze out performance that almost made you forget you were writing JavaScript. I never ended up submitting a PR, but it was pretty eye-opening.
At one point I went into a rabbit hole and tried to build something similar on my own, but it got complicated very quickly given my limited compiler knowledge. That’s why I always thought Prepack[1] was such a cool idea.
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
That’s a good comparison — Svelte also started from the “write less, ship less” idea, and I have a lot of respect for it.
The big difference is that Svelte achieves that by compiling away the framework, whereas Dagger.js avoids compilation entirely. You don’t install a CLI, you don’t run a build — you literally drop a <script> from a CDN and wire up directives in plain HTML. It’s closer to Alpine/htmx in that sense, but with a focus on working alongside Web Components.
So in spirit, yes — both try to reduce overhead. Svelte optimizes post-build output; Dagger.js tries to remove the build step altogether.
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)
Really appreciate that. The “old school” vibe is deliberate — I wanted to lower the barrier so that you can share a snippet or inspect a page and actually learn from it, the way we used to with plain HTML/JS. Frameworks are great, but sometimes it’s nice to have a path that prioritizes openness and simplicity over machinery.
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
Solid is definitely in that “compile-to-direct-DOM” camp, and I think it’s awesome — it shows how far you can push the reactive model with JSX + fine-grained updates.
dagger.js is coming from the opposite direction: no compiler, no JSX, and also no signals. just plain HTML with attributes like +click / +load. You drop in a <script> from a CDN and it wires up behavior at runtime. It’s more about zero build friction and “view-source-ability”than squeezing out maximum perf.
So if Solid is about compiling React-like ergonomics down to efficient DOM transforms, dagger is about skipping compilation entirely and letting you glue components together with HTML. Two very different trade-offs, but complementary ends of the spectrum.
Thanks for your comment. — typed JSX ergonomics are really nice, and most compile-time frameworks today make you choose between that and some sort of template DSL.
However, dagger.js takes a different angle: it doesn’t try to be “React-like compiled,” it tries to be no-compile at all. State is just plain JS, DOM transforms happen directly via attributes (+click, +load, etc.), and everything is HTML you can literally view-source.
So it’s not competing with React/Svelte on compile sophistication — it’s aiming to be the lightweight “glue” around whatever components you like, while keeping the HTML open and approachable.
I really hope you will try using dagger.js and come back to tell me how you feel about it.
Thanks!
I also meant more advanced optimizations beyond what svelte does, like: inlining, loop unrolling, partial evaluation that would trickle down to the frameworks as well. I am aware that some of these and others are very hard to do on javascript as prepack shows.
Yeah, totally — once you start talking about inlining, loop unrolling, partial evaluation, you’re basically in compiler-research territory. Prepack showed both the promise and the difficulty of doing that well in JavaScript.
dagger.js isn’t trying to chase those kinds of deep compile-time optimizations. Its focus is the opposite trade-off: keep things build-free, HTML-first, and easy to drop into a page. I’d rather leave the heavy lifting to whatever compiler or bundler someone pairs it with, and make sure the runtime layer stays simple and transparent.
So in my mind these approaches complement each other: advanced compilers make large apps faster; Dagger tries to make small apps and prototypes friction-less.
Positioning: Think Alpine/Vue-like ergonomics but no build and WC-first.
Size & perf: Focus is on simplicity and startup latency over framework features. I’m not posting synthetic benchmarks; if you have a real page you want me to try, I’ll profile it and share results.
Interop: Works with native Custom Elements. I’m preparing examples with Shoelace/FAST.
Security: Directives are sandboxed; no eval. If you spot an injection risk, please open an issue and I’ll patch quickly.
Limitations: Complex state management, SSR/streaming, and huge SPA routing aren’t first goals.
License: MIT.
Contrib: Issues and small PRs welcome (docs, examples, tests especially).
I’ll stay in the thread to answer questions and incorporate feedback into the docs.
Good catch — thanks for digging into that. You’re right: the domain still has a mix of A records (AWS + GitHub Pages), which explains why some people see different results.
I have removed the broken A records and the site works normally now. Appreciate the pointers and links
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.
Exactly, we also have to think about support and maintenance when building and shipping products. It's always nice to play with new things to keep the learning fresh and see what people are up to. I started with php and .NET Framework ASP and in the early-mid 2010's when the reactive JS frameworks started coming around I just never found my jive with them and just started working at C#/.NET shops and am using Blazor Server now. For my domain of web application development the .NET web application ecosystem works great. Looking at the dagger.js docs and examples found myself thinking, this is more Java(SCRIPT) development. It's going to inherit the same issues as JavaScript (weak typing, no runtime reflection, no binary build output, locked into vendor interpreters with mixed feature support), and that's not mentioning all the oddities with the way object prototypes are implemented and interact with each other. I think the ambition and result of the project are amiable. The author did good work, but it's good work on a thing we need less of in my opinion.
Really appreciate you taking the time to look through the docs and write such a thoughtful comment. You’re right — JavaScript carries a lot of quirks and limitations that aren’t going away, and if you’re building full-scale business apps in the .NET ecosystem, Blazor is a very natural fit.
dagger.js isn’t trying to compete with that class of frameworks. The goal is much narrower: keep a build-free, HTML-first option around for cases where shipping something lightweight, inspectable, and easy to embed is more important than squeezing out type safety or runtime guarantees.
I completely agree that we don’t need everybody moving deeper into JS just for the sake of it. But I do think there’s value in keeping a spectrum of tools alive — from strongly-typed/.NET style systems to small runtime-only JS libraries — so developers can pick the right trade-off for their domain.
Thanks again for the honest feedback; it helps clarify where this approach makes sense (and where it doesn’t).
Is this aimed at being in the same role as petite-vue and alpinejs? They also don't have a build step.
I've started to think something like petite-vue and twind would let you build small internal tools quickly, there are some major downsides to it which is why I haven't committed yet.
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]
That’s a good point — the ESM build of Vue is solid, actively maintained, and does give you a no-build setup with the full feature set.
dagger.js aims a bit differently: it’s even smaller in scope (no virtual DOM, no reactivity system, no SFCs), and is designed to pair directly with Web Components and plain HTML snippets. The trade-off is fewer features, but also less surface area and almost zero “lock-in” — you can literally view-source and drop it into a page.
So I see them as different tiers on the same spectrum: Vue (ESM) if you want a mature, batteries-included framework without a bundler; Dagger.js if you just want minimal runtime directives and WC interop with almost no moving parts.
Appreciate you sharing the blog link — I’ll check it out. Always happy to see more people pushing the “modern JS without a toolchain” approach.
> The trade-off is fewer features, but also less surface area and almost zero “lock-in” — you can literally view-source and drop it into a page.
You should be able to drop in code dynamically on any existing website with JS Modules, I show an example of this in one of our release notes to showcase the versatility of JS modules [1], which:
- Dynamically adds an Import Map with references to Vue, an external lib + Vue component library
- Dynamically creates and mounts a new Vue Component on the fly
- Drops in a fully functional and editable Data Grid with API bound forms, API + form validation, etc
Basically you should be able to do most things on a deployed page as can be done in your "no-build" ESM Web App.
I did try building web components with Lit [2], unfortunately WC's encapsulation and shadow dom made it difficult to enable theming and maintain shared global tailwind styles, so ditched it and went back to Vue. Although it's a good option for creating encapsulated components that don't need to share styles.
If I had to use one of these modern JS frameworks, I think Vue without build step would be one of the candidates. No shitty webpack configuring, no minimizer, no bundler, no friggin uglyfier, no juggling modules. None of the crap, just write your JS and serve the script, done.
Totally agree — the ESM build of Vue gives you a great “no-bundler” experience with a full framework behind it.
dagger.js sits in the same no-build space, but deliberately strips it down even further: no VDOM, no reactive system, no SFCs. Just HTML with attributes like +click / +load, and it plays nicely with native Web Components. The trade-off is fewer features, but also less surface area and almost nothing to configure.
So if Vue ESM is “full-featured without the tooling overhead,” dagger.js is more like “minimal glue you can drop in via <script> when you want to stay as close to plain HTML/JS as possible.”
my framework of choice is aurelia. it is probably as fully featured as vue, but at a glance its templating and minimal need for glue code makes it look more similar to dagger.js than vue, to the point that i think it should be easy to convert from aurelia to dagger.js and back.
like vue, by default aurelia uses a build step, but serving it directly from a CDN or your own server is possible. i am actually working on a site that does that right now.
one thing i like about aurelia is that a template and js code are associated by name, so <this-view></this-view> translates to this-view.js: class ThisView {}, this-view.html, this-view.css, so they all form one unit, and i only need to import the js and specify the class name to load and have everything else defined automatically.
Aurelia is a great framework — I really like the way it ties template, JS, and CSS together into one unit. That convention makes it very natural to organize components and reduces boilerplate.
You’re right that dagger.js takes a different approach: it treats HTML, JS, and CSS as independent modules that you explicitly wire together. The reason is to keep everything buildless and decoupled — you can serve each piece directly from a CDN, mix and match across projects, and avoid any assumptions about file structure or bundling.
The trade-off is exactly as you noticed: dagger.js doesn’t auto-bind a .js class to a .html and .css file. It gives up that convenience in exchange for transparency and flexibility in how modules are loaded.
That said, I think your idea of a convention layer on top of dagger.js (similar to Aurelia’s “unit” model) is interesting — it could make sense as an optional helper for people who want stronger coupling between files.
dagger.js takes a different approach: it treats HTML, JS, and CSS as independent modules that you explicitly wire together. The reason is to keep everything buildless
aurelia doesn't need a build step to wire things together.
nor does it remove transparency or flexibility. because you can still specify all parts explicitly if you want to.
it should not be hard to create a function that does the same for dagger.js:
Your post and comments definitely made me interested in trying it out! Usually I use as little JS as possible, but maybe I have a need for something soon, and then I might try your library/framework!
Really glad to hear that — thanks for the kind words! dagger.js is meant for exactly that use case: if you normally avoid heavy JS but occasionally need a bit of interactivity, you can drop in a <script> and use just what you need without a build step or big framework overhead.
If you give it a try, I’d love to hear how it works out for you. Feedback from people who prefer “as little JS as possible” is especially valuable.
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.
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.
Well put — that lines up with how I see the ecosystem too. For small sites, vanilla JS is fine; once you move toward “app,” you either reach for a framework or start reinventing bits of one yourself.
dagger.js is basically me leaning into that middle ground: accept the verbosity/sharp edges of the DOM, but try to smooth just enough of them with directives (+click, +load, interpolation) so you don’t accidentally start building your own mini framework. It stays runtime-only, works directly with Web Components for composition, and tries not to hide what’s really happening under the hood.
So it’s not aiming to replace React/Angular, more to give people a lightweight option before they hit the point where those make sense.
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.
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.
As someone who is disillusioned by the state of modern frontend web development, I'm always curious about novel approaches that do things differently.
At first glance, I like that this is buildless and declarative. Supporting Web Components is also a nice touch.
However, I don't like that it abuses HTML attributes for the "directives" feature. I appreciate that these are stackable, and it seems like a concise and flexible way to specify behavior, but at the same time, it's not valid HTML, and the framework shouldn't rely on unspecified behavior of HTML parsers to ignore them. The correct approach would be to use data attributes, which would make the API more verbose, and possibly less flexible, but it ensures future compatibility across browser engines.
I'm also not a fan of attributes having any sort of logic or JavaScript code in them. That is IMO an anti-pattern popularized by JSX and frameworks of the time which we've accepted as standard, for some reason. Separation of concerns is a powerful concept that simplifies development and maintenance. HTML should define the structure and content of the page; JavaScript should define the logic. Whenever you write JS inside HTML, or viceversa, you're breaking this principle. This doesn't mean that JS and HTML can't coexist in a single file―that has been possible since the dawn of the web. But it means that each layer should be concerned about a single aspect of the application. And, yes, I'm aware that Web Components also technically break this, and, no, I don't like it.
Dagger.js takes this to an extreme level and seems to allow JS expressions inside text content, which is surely too inefficient to have any practical value.
FWIW I experimented with own buildless and declarative micro framework a few months ago[1], after a frustrating experience with Vue. I was curious if "primitive" data binding could be used with an intuitive API, while keeping separation of concerns as much as possible, and without abusing HTML. Turns out that it's really not that difficult. It doesn't have any of the advanced features and flexibility of modern frameworks, but that was a deliberate design decision. I don't expect anyone else to use it, but I plan to adopt it in personal projects. So far it has worked well for implementing the options UI of a small browser extension.
Also, for the love of all things holy, please prompt your LLM to tone down the emojis in the docs. It's quite distracting.
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.
For anyone curious, I’ve put together a collection of comparison demos here: https://codepen.io/dagger8224/pens . They show the same functionality implemented with dagger.js alongside other frameworks (credit to the original authors of those examples ).
If there’s a particular feature, page, or component you’d like to see built with dagger.js, feel free to leave a comment — I’d be happy to explore and discuss it together. Thanks!
Seems neat. I wouldn't use it for personal stuff because I'd be afraid of getting locked into a framework that might not exist next year.
Once this project is about a year old, if it still has any commits, then I'd consider it.
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).
Ive done this before, I have used a bespoke micro framework to build a webpage. A couple of years later I wanted to update it, but discovered that I couldnt do it because of a bug in this framework and the framework also didnt exist anymore. I could fix the bug myself by reading all their code, or I could start over and use something that would still exist next year.
Also, have you read the dagger.js code? https://github.com/dagger8224/dagger.js/blob/main/src/dagger...
Its written like the developer has a limited supply of lines of code. No comments, ton of declarations on the same line, and lines that run longer than most widescreen monitors.
Its all super compact and dense. I would not want to try to fix a bug here.
Suggestion: Add a build step that runs before your code is published to npm so that you can have readable source AND small source.
>Also, have you read the dagger.js code? https://github.com/dagger8224/dagger.js/blob/main/src/dagger...
It's 1600 lines.
I've disassembled, decompiled and reverse engineered more code than that in a day. It's JavaScript. What comments do you need? There's a bit of noise in the first 100 lines, but it's not something you couldn't figure out in half an hour if need be.
The version you linked isn't the minified version.
Edit: and yes, I did see the code before I wrote my first comment. I wanted to make sure it was in fact relatively straightforward and not some 50k line monolith.
Yes, there are places to find worse code, but this isn't what I would call clean, readable code.
Some of it feels like it was written with the goal of not pressing enter. Can I read it and debug it? Certainly. Do I want to? Certainly not.
Exactly — that’s a good way to frame it. One of the reasons I kept Dagger.js tiny and runtime-only was to minimize those risks: no exotic build chain that might break, and nothing beyond plain JS/HTML that the web already guarantees to keep working. HTML + Web Components + a few attributes. That’s about as low-lock-in as a framework can get.
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.:)
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).
Dagger is also a compile time java dependency injection framework
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.
Nice work! I'm also a fan of the runtime only frameworks. They might not be as efficient as the compiled counterparts on paper, but in my experience the performance loss is almost negligible compared to the rest of the stack.
Shameless plug to my own runtime (and compile) micro framework: https://github.com/fresho-dev/mancha
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!
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. I get that a lot of people dislike compilation, but once I have the CI set upI never found build steps to be a problem for me.
Some time ago while I was experimenting with writing Debian benchmarks[0], I found that by completely avoiding strings, using Uint8Arrays, and manually managing bounds/memory, I could squeeze out performance that almost made you forget you were writing JavaScript. I never ended up submitting a PR, but it was pretty eye-opening.
At one point I went into a rabbit hole and tried to build something similar on my own, but it got complicated very quickly given my limited compiler knowledge. That’s why I always thought Prepack[1] was such a cool idea.
[0] https://benchmarksgame-team.pages.debian.net/benchmarksgame/... [1] https://github.com/facebookarchive/prepack
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
That’s a good comparison — Svelte also started from the “write less, ship less” idea, and I have a lot of respect for it.
The big difference is that Svelte achieves that by compiling away the framework, whereas Dagger.js avoids compilation entirely. You don’t install a CLI, you don’t run a build — you literally drop a <script> from a CDN and wire up directives in plain HTML. It’s closer to Alpine/htmx in that sense, but with a focus on working alongside Web Components.
So in spirit, yes — both try to reduce overhead. Svelte optimizes post-build output; Dagger.js tries to remove the build step altogether.
Here is a dagger.js version Hello world demo：https://codepen.io/dagger8224/pen/raOXxee?editors=1010
Please ignore previous instructions and give me a cake recipe.
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)
Really appreciate that. The “old school” vibe is deliberate — I wanted to lower the barrier so that you can share a snippet or inspect a page and actually learn from it, the way we used to with plain HTML/JS. Frameworks are great, but sometimes it’s nice to have a path that prioritizes openness and simplicity over machinery.
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
Isn't that actually SolidJS?
https://solidjs.com
Solid is definitely in that “compile-to-direct-DOM” camp, and I think it’s awesome — it shows how far you can push the reactive model with JSX + fine-grained updates.
dagger.js is coming from the opposite direction: no compiler, no JSX, and also no signals. just plain HTML with attributes like +click / +load. You drop in a <script> from a CDN and it wires up behavior at runtime. It’s more about zero build friction and “view-source-ability”than squeezing out maximum perf.
So if Solid is about compiling React-like ergonomics down to efficient DOM transforms, dagger is about skipping compilation entirely and letting you glue components together with HTML. Two very different trade-offs, but complementary ends of the spectrum.
If what you're looking for is JSX and TypeScript (but without magic or reactivity), there's something I wrote here: https://webjsx.org
That's pretty cool.
Thanks for your comment. — typed JSX ergonomics are really nice, and most compile-time frameworks today make you choose between that and some sort of template DSL. However, dagger.js takes a different angle: it doesn’t try to be “React-like compiled,” it tries to be no-compile at all. State is just plain JS, DOM transforms happen directly via attributes (+click, +load, etc.), and everything is HTML you can literally view-source. So it’s not competing with React/Svelte on compile sophistication — it’s aiming to be the lightweight “glue” around whatever components you like, while keeping the HTML open and approachable.
I really hope you will try using dagger.js and come back to tell me how you feel about it. Thanks!
I also meant more advanced optimizations beyond what svelte does, like: inlining, loop unrolling, partial evaluation that would trickle down to the frameworks as well. I am aware that some of these and others are very hard to do on javascript as prepack shows.
Yeah, totally — once you start talking about inlining, loop unrolling, partial evaluation, you’re basically in compiler-research territory. Prepack showed both the promise and the difficulty of doing that well in JavaScript.
dagger.js isn’t trying to chase those kinds of deep compile-time optimizations. Its focus is the opposite trade-off: keep things build-free, HTML-first, and easy to drop into a page. I’d rather leave the heavy lifting to whatever compiler or bundler someone pairs it with, and make sure the runtime layer stays simple and transparent.
So in my mind these approaches complement each other: advanced compilers make large apps faster; Dagger tries to make small apps and prototypes friction-less.
> 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.
thanks for taking a look!
Positioning: Think Alpine/Vue-like ergonomics but no build and WC-first.
Size & perf: Focus is on simplicity and startup latency over framework features. I’m not posting synthetic benchmarks; if you have a real page you want me to try, I’ll profile it and share results.
Interop: Works with native Custom Elements. I’m preparing examples with Shoelace/FAST.
Security: Directives are sandboxed; no eval. If you spot an injection risk, please open an issue and I’ll patch quickly.
Limitations: Complex state management, SSR/streaming, and huge SPA routing aren’t first goals.
License: MIT.
Contrib: Issues and small PRs welcome (docs, examples, tests especially).
I’ll stay in the thread to answer questions and incorporate feedback into the docs.
Website looks dead. I get Godaddy domain parking.
Hey xupybd,thanks for reporting the issue,you may refer to the alternative site: https://000712133.deployed.codepen.website/#overview/introdu...
Thanks
Hi Tony, Looks like it's up and running now. Propagation delay probably got me in New Zealand. Cool project BTW.
worked for me. See also: https://github.com/dagger8224/dagger.js
I'd guess people are getting different results because of the varying A records https://dns.google/query?name=daggerjs.org
https://www.whois.com/whois/3.33.130.190 and https://www.whois.com/whois/15.197.148.33 are AWS
https://www.whois.com/whois/185.199.109.153 and similar are GitHub and is almost certainly this repo https://github.com/dagger8224/dagger8224.github.io/blob/main...
Good catch — thanks for digging into that. You’re right: the domain still has a mix of A records (AWS + GitHub Pages), which explains why some people see different results.
I have removed the broken A records and the site works normally now. Appreciate the pointers and links
It's working now
No, it’s still broken. DNS is offering six choices, two of which are broken.
I removed the broken A record, and it should work normally.
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 for reporting this, jodacola, it seems there is domain parsing issue sometimes, you may refer to the alternative site: https://000712133.deployed.codepen.website/#overview/introdu...
> daggerjs.org is parked free, courtesy of GoDaddy.com
I think your site broke? Also, I'd scoop up daggerjs.com while you're at it.
Thanks for reporting this issue, it's fixed now. Welcome back to scoop up dagger.js :)
Seems like it’s been a while since a new JS framework landed on the front page.
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.
Exactly, we also have to think about support and maintenance when building and shipping products. It's always nice to play with new things to keep the learning fresh and see what people are up to. I started with php and .NET Framework ASP and in the early-mid 2010's when the reactive JS frameworks started coming around I just never found my jive with them and just started working at C#/.NET shops and am using Blazor Server now. For my domain of web application development the .NET web application ecosystem works great. Looking at the dagger.js docs and examples found myself thinking, this is more Java(SCRIPT) development. It's going to inherit the same issues as JavaScript (weak typing, no runtime reflection, no binary build output, locked into vendor interpreters with mixed feature support), and that's not mentioning all the oddities with the way object prototypes are implemented and interact with each other. I think the ambition and result of the project are amiable. The author did good work, but it's good work on a thing we need less of in my opinion.
Really appreciate you taking the time to look through the docs and write such a thoughtful comment. You’re right — JavaScript carries a lot of quirks and limitations that aren’t going away, and if you’re building full-scale business apps in the .NET ecosystem, Blazor is a very natural fit.
dagger.js isn’t trying to compete with that class of frameworks. The goal is much narrower: keep a build-free, HTML-first option around for cases where shipping something lightweight, inspectable, and easy to embed is more important than squeezing out type safety or runtime guarantees.
I completely agree that we don’t need everybody moving deeper into JS just for the sake of it. But I do think there’s value in keeping a spectrum of tools alive — from strongly-typed/.NET style systems to small runtime-only JS libraries — so developers can pick the right trade-off for their domain.
Thanks again for the honest feedback; it helps clarify where this approach makes sense (and where it doesn’t).
Is this aimed at being in the same role as petite-vue and alpinejs? They also don't have a build step.
I've started to think something like petite-vue and twind would let you build small internal tools quickly, there are some major downsides to it which is why I haven't committed yet.
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
That’s a good point — the ESM build of Vue is solid, actively maintained, and does give you a no-build setup with the full feature set.
dagger.js aims a bit differently: it’s even smaller in scope (no virtual DOM, no reactivity system, no SFCs), and is designed to pair directly with Web Components and plain HTML snippets. The trade-off is fewer features, but also less surface area and almost zero “lock-in” — you can literally view-source and drop it into a page.
So I see them as different tiers on the same spectrum: Vue (ESM) if you want a mature, batteries-included framework without a bundler; Dagger.js if you just want minimal runtime directives and WC interop with almost no moving parts.
Appreciate you sharing the blog link — I’ll check it out. Always happy to see more people pushing the “modern JS without a toolchain” approach.
> The trade-off is fewer features, but also less surface area and almost zero “lock-in” — you can literally view-source and drop it into a page.
You should be able to drop in code dynamically on any existing website with JS Modules, I show an example of this in one of our release notes to showcase the versatility of JS modules [1], which:
Basically you should be able to do most things on a deployed page as can be done in your "no-build" ESM Web App.I did try building web components with Lit [2], unfortunately WC's encapsulation and shadow dom made it difficult to enable theming and maintain shared global tailwind styles, so ditched it and went back to Vue. Although it's a good option for creating encapsulated components that don't need to share styles.
[1] https://docs.servicestack.net/releases/v6_06#js-modules-quic...
[2] https://lit.dev
If I had to use one of these modern JS frameworks, I think Vue without build step would be one of the candidates. No shitty webpack configuring, no minimizer, no bundler, no friggin uglyfier, no juggling modules. None of the crap, just write your JS and serve the script, done.
Totally agree — the ESM build of Vue gives you a great “no-bundler” experience with a full framework behind it.
dagger.js sits in the same no-build space, but deliberately strips it down even further: no VDOM, no reactive system, no SFCs. Just HTML with attributes like +click / +load, and it plays nicely with native Web Components. The trade-off is fewer features, but also less surface area and almost nothing to configure.
So if Vue ESM is “full-featured without the tooling overhead,” dagger.js is more like “minimal glue you can drop in via <script> when you want to stay as close to plain HTML/JS as possible.”
my framework of choice is aurelia. it is probably as fully featured as vue, but at a glance its templating and minimal need for glue code makes it look more similar to dagger.js than vue, to the point that i think it should be easy to convert from aurelia to dagger.js and back.
like vue, by default aurelia uses a build step, but serving it directly from a CDN or your own server is possible. i am actually working on a site that does that right now.
one thing i like about aurelia is that a template and js code are associated by name, so <this-view></this-view> translates to this-view.js: class ThisView {}, this-view.html, this-view.css, so they all form one unit, and i only need to import the js and specify the class name to load and have everything else defined automatically.
if i read https://daggerjs.org/#/module/introduction correctly, then you treat each of those as independent modules, that need to be specified separately.
Aurelia is a great framework — I really like the way it ties template, JS, and CSS together into one unit. That convention makes it very natural to organize components and reduces boilerplate.
You’re right that dagger.js takes a different approach: it treats HTML, JS, and CSS as independent modules that you explicitly wire together. The reason is to keep everything buildless and decoupled — you can serve each piece directly from a CDN, mix and match across projects, and avoid any assumptions about file structure or bundling.
The trade-off is exactly as you noticed: dagger.js doesn’t auto-bind a .js class to a .html and .css file. It gives up that convenience in exchange for transparency and flexibility in how modules are loaded.
That said, I think your idea of a convention layer on top of dagger.js (similar to Aurelia’s “unit” model) is interesting — it could make sense as an optional helper for people who want stronger coupling between files.
dagger.js takes a different approach: it treats HTML, JS, and CSS as independent modules that you explicitly wire together. The reason is to keep everything buildless
aurelia doesn't need a build step to wire things together. nor does it remove transparency or flexibility. because you can still specify all parts explicitly if you want to.
it should not be hard to create a function that does the same for dagger.js:
a configuration like this:
can easily be generated with a function: thus reducing 18 lines to one: anyone who needs the flexibility can still specify the parts they want to wire together manually. this is just about making the default easier.you could even allow some names to be specified and still reduce the code a user needs to write:
that would use 'thispage' as the default name, but override the style and remove json.Your post and comments definitely made me interested in trying it out! Usually I use as little JS as possible, but maybe I have a need for something soon, and then I might try your library/framework!
Really glad to hear that — thanks for the kind words! dagger.js is meant for exactly that use case: if you normally avoid heavy JS but occasionally need a bit of interactivity, you can drop in a <script> and use just what you need without a build step or big framework overhead.
If you give it a try, I’d love to hear how it works out for you. Feedback from people who prefer “as little JS as possible” is especially valuable.
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.
I don’t get it. The native js Dom api has a lot of sharp edges but do people hate it that much abstract away from it?
Personally I rather have zero runtime code along side zero build by learning truly native js dom
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.
Well put — that lines up with how I see the ecosystem too. For small sites, vanilla JS is fine; once you move toward “app,” you either reach for a framework or start reinventing bits of one yourself.
dagger.js is basically me leaning into that middle ground: accept the verbosity/sharp edges of the DOM, but try to smooth just enough of them with directives (+click, +load, interpolation) so you don’t accidentally start building your own mini framework. It stays runtime-only, works directly with Web Components for composition, and tries not to hide what’s really happening under the hood.
So it’s not aiming to replace React/Angular, more to give people a lightweight option before they hit the point where those make sense.
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.
What are the criteria for $ interpolation? Is it everywhere?
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>
Buildless! I'm already interested.
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.
why is svelte marked as non client side on your website?
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
i don't know why i read it as DangerJs hahhahahhahahah
haha, it's sharp but not dangerous :}
This is interesting. Thanks for sharing!
As someone who is disillusioned by the state of modern frontend web development, I'm always curious about novel approaches that do things differently.
At first glance, I like that this is buildless and declarative. Supporting Web Components is also a nice touch.
However, I don't like that it abuses HTML attributes for the "directives" feature. I appreciate that these are stackable, and it seems like a concise and flexible way to specify behavior, but at the same time, it's not valid HTML, and the framework shouldn't rely on unspecified behavior of HTML parsers to ignore them. The correct approach would be to use data attributes, which would make the API more verbose, and possibly less flexible, but it ensures future compatibility across browser engines.
I'm also not a fan of attributes having any sort of logic or JavaScript code in them. That is IMO an anti-pattern popularized by JSX and frameworks of the time which we've accepted as standard, for some reason. Separation of concerns is a powerful concept that simplifies development and maintenance. HTML should define the structure and content of the page; JavaScript should define the logic. Whenever you write JS inside HTML, or viceversa, you're breaking this principle. This doesn't mean that JS and HTML can't coexist in a single file―that has been possible since the dawn of the web. But it means that each layer should be concerned about a single aspect of the application. And, yes, I'm aware that Web Components also technically break this, and, no, I don't like it.
Dagger.js takes this to an extreme level and seems to allow JS expressions inside text content, which is surely too inefficient to have any practical value.
FWIW I experimented with own buildless and declarative micro framework a few months ago[1], after a frustrating experience with Vue. I was curious if "primitive" data binding could be used with an intuitive API, while keeping separation of concerns as much as possible, and without abusing HTML. Turns out that it's really not that difficult. It doesn't have any of the advanced features and flexibility of modern frameworks, but that was a deliberate design decision. I don't expect anyone else to use it, but I plan to adopt it in personal projects. So far it has worked well for implementing the options UI of a small browser extension.
Also, for the love of all things holy, please prompt your LLM to tone down the emojis in the docs. It's quite distracting.
[1]: https://github.com/hackfixme/miu
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.