←back to thread

Show HN: Dagger.js – A buildless, runtime-only JavaScript micro-framework

(daggerjs.org)
77 points TonyPeakman | 1 comments | 15 Sep 25 01:28 UTC | HN request time: 0s | source

TL;DR: dagger.js is a buildless, runtime-only micro-framework that plays nicely with native Web Components. It uses HTML-first directives (e.g. +click, +load) so you can ship a page by dropping a single <script> from a CDN—no bundlers, no compile step.

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.

Show context
taosx ◴[15 Sep 25 03:09 UTC] No.45245712[source]▶
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

replies(5): >>45245849 #>>45245905 #>>45246845 #>>45247404 #>>45247789 #
1. TonyPeakman ◴[15 Sep 25 08:29 UTC] No.45247404[source]▶
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.