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.
replies(2):
Why I built it Modern stacks are powerful but often heavy: bundlers, compile steps, framework DSLs, local CLIs. For internal tools, small apps, and edge/serverless deployments, I wanted something you can view-source, paste into a page, and ship.
What it is:
Runtime-only: no build or VDOM compile; hydrate behaviors directly on HTML. HTML directives: e.g. +click, lifecycle +load / +loaded / +unload / +unloaded. Zero APIs: dagger.js works in pure declarative mode, modules and directives provide everything you need to build your application. Web-Components-first: works alongside Custom Elements; keep concerns local. Distributed modules: load small, focused script modules via CDN. Progressive enhancement: the page renders without a build step.
Use cases:
Admin panels & dashboards that don’t warrant a full toolchain Embed widgets, docs-sites with interactive bits Edge/serverless apps where cold start and simplicity matter
Links
GitHub: https://github.com/dagger8224/dagger.js Docs/Guide: https://daggerjs.org Examples: https://codepen.io/dagger8224/pens
I’d love feedback on edge-cases, and where it breaks. Happy to answer tough questions here.
Once this project is about a year old, if it still has any commits, then I'd consider it.
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.:)
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.
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.
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.