Live data from Hacker News

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

daggerjs.org

71–80 of 93 posts

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

#71
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

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

#72

Earlier quoted context omitted.

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 conf…

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 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.

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

#73
post #70
post #52

Earlier quoted context omitted.

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…

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://gi…

>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.

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

#74
post #73
post #70

Earlier quoted context omitted.

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://gi…

>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 versio…

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.

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

#75
post #71

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 stack…

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.

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

#76
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).

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

#78
post #72

Earlier quoted context omitted.

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 conf…

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…

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.

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

#79

Earlier quoted context omitted.

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 conf…

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 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.

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

#80
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!

Post reply on HN