←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 #
harrygeez ◴[15 Sep 25 03:35 UTC] No.45245849[source]▶
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
replies(4): >>45246132 #>>45246774 #>>45246977 #>>45247522 #
bytehowl ◴[15 Sep 25 06:38 UTC] No.45246774[source]▶
Isn't that actually SolidJS?

https://solidjs.com

replies(1): >>45247541 #
1. TonyPeakman ◴[15 Sep 25 08:52 UTC] No.45247541[source]▶
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.