←back to thread

77 points TonyPeakman | 2 comments | | HN request time: 0.001s | 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
pyrolistical ◴[] No.45246529[source]
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

replies(2): >>45247243 #>>45247992 #
1. zdragnar ◴[] No.45247243[source]
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.

replies(1): >>45247996 #
2. TonyPeakman ◴[] No.45247996[source]
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.